linux-2.6-microblaze.git
4 months agodrm/i915/casf: Remove redundant argument from intel_casf_filter_lut_load()
Ville Syrjälä [Tue, 7 Apr 2026 17:52:41 +0000 (20:52 +0300)]
drm/i915/casf: Remove redundant argument from intel_casf_filter_lut_load()

intel_casf_filter_lut_load() can find the crtc from the crtc_state.
No need to pass in both.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-8-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: Constify crtc_state
Ville Syrjälä [Tue, 7 Apr 2026 17:52:40 +0000 (20:52 +0300)]
drm/i915/casf: Constify crtc_state

Make the crtc_state const everywhere in the sharpness filter
code where it doesn't need to be mutated.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-7-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: Handle CASF in skl_scaler_get_filter_select()
Ville Syrjälä [Tue, 7 Apr 2026 17:52:39 +0000 (20:52 +0300)]
drm/i915/casf: Handle CASF in skl_scaler_get_filter_select()

Nuke the duplicate CASF_SCALER_FILTER_SELECT and just have
skl_scaler_get_filter_select() return the proper value for
sharpness filter use. It is the same "use programmable coefficients"
value we already use for the nearest neighbor filtering.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-6-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: Extract scaler_has_casf()
Ville Syrjälä [Tue, 7 Apr 2026 17:52:38 +0000 (20:52 +0300)]
drm/i915/casf: Extract scaler_has_casf()

Extract a small helper to determine if the scaler supports
the sharpness filter or not.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-5-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: Move the casf state to better place
Ville Syrjälä [Tue, 7 Apr 2026 17:52:37 +0000 (20:52 +0300)]
drm/i915/casf: Move the casf state to better place

The casf state is placed inside the 'hw' state for some reason.
That is only really meant for things we have to duplicate from
the uapi state. The rest can live on its own in our actual state.

And since casf is just one aspect of the pfit/pipe scaler the
proper place for it seems to be under pch_pfit.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-4-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: Make a proper hw state copy of the sharpness_strength
Ville Syrjälä [Tue, 7 Apr 2026 17:52:36 +0000 (20:52 +0300)]
drm/i915/casf: Make a proper hw state copy of the sharpness_strength

Make a copy of the uapi.sharpness_strength property value in our hw
state. This is how we deal with having proper state for joined pipes.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-3-ville.syrjala@linux.intel.com
4 months agodrm/i915/casf: s/casf_enable/enable/
Ville Syrjälä [Tue, 7 Apr 2026 17:52:35 +0000 (20:52 +0300)]
drm/i915/casf: s/casf_enable/enable/

The 'casf_enable' boolean is already inside a casf specific
structure, so drop the extra 'casf_' namespace from the bool.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-2-ville.syrjala@linux.intel.com
4 months agodrm/i915/pci: move intel_pci_config.h under include/drm/intel
Jani Nikula [Tue, 7 Apr 2026 19:36:30 +0000 (22:36 +0300)]
drm/i915/pci: move intel_pci_config.h under include/drm/intel

Since the PCI registers are used from both i915 display and core, move
intel_pci_config.h to include/drm/intel/pci_config.h. Drop the intel_
prefix from the name to reduce tautology.

With this, we can drop the corresponding xe display compat header.

v2: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/5aac6c711c3f0a09fc52f322455a4a4b35f80a82.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915: drop unnecessary intel_pci_config.h include
Jani Nikula [Tue, 7 Apr 2026 19:36:29 +0000 (22:36 +0300)]
drm/i915: drop unnecessary intel_pci_config.h include

There's an unnecessary include. Drop it.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/8323c99f379809b2973c99ebe54c21fd274d246c.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/mchbar: move intel_mchbar_regs.h under include/drm/intel
Jani Nikula [Tue, 7 Apr 2026 19:36:28 +0000 (22:36 +0300)]
drm/i915/mchbar: move intel_mchbar_regs.h under include/drm/intel

Since the mchbar registers are used from both i915 display and core,
move intel_mchbar_regs.h to include/drm/intel/mchbar_regs.h. Drop the
intel_ prefix from the name to reduce tautology.

With this, we can drop the corresponding xe display compat header.

v2: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/6c951b2c05db74ea517d52a3912986f7eb886422.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/mchbar: drop unnecessary intel_mchbar_regs.h include
Jani Nikula [Tue, 7 Apr 2026 19:36:27 +0000 (22:36 +0300)]
drm/i915/mchbar: drop unnecessary intel_mchbar_regs.h include

There are some unnecessary includes. Remove.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/7eaf98e648240e3011bfb85d0330787074c39205.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/mchbar: include intel_mchbar_regs.h from intel_mchbar.h
Jani Nikula [Tue, 7 Apr 2026 19:36:26 +0000 (22:36 +0300)]
drm/i915/mchbar: include intel_mchbar_regs.h from intel_mchbar.h

As an exception to the rule of not including unnecessary headers from
headers, include intel_mchbar_regs.h from intel_mchbar.h. In order to
use the interfaces in intel_mchbar.h you will always have to include the
registers anyway, so the includes are in pairs everywhere. There is zero
asymmetry. Simplify.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/e44dc2daf3fc39d02c3f598c323caa3c08a54304.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/backlight: Fix VESA backlight possible check condition
Suraj Kandpal [Tue, 7 Apr 2026 03:07:11 +0000 (08:37 +0530)]
drm/i915/backlight: Fix VESA backlight possible check condition

VESA backlight enable is possible when
BACKLIGHT_AUX_ENABLE_CAPABLE is true via AUX command or when
BACKLIGHT_PIN_ENABLE_CAPABLE is true via eDP connector pin.
Similarly, backlight brightness adjustment can be
done via AUX-based control or PWM pin-based control.
It means there can be three configurations:
1) Full AUX-based: Enable and adjustment both via AUX. We currently
   support this (apart from the AUX luminance-based backlight control).
2) Hybrid: Enable via the BL_ENABLE pin, adjustment via either AUX or
   PWM.
3) Fully PWM pin-based: Enable via the BL_ENABLE pin, adjustment via
   PWM.
Since that only 1 is supported as of now we need to make
sure we do not try to manipulate backlight when
BACKLIGHT_AUX_ENABLE_CAPABLE is not set.
Also fix return value when condition is not fulfilled.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15907
Fixes: 0fb03890d182 ("drm/i915/backlight: Check if VESA backlight is possible")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260407030710.1440046-1-suraj.kandpal@intel.com
4 months agodrm/i915/pin: switch to i915 core runtime pm
Jani Nikula [Tue, 7 Apr 2026 10:04:37 +0000 (13:04 +0300)]
drm/i915/pin: switch to i915 core runtime pm

Remove a dependency on struct intel_display from i915 core code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c06366c1c6f9202be5d0b6ea649c20aba414e5bc.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/pin: s/dev_priv/i915/ and drop struct drm_device usage
Jani Nikula [Tue, 7 Apr 2026 10:04:36 +0000 (13:04 +0300)]
drm/i915/pin: s/dev_priv/i915/ and drop struct drm_device usage

Improve consistency within i915_fb_pin.c by replacing dev_priv naming
with i915, and dropping struct drm_device usage.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/3a4ac0a732a561a487e46838bde6327cff5ccb38.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915: move intel_fb_pin.c to i915_fb_pin.c
Jani Nikula [Tue, 7 Apr 2026 10:04:35 +0000 (13:04 +0300)]
drm/i915: move intel_fb_pin.c to i915_fb_pin.c

intel_fb_pin.c is the final file in display/ that's specific to i915
only. Move it to i915 core, renaming it to i915_fb_pin.c. It'll still
depend on a lot of display stuff, unfortunately.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/ab1ffc08bcd1364715396142f91780b6261bbe65.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/pfit: Prevent negative coordinates in center mode
Nemesa Garg [Thu, 2 Apr 2026 06:13:10 +0000 (11:43 +0530)]
drm/i915/pfit: Prevent negative coordinates in center mode

