Laurent Pinchart [Mon, 23 Mar 2026 16:45:26 +0000 (18:45 +0200)]
drm: rcar-du: Don't leak device_link to CMM
The DU driver creates device_link instances between the DU and CMMs, but
never deletes them. Fix it by introducing a rcar_du_cmm structure to
group the CMM device and device_link, and deleting the links at cleanup
time.
Laurent Pinchart [Mon, 23 Mar 2026 16:45:24 +0000 (18:45 +0200)]
drm: rcar-du: Store CMM device pointer instead of platform_device
The DU driver stores the CMM devices as pointers to struct
platform_device, and passes them to the API exposed by the CMM driver.
This is similar to how the VSP is handled, except that the VSP uses
struct device pointers. Replace the CMM platform_device pointers with
device pointers for consistency.
Laurent Pinchart [Mon, 23 Mar 2026 16:45:23 +0000 (18:45 +0200)]
drm: rcar-du: Ensure correct suspend/resume ordering with VSP
The VSP serves as an interface to memory and a compositor to the DU. It
therefore needs to be suspended after and resumed before the DU, to be
properly stopped and restarted in a controlled fashion driven by the DU
driver. This currently works by chance. Avoid relying on luck by
enforcing the correct suspend/resume ordering with device links.
Mithil Bavishi [Tue, 3 Mar 2026 20:30:13 +0000 (15:30 -0500)]
dt-bindings: display: panel-lvds: Add compatibles for Samsung LTN070NL01 and LTN101AL03 panels
The LTN070NL01 is a 7.0 inch 1024x600, 24 bit, VESA Compatible, TFT
display panel
The LTN101AL03 is a 10.1 inch 800x1280, 24 bit, VESA Compatible, TFT
display panel
The prepare timing specified by the G190EAN01 datasheet should be
between 30 and 50 ms. Considering it might take some time for the
LVDS encoder to enable the signal, we should only wait the min.
required time in the panel driver and not the max. allowed time.
Fixes: 2f7b832fc992 ("drm/panel: simple: Add support for AUO G190EAN01 panel") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Ian Ray <ian.ray@gehealthcare.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217142528.68613-1-ian.ray@gehealthcare.com
Val Packett [Tue, 17 Feb 2026 07:00:12 +0000 (04:00 -0300)]
drm/panel: himax-hx83102: Add support for DSI DCS backlight control
The HTF065H045 panel based on the HX83102 controller does use DCS
commands for controlling backlight brightness. Make the driver fall back
to DCS when no external backlight has been defined in the device tree,
like many other drivers do.
Val Packett [Tue, 17 Feb 2026 07:00:11 +0000 (04:00 -0300)]
drm/panel: himax-hx83102: Add support for Holitech HTF065H045
This 720x1600 panel is found in several Motorola/Lenovo smartphones like
the Moto G9 Play (guamp). The initialization sequence is based on the
datasheet. Add it to the existing HX83102 panel driver.
Dmitry Baryshkov [Mon, 23 Mar 2026 01:21:49 +0000 (03:21 +0200)]
drm/panel: sharp-ls043t1le01: make use of prepare_prev_first
The DSI link must be powered up to let panel driver to talk to the panel
during prepare() callback execution. Set the prepare_prev_first flag to
guarantee this.
Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260323-panel-fix-v1-1-9f12b09161e8@oss.qualcomm.com
dt-bindings: display: panel: Align style of "true" properties
For code readability, several bindings which list allowed properties
with ": true" syntax group them in one place, without line breaks
between each. Align a few bindings to match this style. No functional
impact.
Add support for the Rocktech RK050HR345-CT106A panel based on the
Ilitek ILI9806E controller using the SPI bus.
The driver is designed to be easily extensible to support other panels
with different initialization sequences and display timings by
providing a specific descriptor structure for each model.
Dario Binacchi [Wed, 18 Mar 2026 07:32:51 +0000 (08:32 +0100)]
drm/panel: ilitek-ili9806e: split core and DSI logic
Split the driver to support multiple transport buses. The core logic
(power, GPIO, backlight) is moved to a dedicated core module, while
DSI-specific code is restricted to the DSI module.
Introduce DRM_PANEL_ILITEK_ILI9806E_CORE as a hidden Kconfig symbol
selected by the bus-specific configuration.
Dario Binacchi [Wed, 18 Mar 2026 07:32:50 +0000 (08:32 +0100)]
drm/panel: ilitek-ili9806e: rename to specific DSI driver
The Ilitek ILI9806E controller can support different transport buses,
such as MIPI-DSI and SPI. The current implementation is specific to
the MIPI-DSI interface.
In preparation for adding SPI support, rename the current Kconfig
symbol and files to be DSI-specific, clarifying the current scope
of the code.
Since DRM_PANEL_ILITEK_ILI9806E is not used in any in-tree defconfig,
the symbol is renamed directly to DRM_PANEL_ILITEK_ILI9806E_DSI without
providing a legacy compatibility alias.
Pengyu Luo [Mon, 16 Mar 2026 08:40:40 +0000 (16:40 +0800)]
drm/panel: Add Himax HX83121A panel driver
Add a driver for panels using the Himax HX83121A Display Driver IC,
including support for the BOE/CSOT PPC357DB1-4, found in HUAWEI
Matebook E Go series (Gaokun2/3).
Chen-Yu Tsai [Tue, 17 Mar 2026 04:00:32 +0000 (12:00 +0800)]
drm/gem-dma: set VM_DONTDUMP for mmap
When the mmap function was converted from a file op to a GEM object
function in commit f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM
CMA object functions") some VM flags were not lifted from drm_gem_mmap():
- VM_IO
- VM_DONTEXPAND
- VM_DONTDUMP
VM_DONTEXPAND was added back in commit 59f39bfa6553 ("drm/cma-helper:
Set VM_DONTEXPAND for mmap"). VM_IO doesn't make sense since these are
memory buffers, while "IO tells people not to look at these pages
(accesses can have side effects)".
Add back VM_DONTDUMP. This matches the behavior of most other GEM
implementations.
Max Zhen [Tue, 24 Mar 2026 16:31:59 +0000 (09:31 -0700)]
accel/amdxdna: Add per-process BO memory usage query support
Add support for querying per-process buffer object (BO) memory
usage through the amdxdna GET_ARRAY UAPI.
Introduce a new query type, DRM_AMDXDNA_BO_USAGE, along with
struct amdxdna_drm_bo_usage to report BO memory usage statistics,
including heap, total, and internal usage.
Track BO memory usage on a per-client basis by maintaining counters
in GEM open/close and heap allocation/free paths. This ensures the
reported statistics reflect the current memory footprint of each
process.
Wire the new query into the GET_ARRAY implementation to expose
the usage information to userspace.
Deprecate simple-encoder and simple-display-pipe helpers in favor of
regular atomic helpers. Remove the related documentation. Add TODO
item for converting the remaining drivers.
These helpers have been deprecated for years and many drivers have
been updated to not use them. Still there are a few left and we
occasionally receive new drivers build upon them. Marking them as
deprecated will hopefully resolve these problems. The TODO items
should be easy enough for getting new voluteers started on DRM driver
development.
drm/st7735r: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct st7735r_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. St7735r requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/st7586: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct st7586_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. St7586 requires custom helpers for
various pipeline elements, and non-freeing cleanup of the pipeline.
v3:
- return early in st7586_plane_helper_atomic_update (David)
v2:
- fix connector initialization
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-12-tzimmermann@suse.de
drm/panel-mipi-dbi: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct panel_mipi_dbi_device and initialize them as
part of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Panel-mipi-dbi requires a custom helper
for CRTC enablement, and non-freeing cleanup of the pipeline.
v2:
- fix connector initialization
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-11-tzimmermann@suse.de
drm/mi0283qt: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct mi0283qt_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Mi0283qt requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9486: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9486_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9486 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9341: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9341_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9341 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9225: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9225_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9225 requires custom helpers for
various pipeline elements, and non-freeing cleanup of the pipeline.
drm/ili9163: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9163_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9163 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/hx8357d: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct hx8357d_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Hx8357d requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/mipi-dbi: Provide callbacks for atomic interfaces
Refactor the existing simple-display callbacks such that they invoke
helpers compatible with regular atomic modesetting. Allows for adding
mipi-dbi drives that do not require simple-display helpers.
Provide initializer macro for elements of the regular modesetting
pipeline. These will be used by drivers to integrate mipi-dbi helpers.
Also provide initializer macros for the plane formats.
As the new helpers are DRM functions, add the drm_ prefix. Mipi-dbi
interfaces currently lack this.
v3:
- fix uninitialized variable (David)
- document public interfaces (David)
- mention format macros in commit message (David)
drm/mipi-dbi: Support custom pipelines with drm_mipi_dbi_dev_init()
Initialize the mipi-dbi device with drm_mipi_dbi_dev_init() without
creating a modesetting pipeline. Will allow for mipi-dbi drivers
without simple-display helpers.
As the new helper is a DRM function, add the drm_ prefix. Mipi-dbi
interfaces currently lack this.
Use drm_atomic_helper_commit_tail_rpm() as commit tail to update the
plane after enabling the CRTC. Then remove the plane-update code from
mipi_dbi_enable_flush() and inline the remaining backlight code where
necessary.
Mipi-dbi's current commit tail drm_atomic_helper_commit_tail() first
updates the plane and then enables the CRTC. But the CRTC enablement
includes power management that prevents the initial plane update from
working. Hence, each mipi-dbi driver includes a plane update in their
CRTC enablement; in the form of mipi_dbi_enable_flush() or custom code.
Using drm_atomic_helper_commit_tail_rpm() enables the CRTC before any
plane updates. Hence the additional plane update can be removed from
mipi_dbi_enable_flush() and a number of drivers.
This leaves backlight_enable() in the helper, which can now be inlined
into affected drivers. Drivers now enable the CRTC plus an optional
backlight and then automatically update the plane.
In the case of disabling the display, drm_atomic_helper_commit_tail_rpm()
only disables the CRTC without touching the plane at all. Mipi-dbi's
mipi_dbi_pipe_disable() already contains the necessary logic.
Removing the plane update from the CRTC enablement will also help with
converting mipi-dbi from simple-pipe helpers to regular atomic helpers.
Damon Ding [Mon, 10 Nov 2025 08:58:23 +0000 (16:58 +0800)]
drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages and pre-emphasises
Replace analogix_dp_get_adjust_request_voltage() and
analogix_dp_get_adjust_request_pre_emphasis() with existing DP helper
APIs with the same function.
Damon Ding [Tue, 11 Nov 2025 02:21:03 +0000 (10:21 +0800)]
drm/bridge: analogix_dp: Reuse &link_train.training_lane[] to set DPCD DP_TRAINING_LANEx_SET
In analogix_dp_link_start(), &link_train.training_lane[] is used to
set phy PE/VS configurations, and buf[] is initialized with the same
values to set DPCD DP_TRAINING_LANEx_SET.
It makes sense to reuse &link_train.training_lane[] to set DPCD
DP_TRAINING_LANEx_SET, which can remove the redundant assignments
and make codes more concise.
Cunyuan Liu [Fri, 13 Mar 2026 03:31:19 +0000 (11:31 +0800)]
drm/komeda: Add support for Arm China Linlon-D6
Arm China Linlon-D6 is register-compatible with the Mali-D71 display
pipeline for the purpose of basic modesetting.
On Linlon-D6, the PRODUCT_ID register is located at the same offset as on
Mali-D71 and reports 0x0060. The IP also exposes the same Komeda top-level
block layout expected by the existing d71_identify() probing flow, so we
can reuse the D71 function table to bring up the display engine.
Marcin Slusarz [Tue, 24 Mar 2026 13:25:57 +0000 (14:25 +0100)]
drm/panthor: extend timestamp query with flags
Flags now control which data user space wants to query,
there is more information sources, and there's ability
to query duration of multiple timestamp reads.
Julian Braha [Mon, 23 Mar 2026 12:41:18 +0000 (12:41 +0000)]
drm: fix dead default for DRM_TTM_KUNIT_TEST
The DRM_TTM_KUNIT_TEST config option should default
to KUNIT_ALL_TESTS so that if all tests are enabled then
it is included, but currently the 'default KUNIT_ALL_TESTS'
statement is shadowed by an unconditional 'default n',
meaning that this second default statement is currently dead code.
This dead code was found by kconfirm, a static analysis
tool for Kconfig.
Maxime Ripard [Thu, 5 Mar 2026 09:05:06 +0000 (10:05 +0100)]
drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace
The hdmi_colorspace enum was defined to represent the colorspace value
of the HDMI infoframes. It was later used by some HDMI drivers to
express the output format they should be setting up.
During the introduction of the HDMI helpers, it then was used to
represent it in the drm_connector_hdmi_state structure.
However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_*
defines, and now with the drm_output_color_format enum. Let's
consolidate around drm_output_color_format in drm_connector_hdmi_state
to facilitate the current effort to provide a global output format
selection mechanism.
Maxime Ripard [Thu, 5 Mar 2026 09:05:04 +0000 (10:05 +0100)]
drm/rockchip: analogix: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:03 +0000 (10:05 +0100)]
drm/mediatek: dp: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:02 +0000 (10:05 +0100)]
drm/arm: komeda: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:01 +0000 (10:05 +0100)]
drm/bridge: synopsys: dw-hdmi: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:00 +0000 (10:05 +0100)]
drm/bridge: synopsys: dw-dp: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:59 +0000 (10:04 +0100)]
drm/bridge: cadence: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:58 +0000 (10:04 +0100)]
drm/bridge: analogix: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:57 +0000 (10:04 +0100)]
drm/bridge: adv7511: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:56 +0000 (10:04 +0100)]
drm/amdgpu: display: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:55 +0000 (10:04 +0100)]
drm/display: hdmi: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:54 +0000 (10:04 +0100)]
drm/edid: Convert to drm_output_color_format enum
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
The EDID parsing code initially introduced the DRM_COLOR_FORMAT_*
defines to represent the sink capabilities. Since a given sink could
support multiple formats, it was first defined as a bitmask.
However, the core and drivers have since leveraged those defines to
represent both the supported formats but also the current format being
used.
Considering the latter case, the more natural, and consistent, thing to
do would be to create an enum of all the possible formats, and then list
the supported formats using a bitmask of the individual enum values.
Let's create a new enum following that pattern, drm_output_color_format,
while maintaining the DRM_COLOR_FORMAT_* compatibility to make the
transition easier.
Alexandru Dadu [Mon, 23 Mar 2026 18:31:30 +0000 (20:31 +0200)]
drm/imagination: Implement handling of context reset notification
The firmware will send the context reset notification message as
part of handling hardware recovery (HWR) events deecoding the message
and printing via drm_info(). This eliminates the "Unknown FWCCB command"
message that was previously printed.
Alexandru Dadu [Mon, 23 Mar 2026 18:31:29 +0000 (20:31 +0200)]
drm/imagination: Switch reset_reason fields from enum to u32
Update the reset_reason fwif structure fields from enum to u32 to remove
any ambiguity from the interface (enum is not a fixed size thus is unfit
for the purpose of the data type).
Raag Jadav [Thu, 5 Mar 2026 13:06:49 +0000 (18:36 +0530)]
drm/xe: Send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET
XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET is intended for debugging hangs,
so wedge the device with 'none' recovery method and have it available
to the user for debugging.
Raag Jadav [Thu, 5 Mar 2026 13:06:47 +0000 (18:36 +0530)]
drm/doc: Update documentation for 'none' recovery method
Expand 'none' recovery method for wedged event to include debug cases
where driver wants to hint "no recovery" without resetting the device
from driver context.
Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305130720.3685754-2-raag.jadav@intel.com
Wendy Liang [Mon, 23 Mar 2026 17:37:19 +0000 (10:37 -0700)]
accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure
dma_alloc_noncoherent() returns NULL on failure, but callers of
aie2_alloc_msg_buffer() check for IS_ERR(). Return ERR_PTR(-ENOMEM)
instead of NULL to match the amdxdna_iommu_alloc() path and the
caller's error checking convention.
Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Signed-off-by: Wendy Liang <wendy.liang@amd.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260323173719.2311474-1-lizhi.hou@amd.com
Brajesh Gupta [Fri, 13 Mar 2026 06:38:24 +0000 (06:38 +0000)]
drm/imagination: Improve firmware power off for layout_mars config
In layout_mars HW config, Firmware MCU moved from Sidekick to new Mars
domain so Firmware takes care of powering down Sidekick/Jones and SLC.
Skip checks for those from kernel and check idle bits for Firmware MCU
and system arbiter excluding SOCIF.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:28 +0000 (17:49 +0800)]
drm/sun4i: Use backend/mixer as dedicated DMA device
The sun4i DRM driver deals with DMA constraints in a peculiar way.
Instead of using the actual DMA device in various helpers, it justs
reconfigures the DMA constraints of the virtual display device using
the DMA device's device tree node by calling of_dma_configure().
Turns out of_dma_configure() should only be called from bus code.
Lately this also triggers a big warning through of_iommu_configure()
and ultimately __iommu_probe_device():
late IOMMU probe at driver bind, something fishy here!
Now that the GEM DMA helpers have proper support for allocating
and mapping buffers with a dedicated DMA device, switch over to
it as the proper solution.
The mixer change was tested on a Pine H64 model B. The backend change
was only compile tested. Though I don't expect any issues, help testing
on an older device would be appreciated.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:27 +0000 (17:49 +0800)]
drm/mediatek: Set dedicated DMA device and drop custom GEM callbacks
In commit 9b54a32c7c6a ("drm/mediatek: mtk_gem: Partial refactor and
use drm_gem_dma_object") the MediaTek DRM driver was refactored to use
drm_gem_dma_object, but custom callbacks were still needed to deal with
using the first device of the pipeline as the DMA device, instead of
the MMSYS device that the DRM driver binds to.
Turns out there is already partial support for dedicated DMA devices in
the DRM subsystem for PRIME imports. The preceding patches add support
for dedicated DMA devices to the GEM DMA helpers.
This allows us to just set the dedicated DMA device for the DRM device,
and drop all the custom GEM callbacks. Also drop the .dma_dev field
from the driver private data as it is no longer needed.
There are slight differences in the mmap helper: the VM_DONTDUMP and
VM_IO flags are no longer set. Both were lifted from drm_gem_mmap_obj().
VM_IO probably doesn't make sense since the buffer is allocated using
dma_alloc_attrs().
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260311094929.3393338-4-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:26 +0000 (17:49 +0800)]
drm/gem-dma: Support dedicated DMA device for allocation and mapping
Support for a dedicated DMA device for prime imports was added in commit 143ec8d3f939 ("drm/prime: Support dedicated DMA device for dma-buf imports").
This allowed the DRM driver to provide a dedicated DMA device when its
own underlying device was not capable of DMA, for example when it is a
USB device (the original target) or a virtual device. The latter case is
common on embedded SoCs, on which the display pipeline is composed of
various fixed function blocks, and the DRM device is simply a made-up
device, an address space managing the routing between the blocks, or
whichever block the implementor thought made sense at the time. The
point is that the chosen device is often not the actual device doing
the DMA. Various drivers have used workarounds or reimplemented the
GEM DMA helpers to get the DMA addresses and IOMMUs to work correctly.
Add support for the dedicated DMA device to the GEM DMA helpers.
No existing driver currently uses the GEM DMA helpers and calls
drm_dev_set_dma_dev() to set a dedicated DMA device, so no existing
users should be affected.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:25 +0000 (17:49 +0800)]
drm/prime: Limit scatter list size with dedicated DMA device
If a dedicated DMA device is specified for the DRM device, then the
scatter list size limit should pertain to the DMA device.
Use the dedicated DMA device, if given, to limit the scatter list size.
This only applies to drivers that have called drm_dev_set_dma_dev() and
are using drm_prime_pages_to_sg() either directly or through the SHMEM
helpers. At the time of this writing, the former case only includes the
Rockchip DRM driver, while the latter case includes the gud, udl, and
the tiny appletbdrm and gm12u320 drivers.
Max Zhen [Fri, 20 Mar 2026 21:06:14 +0000 (14:06 -0700)]
accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval
Refactor amdxdna GEM buffer object (BO) handling to simplify address
management and unify BO type semantics.
Introduce helper APIs to retrieve commonly used BO addresses:
- User virtual address (UVA)
- Kernel virtual address (KVA)
- Device address (IOVA/PA)
These helpers centralize address lookup logic and avoid duplicating
BO-specific handling across submission and execution paths. This also
improves readability and reduces the risk of inconsistent address
handling in future changes.
As part of the refactor:
- Rename SHMEM BO type to SHARE to better reflect its usage.
- Merge CMD BO handling into SHARE, removing special-case logic for
command buffers.
- Consolidate BO type handling paths to reduce code duplication and
simplify maintenance.
No functional change is intended. The refactor prepares the driver for
future enhancements by providing a cleaner abstraction for BO address
management.
Luca Ceresoli [Tue, 10 Mar 2026 12:13:23 +0000 (13:13 +0100)]
drm/bridge: add drm_bridge_clear_and_put()
Drivers having a struct drm_bridge pointer pointing to a bridge in many
cases hold that reference until the owning device is removed. In those
cases the reference to the bridge can be put in the .remove callback
(possibly using devm actions) or in the .destroy func (possibly with the
help of struct drm_bridge::next_bridge). At those moments the driver should
not be operating anymore and won't dereference the bridge pointer after it
is put.
However there are cases when drivers need to stop holding a reference to a
bridge even when their device is not being removed. This is the case for
bridge hot-unplug, when a bridge is removed but the previous entity (bridge
or encoder) is staying. In such case the "previous entity" needs to put it
but cannot do it via devm or .destroy, because it is not being removed.
However this is risky because there is a time window between the two lines
where the reference is put, and thus the bridge could be deallocated, but
the pointer is still assigned. If other functions of the same driver were
invoked concurrently they might dereference my_priv->some_bridge during
that window, resulting in use-after-free.
A correct solution is to clear the pointer before putting the reference,
but that needs a temporary variable:
Thomas Hellström [Tue, 17 Mar 2026 14:18:55 +0000 (15:18 +0100)]
drm/ttm: Avoid invoking the OOM killer when reading back swapped content
In situations where the system is very short on RAM, the shmem
readback from swap-space may invoke the OOM killer.
However, since this might be a recoverable situation where the caller
is indicating this by setting
struct ttm_operation_ctx::gfp_retry_mayfail to true, adjust the gfp
value used by the allocation accordingly.
Thomas Hellström [Tue, 17 Mar 2026 14:18:54 +0000 (15:18 +0100)]
drm/ttm: Don't spam the log on buffer object backing store allocation failure
If the struct ttm_operation_ctx::gfp_retry_mayfail is true,
buffer object backing store allocation failures are expected to
silently fail with an error code to the caller. But currently an
elaborate warning is printed to the system log.
Maxime Ripard [Tue, 24 Feb 2026 16:10:29 +0000 (17:10 +0100)]
drm/atomic: Remove state argument to drm_atomic_private_obj_init
Now that all drm_private_objs users have been converted to use
atomic_create_state instead of the old ad-hoc initialization, we can
remove the state parameter from drm_private_obj_init and the fallback
code.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-4-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Tue, 24 Feb 2026 16:10:28 +0000 (17:10 +0100)]
drm/tegra: Switch private_obj initialization to atomic_create_state
The tegra driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Maxime Ripard [Tue, 24 Feb 2026 16:10:27 +0000 (17:10 +0100)]
drm/omapdrm: Switch private_obj initialization to atomic_create_state
The omapdrm driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Maxime Ripard [Tue, 24 Feb 2026 16:10:26 +0000 (17:10 +0100)]
drm/amdgpu: Switch private_obj initialization to atomic_create_state
The amdgpu driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Karol Wachowski [Wed, 18 Mar 2026 09:39:27 +0000 (10:39 +0100)]
accel/ivpu: Perform engine reset instead of device recovery on TDR
Replace full device recovery on TDR timeout with per-context abort,
allowing individual context handling instead of resetting the entire
device.
Extend ivpu_jsm_reset_engine() to return the list of contexts impacted
by the engine reset and use that information to abort only the affected
contexts.
Only check for potentially faulty contexts when the engine reset was not
triggered by an MMU fault or a job completion error status. This prevents
misidentifying non-guilty contexts that happened to be running at the
time of the fault.
Trigger full device recovery if no contexts were marked by engine reset
if triggered by job completion timeout, as there is no way to identify
guilty one.
Add engine reset counter to debugfs for engine resets bookkeeping
for debugging/testing purposes.
projects / thirdparty / kernel / stable.git / log
