The Fixed: commit below overlooked the fact that
intel_dp_link_train_all_phys() is only used for non-UHBR link rates, but
intel_dp_stop_link_train() is used for both non-UHBR and UHBR link
rates. Hence, after removing the disabling of the training pattern from
intel_dp_stop_link_train(), the commit missed adding this back to the
end of UHBR link training in intel_dp_128b132b_link_train(). This left
the sink in link training mode at the end of an UHBR rate link training.
Fix things by disabling the training pattern at the end of UHBR link
training as well.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 11fab5a2a1 ("drm/i915/dp: Clear DPCD training pattern before transmitting the idle pattern")
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250724182900.160891-1-imre.deak@intel.com
While we expect config directory names to match PCI device name,
currently we are only scanning provided names for domain, bus,
device and function numbers, without checking their format.
This would pass slightly broken entries like:
/sys/kernel/config/xe/
├── 0000:00:02.0000000000000
│ └── ...
├── 0000:00:02.0x
│ └── ...
├── 0: 0: 2. 0
│ └── ...
└── 0:0:2.0
└── ...
To avoid such mistakes, check if the name provided exactly matches
the canonical PCI device address format, which we recreated from
the parsed BDF data. Also simplify scanf format as it can't really
catch all formatting errors.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250722141059.30707-3-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Selecting an option which depends on other options only works if the
dependencies are guaranteed to be selected (as these dependencies will
not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on DRM,
MMU and KUNIT the first two of which are guaranteed to be selected for
i915, but the last one is not. Hence, selecting CONFIG_DRM_KUNIT_TEST in
i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being selected
without the CONFIG_KUNIT dependency being selected. This causes at least
the following compile error:
drivers/gpu/drm/tests/drm_bridge_test.c: In function ‘drm_test_bridge_alloc_init’:
drivers/gpu/drm/tests/drm_bridge_test.c:449:21: error: implicit declaration of function ‘kunit_device_register’; did you mean ‘root_device_register’? [-Werror=implicit-function-declaration]
449 | priv->dev = kunit_device_register(test, "drm-bridge-dev");
Fix the above by selecting CONFIG_DRM_KUNIT_TEST only if CONFIG_KUNIT is
also selected.
Fixes: 17133255a3 ("drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST")
Cc: Ruben Wauters <rubenru09@aol.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250724090237.92040-1-imre.deak@intel.com
Rather than open-coding GT TLB invalidations in the PT layer, use GT TLB
invalidation jobs. The real benefit is that GT TLB invalidation jobs use
a single dma-fence context, allowing the generated fences to be squashed
in dma-resv/DRM scheduler.
v2:
- s/;;/; (checkpatch)
- Move ijob/mjob job push after range fence install
v3:
- Remove extra newline (Stuart)
- Set ijob/mjob near creation (Stuart)
- Add comment back in (Stuart)
Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://lore.kernel.org/r/20250724191216.4076566-7-matthew.brost@intel.com
Add generic dependecy jobs / scheduler which serves as wrapper for DRM
scheduler. Useful when we want delay a generic operation until a
dma-fence signals.
Existing use cases could be destroying of resources based fences /
dma-resv, the preempt rebind worker, and pipelined GT TLB invalidations.
Written in such a way it could be moved to DRM subsystem if needed.
v3:
- Remove unnecessary cast (Staurt)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://lore.kernel.org/r/20250724191216.4076566-3-matthew.brost@intel.com
The register at offset 0xfd0 was incorrectly named MCFG_MCR_SELECTOR,
likely copied from i915. According to the hardware specification (Bspec),
this register is actually called STEER_SEMAPHORE.
Rename the register definition and update its usage in xe_gt_mcr.c to
match the official hardware documentation.
No functional changes.
v2: Add Bspec reference (Tejas)
Bspec: 67113
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://lore.kernel.org/r/20250723141039.3848390-1-nitin.r.gote@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
drm-misc-fixes for v6.16-rc8/final?:
- Revert all uses of drm_gem_object->dmabuf to
drm_gem_object->import_attach->dmabuf.
- Fix amdgpu returning BIOS cluttered VRAM after resume.
- Scheduler hang fix.
- Revert nouveau ioctl fix as it caused regressions.
- Fix null pointer deref in nouveau.
- Fix unnecessary semicolon in ti_sn_bridge_probe.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://lore.kernel.org/r/72235afd-c849-49fe-9cc1-2b1781abdf08@linux.intel.com
We were already testing those two platforms for a while on our CI,
but enabling flag (has_sriov) was only available on the topic branch
and only for builds with CONFIG_DRM_XE_DEBUG config.
Since those two platforms are guarded by the another enabling flag
(require_force_probe) and we believe our SR-IOV support for them is
at sufficient level to start enjoying the feature, turn on the
SR-IOV enabling flag unconditionally.
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250722182618.30811-4-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Add 50ms disable delay for NV116WHM-N49, NV122WUM-N41, and MNC207QS1-1
to satisfy T9+T10 timing. Add 50ms disable delay for MNE007JA1-2
as well, since MNE007JA1-2 copies the timing of MNC207QS1-1.
Specifically, it should be noted that the MNE007JA1-2 panel was added
by someone who did not have the panel documentation, so they simply
copied the timing from the MNC207QS1-1 panel. Adding an extra 50 ms
of delay should be safe.
Fixes: 0547692ac1 ("drm/panel-edp: Add several generic edp panels")
Fixes: 50625eab39 ("drm/edp-panel: Add panel used by T14s Gen6 Snapdragon")
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250723072513.2880369-1-yelangyan@huaqin.corp-partner.google.com
When CONFIG_DEBUG_FS is off, drivers/gpu/drm/xe/xe_gt_debugfs.o
is not built and build fails on some setups with:
ld: drivers/gpu/drm/xe/xe_gt.o: in function `xe_fault_inject_gt_reset':
drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1659): undefined reference to `gt_reset_failure'
ld: drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1c16): undefined reference to `gt_reset_failure'
collect2: error: ld returned 1 exit status
Do not use the gt_reset_failure attribute if debugfs is not enabled.
Fixes: 8f3013e0b2 ("drm/xe: Introduce fault injection for gt reset")
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://lore.kernel.org/r/20250722-xe-fix-build-fault-v1-1-157384d50987@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
dma_fence_wait_timeout returns a long type but the driver is
only using the lower 32 bits of the retval and discarding the
upper 32 bits.
This is particularly problematic if there are already signalled
or stub fences on some of the hw planes. In this case the
dma_fence_wait_timeout function will immediately return with
timeout value MAX_SCHEDULE_TIMEOUT (0x7fffffffffffffff) since
the fence is already signalled. If the driver only uses the lower
32 bits of this return value then it'll interpret it as an error
code (0xFFFFFFFF or (-1)) and skip the wait on the remaining fences.
This issue was first observed in the xe driver with the Android
compositor where the GPU composited layer was not properly waited
on when there were stub fences in other overlay planes resulting in
visual artifacts.
Fixes: d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence")
Signed-off-by: Aakash Deep Sarkar <aakash.deep.sarkar@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com
(cherry picked from commit cdb1603951)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
dma_fence_wait_timeout returns a long type but the driver is
only using the lower 32 bits of the retval and discarding the
upper 32 bits.
This is particularly problematic if there are already signalled
or stub fences on some of the hw planes. In this case the
dma_fence_wait_timeout function will immediately return with
timeout value MAX_SCHEDULE_TIMEOUT (0x7fffffffffffffff) since
the fence is already signalled. If the driver only uses the lower
32 bits of this return value then it'll interpret it as an error
code (0xFFFFFFFF or (-1)) and skip the wait on the remaining fences.
This issue was first observed in the xe driver with the Android
compositor where the GPU composited layer was not properly waited
on when there were stub fences in other overlay planes resulting in
visual artifacts.
Fixes: d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence")
Signed-off-by: Aakash Deep Sarkar <aakash.deep.sarkar@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com
We are seeing "dmesg-warn/abort - *ERROR* PHY * failed after 3 retries"
since we started configuring LFPS sending. According to Bspec Configuring
LFPS sending is needed only when using AUXLess ALPM. This patch avoids
these failures by configuring LFPS sending only when using AUXLess ALPM.
Bspec: 68849
Fixes: 9dc619680d ("drm/i915/display: Add function to configure LFPS sending")
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250722125618.1842615-2-jouni.hogander@intel.com
Merge miscellaneous power management updates and cpupower utility
updates for 6.17-rc1:
- Update contact information in the PM ABI docs and maintainer
information in the power domains DT binding (Rafael Wysocki)
- Update PM header inclusions to follow the IWYU (Include What You Use)
principle (Andy Shevchenko)
- Add flags to specify power on attach/detach for PM domains, make the
driver core detach PM domains in device_unbind_cleanup(), and drop
the dev_pm_domain_detach() call from the platform bus type (Claudiu
Beznea)
- Improve Python binding's Makefile for cpupower (John B. Wyatt IV)
- Fix printing of CORE, CPU fields in cpupower-monitor (Gautham Shenoy)
* pm-misc:
PM: docs: Use my kernel.org address in ABI docs and DT bindings
driver core: platform: Drop dev_pm_domain_detach() call
PM: domains: Detach on device_unbind_cleanup()
PM: domains: Add flags to specify power on attach/detach
PM: Don't use "proxy" headers
* pm-tools:
cpupower: Improve Python binding's Makefile
pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor
pm: cpupower: Fix the snapshot-order of tsc,mperf, clock in mperf_stop()