When the pipe_src width or height are greater than adjusted_mode hdisplay
and vdisplay, computed x and y offsets for center mode can be negative.
Writing negative values into the pch_fit registers result in a state error.
Add a check to clamp these values so that they are never negative.

v2: Compare in terms of pipe_src width and height.[Ville]
v3: Change width/height to pipe_src_w/h in logging. [Ville]

Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260402061310.111073-1-nemesa.garg@intel.com
4 months agodrm/i915/display: Panel Replay BW optimization for DP2.0 tunneling
Animesh Manna [Mon, 30 Mar 2026 13:36:20 +0000 (19:06 +0530)]
drm/i915/display: Panel Replay BW optimization for DP2.0 tunneling

Unused bandwidth can be used by external display agents for Panel Replay
enabled DP panel during idleness with link on. Enable source to replace
dummy data from the display with data from another agent by programming
TRANS_DP2_CTL [Panel Replay Tunneling Enable].

v2:
- Enable pr bw optimization along with panel replay enable. [Jani]

v3:
- Write TRANS_DP2_CTL once for both bw optimization and panel replay
enable. [Jani]

v4:
- Read DPCD once in init() and store in panel_replay_caps. [Jouni]

v5:
- Avoid reading DPCD for edp. [Jouni]
- Use drm_dp_dpcd_read_byte() and some cosmetic changes. [Jani]

v6:
- Extend the corresponding interface defined in drm_dp_tunnel.c
to query the Panel Replay optimization capability. [Imre]

v7:
- Clear TRANS_DP2_PR_TUNNELING_ENABLE if pr bw optimization
is not allowed. [Jouni]
- Move intel_dp_is_edp() check. [Jouni]

Bspec: 68920
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260330133620.3750559-4-animesh.manna@intel.com
4 months agodrm/i915/display: Add hook to check optimization support for Intel platforms
Animesh Manna [Mon, 30 Mar 2026 13:36:19 +0000 (19:06 +0530)]
drm/i915/display: Add hook to check optimization support for Intel platforms

Add a hook that uses the drm core tunneling function to check
whether panel replay bandwidth optimization support is present.

v2: Move DISPLAY_VER() check to
intel_dp_tunnel_pr_optimization_supported(). [Jouni]

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260330133620.3750559-3-animesh.manna@intel.com
4 months agodrm/display: Add drm helper to check pr optimization support
Animesh Manna [Mon, 30 Mar 2026 13:36:18 +0000 (19:06 +0530)]
drm/display: Add drm helper to check pr optimization support

Add api to check panel replay optimization supported or not to
drm-core DP tunneling framework which can be used by other driver
as well.

v2: Split generic drm changes from Intel specific changes. [Jouni]

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Suggested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Acked-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260330133620.3750559-2-animesh.manna@intel.com
4 months agodrm/xe: pass struct xe_device to xe_display_bo_fbdev_prefer_stolen()
Jani Nikula [Tue, 31 Mar 2026 09:49:18 +0000 (12:49 +0300)]
drm/xe: pass struct xe_device to xe_display_bo_fbdev_prefer_stolen()

This is xe core code, use struct xe_device for simplicity.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/56bd532dc5cf460cdbf17c7781f18db5378a28e6.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915: pass struct drm_i915_private to i915_bo_fbdev_prefer_stolen()
Jani Nikula [Tue, 31 Mar 2026 09:49:17 +0000 (12:49 +0300)]
drm/i915: pass struct drm_i915_private to i915_bo_fbdev_prefer_stolen()

This is i915 core code, use struct drm_i915_private for simplicity.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/321edddfd7509fd2cff0303747cdf18bb0cb911d.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/{i915, xe}: move fbdev fb calls to parent interface
Jani Nikula [Tue, 31 Mar 2026 09:49:16 +0000 (12:49 +0300)]
drm/{i915, xe}: move fbdev fb calls to parent interface

Move the driver specific fbdev fb calls to the display parent
interface. Reuse the existing struct intel_display_bo_interface, as this
is mostly about gem objects.

Put everything behind IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) to catch
configuration issues at build or link time.

v2: Rebase

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Link: https://patch.msgid.link/a6bb24909a58181cfc41b91a4c6538a181d27158.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/{i915, xe}/fbdev: drop drm device parameter from intel_fbdev_fb_fill_info()
Jani Nikula [Tue, 31 Mar 2026 09:49:15 +0000 (12:49 +0300)]
drm/{i915, xe}/fbdev: drop drm device parameter from intel_fbdev_fb_fill_info()

The struct drm_device *drm parameter of intel_fbdev_fb_fill_info() is
redundant, as you can obtain the same information via obj->dev. Drop the
drm parameter, and move obj as first (or the context) parameter.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/6c617dc41c07b0e3e9af01b82d0d1dadbd4760fc.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/xe/fbdev: put intel_fbdev_fb_prefer_stolen() behind IS_ENABLED(CONFIG_DRM_FBDEV_E...
Jani Nikula [Tue, 31 Mar 2026 09:49:14 +0000 (12:49 +0300)]
drm/xe/fbdev: put intel_fbdev_fb_prefer_stolen() behind IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)

Unify the behaviour with i915. Similar to commit b63c6b9b7f5e
("drm/i915/fbdev: fix link failure without FBDEV emulation"). The
difference is that unlike i915, xe doesn't build
display/intel_fbdev_fb.c conditional to CONFIG_DRM_FBDEV_EMULATION.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/245880a591fe5267a1c06bfbbcc42a4dd9f2e4ee.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/psr: Do not use pipe_src as borders for SU area
Jouni Högander [Fri, 27 Mar 2026 11:45:53 +0000 (13:45 +0200)]
drm/i915/psr: Do not use pipe_src as borders for SU area

This far using crtc_state->pipe_src as borders for Selective Update area
haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) ==
crtc_state->hw.adjusted_mode.crtc_hdisplay and
drm_rect_height(crtc_state->pipe_src) ==
crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not
used. On the other hand using pipe scaling is forcing full frame updates and all the
Selective Update area calculations are skipped. Now this improper usage of
crtc_state->pipe_src is causing following warnings:

<4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height)

after WARN_ON_ONCE was added by commit:

"drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters"

These warnings are seen when DSC and pipe scaling are enabled
simultaneously. This is because on full frame update SU area is improperly
set as pipe_src which is not aligned with DSC slice height.

Fix these by creating local rectangle using
crtc_state->hw.adjusted_mode.crtc_hdisplay and
crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as
borders for SU area.

Fixes: d6774b8c3c58 ("drm/i915: Ensure damage clip area is within pipe area")
Cc: <stable@vger.kernel.org> # v6.0+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com
4 months agodrm/i915/rom: Use intel_de for SPI ROM register access
Ville Syrjälä [Tue, 31 Mar 2026 15:42:59 +0000 (18:42 +0300)]
drm/i915/rom: Use intel_de for SPI ROM register access

Since we moved intel_rom.c back into the display code, just
use intel_de_{read,write}() for the register accesses.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-13-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: Use intel_de_read*() for MCHBAR register accesses
Ville Syrjälä [Tue, 31 Mar 2026 15:42:58 +0000 (18:42 +0300)]
drm/i915/mchbar: Use intel_de_read*() for MCHBAR register accesses

Replace the naked intel_uncore_read*() with intel_de_read*()
in the MCHBAR code.

v2: Rebase due to intel_uncore_read64_2x32()

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-12-ville.syrjala@linux.intel.com
4 months agodrm/i915/vrr: Use intel_de_read64_2x32()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:57 +0000 (18:42 +0300)]
drm/i915/vrr: Use intel_de_read64_2x32()

