summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-04drm/amd/ras: add check safety watermark func for pmfw eepromGangliang Xie
add check safety watermark func for pmfw eeprom Signed-off-by: Gangliang Xie <ganglxie@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-04drm/xe: Fix memory leak in xe_vm_madvise_ioctlVarun Gupta
When check_bo_args_are_sane() validation fails, jump to the new free_vmas cleanup label to properly free the allocated resources. This ensures proper cleanup in this error path. Fixes: 293032eec4ba ("drm/xe/bo: Update atomic_access attribute on madvise") Cc: stable@vger.kernel.org # v6.18+ Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Varun Gupta <varun.gupta@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223175145.1532801-1-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-04drm/xe/reg_sr: Fix leak on xa_store failureShuicheng Lin
Free the newly allocated entry when xa_store() fails to avoid a memory leak on the error path. v2: use goto fail_free. (Bala) Fixes: e5283bd4dfec ("drm/xe/reg_sr: Remove register pool") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260204172810.1486719-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-04drm/xe/xe2_hpg: Correct implementation of Wa_16025250150Matt Roper
Wa_16025250150 asks us to set five register fields of the register to 0x1 each. However we were just OR'ing this into the existing register value (which has a default of 0x4 for each nibble-sized field) resulting in final field values of 0x5 instead of the desired 0x1. Correct the RTP programming (use FIELD_SET instead of SET) to ensure each field is assigned to exactly the value we want. Cc: Aradhya Bhatia <aradhya.bhatia@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: stable@vger.kernel.org # v6.16+ Fixes: 7654d51f1fd8 ("drm/xe/xe2hpg: Add Wa_16025250150") Reviewed-by: Ngai-Mint Kwan <ngai-mint.kwan@linux.intel.com> Link: https://patch.msgid.link/20260227164341.3600098-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit d139209ef88e48af1f6731cd45440421c757b6b5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-04drm/xe/gsc: Fix GSC proxy cleanup on early initialization failureZhanjun Dong
xe_gsc_proxy_remove undoes what is done in both xe_gsc_proxy_init and xe_gsc_proxy_start; however, if we fail between those 2 calls, it is possible that the HW forcewake access hasn't been initialized yet and so we hit errors when the cleanup code tries to write GSC register. To avoid that, split the cleanup in 2 functions so that the HW cleanup is only called if the HW setup was completed successfully. Since the HW cleanup (interrupt disabling) is now removed from xe_gsc_proxy_remove, the cleanup on error paths in xe_gsc_proxy_start must be updated to disable interrupts before returning. Fixes: ff6cd29b690b ("drm/xe: Cleanup unwind of gt initialization") Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260220225308.101469-1-zhanjun.dong@intel.com (cherry picked from commit 2b37c401b265c07b46408b5cb36a4b757c9b5060) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-04Revert "drm/pagemap: Disable device-to-device migration"Thomas Hellström
With commit a69d1ab971a6 ("mm: Fix a hmm_range_fault() livelock / starvation problem") device-to-device migration is not functional again and the disabling can be reverted. Add the above commit as a Fixes: tag in order for the revert to not take place unless that commit is present. This reverts commit 10dd1eaa80a56d3cf6d7c36b5269c8fed617f001. Cc: Matthew Brost <matthew.brost@intel.com> Fixes: b570f37a2ce4 ("mm: Fix a hmm_range_fault() livelock / starvation problem") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260211104159.114947-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 1a3c0049b3f56278c9caf2784c53f6ab435fd12c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo updated Fixes tag]
2026-03-04drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTLVille Syrjälä
Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE before enabling TRANS_DDI_FUNC_CTL. Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason. BSpec does tell us to configure VRR after enabling TRANS_DDI_FUNC_CTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANS_VRR_CTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/VMIN/FLIPLINE, among other things So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later. BSpec: 22243 Cc: stable@vger.kernel.org Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reported-by: Benjamin Tissoires <bentiss@kernel.org> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15777 Tested-by: Benjamin Tissoires <bentiss@kernel.org> Fixes: dda7dcd9da73 ("drm/i915/vrr: Use fixed timings for platforms that support VRR") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260303095414.4331-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2026-03-04drm/i915/psr: Fix for Panel Replay X granularity DPCD register handlingJouni Högander
DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line granularity. Take this into account when handling Panel Replay X granularity informed by the panel. Fixes: 1cc854647450 ("drm/i915/psr: Use SU granularity information available in intel_connector") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7284 Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260225074221.1744330-2-jouni.hogander@intel.com (cherry picked from commit f5c8f824a495e849492f09a43bd965a8f4d86cb2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-03-04drm/i915/gt: prefer _PICK_EVEN() over _PICK()Jani Nikula
There's no need to use _PICK() here. Use the simpler one instead. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/f94272fb9e93afa51d9fdb006888b8ebe38580df.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/intel: add pick.h for the various "picker" helpersJani Nikula
Add a shared header that's used by i915, xe, and i915 display. This allows us to drop the compat-i915-headers/i915_reg_defs.h include from xe_reg_defs.h. All the register macro helpers were subtly pulled in from i915 to all of xe through this. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/fcd70f3317755bf98a6e7ae88974aa8ba06efd1e.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/intel: add reg_bits.h for the various register content helpersJani Nikula
Add a shared header that's used by i915, xe, and i915 display. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/e641fe6dcecef92367471f3e0d150f9f47ae4edc.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/xe/oa: prefer REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE()Jani Nikula
Using REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE() is more obvious to the reader than having the ternary expression inside REG_MASKED_FIELD(). Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/a9b0151d82b1622daa0625fc8ea2c41d233e4318.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/i915/perf: prefer REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE()Jani Nikula
Using REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE() is more obvious to the reader than having the ternary expression inside REG_MASKED_FIELD(). Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/93caec439ad10ef8b163162c52407abf36df69f5.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/{i915, xe}/reg: rename masked field helpers REG_MASKED_FIELD*()Jani Nikula
The underscore prefixed masked field helper names aren't great. Rename them REG_MASKED_FIELD(), REG_MASKED_FIELD_ENABLE(), and REG_MASKED_FIELD_DISABLE(). This is more in line with the existing REG_FIELD_PREP() etc. helpers, and using "field" instead of "bit" is more accurate for the functionality. This is done with: sed -i 's/_MASKED_FIELD/REG_MASKED_FIELD/g' $(git grep -wl _MASKED_FIELD) sed -i 's/_MASKED_BIT_ENABLE/REG_MASKED_FIELD_ENABLE/g' $(git grep -wl _MASKED_BIT_ENABLE) sed -i 's/_MASKED_BIT_DISABLE/REG_MASKED_FIELD_DISABLE/g' $(git grep -wl _MASKED_BIT_DISABLE) with some manual indentation fixes on top. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/i915/lrc: switch to _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE()Jani Nikula
Since it's now possible to use _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() in the array initializer, switch to them. This allows us to remove __MASKED_FIELD() macro. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/733568f8a6155b6e2da1dcdce9d21d6aab881449.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/i915/reg: make masked field helpers constexprJani Nikula
Make it possible to use _MASKED_FIELD(), _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() in contexts that require integer constant expressions. This increases their usefulness at the small cost of making the warnings from build time checks less helpful. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/788f538cc71dec0db25e0c768e8945bef6f9701c.1772042022.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-04drm/ttm/tests: Fix build failure on PREEMPT_RTMaarten Lankhorst
Fix a compile error in the kunit tests when CONFIG_PREEMPT_RT is enabled, and the normal mutex is converted into a rtmutex. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602261547.3bM6yVAS-lkp@intel.com/ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260304085616.1216961-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-03-04drm/imagination: Ensure struct pvr_device->power is initializedMatt Coster
When pvr_power_domains_init() handles <=1 power domains, the content of struct pvr_device->power was previously left uninitialized. Fixes: e19cc5ab347e3 ("drm/imagination: Use dev_pm_domain_attach_list()") Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260227-single-domain-power-fixes-v1-3-d37ba0825f7c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-04drm/imagination: Detach pm domains if linking failsMatt Coster
There's a missing call to dev_pm_domain_detach_list() in the error path of pvr_power_domains_init(); if creating the second stage of device links fails then the struct dev_pm_domain_list will be left dangling. Fixes: e19cc5ab347e3 ("drm/imagination: Use dev_pm_domain_attach_list()") Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260227-single-domain-power-fixes-v1-2-d37ba0825f7c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-04drm/imagination: Check for NULL struct dev_pm_domain_listMatt Coster
While dev_pm_domain_detach_list() itself contains the necessary NULL check, the access to struct dev_pm_domain_list->num_pds does not and thus faults on devices with <=1 power domains (where the struct dev_pm_domain_list machinery is skipped for simplicity). This can be reproduced on AM625, which produces the following log[1]: [ 10.820056] powervr fd00000.gpu: Direct firmware load for powervr/rogue_33.15.11.3_v1.fw failed with error -2 [ 10.831903] powervr fd00000.gpu: [drm] *ERROR* failed to load firmware powervr/rogue_33.15.11.3_v1.fw (err=-2) ... [ 10.844023] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 11.090162] Call trace: [ 11.092600] pvr_power_domains_fini+0x18/0xa0 [powervr] (P) [ 11.098218] pvr_probe+0x100/0x14c [powervr] [ 11.102505] platform_probe+0x5c/0xa4 Fixes: e19cc5ab347e3 ("drm/imagination: Use dev_pm_domain_attach_list()") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/r/c353fdef-9ccd-4a11-a527-ab4a792d8e70@sirena.org.uk/ [1] Tested-by: Mark Brown <broonie@kernel.org> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260227-single-domain-power-fixes-v1-1-d37ba0825f7c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-04drm/i915/psr: Fix for Panel Replay X granularity DPCD register handlingJouni Högander
DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line granularity. Take this into account when handling Panel Replay X granularity informed by the panel. Fixes: 1cc854647450 ("drm/i915/psr: Use SU granularity information available in intel_connector") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7284 Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260225074221.1744330-2-jouni.hogander@intel.com
2026-03-04drm/sched: Fix kernel-doc warning for drm_sched_job_done()Yujie Liu
There is a kernel-doc warning for the scheduler: Warning: drivers/gpu/drm/scheduler/sched_main.c:367 function parameter 'result' not described in 'drm_sched_job_done' Fix the warning by describing the undocumented error code. Fixes: 539f9ee4b52a ("drm/scheduler: properly forward fence errors") Signed-off-by: Yujie Liu <yujie.liu@intel.com> [phasta: Flesh out commit message] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260227082452.1802922-1-yujie.liu@intel.com
2026-03-03drm/msm: Fix dma_free_attrs() buffer sizeThomas Fourier
The gpummu->table buffer is alloc'd with size TABLE_SIZE + 32 in a2xx_gpummu_new() but freed with size TABLE_SIZE in a2xx_gpummu_destroy(). Change the free size to match the allocation. Fixes: c2052a4e5c99 ("drm/msm: implement a2xx mmu") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707340/ Message-ID: <20260226095714.12126-2-fourier.thomas@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-03drm/msm/a6xx: Fix the bogus protect error on X2-85Akhil P Oommen
Update the X2-85 gpu's register protect count configuration with the correct count_max value to avoid blocking the entire MMIO region from the UMD. Protect configurations are a bit complicated on A8xx. There are 2 set of protect registers with different counts: Global and Pipe-specific. The last-span-unbound feature is available only on the Pipe-specific protect registers. Due to this, we cannot use the BUILD_BUG sanity check for A8x protect configurations, so remove the A840 entry from there. Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/706944/ Message-ID: <20260225-glymur-protect-fix-v1-1-0deddedf9277@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-03drm/i915/overlay: Fix oops on unloadVille Syrjälä
Apparently I failed to test the unload case properly and thus didn't notice that the i915_overlay_is_active() needs i915->overlay after fetch_and_zero() already cleared it. Stop using fetch_and_zero() and only clear the pointer at the end to avoid the oops. Fixes: 38d9a352c45e ("drm/i915/overlay: Extract i915_overlay_is_active()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260303101417.14409-1-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-03-03drm/i915/dp: Ack only the handled link service IRQsImre Deak
Ack only those SST link service IRQs that will be handled, similarly to device service IRQs. While at it add asserts that only the known/acked link service IRQs are handled both in the MST and SST case. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-21-imre.deak@intel.com
2026-03-03drm/i915/dp: Ack only the handled device service IRQsImre Deak
Only those IRQs should be acked that are handled, however for SST all IRQs triggered by the sink are acked. This can be a problem for flags that are reserved/reading zero at a given moment, but become used for some purpose - with a side-effect if set - in a future DPCD revision. Fix the above by acking only those device service IRQs that will be handled. While at it add asserts that only the known/acked device service IRQs are handled both in the MST and SST case. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-20-imre.deak@intel.com
2026-03-03drm/i915/dp_mst: Reuse intel_dp_handle_link_service_irq()Imre Deak
Use intel_dp_handle_link_service_irq() while handling an MST HPD IRQ, instead of open-coding this. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-19-imre.deak@intel.com
2026-03-03drm/i915/dp: Check SST link status while handling link service IRQsImre Deak
Move checking the link status for SST to intel_dp_handle_link_service_irq(). This is the logical place for the check which should only happen in response to a LINK_STATUS_CHANGE sink IRQ. This IRQ is only supported by DPCD revision >= 1.2, so for sinks with an older DPCD revision the link status is checked in response to any HPD IRQ. For newer DPCD revisions however the link status check can be made conditional on LINK_STATUS_CHANGE. For now keep the current behavior of always forcing a link status check regardless of LINK_STATUS_CHANGE being set or not. This also prepares for a follow-up change sharing the link service IRQ handler for SST and MST (on MST the link status check only happening in response to a LINK_STATUS_CHANGE IRQ). Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-18-imre.deak@intel.com
2026-03-03drm/i915/dp: Print debug message for a sink connected off requestImre Deak
So far the CONNECTED_OFF_ENTRY_REQUESTED request was accepted only implicitly, by acking all the IRQs raised by the sink. Make this explicit by printing a debug message. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-17-imre.deak@intel.com
2026-03-03drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MSTImre Deak
Read and ack the sink count, sink device and link service IRQs for SST the same way this is done for MST, the read/ack happening in separate steps via an ESI (Event Status Indicator) vector. The above way is more efficient, since on newer (DPCD_REV >= 1.2) sinks the DP_SINK_COUNT_ESI..DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers can be read out in one AUX transaction - and the 3 last one written in one transaction. Also this allows sharing more of the SST and MST IRQ handling code (done as a follow-up). For now keep the current behavior of always reading the legacy DP_SINK_COUNT, DP_DEVICE_SERVICE_IRQ_VECTOR registers and not reading the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 register. v2: Document the ESI vector get/ack helper fnuctions' return value. (Jani, Luca) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-16-imre.deak@intel.com
2026-03-03drm/i915/dp: Return early if getting/ackink link service IRQs failsImre Deak
If getting/acking the link service IRQs fail, the short HPD handler should bail out, falling back to a full connector detection as in case of any AUX access failures during the HPD handling. Do this by separating the getting/acking and handling steps of the IRQs. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-15-imre.deak@intel.com
2026-03-03drm/i915/dp: Return early if getting/acking device service IRQs failsImre Deak
If getting/acking the device service IRQs fail, the short HPD handler should bail out, falling back to a full connector detection as in case of any AUX access failures during the HPD handling. Do this by separating the getting/acking and handling steps of the IRQs. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-14-imre.deak@intel.com
2026-03-03drm/i915/dp: Reprobe connector if getting/acking link service IRQs failsImre Deak
An AUX access failure during HPD IRQ handling should be handled by falling back to a full connector detection, ensure that if the failure happens while reading/acking a link service IRQ. While at it add code comment documenting the return value of intel_dp_check_link_service_irq(). v2: Docuement intel_dp_check_link_service_irq()'s return value. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-13-imre.deak@intel.com
2026-03-03drm/i915/dp: Reprobe connector if getting/acking device IRQs failsImre Deak
An AUX access failure during HPD IRQ handling should be handled by falling back to a full connector detection, ensure that if the failure happens while reading/acking a device service IRQ. v2: Document intel_dp_check_device_service_irq()'s return value. (Jani, Luca) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-12-imre.deak@intel.com
2026-03-03drm/i915/dp: Fix the link service IRQ DPCD_REV checkImre Deak
The DP_LINK_SERVICE_IRQ_VECTOR_ESI0 DPCD register is supported only since DPCD REV 1.2, so fix the revision check accordingly. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-11-imre.deak@intel.com
2026-03-03drm/i915/dp: Fix the device service IRQ DPCD_REV checkImre Deak
The DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register is supported since DPCD REV 1.0, so read it out always. Flags added only by later DPCD revisions are defined as reserved/must-be-zero by earlier DP Standard versions. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-10-imre.deak@intel.com
2026-03-03drm/i915/dp: Remove the device service IRQ handling from connector detectImre Deak
The device service IRQ handling was added to the connector detect function by commit 09b1eb130e43 ("drm/i915: Move Displayport test request and sink IRQ logic to intel_dp_detect()") since some Automated Test Request IRQs couldn't be handled in the short HPD IRQ handler context. This has been fixed meanwhile by deferring the handling of all test request events from the IRQ handler to the hotplug handler (intel_dp_short_pulse() -> intel_dp_test_short_pulse() -> reprobe) and by handling all hotplug events (both for short and long HPD pulses) in the test application. Handling device IRQs during connector detection is not standard compliant (the IRQs should be handled when an HPD IRQ is raised) and it happens in a racy way with the same device IRQ handling happening from the HPD IRQ handler (since the detect and HPD IRQ handler can run in parallel). Based on the above, remove the redundant call from the detect function. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-9-imre.deak@intel.com
2026-03-03drm/i915/dp: Don't clobber the encoder state in the HPD IRQ handlerImre Deak
The intel_dp_get_dpcd() function called from an HPD IRQ handler reads out the DPRX capabilities from the sink and updates these in the intel_dp encoder state. Since the IRQ handler can run in parallel with the encoder/connector detection (intel_dp_detect()) which also calls intel_dp_get_dpcd(), the encoder state can get corrupted, since the two updates happen in a racy way. Fix the above by checking only for any change in the sink count value in the HPD IRQ handler, without updating the encoder state. Note that any state change in the sink requiring an update of the encoder state is handled via the sink's SINK_COUNT change, RX_CAPS_CHANGED, DOWNSTREAM_PORT_STATUS_CHANGED signaling, which all should result in a full connector detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-8-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle the DOWNSTREAM_PORT_STATUS_CHANGED eventImre Deak
Handle the DOWNSTREAM_PORT_STATUS_CHANGED event a branch device can use to indicate the state change of a DFP connector on the branch device. The event is signaled in the DP_LANE_ALIGN_STATUS_UPDATED DPCD register setting a clear-on-read flag and triggering an HPD IRQ. Accordingly keep a cached version of the flag, updating it whenever DP_LANE_ALIGN_STATUS_UPDATED is read. Schedule a full connector detection from the HPD IRQ handler if the cached flag is set and clear the cached flag at the start of detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-7-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQImre Deak
Handle the RX_CAP_CHANGED IRQ, which a sink can use to indicate a DPRX capability change without disconnecting and reconnecting itself (i.e. through a short vs. long HPD pulse). Handle the IRQ by doing a full connector detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-6-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle a tunneling IRQ after acking itImre Deak
HPD IRQs in general should be handled after acking them. The 1. Read IRQ register (read DP_DEVICE_SERVICE_IRQ_VECTOR, DP_LINK_SERVICE_IRQ_VECTOR_ESI0) 2. Handle IRQ 3. Ack IRQ (write DP_DEVICE_SERVICE_IRQ_VECTOR, DP_LINK_SERVICE_IRQ_VECTOR_ESI0) sequence would miss a new interrupt triggered after 2. and before 3., since the flag set in the IRQ register for this interrupt would be cleared in step 3. Fix the above by handling the IRQ after acking it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-5-imre.deak@intel.com
2026-03-03drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handlerImre Deak
Use intel_dp_check_link_state() in the MST HPD IRQ handler instead of open-coding it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-4-imre.deak@intel.com
2026-03-03drm/i915/dp_mst: Verify the link status always the same wayImre Deak
The MST link status should be always verified from the same DPCD registers after link training. Atm, both the legacy (0x202 - 0x205) and the ESI (0x200C - 0x200F) link status registers are used. Use always the latter ESI version of link status registers. v2: Propagate error from intel_dp_read_link_status(). (Jani, Luca) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-3-imre.deak@intel.com
2026-03-03drm/i915/dp_mst: Reprobe connector if the IRQ ESI read failedImre Deak
An AUX access failure during HPD IRQ handling should be handled by falling back to a full connector detection, do so. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-2-imre.deak@intel.com
2026-03-03drm/xe/tests: Change TEST_VRAM to work with 32-bit resource_size_tMichal Wajdeczko
We've picked the value of TEST_VRAM to match real VRAM size as found on the machines used by the CI, but that didn't work well on kernels that have 32-bit resource_size_t. Use smaller value instead. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/intel-xe/20260227011639.GA1683727@ax162/ Fixes: cbe29da6f7c0 ("drm/xe/tests: Add KUnit tests for new VRAM fair provisioning") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260227160010.12425-1-michal.wajdeczko@intel.com
2026-03-03drm/xe/display: clean up xe_initial_plane.c includesJani Nikula
Remove excess includes, group and sort include directives. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/637eab7df00a540df6b7ca1ca345302864b6342f.1772212579.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-03drm/xe/compat: remove i915_vma.h from compatJani Nikula
Move compat i915_vma.h to xe_display_vma.h, and remove all extra cruft. Drop the i915_ggtt_offset() wrapper in favour of using xe_ggtt_node_addr() directly. The usefulness of the I915_TILING_X and I915_TILING_Y undef/define is unclear, since uapi/drm/i915_drm.h is included in other paths as well. The naming of struct i915_vma is a bit unfortunate in xe, but (at least for now) a necessity for maintaining type safety on the opaque type. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/ecd5d75981b4b21c3da3b1831faceccfe385d898.1772212579.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-03drm/i915: add VMA to parent interfaceJani Nikula
It's unclear what the direction of the VMA abstraction in the parent interface should be, but convert i915_vma_fence_id() to parent interface for starters. This paves the way for making struct i915_vma opaque towards display. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/036f4b2d20cc1b0a7ab814beb5bb914c53b6eb53.1772212579.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-03drm/i915/fbdev: stop debug logging i915_ggtt_offset()Jani Nikula
The debug logging in fbdev is the only user of i915_ggtt_offset() in display code. Just stop doing it to drop a dependency on i915_vma.h. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/c3b84cb572c7ee94389e702aba4dcacb26c41673.1772212579.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-08 06:16:56 +0000