#
be46d7aa |
|
13-Feb-2024 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/xe/vf: Don't support MCR registers if VF VF drivers can't operate on MCR registers. Make sure that driver is not trying to read nor write using any of MCR register. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240213154355.1221-9-michal.wajdeczko@intel.com
|
#
97fd7a7e |
|
17-Jan-2024 |
Thomas Hellström <thomas.hellstrom@linux.intel.com> |
drm/xe: Annotate mcr_[un]lock() These functions acquire and release the gt::mcr_lock. Annotate accordingly. Fix the corresponding sparse warning. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: fb1d55efdfcb ("drm/xe: Cleanup OPEN_BRACE style issues") Cc: Francois Dugast <francois.dugast@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117134048.165425-4-thomas.hellstrom@linux.intel.com
|
#
3ecf036b |
|
17-Jan-2024 |
Thomas Hellström <thomas.hellstrom@linux.intel.com> |
drm/xe: Annotate mcr_[un]lock() These functions acquire and release the gt::mcr_lock. Annotate accordingly. Fix the corresponding sparse warning. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: fb1d55efdfcb ("drm/xe: Cleanup OPEN_BRACE style issues") Cc: Francois Dugast <francois.dugast@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117134048.165425-4-thomas.hellstrom@linux.intel.com (cherry picked from commit 97fd7a7e4e877676a2ab1a687ba958b70931abcc) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
#
9fa81f91 |
|
08-Sep-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mmio: Account for GSI offset when checking ranges Change xe_mmio_in_range() to use the same logic to account for the GT's adj_offset as the read and write functions. This is needed when checking ranges for the MCR registers if the GT has an offset to adjust. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230908225227.1276610-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
8e99b545 |
|
11-Aug-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/xe/xe2: Add MCR register steering for media GT Xe2 media has a few types of MCR registers, but all except for "GPMXMT" can safely steer to instance 0,0. GPMXMT follows the same rules that MTL's OADDRM ranges did, so it can re-use the same enum value. Bspec: 71186 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
5c82000f |
|
11-Aug-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/xe/xe2: Add MCR register steering for primary GT Xe2 uses the same steering control register and steering semaphore register as MTL. As with recent platforms, group/instance 0,0 is sufficient to target a non-terminated instance for most classes of MCR registers; the only types of ranges that need to consider platform fusing to find a non-terminated instance are SLICE/DSS ranges and a new SQIDI_PSMI type of range. Note that the range of valid bits in XE2_NODE_ENABLE_MASK may be reduced for some Xe2 SKUs. However the lowest bits are always valid and only the lowest instance is obtained via __ffs(), so there's no need to complicate the masking with extra platform/subplatform checks. Also note that Wa_14017387313 suggests skipping MCR lock acquisition around GAM and GAMWKR registers to prevent MCR register accesses in an interrupt handler from deadlocking when the steering semaphore is already held outside the interrupt context. At this time Xe never issues MCR accesses from within an interrupt handler so the workaround is not currently needed. v2: - [0x008700-0x0087FF] range to extend up to 0x887F (Matt Attwood) - [0x00EF00-0x00F4FF] -> [0x00F000, 0xFFFF] to follow latest bspec version (Bala) Bspec: 71185 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
43b5d81e |
|
26-Jul-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/xe: fix mcr semaphore locking for MTL in commit 81593af6c88d ("drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us.") the mcr semaphore register read was accidentally switched from waiting for the register to go to 1 to waiting for the register to go to 0, so we need to flip it back. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
72e8d73b |
|
19-Jul-2023 |
Francois Dugast <francois.dugast@intel.com> |
drm/xe: Cleanup style warnings and errors Fix 6 errors and 20 warnings reported by checkpatch.pl. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
fb1d55ef |
|
11-Jul-2023 |
Francois Dugast <francois.dugast@intel.com> |
drm/xe: Cleanup OPEN_BRACE style issues Remove almost all existing style issues of type OPEN_BRACE reported by checkpatch. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
ee21379a |
|
08-May-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Rename reg field to addr Rename the address field to "addr" rather than "reg" so it's easier to understand what it is. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20230508225322.2692066-4-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
ce8bf5bd |
|
08-May-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mmio: Use struct xe_reg Convert all the callers to deal with xe_mmio_*() using struct xe_reg instead of plain u32. In a few places there was also a rename s/reg/reg_val/ when dealing with the value returned so it doesn't get mixed up with the register address. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20230508225322.2692066-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
a56d8dab |
|
05-May-2023 |
Nirmoy Das <nirmoy.das@intel.com> |
drm/xe: Do not sleep in atomic Set atomic in xe_mmio_wait32() otherwise we would be scheduling in atomic context. Fixes: 7dc9b92dcfef ("drm/xe: Remove i915_utils dependency from xe_pcode.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
215bb2ce |
|
04-May-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Fix comment on Wa_22013088509 On i915 the "see comment about Wa_22013088509" referred to the comment in the graphics version >= 11 branch, where there were more details about it. From the platforms supported by xe, only PVC needs Wa_22013088509, but as the comment says, it's simpler to do it for all platforms as there is no downside. Bring the missing comment over from i915 and reword it to fit xe better. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20230504073250.1436293-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
36e22be4 |
|
27-Apr-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Introduce xe_reg/xe_reg_mcr Stop using i915 types for registers. Use our own types. Differently from i915, this will keep under the register definition the knowledge for the different types of registers. For now, the "flags"/"options" are mcr and masked, although only the former is being used. Additionally MCR registers have their own type. The only place that should really look inside a xe_mcr_reg_t is that code dealing with the steering and using other APIs when the register is MCR has been a source of problem in the past. Most of the driver is agnostic to the register differences since they either use the definition from the header or already call the correct MCR_REG()/_MMIO() macros. By embeding the struct xe_reg inside the struct it's also possible to guarantee the compiler will break if using RANDOM_MCR_REG.reg is attempted, since now the u32 is inside the inner struct. v2: - Deep a dedicated type for MCR registers to avoid misuse (Matt Roper, Jani) - Drop the typedef and just use a struct since it's not an opaque type (Jani) - Add more kernel-doc v3: - Use only 22 bits for the register address since all the platforms supported so far have only 4MB of MMIO per tile (Matt Roper) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230427223256.1432787-7-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
d9b79ad2 |
|
27-Apr-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Drop gen afixes from registers The defines for the registers were brought over from i915 while bootstrapping the driver. As xe supports TGL and later only, it doesn't make sense to keep the GEN* prefixes and suffixes in the registers: TGL is graphics version 12, previously called "GEN12". So drop the prefix everywhere. v2: - Also drop _TGL suffix and reword commit message as suggested by Matt Roper. While at it, rename VSUNIT_CLKGATE_DIS_TGL to VSUNIT_CLKGATE2_DIS with the additional "2", so it doesn't clash with the define for the other register Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230427223256.1432787-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
436dbd6b |
|
17-Mar-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mcr: Separate version from engine type selection In order to improve readability and make it more future proof, split the engine type from the graphics/platform checks. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230317223441.3891073-1-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
6b980aa8 |
|
08-Mar-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mcr: Document how to initialize group/instance Add a sentence about the initialization so it's clear for newcomers how to tweak the init functions for new platforms. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
e84535d8 |
|
06-Mar-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mcr: Add L3BANK steering for DG2 Some register ranges with replication type L3BANK were missing from the driver table. The following warning was triggering when adding a workaround touching the register 0xb188: xe 0000:03:00.0: Did not find MCR register 0xb188 in any MCR steering table Add the L3BANK ranges according to the spec. v2: - Fix typo in one of the ranges: s/0x00BCFF/0x008CFF/ (Matt Roper) - Add termination rule in the init function for L3BANK (Matt Roper) Bspec: 66534 Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
226bfec8 |
|
24-Feb-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Remove dependency on intel_gt_regs.h Create regs/xe_gt_regs.h file with all the registers and bit definitions used by the xe driver. Eventually the registers may be defined in a different way and since xe doesn't supported below gen12, the number of registers touched is much smaller, so create a new header. The definitions themselves are direct copy from the gt/intel_gt_regs.h file, just sorting the registers by address. Cleaning those up and adhering to a common coding style is left for later. v2: Make the change to MCR_REG location in a separate patch to go through the i915 branch (Matt Roper / Rodrigo) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
ea9f879d |
|
24-Feb-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Sort includes Sort includes and split them in blocks: 1) .h corresponding to the .c. Example: xe_bb.c should have a "#include "xe_bb.h" first. 2) #include <linux/...> 3) #include <drm/...> 4) local includes 5) i915 includes This is accomplished by running `clang-format --style=file -i --sort-includes drivers/gpu/drm/xe/*.[ch]` and ignoring all the changes after the includes. There are also some manual tweaks to split the blocks. v2: Also sort includes in headers Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
dc97898e |
|
16-Feb-2023 |
José Roberto de Souza <jose.souza@intel.com> |
drm/xe: Initialize ret in mcr_lock() ret is not initialized in mcr_lock() when running in platforms with graphics IP version < 1270, this could cause drm_WARN_ON_ONCE() to hit eventually(what just happened to me). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
564d64f8 |
|
30-Jan-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mcr: Add SQIDI steering for DG2 Like detailed in commit 927dfdd09d8c ("drm/i915/dg2: Add SQIDI steering"), some registers are expected to have the selector initialized just once and never set to anything else. For xe, the registers with SQIDI replication type (SF and MCFG) were missing, resulting in warnings like: [ 410.685565] xe 0000:03:00.0: Did not find MCR register 0x8724 in any MCR steering table While adding these registers, abstract the handling for "dg2_gam_ranges", moving them together with SF/MCFG to a dedicated table. This also avoids that range to be checked for platforms other than DG2. For DG2, this is the new steering output: # cat /sys/kernel/debug/dri/0/gt0/steering ... IMPLICIT steering: group=0x0, instance=0x0 0x000b00 - 0x000bff 0x001000 - 0x001fff 0x004000 - 0x004aff 0x008700 - 0x0087ff 0x00c800 - 0x00cfff 0x00f000 - 0x00ffff Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
3319b213 |
|
30-Jan-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe/mcr: Use designated init for xe_steering_types There is already a BUILD_BUG_ON() check to make sure the size follow the number of steering types. Also make sure the right index is being used for each steering type. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
62421b45 |
|
20-Jan-2023 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/xe: Fix typo in MCR documentation Add missing "multicast" word and adapt/wrap the rest of the sentence. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
7dc9b92d |
|
12-Jan-2023 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/xe: Remove i915_utils dependency from xe_pcode. Expand xe_mmio_wait32 to accept atomic and then use that directly when possible, and create own routine to wait for the pcode status. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
|
#
81593af6 |
|
12-Jan-2023 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. Another clean-up towards killing the usage of i915_utils.h Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
|
#
0f06dc10 |
|
12-Jan-2023 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/xe: Implement a local xe_mmio_wait32 Then, move the i915_utils.h include to its user. The overall goal is to kill all the usages of the i915_utils stuff. Yes, wait_for also depends on <linux/delay.h>, so they go together to where it is needed. It will be likely needed anyway directly for udelay or usleep_range. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
|
#
dd08ebf6 |
|
30-Mar-2023 |
Matthew Brost <matthew.brost@intel.com> |
drm/xe: Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake (first Intel Xe Architecture). The code is at a stage where it is already functional and has experimental support for multiple platforms starting from Tiger Lake, with initial support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO (for OpenCL and Level0). The new Xe driver leverages a lot from i915. As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. But it is not added in this patch. This initial work is a collaboration of many people and unfortunately the big squashed patch won't fully honor the proper credits. But let's get some git quick stats so we can at least try to preserve some of the credits: Co-developed-by: Matthew Brost <matthew.brost@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Co-developed-by: Francois Dugast <francois.dugast@intel.com> Co-developed-by: Lucas De Marchi <lucas.demarchi@intel.com> Co-developed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Co-developed-by: Philippe Lecluse <philippe.lecluse@intel.com> Co-developed-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Jani Nikula <jani.nikula@intel.com> Co-developed-by: José Roberto de Souza <jose.souza@intel.com> Co-developed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Co-developed-by: Dave Airlie <airlied@redhat.com> Co-developed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Co-developed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Co-developed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|