Replace the pointless use of intel_de_read64_2x32_volatile()
with the simpler intel_de_read64_2x32().

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-11-ville.syrjala@linux.intel.com
4 months agodrm/i915/de: Add a simple intel_de_read64_2x32()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:56 +0000 (18:42 +0300)]
drm/i915/de: Add a simple intel_de_read64_2x32()

intel_de_read64_2x32_volatile() is a complex beast because
it needs to deal with volatile register values. For simpler
cases we can simply do a pair normal intel_de_read()s.

My main reason for hating overuse of intel_de_read64_2x32_volatile()
is that it makes register tracepoints confusing. It always
does three accesses in the somewhat weird udw,ldw,udw order,
confusing the reader of the trace. Much more clear if we just
observe the two reads in the natural little endian order.

We also have no non-volatile use case where the LDW and UDW
are stored in non-consecutive registers, so we can just pass
along a single register offset.

v2: Put the function arguments on one line (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-10-ville.syrjala@linux.intel.com
4 months agodrm/i915/de: s/intel_de_read64_2x32()/intel_de_read64_2x32_volatile()/
Ville Syrjälä [Tue, 31 Mar 2026 15:42:55 +0000 (18:42 +0300)]
drm/i915/de: s/intel_de_read64_2x32()/intel_de_read64_2x32_volatile()/

The raison d'etre of intel_de_read64_2x32() is that it can
handle registers where volatile values are split across two
registers. I don't like that it's being used needlessly.

Rename it to intel_de_read64_2x32_volatile() to make it
more clear when it should be used.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-9-ville.syrjala@linux.intel.com
4 months agodrm/i915/de: Add intel_de_read16()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:54 +0000 (18:42 +0300)]
drm/i915/de: Add intel_de_read16()

We'll need a replacement for intel_uncore_read16() in order to
untangle intel_mchbar_read16() from uncore. As with the 8 bit
counterpart this doesn't need to work on modern platforms
so we can forgo all the DMC wakelock stuff and whatnot.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-8-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: Use intel_mchbar_read*() instead of intel_uncore_read*()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:53 +0000 (18:42 +0300)]
drm/i915/mchbar: Use intel_mchbar_read*() instead of intel_uncore_read*()

Replace all the naked intel_uncore_read*() accesses to MCHBAR
registers with the dedicated intel_mchbar_read*().

v2: Rebase due to the intel_mchbar_read64_2x32() rename

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-7-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: Use intel_mchbar_read() instead of intel_de_read()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:52 +0000 (18:42 +0300)]
drm/i915/mchbar: Use intel_mchbar_read() instead of intel_de_read()

We are doing a few accesses to MCHBAR registers with intel_de_read().
Use the dedicated intel_mchbar_read() instead.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-6-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: WARN when accessing non-MCHBAR registers via intel_mchbar_read*()
Ville Syrjälä [Tue, 31 Mar 2026 15:42:51 +0000 (18:42 +0300)]
drm/i915/mchbar: WARN when accessing non-MCHBAR registers via intel_mchbar_read*()

The intel_mchbar_read*() functions should only be used for
accessing MCHBAR registers. Warn if someone tries to use
them for other registers.

I suppose we could even have a dedicated type for MCHBAR
registers. But that is true for many other special register
types as well, and so far we haven't bothered adding any
special types apart from i915_mcr_reg_t.

