summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-08-12drm/xe: Defer buffer object shrinker write-backs and GPU waitsThomas Hellström1-4/+47
When the xe buffer-object shrinker allows GPU waits and write-back, (typically from kswapd), perform multiple passes, skipping subsequent passes if the shrinker number of scanned objects target is reached. 1) Without GPU waits and write-back 2) Without write-back 3) With both GPU-waits and write-back This is to avoid stalls and costly write- and readbacks unless they are really necessary. v2: - Don't test for scan completion twice. (Stuart Summers) - Update tags. Reported-by: melvyn <melvyn2@dnsense.pub> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5557 Cc: Summers Stuart <stuart.summers@intel.com> Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250805074842.11359-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 80944d334182ce5eb27d00e2bf20a88bfc32dea1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-12drm/xe/migrate: prevent potential UAFMatthew Auld1-4/+5
If we hit the error path, the previous fence (if there is one) has already been put() prior to this, so doing a fence_wait could lead to UAF. Tweak the flow to do to the put() until after we do the wait. Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250731093807.207572-8-matthew.auld@intel.com (cherry picked from commit 9b7ca35ed28fe5fad86e9d9c24ebd1271e4c9c3e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-12drm/xe/migrate: don't overflow max copy sizeMatthew Auld1-0/+6
With non-page aligned copy, we need to use 4 byte aligned pitch, however the size itself might still be close to our maximum of ~8M, and so the dimensions of the copy can easily exceed the S16_MAX limit of the copy command leading to the following assert: xe 0000:03:00.0: [drm] Assertion `size / pitch <= ((s16)(((u16)~0U) >> 1))` failed! platform: BATTLEMAGE subplatform: 1 graphics: Xe2_HPG 20.01 step A0 media: Xe2_HPM 13.01 step A1 tile: 0 VRAM 10.0 GiB GT: 0 type 1 WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe] To fix this account for the pitch when calculating the number of current bytes to copy. Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250731093807.207572-7-matthew.auld@intel.com (cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-12drm/xe/migrate: prevent infinite recursionMatthew Auld1-12/+17
If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to using a bounce buffer. However the bounce buffer here is allocated on the stack, and the only alignment requirement here is that it's naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce buffer is also misaligned we then recurse back into the function again, however the new bounce buffer might also not be aligned, and might never be until we eventually blow through the stack, as we keep recursing. Instead of using the stack use kmalloc, which should respect the power-of-two alignment request here. Fixes a kernel panic when triggering this path through eudebug. v2 (Stuart): - Add build bug check for power-of-two restriction - s/EINVAL/ENOMEM/ Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250731093807.207572-6-matthew.auld@intel.com (cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-12drm/xe/pf: Set VF LMEM BAR sizeMichał Winiarski2-0/+23
LMEM is partitioned between multiple VFs and we expect that the more VFs we have, the less LMEM is assigned to each VF. This means that we can achieve full LMEM BAR access without the need to attempt full VF LMEM BAR resize via pci_resize_resource(). Always try to set the largest possible BAR size that allows to fit the number of enabled VFs and inform the user in case the resize attempt is not successful. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250527120637.665506-7-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-12Merge drm/drm-next into drm-xe-nextLucas De Marchi864-18145/+28488
Bring v6.17-rc1 to propagate commits from other subsystems, particularly PCI, which has some new functions needed for SR-IOV integration. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-12drm/xe: Move ASID allocation and user PT BO tracking into xe_vm_createPiotr Piórkowski1-19/+15
Currently, ASID assignment for user VMs and page-table BO accounting for client memory tracking are performed in xe_vm_create_ioctl. To consolidate VM object initialization, move this logic to xe_vm_create. v2: - removed unnecessary duplicate BO tracking code - using the local variable xef to verify whether the VM is being created by userspace Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250811104358.2064150-3-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-08-12drm/xe: Assign ioctl xe file handler to vm in xe_vm_createPiotr Piórkowski4-8/+9
In several code paths, such as xe_pt_create(), the vm->xef field is used to determine whether a VM originates from userspace or the kernel. Previously, this handler was only assigned in xe_vm_create_ioctl(), after the VM was created by xe_vm_create(). However, xe_vm_create() triggers page table creation, and that function assumes vm->xef should be already set. This could lead to incorrect origin detection. To fix this problem and ensure consistency in the initialization of the VM object, let's move the assignment of this handler to xe_vm_create. v2: - take reference to the xe file object only when xef is not NULL - release the reference to the xe file object on the error path (Matthew) Fixes: 7f387e6012b6 ("drm/xe: add XE_BO_FLAG_PINNED_LATE_RESTORE") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250811104358.2064150-2-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-08-12drm/i915/icl+/tc: Convert AUX powered WARN to a debug messageImre Deak1-3/+3
The BIOS can leave the AUX power well enabled on an output, even if this isn't required (on platforms where the AUX power is only needed for an AUX access). This was observed at least on PTL. To avoid the WARN which would be triggered by this during the HW readout, convert the WARN to a debug message. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-6-imre.deak@intel.com
2025-08-12drm/i915/lnl+/tc: Use the cached max lane count valueImre Deak1-1/+5
Use the cached max lane count value on LNL+, to account for scenarios where this value is queried after the HW cleared the corresponding pin assignment value in the TCSS_DDI_STATUS register after the sink got disconnected. For consistency, follow-up changes will use the cached max lane count value on other platforms as well and will also cache the pin assignment value in a similar way. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-5-imre.deak@intel.com
2025-08-12drm/i915/lnl+/tc: Fix max lane count HW readoutImre Deak1-0/+9
On LNL+ for a disconnected sink the pin assignment value gets cleared by the HW/FW as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the BIOS/driver (and hence the PHY itself is still connected and used by the display). During HW readout this can result in detecting the PHY's max lane count as 0 - matching the above cleared aka NONE pin assignment HW state. For a connected PHY the driver in general (outside of intel_tc.c) expects the max lane count value to be valid for the video mode enabled on the corresponding output (1, 2 or 4). Ensure this by setting the max lane count to 4 in this case. Note, that it doesn't matter if this lane count happened to be more than the max lane count with which the PHY got connected and enabled, since the only thing the driver can do with such an output - where the DP-alt sink is disconnected - is to disable the output. v2: Rebased on change reading out the pin configuration only if the PHY is connected. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-4-imre.deak@intel.com
2025-08-12drm/i915/icl+/tc: Cache the max lane count valueImre Deak1-9/+48
The PHY's pin assignment value in the TCSS_DDI_STATUS register - as set by the HW/FW based on the connected DP-alt sink's TypeC/PD pin assignment negotiation - gets cleared by the HW/FW on LNL+ as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the driver (and hence the PHY itself is still connected and used by the display). This is similar to how the PHY Ready flag gets cleared on LNL+ in the same register. To be able to query the max lane count value on LNL+ - which is based on the above pin assignment - at all times even after the sink gets disconnected, the max lane count must be determined and cached during the PHY's HW readout and connect sequences. Do that here, leaving the actual use of the cached value to a follow-up change. v2: Don't read out the pin configuration if the PHY is disconnected. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-3-imre.deak@intel.com
2025-08-12drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sinkImre Deak1-6/+11
The TypeC PHY HW readout during driver loading and system resume determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and whether the PHY is connected, based on the PHY's Owned and Ready flags. For the PHY to be in DP-alt or legacy mode and for the PHY to be in the connected state in these modes, both the Owned (set by the BIOS/driver) and the Ready (set by the HW) flags should be set. On ICL-MTL the HW kept the PHY's Ready flag set after the driver connected the PHY by acquiring the PHY ownership (by setting the Owned flag), until the driver disconnected the PHY by releasing the PHY ownership (by clearing the Owned flag). On LNL+ this has changed, in that the HW clears the Ready flag as soon as the sink gets disconnected, even if the PHY ownership was acquired already and hence the PHY is being used by the display. When inheriting the HW state from BIOS for a PHY connected in DP-alt mode on which the sink got disconnected - i.e. in a case where the sink was connected while BIOS/GOP was running and so the sink got enabled connecting the PHY, but the user disconnected the sink by the time the driver loaded - the PHY Owned but not Ready state must be accounted for on LNL+ according to the above. Do that by assuming on LNL+ that the PHY is connected in DP-alt mode whenever the PHY Owned flag is set, regardless of the PHY Ready flag. This fixes a problem on LNL+, where the PHY TypeC mode / connected state was detected incorrectly for a DP-alt sink, which got connected and then disconnected by the user in the above way. v2: Rename tc_phy_in_legacy_or_dp_alt_mode() to tc_phy_owned_by_display(). (Luca, Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> [Imre: Add one-liner function documentation for tc_phy_owned_by_display()] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-2-imre.deak@intel.com
2025-08-12drm/i915/psr: Do not trigger Frame Change events from frontbuffer flushJouni Högander1-5/+9
We want to get rid of triggering "Frame Change" events from frontbuffer flush calls. We are about to move using TRANS_PUSH register for this on LunarLake and onwards. Touching TRANS_PUSH register from fronbuffer flush would be problematic as it's written by DSB as well. Fix this by using intel_psr_exit when flush or invalidate is done on LunarLake and onwards. This is not possible on AlderLake and MeteorLake due to HW bug in PSR2 disable. This patch is also fixing problems with cursor plane where cursor is disappearing or duplicate cursor is seen on the screen. v2: Commit message updated Bspec: 68927, 68934, 66624 Reported-by: Janna Martl <janna.martl109@gmail.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5522 Fixes: 411ad63877bb ("drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwards") Tested-by: Janna Martl <janna.martl109@gmail.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250801062905.564453-1-jouni.hogander@intel.com (cherry picked from commit 46fb38cb20c0d185a6391ab524b23e0e0219c41f) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-12drm/i915/fbc: fix the implementation of wa_18038517565Vinod Govindapillai1-4/+4
As per the wa_18038517565, we need to disable FBC compressor clock gating before enabling FBC and enable after disabling FBC. Placing the enabling of clock gating in the fbc deactivate function can make the above wa logic go wrong in case of frontbuffer rendering FBC mechanism. FBC deactivate can get called during fb invalidate and then the corresponding FBC activate can get called without properly disabling the clock gating and can result in compression stalled. So move the enable clock gating at the end of one FBC session after FBC is completely disabled for a pipe. Bspec: 74212, 72197, 69741, 65555 Fixes: 010363c46189 ("drm/i915/display: implement wa_18038517565") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250729124648.288497-1-vinod.govindapillai@intel.com (cherry picked from commit 82dde0407ab126f8413fd6c51429e5057ced5ba2) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-12drm/i915/vbt: add missing DSI VBT defsJani Nikula1-3/+10
Add some missing DSI VBT definitions. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/17e0f38391314aceff12619a04829c3e36fa26b7.1754925923.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-12drm/i915/vbt: flip bta_enabled to bta_disableJani Nikula2-2/+2
The meaning is disable, so flip the member name. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/180079eca346edc1671c164da2ca7f428c2ba1de.1754925923.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-12drm/i915/vbt: add anonymous structs to group DSI VBT defsJani Nikula1-40/+47
The grouping of DSI VBT definitions is hard to follow and match against the spec. Use anonymous structs and add comments with the spec description. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/f57ca596aefa3ef0b4ce1f36452410cf745acddd.1754925923.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-12drm/i915/vbt: split up DSI VBT defs to a separate fileJani Nikula4-175/+185
The DSI VBT definitions have ended up in intel_bios.h, because intel_vbt_defs.h is supposed to be internal to intel_bios.c, but the DSI VBT definitions are needed in more places. Split out the DSI VBT definitions to intel_dsi_vbt_defs.h. This will also help keep the definitions in sync with IGT. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/84417e0141f98ae8f8c7a66e9002c3e99c9ed3db.1754925923.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-12drm/panic: Add a u64 divide by 10 for arm32Jocelyn Falempe1-1/+21
On 32bits ARM, u64 divided by a constant is not optimized to a multiply by inverse by the compiler [1]. So do the multiply by inverse explicitly for this architecture. Link: https://github.com/llvm/llvm-project/issues/37280 [1] Reported-by: Andrei Lalaev <andrey.lalaev@gmail.com> Closes: https://lore.kernel.org/dri-devel/c0a2771c-f3f5-4d4c-aa82-d673b3c5cb46@gmail.com/ Fixes: 675008f196ca ("drm/panic: Use a decimal fifo to avoid u64 by u64 divide") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-08-12drm/panfrost: Print RSS for tiler heap BO's in debugfs GEMS fileAdrián Larumbe1-1/+1
Otherwise it would display the virtual allocation size, which is often much bigger than the RSS. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: e48ade5e23ba ("drm/panfrost: show device-wide list of DRM GEM objects over DebugFS") Tested-by: Christopher Healy <healych@amazon.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250808010235.2831853-1-adrian.larumbe@collabora.com
2025-08-12drm/bridge: it6505: select REGMAP_I2CChia-I Wu1-0/+1
Fix aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_i2c_probe': ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20250610235825.3113075-1-olvaffe@gmail.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2025-08-12drm/i915/scaler: Fix condition for WA_14011503117Nemesa Garg1-1/+1
As scaler_state can never be null so no need to check this, only check if scaler_id is less than 0 or not. v2: Add scaler_id check [Jani] v3: Modify commit message[Suraj] Fixes: 73309ed9d598 ("drm/i915/display: WA_14011503117") Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250807113855.3175435-1-nemesa.garg@intel.com
2025-08-12drm/nouveau: always set RMDevidCheckIgnore for GSP-RMTimur Tabi1-0/+3
Always set the RMDevidCheckIgnore registry key for GSP-RM so that it will continue support newer variants of already supported GPUs. GSP-RM maintains an internal list of PCI IDs of GPUs that it supports, and checks if the current GPU is on this list. While the actual GPU architecture (as specified in the BOOT_0/BOOT_42 registers) determines how to enable the GPU, the PCI ID is used for the product name, e.g. "NVIDIA GeForce RTX 5090". Unfortunately, if there is no match, GSP-RM will refuse to initialize, even if the device is fully supported. Nouveau will get an error return code, but by then it's too late. This behavior may be corrected in a future version of GSP-RM, but that does not help Nouveau today. Fortunately, GSP-RM supports an undocumented registry key that tells it to ignore the mismatch. In such cases, the product name returned will be a blank string, but otherwise GSP-RM will continue. Unlike Nvidia's proprietary driver, Nouveau cannot update to newer firmware versions to keep up with every new hardware release. Instead, we can permanently set this registry key, and GSP-RM will continue to function the same with known hardware. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://lore.kernel.org/r/20250808191340.1701983-1-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-12drm/panel-edp: Add SHP LQ134Z1 panel for Dell XPS 9345Christopher Orr1-0/+1
Introduce high-res OLED panel for the Dell XPS 9345 These timings were selected based on Alex Vinarkskis' commit, (6b3815c6815f07acc7eeffa8ae734d1a1c0ee817) for the LQ134N1 and seem to work fine for the high-res OLED panel on the 9345. The raw edid for this SHP panel is: 00 ff ff ff ff ff ff 00 4d 10 8f 15 00 00 00 00 2e 21 01 04 b5 1d 12 78 03 0f 95 ae 52 43 b0 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 fd d7 00 a0 a0 40 fc 66 30 20 36 00 20 b4 10 00 00 18 00 00 00 fd 00 1e 78 cc cc 38 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 37 31 4d 31 81 4c 51 31 33 34 5a 31 00 00 00 00 00 02 41 0c 32 01 01 00 00 0b 41 0a 20 20 01 ea 70 20 79 02 00 20 00 13 8c 52 19 8f 15 00 00 00 00 2e 17 07 4c 51 31 33 34 5a 31 21 00 1d 40 0b 08 07 00 0a 40 06 88 e1 fa 51 3d a4 b0 66 62 0f 02 45 54 d0 5f d0 5f 00 34 13 78 26 00 09 06 00 00 00 00 00 41 00 00 22 00 14 d9 6f 08 05 ff 09 9f 00 2f 00 1f 00 3f 06 5d 00 02 00 05 00 25 01 09 d9 6f 08 d9 6f 08 1e 78 80 81 00 0b e3 05 80 00 e6 06 05 01 6a 6a 39 00 00 00 00 00 00 58 90 Signed-off-by: Christopher Orr <chris.orr@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/aJKvm3SlhLGHW4qn@jander
2025-08-11drm/sharp-memory: Do not access GEM-DMA vaddr directlyThomas Zimmermann1-14/+13
Use DRM's shadow-plane helper to map and access the GEM object's buffer within kernel address space. Encapsulates the vmap logic in the GEM-DMA helpers. The sharp-memory driver currently reads the vaddr field from the GME buffer object directly. This only works because GEM code 'automagically' sets vaddr. Shadow-plane helpers perform the same steps, but with correct abstraction behind drm_gem_vmap(). The shadow-plane state provides the buffer address in kernel address space and the format-conversion state. v2: - fix typo in commit description Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250627152327.8244-1-tzimmermann@suse.de
2025-08-11drm/repaper: Do not access GEM-DMA vaddr directlyThomas Zimmermann1-9/+7
Use DRM's shadow-plane helper to map and access the GEM object's buffer within kernel address space. Encapsulates the vmap logic in the GEM-DMA helpers. The repaper driver currently reads the vaddr field from the GME buffer object directly. This only works because GEM code 'automagically' sets vaddr. Shadow-plane helpers perform the same steps, but with correct abstraction behind drm_gem_vmap(). The shadow-plane state provides the buffer address in kernel address space and the format-conversion state. v2: - fix typo in commit description Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250627152422.8399-1-tzimmermann@suse.de
2025-08-11drm/xe: rework PDE PAT index selectionMatthew Auld4-15/+36
For non-leaf paging structures we end up selecting a random index between [0, 3], depending on the first user if the page-table is shared, since non-leaf structures only have two bits in the HW for encoding the PAT index, and here we are just passing along the full user provided index, which can be an index as large as ~31 on xe2+. The user provided index is meant for the leaf node, which maps the actual BO pages where we have more PAT bits, and not the non-leaf nodes which are only mapping other paging structures, and so only needs a minimal PAT index range. Also the chosen index might need to consider how the driver mapped the paging structures on the host side, like wc vs wb, which is separate from the user provided index. With that move the PDE PAT index selection under driver control. For now just use a coherent index on platforms with page-tables that are cached on host side, and incoherent otherwise. Using a coherent index could potentially be expensive, and would be overkill if we know the page-table is always uncached on host side. v2 (Stuart): - Add some documentation and split into separate helper. BSpec: 59510 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250808103455.462424-2-matthew.auld@intel.com
2025-08-11drm/tests: Fix drm_test_fb_xrgb8888_to_xrgb2101010() on big-endianJosé Expósito1-0/+1
Fix failures on big-endian architectures on tests cases single_pixel_source_buffer, single_pixel_clip_rectangle, well_known_colors and destination_pitch. Fixes: 15bda1f8de5d ("drm/tests: Add calls to drm_fb_blit() on supported format conversion tests") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250630090054.353246-2-jose.exposito89@gmail.com
2025-08-11drm/tests: Fix endian warningJosé Expósito1-1/+1
When compiling with sparse enabled, this warning is thrown: warning: incorrect type in argument 2 (different base types) expected restricted __le32 const [usertype] *buf got unsigned int [usertype] *[assigned] buf Add a cast to fix it. Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250630090054.353246-1-jose.exposito89@gmail.com
2025-08-11drm/gud: Remove unnecessary loggingRuben Wauters1-2/+0
The debug logging in gud_disconnect() adds zero detail and is unnecessary, as it only prints the function name. The same functionality can be achieved by using ftrace, and is highlighted by checkpatch, stating the same. This patch removes the debug log in the gud_disconnect() function. Signed-off-by: Ruben Wauters <rubenru09@aol.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250721232210.12578-1-rubenru09@aol.com
2025-08-11drm/radeon/r600_cs: clean up of dead code in r600_csBrahmajit Das1-2/+2
GCC 16 enables -Werror=unused-but-set-variable= which results in build error with the following message. drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_texture_size’: drivers/gpu/drm/radeon/r600_cs.c:1411:29: error: variable ‘level’ set but not used [-Werror=unused-but-set-variable=] 1411 | unsigned offset, i, level; | ^~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/radeon/r600_cs.o] Error 1 level although is set, but in never used in the function r600_texture_size. Thus resulting in dead code and this error getting triggered. Fixes: 60b212f8ddcd ("drm/radeon: overhaul texture checking. (v3)") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Brahmajit Das <listout@listout.xyz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amdgpu: fix incorrect comment formatCryolitia PukNgae1-3/+3
Comments should not have a leading plus sign. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amd/display: Promote DC to 3.2.345Taimur Hassan1-1/+1
This version brings along following update: -Fix close and open lid may cause eDP remaining blank -Fix frequently disabling/enabling OTG may cause incorrect configuration of OTG Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amd/display: [FW Promotion] Release 0.1.22.0Taimur Hassan1-0/+69
Add a new command for Panel Replay. Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amd/display: Reset apply_eamless_boot_optimization when dpms_offDanny Wang1-1/+1
[WHY&HOW] The user closed the lid while the system was powering on and opened it again before the “apply_seamless_boot_optimization” was set to false, resulting in the eDP remaining blank. Reset the “apply_seamless_boot_optimization” to false when dpms off. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Danny Wang <Danny.Wang@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amd/display: Wait until OTG enable state is clearedTungYu Lu1-0/+5
[Why] Customer reported an issue that OS starts and stops device multiple times during driver installation. Frequently disabling and enabling OTG may prevent OTG from being safely disabled and cause incorrect configuration upon the next enablement. [How] Add a wait until OTG_CURRENT_MASTER_EN_STATE is cleared as a short term solution. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: TungYu Lu <tungyu.lu@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amdgpu: add to custom amdgpu_drm_release drm_dev_enter/exitVitaly Prosyak1-1/+4
User queues are disabled before GEM objects are released (protecting against user app crashes). No races with PCI hot-unplug (because drm_dev_enter prevents cleanup if iewdevice is being removed). Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11drm/amdgpu: Save and restore switch stateLijo Lazar2-5/+83
During a DPC error kernel waits for the link to be active before notifying downstream devices. On certain platforms with Broadcom switch in synthetiic mode, switch responds with values even though the link is not fully ready. The config space restoration done by pcie port driver for SWUS/DS of dGPU is thus not effective as the switch is still doing internal enumeration. As a workaround, save state of SWUS/DS device in driver. Add additional check to see if link is active and restore the values during DPC error callbacks. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-11Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann1382-29569/+52847
Updating drm-misc-fixes to the state of v6.17-rc1. Begins a new release cycle. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-08-11drm/xe/hwmon: Add SW clamp for power limits writesKarthik Poosa1-0/+29
Clamp writes to power limits powerX_crit/currX_crit, powerX_cap, powerX_max, to the maximum supported by the pcode mailbox when sysfs-provided values exceed this limit. Although the pcode already performs clamping, values beyond the pcode mailbox's supported range get truncated, leading to incorrect critical power settings. This patch ensures proper clamping to prevent such truncation. v2: - Address below review comments. (Riana) - Split comments into multiple sentences. - Use local variables for readability. - Add a debug log. - Use u64 instead of unsigned long. v3: - Change drm_dbg logs to drm_info. (Badal) v4: - Rephrase the drm_info log. (Rodrigo, Riana) - Rename variable max_mbx_power_limit to max_supp_power_limit, as limit is same for platforms with and without mailbox power limit support. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: 92d44a422d0d ("drm/xe/hwmon: Expose card reactive critical power") Fixes: fb1b70607f73 ("drm/xe/hwmon: Expose power attributes") Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20250808185310.3466529-1-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-11Merge drm/drm-next into drm-misc-nThomas Zimmermann380-3664/+7890
Updating drm-misc-next to the state of v6.17-rc1. Begins a new release cycle. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-08-09drm/nouveau: fix typos in commentsMadhur Kumar1-3/+3
Fixed three spelling mistakes in nouveau_exec.c comments: - alloctor -> allocator - exectued -> executed - depent -> depend No functional changes. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by: Madhur Kumar <madhurkumar004@gmail.com> Link: https://lore.kernel.org/r/20250808073840.376764-1-madhurkumar004@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-09drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().Fanhua Li1-1/+2
When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202312040659.4pJpMafN-lkp@intel.com/ Fixes: 6b252cf42281 ("drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm") Signed-off-by: Fanhua Li <lifanhua5@huawei.com> Link: https://lore.kernel.org/r/20250728115027.50878-1-lifanhua5@huawei.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-09drm/i915/gt: Protect against overflow in active_engine()Krzysztof Karas1-0/+2
It is unlikely, but possible for the first call to intel_context_create() to fail with -ENOMEM, which would result in entering the following code block and decrementing "count", when it is set to 0 (initial condition in the for loop). Protect from overflowing the variable by checking for 0 value of "count" before entering the loop. Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/pogr74jktdqehrfap4tjky23ees4x7erh5dwgg5jb2n522cfkw@kpnxe4qzx4pj
2025-08-09drm/nouveau: Remove surplus struct memberPhilipp Stanner2-3/+0
struct nouveau_channel contains the member 'accel_done' and a forgotten TODO which hints at that mechanism being removed in the "near future". Since that variable is read nowhere anymore, this "near future" is now. Remove the variable and the TODO. Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250801074531.79237-2-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-09drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf()Seyediman Seyedarab1-1/+1
snprintf() returns the number of characters that *would* have been written, which can overestimate how much you actually wrote to the buffer in case of truncation. That leads to 'data += this' advancing the pointer past the end of the buffer and size going negative. Switching to scnprintf() prevents potential buffer overflows and ensures consistent behavior when building the output string. Signed-off-by: Seyediman Seyedarab <ImanDevel@gmail.com> Link: https://lore.kernel.org/r/20250724195913.60742-1-ImanDevel@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-09Merge tag 'gpio-updates-for-v6.17-rc1-part2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "As discussed: there's a small commit that removes the legacy GPIO line value setter callbacks as they're no longer used and a big, treewide commit that renames the new ones to the old names across all GPIO drivers at once. While at it: there are also two fixes that I picked up over the course of the merge window: - remove unused, legacy GPIO line value setters from struct gpio_chip - rename the new set callbacks back to the original names treewide - fix interrupt handling in gpio-mlxbf2 - revert a buggy immutable irqchip conversion" * tag 'gpio-updates-for-v6.17-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: treewide: rename GPIO set callbacks back to their original names gpio: remove legacy GPIO line value setter callbacks gpio: mlxbf2: use platform_get_irq_optional() Revert "gpio: pxa: Make irq_chip immutable"
2025-08-09drm/i915/selftests: Do not leak vm_area_struct on early returnKrzysztof Karas1-37/+31
This structure may be leaked on early failure paths, so include vm_munmap() call in them to avoid that. Suggested-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/d8277e3af09c388fa5dfbf5c9bb3985ae0b191a2.1753859971.git.krzysztof.karas@intel.com
2025-08-09drm/i915/selftests: Do not overwrite error code after ↵Krzysztof Karas1-1/+1
intel_context_migrate_clear() call Currently this function's error code is stored in err variable, which, if a i915_request is present, will be immediately overwritten by return from dma_resv_reserve_fences(). Call DMA functions only if intel_context_migrate_clear() succeeded. Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/c0348e052bcb2870acdc15d60f5389fbdf4ef886.1753859971.git.krzysztof.karas@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-10 19:00:35 +0300