Several Samsung display controllers use identical commands to enable
and disable their three levels of test keys. The drivers currently
duplicate these commands in local macros.
Move the commands to typed helpers in a private Samsung DSI header and
use them from the drivers which already identify the commands by their
test key level.
Assisted-by: LLM
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-drm-panels-sofef0-v1-1-9e841645beba@kernel.org
Replace the PL111 simple display pipe with explicit plane, CRTC and
encoder objects.
Move the existing timing, format and pitch validation into explicit
atomic check paths. Use commit-local plane state in the CRTC enable path
when reading framebuffer format state.
Move page-flip event handling to the CRTC commit path.
Signed-off-by: Ze Huang <ze.huang@oss.qualcomm.com>
Tested-by: Roshan Kumar <roshaen09@gmail.com> # Ze Huang's patch, QEMU vexpress
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260727-drm-simple-kms-removal-v3-4-cd5dc89858c6@oss.qualcomm.com
The PL110/PL111 controller scans out a single framebuffer and never
blends its alpha channel with anything. In every pixel-format table
each alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to
exactly the same register configuration as its XRGB/XBGR counterpart,
so the alpha byte was never used by the hardware.
Commit 860e748bdd ("drm: ensure blend mode supported if pixel format
with alpha exposed") added validation that warns when a plane exposes
alpha formats without a pixel blend mode property, and PL111 does exactly
that. With panic_on_warn enabled the warning prevents the syzkaller
vexpress-a15 manager from booting.
Drivers should not report formats they do not support, so remove the
alpha formats from all variant tables: the generic PL110, PL111 and
Nomadik tables in pl111_drv.c and the board-specific Integrator, IM-PD1,
Versatile and RealView/Versatile-Express tables in pl111_versatile.c,
plus the now dead case labels in the display setup and the Versatile
syscon connector switch, instead of advertising a blend mode property.
Behavior is unchanged for userspace that picks an XRGB/XBGR/RGB format;
alpha-picking clients fall back to the identical X variant.
Link: https://github.com/google/syzkaller/issues/7805
Fixes: 860e748bdd ("drm: ensure blend mode supported if pixel format with alpha exposed")
Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
Changes in v2: drop the alpha formats entirely instead of advertising a
DRM_MODE_BLEND_PIXEL_NONE property, per review feedback from Thomas
Zimmermann. Leandro's Reviewed-by from v1 is not carried as the
approach changed.
Changes in v3: v2 missed the board-specific variant tables in
pl111_versatile.c (Integrator, IM-PD1, Versatile, RealView and
Versatile Express), which still exposed alpha formats and would fall
through to the WARN_ONCE default in pl111_display_enable() on those
boards. Pointed out by the sashiko AI reviewer.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://github.com/google/syzkaller/issues/7805
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260910192526.137057-1-roshaen09@gmail.com
handle_mm_fault() must not be called from the mmap callback because
the VMA has not yet been linked. The handle_mm_fault() API contract
assumes that the VMA is already linked.
Remove the handle_mm_fault() call from the mmap callback. For imported
BOs, mark the mapping as invalid and rely on the first command submission
to fault in the pages.
For shmem BOs, set the VM_MIXEDMAP flag and use vm_insert_pages().
Implement amdxdna_gem_mixed_vm_ops to handle the page faults.
Fixes: e486147c91 ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260910211338.1102315-1-lizhi.hou@amd.com
In amdxdna_gem_obj_open(), abo->lock is held when calling
amdxdna_gem_add_bo_usage(), which then acquires client->mm_lock.
However, the heap update path may acquire these locks in the reverse
order, creating a potential deadlock.
Fix this by saving the client pointer locally before acquiring abo->lock,
and releasing abo->lock before calling amdxdna_gem_add_bo_usage().
Apply the same change to amdxdna_gem_obj_close().
Fixes: 1f513a3ec3 ("accel/amdxdna: Add per-process BO memory usage query support")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260902180955.3999242-2-lizhi.hou@amd.com
Accessing abo->client in amdxdna_gem_del_bo_usage() may result in a
use-after-free when the BO is imported via flink.
Disable flink import by verifying that filp->driver_priv matches the client
stored in abo->client before accessing the client.
Fixes: 3cc5d7a595 ("accel/amdxdna: Add carveout memory support for non-IOMMU systems")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260902180955.3999242-1-lizhi.hou@amd.com
Remove all unused interfaces that used to implement the functionality
of pre_switch and post_switch.
For pre_switch, remove vga_switcheroo_client_fb_set(). This further
allows for removing all symbols and data structures that refer to
fbdev; such as fb_info and fb_switch_outputs().
For post_switch, remove the reprobe callback from the client ops.
v2:
- move changes to fbcon and drivers into other patches
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-8-tzimmermann@suse.de
An output's attached display might have changed while a DRM client's
device did not have the output switched to it.
The nouveau_switcheroo_reprobe() callback sends a hotplug notice to
DRM's internal clients, so that they can reconfigure their display
output if necessary.
As post_switch callback replaces reprobe in vga_switcheroo, update
nouveau accordingly. In the other drivers, remove the NULL-assignment
to reprobe. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-7-tzimmermann@suse.de
Call drm_client_dev_acquire_outputs() from vga_switcheroo's pre_switch
callback. Pushes fbcon updates from vga_switcheroo into DRM's fbdev
emulation. This affects amdgpu, i915, nouveau and radeon. No other
drivers implement vga_switcheroo.
Also remove the calls to vga_switcheroo_client_fb_set() from fbcon. It
is called from the DRM client's hotplug and sets the fbcon's framebuffer
at vga_switcheroo. Running pre_switch and hotplug concurrently could
result in a deadlock between clientlist_mutex and vgasr_mutex. Hence
clean up fbcon here as well.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-6-tzimmermann@suse.de
Add post_switch to struct vga_switcheroo_client_ops to inform the
switcheroo client about a completed switch of the output.
This callback is intended to replace the reprobe client op. It is a
rename of reprobe for consistency with pre_switch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-5-tzimmermann@suse.de
Add pre_switch to struct vga_switcheroo_client_ops to inform the
switcheroo client about upcoming switches of the outputs.
This callback is intended to replace the hard-coded call to fbdev's
fb_switch_outputs(). With DRM supporting more clients than just fbdev
emulation, something more flexible is required.
v2:
- remove non-sensical gpu_bound documentation (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-4-tzimmermann@suse.de
Add the callback acquire_outputs to drm_client_funcs to inform an internal
DRM client that vga-switcheroo is about to switch the physical outputs to
the client's device. Allows the client to prepare its internal state for
the upcoming switch.
Wire up the DRM client helpers to invoke the helper for a device's
clients.
Implement acquire_outputs for fbdev emulation. Invoke fb_switch_outputs(),
which remaps framebuffers to virtual terminals in fbcon. Currently this
is still being done by vga-switcheroo. With more DRM clients becoming
available, vga-switcheroo needs to become client agonostic.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-3-tzimmermann@suse.de
We currently get <linux/fb.h> via <linux/vga_switcheroo.h>. Include it
explicitly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260709092215.168172-2-tzimmermann@suse.de
The atomic state tracking structures used to have a generic state
field to track the state to free when tearing down the
drm_atomic_commit. It has since been renamed to state_to_destroy in
__drm_planes_state, __drm_crtcs_state, __drm_connnectors_state, and
__drm_private_objs_state to better describe its purpose.
The colorop support has been added after that rename, but
__drm_colorops_state still uses the old state name. Rename it to
state_to_destroy for consistency, and add the matching kerneldoc.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260908-drm-reset-state-flag-v3-1-905570f387a4@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The st7920 crtc implementation provides a custom reset hook. However,
this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), and warns if there's a previous state.
It does not perform any hardware reset.
Since this is exactly what the atomic_create_state hook is meant to
do, minus the old state cleanup which the caller handles, convert the
implementation to use atomic_create_state with
__drm_atomic_helper_crtc_state_init() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-11-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The mediatek crtc implementation provides a custom reset hook.
However, this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), and frees the previous state. It
does not perform any hardware reset.
Since this is exactly what the atomic_create_state hook is meant to
do, minus the old state cleanup which the caller handles, convert the
implementation to use atomic_create_state with
__drm_atomic_helper_crtc_state_init() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-10-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The loongson crtc implementation provides a custom reset hook. However,
this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), and frees the previous state. It does
not perform any hardware reset.
Since the atomic_create_state hook is only meant to deal with state
allocation and initialization, convert it accordingly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-9-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The loongson crtc reset hook performs both atomic state initialization
using __drm_atomic_helper_crtc_reset() and hardware-level register
writes to reset the CRTC.
The hardware reset is not related to atomic state initialization, and
the reset hook is being converted to atomic_create_state which only
deals with state allocation. Move the hardware reset to the hw_reset
helper hook instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-8-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The amdgpu display manager crtc implementation provides a custom reset
hook. However, this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), and frees the previous state. It
does not perform any hardware reset.
Since this is exactly what the atomic_create_state hook is meant to
do, minus the old state cleanup which the caller handles, convert the
implementation to use atomic_create_state with
__drm_atomic_helper_crtc_state_init() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-7-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tilcdc crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook.
Switch to drm_atomic_helper_crtc_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-5-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tilcdc crtc reset hook performs both atomic state initialization
using drm_atomic_helper_crtc_reset() and hardware-level register
writes to disable the raster and clear IRQ status.
The hardware reset is not related to atomic state initialization, and
the reset hook is being converted to atomic_create_state which only
deals with state allocation. Move the hardware reset to the hw_reset
helper hook instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-4-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The logicvc crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook.
Switch to drm_atomic_helper_crtc_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-3-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The amdgpu vkms crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook.
Switch to drm_atomic_helper_crtc_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-2-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The CRTC reset hook conflates initial software state allocation with
hardware reset. The atomic_create_state hook addresses the software
state side, but drivers may still need to reset hardware to a known good
state during drm_mode_config_reset(), for example during suspend/resume.
Separating hardware reset from state allocation is also useful for the
pending atomic state readout and userspace atomic reset flag series,
which need to create pristine software state without affecting the
hardware.
Introduce a hw_reset hook in struct drm_crtc_helper_funcs that only
resets the hardware, without touching the software state at all. Call it
from drm_mode_config_crtc_reset_with_create_state() after the state has
been successfully created.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260904-drm-no-more-crtc-reset-v3-1-27d9891512ce@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Convert gm12u320 to direct primary plane, CRTC and encoder setup.
Keep shadow-plane helper state, framebuffer access helpers and
no-scaling plane-state check from simple-KMS path.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ze Huang <ze.huang@oss.qualcomm.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260727-drm-simple-kms-removal-v3-5-cd5dc89858c6@oss.qualcomm.com
In commit dbe48d030b ("drm/sched: Split drm_sched_job_init") the only
use of the entity argument of drm_sched_fence_alloc(), fence->sched =
entity->rq->sched, moved into drm_sched_fence_init(), and the now unused
argument was left behind.
Drop the argument. The sole caller still passes the entity to
drm_sched_fence_init() at arm time, so behavior is unchanged. This also
removes the parameter-name mismatch between the declaration (s_entity)
and the definition (entity).
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260910054537.633952-1-donggeunyoo.kernel@gmail.com
Currently, the driver supports register access mode for DSI command
transfer, which limits both TX and RX to only 16 Bytes long packets.
Implement support for DSI command TX using AXI memory access mode,
which extends the packet transfer length up to 128 Bytes long in LP
and 1024 Bytes long in HS. Support for DSI command RX using the AXI
access mode is not implemented due to missing test hardware.
The implementation allocates a DMAble 4k page. In case the command
transfer is longer than 16 Bytes, the payload is copied into the
page and sent out using the AXI access mode, otherwise the register
access mode is used.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260910182003.31612-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is
provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the
crtc, when enabling the crtc.
With DSC in the pipeline, between the DU and the DSI, the above call
path is broken as the crtc tries to call rcar_mipi_dsi_pclk_enable() on
the DSC.
To solve this problem, make sure we store the DSI bridge to the
rcdu->dsi[] array, instead of the first bridge in the DSI pipeline
(which can be DSC), by checking the bridge's bridge->type.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260907-rcar-du-dsc-v6-3-f8ef711a7494@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The Renesas DSC Display Stream Compression is a bridge embedded in the
Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
8k or 400 Mpixel/s. Add rudimentary driver, which currently acts as a
pass-through bridge and allows DSI1 to be operational on R-Car V4H.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: use bridge->next_bridge, minor changes]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260907-rcar-du-dsc-v6-2-f8ef711a7494@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The Renesas DSC Display Stream Compression is a bridge embedded in the
Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
8k or 400 Mpixel/s.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: fix the example]
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260907-rcar-du-dsc-v6-1-f8ef711a7494@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Add a new DRM_IVPU_PARAM_CMDQ_PRIORITY parameter to query and update
the scheduling priority of an existing command queue, identified by
its ID via drm_ivpu_param.index.
The priority can be changed on a queue that already has pending jobs;
if the queue's doorbell is registered, the new priority is propagated
to the firmware immediately, otherwise it is applied when the queue is
next registered. The firmware picks up the change at the first
opportunity.
The feature requires HW scheduling mode and is advertised through the
new DRM_IVPU_CAP_CMDQ_SET_PRIORITY capability. Legacy command queues
are not supported.
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260831121617.395523-1-andrzej.kacprowski@linux.intel.com
Sysfb drivers currently use the given display mode for looking up the
panel orientation. But the look-up table stores the native geometry of
the panels, so the lookup fails if the current mode sizes differs.
Get the panel's native geometry with drm_edid_detect_panel_size() from
the EDID and use it for looking up the panel orientation.
v2:
- ofdrm: validate EDID header before using it (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-4-tzimmermann@suse.de
Add drm_edid_detect_panel_size() to extract the panel's preferred
display resolution from a given EDID. Required for setting up DRM's
panel orientation quirks in sysfb drivers.
v4:
- fix test for EDID PTD (Jani)
v3:
- mention use case in documentation (Jani)
- use is_detailed_timing_descriptor() (Jani)
- rename helper to drm_edid_detect_panel_size()
v2:
- handle EDID without pixel timing descriptor (Sashiko)
- fix checks for width and height pointers
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-3-tzimmermann@suse.de
The Lenovo D330 is a notebook with detachable display. The display
is installed in landscape orientation, but the display mode is in
portrait orientation. By default, the display output is rotated to
the left by 90°.
The sysfb quirk breaks the display by swapping display width and
height; and thus mixing up the display geometry. Fix this by keeping
the display as-is. The sysfb DRM drivers, usually efidrm, will pick
the correct panel orientation for the display.
The exact behavior might depend on the version of the BIOS release,
but the exact version numbers of broken and good releases are unknown.
Users are advised to update to the latest firmware.
Tested on a Lenovo D330-10IGM IdeaPad with firmware 8NCN43WW.
v3:
- mention possible dependency on BIOS release in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-2-tzimmermann@suse.de
Do not send the vblank event when the page flip completes, but when
the vblank interrupt fires. Sending the vblank event at the wrong time
can break synchronization of the display update with the vblank period.
Use the vblank helper drm_crtc_vblank_atomic_flush(), which sets up
the vblank event accordingly. In case of an error, it still sends out
the vblank event immediately; thus not starving consumers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
Link: https://patch.msgid.link/20260827082915.61176-3-tzimmermann@suse.de
Let the kernel know if hibmc did not handle an interrupt. Allows
the kernel to detect spurious interrupts and maintain diagnostics.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
Link: https://patch.msgid.link/20260827082915.61176-2-tzimmermann@suse.de
Add support for using SN65DSI84 in single-link mode with output to LVDS
Channel B.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Esben Haabendal <esben@geanix.com>
Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-2-e712765d6c4f@geanix.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Parse the optional 'data-lanes' device tree property to support
custom physical lane mapping configuration.
If no valid configuration is found, fall back to the default
lane map (0, 1, 2, 3) automatically and keep the driver running.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260828065153.590802-6-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Revert the change that made samsung,link-rate and samsung,lane-count
optional for Exynos DP. Add error checking to fail probe early if the
required DT properties are missing.
If these properties are missing, video_info->max_link_rate and
video_info->max_lane_count remain zero, and so do link_train.link_rate
and link_train.lane_count used in the subsequent link training flow,
resulting in link training failure.
There is no way at all a device can work without these properties.
Here is the code flow when either max_link_rate or max_lane_count is 0:
analogix_dp_commit()
-> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0)
analogix_dp_full_link_train(max_lanes, max_rate):
// Read sink capabilities via DPCD and sanitize them
link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup
lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup
// Clamp by the limits from DT
if (link_rate > max_rate) // 0x06 > 0, always true
link_rate = max_rate; // link_rate = 0
if (lane_count > max_lanes) // 1 > 0, always true
lane_count = max_lanes; // lane_count = 0
// Configure TX with the zeroed values
set_link_bandwidth(link_rate = 0)
// writel() is only executed for bwtype == 0x06/0x0a,
// so LINK_BW_SET is never written and stays at
// reset value; phy_configure() gets link_rate = 0.
set_lane_count(lane_count = 0)
// writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes;
// phy_configure() is called with lanes = 0.
// Program sink for link training
drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0})
// DP spec requires link rate in {0x06, 0x0a, 0x14} and
// lane count in {1, 2, 4}. Writing zeros is illegal, so
// the sink cannot enter the training state.
// Training loop
for (lane = 0; lane < lane_count /* 0 */; lane++)
// loop body never executes; training_lane[] stays
// uninitialized and no training register is programmed
Since the sanitized sink values are always non-zero (link_rate >= 0x06,
lane_count >= 1), the clamping with a zero maximum unconditionally
forces the training parameters to zero. Clock recovery can never be
achieved, so link training fails deterministically.
Consequently, making these properties mandatory again cannot break
any existing device: a DT without them could never have worked in
the first place. Failing probe early with a clear error message is
more helpful than a silent link training failure at runtime.
Fixes: 0d0abd894e ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288")
Cc: stable@vger.kernel.org
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Add a generic helper function drm_dp_lane_count_is_valid() to check
if a DisplayPort lane count is valid. According to the DP specification,
only 1, 2, or 4 lanes are supported.
This helper avoids duplicating DP lane count validation logic across
individual DisplayPort drivers.
Suggested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-3-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Add data-lanes property support to the port@1 endpoint for physical
lane mapping configuration.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Additionally, add data-lanes setting in Rockchip eDP DT node example
to show actual lane mapping usage.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-2-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm_crtc_init() creates the primary plane from a fixed format list
that includes ARGB8888. The display engine programs the primary plane
with DISPPLANE_32BPP_NO_ALPHA, so it does not support per-pixel alpha
and must not advertise alpha formats. Since commit 860e748bdd
("drm: ensure blend mode supported if pixel format with alpha exposed"),
drm_mode_config_validate() warns about this at probe time.
Replace drm_crtc_init() with a driver-owned primary plane that
advertises only XRGB8888. The plane is allocated by
drmm_universal_plane_alloc() and the "pixel blend mode" property is
not needed because no format with alpha is exposed.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patch.msgid.link/20260903071149.423579-1-oushixiong1025@163.com
Device names for i2c_device_id are not OF compatibles and have a meaning
only for in-tree users (which there are no except the driver itself),
thus vendor prefix in this name is completely redundant.
It is actually a discouraged pattern because for OF platforms it allows
matching driver by I2C bus, instead of OF, thus hiding incomplete
way of obtaining driver match data (lack of i2c_get_match_data() usage).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260825143921.512966-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
parse_hdmi_amd_vsdb() was removed when HDMI FreeSync detection moved to
the common EDID parser, but its declaration and KUnit tests remained,
breaking modpost:
ERROR: modpost: "parse_hdmi_amd_vsdb" [...connector_test.ko] undefined!
Remove the stale declaration and the three dead test cases.
Fixes: f65198b3d0 ("drm/amd/display: Use HDMI FreeSync range from common EDID parser")
Cc: Alex Huang <Alex.Huang2@amd.com>
Cc: Mario Limonciello <superm1@kernel.org>
Assisted-by: Copilot:Claude-Opus-5
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260820142802.1342066-2-rodrigo.vivi@intel.com
'ad->card' was removed in commit 9af2c1d4f8 ("ASoC: ti: omap-hdmi:
remove unused *card"), but commit 699e5975e2 ("drm/omap: Report HDMI
hotplug events to the ASoC HDMI codec") moved that code line. These
commits were applied to different trees, and the merge was not quite
right: assignment to 'ad->card' from the latter commit was left in the
file, causing:
sound/soc/ti/omap-hdmi.c:408:11: error: ‘struct hdmi_audio_data’ has no member named ‘card’
Fix the issue by removing the line.
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/all/apbbvQSfUbzYRFaw@sirena.org.uk/
Fixes: 1ae7fe832c ("Merge drm/drm-next into drm-misc-next")
Reviewed-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Link: https://patch.msgid.link/20260903-omap-hdmi-fix-v1-1-b0447a1d35d5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Backmerging to get drm-misc-next up to v7.3-rc2. Requested for
commit 3a2c4d55e3 ("treewide: refresh kmalloc_obj() conversions").
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
- Fix several tracefs files that did not take the trace_array reference
A trace instance can be created and destroyed in the tracefs "instances"
directory via mkdir and rmdir respectively. The instance is represented by
a trace_array descriptor. Most tracefs files pass the trace_array as the
private data of the inode to the open/read/write functions. Since there is
no locking between the time a task opens a file and the deletion of the
instance (and the freeing of the trace_array), each open needs to get a
reference to the trace_array and each close must remove it. A instance
can't be removed if there's any reference taken on its trace_array. The
open function uses trace_array_get() that takes a lock (preventing removal
of instances) and iterates the list of all existing trace_arrays and if it
finds a match, it takes the reference and releases the lock. If it doesn't
find a match, it causes the open to return -ENODEV.
There were some added files that did not take the trace_array reference
on open that needed to be fixed. Sashiko also correctly pointed out that
there were some files that took an address of an field or element of the
trace_array which had a pointer back to the trace_array to take its
reference on open. But this leaves a slight race between referencing this
element to get the trace_array as the element itself could be freed. To
solve this, some helper functions were created to look for trace_arrays
with this field or element in the search so that the element did not have
to be dereferenced before the trace_array's reference was taken.
- Add a lock around ftrace_ops initialization
When a ftrace_ops is first used by ftrace, some internal initialization is
performed on the ops. But if multiple tasks were calling functions that
did this initialization, it could race and perform doing the
initialization more than once, corrupting the internal data. Add a lock in
the initialization code to prevent this from happening.
- Fix splice reads on mmapped buffers
The logic in the ring buffer splice code for mmapped buffers is supposed
to do a copy of the memory as the mapped buffers can't be given to splice.
But there was an if statement within the copy code that would return a -1
if a request for a full page was done and it wasn't a partial read. This
is because this logic was written before mmapped buffers existed and this
case didn't make sense at the time. For mmapped buffers it makes perfect
sense and by returning early can drop a lot of pages unnecessarily.
- Have the persistent ring buffer validation check nr_subbufs
Sashiko reported that the validation code was relying on the saved
nr_subbufs to match the calculated nr_pages + 1 and if they were off, that
the code could cause corruption. Sashiko is correct, and the saved
nr_subbufs should be validated before assuming it is correct.
- Do not allow more than one instance with the same name on cmdline
If an admin were to add more than one trace instances with the same name
they all would be created, but only the first one would be accessible via
tracefs. This used to not be allowed but some restructuring of code has
since made it possible.
- Fix the race between subbuf resize and trace_pipe_raw readers
If a task was reading trace_pipe_raw while another task was changing the
ring buffer subbuf size, it could crash the reader. The trace_pipe_raw
readers do get their own copy of the page from the buffer, but the code
needs some restructuring to not have the resize of the subbuffers cause
issues.
- Cap the size of the mapped (static) ring buffer nr_pages
The meta data used for ring buffer mapped buffers is 32 bit in size. A
normal ring buffer could (in theory) have more than 4 billion pages.
But this is not allowed by mapped buffers, so enforce it.
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCap3GJRQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qtAfAP9hDPtzctAoz+IHZq+GYejhKTu99ICG
vAxTOZivuG6KYAD/UPA4P7z5ayxGM5UlT+2U81+mpCd55F2oFiIxRuFYcwk=
=/d+T
-----END PGP SIGNATURE-----
Merge tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix several tracefs files that did not take the trace_array reference
A trace instance can be created and destroyed in the tracefs
"instances" directory via mkdir and rmdir respectively. The instance
is represented by a trace_array descriptor.
Most tracefs files pass the trace_array as the private data of the
inode to the open/read/write functions. Since there is no locking
between the time a task opens a file and the deletion of the instance
(and the freeing of the trace_array), each open needs to get a
reference to the trace_array and each close must remove it.
An instance can't be removed if there's any reference taken on its
trace_array. The open function uses trace_array_get() that takes a
lock (preventing removal of instances) and iterates the list of all
existing trace_arrays and if it finds a match, it takes the reference
and releases the lock. If it doesn't find a match, it causes the open
to return -ENODEV.
There were some added files that did not take the trace_array
reference on open that needed to be fixed. Sashiko also correctly
pointed out that there were some files that took an address of an
field or element of the trace_array which had a pointer back to the
trace_array to take its reference on open. But this leaves a slight
race between referencing this element to get the trace_array as the
element itself could be freed. To solve this, some helper functions
were created to look for trace_arrays with this field or element in
the search so that the element did not have to be dereferenced before
the trace_array's reference was taken.
- Add a lock around ftrace_ops initialization
When a ftrace_ops is first used by ftrace, some internal
initialization is performed on the ops. But if multiple tasks were
calling functions that did this initialization, it could race and
perform doing the initialization more than once, corrupting the
internal data. Add a lock in the initialization code to prevent this
from happening.
- Fix splice reads on mmapped buffers
The logic in the ring buffer splice code for mmapped buffers is
supposed to do a copy of the memory as the mapped buffers can't be
given to splice. But there was an if statement within the copy code
that would return a -1 if a request for a full page was done and it
wasn't a partial read. This is because this logic was written before
mmapped buffers existed and this case didn't make sense at the time.
For mmapped buffers it makes perfect sense and by returning early can
drop a lot of pages unnecessarily.
- Have the persistent ring buffer validation check nr_subbufs
Sashiko reported that the validation code was relying on the saved
nr_subbufs to match the calculated nr_pages + 1 and if they were off,
that the code could cause corruption. Sashiko is correct, and the
saved nr_subbufs should be validated before assuming it is correct.
- Do not allow more than one instance with the same name on cmdline
If an admin were to add more than one trace instances with the same
name they all would be created, but only the first one would be
accessible via tracefs. This used to not be allowed but some
restructuring of code has since made it possible.
- Fix the race between subbuf resize and trace_pipe_raw readers
If a task was reading trace_pipe_raw while another task was changing
the ring buffer subbuf size, it could crash the reader. The
trace_pipe_raw readers do get their own copy of the page from the
buffer, but the code needs some restructuring to not have the resize
of the subbuffers cause issues.
- Cap the size of the mapped (static) ring buffer nr_pages
The meta data used for ring buffer mapped buffers is 32 bit in size.
A normal ring buffer could (in theory) have more than 4 billion
pages. But this is not allowed by mapped buffers, so enforce it.
* tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
ring-buffer: Use a macro for static buffer bits
tracing: Fix comment in tracing_buffers_splice_read()
ring-buffer: Prevent truncation of nr_pages / nr_subbufs
ring-buffer: Cap static ring buffer nr_pages
tracing: Fix subbuf resize races with trace_pipe_raw readers
tracing: Fix to avoid creating trace instances with duplicate names
ring-buffer: Add checking nr_subbufs to persistent ring buffer validation
ring-buffer: Allow splice reads on static buffers
tracing: Take trace_array reference when opening options file
ftrace: Synchronize the initialization of ftrace_ops
ftrace: Take trace_array reference before accessing its ftrace_ops
tracing: Have show_event_filters/triggers files take trace array ref
