summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-07-15drm/xe/pf: Prepare to stop SR-IOV support prior GT resetMichal Wajdeczko3-0/+27
As part of the resume or GT reset, the PF driver schedules work which is then used to complete restarting of the SR-IOV support, including resending to the GuC configurations of provisioned VFs. However, in case of short delay between those two actions, which could be seen by triggering a GT reset on the suspened device: $ echo 1 > /sys/kernel/debug/dri/0000:00:02.0/gt0/force_reset this PF worker might be still busy, which lead to errors due to just stopped or disabled GuC CTB communication: [ ] xe 0000:00:02.0: [drm:xe_gt_resume [xe]] GT0: resumed [ ] xe 0000:00:02.0: [drm] GT0: trying reset from force_reset_show [xe] [ ] xe 0000:00:02.0: [drm] GT0: reset queued [ ] xe 0000:00:02.0: [drm] GT0: reset started [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel stopped [ ] xe 0000:00:02.0: [drm:guc_ct_send_recv [xe]] GT0: H2G request 0x5503 canceled! [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 12 config KLVs (-ECANCELED) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 configuration (-ECANCELED) [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel disabled [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 12 config KLVs (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 configuration (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push 2 of 2 VFs configurations [ ] xe 0000:00:02.0: [drm:pf_worker_restart_func [xe]] GT0: PF: restart completed While this VFs reprovisioning will be successful during next spin of the worker, to avoid those errors, make sure to cancel restart worker if we are about to trigger next reset. Fixes: 411220808cee ("drm/xe/pf: Restart VFs provisioning after GT reset") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250711193316.1920-2-michal.wajdeczko@intel.com
2025-07-15drm/i915: Don't check for atomic context on PREEMPT_RTSebastian Andrzej Siewior1-2/+7
The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT because the uncore::lock is a spinlock_t and does not disable preemption or interrupts. Changing the uncore:lock to a raw_spinlock_t doubles the worst case latency on an otherwise idle testbox during testing. Ignore _WAIT_FOR_ATOMIC_CHECK() on PREEMPT_RT. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/ Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20250714153954.629393-4-bigeasy@linutronix.de Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-07-14drm/xe/lrc: Add table with LRC layoutLucas De Marchi1-0/+24
Add a table to document the LRC's BO layout to make it easier to visualize how each region stacks on top of each other. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-4-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Waste fewer instructions in emit_wa_job()Tvrtko Ursulin3-41/+49
I was debugging some unrelated issue and noticed the current code was very verbose. We can improve it easily by using the more common batch buffer building pattern. Before: bb->cs[bb->len++] = MI_LOAD_REGISTER_REG | MI_LRR_DST_CS_MMIO; c4d: 41 8b 56 10 mov 0x10(%r14),%edx c51: 49 8b 4e 08 mov 0x8(%r14),%rcx c55: 8d 72 01 lea 0x1(%rdx),%esi c58: 41 89 76 10 mov %esi,0x10(%r14) c5c: c7 04 91 01 00 08 15 movl $0x15080001,(%rcx,%rdx,4) bb->cs[bb->len++] = entry->reg.addr; c63: 8b 08 mov (%rax),%ecx c65: 41 8b 56 10 mov 0x10(%r14),%edx c69: 49 8b 76 08 mov 0x8(%r14),%rsi c6d: 81 e1 ff ff 3f 00 and $0x3fffff,%ecx c73: 8d 7a 01 lea 0x1(%rdx),%edi c76: 41 89 7e 10 mov %edi,0x10(%r14) c7a: 89 0c 96 mov %ecx,(%rsi,%rdx,4) ..etc.. After: *cs++ = MI_LOAD_REGISTER_REG | MI_LRR_DST_CS_MMIO; c52: 41 c7 04 24 01 00 08 movl $0x15080001,(%r12) c59: 15 *cs++ = entry->reg.addr; c5a: 8b 10 mov (%rax),%edx ..etc.. Resulting in the following binary change: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-348 (-348) Function old new delta xe_gt_record_default_lrcs.cold 304 296 -8 xe_gt_record_default_lrcs 2200 1860 -340 Total: Before=13554, After=13206, chg -2.57% Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-7-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/gt: Drop third submission for default contextLucas De Marchi1-8/+0
There's no need to submit the nop job again on the first queue. Any state needed is already saved when the first LRC is switched out. The comment is a little misleading regarding indirect W/A: first of all there's still no indirect W/A enabled and secondly, even after they are, there's no need to submit this job again for having their state propagated: the indirect W/A will actually run on every LRC switch. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-6-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/lrc: Remove leftover TODO/FIXMELucas De Marchi1-6/+0
There isn't anything to set for CTX_TIMESTAMP handling in the empty LRC: that is set on every LRC init since it should always start from 0 rather than the value saved in the image after first submission. The FIXME about perma-pinning also doesn't make much sense as we will always going to pin the lrc and the GGTT mapping has nothing to do with VM bind. Nuke these leftover comments. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-5-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/gt: Extract emit_job_sync()Lucas De Marchi1-32/+22
Both the nop and wa jobs are going through the same boiler plate calls to emit the job with a timeout and handling error for both bb and job. Extract emit_job_sync() so those functions create the bb, handling possible errors and delegate the part about really emitting the job and waiting for its completion. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-3-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Count dwords before allocatingLucas De Marchi2-15/+25
The bb allocation in emit_wa_job() is wrong in 2 ways: first it's allocating enough space for the 3DSTATE or hardcoding 4k depending on the engine. In the first case it doesn't account for the WAs and in the former it may not be sufficient. Secondly it's using the size instead of number of dwords, causing the buffer to be 4x bigger than needed: xe_bb_new() receives number of dwords as parameter and its declaration was also not following its implementation. Lastly, reword the debug message since it's not only about the LRC WAs anymore as it also include the 3DSTATE for render. While it's unlikely this is causing any real issue, let's calculate the needed space and allocate just enough. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-2-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/lrc: Reduce scope of empty lrc dataLucas De Marchi1-11/+11
The only case in which new lrc data is created from scratch is when it's called prior to recording the default lrc. There's no need to check for NULL init_data since in that case the function already failed: just move the allocation where it's needed. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-1-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/panel-edp: Add BOE NE14QDM panel for Dell Latitude 7455Val Packett1-0/+1
Cannot confirm which variant exactly it is, as the EDID alphanumeric data contains '0RGNR' <0x80> 'NE14QDM' and ends there; but it's 60 Hz and with touch. I do not have access to datasheets for these panels, so the timing is a guess that was tested to work fine on this laptop. Raw EDID dump: 00 ff ff ff ff ff ff 00 09 e5 1e 0b 00 00 00 00 10 20 01 04 a5 1e 13 78 07 fd 85 a7 53 4c 9b 25 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a7 6d 00 a0 a0 40 78 60 30 20 36 00 2e bc 10 00 00 1a b9 57 00 a0 a0 40 78 60 30 20 36 00 2e bc 10 00 00 1a 00 00 00 fe 00 30 52 47 4e 52 80 4e 45 31 34 51 44 4d 00 00 00 00 00 02 41 31 a8 00 01 00 00 1a 41 0a 20 20 00 8f Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250706205723.9790-7-val@packett.cool
2025-07-14drm/xe/vf: Store negotiated VF/PF ABI version at device levelMichal Wajdeczko3-24/+30
There is no need to maintain PF ABI version on per-GT level. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-8-michal.wajdeczko@intel.com
2025-07-14drm/xe/pf: Stop requiring VF/PF version negotiation on every GTMichal Wajdeczko12-403/+548
While some VF/PF relay actions must be handled on the GT level, like query for runtime registers, it was clarified by the arch team that initial version negotiation can be done by the VF just once, by using any available GuC/GT. Move handling of the VF/PF ABI version negotiation on the PF side from the GT level functions to the device level functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-7-michal.wajdeczko@intel.com
2025-07-14drm/xe/pf: Expose basic info about VFs in debugfsMichal Wajdeczko3-0/+53
We already have function to print summary about VFs, but we missed to add debugfs attribute to make it visible. Do it now. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-6-michal.wajdeczko@intel.com
2025-07-14drm/xe: Introduce xe_gt_is_main_type helperMichal Wajdeczko10-34/+39
Instead of checking for not being a media type GT provide a small helper to explicitly express our intentions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-5-michal.wajdeczko@intel.com
2025-07-14drm/xe: Introduce xe_tile_is_root helperMichal Wajdeczko3-2/+10
Instead of looking at the tile->id member provide a small helper to explicitly express our intentions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-4-michal.wajdeczko@intel.com
2025-07-14drm/xe: Move PF and VF device types to separate headersMichal Wajdeczko4-36/+58
We plan to add more PF and VF types and mixing them in a single file is not desired. Move them out to new dedicated files. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-3-michal.wajdeczko@intel.com
2025-07-14drm/panthor: Remove dead VM flushing codeAdrián Larumbe2-12/+0
Commit ec62d37d2c0d("drm/panthor: Fix the fast-reset logic") did away with the only reference to panthor_vm_flush_all(), so let's get rid of the orphaned definition. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250711154557.739326-1-adrian.larumbe@collabora.com
2025-07-14drm/xe: Combine PF and VF device data into unionMichal Wajdeczko1-4/+6
There is no need to keep PF and VF data fields fully separate since we can be only in one mode at the time. Move them into a anonymous union to save few bytes. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250713103625.1964-2-michal.wajdeczko@intel.com
2025-07-14drm/panfrost: Fix scheduler workqueue bugPhilipp Stanner1-1/+1
When the GPU scheduler was ported to using a struct for its initialization parameters, it was overlooked that panfrost creates a distinct workqueue for timeout handling. The pointer to this new workqueue is not initialized to the struct, resulting in NULL being passed to the scheduler, which then uses the system_wq for timeout handling. Set the correct workqueue to the init args struct. Cc: stable@vger.kernel.org # 6.15+ Fixes: 796a9f55a8d1 ("drm/sched: Use struct for drm_sched_init() params") Reported-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Closes: https://lore.kernel.org/dri-devel/b5d0921c-7cbf-4d55-aa47-c35cd7861c02@igalia.com/ Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250709102957.100849-2-phasta@kernel.org
2025-07-14drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to ↵Imre Deak1-1/+1
TRAINING_PATTERN_SET Commit a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for DPCD probing, since this results in link training failures at least when using an Intel Barlow Ridge TBT hub at UHBR link rates (the DP_INTRA_HOP_AUX_REPLY_INDICATION never getting cleared after the failed link training). Since accessing DPCD_REV during link training is prohibited by the DP Standard, LANE0_1_STATUS (0x202) was used instead, as it falls within the Standard's valid register address range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) and it fixed the link training on the above TBT hub. However, reading the LANE0_1_STATUS register also has a side-effect at least on a Novatek eDP panel, as reported on the Closes: link below, resulting in screen flickering on that panel. One clear side-effect when doing the 1-byte probe reads from LANE0_1_STATUS during link training before reading out the full 6 byte link status starting at the same address is that the panel will report the link training as completed with voltage swing 0. This is different from the normal, flicker-free scenario when no DPCD probing is done, the panel reporting the link training complete with voltage swing 2. Using the TRAINING_PATTERN_SET register for DPCD probing doesn't have the above side-effect, the panel will link train with voltage swing 2 as expected and it will stay flicker-free. This register is also in the above valid register range and is unlikely to have a side-effect as that of LANE0_1_STATUS: Reading LANE0_1_STATUS is part of the link training CR/EQ sequences and so it may cause a state change in the sink - even if inadvertently as I suspect in the case of the above Novatek panel. As opposed to this, reading TRAINING_PATTERN_SET is not part of the link training sequence (it must be only written once at the beginning of the CR/EQ sequences), so it's unlikely to cause any state change in the sink. As a side-note, this Novatek panel also lacks support for TPS3, while claiming support for HBR2, which violates the DP Standard (the Standard mandating TPS3 for HBR2). Besides the Novatek panel (PSR 1), which this change fixes, I also verified the change on a Samsung (PSR 1) and an Analogix (PSR 2) eDP panel as well as on the Intel Barlow Ridge TBT hub. Note that in the drm-tip tree (targeting the v6.17 kernel version) the i915 and xe drivers keep DPCD probing enabled only for the panel known to require this (HP ZR24w), hence those drivers in drm-tip are not affected by the above problem. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Fixes: a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") Reported-and-tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14558 Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250708212331.112898-1-imre.deak@intel.com
2025-07-14drm/xe: Update register definitions in LRC layout headerXin Wang2-4/+3
Update the register definitions in xe_lrc_layout.h to align with the official hardware specification (Bspec) terminology. Specifically: - rename PVC_CTX_ACC_CTR_THOLD to CTX_ACC_CTR_THOLD - rename PVC_CTX_ASID to CTX_ASID Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711060924.7373-1-x.wang@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/bridge: Pass down connector to drm bridge detect hookAndy Yan31-38/+65
In some application scenarios, we hope to get the corresponding connector when the bridge's detect hook is invoked. In most cases, we can get the connector by drm_atomic_get_connector_for_encoder if the encoder attached to the bridge is enabled, however there will still be some scenarios where the detect hook of the bridge is called but the corresponding encoder has not been enabled yet. For instance, this occurs when the device is hot plug in for the first time. Since the call to bridge's detect is initiated by the connector, passing down the corresponding connector directly will make things simpler. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250703125027.311109-3-andyshrk@163.com [DB: added the chunk to the cdn-dp driver] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-14drm/bridge: Make dp/hdmi_audio_* callback keep the same paramter order with ↵Andy Yan11-59/+59
get_modes Make the dp/hdmi_audio_* callback maintain the same parameter order as get_modes and edid_read: first the bridge, then the connector. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250703125027.311109-2-andyshrk@163.com [DB: added the chunk to the cdn-dp driver] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-14drm/xe: Add plumbing for indirect context workaroundsTvrtko Ursulin3-3/+89
Some upcoming workarounds need to be emitted from the indirect workaround context so lets add some plumbing where they will be able to easily slot in. No functional changes for now since everything is still deactivated. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Bspec: 45954 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-7-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Allow specifying number of extra dwords at the end of wa bb emissionTvrtko Ursulin1-3/+5
Indirect context setup will need more than one. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-6-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Track number of written dwords from workaround batch buffer emissionTvrtko Ursulin1-1/+4
Indirect context setup will need to get to the number of written dwords. Lets add it as an output parameter so it can be accessed from the finish helper regardless of whether code is writing directly or via an shadow buffer. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-5-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Rename utilization workaround emission functionTvrtko Ursulin1-3/+5
Lucas suggested to consolidate to a slightly different naming scheme which will align with the upcoming additions better. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-4-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Pass wa bb setup arguments in a structTvrtko Ursulin1-40/+53
Group the function arguments in a struct for more readable code and easier extending. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-3-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Generalize wa bb emission codeTvrtko Ursulin1-22/+48
Generalize the wa bb emission by splitting it into three phases - setup, emit and finish, and extract setup and finish steps into helpers. This will enable using the same infrastructure for emitting the indirect context workarounds. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250711160153.49833-2-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Fix missing kernel-docLucas De Marchi1-0/+1
Fix warning: Warning: drivers/gpu/drm/xe/xe_device_types.h:658 struct member 'wa_active' not described in 'xe_device' Fixes: 661a6950e061 ("drm/xe: Add infrastructure for Device OOB workarounds") Cc: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Jonathan Cavitt <joanthan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250711214911.2009714-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Remove unused functionsDr. David Alan Gilbert6-51/+0
xe_bo_create_from_data() last use was removed in 2023 by commit 0e1a47fcabc8 ("drm/xe: Add a helper for DRM device-lifetime BO create") xe_rtp_match_first_gslice_fused_off() last use was removed in 2023 by commit 4e124151fcfc ("drm/xe/dg2: Drop pre-production workarounds") Remove them, and xe_dss_mask_empty whose last use was by xe_rtp_match_first_gslice_fused_off(). (Xe has a bunch ofother symbols that have been added but not used, given how new it is, I've left those, as opposed to these that had the code that used them removed). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250713152531.219326-1-linux@treblig.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2Ankit Nautiyal3-7/+44
Some ICL/TGL platforms with combo PHY ports suffer from signal integrity issues at HBR3. While certain systems include a Parade PS8461 mux to mitigate this, its presence cannot be reliably detected. Furthermore, broken or missing VBT entries make it unsafe to rely on VBT for enforcing link rate limits. To address this introduce a device specific quirk to cap the eDP link rate to HBR2 (540000 kHz). This will override any higher advertised rates from the sink or DPCD for specific devices. Currently, the quirk is added for Dell XPS 13 7390 2-in-1 which is reported in gitlab issue #5969 [1]. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 v2: Align the quirk with the intended quirk name and refactor the condition to use min(). (Jani) v3: Use condition `rate > 540000`. Drop extra parentheses. (Ville) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-3-ankit.k.nautiyal@intel.com
2025-07-14Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"Ankit Nautiyal1-42/+7
This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6. Commit 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") introduced a blanket rejection of HBR3 link rate when the sink does not support TPS4. While this was intended to address instability observed on certain eDP panels [1], there seem to be edp panels that do not follow the specification. These eDP panels do not advertise TPS4 support, but require HBR3 to operate at their fixed native resolution [2]. As a result, the change causes blank screens on such panels. Apparently, Windows driver does not enforce this restriction, and the issue is not seen there. Therefore, revert the commit to restore functionality for such panels, and align behaviour with Windows driver. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 [2] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 v2: Update the commit message with better justification. (Ville) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-2-ankit.k.nautiyal@intel.com
2025-07-12Merge tag 'amd-drm-next-6.17-2025-07-11' of ↵Simona Vetter26-239/+270
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.17-2025-07-11: amdgpu: - Clean up function signatures - GC 10 KGQ reset fix - SDMA reset cleanups - Misc fixes - LVDS fixes - UserQ fix amdkfd: - Reset fix Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250711205548.21052-1-alexander.deucher@amd.com
2025-07-11drm/xe: Normalize default param valuesLucas De Marchi1-12/+23
Document xe module params with the default values following a similar strategy for all of them: 1) Define a DEFAULT_* macro with the default value. When the value can't be directly stringified, also define a *_STR variant 2) Use __stringify() or the _STR variant to make sure the default value shows up in the param description This allows us to show the correct default according to the configuration. max_vfs for example was wrongly documented for CONFIG_DRM_XE_DEBUG and svm_notifier_size didn't have its default documented. Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250626-guc-log-level-v3-1-c3ed8b452e91@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-11drm/xe/migrate: Fix alignment checkLucas De Marchi1-2/+2
The check would fail if the address is unaligned, but not when accounting the offset. Instead of `buf | offset` it should have been `buf + offset`. To make it more readable and also drop the uintptr_t, just use the IS_ALIGNED() macro. Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250710-migrate-aligned-v1-1-44003ef3c078@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-11drm/nouveau: check ioctl command codes betterArnd Bergmann1-6/+5
nouveau_drm_ioctl() only checks the _IOC_NR() bits in the DRM_NOUVEAU_NVIF command, but ignores the type and direction bits, so any command with '7' in the low eight bits gets passed into nouveau_abi16_ioctl() instead of drm_ioctl(). Check for all the bits except the size that is handled inside of the handler. Fixes: 27111a23d01c ("drm/nouveau: expose the full object/event interfaces to userspace") Signed-off-by: Arnd Bergmann <arnd@arndb.de> [ Fix up two checkpatch warnings and a typo. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250711072458.2665325-1-arnd@kernel.org
2025-07-11drm/xe: Remove references to CONFIG_DRM_XE_DEVMEM_MIRRORMatthew Brost1-2/+2
The prefetch code was referencing CONFIG_DRM_XE_DEVMEM_MIRROR, which has been replaced by CONFIG_DRM_XE_PAGEMAP. As a result, prefetches were limited to SRAM. Update the code to use CONFIG_DRM_XE_PAGEMAP instead of the deprecated option. Fixes: f86ad0ed620c ("drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemap") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250710205413.1105595-1-matthew.brost@intel.com
2025-07-11drm/xe: Move page fault init after topology initMatthew Brost1-3/+3
We need the topology to determine GT page fault queue size, move page fault init after topology init. Cc: stable@vger.kernel.org Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250710191208.1040215-1-matthew.brost@intel.com
2025-07-11drm/xe/migrate: fix copy direction in access_memoryMatthew Auld1-1/+1
After we do the modification on the host side, ensure we write the result back to VRAM and not the other way around, otherwise the modification will be lost if treated like a read. 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: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710134128.800756-2-matthew.auld@intel.com
2025-07-11Merge tag 'drm-misc-fixes-2025-07-10' of ↵Simona Vetter11-51/+100
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.16-rc6 or final: - Fix nouveau fail on debugfs errors. - Magic 50 ms to fix nouveau suspend. - Call rust destructor on drm device release. - Fix DMA api error handling in tegra/nvdec. - Fix PVR device reset. - Habanalabs maintainer update. - Small memory leak fix when nouveau acpi init fails. - Do not attempt to bind to any PCI device with AGP capability. - Make FB's acquire handles on backing object, same as i915/xe already does. - Fix race in drm_gem_handle_create_tail. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e522cdc7-1787-48f2-97e5-0f94783970ab@linux.intel.com
2025-07-11Merge tag 'drm-xe-fixes-2025-07-11' of ↵Simona Vetter9-23/+53
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Clear LMTT page to avoid leaking data from one VF to another - Align PF queue size to power of 2 - Disable Indirect Ring State to avoid intermittent issues on context switch: feature is not currently needed, so can be disabled for now. - Fix compression handling when the BO pages are very fragmented - Restore display pm on error path - Fix runtime pm handling in xe devcoredump - Fix xe_pm_set_vram_threshold() doc - Recommend new minor versions of GuC firmware - Drop some workarounds on VF - Do not use verbose GuC logging by default: it should be only for debugging Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/s6jyd24mimbzb4vxtgc5vupvbyqplfep2c6eupue7znnlbhuxy@lmvzexfzhrnn
2025-07-11Merge tag 'drm-intel-next-2025-07-10' of ↵Simona Vetter1-4/+4
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: - DSI panel's version 2 mipi-sequences fix (Hans) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/aHA-qrFQ00TaNsGr@intel.com
2025-07-11drm/xe: Dont skip TLB invalidations on VFTejas Upadhyay1-12/+10
Skipping TLB invalidations on VF causing unrecoverable faults. Probable reason for skipping TLB invalidations on SRIOV could be lack of support for instruction MI_FLUSH_DW_STORE_INDEX. Add back TLB flush with some additional handling. Helps in resolving, [ 704.913454] xe 0000:00:02.1: [drm:pf_queue_work_func [xe]] ASID: 0 VFID: 0 PDATA: 0x0d92 Faulted Address: 0x0000000002fa0000 FaultType: 0 AccessType: 1 FaultLevel: 0 EngineClass: 3 bcs EngineInstance: 8 [ 704.913551] xe 0000:00:02.1: [drm:pf_queue_work_func [xe]] Fault response: Unsuccessful -22 V2: - Use Xmas tree (MichalW) Suggested-by: Matthew Brost <matthew.brost@intel.com> Fixes: 97515d0b3ed92 ("drm/xe/vf: Don't emit access to Global HWSP if VF") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710045945.1023840-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2025-07-11Merge tag 'drm-xe-next-2025-07-10' of ↵Simona Vetter87-1505/+2921
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - Documentation fixes (Shuicheng) Cross-subsystem Changes: - MTD intel-dg driver for dgfx non-volatile memory device (Sasha) - i2c: designware changes to allow i2c integration with BMG (Heikki) Core Changes: - Restructure migration in preparation for multi-device (Brost, Thomas) - Expose fan control and voltage regulator version on sysfs (Raag) Driver Changes: - Add WildCat Lake support (Roper) - Add aux bus child device driver for NVM on DGFX (Sasha) - Some refactor and fixes to allow cleaner BMG w/a (Lucas, Maarten, Auld) - BMG w/a (Vinay) - Improve handling of aborted probe (Michal) - Do not wedge device on killed exec queues (Brost) - Init changes for flicker-free boot (Maarten) - Fix out-of-bounds field write in MI_STORE_DATA_IMM (Jia) - Enable the GuC Dynamic Inhibit Context Switch optimization (Daniele) - Drop bo->size (Brost) - Builds and KConfig fixes (Harry, Maarten) - Consolidate LRC offset calculations (Tvrtko) - Fix potential leak in hw_engine_group (Michal) - Future-proof for multi-tile + multi-GT cases (Roper) - Validate gt in pmu event (Riana) - SRIOV PF: Clear all LMTT pages on alloc (Michal) - Allocate PF queue size on pow2 boundary (Brost) - SRIOV VF: Make multi-GT migration less error prone (Tomasz) - Revert indirect ring state patch to fix random LRC context switches failures (Brost) - Fix compressed VRAM handling (Auld) - Add one additional BMG PCI ID (Ravi) - Recommend GuC v70.46.2 for BMG, LNL, DG2 (Julia) - Add GuC and HuC to PTL (Daniele) - Drop PTL force_probe requirement (Atwood) - Fix error flow in display suspend (Shuicheng) - Disable GuC communication on hardware initialization error (Zhanjun) - Devcoredump fixes and clean up (Shuicheng) - SRIOV PF: Downgrade some info to debug (Michal) - Don't allocate temporary GuC policies object (Michal) - Support for I2C attached MCUs (Heikki, Raag, Riana) - Add GPU memory bo trace points (Juston) - SRIOV VF: Skip some W/a (Michal) - Correct comment of xe_pm_set_vram_threshold (Shuicheng) - Cancel ongoing H2G requests when stopping CT (Michal) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/aHA7184UnWlONORU@intel.com
2025-07-11drm/i915/xe3lpd: Prune modes for YUV420Suraj Kandpal6-4/+63
We only support resolution up to 4k for single pipe when using YUV420 format so we prune these modes and restrict the plane size at src. This is because pipe scaling will not support YUV420 scaling for hwidth > 4096. --v2 -Use output format to check [Ville] -Add Bspec references -Modify commit messge to point to why this is needed --v3 -Use a function skl_scaler_mode_valid which is routed throug intel_pfit_mode_valid [Ville] -Combine the check conditons [Jonathan] --v4 -mode_valid functions should return drm_mode_status [Jani] --v5 -Use skl_scaler_max_src_size [Ankit] Bspec: 49247, 50441 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> #v2 Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708043328.1086192-2-suraj.kandpal@intel.com
2025-07-11drm/i915/scaler: Use intel_display as argument to skl_scaler_max_src_sizeSuraj Kandpal1-4/+2
skl_scaler_max_src_size has really no use of intel_crtc other than deriving intel_display. Let's just pass intel_display to it directly. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708043328.1086192-1-suraj.kandpal@intel.com
2025-07-11drm/xe/guc: Default log level to non-verboseLucas De Marchi1-1/+1
Currently xe sets the guc log level to a verbose level since it's useful to debug hangs and general development. However the verbose level may already be too much and affect performance. Michal Mrozek did some tests with the L0 compute stack for submission latency with ULLS disabled. Below are the normalized numbers with log level 3 (the current default) as baseline for each test: Test \ Log Level 3 0 1 2 ----------------------------------------------------------- ------ ------ ------ ------ BestWalkerNthCommandListSubmission(CmdListCount=2) 1.00 0.63 0.63 0.96 BestWalkerNthSubmission(KernelCount=2) 1.00 0.62 0.63 0.96 BestWalkerNthSubmissionImmediate(KernelCount=2) 1.00 0.58 0.58 0.85 BestWalkerSubmission 1.00 0.62 0.62 0.96 BestWalkerSubmissionImmediate 1.00 0.63 0.62 0.96 BestWalkerSubmissionImmediateMultiCmdlists(cmdlistCount=2) 1.00 0.58 0.58 0.86 BestWalkerSubmissionImmediateMultiCmdlists(cmdlistCount=4) 1.00 0.70 0.70 0.83 BestWalkerSubmissionImmediateMultiCmdlists(cmdlistCount=8) 1.00 0.53 0.52 0.78 Log level 2 is the first "verbose level" for GuC, where the biggest difference happens. Keep log level 3 for CONFIG_DRM_XE_DEBUG, but switch to 1, i.e. GUC_LOG_LEVEL_NON_VERBOSE, for "normal" builds. Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250613-guc-log-level-v2-1-cb84a63e49fe@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit a37128ba613ad6a5f81f382fa3cfe5c4a6527310) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-11drm/xe/bmg: Don't use WA 16023588340 and 22019338487 on VFMichal Wajdeczko1-2/+2
These workarounds are not applicable for use by the VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Tested-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Link: https://lore.kernel.org/r/20250710103040.375610-2-jakub1.kolakowski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 1d2e2503e506ddc499cbb7afdc8b70bcf6fe241f) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-11drm/xe/guc: Recommend GuC v70.46.2 for BMG, LNL, DG2Julia Filipchuk1-3/+3
UAPI compatibility version 1.22.2 Resolves various bugs. Recommend newer version. Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250626182805.1701096-13-daniele.ceraolospurio@intel.com (cherry picked from commit 0b64addcae7f04745bc5f62d41e27268052f812e) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-12 11:20:09 +0300