aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-05-02drm: move DRM-related CONFIG options into DRM submenuMasahiro Yamada1-4/+8
When you create a submenu using the 'menu' syntax, there is no ambiguity about its end because the code between 'menu' and 'endmenu' becomes the submenu. In contrast, 'menuconfig' does not have the corresponding end marker. Instead, the end of the submenu is inferred from symbol dependencies. This is detailed in Documentation/kbuild/kconfig-language.rst, starting line 348. It outlines two methods to place the code under the submenu: (1) Open an if-block immediately after 'menuconfig', enclosing the submenu content within it (2) Add 'depends on' to every symbol intended for the submenu Many subsystems opt for (1) because it reliably maintains the submenu structure. The DRM subsystem adopts (2). The submenu ends when the sequence of 'depends on DRM' breaks. It can be confirmed by running a GUI frontend such as 'make menuconfig' and visiting the DRM menu: < > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---- If you toggle this, you will notice most of the DRM-related options appear below it, not in the submenu. I highly recommend the approach (1). Obviously, (2) is not reliable, as the submenu breaks whenever someone forgets to add 'depends on DRM'. This commit encloses the entire DRM configuration with 'if DRM' and 'endif', except for DRM_PANEL_ORIENTATION_QUIRKS. Note: Now, 'depends on DRM' properties inside the if-block are all redundant. I leave it as follow-up cleanups. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm/display: Make all helpers visible and switch to depends on"Geert Uytterhoeven1-14/+12
This reverts commit d674858ff979550a0e97b4ac766f2640f0d9d7e7, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3db958e3f4002e26cd963596d810c37feb315fb3.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Make drivers depends on DRM_DW_HDMI"Geert Uytterhoeven7-10/+9
This reverts commit c0e0f139354c01e0213204e4a96e7076e5a3e396, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bd93d43b07f8ed6368119f4a5ddac2ee80debe53.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HELPER to depends on"Geert Uytterhoeven19-59/+45
This reverts commit e075e496f516bf92bc0cbaf94d64e8d4a6b58321, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1ba76cc4d96a8afefff5d1bc42fb1e1329c5da68.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on"Geert Uytterhoeven7-10/+9
This reverts commit 4d15125d7fe637f401e64e33c99513adf6586fdd, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/79824fec01eb9ab0673b9409f9b39cc8b5cc338d.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_HELPER to depends on"Geert Uytterhoeven17-27/+26
This reverts commit 0323287de87d7e6e9c22c57d7440aa353a2298d0, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/89ac456805746b6d0c888f10c5120b11aacd3319.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDCP_HELPER to depends on"Geert Uytterhoeven7-7/+6
This reverts commit 3166e7e6d935caaef07605a5c90773fbf9ffeaf4, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a40e70a0abd3d841c23c107d452a43fdd70ef37a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on"Geert Uytterhoeven8-8/+7
This reverts commit f6d2dc03fa8546b284dd8c1af027d9fac5725921, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bd288a5943dab8609f2d1f2bf413595a61df727a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: fix DRM_DISPLAY_DP_HELPER dependencies"Geert Uytterhoeven2-2/+2
This reverts commit d1ef8fc18be6adbbffdee06fbb5b33699e2852be, as the commit it fixes will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/df2876c72e82cbecfe8406fa058e8d3e895e4b93.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectable"Geert Uytterhoeven1-1/+1
This reverts commit 0209df3b4731516fe77638bfc52ba2e9629c67cd, as the commit it fixes (which is BTW not the commit in the Fixes: tag!) will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b2d1a7a765e4af249f4c450383de6e8422647e2e.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm/display: Select DRM_KMS_HELPER for DP helpers"Geert Uytterhoeven1-1/+0
This reverts commit 7fa678cc0a5648b5ea28629a2d21b9d4b6ac8f56, as the commit it fixes will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/17b6a2c5f3250a7d02ee1b517182ca6fd9baa45a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: fix DRM_DISPLAY_DP_HELPER dependencies, part 2"Geert Uytterhoeven2-2/+2
This reverts commit a57e191ebbaa0363dbf352cc37447c2230573e29, as the commits it fixes will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/37216404c77b4c677d3b3a80d12d6d4447a3f3a0.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02drm/panthor: Kill the faulty_slots variable in panthor_sched_suspend()Boris Brezillon1-7/+3
We can use upd_ctx.timedout_mask directly, and the faulty_slots update in the flush_caches_failed situation is never used. Suggested-by: Suggested-by: Steven Price <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-02drm/xe: Merge 16021540221 and 18034896535 WAsLucas De Marchi1-6/+1
In order to detect duplicate implementations for the same workaround, early in the implementation of RTP it was decided to error out even if the values set are exactly the same. With the introduction of 18034896535 in commit 74671d23ca18 ("drm/xe/xe2: Add workaround 18034896535"), LNL stepping with graphics stepping A1 now gives the following error on module load: xe 0000:00:02.0: [drm] *ERROR* GT0: [GT OTHER] \ discarding save-restore reg e48c (clear: 00000200, set: 00000200,\ masked: yes, mcr: yes): ret=-22 RTP may be improved in the future, but for now simply join the entries like done with e.g. "1607297627, 1607030317, 1607186500". Fixes: 74671d23ca18 ("drm/xe/xe2: Add workaround 18034896535") Cc: Bommu Krishnaiah <[email protected]> Cc: Tejas Upadhyay <[email protected]> Cc: Matt Roper <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit 4caf410766add8cf376a3afc910b17dd0961dd75) Signed-off-by: Thomas Hellström <[email protected]>
2024-05-02drm/xe/vm: prevent UAF in rebind_work_func()Matthew Auld1-0/+3
We flush the rebind worker during the vm close phase, however in places like preempt_fence_work_func() we seem to queue the rebind worker without first checking if the vm has already been closed. The concern here is the vm being closed with the worker flushed, but then being rearmed later, which looks like potential uaf, since there is no actual refcounting to track the queued worker. We can't take the vm->lock here in preempt_rebind_work_func() to first check if the vm is closed since that will deadlock, so instead flush the worker again when the vm refcount reaches zero. v2: - Grabbing vm->lock in the preempt worker creates a deadlock, so checking the closed state is tricky. Instead flush the worker when the refcount reaches zero. It should be impossible to queue the preempt worker without already holding vm ref. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1676 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1364 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249 Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: <[email protected]> # v6.8+ Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3d44d67c441a9fe6f81a1d705f7de009a32a5b35) Signed-off-by: Thomas Hellström <[email protected]>
2024-05-02drm/xe: Fix unexpected backmerge resultsThomas Hellström2-6/+11
The recent backmerge from drm-next to drm-xe-next brought with it some silent unexpected results. One code snippet was added twice and a partial revert had merge errors. Fix that up to reinstate the affected code as it was before the backmerge. v2: - Commit log message rewording (Lucas DeMarchi) Fixes: 79790b6818e9 ("Merge drm/drm-next into drm-xe-next") Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 06e7139a034f26804904368fe4af2ceb70724756) Signed-off-by: Thomas Hellström <[email protected]>
2024-05-02Merge tag 'drm-intel-next-2024-04-30' of ↵Dave Airlie31-1457/+1406
https://anongit.freedesktop.org/git/drm/drm-intel into drm-next Core DRM: - Export drm_client_dev_unregister (Thomas Zimmermann) Display i915: - More initial work to make display code more independent from i915 (Jani) - Convert i915/xe fbdev to DRM client (Thomas Zimmermann) - VLV/CHV DPIO register cleanup (Ville) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-30drm/i915/dpio: Extract vlv_dpio_phy_regs.hVille Syrjälä6-298/+313
Pull the VLV/CHV DPIO PHY sideband registers to their own file. v2: drop stray tabs (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Clean up the vlv/chv PHY register bitsVille Syrjälä4-202/+229
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers. Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined to be 21 wheres 20 is the correct value. It is not used in the code though so didn't bother splitting to a separate patch. v2: drop stray tabs (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Clean up VLV/CHV DPIO PHY register definesVille Syrjälä2-176/+101
The DPIO PHY registers follow clear numbering rules. Express those in a few macros to get rid of the hand calculated final offsets. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Rename a few CHV DPIO PHY registersVille Syrjälä3-24/+23
Drop the leading underscore from the CHV PHY common lane register definitions. We use these directly from actual code so the underscore here is misleading as usually it indicates an intermediate define that shouldn't be used directly. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Give VLV DPIO group register a clearer nameVille Syrjälä2-62/+62
Include _GRP in VLV DPIO PHY group access register define names. Makes it more obvious where the accesses will land. Also matches the naming used by BXT already. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Derive the phy from the port rather than pipe in encoder hooksVille Syrjälä2-17/+11
In the encoder hooks we are dealing primarily with the encoder, so derive the DPIO PHY from the encoder rather than the pipe. Technically this doesn't matter as we can't cross connect pipes<->port across PHY boundaries, but it does conveny the intention more accurately. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: s/pipe/ch/Ville Syrjälä1-24/+25
Stop using 'pipe' directly as the DPIO PHY channel. This does happen to work on VLV since it just has the one PHY with CH0==pipe A and CH1==pipe B. But explicitly converting the thing to the right enum makes the whole thing less confusing. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: s/port/ch/Ville Syrjälä2-49/+49
Stop calling the DPIO PHY channel "port". Just say "ch", which is already used in a bunch of places. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Rename some variablesVille Syrjälä1-49/+48
Use a consistent 'tmp' as the variable name for the register values during rmw when we don't deal with multiple registers in parallel. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Remove pointless variables from vlv/chv DPLL codeVille Syrjälä1-36/+28
Drop all the local variables for the DPLL dividers for vlv/chv and just consult the state directly. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Fix VLV DPIO PLL register dword numberingVille Syrjälä2-21/+21
The spreadsheet defines the PLL register block as having the dwords in the following order: block dwords offsets PLL1 0x0-0x7 0x00-0x1f PLL2 0x0-0x7 0x20-0x3f PLL1ext 0x10-0x1f 0x40-0x5f PLL2ext 0x10-0x1f 0x60-0x7f So dword indexes 0x8-0xf don't even exist. Renumber our register defines to match. Note that the spreadsheet used hex numbering whereas our defiens are in decimal. Perhaps we should change that? Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/Ville Syrjälä2-2/+3
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address does kinda look like it goes to the PLL block on a first glance, but broadcast is special and doesn't even exist for the PLL (only PCS and TX have it). The fact that we use a broadcast write here is a bit sketchy IMO since we're now blasting the register to all PCS splines across the whole PHY. So the PCS registers in the other channel (ie. other pipe/port) will also be written. But I guess the fact that we always write the same value should make this a nop even if the other channel is already enabled (assuming the VBIOS/GOP didn't screw up and use some other value...). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/Ville Syrjälä2-6/+6
Our VLV_REF_DW13 is actually VLV_REF_DW11. Rename it. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/dpio: Remove pointless VLV_PCS01_DW8 readVille Syrjälä1-1/+0
We don't use the result of the VLV_PCS01_DW8 read at all, so don't read. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-04-30drm/i915/gt: Automate CCS Mode setting during engine resetsAndi Shyti3-5/+7
We missed setting the CCS mode during resume and engine resets. Create a workaround to be added in the engine's workaround list. This workaround sets the XEHP_CCS_MODE value at every reset. The issue can be reproduced by running: $ clpeak --kernel-latency Without resetting the CCS mode, we encounter a fence timeout: Fence expiration time out i915-0000:03:00.0:clpeak[2387]:2! Fixes: 2bebae0112b1 ("drm/i915/gt: Enable only one CCS for compute workload") Reported-by: Gnattu OC <[email protected]> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 Signed-off-by: Andi Shyti <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matt Roper <[email protected]> Cc: <[email protected]> # v6.2+ Tested-by: Gnattu OC <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Krzysztof Gibala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C22Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C22 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0a07f615c574040094b37c861078e41daf53c706.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C21_C20Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C21_C20 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/af39047d304f8a5c3c7a643f702f66c06ea5d638.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C12Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C12 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/62a748b685f253151b17c101dec75351577f30c0.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C11_C10Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C11_C10 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3f7aae89cf63760bca43b54102c76b3ed2cf8735.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C02Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C02 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/550d4e787445802236f0bf89e4d2f4f32cbd6d75.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PIPE_WGC_C01_C00Jani Nikula2-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C01_C00 register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/85b3db6e666a7a629b10b482b7e7043d52d30511.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30drm/i915: pass dev_priv explicitly to PALETTEJani Nikula2-11/+20
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PALETTE register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bf07d29cefef23ebd5d54fbb0d3bf7e41d132d93.1714399071.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-30Merge tag 'amd-drm-next-6.10-2024-04-26' of ↵Dave Airlie185-286/+1650
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.10-2024-04-26: amdgpu: - Misc code cleanups and refactors - Support setting reset method at runtime - Report OD status - SMU 14.0.1 fixes - SDMA 4.4.2 fixes - VPE fixes - MES fixes - Update BO eviction priorities - UMSCH fixes - Reset fixes - Freesync fixes - GFXIP 9.4.3 fixes - SDMA 5.2 fixes - MES UAF fix - RAS updates - Devcoredump updates for dumping IP state - DSC fixes - JPEG fix - Fix VRAM memory accounting - VCN 5.0 fixes - MES fixes - UMC 12.0 updates - Modify contiguous flags handling - Initial support for mapping kernel queues via MES amdkfd: - Fix rescheduling of restore worker - VRAM accounting for SVM migrations - mGPU fix - Enable SQ watchpoint for gfx10 Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-30Merge tag 'drm-intel-gt-next-2024-04-26' of ↵Dave Airlie54-156/+414
https://anongit.freedesktop.org/git/drm/drm-intel into drm-next UAPI Changes: - drm/i915/guc: Use context hints for GT frequency Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq for this context more slowly. We also disable waitboost for this context as that will interfere with the strategy. We need to enable the use of SLPC Compute strategy during init, but it will apply only to contexts that set this bit during context creation. Userland can check whether this feature is supported using a new param- I915_PARAM_HAS_CONTEXT_FREQ_HINT. This flag is true for all guc submission enabled platforms as they use SLPC for frequency management. The Mesa usage model for this flag is here - https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint - drm/i915/gt: Enable only one CCS for compute workload Enable only one CCS engine by default with all the compute sices allocated to it. While generating the list of UABI engines to be exposed to the user, exclude any additional CCS engines beyond the first instance *** NOTE: This W/A will make all DG2 SKUs appear like single CCS SKUs by default to mitigate a hardware bug. All the EUs will still remain usable, and all the userspace drivers have been confirmed to be able to dynamically detect the change in number of CCS engines and adjust. For the smaller percent of applications that get perf benefit from letting the userspace driver dispatch across all 4 CCS engines we will be introducing a sysfs control as a later patch to choose 4 CCS each with 25% EUs (or 50% if 2 CCS). NOTE: A regression has been reported at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 However Andi has been triaging the issue and we're closing in a fix to the gap in the W/A implementation: https://lists.freedesktop.org/archives/intel-gfx/2024-April/348747.html Driver Changes: - Add new and fix to existing workarounds: Wa_14018575942 (MTL), Wa_16019325821 (Gen12.70), Wa_14019159160 (MTL), Wa_16015675438, Wa_14020495402 (Gen12.70) (Tejas, John, Lucas) - Fix UAF on destroy against retire race and remove two earlier partial fixes (Janusz) - Limit the reserved VM space to only the platforms that need it (Andi) - Reset queue_priority_hint on parking for execlist platforms (Chris) - Fix gt reset with GuC submission is disabled (Nirmoy) - Correct capture of EIR register on hang (John) - Remove usage of the deprecated ida_simple_xx() API - Refactor confusing __intel_gt_reset() (Nirmoy) - Fix the fix for GuC reset lock confusion (John) - Simplify/extend platform check for Wa_14018913170 (John) - Replace dev_priv with i915 (Andi) - Add and use gt_to_guc() wrapper (Andi) - Remove bogus null check (Rodrigo, Dan) . Selftest improvements (Janusz, Nirmoy, Daniele) Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-29Merge v6.9-rc6 into drm-nextDaniel Vetter355-1900/+3033
Thomas needs the defio fixes, Maíra needs the vkms fixes and Joonas has some fun with i915-gem conflicts. Signed-off-by: Daniel Vetter <[email protected]>
2024-04-29drm/i915/display: split out intel_sprite_regs.h from i915_reg.hJani Nikula8-341/+357
Clean up i915_reg.h. v2: Drop a redundant comment (Ville) Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/679b7395a78c53006ac07448706f1809b74810de.1714128645.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-29drm/i915/display: split out intel_fbc_regs.h from i915_reg.hJani Nikula6-123/+125
Clean up i915_reg.h. v2: Drop chicken regs and comments (Ville) Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/aa9b5d8adefbe97e1e37c9cfada3ab1581b0e8d5.1714128645.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-29drm/i915/color: move palette registers to intel_color_regs.hJani Nikula2-31/+29
For some reason the paletter registers were missed when adding intel_color_regs.h. Finish the job. Adjust some comments while at it. v2: Fix comments (Ville) Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1322f577b113b8fc1a6c2ef35340fc3c599b4bcb.1714128645.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-29drm/i915/audio: move LPE audio regs to intel_audio_regs.hJani Nikula3-17/+17
There are too few registers to warrant a dedicated file for LPE audio regs, but the audio reg file is better than i915_reg.h. v2: Rebase Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b5ee35309b2e0905aaa12d944b3d379c45a8a0bd.1714128645.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-28Linux 6.9-rc6Linus Torvalds1-1/+1
2024-04-28Merge tag 'sched-urgent-2024-04-28' of ↵Linus Torvalds3-21/+38
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix EEVDF corner cases - Fix two nohz_full= related bugs that can cause boot crashes and warnings * tag 'sched-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU sched/isolation: Prevent boot crash when the boot CPU is nohz_full sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr sched/eevdf: Always update V if se->on_rq when reweighting
2024-04-28Merge tag 'x86-urgent-2024-04-28' of ↵Linus Torvalds10-17/+53
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Make the CPU_MITIGATIONS=n interaction with conflicting mitigation-enabling boot parameters a bit saner. - Re-enable CPU mitigations by default on non-x86 - Fix TDX shared bit propagation on mprotect() - Fix potential show_regs() system hang when PKE initialization is not fully finished yet. - Add the 0x10-0x1f model IDs to the Zen5 range - Harden #VC instruction emulation some more * tag 'x86-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n cpu: Re-enable CPU mitigations by default for !X86 architectures x86/tdx: Preserve shared bit on mprotect() x86/cpu: Fix check for RDPKRU in __show_regs() x86/CPU/AMD: Add models 0x10-0x1f to the Zen5 range x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler
2024-04-28Merge tag 'irq-urgent-2024-04-28' of ↵Linus Torvalds1-7/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix a double free bug in the init error path of the GICv3 irqchip driver" * tag 'irq-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Prevent double free on error