aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-09-02drm/i915/hdcp: migrate away from kdev_to_i915() in bind/unbindJani Nikula1-4/+6
Use to_intel_display() instead of kdev_to_i915() in the HDCP component API hooks. Avoid further drive-by changes at this point, and just convert the display pointer to i915, and leave the struct intel_display conversion for later. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0beedaa438e912828b48d9980f017807e079d7ab.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-09-02drm/i915/audio: migrate away from kdev_to_i915()Jani Nikula1-13/+21
Use to_intel_display() instead of kdev_to_i915() in the audio component API hooks. Avoid further drive-by changes at this point, and just convert the display pointer to i915, and leave the struct intel_display conversion for later. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/35ef00470db0088eb82b0406e4f7730154f54baf.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-09-02drm/i915: support struct device and pci_dev in to_intel_display()Jani Nikula1-1/+7
Now that both xe and i915 store struct drm_device in drvdata, we can trivially support struct device and struct pci_dev in to_intel_display(). We do need to check for NULL drvdata before converting it into struct intel_device pointer, though. Do it in __drm_device_to_intel_display(). v2: Add NULL check in __drm_device_to_intel_display() (Gustavo) Reviewed-by: Gustavo Sousa <[email protected]> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/f025a3fa4422725c78baac4501ad3ecc9e5b40d5.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-09-02drm/i915 & drm/xe: save struct drm_device to drvdataJani Nikula6-8/+18
In the future, the display code shall not have any idea about struct xe_device or struct drm_i915_private, but will need to get at the struct drm_device via drvdata. Store the struct drm_device pointer to drvdata instead of the driver specific pointer. Avoid passing NULL to container_of() via to_i915()/to_xe_device(). (It does return NULL for NULL pointers when the offset happens to be 0, but otherwise returns garbage pointers for NULL.) Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/946805b32e38d4785880cc7857e01e6a309126a9.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-09-02drm/i915/fence: Mark debug_fence_free() with __maybe_unusedAndy Shevchenko1-2/+2
When debug_fence_free() is unused (CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:118:20: error: unused function 'debug_fence_free' [-Werror,-Wunused-function] 118 | static inline void debug_fence_free(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~ Fix this by marking debug_fence_free() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: fc1584059d6c ("drm/i915: Integrate i915_sw_fence with debugobjects") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]> (cherry picked from commit 8be4dce5ea6f2368cc25edc71989c4690fa66964) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-09-02drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unusedAndy Shevchenko1-2/+2
When debug_fence_init_onstack() is unused (CONFIG_DRM_I915_SELFTEST=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:97:20: error: unused function 'debug_fence_init_onstack' [-Werror,-Wunused-function] 97 | static inline void debug_fence_init_onstack(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking debug_fence_init_onstack() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 214707fc2ce0 ("drm/i915/selftests: Wrap a timer into a i915_sw_fence") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]> (cherry picked from commit 5bf472058ffb43baf6a4cdfe1d7f58c4c194c688) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-09-02drm/i915: Fix readout degamma_lut mismatch on ilk/snbVille Syrjälä1-5/+26
On ilk/snb the pipe may be configured to place the LUT before or after the CSC depending on various factors, but as there is only one LUT (no split mode like on IVB+) we only advertise a gamma_lut and no degamma_lut in the uapi to avoid confusing userspace. This can cause a problem during readout if the VBIOS/GOP enabled the LUT in the pre CSC configuration. The current code blindly assigns the results of the readout to the degamma_lut, which will cause a failure during the next atomic_check() as we aren't expecting anything to be in degamma_lut since it's not visible to userspace. Fix the problem by assigning whatever LUT we read out from the hardware into gamma_lut. Cc: [email protected] Fixes: d2559299d339 ("drm/i915: Make ilk_read_luts() capable of degamma readout") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11608 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]> (cherry picked from commit 33eca84db6e31091cef63584158ab64704f78462) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-09-02drm/i915: Do not attempt to load the GSC multiple timesDaniele Ceraolo Spurio2-1/+6
If the GSC FW fails to load the GSC HW hangs permanently; the only ways to recover it are FLR or D3cold entry, with the former only being supported on driver unload and the latter only on DGFX, for which we don't need to load the GSC. Therefore, if GSC fails to load there is no need to try again because the HW is stuck in the error state and the submission to load the FW would just hang the GSCCS. Note that, due to wa_14015076503, on MTL the GuC escalates all GSCCS hangs to full GT resets, which would trigger a new attempt to load the GSC FW in the post-reset HW re-init; this issue is also fixed by not attempting to load the GSC FW after an error. Fixes: 15bd4a67e914 ("drm/i915/gsc: GSC firmware loading") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: <[email protected]> # v6.3+ Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 03ded4d432a1fb7bb6c44c5856d14115f6f6c3b9) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-09-02drm/imagination: Free pvr_vm_gpuva after unlinkMatt Coster1-0/+4
This caused a measurable memory leak. Although the individual allocations are small, the leaks occurs in a high-usage codepath (remapping or unmapping device memory) so they add up quickly. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Cc: [email protected] Reviewed-by: Frank Binns <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Matt Coster <[email protected]>
2024-09-02drm/i915/fence: Mark debug_fence_free() with __maybe_unusedAndy Shevchenko1-2/+2
When debug_fence_free() is unused (CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:118:20: error: unused function 'debug_fence_free' [-Werror,-Wunused-function] 118 | static inline void debug_fence_free(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~ Fix this by marking debug_fence_free() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: fc1584059d6c ("drm/i915: Integrate i915_sw_fence with debugobjects") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-09-02drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unusedAndy Shevchenko1-2/+2
When debug_fence_init_onstack() is unused (CONFIG_DRM_I915_SELFTEST=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:97:20: error: unused function 'debug_fence_init_onstack' [-Werror,-Wunused-function] 97 | static inline void debug_fence_init_onstack(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking debug_fence_init_onstack() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 214707fc2ce0 ("drm/i915/selftests: Wrap a timer into a i915_sw_fence") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-09-01drm/xe: clean up fault injection usageJani Nikula2-14/+3
With the proper stubs in place in linux/fault-inject.h, we can remove a bunch of conditional compilation for CONFIG_FAULT_INJECTION=n. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Cc: Akinobu Mita <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Rob Clark <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01drm/msm: clean up fault injection usageJani Nikula3-8/+0
With the proper stubs in place in linux/fault-inject.h, we can remove a bunch of conditional compilation for CONFIG_FAULT_INJECTION=n. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Cc: Akinobu Mita <[email protected]> Cc: Rob Clark <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01fault-inject: improve build for CONFIG_FAULT_INJECTION=nJani Nikula1-0/+1
The fault-inject.h users across the kernel need to add a lot of #ifdef CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make fault-inject.h self-contained for CONFIG_FAULT_INJECTION=n, and add stubs for DECLARE_FAULT_ATTR(), setup_fault_attr(), should_fail_ex(), and should_fail() to allow removal of conditional compilation. [[email protected]: repair fallout from no longer including debugfs.h into fault-inject.h] [[email protected]: fix drivers/misc/xilinx_tmr_inject.c] [[email protected]: Add debugfs.h inclusion to more files, per Stephen] Link: https://lkml.kernel.org/r/[email protected] Fixes: 6ff1cb355e62 ("[PATCH] fault-injection capabilities infrastructure") Signed-off-by: Jani Nikula <[email protected]> Cc: Akinobu Mita <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: kvmalloc: align kvrealloc() with krealloc()Danilo Krummrich1-2/+1
Besides the obvious (and desired) difference between krealloc() and kvrealloc(), there is some inconsistency in their function signatures and behavior: - krealloc() frees the memory when the requested size is zero, whereas kvrealloc() simply returns a pointer to the existing allocation. - krealloc() behaves like kmalloc() if a NULL pointer is passed, whereas kvrealloc() does not accept a NULL pointer at all and, if passed, would fault instead. - krealloc() is self-contained, whereas kvrealloc() relies on the caller to provide the size of the previous allocation. Inconsistent behavior throughout allocation APIs is error prone, hence make kvrealloc() behave like krealloc(), which seems superior in all mentioned aspects. Besides that, implementing kvrealloc() by making use of krealloc() and vrealloc() provides oppertunities to grow (and shrink) allocations more efficiently. For instance, vrealloc() can be optimized to allocate and map additional pages to grow the allocation or unmap and free unused pages to shrink the allocation. [[email protected]: document concurrency restrictions] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: disable KASAN when switching to vmalloc] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: properly document __GFP_ZERO behavior] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Christian König <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Hyeonggon Yoo <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kees Cook <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Uladzislau Rezki <[email protected]> Cc: Wedson Almeida Filho <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-02drm/msm/dpu: enable writeback on SM6350Dmitry Baryshkov1-0/+18
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: Luca Weiss <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570194/ Link: https://lore.kernel.org/r/[email protected]
2024-09-02drm/msm/dpu: enable writeback on SM6125Dmitry Baryshkov1-0/+18
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570193/ Link: https://lore.kernel.org/r/[email protected]
2024-09-02drm/msm/dpu: enable writeback on SC8108XDmitry Baryshkov1-0/+18
Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570196/ Link: https://lore.kernel.org/r/[email protected]
2024-09-02drm/msm/dpu: enable writeback on SM8150Dmitry Baryshkov2-2/+22
Enable WB2 hardware block, enabling writeback support on this platform. Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570192/ Link: https://lore.kernel.org/r/[email protected] [DB: picked up WB_SDM845_MASK from sdm845 patch] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-09-02drm/msm: fix %s null argument errorSherry Yang1-1/+1
The following build error was triggered because of NULL string argument: BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function 'mdp5_smp_dump': BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=] BUILDSTDERR: 352 | drm_printf(p, "%s:%d\t%d\t%s\n", BUILDSTDERR: | ^~ BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=] This happens from the commit a61ddb4393ad ("drm: enable (most) W=1 warnings by default across the subsystem"). Using "(null)" instead to fix it. Fixes: bc5289eed481 ("drm/msm/mdp5: add debugfs to show smp block status") Signed-off-by: Sherry Yang <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611071/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-09-02drm/msm/dsi: correct programming sequence for SM8350 / SM8450Dmitry Baryshkov1-1/+11
According to the display-drivers, 5nm DSI PLL (v4.2, v4.3) have different boundaries for pll_clock_inverters programming. Follow the vendor code and use correct values. Fixes: 2f9ae4e395ed ("drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/606947/ Link: https://lore.kernel.org/r/[email protected]
2024-09-02drm/msm/dp: enable widebus on all relevant chipsetsAbhinav Kumar1-5/+5
Hardware document indicates that widebus is recommended on DP on all MDSS chipsets starting version 5.x.x and above. Follow the guideline and mark widebus support on all relevant chipsets for DP. Fixes: 766f705204a0 ("drm/msm/dp: Remove now unused connector_type from desc") Fixes: 1b2d98bdd7b7 ("drm/msm/dp: Add DisplayPort controller for SM8650") Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Fixes: 757a2f36ab09 ("drm/msm/dp: enable widebus feature for display port") Fixes: 1b2d98bdd7b7 ("drm/msm/dp: Add DisplayPort controller for SM8650") Patchwork: https://patchwork.freedesktop.org/patch/606556/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-09-02drm/msm: add msm8998 hdmi phy/pll supportArnaud Vrac5-0/+882
Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC. This code is mostly copy & paste of the vendor code from msm-4.4 kernel.lnx.4.4.r38-rel. Signed-off-by: Arnaud Vrac <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marc Gonzalez <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/605631/ Link: https://lore.kernel.org/r/[email protected] [DB: replaced division with do_div64 to fix build issues on ARM32] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-09-02drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatibleMarc Gonzalez1-0/+1
Current driver already supports the msm8998 HDMI TX. We just need to add the compatible string. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Marc Gonzalez <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/605632/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-09-02drm/msm/dpu: Configure DP INTF/PHY selectorDmitry Baryshkov4-6/+72
Some platforms provides a mechanism for configuring the mapping between (one or two) DisplayPort intfs and their PHYs. In particular SC8180X requires this to be configured, since on this platform there are fewer controllers than PHYs. The change implements the logic for optionally configuring which PHY each of the DP INTFs should be connected to and marks the SC8180X DPU to program 2 entries. For now the request is simply to program the mapping 1:1, any support for alternative mappings is left until the use case arrise. Note that e.g. msm-4.14 unconditionally maps INTF 0 to PHY 0 on all platforms, so perhaps this is needed in order to get DisplayPort working on some other platforms as well. Co-developed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/600895/ Link: https://lore.kernel.org/r/[email protected]
2024-09-01drm/msm/adreno: Add A306A supportOtto Pflüger3-3/+28
Add support for Adreno 306A GPU what is found in MSM8917 SoC. This GPU marketing name is Adreno 308. Signed-off-by: Otto Pflüger <[email protected]> [use internal name of the GPU, reword the commit message] Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Barnabás Czémán <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/605403/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Add A621 supportKonrad Dybcio4-1/+106
A621 is a clear A662 derivative (same lineage as A650), no explosions or sick features, other than a NoC bug which can stall the GPU.. Add support for it. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611100/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Set GMU CGC properties on a6xx tooKonrad Dybcio3-10/+17
This was apparently never done before.. Program the expected values. This also gets rid of sneakily setting that register through the HWCG reg list on A690. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611098/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Use the per-GPU value for gmu_cgc_modeKonrad Dybcio1-4/+2
This register's magic value differs wildly between different GPUs, use the hardcoded data instead of trying to make some logic out of it. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611096/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Store correct gmu_cgc_mode in struct a6xx_infoKonrad Dybcio2-0/+20
Store the correct values that we happen to have for some A7xx SKUs in the GPU info struct and fill out the missing information for A6xx GPUs based on downstream kernel information. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611094/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Store primFifoThreshold in struct a6xx_infoKonrad Dybcio3-19/+21
The if-else monster is so unmaintainable that one case is repeated twice. Get rid of it. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/611092/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a6xx: Evaluate adreno_is_a650_family in pdc_in_aop checkKonrad Dybcio1-2/+1
A650 family includes A660 family (they've got a big family), A650 itself, and some more A6XX_GEN3 SKUs, all of which should fall into the same branch of the if-condition. Simplify that. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/605206/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a5xx: workaround early ring-buffer emptiness checkVladimir Lypak3-0/+9
There is another cause for soft lock-up of GPU in empty ring-buffer: race between GPU executing last commands and CPU checking ring for emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS event and RPTR shadow (which is used to check ring emptiness) is updated a bit later from CP_CONTEXT_SWITCH_YIELD. Thus if GPU is executing its last commands slow enough or we check that ring too fast we will miss a chance to trigger switch to lower priority ring because current ring isn't empty just yet. This can escalate to lock-up situation described in previous patch. To work-around this issue we keep track of last submit sequence number for each ring and compare it with one written to memptrs from GPU during execution of CACHE_FLUSH_TS event. Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/612047/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a5xx: fix races in preemption evaluation stageVladimir Lypak2-2/+23
On A5XX GPUs when preemption is used it's invietable to enter a soft lock-up state in which GPU is stuck at empty ring-buffer doing nothing. This appears as full UI lockup and not detected as GPU hang (because it's not). This happens due to not triggering preemption when it was needed. Sometimes this state can be recovered by some new submit but generally it won't happen because applications are waiting for old submits to retire. One of the reasons why this happens is a race between a5xx_submit and a5xx_preempt_trigger called from IRQ during submit retire. Former thread updates ring->cur of previously empty and not current ring right after latter checks it for emptiness. Then both threads can just exit because for first one preempt_state wasn't NONE yet and for second one all rings appeared to be empty. To prevent such situations from happening we need to establish guarantee for preempt_trigger to make decision after each submit or retire. To implement this we serialize preemption initiation using spinlock. If switch is already in progress we need to re-trigger preemption when it finishes. Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/612045/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a5xx: properly clear preemption records on resumeVladimir Lypak1-0/+2
Two fields of preempt_record which are used by CP aren't reset on resume: "data" and "info". This is the reason behind faults which happen when we try to switch to the ring that was active last before suspend. In addition those faults can't be recovered from because we use suspend and resume to do so (keeping values of those fields again). Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/612043/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/a5xx: disable preemption in submits by defaultVladimir Lypak1-2/+6
Fine grain preemption (switching from/to points within submits) requires extra handling in command stream of those submits, especially when rendering with tiling (using GMEM). However this handling is missing at this point in mesa (and always was). For this reason we get random GPU faults and hangs if more than one priority level is used because local preemption is enabled prior to executing command stream from submit. With that said it was ahead of time to enable local preemption by default considering the fact that even on downstream kernel it is only enabled if requested via UAPI. Fixes: a7a4c19c36de ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register") Signed-off-by: Vladimir Lypak <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/612041/ Signed-off-by: Rob Clark <[email protected]>
2024-09-01drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsKonrad Dybcio2-1/+1
There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/602742/ Signed-off-by: Rob Clark <[email protected]>
2024-08-31nouveau: fix the fwsec sb verification register.Dave Airlie1-1/+1
This aligns with what open gpu does, the 0x15 hex is just to trick you. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Reviewed-by: Ben Skeggs <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-30drm/xe: Invalidate media_gt TLBs in PT codeMatthew Brost1-21/+96
Testing on LNL has shown media GT's TLBs need to be invalidated via the GuC, update PT code appropriately. v2: - Do dma_fence_get before first call of invalidation_fence_init (Himal) - No need to check for valid chain fence (Himal) v3: - Use dma-fence-array Fixes: 3330361543fc ("drm/xe/lnl: Add LNL platform definition") Signed-off-by: Matthew Brost <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-30Merge drm/drm-next into drm-intel-nextRodrigo Vivi134-1579/+4441
Sync with drm-xe-next so we can continue with display clean-up. Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-30drm/msm: Fix incorrect file name output in adreno_request_fw()Aleksandr Mishin1-1/+1
In adreno_request_fw() when debugging information is printed to the log after firmware load, an incorrect filename is printed. 'newname' is used instead of 'fwname', so prefix "qcom/" is being added to filename. Looks like "copy-paste" mistake. Fix this mistake by replacing 'newname' with 'fwname'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2c41ef1b6f7d ("drm/msm/adreno: deal with linux-firmware fw paths") Signed-off-by: Aleksandr Mishin <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/602382/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Fix UBWC macrotile_mode for a680Connor Abbott1-0/+3
Make it match the MDSS settings for sc8180x and downstream. Note that without the previous commit that exposes the value of macrotile_mode to mesa, this will break mesa which expects the legacy default value of 0. Therefore we do *not* want to backport it. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607398/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Expose expanded UBWC config uapiConnor Abbott1-0/+6
This adds extra parameters that affect UBWC tiling that will be used by the Mesa implementation of VK_EXT_host_image_copy. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607401/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Expand UBWC config settingConnor Abbott3-17/+53
According to downstream we should be setting RBBM_NC_MODE_CNTL to a non-default value on a663 and a680, we don't support a663 and on a680 we're leaving it at the wrong (suboptimal) value. Just set it on all GPUs. Similarly, plumb through level2_swizzling_dis which will be necessary on a663. ubwc_mode is expanded and renamed to ubwc_swizzle to match the name on the display side. Similarly macrotile_mode should match the display side. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607397/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Update a6xx register XMLConnor Abbott1-21/+1097
Update to Mesa commit 36a13d2b3b0 ("freedreno: fix a7xx perfcntr countables"). Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607395/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Fix CP_BV_DRAW_STATE_ADDR nameConnor Abbott1-1/+1
This was missed because we weren't using the a750-specific indexed regs. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607394/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Dump correct dbgahb clusters on a750Connor Abbott1-2/+5
This was missed thanks to the family mixup fixed in the previous commit. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607393/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm: Use a7xx family directly in gpu_stateConnor Abbott1-21/+20
With a7xx, we need to import a new header for each new generation and switch to a different list of registers, instead of making backwards-compatible changes. Using the helpers inadvertently made a750 use the a740 list of registers, instead use the family directly to fix this. Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607392/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm/adreno: add a615 supportRichard Acayan1-0/+27
The Adreno A615 is used in SDM670. Add an entry to support it. Signed-off-by: Richard Acayan <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/607238/ Signed-off-by: Rob Clark <[email protected]>
2024-08-30drm/msm/a6xx: Add A642L speedbin (0x81)Eugene Lepshy1-0/+1
According to downstream, A642L's speedbin is 129 and uses 4 as index Signed-off-by: Eugene Lepshy <[email protected]> Signed-off-by: Danila Tikhonov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/606722/ Signed-off-by: Rob Clark <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.