Merge tag 'drm-intel-next-2025-07-04' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
drm/i915 feature pull #2 for v6.17:
Features and functionality:
- Add drm_panic support for both i915 and xe drivers (Jocelyn Falempe)
- Add initial flip queue implementation, disabled by default, for LNL and PTL
(Ville)
- Add support for Wildcat Lake (WCL) display, version 30.02 (Matt Roper, Matt
Atwood, Dnyaneshwar)
- Extend drm_panel and follower support to DDI eDP (Arun)
Refactoring and cleanups:
- Make all global state objects opaque (Jani)
- Move display works to display specific unordered workqueue (Luca)
- Add and use struct drm_device based pcode interface (Jani, Lucas)
- Use clamp() instead of max()+min() combo (Ankit)
- Simplify wait for power well disable (Jani)
- Various stylistics cleanups and renames (Jani)
Fixes:
- Deal with loss of pipe DMC state (Ville)
- Fix PTL HDCP2 stream status check (Suraj)
- Add workaround for ADL-P DKL PHY DP and HDMI (Nemesa)
- Fix skl_print_wm_changes() stack usage with KMSAN (Arnd Bergmann)
- Fix PCON capability reads on non-branch devices (Chaitanya)
- Fix which platforms have ultra joiner (Ankit)
DRM core changes:
- Add ttm_bo_kmap_try_from_panic() for xe drm_panic support (Jocelyn Falempe)
- Add private pointer to struct drm_scanout buffer for xe/i915 drm_panic support
(Jocelyn Falempe)
Merges:
- Backmerge drm-next for drm_panel and xe changes (Jani)
Jani Nikula [Thu, 26 Jun 2025 19:26:32 +0000 (22:26 +0300)]
drm/i915/power: use intel_de_wait_for_clear() instead of wait_for()
Prefer the register read specific wait function over i915 wait_for_us().
The existing condition is quite complicated. Simplify by checking for
requesters first, and determine timeout based on that. Refresh
requesters in case of timeouts, should one have popped up during the
wait. The downside is that this does not cut the wait short if
requesters show up *during* the wait, but we're talking about 1 ms so
shouldn't be an issue.
v2: Refresh requesters only if there were none before (Imre)
Jani Nikula [Thu, 26 Jun 2025 10:16:36 +0000 (13:16 +0300)]
drm/i915/display: drop a number of dependencies on i915_drv.h
With the switch to an unordered workqueue dedicated to display, we've
stopped using struct drm_i915_private in a number of places, and can
drop the dependencies on i915_drv.h.
Philipp Zabel [Fri, 27 Jun 2025 11:45:41 +0000 (13:45 +0200)]
drm/mipi-dsi: Drop MIPI_DSI_MODE_VSYNC_FLUSH flag
Drop the unused MIPI_DSI_MODE_VSYNC_FLUSH flag. Whether or not a display
FIFO flush on vsync is required to avoid sending garbage to the panel is
not a property of the DSI link, but of the integration between display
controller and DSI host bridge.
Philipp Zabel [Fri, 27 Jun 2025 11:45:38 +0000 (13:45 +0200)]
drm/bridge: samsung-dsim: Always flush display FIFO on vsync pulse
Always flush the display FIFO on vsync pulse, even if not explicitly
requested by the panel via MIPI_DSI_MODE_VSYNC_FLUSH mode_flag.
The display FIFO should be empty at vsync. Flushing it at vsync pulses
helps to remove garbage that may have entered the FIFO during startup
(if synchronisation between upstream display controller and Samsung DSIM
is lacking) and that may persist in form of last frame's leftovers on
subsequent frames. Flushing the display FIFO if it is already empty
should have no effect.
This will allow to remove the MIPI_DSI_MODE_VSYNC_FLUSH flag, which is
only used by the Samsung DSIM bridge driver. Arguably this flag doesn't
belong in the panel configuration at all: flushing the display FIFO on
vsync is a workaround for issues with the integration between display
controller and DSI bridge, not a property of the DSI link between bridge
and panel. No panel actually has a requirement to receive garbage or old
frame content after vsync.
I wonder if host controller FIFO resets are mentioned by the MIPI DSI
specification at all. This patch is based on the assumption that the
MIPI_DSI_MODE_VSYNC_FLUSH flag only exists because the DSIM_MFLUSH_VS
bit happens to be located in the same register as the bits controlling
the DSI mode.
drm/i915/gsc: mei interrupt top half should be in irq disabled context
MEI GSC interrupt comes from i915. It has top half and bottom half.
Top half is called from i915 interrupt handler. It should be in
irq disabled context.
With RT kernel, by default i915 IRQ handler is in threaded IRQ. MEI GSC
top half might be in threaded IRQ context. generic_handle_irq_safe API
could be called from either IRQ or process context, it disables local
IRQ then calls MEI GSC interrupt top half.
This change fixes A380/A770 GPU boot hang issue with RT kernel.
Fixes: 1e3dc1d8622b ("drm/i915/gsc: add gsc as a mei auxiliary device") Tested-by: Furong Zhou <furong.zhou@intel.com> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Link: https://lore.kernel.org/r/20250425151108.643649-1-junxiao.chang@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ce Sun [Mon, 30 Jun 2025 02:29:21 +0000 (10:29 +0800)]
drm/amdgpu: Fix code style issue
cocci warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6088:8-9:
Unneeded variable: "r". Return "0" on line 6141
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506281925.HHIpXiO7-lkp@intel.com/ Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd: Decrease message level for legacy-pm, kv-dpm and si-dpm
legacy-pm, kv-dpm and si-dpm have prints while changing power states
that don't have a level and thus are printed by default. These are
not useful at runtime for most people, so decrease them to debug.
Reported-by: Alexandre Demers <alexandre.f.demers@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4322 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250627143432.3222843-1-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taimur Hassan [Sun, 22 Jun 2025 22:27:48 +0000 (17:27 -0500)]
drm/amd/display: Promote DAL to 3.2.340
Summary:
* Remove unused tunnel BW validation
* Refactor DML21 initialization and configuration
* Fix link override sequencing when switching between DIO/HPO
* Ensure OLED minimum luminance
Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taimur Hassan [Sun, 22 Jun 2025 20:33:48 +0000 (16:33 -0400)]
drm/amd/display: [FW Promotion] Release 0.1.17.0
Summary for changes in firmware:
* Add AMD brightness adjustment feature for edp
* Fix BL enable
* Revise low power init sequence
* Fix brightness delta after IPS1 entry
* Adjusted DP blanking sequence
Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ivan Lipski [Thu, 19 Jun 2025 22:14:52 +0000 (18:14 -0400)]
drm/amd/display: Add DPP & HUBP reset if power gate enabled on DCN314
[WHY]
On DCN314, using full screen application with enabled scaling like 150%,
175%, with overlay cursor, causes a second cursor to appear when changing
planes. Dpp cache is used to track the HW cursor enable. Since power gate
is disabled for hubp & dpp in DCN314, dpp_reset() zero'ed the dpp struct,
while the dpp hardware was not power gated.
So, when plane is changed in a full screen app, and the overlay cursor is
enabled, the cache is cleared, so the cache does not represent the actual
cursor state.
[HOW]
Added conditionals for dpp & hubp reset and their pg_control functions
only if according power_gate flags are enabled.
Reviewed-by: Sun peng Li <sunpeng.li@amd.com> Signed-off-by: Ivan Lipski <ivlipski@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Michael Strauss [Wed, 12 Feb 2025 18:52:42 +0000 (13:52 -0500)]
drm/amd/display: Fix Link Override Sequencing When Switching Between DIO/HPO
[WHY]
When performing certain link maintenance compliance tests or forcing link
settings, changing between 128b/132b and 8b/10b rates no longer works on
some ASICs. Some rate divider updates only occur when we set
timings or validate state, which is not performed currently when toggling
DPMS to change rates.
[HOW]
Re-calculate dividers and reprogram audio when switching between DIO
and HPO through DP compliance/escape code path.
Add OTG disable/re-enable so we don't touch the clock while OTG is active.
Acquire dcLock before forcing link settings to avoid thread synchronization
errors due to added programming in escape code path and potential HPD
interrupts.
Reviewed-by: George Shen <george.shen@amd.com> Signed-off-by: Michael Strauss <michael.strauss@amd.com> Signed-off-by: Mike Katsnelson <mike.katsnelson@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Don't allow OLED to go down to fully off
[Why]
OLED panels can be fully off, but this behavior is unexpected.
[How]
Ensure that minimum luminance is at least 1.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4338 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harold Sun [Thu, 19 Jun 2025 18:52:54 +0000 (14:52 -0400)]
drm/amd/display: Added case for when RR equals panel's max RR using freesync
[WHY]
Rounding error sometimes occurs when the refresh rate is equal to a panel's
max refresh rate, causing HDMI compliance failures.
[HOW]
Added a case so that we round up to avoid v_total_min to be below a panel's
minimum bound.
Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Harold Sun <Harold.Sun@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wenjing Liu [Wed, 11 Jun 2025 21:31:40 +0000 (17:31 -0400)]
drm/amd/display: Refactor DML21 Initialization and Configuration
[Why & How]
- Consolidated the initialization of DML21 parameters into a single
function `dml21_populate_dml_init_params` to streamline the process
and improve code readability.
- Updated the function signatures in the header files to reflect changes
in parameter passing for DML context.
- Removed redundant debug option handling and integrated it into the new
configuration population function.
- Adjusted the DML21 initialization logic in the wrapper to accommodate
the new structure, ensuring compatibility with different DCN versions.
- Enhanced the handling of clock parameters and bounding box configurations
from various sources, including hardware defaults and software policies.
- Improved the clarity of the code by renaming functions and variables for
better understanding of their purposes.
Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why & How]
The tunnel BW validation code has changed to the new one.
Remove the unused code.
The DP tunneling overhead is not updated in SST.
Move updating DP tunneling overhead for both SST and MST.
Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Cruise Hung <Cruise.Hung@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Mon, 16 Jun 2025 21:45:05 +0000 (17:45 -0400)]
drm/amdgpu: move scheduler wqueue handling into callbacks
Move the scheduler wqueue stopping and starting into
the ring reset callbacks. On some IPs we have to reset
an engine which may have multiple queues. Move the wqueue
handling into the backend so we can handle them as needed
based on the type of reset available.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 6 Jun 2025 03:34:48 +0000 (23:34 -0400)]
drm/amdgpu: move guilty handling into ring resets
Move guilty logic into the ring reset callbacks. This
allows each ring reset callback to better handle fence
errors and force completions in line with the reset
behavior for each IP. It also allows us to remove
the ring guilty callback since that logic now lives
in the reset callback.
Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Thu, 29 May 2025 16:58:53 +0000 (12:58 -0400)]
drm/amdgpu: move force completion into ring resets
Move the force completion handling into each ring
reset function so that each engine can determine
whether or not it needs to force completion on the
jobs in the ring.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Steven Price [Mon, 30 Jun 2025 14:07:02 +0000 (15:07 +0100)]
drm/panthor: Wait for _READY register when powering on
panthor_gpu_block_power_on() takes a register offset (rdy_reg) for the
purpose of waiting for the power transition to complete. However, a
copy/paste error converting to use the new 64 register functions
switched it to using the pwrtrans_reg register instead. Fix the function
to use the correct register.
Fixes: 4d230aa209ed ("drm/panthor: Add 64-bit and poll register accessors") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20250630140704.432409-1-steven.price@arm.com
Stopping the scheduler for queue reset is generally a good idea because
it prevents any worker from touching the ring buffer.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Wed, 25 Jun 2025 22:15:37 +0000 (18:15 -0400)]
drm/amdkfd: add hqd_sdma_get_doorbell callbacks for gfx7/8
These were missed when support was added for other generations.
The callbacks are called unconditionally so we need to make
sure all generations have them.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4304 Link: https://github.com/ROCm/ROCm/issues/4965 Fixes: bac38ca8c475 ("drm/amdkfd: implement per queue sdma reset for gfx 9.4+") Cc: Jonathan Kim <jonathan.kim@amd.com> Reported-by: Johl Brown <johlbrown@gmail.com> Reviewed-by: Jonathan Kim <jonathan.kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Lin.Cao [Tue, 24 Jun 2025 09:05:34 +0000 (17:05 +0800)]
drm/amdgpu: Fix memory leak in amdgpu_ctx_mgr_entity_fini
patch dd64956685fa ("drm/amdgpu: Remove duplicated "context still
alive" check") removed ctx put, which will cause amdgpu_ctx_fini()
cannot be called and then cause some finished fence that added by
amdgpu_ctx_add_fence() cannot be released and cause memleak.
Fixes: dd64956685fa ("drm/amdgpu: Remove duplicated "context still alive" check") Signed-off-by: Lin.Cao <lincao12@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Avoid dereferencing struct drm_gem_object.import_attach for the
imported dma-buf. The dma_buf field in the GEM object instance refers
to the same buffer. Prepares to make import_attach an implementation
detail of PRIME.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Philip Yang [Fri, 20 Jun 2025 22:32:32 +0000 (18:32 -0400)]
drm/amdkfd: Don't call mmput from MMU notifier callback
If the process is exiting, the mmput inside mmu notifier callback from
compactd or fork or numa balancing could release the last reference
of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
with below backtrace.
The deadlock will leak kfd process as mmu notifier release is not called
and cause VRAM leaking.
The fix is to take mm reference mmget_non_zero when adding prange to the
deferred list to pair with mmput in deferred list work.
If prange split and add into pchild list, the pchild work_item.mm is not
used, so remove the mm parameter from svm_range_unmap_split and
svm_range_add_child.
Fixes: fa582c6f3684 ("drm/amdkfd: Use mmget_not_zero in MMU notifier") Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kent Russell [Tue, 24 Jun 2025 15:42:06 +0000 (11:42 -0400)]
drm/amdgpu: Include sdma_4_4_4.bin
This got missed during SDMA 4.4.4 support.
Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
André Almeida [Fri, 13 Jun 2025 18:26:51 +0000 (15:26 -0300)]
drm/amd: Include <linux/export.h> when needed
Fix the following compile time warning when building with W=1:
warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
André Almeida [Fri, 13 Jun 2025 18:26:50 +0000 (15:26 -0300)]
drm/amd: Do not include <linux/export.h> when unused
Fix the following compile time warning when building with W=1:
warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present
Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Mon, 16 Jun 2025 18:04:54 +0000 (14:04 -0400)]
drm/amdgpu/sdma5.x: suspend KFD queues in ring reset
SDMA 5.x only supports engine soft reset which resets
all queues on the engine. As such, we need to suspend
KFD queues around resets like we do for SDMA 4.x.
Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add missing drm_display_mode DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC
flags. Those are used by various bridges(e.g. dw-mipi-dsi) in the
pipeline to correctly configure its sync signals polarity.
Andy Yan [Mon, 16 Jun 2025 07:05:17 +0000 (15:05 +0800)]
drivers/panel: raydium-rm67200: Make reset-gpio optional
Although the datasheet of the panel module describes that it has a
reset pin, in the actual hardware design, we often use an RC circuit
to control the reset, and rarely use GPIO to control the reset. This
is the way it is done on our numerous development boards (such as
RK3568/RK3576 EVB).
Andy Yan [Mon, 16 Jun 2025 07:05:16 +0000 (15:05 +0800)]
dt-bindings: display: panel: Make reset-gpio as optional for Raydium RM67200
Although the datasheet of the panel module describes that it has a
reset pin, in the actual hardware design, we often use an RC circuit
to control the reset, and rarely use GPIO to control the reset. This
is the way it is done on our numerous development boards (such as RK3568,
RK3576 EVB).
So make the reset-gpio optional.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250616070536.670519-1-andyshrk@163.com
Philipp Stanner [Thu, 5 Jun 2025 13:41:55 +0000 (15:41 +0200)]
drm/sched/tests: Make timedout_job callback a better role model
Since the drm_mock_scheduler does not have real users in userspace, nor
does it have real hardware or firmware rings, it's not necessary to
signal timedout fences nor free jobs - from a functional standpoint.
Still, the dma_fence framework establishes the hard rule that all fences
must always get signaled.
The unit tests, moreover, should as much as possible represent the
intended usage of the scheduler API.
Furthermore, this later enables simplifying the mock scheduler's
teardown code path.
Make sure timed out hardware fences get signaled with the appropriate
error code.
Suraj Kandpal [Fri, 20 Jun 2025 06:34:45 +0000 (12:04 +0530)]
drm/i915/backlight: Use drm_edp_backlight_enable
Use drm dp helper to enable backlight now that it has been modified
to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability
supports it and the driver wants it. Remove the dead code.
Suraj Kandpal [Fri, 20 Jun 2025 06:34:41 +0000 (12:04 +0530)]
drm/dp: Change argument type of drm_edp_backlight_enable
Change the argument type to u32 for the default level being sent
since it has to now account for luminance value which has to be
set for DP_EDP_PANEL_LUMINANCE_TARGET_VALUE.
Suraj Kandpal [Fri, 20 Jun 2025 06:34:40 +0000 (12:04 +0530)]
drm/dp: Modify drm_edp_backlight_set_level
Modify drm_edp_backlight_set_level to be able to set the value
for register in DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We multiply
the level with 1000 since we get the value in Nits and the
register accepts it in milliNits.
Suraj Kandpal [Fri, 20 Jun 2025 06:34:38 +0000 (12:04 +0530)]
drm/dp: Modify drm_edp_probe_state
Modify drm_edp_probe_state to read current level from
DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We divide it by
1000 since the value in this register is in millinits.
Suraj Kandpal [Fri, 20 Jun 2025 06:34:36 +0000 (12:04 +0530)]
drm/dp: Move from u16 to u32 for max in drm_edp_backlight_info
Use u32 instead of u16 for max variable in drm_edp_backlight_info
since it can now hold max luminance range value which is u32.
We will set this max with max_luminance value when luminance_set is
true.
Closer analysis of CI results history has revealed a dependency of the
error on a few IGT tests, namely:
- igt@api_intel_allocator@fork-simple-stress-signal,
- igt@api_intel_allocator@two-level-inception-interruptible,
- igt@gem_linear_blits@interruptible,
- igt@prime_mmap_coherency@ioctl-errors,
which invisibly trigger the issue, then exhibited with first driver unbind
attempt.
All of the above tests perform actions which are actively interrupted with
signals. Further debugging has allowed to narrow that scope down to
DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring
submission, in particular.
If successful then that function, or its execlists or GuC submission
equivalent, is supposed to be called only once per GEM context engine,
followed by raise of a flag that prevents the function from being called
again. The function is expected to unwind its internal errors itself, so
it may be safely called once more after it returns an error.
In case of ring submission, the function first gets a reference to the
engine's legacy timeline and then allocates a VMA. If the VMA allocation
fails, e.g. when i915_vma_instance() called from inside is interrupted
with a signal, then ring_context_alloc() fails, leaving the timeline held
referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the
timeline is got, and only that last one is put on successful completion.
As a consequence, the legacy timeline, with its underlying engine status
page's VMA object, is still held and not released on driver unbind.
Get the legacy timeline only after successful allocation of the context
engine's VMA.
v2: Add a note on other submission methods (Krzysztof Karas):
Both execlists and GuC submission use lrc_alloc() which seems free
from a similar issue.
Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250611104352.1014011-2-janusz.krzysztofik@linux.intel.com
dt-bindings: display: vop2: Add optional PLL clock property for rk3576
As with the RK3588 SoC, RK3576 also allows the use of HDMI PHY PLL as an
alternative and more accurate pixel clock source for VOP2.
Document the optional PLL clock property.
Moreover, given that this is part of a series intended to address some
recent display problems, provide the appropriate tags to facilitate
backporting.
Lucas De Marchi [Fri, 27 Jun 2025 20:30:34 +0000 (13:30 -0700)]
drm/xe: Fix conflicting intel_pcode_* symbols
If CONFIG_DRM_XE_DISPLAY is set, the xe module can only be built as
module to avoid duplicate symbols from i915. The interface for pcode was
added without considering that, so the build breaks if both xe and i915
are built-in.
Since the intel_pcode_* functions should only be called from the display
side (xe side should call the xe interface directly) and there's already
a protection in Kconfig to avoid the problematic configuration, ifdef it
out in case CONFIG_DRM_XE_DISPLAY is disabled.
Closes: https://lore.kernel.org/r/3667a992-a24b-4e49-aab2-5ca73f2c0a56@infradead.org Fixes: d9465cc8ac2d ("drm/xe/pcode: add struct drm_device based interface") Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250627-xe-kunit-v2-1-756fe5cd56cf@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
MAINTAINERS: Add missing sysfb files to firmware framebuffers entry
The commit d391c5827107 ("drivers/firmware: move x86 Generic System
Framebuffers support") moved the sysfb*.c source files from arch/x86
to drivers/firmware, because the logic wasn't x86 specific and could
be used by other architectures.
But the drivers/firmware path is not listed in MAINTAINERS, which led
to the files being orphaned and scripts/get_maintainer.pl not listing
a mailing list to Cc anymore.
Now that we have an entry for all the firmware-provided framebuffer code,
add the missing sysfb files to make sure correct folks and list is Cc'ed.
Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Closes: https://lore.kernel.org/lkml/aF53djlieUNF_-aV@smile.fi.intel.com/ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250627113328.2703491-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Jacopo Mondi [Mon, 26 Feb 2024 13:25:43 +0000 (14:25 +0100)]
drm/fourcc: Add RGB161616 and BGR161616 formats
Add FourCC definitions for the 48-bit RGB/BGR formats to the
DRM/KMS uapi.
The format will be used by the Raspberry Pi PiSP Back End,
supported by a V4L2 driver in kernel space and by libcamera in
userspace, which uses the DRM FourCC identifiers.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
drm/format-helper: Split off byte swapping from drm_fb_xrgb8888_to_rgb565()
Move big-endian support from drm_fb_xrgb8888_to_rgb565() into the new
helper drm_xrgb8888_to_rgb565be(). The functionality is required for
displays with big-endian byte order. Update all callers.
With the change applied, drm_fb_xrgb8888_to_rgb565() has the same
signature as the other conversion functions, which is required for
further updates to drm_fb_blit(). Also makes the format-conversion
helper available to panic handlers, if necessary.
Ville Syrjälä [Tue, 24 Jun 2025 17:00:46 +0000 (20:00 +0300)]
drm/i915/flipq: Implement Wa_18034343758
Implement the driver side of Wa_18034343758, which is supposed to
prevent the DSB and DMC from accessing registers in parallel, and
thus potentially corrupting the registers due to a hardware issue
(which should be fixed in PTL-B0).
The w/a sequence goes as follows:
DMC starts the DSB
| \
DMC halts itself | DSB waits a while for DMC to have time to halt
. | DSB executes normally
. | DSB unhalts the DMC at the very end
. /
DMC resumes execution
v2: PTL-B0+ firmware no longer has the w/a since the hw got fixed
v3: Do the w/a on all PTL for now since we only have the A0 firmware
binaries which issues the halt instructions unconditionally
v4: PTL DMC binaries do in fact have the A0 vs. B0 split, so skip
the w/a on PTL-B0+
Ville Syrjälä [Tue, 24 Jun 2025 17:00:45 +0000 (20:00 +0300)]
drm/i915/flipq: Implement flip queue based commit path
Support commits via the flip queue (as opposed to DSB or MMIO).
As it's somewhat unknown if we can actually use it is currently
gated behind the new use_flipq modparam, which defaults to disabled.
The implementation has a bunch of limitations that would need
real though to solve:
- disabled when PSR is used
- disabled when VRR is used
- color management updates not performed via the flip queue
v2: Don't use flip queue if there is no dmc
v3: Use intel_flipq_supported()
v3: Configure PKG_C_LATENCY appropriately
Ignore INT_VECTOR if there is a real PIPEDMC interrupt
(nothing in the hw appears to clear INT_VECTOR)
v4: Leave added_wake_time=0 when flip queue isn't used, to
avoid needleslly increasing pkg_c_latency on lnl/ptl due
to Wa_22020432604. This is a bit racy though...
Use IS_DISPLAY_VER()
Ville Syrjälä [Tue, 24 Jun 2025 17:00:44 +0000 (20:00 +0300)]
drm/i915/flipq: Provide the nuts and bolts code for flip queue
Provide the lower level code for PIPEDMC based flip queue.
We'll use the so called semi-full flip queue mode where the
PIPEDMC will start the provided DSB on a scanline a little
ahead of the vblank. We need to program the triggering scanline
early enough so that the DSB has enough time to complete writing
all the double buffered registers before they get latched (at
start of vblank).
The firmware implements several queues:
- 3 "plane queues" which execute a single DSB per entry
- 1 "general queue" which can apparently execute 2 DSBs per entry
- 1 vestigial "fast queue" that replaced the "simple flip queue"
on ADL+, but this isn't supposed to be used due to issues.
But we only need a single plane queue really, and we won't actually
use it as a real queue because we don't allow queueing multiple commits
ahead of time. So the whole thing is perhaps useless. I suppose
there migth be some power saving benefits if we would get the flip
scheduled by userspace early and then could keep some hardware powered
off a bit longer until the DMC kicks off the flipq programming. But that
is pure speculation at this time and needs to be proven.
The code to hook up the flip queue into the actual atomic commit
path will follow later.
TODO: need to think how to do the "wait for DMC firmware load" nicely
need to think about VRR and PSR
etc.
v2: Don't write DMC_FQ_W2_PTS_CFG_SEL on pre-lnl
Don't oops at flipq init if there is no dmc
v3: Adapt to PTL+ flipq changes (different queue entry
layout, different trigger event, need VRR TG)
Use the actual CDCLK frequency
Ask the DSB code how long things are expected to take
v3: Adjust the cdclk rounding (docs are 100% vague, Windows
rounds like this)
Initialize some undocumented magic DMC variables on PTL
v4: Use PIPEDMC_FQ_STATUS for busy check (the busy bit in
PIPEDMC_FQ_CTRL is apparently gone on LNL+)
Based the preempt timeout on the max exec time
Preempt before disabling the flip queue
Order the PIPEDMC_SCANLINECMP* writes a bit more carefully
Fix some typos
v5: Try to deal with some clang-20 div-by-zero false positive (Nathan)
Add some docs (Jani)
Ville Syrjälä [Tue, 24 Jun 2025 17:00:43 +0000 (20:00 +0300)]
drm/i915/dmc: Define flip queue related PIPEDMC registers
Add the register definitions for a bunch of flip queue related
PIPEDMC registers.
v2: The layout of flip queue entries changed on PTL
Bump the DMC_FQ_W2_PTS_CFG_SEL bitfields sizes (Uma)
Reduce the scanlines to 21 bits for now (Uma)
v3: Also define some undocumented DMC variables we need on PTL
v3: Drop PIPEDMC_FQ_CTRL_BUSY as it seems to no longer exist
on LNL+
Fix up some typos
Ville Syrjälä [Tue, 24 Jun 2025 17:00:42 +0000 (20:00 +0300)]
drm/i915: Try to program PKG_C_LATENCY more correctly
The current PKG_C_LATENCY stuff looks busted in several ways:
- doesn't account for multiple pipes from different commits
correctly
- WM_LINETIME is in units of 0.125usec, PKG_C_LATENCY wants
units on 1 usec
- weird VRR state stuff being checked
- use of pointless RMW
Fix it all up. Note that it's still a bit unclear how all this
works, especially how the added_wake_time ties into the flipq
triggers in DMC, and how we need to sequence updates to
PKG_C_LATENCY when enabling/disabling pipes/etc. We may also
need to think what to about the WM1+ disabling and the related
PSR chicken bits when we can use PKG_C_LATENCY for early wake...
Hans de Goede [Thu, 26 Jun 2025 14:33:17 +0000 (16:33 +0200)]
drm/i915/dsi: Fix NULL pointer deref in vlv_dphy_param_init()
Commit 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct
intel_display") added a to_intel_display(connector) call to
vlv_dphy_param_init() but when vlv_dphy_param_init() gets called
the connector object has not been initialized yet, so this leads
to a NULL pointer deref:
Use to_intel_display(&intel_dsi->base) instead to fix this.
Fixes: 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250626143317.101706-1-hansg@kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:19 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support for 4-tiling with DPT
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements 4-Tiling support, to still be able to draw
the panic screen.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:18 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support for Y-tiling with DPT
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements Y-Tiling support, to still be able to draw
the panic screen.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:17 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, Raptor Lake, and Lunar Lake.
For hardware using DPT, it's not possible to disable tiling, as you
will need to reconfigure the way the GPU is accessing the
framebuffer, so this will be handled by the following patches.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:16 +0000 (11:01 +0200)]
drm/i915: Add intel_bo_panic_setup() and intel_bo_panic_finish()
Implement both functions for i915 and xe, they prepare the work for
drm_panic support.
They both use kmap_try_from_panic(), and map one page at a time, to
write the panic screen on the framebuffer.
projects / thirdparty / linux.git / log
