| 75f65f1a | 14-May-2026 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4
The register COMMON_SLICE_CHICKEN4 is a MCR register on both Xe2 and Xe3. Let's make sure to define a MCR version of it and use it for the
drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4
The register COMMON_SLICE_CHICKEN4 is a MCR register on both Xe2 and Xe3. Let's make sure to define a MCR version of it and use it for the relevant IP versions.
Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP.
v2: - Also change for one entry in lrc_tunnings, which was caught by manual testing and add corresponging Fixes tag in commit message. (Gustavo)
Fixes: 8d6f16f1f082 ("drm/xe: Extend Wa_22021007897 to Xe3 platforms") Fixes: e5c13e2c505b ("drm/xe/xe2hpg: Add Wa_22021007897") Fixes: 8ccf5f6b2295 ("drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3p") Bspec: 66534, 71185, 74417 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-3-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
show more ...
|
| a672725f | 14-May-2026 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1
The register COMMON_SLICE_CHICKEN1 is a MCR register on Xe2. Let's make sure to define a MCR version of it and use it for the relevant IP
drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1
The register COMMON_SLICE_CHICKEN1 is a MCR register on Xe2. Let's make sure to define a MCR version of it and use it for the relevant IP versions.
Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP.
Fixes: a5d221924e13 ("drm/xe/xe2_hpg: Add set of workarounds") Fixes: 9f18b55b6d3f ("drm/xe/xe2: Add workaround 18033852989") Bspec: 66534, 71185 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-2-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
show more ...
|
| bccf190e | 07-May-2026 |
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> |
drm/xe/multi_queue: Capture queue run times for active queues
If a queue is currently active on the CS, query the QUEUE TIMESTAMP register to get an up to date value of the runtime. To do so, ensure
drm/xe/multi_queue: Capture queue run times for active queues
If a queue is currently active on the CS, query the QUEUE TIMESTAMP register to get an up to date value of the runtime. To do so, ensure that the primary queue is active and then check if the secondary queue is executing on the CS.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-21-umesh.nerlige.ramappa@intel.com
show more ...
|
| 461a6698 | 24-Apr-2026 |
Matt Roper <matthew.d.roper@intel.com> |
drm/xe: Drop unnecessary STOP_RING clearing
The STOP_RING bit in MI_MODE is already clear by default out of hardware reset and will only be '1' if the driver intentionally sets it after that.
The l
drm/xe: Drop unnecessary STOP_RING clearing
The STOP_RING bit in MI_MODE is already clear by default out of hardware reset and will only be '1' if the driver intentionally sets it after that.
The logic of clearing this bit appears to originate from very early (pre-GuC, pre-execlist) code in i915 where we needed to stop the ring before performing a host-initiated engine reset; after the reset the STOP_RING bit needed to be cleared to allow execution to resume.
None of that is relevant to Xe (or even modern i915) since STOP_RING isn't necessary for execlist-based engine resets (and even if it were, Xe doesn't initiate any engine resets; the GuC handles that now).
Bspec: 60356, 60184 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-8-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
show more ...
|
| c973f7a6 | 17-Apr-2026 |
Karthik Poosa <karthik.poosa@intel.com> |
drm/xe/hwmon: Enable energy attributes for CRI
Enable HWMON energy attributes for CRI, which are available through MMIO registers. Although these attributes can also be accessed via PMT, MMIO is pre
drm/xe/hwmon: Enable energy attributes for CRI
Enable HWMON energy attributes for CRI, which are available through MMIO registers. Although these attributes can also be accessed via PMT, MMIO is preferred as it avoids dependency on ocode firmware load in late binding scenario.
v2: Rephrase commit message. (Anshuman)
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Soham Purkait <soham.purkait@intel.com> Link: https://patch.msgid.link/20260417041456.818668-1-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
| 68bed0d6 | 10-Mar-2026 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/xe: Translate C-state "reset value" into RC6
There are higher level sleep states that will cause RC6 state readout to come back with an "in-reset" value. That is the case with NVL-P. As those st
drm/xe: Translate C-state "reset value" into RC6
There are higher level sleep states that will cause RC6 state readout to come back with an "in-reset" value. That is the case with NVL-P. As those states are only possible if the GT is already in C6, let's just translate the "reset value" into C6 when doing the readout.
Bspec: 67651 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-7-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
show more ...
|
| 44b51275 | 10-Mar-2026 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/xe/xe3p: Drop Wa_16028780921
Wa_16028780921 involves writing to a register that is locked by firmware prior to driver loading and doesn't have any effect if implemented by the KMD. Since the im
drm/xe/xe3p: Drop Wa_16028780921
Wa_16028780921 involves writing to a register that is locked by firmware prior to driver loading and doesn't have any effect if implemented by the KMD. Since the implementation of the workaround actually belongs the firmware, just drop the ineffective implementation by the KMD.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-6-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
show more ...
|
| 0919b266 | 10-Mar-2026 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/xe/nvlp: Implement Wa_14026539277
Implement the KMD part of Wa_14026539277, which applies to NVL-P A0. The KMD implementation is just one component of the workaround, which also depends on Pcode
drm/xe/nvlp: Implement Wa_14026539277
Implement the KMD part of Wa_14026539277, which applies to NVL-P A0. The KMD implementation is just one component of the workaround, which also depends on Pcode to implement its part in order to be complete.
v2: - Add FUNC(xe_rtp_match_not_sriov_vf) to skip applying the workaround to SRIOV VFs. (Matt) v3: - Make Wa_14026539277 a device workaround instead of a GT workaround. (Matt) v4: - Drop FUNC(xe_rtp_match_not_sriov_vf) and use a direct check with IS_SRIOV_VF() in the workaround implementation. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v3 Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-5-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
show more ...
|