v2: Print the register offset (Jani)
    Mention i915_mcr_reg_t (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-5-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: Define the end of the MCHBAR mirror
Ville Syrjälä [Tue, 31 Mar 2026 15:42:50 +0000 (18:42 +0300)]
drm/i915/mchbar: Define the end of the MCHBAR mirror

Add defines for the end of the MCHBAR mirror. I'm planning to
use this for some range sanity checks.

BSpec: 51771
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-4-ville.syrjala@linux.intel.com
4 months agodrm/i915/mchbar: Provide intel_mchbar_read*() abstraction
Ville Syrjälä [Tue, 31 Mar 2026 15:42:49 +0000 (18:42 +0300)]
drm/i915/mchbar: Provide intel_mchbar_read*() abstraction

MCHBAR registers are a bit special in that:
- we access them through the mirror
- the mirror is read only on HSW+
- the mirror requires the actual MCHBAR to be enabled in device 0:0.0
- the mirror is gone on MTL+

So I'd prefer to treat MCHBAR registers as a bit special in
the code as well, and do all accesses to them via dedicated
functions. Prodive such functions in the form of
intel_mchbar_read*().

v2: Put the function arguments on one line
    No intel_uncore_read64() on xe, use intel_uncore_read64_2x32()
    Name the new function intel_mchbar_read64_2x32() as well

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-3-ville.syrjala@linux.intel.com
4 months agodrm/i915/qgv: Use intel_de_read() for MTL_MEM_SS_INFO* reads
Ville Syrjälä [Tue, 31 Mar 2026 15:42:48 +0000 (18:42 +0300)]
drm/i915/qgv: Use intel_de_read() for MTL_MEM_SS_INFO* reads

The MTL_MEM_SS_INFO* are just regular display registers. Use
intel_de_read() to access them.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-2-ville.syrjala@linux.intel.com
4 months agodrm/{i915, xe}: add shared header for VLV IOSF sideband units and registers
Jani Nikula [Tue, 31 Mar 2026 11:40:58 +0000 (14:40 +0300)]
drm/{i915, xe}: add shared header for VLV IOSF sideband units and registers

Move vlv_iosf_sb_reg.h to include/drm/intel/vlv_iosf_sb_regs.h. Use
_regs.h suffix to align better with other register headers. Move enum
vlv_iosf_sb_unit there as well, breaking the final include tie related
to IOSF sideband between display and i915 core.

With this, we can completely remove the xe compat vls_iosf_sb*.h
headers.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/41b060b0d6453de39ca775eab10ee12b25c45b7d.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915: move VLV IOSF sideband to display parent interface
Jani Nikula [Tue, 31 Mar 2026 11:40:57 +0000 (14:40 +0300)]
drm/i915: move VLV IOSF sideband to display parent interface

Remove another direct dependency from display to i915 core by moving the
VLV IOSF sideband calls to the display parent interface. Xe doesn't need
this, so it'll remain optional and NULL.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/15dfc67b58f5b5b381be0f9bc66d60b43bebfecf.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dram: prefer display abstractions for VLV sideband
Jani Nikula [Tue, 31 Mar 2026 11:40:56 +0000 (14:40 +0300)]
drm/i915/dram: prefer display abstractions for VLV sideband

Use the display wrappers for VLV sideband in dram code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c971f1a1eccceeb5599ccea5909443afe24b20d3.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915: pass struct intel_display * to VLV sideband wrappers
Jani Nikula [Tue, 31 Mar 2026 11:40:55 +0000 (14:40 +0300)]
drm/i915: pass struct intel_display * to VLV sideband wrappers

In display code, the display pointer will be all around more convenient.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/a355fe0642f7e6566a22e85bda455092e49e3b68.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/{i915, xe}: convert VLV sideband display wrappers into real functions
Jani Nikula [Tue, 31 Mar 2026 11:40:54 +0000 (14:40 +0300)]
drm/{i915, xe}: convert VLV sideband display wrappers into real functions

Convert the VLV sideband static inline wrappers into real
functions. This will help the follow-up work of moving the VLV sideband
to the display parent interface.

The downside is that we'll have to build vlv_sideband.c as part of xe
build, to avoid a plethora of stubs.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/57740dc3a820cb5fc1cfcd28e4be58b2cb48020d.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dp: Implement the POST_LT_ADJ_REQ sequence
Ville Syrjälä [Mon, 30 Mar 2026 20:26:28 +0000 (23:26 +0300)]
drm/i915/dp: Implement the POST_LT_ADJ_REQ sequence

Implement the POST_LT_ADJ_REQ sequence, which should be used
to further fine tune the link if TPS4 is not supported.
The POST_LT_ADJ_REQ sequence will be performed after
the normal link training has succeeded.

Only the final hop between the last LTTPR and DPRX will
perform the POST_LT_ADJ_REQ adjustment. The earlier hops
will use TPS4 instead since it's mandatory for LTTPRs.

The sequence will terminate when the sink clears the
"in progress" flag, the vswing/pre-emphasis values have
changed six times, or the vswing/pre-emphasis values have
remained unchanged for 200 ms.

Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260330202629.28616-2-ville.syrjala@linux.intel.com
4 months agodrm/i915: Move the sharpness filter dump next to pfit
Ville Syrjälä [Wed, 25 Mar 2026 13:58:49 +0000 (15:58 +0200)]
drm/i915: Move the sharpness filter dump next to pfit

Group the sharpness filter parameters next to all the other pfit
stuff in the state dump.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-7-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agodrm/i915: Eliminate out of place "HBlank" CamelCase
Ville Syrjälä [Wed, 25 Mar 2026 13:58:48 +0000 (15:58 +0200)]
drm/i915: Eliminate out of place "HBlank" CamelCase

Nothing else in the crtc state dump uses CamelCase, so
don't use it for "HBlank" either.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-6-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agodrm/i915: Include the crtc min_voltage_level in the state dump
Ville Syrjälä [Wed, 25 Mar 2026 13:58:47 +0000 (15:58 +0200)]
drm/i915: Include the crtc min_voltage_level in the state dump

Include the pipe's min_voltage_level in its state dump, to help
with debugging.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-5-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agodrm/i915: Split the pipe_src dump to its own line
Ville Syrjälä [Wed, 25 Mar 2026 13:58:46 +0000 (15:58 +0200)]
drm/i915: Split the pipe_src dump to its own line

The pipe_src dump doesn't really fit in with the rest
of the guys (pixel_rate, port_clock, min_cdclk) included
on the same line. Split pipe_src onto its own line,
next to the related pfit stuff.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-4-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agodrm/i915/dp: Use crtc_state->enhanced_framing properly on ivb/hsw CPU eDP
Ville Syrjälä [Wed, 25 Mar 2026 13:58:45 +0000 (15:58 +0200)]
drm/i915/dp: Use crtc_state->enhanced_framing properly on ivb/hsw CPU eDP

Looks like I missed the drm_dp_enhanced_frame_cap() in the ivb/hsw CPU
eDP code when I introduced crtc_state->enhanced_framing. Fix it up so
that the state we program to the hardware is guaranteed to match what
we computed earlier.

Cc: stable@vger.kernel.org
Fixes: 3072a24c778a ("drm/i915: Introduce crtc_state->enhanced_framing")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-3-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agodrm/i915/cdclk: Do the full CDCLK dance for min_voltage_level changes
Ville Syrjälä [Wed, 25 Mar 2026 13:58:44 +0000 (15:58 +0200)]
drm/i915/cdclk: Do the full CDCLK dance for min_voltage_level changes

Apparently I forgot about the pipe min_voltage_level when I
decoupled the CDCLK calculations from modesets. Even if the
CDCLK frequency doesn't need changing we may still need to
bump the voltage level to accommodate an increase in the
port clock frequency.

Currently, even if there is a full modeset, we won't notice the
need to go through the full CDCLK calculations/programming,
unless the set of enabled/active pipes changes, or the
pipe/dbuf min CDCLK changes.

Duplicate the same logic we use the pipe's min CDCLK frequency
to also deal with its min voltage level.

Note that the 'allow_voltage_level_decrease' stuff isn't
really useful here since the min voltage level can only
change during a full modeset. But I think sticking to the
same approach in the three similar parts (pipe min cdclk,
pipe min voltage level, dbuf min cdclk) is a good idea.

Cc: stable@vger.kernel.org
Tested-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15826
Fixes: ba91b9eecb47 ("drm/i915/cdclk: Decouple cdclk from state->modeset")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-2-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
4 months agoMerge drm/drm-next into drm-intel-next
Jani Nikula [Mon, 30 Mar 2026 12:06:42 +0000 (15:06 +0300)]
Merge drm/drm-next into drm-intel-next

Backmerge drm-next to sync up with drm and xe changes, in particular
AuxCCS.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dmc: Enable PIPEDMC_ERROR interrupt
Dibin Moolakadan Subrahmanian [Fri, 27 Mar 2026 06:44:53 +0000 (12:14 +0530)]
drm/i915/dmc: Enable PIPEDMC_ERROR interrupt

Enable PIPEDMC_ERROR interrupt bit for display version 35+.

Changes in v2:
- Move PIPEDMC_ERROR interrupt enable to a separate patch (Ville Syrjala)
Changes in v3:
- Add Bspec reference (Suraj Kandpal)
Changes in v4:
- Add TODO to check the enablement of PIPEDMC_ERROR for PTL (Suraj Kandpal)
Changes in v5:
- Move TODO to the beginning of pipedmc_interrupt_mask() (Suraj Kandpal)

Bspec: 70296
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260327064453.2241523-3-dibin.moolakadan.subrahmanian@intel.com
4 months agodrm/i915/dmc: Remove invalid PIPEDMC interrupt bits
Dibin Moolakadan Subrahmanian [Fri, 27 Mar 2026 06:44:52 +0000 (12:14 +0530)]
drm/i915/dmc: Remove invalid PIPEDMC interrupt bits

On display version 35+ PIPEDMC_ATS_FAULT and
PIPEDMC_GTT_FAULT interrupt bits are no longer defined.

Update the interrupt mask to drop these.

Changes in v2:
- Move PIPEDMC_ERROR interrupt enable to a separate patch (Ville Syrjala)
Changes in v3:
- Add Bspec reference (Suraj Kandpal)
Changes in v4:
- Move bspec position in commit message(Suraj Kandpal)

Bspec: 70296
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260327064453.2241523-2-dibin.moolakadan.subrahmanian@intel.com
4 months agoMerge tag 'drm-xe-next-2026-03-26-1' of https://gitlab.freedesktop.org/drm/xe/kernel...
Dave Airlie [Sun, 29 Mar 2026 20:04:57 +0000 (06:04 +1000)]
Merge tag 'drm-xe-next-2026-03-26-1' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next

Hi Dave and Sima,

Here goes our late, final drm-xe-next PR towards 7.1. We just purgeable
BO uAPI in today, hence the late pull.

In the big things we have:
- Add support for purgeable buffer objects

Thanks,
Matt

UAPI Changes:
- Add support for purgeable buffer objects (Arvind, Himal)

Driver Changes:
- Remove useless comment (Maarten)
- Issue GGTT invalidation under lock in ggtt_node_remove (Brost, Fixes)
- Fix mismatched include guards in header files (Shuicheng)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/acX4fWxPkZrrfwnT@gsse-cloud1.jf.intel.com
4 months agodrm/i915/uncore: Do GT FIFO checks in early sanitize and forcewake get
Ville Syrjälä [Mon, 23 Mar 2026 10:16:09 +0000 (12:16 +0200)]
drm/i915/uncore: Do GT FIFO checks in early sanitize and forcewake get

We're mixing up the GT FIFO debug checks (overflows and such)
with RMbus unclaimed register checks. The two are quite different
things as RMbus is only relevant for display registers, and the
GT FIFO only relevant for GT registers.

Split the GT FIFO debugs out from the unclaimed register logic
and just do the checks during forcewake_get() and early init.
That is still sufficient to detect if any errors have happened.

Any errors would anyway be caused by overflowing the FIFO
rather than accessing specific registers, so trying to figure
out exactly when the error happened isn't particularly useful.
To fix such issues we'd rather have to do something to slow down
the rate at which registers are accessed (eg. increase
GT_FIFO_NUM_RESERVED_ENTRIES or something).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/selftests: Nuke live_forcewake_domains selftest
Ville Syrjälä [Mon, 23 Mar 2026 10:16:08 +0000 (12:16 +0200)]
drm/i915/selftests: Nuke live_forcewake_domains selftest

The live_forcewake_domains selftest doesn't really test anything
particularly sensible. It only runs on platforms that have RMbus
unclaimer error detection, but that only catches display registers
which the test doesn't even access.

I suppose if we really wanted to we might try to make the test
exercise the GT FIFO instead by writing GT registers as fast
as possible, and then checking GTFIFODBG to see if the FIFO has
overflowed. But dunno if there's much point in that. I think a
GT FIFO overflow might even be fatal to the machine.

So in its current for the test doesn't really make sense,
and it's in the way of moving all the RMbus noclaim stuff
to the display driver side. So let's just get rid of it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dsi: Place clock into LP during LPM if requested
Ville Syrjälä [Thu, 26 Mar 2026 11:18:14 +0000 (13:18 +0200)]
drm/i915/dsi: Place clock into LP during LPM if requested

TGL/ADL DSI can be configured to place the clock lane into
LP state during LPM, if otherwise configured for continuous
HS clock.

Hook that up. VBT tells us whether this should be done.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dsi: Fill BLLPs with blanking packets if requested
Ville Syrjälä [Thu, 26 Mar 2026 11:18:13 +0000 (13:18 +0200)]
drm/i915/dsi: Fill BLLPs with blanking packets if requested

TGL/ADL DSI can be configured to fill all BLLPs with blanking
packets. Currently we enable that always, but the VBT actually
tells us whether this is desired or not. Hook that up.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dsi: Make 'clock_stop' boolean
Ville Syrjälä [Thu, 26 Mar 2026 11:18:12 +0000 (13:18 +0200)]
drm/i915/dsi: Make 'clock_stop' boolean

The DSI 'clock_stop' parameter is a boolean, so use a real
'bool' for it. And pimp the debug print while at it.

Note that we also remove the incorrect negation of the value
in the debug print. That has been there since the code was
introduced in commit 2ab8b458c6a1 ("drm/i915: Add support for
Generic MIPI panel driver"). An earlier version of the patch
https://lore.kernel.org/intel-gfx/1397454507-10273-5-git-send-email-shobhit.kumar@intel.com/
got it right, but looks like it got fumbled while dealing
with other review comments.

v2: Highlight the removal of the '!' (Jani)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dsi: s/eotp_pkt/eot_pkt/
Ville Syrjälä [Thu, 26 Mar 2026 11:18:11 +0000 (13:18 +0200)]
drm/i915/dsi: s/eotp_pkt/eot_pkt/

eotp == "End of Transmission Packet". Drop the redundant
extra 'p' from 'eotp_pkt', and make the thing a boolean
while at it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agodrm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode
Ville Syrjälä [Thu, 26 Mar 2026 11:18:10 +0000 (13:18 +0200)]
drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode

Stop adjusting the horizontal timing values based on the
compression ratio in command mode. Bspec seems to be telling
us to do this only in video mode, and this is also how the
Windows driver does things.

This should also fix a div-by-zero on some machines because
the adjusted htotal ends up being so small that we end up with
line_time_us==0 when trying to determine the vtotal value in
command mode.

Note that this doesn't actually make the display on the
Huawei Matebook E work, but at least the kernel no longer
explodes when the driver loads.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com
Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
4 months agoMerge tag 'mediatek-drm-next-20260325' of https://git.kernel.org/pub/scm/linux/kernel...
Dave Airlie [Fri, 27 Mar 2026 07:04:55 +0000 (17:04 +1000)]
Merge tag 'mediatek-drm-next-20260325' of https://git./linux/kernel/git/chunkuang.hu/linux into drm-next

Mediatek DRM Next - 20260325

1. mtk_dsi: enable hs clock during pre-enable
2. Remove all conflicting aperture devices during probe
3. Add support for mt8167 display blocks

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patch.msgid.link/20260325160721.4891-1-chunkuang.hu@kernel.org
4 months agodrm/xe/madvise: Accept canonical GPU addresses in xe_vm_madvise_ioctl
Arvind Yadav [Thu, 26 Mar 2026 13:08:38 +0000 (18:38 +0530)]
drm/xe/madvise: Accept canonical GPU addresses in xe_vm_madvise_ioctl

Userspace passes canonical (sign-extended) GPU addresses where bits 63:48
mirror bit 47. The internal GPUVM uses non-canonical form (upper bits
zeroed), so passing raw canonical addresses into GPUVM lookups causes
mismatches for addresses above 128TiB.

Strip the sign extension with xe_device_uncanonicalize_addr() at the
top of xe_vm_madvise_ioctl(). Non-canonical addresses are unaffected.

Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe")
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-13-arvind.yadav@intel.com
4 months agodrm/xe/madvise: Enable purgeable buffer object IOCTL support
Arvind Yadav [Thu, 26 Mar 2026 13:08:37 +0000 (18:38 +0530)]
drm/xe/madvise: Enable purgeable buffer object IOCTL support

Hook the madvise_purgeable() handler into the madvise IOCTL now that all
supporting infrastructure is complete:

 - Core purge implementation (patch 3)
 - BO state tracking and helpers (patches 1-2)
 - Per-VMA purgeable state tracking (patch 6)
 - Shrinker integration for memory reclamation (patch 10)

This final patch enables userspace to use the
DRM_XE_VMA_ATTR_PURGEABLE_STATE madvise type to mark buffers as
WILLNEED/DONTNEED and receive the retained status indicating whether
buffers were purged.

The feature was kept disabled in earlier patches to maintain
bisectability and ensure all components are in place before exposing to
userspace.

Userspace can detect kernel support for purgeable BOs by checking the
DRM_XE_QUERY_CONFIG_FLAG_HAS_PURGING_SUPPORT flag in the query_config
response.

Suggested-by: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-12-arvind.yadav@intel.com
4 months agodrm/xe/bo: Add purgeable shrinker state helpers
Arvind Yadav [Thu, 26 Mar 2026 13:08:36 +0000 (18:38 +0530)]
drm/xe/bo: Add purgeable shrinker state helpers

Encapsulate TTM purgeable flag updates and shrinker page accounting
into helper functions to prevent desynchronization between the TTM
tt->purgeable flag and the shrinker's page bucket counters.

Without these helpers, direct manipulation of xe_ttm_tt->purgeable
risks forgetting to update the corresponding shrinker counters,
leading to incorrect memory pressure calculations.

Update purgeable BO state to PURGED after successful shrinker purge
for DONTNEED BOs.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-11-arvind.yadav@intel.com
4 months agodrm/xe/dma_buf: Block export of DONTNEED/purged BOs
Arvind Yadav [Thu, 26 Mar 2026 13:08:35 +0000 (18:38 +0530)]
drm/xe/dma_buf: Block export of DONTNEED/purged BOs

Don't allow exporting BOs marked DONTNEED or PURGED as dma-bufs.
DONTNEED BOs can have their contents discarded at any time, making
the exported dma-buf unusable for external devices. PURGED BOs have
no backing store and are permanently invalid.

Return -EBUSY for DONTNEED BOs (temporary purgeable state) and
-EINVAL for purged BOs (permanent, no backing store).

The export path now checks the BO's purgeable state before creating
the dma-buf, preventing external devices from accessing memory that
may be purged at any time.

Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-10-arvind.yadav@intel.com
4 months agodrm/xe/bo: Block mmap of DONTNEED/purged BOs
Arvind Yadav [Thu, 26 Mar 2026 13:08:34 +0000 (18:38 +0530)]
drm/xe/bo: Block mmap of DONTNEED/purged BOs

Don't allow new CPU mmaps to BOs marked DONTNEED or PURGED.
DONTNEED BOs can have their contents discarded at any time, making
CPU access undefined behavior. PURGED BOs have no backing store and
are permanently invalid.

Return -EBUSY for DONTNEED BOs (temporary purgeable state) and
-EINVAL for purged BOs (permanent, no backing store).

The mmap offset ioctl now checks the BO's purgeable state before
allowing userspace to establish a new CPU mapping. This prevents
the race where userspace gets a valid offset but the BO is purged
before actual faulting begins.

Existing mmaps (established before DONTNEED) may still work until
pages are purged, at which point CPU faults fail with SIGBUS.

Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-9-arvind.yadav@intel.com
4 months agodrm/xe/madvise: Block imported and exported dma-bufs
Arvind Yadav [Thu, 26 Mar 2026 13:08:33 +0000 (18:38 +0530)]
drm/xe/madvise: Block imported and exported dma-bufs

Prevent marking imported or exported dma-bufs as purgeable.
External devices may be accessing these buffers without our
knowledge, making purging unsafe.

Check drm_gem_is_imported() for buffers created by other
drivers and obj->dma_buf for buffers exported to other
drivers. Silently skip these BOs during madvise processing.

This follows drm_gem_shmem's purgeable implementation and
prevents data corruption from purging actively-used shared
buffers.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-8-arvind.yadav@intel.com
4 months agodrm/xe/madvise: Implement per-VMA purgeable state tracking
Arvind Yadav [Thu, 26 Mar 2026 13:08:32 +0000 (18:38 +0530)]
drm/xe/madvise: Implement per-VMA purgeable state tracking

Track purgeable state per-VMA instead of using a coarse shared
BO check. This prevents purging shared BOs until all VMAs across
all VMs are marked DONTNEED.

Add xe_bo_all_vmas_dontneed() to check all VMAs before marking
a BO purgeable. Add xe_bo_recheck_purgeable_on_vma_unbind() to
handle state transitions when VMAs are destroyed - if all
remaining VMAs are DONTNEED the BO can become purgeable, or if
no VMAs remain it transitions to WILLNEED.

The per-VMA purgeable_state field stores the madvise hint for
each mapping. Shared BOs can only be purged when all VMAs
unanimously indicate DONTNEED.

This prevents the bug where unmapping the last VMA would incorrectly
flip a DONTNEED BO back to WILLNEED. The enum-based state check
preserves BO state when no VMAs remain, only updating when VMAs provide
explicit hints.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-7-arvind.yadav@intel.com
4 months agodrm/xe/vm: Prevent binding of purged buffer objects
Arvind Yadav [Thu, 26 Mar 2026 13:08:31 +0000 (18:38 +0530)]
drm/xe/vm: Prevent binding of purged buffer objects

Add purge checking to vma_lock_and_validate() to block new mapping
operations on purged BOs while allowing cleanup operations to proceed.

Purged BOs have their backing pages freed by the kernel. New
mapping operations (MAP, PREFETCH, REMAP) must be rejected with
-EINVAL to prevent GPU access to invalid memory. Cleanup
operations (UNMAP) must be allowed so applications can release
resources after detecting purge via the retained field.

REMAP operations require mixed handling - reject new prev/next
VMAs if the BO is purged, but allow the unmap portion to proceed
for cleanup.

The check_purged flag in struct xe_vma_lock_and_validate_flags
distinguishes between these cases: true for new mappings (must reject),
false for cleanup (allow).

Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-6-arvind.yadav@intel.com
4 months agodrm/xe/bo: Block CPU faults to purgeable buffer objects
Arvind Yadav [Thu, 26 Mar 2026 13:08:30 +0000 (18:38 +0530)]
drm/xe/bo: Block CPU faults to purgeable buffer objects

Block CPU page faults to buffer objects marked as purgeable (DONTNEED)
or already purged. Once a BO is marked DONTNEED, its contents can be
discarded by the kernel at any time, making access undefined behavior.
Return VM_FAULT_SIGBUS immediately to fail consistently instead of
allowing erratic behavior where access sometimes works (if not yet
purged) and sometimes fails (if purged).

For DONTNEED BOs:
- Block new CPU faults with SIGBUS to prevent undefined behavior.
- Existing CPU PTEs may still work until TLB flush, but new faults
  fail immediately.

For PURGED BOs:
- Backing store has been reclaimed, making CPU access invalid.
- Without this check, accessing existing mmap mappings would trigger
  xe_bo_fault_migrate() on freed backing store, causing kernel hangs
  or crashes.

The purgeable check is added to both CPU fault paths:
- Fastpath (xe_bo_cpu_fault_fastpath): Returns VM_FAULT_SIGBUS
  immediately under dma-resv lock, preventing attempts to
  migrate/validate DONTNEED/purged pages.
- Slowpath (xe_bo_cpu_fault): Returns -EFAULT under drm_exec lock,
  converted to VM_FAULT_SIGBUS.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-5-arvind.yadav@intel.com
4 months agodrm/xe/madvise: Implement purgeable buffer object support
Arvind Yadav [Thu, 26 Mar 2026 13:08:29 +0000 (18:38 +0530)]
drm/xe/madvise: Implement purgeable buffer object support

This allows userspace applications to provide memory usage hints to
the kernel for better memory management under pressure:

Add the core implementation for purgeable buffer objects, enabling
memory reclamation of user-designated DONTNEED buffers during eviction.

This patch implements the purge operation and state machine transitions:

Purgeable States (from xe_madv_purgeable_state):
 - WILLNEED (0): BO should be retained, actively used
 - DONTNEED (1): BO eligible for purging, not currently needed
 - PURGED (2): BO backing store reclaimed, permanently invalid

Design Rationale:
  - Async TLB invalidation via trigger_rebind (no blocking
    xe_vm_invalidate_vma)
  - i915 compatibility: retained field, "once purged always purged"
    semantics
  - Shared BO protection prevents multi-process memory corruption
  - Scratch PTE reuse avoids new infrastructure, safe for fault mode

Note: The madvise_purgeable() function is implemented but not hooked
into the IOCTL handler (madvise_funcs[] entry is NULL) to maintain
bisectability. The feature will be enabled in the final patch when all
supporting infrastructure (shrinker, per-VMA tracking) is complete.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-4-arvind.yadav@intel.com
4 months agodrm/xe/bo: Add purgeable bo state tracking and field madv to xe_bo
Arvind Yadav [Thu, 26 Mar 2026 13:08:28 +0000 (18:38 +0530)]
drm/xe/bo: Add purgeable bo state tracking and field madv to xe_bo

Add infrastructure for tracking purgeable state of buffer objects.
This includes:

Introduce enum xe_madv_purgeable_state with three states:
   - XE_MADV_PURGEABLE_WILLNEED (0): BO is needed and should not be
     purged. This is the default state for all BOs.

   - XE_MADV_PURGEABLE_DONTNEED (1): BO is not currently needed and
     can be purged by the kernel under memory pressure to reclaim
     resources. Only non-shared BOs can be marked as DONTNEED.

   - XE_MADV_PURGEABLE_PURGED (2): BO has been purged by the kernel.
     Accessing a purged BO results in error. Follows i915 semantics
     where once purged, the BO remains permanently invalid ("once
     purged, always purged").

Add madv_purgeable field to struct xe_bo for state tracking
  of purgeable state across concurrent access paths

Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-3-arvind.yadav@intel.com
4 months agodrm/xe/uapi: Add UAPI support for purgeable buffer objects
Himal Prasad Ghimiray [Thu, 26 Mar 2026 13:08:27 +0000 (18:38 +0530)]
drm/xe/uapi: Add UAPI support for purgeable buffer objects

Extend the DRM_XE_MADVISE ioctl to support purgeable buffer object
management by adding DRM_XE_VMA_ATTR_PURGEABLE_STATE attribute type.

This allows userspace applications to provide memory usage hints to
the kernel for better memory management under pressure:

- WILLNEED: Buffer is needed and should not be purged. If the BO was
  previously purged, retained field returns 0 indicating backing store
  was lost (once purged, always purged semantics matching i915).

- DONTNEED: Buffer is not currently needed and may be purged by the
  kernel under memory pressure to free resources. Only applies to
  non-shared BOs.

  To prevent undefined behavior, the following operations are blocked
  while a BO is in DONTNEED state:
  - New mmap() operations return -EBUSY
  - VM_BIND operations return -EBUSY
  - New dma-buf exports return -EBUSY
  - CPU page faults return SIGBUS
  - GPU page faults fail with -EACCES

  This ensures applications cannot use a BO while marked as DONTNEED,
  preventing erratic behavior when the kernel purges the backing store.

The implementation includes a 'retained' output field (matching i915's
drm_i915_gem_madvise.retained) that indicates whether the BO's backing
store still exists (1) or has been purged (0).

Added DRM_XE_QUERY_CONFIG_FLAG_HAS_PURGING_SUPPORT flag to allow
userspace to detect kernel support for purgeable buffer objects
before attempting to use the feature.

Cc: Matthew Brost <matthew.brost@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260326130843.3545241-2-arvind.yadav@intel.com
4 months agoMerge tag 'drm-misc-next-2026-03-26' of https://gitlab.freedesktop.org/drm/misc/kerne...
Dave Airlie [Fri, 27 Mar 2026 02:45:28 +0000 (12:45 +1000)]
Merge tag 'drm-misc-next-2026-03-26' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

drm-misc-next for v7.1:

UAPI Changes:

amdxdna:
- support per-BO memory-usage queries

docs:
- Improve UAPI documentation

panthor:
- extend timestamp query with flags

Core Changes:

edid:
- provide enum drm_output_color_format; mass-convert drivers

gem-dma:
- use drm_dev_dma_dev() for DMA mappings
- set VM_DONTDUMP on mmap

mipi-dbi:
- drop simple-display; mass-convert drivers

prime:
- use drm_dev_dma_dev() for DMA mappings

ttm:
- improve handling of gfp_retry_mayfail

Driver Changes:

amdgpu:
- use atomic_create_state for private_obj

amdxdna:
- refactor GEM implementation
- fixes

bridge:
- provide clear-and-put helper for reliable cleanup
- analogix_dp: Use DP helpers for link training
- lontium-lt8713sx: Fix 64-bit division and Kconfig
- samsung-dsim: Use clear-and-put

imagination:
- improve power-off sequence
- support context-reset notification from firmware

komeda:
- support Arm China Linlon D6 plus DT bindings

mediatek:
- use drm_dev_dma_dev() for DMA mappings

panel:
- support Himax HX83121A plus DT bindings
- support JuTouch JT070TM041 plus DT bindings
- support Samsung S6E8FC0 plus DT bindings
- himax-hx83102c: support Samsung S6E8FC0 plus DT bindings; support backlight
- ili9806e: support Rocktech RK050HR345-CT106A plus DT bindings
- simple: support Tianma TM050RDH03 plus DT bindings

panthor:
- support various sources for timestamp queries
- fixes

omapdrm:
- use atomic_create_state for private_obj

rcar-du:
- fix suspend/resume wrt VSP interface
- fix leak of device_link
- clean up

sun4i:
- use drm_dev_dma_dev() for DMA mappings

tegra:
- use atomic_create_state for private_obj

xe:
- send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260326151812.GA76082@linux.fritz.box
4 months agoMerge tag 'drm-xe-next-2026-03-25' of https://gitlab.freedesktop.org/drm/xe/kernel...
Dave Airlie [Fri, 27 Mar 2026 01:01:44 +0000 (11:01 +1000)]
Merge tag 'drm-xe-next-2026-03-25' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next

Hi Dave and Sima,

Here goes our third, perhaps, final drm-xe-next PR towards 7.1.

In the big things we have:
- THP support in drm_pagemap
- xe_vm_get_property_ioctl

Thanks,
Matt

UAPI Changes:
- Implement xe_vm_get_property_ioctl (Jonathan)

Cross-subsystem Changes:
- Enable THP support in drm_pagemap (Francois, Brost)

Core Changes:
- Improve VF FLR synchronization for Xe VFIO (Piotr)

Driver Changes:
- Fix confusion with locals on context creation (Tomasz, Fixes)
- Add new SVM copy GT stats per size (Francois)
- always keep track of remap prev/next (Auld, Fixes)
- AuxCCS handling and render compression modifiers (Tvrtko)
- Implement recent spec updates to Wa_16025250150 (Roper)
- xe3p_lpg: L2 flush optimization (Tejas)
- vf: Improve getting clean NULL context (Wajdeczko)
- pf: Fix use-after-free in migration restore (Winiarski. Fixes)
- Fix format specifier for printing pointer differences (Nathan Chancellor, Fixes)
- Extend Wa_14026781792 for xe3lpg (Niton)
- xe3p_lpg: Add Wa_16029437861 (Varun)
- Fix spelling mistakes and comment style in ttm_resource.c (Varun)
- Merge drm/drm-next into drm-xe-next (Thomas)
- Fix missing runtime PM reference in ccs_mode_store (Sanjay, Fixes)
- Fix uninitialized new_ts when capturing context timestamp (Umesh)
- Allow reading after disabling OA stream (Ashutosh)
- Page Reclamation Fixes (Brian Nguyen, Fixes)
- Include running dword offset in default_lrc dumps (Roper)
- Assert/Deassert I2C IRQ (Raag)
- Fixup reset, wedge, unload corner cases (Zhanjun, Brost)
- Fail immediately on GuC load error (Daniele)
- Fix kernel-doc for DRM_XE_VM_BIND_FLAG_DECOMPRESS (Niton, Fixes)
- Drop redundant entries for Wa_16021867713 & Wa_14019449301 (Roper, Fixes)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/acS5xmWC3ivPTmyV@gsse-cloud1.jf.intel.com
4 months agoMerge tag 'amd-drm-next-7.1-2026-03-25' of https://gitlab.freedesktop.org/agd5f/linux...
Dave Airlie [Thu, 26 Mar 2026 23:30:34 +0000 (09:30 +1000)]
Merge tag 'amd-drm-next-7.1-2026-03-25' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

amd-drm-next-7.1-2026-03-25:

amdgpu:
- DSC fix
- Module parameter parsing fix
- PASID reuse fix
- drm_edid leak fix
- SMU 13.x fixes
- SMU 14.x fix
- Fence fix in amdgpu_amdkfd_submit_ib()
- LVDS fixes
- GPU page fault fix for non-4K pages
- Misc cleanups
- UserQ fixes
- SMU 15.0.8 support
- RAS updates
- Devcoredump fixes
- GFX queue priority fixes
- DPIA fixes
- DCN 4.2 updates
- Add debugfs interface for pcie64 registers
- SMU 15.x fixes
- VCN reset fixes
- Documentation fixes

amdkfd:
- Ordering fix in kfd_ioctl_create_process()

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260325175012.4185721-1-alexander.deucher@amd.com
4 months agodrm/xe: Fix mismatched include guards in header files
Shuicheng Lin [Mon, 16 Mar 2026 16:04:45 +0000 (16:04 +0000)]
drm/xe: Fix mismatched include guards in header files

Fix include guard macros that don't match their respective file names:

- xe_gt_idle_types.h: _XE_GT_IDLE_SYSFS_TYPES_H_ -> _XE_GT_IDLE_TYPES_H_
- xe_guc_exec_queue_types.h: _XE_GUC_ENGINE_TYPES_H_ -> _XE_GUC_EXEC_QUEUE_TYPES_H_
- xe_heci_gsc.h: __XE_HECI_GSC_DEV_H__ -> _XE_HECI_GSC_H_
- xe_hw_engine_class_sysfs.h: _XE_ENGINE_CLASS_SYSFS_H_ -> _XE_HW_ENGINE_CLASS_SYSFS_H_
- xe_late_bind_fw_types.h: _XE_LATE_BIND_TYPES_H_ -> _XE_LATE_BIND_FW_TYPES_H_
- xe_platform_types.h: _XE_PLATFORM_INFO_TYPES_H_ -> _XE_PLATFORM_TYPES_H_
- xe_tile_printk.h: _xe_tile_printk_H_ -> _XE_TILE_PRINTK_H_

These guards appear to be leftovers from file renames or copy-paste
errors. Correcting them to follow the standard convention of matching
the file name prevents potential include guard collisions.

No functional change expected.

Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260316160451.1688247-2-shuicheng.lin@intel.com
4 months agodrm/xe: Issue GGTT invalidation under lock in ggtt_node_remove
Matthew Brost [Thu, 26 Mar 2026 01:12:07 +0000 (18:12 -0700)]
drm/xe: Issue GGTT invalidation under lock in ggtt_node_remove

Async work (e.g., GuC queue teardowns) can call ggtt_node_remove, so the
operation must be performed under the GGTT lock to ensure the GGTT
online check remains stable. GGTT insertion and removal are heavyweight
operations (e.g., queue create/destroy), so the additional serialization
cost is negligible compared to ensuring correctness.

Fixes: 4f3a998a173b ("drm/xe: Open-code GGTT MMIO access protection")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20260326011207.62373-1-matthew.brost@intel.com
4 months agodrm/xe: Remove useless comment.
Maarten Lankhorst [Thu, 26 Mar 2026 12:18:14 +0000 (13:18 +0100)]
drm/xe: Remove useless comment.

Commit 792d2b9a1259 ("drm: drop mtrr from i915"), added this comment,
drop it since it was carried over from i915.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326121818.122401-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
4 months agodrm: rcar-du: Don't leak device_link to CMM
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.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260323164526.2292491-5-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
4 months agodrm: rcar-du: Use __free() to simplify device_node handling
Laurent Pinchart [Mon, 23 Mar 2026 16:45:25 +0000 (18:45 +0200)]
drm: rcar-du: Use __free() to simplify device_node handling

Replace manual of_node_put() calls with __free(). This simplifies error
handling code and makes it less bug-prone.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260323164526.2292491-4-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
4 months agodrm: rcar-du: Store CMM device pointer instead of platform_device
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.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260323164526.2292491-3-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
4 months agodrm: rcar-du: Ensure correct suspend/resume ordering with VSP
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.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Link: https://patch.msgid.link/20260323164526.2292491-2-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
4 months agodt-bindings: display: panel-lvds: Add compatibles for Samsung LTN070NL01 and LTN101AL...
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

Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260303203017.511-5-bavishimithil@gmail.com
4 months agodrm/panel: simple: Correct G190EAN01 prepare timing
Sebastian Reichel [Tue, 17 Feb 2026 14:25:26 +0000 (16:25 +0200)]
drm/panel: simple: Correct G190EAN01 prepare timing

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
4 months agodrm/panel: himax-hx83102: Add support for DSI DCS backlight control
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.

Signed-off-by: Val Packett <val@packett.cool>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217070121.190108-5-val@packett.cool
4 months agodrm/panel: himax-hx83102: Add support for Holitech HTF065H045
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.

Signed-off-by: Val Packett <val@packett.cool>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217070121.190108-4-val@packett.cool
4 months agodt-bindings: display: panel: Add compatible for Holitech HTF065H045
Val Packett [Tue, 17 Feb 2026 07:00:10 +0000 (04:00 -0300)]
dt-bindings: display: panel: Add compatible for Holitech HTF065H045

Add a new compatible for the Holitech HTF065H045 panel that uses the
Himax HX83102 controller IC.

Signed-off-by: Val Packett <val@packett.cool>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217070121.190108-3-val@packett.cool
4 months agodt-bindings: vendor-prefixes: Add Holitech
Val Packett [Tue, 17 Feb 2026 07:00:09 +0000 (04:00 -0300)]
dt-bindings: vendor-prefixes: Add Holitech

Jiangxi Holitech Technology Co., Ltd. is a manufacturer of display panels.

Signed-off-by: Val Packett <val@packett.cool>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217070121.190108-2-val@packett.cool
4 months agodrm: panel: Add Samsung S6E8FC0 DSI controller for M1906F9 panel
Yedaya Katsman [Fri, 20 Mar 2026 14:41:39 +0000 (16:41 +0200)]
drm: panel: Add Samsung S6E8FC0 DSI controller for M1906F9 panel

Add driver for Samsung S6E8FC0 DSI controller for M1906F9 video mode panel,
found in Xiaomi Mi A3 mobile phone.

Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260320-panel-patches-v7-2-3eaefc4b3878@gmail.com
4 months agodt-bindings: display: panel: Add Samsung S6E8FC0-M1906F9
Yedaya Katsman [Fri, 20 Mar 2026 14:41:38 +0000 (16:41 +0200)]
dt-bindings: display: panel: Add Samsung S6E8FC0-M1906F9

Add Samsung S6E8FC0 DTS binding used with the M1906F9 6.09" 720x1560
panel found in the Xiaomi Mi A3 smartphone.

Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260320-panel-patches-v7-1-3eaefc4b3878@gmail.com
4 months agodrm/panel: sharp-ls043t1le01: make use of prepare_prev_first
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
4 months agodt-bindings: display: panel: Align style of "true" properties
Krzysztof Kozlowski [Fri, 13 Mar 2026 08:20:54 +0000 (09:20 +0100)]
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.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260313-dt-bindings-display-panel-clean-v2-1-d49615218f92@oss.qualcomm.com
4 months agodrm/panel: simple: Add Tianma TM050RDH03 panel
Liu Ying [Fri, 27 Feb 2026 09:31:36 +0000 (17:31 +0800)]
drm/panel: simple: Add Tianma TM050RDH03 panel

Add the Tianma Micro-electronics TM050RDH03 5.0" WVGA TFT LCD panel.

Reuse panel ontat,kd50g21-40nt-a1's panel description as they are
identical.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260227-tianma-tm050rdh03-v1-2-cab78a0d765d@nxp.com
4 months agodt-bindings: display: simple: Add Tianma TM050RDH03 panel
Liu Ying [Fri, 27 Feb 2026 09:31:35 +0000 (17:31 +0800)]
dt-bindings: display: simple: Add Tianma TM050RDH03 panel

Add the Tianma Micro-electronics TM050RDH03 5.0" WVGA TFT LCD panel.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260227-tianma-tm050rdh03-v1-1-cab78a0d765d@nxp.com
4 months agodrm/panel: ilitek-ili9806e: add Rocktech RK050HR345-CT106A SPI panel
Dario Binacchi [Wed, 18 Mar 2026 07:32:53 +0000 (08:32 +0100)]
drm/panel: ilitek-ili9806e: add Rocktech RK050HR345-CT106A SPI panel

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.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260318073346.18041-5-dario.binacchi@amarulasolutions.com
4 months agodt-bindings: ili9806e: add Rocktech RK050HR345-CT106A display
Dario Binacchi [Wed, 18 Mar 2026 07:32:52 +0000 (08:32 +0100)]
dt-bindings: ili9806e: add Rocktech RK050HR345-CT106A display

Document the Rocktech 5" 480x854 panel based on the Ilitek ILI9806E
controller.

This panel uses SPI for control and an RGB interface for display
data, so adjust the binding requirements accordingly.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260318073346.18041-4-dario.binacchi@amarulasolutions.com
4 months agodrm/panel: ilitek-ili9806e: split core and DSI logic
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.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260318073346.18041-3-dario.binacchi@amarulasolutions.com
4 months agodrm/panel: ilitek-ili9806e: rename to specific DSI driver
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.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260318073346.18041-2-dario.binacchi@amarulasolutions.com