summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-10-17drm/i915/dp: Fix panel replay when DSC is enabledImre Deak
Prevent enabling panel replay if the sink doesn't support this due to DSC being enabled. Panel replay has two modes, updating full frames or only selected regions of the frame. If the sink doesn't support Panel Replay in full frame update mode with DSC prevent Panel Replay completely if DSC is enabled. If the sink doesn't support Panel Replay only in the selective update mode while DSC is enabled, it will still support Panel Replay in the full frame update mode, so only prevent selective updates in this case. v2: - Use Panel Replay instead of PR in debug prints. (Jouni) - Rebase on change tracking the link DSC state in the crtc state. Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the linkImre Deak
The state of all the CRTCs on an MST link must be recomputed, if DSC gets enabled on any of the CRTCs on the link. For instance an MST docking station's Panel Replay capability may depend on whether DSC is enabled on any of the dock's streams (aka CRTCs). To assist the Panel Replay state computation for a CRTC based on the above, track in the CRTC state if DSC is enabled on any CRTC on an MST link. The intel_link_bw_limits::force_fec_pipes mask is used for a reason similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST link if DSC is enabled on any of the link's CRTCs. The FEC enabled state for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is always enabled by the HW for UHBR, hence it's not tracked by the intel_crtc_state::fec_enable flag for such links, where this flag is always false). Based on the above, to be able to determine the DSC state on both non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link state (instead of the FEC-enabled-on-link state) for each CRTC in intel_link_bw_limits. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Track DSC enabled status on the MST linkImre Deak
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI) this will always match the CRTC's DSC state, those links having only a single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will be as follows: CRTC#0: - compression_enable = true - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b CRTC#1: - compression_enable = false - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b This patch only sets compression_enabled_on_link for CRTC#0 above and enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b MST link. A follow-up change will make sure that the state of all the CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on any CRTC, setting compression_enabled_on_link and fec_enable for these. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC configImre Deak
Reuse the DP-SST helper to compute the state for the FEC enabled state for DP-MST as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17drm/i915/dp: Export helper to determine if FEC on non-UHBR links is requiredImre Deak
Export the helper function to determine if FEC is required on a non-UHBR (8b10b) SST or MST link. A follow up change will take this into use for MST as well. While at it determine the output type from the CRTC state, which allows dropping the intel_dp argument. Also make the function return the required FEC state, instead of setting this in the CRTC state, which allows only querying this requirement, without changing the state. Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that the function determines if FEC is required on an 8b10b link (on 128b132b links FEC is always enabled by the HW implicitly, so the function will return false for that case). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17drm/i915/dp: Ensure the FEC state stays disabled for UHBR linksImre Deak
Atm, in the DP SST case the FEC state is computed before intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr() will always return false and the FEC state will be always computed assuming a non-UHBR link. This happens to work, since the FEC state is recomputed later in intel_dp_mtp_tu_compute_config(), where port_clock will be set already, so intel_crtc_state::fec_enable will be reset as expected for UHBR. This also depends on link rates being tried in an increasing order (i.e. from non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus intel_crtc_state::fec_enable being set for the non-UHBR rates and getting reset for the first UHBR rate as expected. A follow-up change will reuse intel_dp_fec_compute_config() for the DP MST state computation, prepare for that here, making sure that the function determines the correct intel_crtc_state::fec_enable=false state for UHBR link rates based on the above. The DP SST and MST state computation should be further unified to avoid computing/setting the intel_crtc_state::fec_enable state multiple times, but that's left for a follow-up change. For now add only code comments about this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17drm/i915/dsc: Add helper to enable the DSC configuration for a CRTCImre Deak
Add a helper to enable the DSC compression configuration for a CRTC. Follow-up changes will introduce tracking for the same DSC state on the whole link, which will need to be set whenever DSC is enabled for the CRTC. Also, according to the above, when querying the DSC state on the link, both the CRTC's and the link's DSC state must be considered. Setting the DSC configuration for a CRTC and querying the DSC configuration for the link (added by follow-up changes) is better done via helper functions based on the above, prepare for that here. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17drm/xe/pf: Allow to restore auto-provisioning modeMichal Wajdeczko
After doing tweaks to the VFs provisioning we may want to restore back the auto-provisioning mode. Allow that unless VFs are still enabled. This can be also used to release all VFs resources. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Disable auto-provisioning if changed using debugfsMichal Wajdeczko
When we attempt to tweak VFs configurations using debugfs, stop assuming that VFs need auto-(un)provisioning. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Automatically provision VFs only in auto-modeMichal Wajdeczko
We shouldn't attempt to auto-provision VFs once we allow other provisioning methods. Make the code aware of the new condition. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Promote VFs provisioning helpersMichal Wajdeczko
As we plan to add more VFs provisioning methods, start moving related code into single place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Always expose VRAM provisioning data on discrete GPUsLukasz Laguna
Currently, VRAM provisioning data is only exposed if the device supports LMTT. While it should not be possible to modify VRAM provisioning on platforms without LMTT, it is still useful to be able to read the VRAM provisioning data on all discrete GPU platforms. Expose the VRAM debugfs attributes whenever running on dGFX, adjusting file permissions to read only when LMTT is not available. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251016122233.3789-1-lukasz.laguna@intel.com
2025-10-17drm/panthor: Fix kernel panic on partial unmap of a GPU VA regionAkash Goel
This commit address a kernel panic issue that can happen if Userspace tries to partially unmap a GPU virtual region (aka drm_gpuva). The VM_BIND interface allows partial unmapping of a BO. Panthor driver pre-allocates memory for the new drm_gpuva structures that would be needed for the map/unmap operation, done using drm_gpuvm layer. It expected that only one new drm_gpuva would be needed on umap but a partial unmap can require 2 new drm_gpuva and that's why it ended up doing a NULL pointer dereference causing a kernel panic. Following dump was seen when partial unmap was exercised. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078 Mem abort info: ESR = 0x0000000096000046 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000 [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000 Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP <snip> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor] sp : ffff800085d43970 x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000 x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000 x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010 x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58 x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7 x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001 x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078 Call trace: panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] op_remap_cb.isra.22+0x50/0x80 __drm_gpuvm_sm_unmap+0x10c/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xb4/0x3d0 [panthor] panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor] panthor_ioctl_vm_bind+0x160/0x4a0 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x240/0x500 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251017102922.670084-1-akash.goel@arm.com
2025-10-17drm/xe/uapi: Hide the madvise autoreset behind a VM_BIND flagThomas Hellström
The madvise implementation currently resets the SVM madvise if the underlying CPU map is unmapped. This is in an attempt to mimic the CPU madvise behaviour. However, it's not clear that this is a desired behaviour since if the end app user relies on it for malloc()ed objects or stack objects, it may not work as intended. Instead of having the autoreset functionality being a direct application-facing implicit UAPI, make the UMD explicitly choose this behaviour if it wants to expose it by introducing DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET, and add a semantics description. v2: - Kerneldoc fixes. Fix a commit log message. Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: "Falkowski, John" <john.falkowski@intel.com> Cc: "Mrozek, Michal" <michal.mrozek@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-2-thomas.hellstrom@linux.intel.com
2025-10-17drm/xe: Retain vma flags when recreating and splitting vmas for madviseThomas Hellström
When splitting and restoring vmas for madvise, we only copied the XE_VMA_SYSTEM_ALLOCATOR flag. That meant we lost flags for read_only, dumpable and sparse (in case anyone would call madvise for the latter). Instead, define a mask of relevant flags and ensure all are replicated, To simplify this and make the code a bit less fragile, remove the conversion to VMA_CREATE flags and instead just pass around the gpuva flags after initial conversion from user-space. Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-1-thomas.hellstrom@linux.intel.com
2025-10-17drm/gpusvm, drm/xe: Allow mixed mappings for userptrMatthew Brost
Compute kernels often issue memory copies immediately after completion. If the memory being copied is an SVM pointer that was faulted into the device and then bound via userptr, it is undesirable to move that memory. Worse, if userptr is mixed between system and device memory, the bind operation may be rejected. Xe already has the necessary plumbing to support userptr with mixed mappings. This update modifies GPUSVM's get_pages to correctly locate pages in such mixed mapping scenarios. v2: - Rebase (Thomas Hellström) v3: - Remove Fixes tag. v4: - Break out from series since the other patch was merged. - Update patch subject, ensure dri-devel and Maarten are CC'd. Cc: Maarten Lankhorst <maarten.lankhorst@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015120320.176338-1-thomas.hellstrom@linux.intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-10-17Merge tag 'drm-xe-fixes-2025-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Increase global invalidation timeout to handle some workloads (Kenneth Graunke) - Fix NPD while evicting BOs in an array of VM binds (Matthew Brost) - Fix resizable BAR to account for possibly needing to move BARs other than the LMEMBAR (Lucas De Marchi) - Fix error handling in xe_migrate_init() (Thomas Hellström) - Fix atomic fault handling with mixed mappings or if the page is already in VRAM (Matthew Brost) - Enable media samplers power gating for platforms before Xe2 (Vinay Belgaumkar) - Fix de-registering exec queue from GuC when unbinding (Matthew Brost) - Ensure data migration to system if indicated by madvise with SVM (Thomas Hellström) - Fix kerneldoc for kunit change (Matt Roper) - Always account for cacheline alignment on migration (Matthew Auld) - Drop bogus assertion on eviction (Matthew Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/rch735eqkmprfyutk3ux2fsqa3e5ve4p77w7a5j66qdpgyquxr@ao3wzcqtpn6s
2025-10-17Merge tag 'drm-misc-fixes-2025-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: ast: - Fix display output after reboot bridge: - lt9211: Fix version check core: - draw: Avoid color truncation - gpuvm: Avoid kernel-doc warning - sched: Avoid double free panthor: - Fix MCU suspend qaic: - Init bootlog in correct order - Treat remaining == 0 as error in find_and_map_user_pages() - Lock access to DBC request queue rockchip: - vop2: Fix destination size in atomic check Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251016141607.GA73919@linux.fritz.box
2025-10-16drm/i915: Fix conversion between clock ticks and nanosecondsUmesh Nerlige Ramappa
When tick values are large, the multiplication by NSEC_PER_SEC is larger than 64 bits and results in bad conversions. The issue is seen in PMU busyness counters that look like they have wrapped around due to bad conversion. i915 PMU implementation returns monotonically increasing counters. If a count is lesser than previous one, it will only return the larger value until the smaller value catches up. The user will see this as zero delta between two measurements even though the engines are busy. Fix it by using mul_u64_u32_div() Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14955 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://lore.kernel.org/r/20251016000350.1152382-2-umesh.nerlige.ramappa@intel.com
2025-10-17drm/i915: Include the per-crtc minimum cdclk in the crtc state dumpVille Syrjälä
Include the crtc minimum cdclk in the crtc state dump. Might help figuring out who needed how much cdclk. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-9-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915: Compute per-crtc min_cdclk earlierVille Syrjälä
Currently we compute the min_cdclk for each pipe during intel_cdclk_atomic_check(). But that is too late for the pipe prefill vs. vblank length checks (done during intel_compute_global_watermarks). We can't just reorder these things due to other dependencies, so instead pull only the per-crtc minimum cdclk calculation ahead. We should have enough information for that as soon as we've computed the min cdclk for the planes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-8-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915: s/min_cdck[]/plane_min_cdclk[]/Ville Syrjälä
Rename crtc_state->min_cdclk[] into crtc_state->plane_min_cdclk[] to better reflect what it represents. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-7-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915/fbc: Decouple FBC from intel_cdclk_atomic_check()Ville Syrjälä
Always account for FBC requirements in intel_crtc_compute_min_cdclk() so that we don't have to worry about the actual CDCLK frequency in intel_fbc_check_plane() any longer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915/ips: Eliminate the cdclk_state stuff from hsw_ips_compute_config()Ville Syrjälä
Reorganize the IPS CDCLK handling such that the computed CDCLK frequency will always satisfy the IPS requirements. The only exceptional case is if IPS would push the CDCLK above the platform max, but in that case we can simply disable IPS. To make this 100% race free we must move the enable_ips modparam check out from the min CDCLK computation path so that there is no chance of hsw_min_cdclk() and hsw_ips_compute_config() observing a different enable_ips value during the same commit. This allows us to completely remove the cdclk_state stuff from the IPS code. We only ever have to compare the IPS min CDCLK against the platform max CDCLK. Thus we eliminate any ordering requirements between intel_cdclk_atomic_check() and hsw_ips_compute_config(). Additionally we reduce the three copies of the code doing the 95% calculation into just one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915/bw: Relocate intel_bw_crtc_min_cdclk()Ville Syrjälä
intel_bw_crtc_min_cdclk() (aka. the thing that deals with what bspec calls "Maximum Pipe Read Bandwidth") doesn't really have anything to do with the rest of intel_bw.c (which is all about SAGV/QGV and memory bandwidth). Move it into intel_crtc.c (for the lack of a better place). And I don't really want to call intel_bw.c functions from intel_crtc.c, so move out intel_bw_crtc_data_rate() as well. And when we move that we pretty much have to move intel_bw_crtc_num_active_planes() as well since the two are meant to be used as a pair (they both implement the same "ignore the cursor" logic). And in an effort to keep the namespaces at least semi-sensible we flip the intel_bw_crtc_ prefix into intel_crtc_bw_. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915: s/"not not"/"not"/Ville Syrjälä
Elimiante the repeated "not not" in the bw code comments. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17drm/i915/bw: Untangle dbuf bw from the sagv/mem bw stuffVille Syrjälä
Currently intel_bw.c contains basically three completely independent parts: - SAGV/memory bandwidth handling - DBuf bandwidth handling - "Maximum pipe read bandwidth" calculation, which is some kind of internal per-pipe bandwidth limit. Carve out the DBuf bandwdith handling into a separate file since there is no actual dependency between it and the rest of intel_bw.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-17Merge tag 'amd-drm-fixes-6.18-2025-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-10-16: amdgpu: - Backlight fix - SI fixes - CIK fix - Make CE support debug only - IP discovery fix - Ring reset fixes - GPUVM fault memory barrier fix - Drop unused structures in amdgpu_drm.h - JPEG debugfs fix - VRAM handling fixes for GPUs without VRAM - GC 12 MES fixes amdkfd: - MES fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251016132224.2534946-1-alexander.deucher@amd.com
2025-10-16drm/i915: move and rename reg_in_range_tableMatt Atwood
reg_in_range_table is a useful function that is used in multiple places, and will be needed for WA_BB implementation later. Let's move this function and i915_range struct to its own file, as we are trying to move away from i915_utils files. v2: move functions to their own file v3: use correct naming convention Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20251009215210.41000-1-matthew.s.atwood@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-16drm/xe: Prevent runtime PM wake while reading rp0 frequencyBadal Nilawar
The rp0 frequency is a fused value that is read once during probe and then cached, so there’s no need to trigger a runtime wake when accessing rp0. Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Karthik Poosa <karthik.poosa@intel.com> Link: https://lore.kernel.org/r/20251015094611.1468939-1-badal.nilawar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-16drm/rockchip: dw_hdmi: use correct SCLIN mask for RK3228Alok Tiwari
In dw_hdmi_rk3228_setup_hpd(), the SCLIN mask incorrectly references the RK3328 variant. This change updates it to the RK3228-specific mask RK3228_HDMI_SCLIN_MSK using FIELD_PREP_WM16, ensuring proper HPD and I2C pin configuration for RK3228. Change: RK3328_HDMI_SCLIN_MSK -> RK3228_HDMI_SCLIN_MSK Fixes: 63df37f3fc71 ("drm/rockchip: dw_hdmi: switch to FIELD_PREP_WM16* macros") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251010173143.72733-1-alok.a.tiwari@oracle.com
2025-10-16drm/i915/wm: Use skl_prefillVille Syrjälä
Replace the current ad-hoc prefill calculations with skl_prefill. v2: cdclk_state no longer needed Rename to skl_prefill Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-10-ville.syrjala@linux.intel.com
2025-10-16drm/i915/prefill: Introduce skl_prefill.cVille Syrjälä
Add a new helper thingy to deal with the pipe prefill latency. We get three potentially useful thigns out of this: - skl_prefill_vblank_too_short() used for checking the actual vblank/guardband length - skl_prefill_min_guardband() to calculate a suitable guardband size based on some worst case scaling/etc. estimates - skl_prefill_min_cdclk() used to calculate a minimum cdclk frequency required for very small vblank lengths (in case the otherwise computed minimum cdclk doesn't result in fast enough prefill). The internal arithmetic is done terms of scanlines using .16 binary fixed point representation. v2: Add the missing <<16 for framestart_delay Drop the cdclk_state stuff in favor of crtc_state->min_cdclk Rename to skl_prefill since this is skl+ only Use intel_crtc_vblank_length() instead of hand rolling it memset(0) in prefill_init() Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-9-ville.syrjala@linux.intel.com
2025-10-16drm/i915/wm: Add WM0 prefill helpersVille Syrjälä
Add skl_wm0_prefill_lines() (based on the actual state) and skl_wm0_prefill_lines_worst() (worst case estimate) which tell us how many extra lines are needed in prefill for WM0. The returned numbers are in .16 binary fixed point. TODO: skl_wm0_prefill_lines_worst() is a bit rough still v2: Drop all pre-icl FIXMEs since this only gets used for VRR guardband Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-8-ville.syrjala@linux.intel.com
2025-10-16drm/i915/scaler: Add scaler prefill helpersVille Syrjälä
Add helpers to compute the required prefill line count and adjustment factors for the scalers. The "1st" variants hand out numbers for the first scaler stage in the pipeline (pipe scaler if no plane scalers are enabled, or the max from all the plane scaler). The "2nd" variants deal with second scaler stage (pipe scaler when plane scaling is also enabled, otherwise there is no second stage). The _worst() variants give out worst case estimates, meant for guardband sizing. The other variants are meant for the actual vblank/guardband length check vs. prefill+pkgc/sagv latency. The returned numbers are in .16 binary fixed point. TODO: pretty rough, should check the actual scaler max scaling factors instead of just assuming 3x everywhere TODO: Reorder scaler assignment vs. vblank length check to get the actual scale factors v2: Drop debugs v3: Ignore scale factors for the vblank length check for now since we don't have the scalers assigned yet Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251015125645.11230-1-ville.syrjala@linux.intel.com
2025-10-16drm/i915/dsc: Add prefill helper for DSCVille Syrjälä
Add intel_vdsc_prefill_lines() which tells us how many extra lines of latency the DSC adds to the pipe prefill. We shouldn't need a "worst case" vs, "current case" split here as the DSC state should only change during full modesets. The returned numbers are in .16 binary fixed point. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-6-ville.syrjala@linux.intel.com
2025-10-16drm/i915/cdclk: Add intel_cdclk_min_cdclk_for_prefill()Ville Syrjälä
Introduce a helper to compute the min required cdclk frequency for a given guardband size. This could be used to bump up the cdclk in case the vblank is so small that the normally computed minimum cdclk results in too slow a prefill. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-5-ville.syrjala@linux.intel.com
2025-10-16drm/i915/cdclk: Add prefill helpers for CDCLKVille Syrjälä
Add helpers to compute the CDCLKl adjustment factor for prefill calculations. The adjustment factor is always <= 1.0. That is, a faster CDCLK speeds up the pipe prefill. intel_cdclk_prefill_adjustment_worst() gives out a worst case estimate, meant to be used during guardband sizing. We can actually do better than 1.0 here because the absolute minimum CDCLK is limited by the dotclock. This will still allow planes, pfit, etc. to be changed any which way without having to resize the guardband yet again. intel_cdclk_prefill_adjustment() is supposed to give a more accurate value based on the current min cdclk for the pipe, but currently that is not yet available when this gets called. So for now use the same worst case estimate here. The returned numbers are in .16 binary fixed point. TODO: the intel_cdclk_prefill_adjustment_worst() approach here can result in guardband changes for DRRS. But I'm thinking that is fine since M/N changes will always happen on the legacy timing generator so guardband doesn't actually matter. May need to think about this a bit more though... v2: Use the worst case estimate always for now Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-4-ville.syrjala@linux.intel.com
2025-10-16drm/i915: Reject modes with linetime > 64 usecVille Syrjälä
Reject modes whose linetime exceeds 64 usec. First reason being that WM_LINETIME is limited to (nearly) 64 usec. Additionally knowing the linetime is bounded will help with determining whether overflows may be a concern during various calculations. I decided to round up, and accept the linetime==64 case. We use various rounding directions for this in other parts of the code, so I feel this provides the most consistent result all around. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-3-ville.syrjala@linux.intel.com
2025-10-16drm/komeda: Convert logging in komeda_crtc.c to drm_* with drm_device parameterRahul Kumar
Replace all dev_err(), dev_warn(), dev_info() and DRM_ERROR/WARN/INFO() calls in drivers/gpu/drm/arm/display/komeda/komeda_crtc.c with the corresponding drm_err(), drm_warn(), and drm_info() helpers. The new drm_*() logging functions take a struct drm_device * as the first argument. This allows the DRM core to prefix log messages with the specific DRM device name and instance, which is essential for distinguishing logs when multiple GPUs or display controllers are present. This change aligns komeda with the DRM TODO item: "Convert logging to drm_* functions with drm_device parameter". Signed-off-by: Rahul Kumar <rk0006818@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250926093008.1949131-1-rk0006818@gmail.com
2025-10-16drm/ci: disable broken MR check in sanity jobVignesh Raman
GitLab recently changed the required permissions for the are-developers-allowed-to-push-to-my-MR check: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/81 Until that’s resolved, disable the check - it’s mostly obsolete anyway. Based on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37782 Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Patchwork: https://patchwork.freedesktop.org/patch/680263/ Message-ID: <20251013060212.14583-1-vignesh.raman@collabora.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-10-16drm/msm: make sure last_fence is always updatedAnna Maniscalco
Update last_fence in the vm-bind path instead of kernel managed path. last_fence is used to wait for work to finish in vm_bind contexts but not used for kernel managed contexts. This fixes a bug where last_fence is not waited on context close leading to faults as resources are freed while in use. Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue") Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/680080/ Message-ID: <20251011-close_fence_wait_fix-v3-1-5134787755ff@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-10-16drm/msm/a6xx: Fix GMU firmware parserAkhil P Oommen
Current parser logic for GMU firmware assumes a dword aligned payload size for every block. This is not true for all GMU firmwares. So, fix this by using correct 'size' value in the calculation for the offset for the next block's header. Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/674040/ Message-ID: <20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-10-16drm/msm: Fix pgtable prealloc error pathRob Clark
The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Reported-by: Connor Abbott <cwabbott0@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/678677/ Message-ID: <20251006153542.419998-1-robin.clark@oss.qualcomm.com>
2025-10-16drm/i915/display: Prepare for vblank_delay for LRRAnkit Nautiyal
Update allow_vblank_delay_fastset() to permit vblank delay adjustments during with LRR when VRR TG is always active. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251016055415.2101347-11-ankit.k.nautiyal@intel.com
2025-10-16drm/i915/display: Add vblank_start adjustment logic for always-on VRR TGAnkit Nautiyal
As we move towards using a shorter, optimized guardband, we need to adjust how the delayed vblank start is computed. Adjust the crtc_vblank_start using Vmin Vtotal - guardband only when intel_vrr_always_use_vrr_tg() is true. Also update the pipe_mode->crtc_vblank_start which is derived from adjusted_mode->crtc_vblank_start in intel_crtc_compute_pipe_mode(). To maintain consistency between the computed and readout paths, update the readout logic in intel_vrr_get_config() to overwrite crtc_vblank_start with the same value (vtotal - guardband) on platforms with always-on VRR TG. This also paves way for guardband optimization, by handling the movement of the crtc_vblank_start for platforms that have VRR TG always active. v2: Drop the helper and add the adjustment directly to intel_vrr_compute_guardband(). (Ville) v3: Use adjusted_mode.crtc_vtotal instead of vmin and include the readout logic to keep the compute and readout paths in sync. (Ville) v4: Also set pipe_mode->crtc_vblank_start as its derived from adjusted_mode. (Ville) v5: Add a comment about rationale behind updating pipe_mode->crtc_vblank_start. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251016055415.2101347-10-ankit.k.nautiyal@intel.com
2025-10-16drm/i915/psr: Check if final vblank is sufficient for PSR featuresAnkit Nautiyal
Currently, wake line latency checks rely on the vblank length, which does not account for either the extra vblank delay for icl/tgl or for the optimized guardband which will come into picture later at some point. Validate whether the final vblank (with extra vblank delay) or guardband is sufficient to support wake line latencies required by Panel Replay and PSR2 selective update. Disable the PSR features if their wake requirements cannot be accomodated. v2: Add comments clarifying wake line checks and rationale for not resetting SCL. (Jouni) v3: Reset other psr flags based on features that are dropped. (Jouni) v4: Update commit message. v5: Remove early return and simplify the checking for wakelines. (Jouni) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251016055415.2101347-9-ankit.k.nautiyal@intel.com
2025-10-16drm/i915/display: Introduce dp/psr_compute_config_late()Ankit Nautiyal
Introduce intel_dp_compute_config_late() to handle late-stage configuration checks for DP/eDP features. For now, it paves path for psr_compute_config_late() to handle psr parameters that need to be computed late. Move the handling of psr_flag for Wa_18037818876 and setting of non-psr pipes to intel_psr_compute_config_late() as these are the last things to be configured for PSR features. v2: Update dp_compute_config_late() to return int. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> (#v1) Link: https://lore.kernel.org/r/20251016055415.2101347-8-ankit.k.nautiyal@intel.com
2025-10-16drm/i915/psr: Introduce helper intel_psr_set_non_psr_pipes()Ankit Nautiyal
Add a function to set non-psr pipes in crtc_state based on psr features. This will help to move this part later where we re-evaluate psr features and update the non-psr pipes. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251016055415.2101347-7-ankit.k.nautiyal@intel.com
2025-10-16drm/i915/psr: Consider SCL lines when validating vblank for wake latencyAnkit Nautiyal
Panel Replay and PSR2 selective update require sufficient vblank duration to accommodate wake latencies. However, the current wake_lines_fit_into_vblank() logic does not account for the minimum Set Context Latency (SCL) lines. Separate out _intel_psr_min_set_context_latency() to compute the minimum SCL requirement based on platform and feature usage. The alpm_config_valid() helper is updated to pass the necessary context for determining whether Panel Replay or PSR2 selective update is enabled. v2: While calling alpm_config_valid() for selective_update use false flag instead of has_panel_replay. (Jouni) v3: Correct ordering of the panel_replay, sel_update flags. (Jouni) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251016055415.2101347-6-ankit.k.nautiyal@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-15 05:20:26 +0000