summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-04-10drm/msm/dpu: Fix error pointers in dpu_plane_virtual_atomic_checkChenyuan Yang1-0/+3
The function dpu_plane_virtual_atomic_check was dereferencing pointers returned by drm_atomic_get_plane_state without checking for errors. This could lead to undefined behavior if the function returns an error pointer. This commit adds checks using IS_ERR to ensure that plane_state is valid before dereferencing them. Similar to commit da29abe71e16 ("drm/amd/display: Fix error pointers in amdgpu_dm_crtc_mem_type_changed"). Fixes: 774bcfb73176 ("drm/msm/dpu: add support for virtual planes") Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/643132/ Link: https://lore.kernel.org/r/20250314011004.663804-1-chenyuan0y@gmail.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2025-04-10drm/msm/dpu: check every pipe per capabilityJun Nie1-35/+36
The capability stored in sblk and pipe_hw_caps is checked only for SSPP of the first pipe in the pair with current implementation. That of the 2nd pipe, r_pipe, is not checked and may violate hardware capability. Move requirement check to dpu_plane_atomic_check_pipe() for the check of every pipe. Fixes: ("dbbf57dfd04e6 drm/msm/dpu: split dpu_plane_atomic_check()") Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/640513/ Link: https://lore.kernel.org/r/20250303-sm8650-v6-14-hmd-deckard-mdss-quad-upstream-oldbootwrapper-36-prep-v8-1-eb5df105c807@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2025-04-10drm/v3d: Fix Indirect Dispatch configuration for V3D 7.1.6 and laterMaíra Canal1-3/+13
This commit is a resubmission of commit 1fe1c66274fb ("drm/v3d: Fix Indirect Dispatch configuration for V3D 7.1.6 and later"), which was accidentally reverted by commit 91dae758bdb8 ("Merge tag 'drm-misc-next-2024-08-01' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next"), likely due to an unfortunate conflict resolution. From the original commit message: ``` `args->cfg[4]` is configured in Indirect Dispatch using the number of batches. Currently, for all V3D tech versions, `args->cfg[4]` equals the number of batches subtracted by 1. But, for V3D 7.1.6 and later, we must not subtract 1 from the number of batches. Implement the fix by checking the V3D tech version and revision. Fixes several `dEQP-VK.synchronization*` CTS tests related to Indirect Dispatch. ``` Fixes: 91dae758bdb8 ("Merge tag 'drm-misc-next-2024-08-01' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://lore.kernel.org/r/20250409205051.9639-1-mcanal@igalia.com
2025-04-10drm/i915: Simplify combo PLL frac w/aVille Syrjälä1-5/+2
We are applying the combo PLL frac w/a to all TGL+ platforms, except RKL. I *think* all RKL machines use a 24 MHz refclk (certainly all machines in our CI do) and so technically never need the adjustment. But let's assume the hardware is exactly the same anyway and simplify the code by applying the w/a to all TGL+ platforms. v2: Keep the 38.4 MHz check Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250402171720.9350-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2025-04-10drm/i915: Apply the combo PLL frac w/a on DG1Ville Syrjälä1-0/+1
DG1 apparently needs the combo PLL fractional divider w/a with 38.4 MHz refclk as well. This isn't listed in bspec, but looking at the hsd it looks like it was possibly just missed due to no one having a DG1 around at the time. This gives us slightly more accurate clocks on DG1. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250401163752.6412-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2025-04-10drm/panel: simple: Add NLT NL13676BC25-03F panel entryAntonin Godard1-0/+27
Add support for the NLT NL13676BC25-03F 15.6" LCD-TFT LVDS panel. Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250318-b4-add-nlt-nl13676bc25-03f-v1-2-67e0f8cf2e6f@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-04-10drm/panthor: Don't update MMU_INT_MASK in panthor_mmu_irq_handler()Boris Brezillon1-1/+0
Interrupts are automatically unmasked in panthor_mmu_irq_threaded_handler() when the handler returns. Unmasking prematurely might generate spurious interrupts if the IRQ line is shared. Changes in v2: - New patch Changes in v3: - Add R-bs Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250404080933.2912674-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-10drm/panthor: Let IRQ handlers clear the interrupts themselvesBoris Brezillon4-2/+11
MMU handler needs to be in control of the job interrupt clears because clearing the interrupt also unblocks the writer/reader that triggered the fault, and we don't want it to be unblocked until we've had a chance to process the IRQ. Since clearing the clearing is just one line, let's make it explicit instead of doing it in the generic code path. Note that this commit changes the existing behavior in that the MMU COMPLETED irqs are no longer cleared, which is fine because they are masked, so we're not risking an interrupt flood. Changes in v3: - Mention the fact we no longer clear MMU COMPLETED irqs - Add Liviu's R-b Changes in v2: - Move the MMU_INT_CLEAR around Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250404080933.2912674-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-10drm/panthor: Update panthor_mmu::irq::mask when neededBoris Brezillon1-0/+1
When we clear the faulty bits in the AS mask, we also need to update the panthor_mmu::irq::mask field otherwise our IRQ handler won't get called again until the GPU is reset. Changes in v2: - Add Liviu's R-b Changes in v3: - Add Steve's R-b Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250404080933.2912674-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-10drm/panthor: Call panthor_gpu_coherency_init() after PM resume()Boris Brezillon1-4/+4
When the device is coherent, panthor_gpu_coherency_init() will read GPU_COHERENCY_FEATURES to make sure the GPU supports the ACE-Lite coherency protocol, which will fail if the clocks/power-domains are not enabled when the read is done. Move the panthor_gpu_coherency_init() call after the device has been resumed to prevent that. Changes in v2: - Add Liviu's R-b Changes in v3: - Add Steve's R-b Fixes: dd7db8d911a1 ("drm/panthor: Explicitly set the coherency mode") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250404080933.2912674-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-10drm/panthor: Fix GPU_COHERENCY_ACE[_LITE] definitionsBoris Brezillon1-2/+2
GPU_COHERENCY_ACE and GPU_COHERENCY_ACE_LITE definitions have been swapped. Changes in v2: - New patch Changes in v3: - Add Steve's R-b Reported-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: 546b366600ef ("drm/panthor: Add GPU register definitions") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250404080933.2912674-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-10drm: Mark CONFIG_DRM_HEADER_TEST as BROKENThomas Zimmermann1-1/+1
The flag got lost during a merge. Add it back. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Simona Vetter <simona@ffwll.ch> Closes: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2025-04-10&show_html=true Fixes: 1afba39f9305 ("Merge drm/drm-next into drm-misc-next") Acked-by: Simona Vetter <simona@ffwll.ch> Link: https://lore.kernel.org/r/20250410095014.20471-1-tzimmermann@suse.de
2025-04-10x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'Ingo Molnar1-2/+2
Suggested-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Juergen Gross <jgross@suse.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Xin Li <xin@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-10drm/rockchip: dw_hdmi_qp: Fix io init for dw_hdmi_qp_rockchip_resumeAndy Yan1-20/+3
Use cfg->ctrl_ops->io_init callback make it work for all platform. And it's also gets rid of code duplication Fixes: 3f60dbd40d3f ("drm/rockchip: dw_hdmi_qp: Add platform ctrl callback") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250317102757.565679-1-andyshrk@163.com
2025-04-10drm/panic: Add support to scanout buffer as array of pagesJocelyn Falempe1-6/+136
Some drivers like virtio-gpu, don't map the scanout buffer in the kernel. Calling vmap() in a panic handler is not safe, and writing an atomic_vmap() API is more complex than expected [1]. So instead, pass the array of pages of the scanout buffer to the panic handler, and map only one page at a time to draw the pixels. This is obviously slow, but acceptable for a panic handler. [1] https://lore.kernel.org/dri-devel/20250305152555.318159-1-ryasuoka@redhat.com/ Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Simona Vetter <simona@ffwll.ch> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250407140138.162383-3-jfalempe@redhat.com
2025-04-10drm/rockchip: vop2: Fix interface enable/mux setting of DP1 on rk3588Andy Yan1-3/+3
This is a copy-paste error, which affects DP1 usage. Fixes: 328e6885996c ("drm/rockchip: vop2: Add platform specific callback") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250312064218.524143-1-andyshrk@163.com
2025-04-10drm/rockchip: vop: Consistently use rk3399 registers constsKonstantin Shabanov1-47/+47
As rk3399 has its own registers definitions, update related structs to use them. There are no changes in behaviour as updated constants values are the for rk3288/rk3368/rk3399 chips. Signed-off-by: Konstantin Shabanov <mail@etehtsea.me> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250403064740.4016-1-mail@etehtsea.me
2025-04-10drm/rockchip: vop2: Make overlay layer select register configuration take ↵Andy Yan2-1/+5
effect by vsync Because the layer/window enable/disable is take effect by vsync, if the overlay configuration of these layers does not follow vsync and takes effect immediately instead, when multiple layers are dynamically enable/disable, inconsistent display contents may be seen on the screen. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250318062024.4555-1-andyshrk@163.com
2025-04-10drm/rockchip: vop: remove redundant condition checkLucas Stach1-3/+2
Instead of checking the same thing twice in a row, fold the second condition into the first clause. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Andy Yan <andyshrk@163.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250207182247.215537-1-l.stach@pengutronix.de
2025-04-10Merge tag 'amd-drm-fixes-6.15-2025-04-09' of ↵Dave Airlie20-36/+187
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.15-2025-04-09: amdgpu: - MES FW version caching fixes - Only use GTT as a fallback if we already have a backing store - dma_buf fix - IP discovery fix - Replay and PSR with VRR fix - DC FP fixes - eDP fixes - KIQ TLB invalidate fix - Enable dmem groups support - Allow pinning VRAM dma bufs if imports can do P2P - Workload profile fixes - Prevent possible division by 0 in fan handling amdkfd: - Queue reset fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250409165238.1180153-1-alexander.deucher@amd.com
2025-04-10drm/xe: Add page queue multiplierMatthew Brost1-2/+9
For an unknown reason the math to determine the PF queue size does is not correct - compute UMD applications are overflowing the PF queue which is fatal. A multippier of 8 fixes the problem. Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com> Link: https://lore.kernel.org/r/20250408155915.78770-1-matthew.brost@intel.com
2025-04-10drm/xe: remove unused LE_COSShuicheng Lin1-1/+0
The LE_COS definition missed passing the value parameter to REG_FIELD_PREP. This didn't cause build errors because the entire macro was unused. The value for this field is universally "0" for every MOCS entry on the old Xe_LP platforms, and the whole field has been removed from Xe_HP onward. Just delete the line so that we don't have an unused definition. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250405171539.599850-1-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-04-09drm/amdgpu/mes12: optimize MES pipe FW version fetchingAlex Deucher1-9/+12
Don't fetch it again if we already have it. It seems the registers don't reliably have the value at resume in some cases. Fixes: 785f0f9fe742 ("drm/amdgpu: Add mes v12_0 ip block support (v4)") Reviewed-by: Shaoyun.liu <Shaoyun.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9e7b08d239c2f21e8f417854f81e5ff40edbebff) Cc: stable@vger.kernel.org # 6.12.x
2025-04-09drm/amd/pm/smu11: Prevent division by zeroDenis Arefev1-1/+1
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1e866f1fe528 ("drm/amd/pm: Prevent divide by zero") Signed-off-by: Denis Arefev <arefev@swemel.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71) Cc: stable@vger.kernel.org
2025-04-09drm/amdgpu: cancel gfx idle work in device suspend for s0ixAlex Deucher1-0/+7
This is normally handled in the gfx IP suspend callbacks, but for S0ix, those are skipped because we don't want to touch gfx. So handle it in device suspend. Fixes: b9467983b774 ("drm/amdgpu: add dynamic workload profile switching for gfx10") Fixes: 963537ca2325 ("drm/amdgpu: add dynamic workload profile switching for gfx11") Fixes: 5f95a1549555 ("drm/amdgpu: add dynamic workload profile switching for gfx12") Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 906ad451675155380c1dc1881a244ebde8e8df0a) Cc: stable@vger.kernel.org
2025-04-09drm/amd/display: pause the workload setting in dmKenneth Feng1-1/+10
Pause the workload setting in dm when doing idle optimization Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b23f81c442ac33af0c808b4bb26333b881669bb7)
2025-04-09drm/amdgpu/pm/swsmu: implement pause workload profileAlex Deucher2-1/+36
Add the callback for implementation for swsmu. Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 92e511d1cecc6a8fa7bdfc8657f16ece9ab4d456)
2025-04-09drm/amdgpu/pm: add workload profile pause helperAlex Deucher3-0/+22
To be used for display idle optimizations when we want to pause non-default profiles. Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6dafb5d4c7cdfc8f994e789d050e29e0d5ca6efd)
2025-04-09drm/i915/wm: convert i9xx_wm.c internally to struct intel_displayJani Nikula1-425/+397
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of i9xx_wm.c to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/bbee93f837fe7fedfd1627ff6fa295da8881df8d.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert i9xx_wm.c to intel_de_*() register interfaceJani Nikula1-187/+196
The registers handled in i9xx_wm.c are mostly display registers. The MCH_SSKPD and MLTR_ILK registers are not. Convert register access to intel_de_*() interface where applicaple. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/68367382759570413669d5648895a1da8f6c68f7.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert i9xx_wm.h external interfaces to struct intel_displayJani Nikula5-32/+37
Going forward, struct intel_display is the main display device data pointer. Convert the i9xx_wm.h interface to struct intel_display. With this, we can make intel_wm.c independent of i915_drv.h. v2: Also remove i915_drv.h, fix commit message Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/3e30634d85c0e0aac9c95f9a2f928131ba400271.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert skl_watermarks.c internally to struct intel_displayJani Nikula1-286/+250
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of skl_watermarks.c to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/61ae2013c5db962e90e072be7d37d630cb7dfc34.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert skl_watermark.h external interfaces to struct intel_displayJani Nikula10-92/+90
Going forward, struct intel_display is the main display device data pointer. Convert the skl_watermark.h interface to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/cd2b1863dee25b69b4766090dd183a7467c4edea.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert intel_wm.c internally to struct intel_displayJani Nikula1-61/+61
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_wm.c to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/6106c0313190ee904c7f7737d0b78b61983eed91.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert intel_wm.h external interfaces to struct intel_displayJani Nikula9-68/+80
Going forward, struct intel_display is the main display device data pointer. Convert the intel_wm.h interface as well as the hooks in struct intel_wm_funcs to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/1085900b4e46bbb514e6918c321639ac380331ce.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/dsi: unify naming and simplify checks for dphy paramsJani Nikula1-60/+22
Unify the naming of the data and clock lane timing parameters, and simplify their bounds checks. Drop the debug messages on out of bounds parameters as excessive. Clarify the comment while at it. Cc: William Tseng <william.tseng@intel.com> Reviewed-by: William Tseng <william.tseng@intel.com> Tested-by: William Tseng <william.tseng@intel.com> Link: https://lore.kernel.org/r/d1a75ae7b9d93a0b50976b5de45ba2ca798991ad.1743682608.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/dsi: separate clock and data lane prepare timingJani Nikula1-8/+8
The history of why the max of VBT clock and data lane prepare timing parameter is used for both instead of each individually is unknown. Separate them to follow what the Windows driver does. Cc; William Tseng <william.tseng@intel.com> Reviewed-by: William Tseng <william.tseng@intel.com> Tested-by: William Tseng <william.tseng@intel.com> Link: https://lore.kernel.org/r/079a26d0aae79f299aee0397dad2d6519cd55071.1743682608.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/huc: Fix fence not released on early probe errorsJanusz Krzysztofik3-6/+7
HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. Fixes: 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13592 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20250402172057.209924-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/vrr: Add vrr.vsync_{start, end} in vrr_params_changedAnkit Nautiyal1-1/+3
Add the missing vrr parameters in vrr_params_changed() helper. This ensures that changes in vrr.vsync_{start,end} trigger a call to appropriate helpers to update the VRR registers. Fixes: e8cd188e91bb ("drm/i915/display: Compute vrr_vsync params") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250404080540.2059511-1-ankit.k.nautiyal@intel.com (cherry picked from commit ced5e64f011cb5cd541988442997ceaa7385827e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/sysfb: efidrm: Support module buildsThomas Zimmermann1-2/+2
Make CONFIG_DRM_EFIDRM a tristate to enable module builds. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250408091837.407401-3-tzimmermann@suse.de
2025-04-09drm/xe: Enable configfs support for survivability modeRiana Tauro6-19/+108
Enable survivability mode if supported and configfs attribute is set. Enabling survivability mode manually is useful in cases where pcode does not detect failure, validation and for IFR (in-field-repair). To set configfs survivability mode attribute for a device echo 1 > /sys/kernel/config/xe/0000:03:00.0/survivability_mode The card enters survivability mode if supported v2: add a log if survivability mode is enabled for unsupported platforms (Rodrigo) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250407051414.1651616-4-riana.tauro@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-04-09drm/xe: Add documentation for survivability modeRiana Tauro1-11/+23
Add survivability mode document to pcode document as it is enabled when pcode detects a failure. v2: fix kernel-doc (Lucas) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250407051414.1651616-3-riana.tauro@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-04-09drm/xe: Add configfs to enable survivability modeRiana Tauro4-0/+210
Registers a configfs subsystem called 'xe' that creates a directory in the mounted configfs directory (/sys/kernel/config) Userspace can then create the device that has to be configured under the xe directory mkdir /sys/kernel/config/xe/0000:03:00.0 The device created will have the following attributes to be configured /sys/kernel/config/xe/ .. 0000:03:00.0/ ... survivability_mode v2: fix kernel-doc fix return value (Lucas) v3: fix kernel-doc (Lucas) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250407051414.1651616-2-riana.tauro@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-04-08drm/amdgpu/sdma7: add support for disable_kqAlex Deucher1-0/+4
When the parameter is set, disable user submissions to kernel queues. Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/sdma6: add support for disable_kqAlex Deucher1-0/+4
When the parameter is set, disable user submissions to kernel queues. Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/sdma: add flag for tracking disable_kqAlex Deucher1-0/+1
For SDMA, we still need kernel queues for paging so they need to be initialized, but we no not want to accept submissions from userspace when disable_kq is set. Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/gfx12: add support for disable_kqAlex Deucher1-53/+114
Plumb in support for disabling kernel queues. v2: use ring counts per Felix' suggestion v3: fix stream fault handler, enable EOP interrupts v4: fix MEC interrupt offset (Sunil) v5: clean up after removing extra sched.ready settings Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/gfx11: add support for disable_kqAlex Deucher1-55/+136
Plumb in support for disabling kernel queues in GFX11. We have to bring up a GFX queue briefly in order to initialize the clear state. After that we can disable it. v2: use ring counts per Felix' suggestion v3: fix stream fault handler, enable EOP interrupts v4: fix MEC interrupt offset (Sunil) Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/mes: make more vmids available when disable_kq=1Alex Deucher3-3/+3
If we don't have kernel queues, the vmids can be used by the MES for user queues. Acked-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-04-08drm/amdgpu/mes: update hqd masks when disable_kq is setAlex Deucher1-3/+3
Make all resources available to user queues. Reviewed-by: Prike Liang <Prike.Liang@amd.com> Suggested-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>