- 19 Dec, 2023 40 commits
-
-
Lucas De Marchi authored
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.comSigned-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Cleanup GuC register declarations by converting them to use REG_FIELD, REG_BIT and REG_GENMASK. While converting, also reorder the bitfields so they follow the convention of declaring the higher bits first. v2: - Drop unused HUC_LOADING_AGENT_VCR and DMA_ADDRESS_SPACE_GTT (Matt Roper) - Simplify HUC_LOADING_AGENT_GUC define (Matt Roper) Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20230427223256.1432787-2-lucas.demarchi@intel.comSigned-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Maarten Lankhorst authored
Commit 7aaec3a6 ("drm/xe: Let's return last value read on xe_mmio_wait32.") mentions that we should return the last value read, but we never actually return it. This breaks display which depends on the value being actually returned where needed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: 7aaec3a6 ("drm/xe: Let's return last value read on xe_mmio_wait32.") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/257Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
There's no good reason to keep the GuC registers outside the regs/ directory: move the header with GuC registers under that. 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>
-
Lucas De Marchi authored
That register is a completely different register, it's not the same as SOFT_SCRATCH for GEN11 and beyond. Rename to to the same name as the bspec uses, including the new variant for media. Also, move the definitions to the guc header. 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>
-
Lucas De Marchi authored
There was both BLT_DEPTH_32 and XY_FAST_COLOR_BLT_DEPTH_32 - also add the prefix to the first to make it clear this is about the FAST_**COPY** operation. While at it, remove the GEN9_ prefix. 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>
-
Lucas De Marchi authored
Follow up commits will mass-remove the gen prefix/suffix. For GEN6_RC0 and GEN6_RC6 that would make the variable too short and easy to conflict. So, add "GT_" prefix that is also part of the register name. 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>
-
Lucas De Marchi authored
Rename the following defines to lose the GEN* prefixes since they don't make sense for xe: GEN8_PTE_SHIFT -> XE_PTE_SHIFT GEN8_PAGE_SIZE -> XE_PAGE_SIZE GEN8_PTE_MASK -> XE_PTE_MASK GEN8_PDE_SHIFT -> XE_PDE_SHIFT GEN8_PDES -> XE_PDES GEN8_PDE_MASK -> XE_PDE_MASK GEN8_64K_PTE_SHIFT -> XE_64K_PTE_SHIFT GEN8_64K_PAGE_SIZE -> XE_64K_PAGE_SIZE GEN8_64K_PTE_MASK -> XE_64K_PTE_MASK GEN8_64K_PDE_MASK -> XE_64K_PDE_MASK GEN8_PDE_PS_2M -> XE_PDE_PS_2M GEN8_PDPE_PS_1G -> XE_PDPE_PS_1G GEN8_PDE_IPS_64K -> XE_PDE_IPS_64K GEN12_GGTT_PTE_LM -> XE_GGTT_PTE_LM GEN12_USM_PPGTT_PTE_AE -> XE_USM_PPGTT_PTE_AE GEN12_PPGTT_PTE_LM -> XE_PPGTT_PTE_LM GEN12_PDE_64K -> XE_PDE_64K GEN12_PTE_PS64 -> XE_PTE_PS64 GEN8_PAGE_PRESENT -> XE_PAGE_PRESENT GEN8_PAGE_RW -> XE_PAGE_RW PTE_READ_ONLY -> XE_PTE_READ_ONLY Keep an XE_ prefix to make sure we don't mix the defines for the CPU (e.g. PAGE_SIZE) with the ones fro the GPU). 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>
-
Rodrigo Vivi authored
On xe_hw_engine_print_state we were printing: value_of(0x510) + 4 instead of value_of(0x514) as desired. So, let's properly define a RING_EXECLIST_SQ_CONTENTS_HI register to fix the issue and also to avoid other issues like that. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
-
Rodrigo Vivi authored
The main issue with buddy allocator was fixed, but then we ended up on other issues, so we need to step back and rethink our strategy with D3cold. So, let's update the comment with a todo list so we don't get tempted in removing it before we are really ready. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
-
José Roberto de Souza authored
ttm_global_init() imposes this limitation. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Francois Dugast authored
Build without CONFIG_PM_SLEEP (such as for riscv) was failing due to unused xe_pci_runtime_* functions. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Riana Tauro authored
When the device is runtime suspended, reading some of the sysfs entries under device/gt#/ causes a resume error This is due to the ordering of pm_runtime and forcewake calls. Reorder to wake up using xe_pm_runtime_get and then forcewake v2: add goto statements (Rodrigo) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Balasubramani Vivekanandan authored
xe_resize_vram_bar() function is already printing the status of bar resizing. It has prints covering both success and failure. There is no need of additional prints in the caller which were not so easily to follow. Modified all BAR size prints to consistently print the size in MiB. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
The write of GFX_FLSH_CNTL_GEN6 was inherited from the i915 codebase where it was used to force a flush of the write-combine buffer in cases where the GSM/GGTT were mapped as WC. Since Xe never uses WC mappings of the GGTT, this register write is unnecessary. Furthermore, this register was removed on Xe_HP-based platforms, so this write winds up clobbering an unrelated register. v2: - Also drop GFX_FLSH_CNTL_GEN6 from the register file now that it's no longer used. (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230418230247.3802438-1-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
xe_mmio_rmw32 was failing to invert the passed in mask, resulting in a register update that wasn't the expected RMW operation. Fortunately the impact of this mistake was limited, since this function isn't heavily used in Xe right now; this will mostly fix some GuC PM interrupt unmasking. v2: - Rename parameters as 'clr' and 'set' to clarify semantics. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230421145006.10940-1-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
If looking at the initial engine dump we should expect this to match XE_FENCE_INITIAL_SEQNO - 1. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
Doesn't look like we are accounting for seqno wrap. Just use __dma_fence_is_later() like we already do for xe_hw_fence_signaled(). Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
The 'clear' field for register save/restore entries was being placed in the value bits of the register rather than the mask bits; make sure it gets shifted into the mask bits. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230419224909.4000920-1-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
It looks like when tlb_invalidation.seqno overflows TLB_INVALIDATION_SEQNO_MAX, we start counting again from one, as per send_tlb_invalidation(). This is also inline with initial value we give it in xe_gt_tlb_invalidation_init(). When calculating the expected_seqno we should also take this into account. While we are here also print out the values if we ever trigger the warning. v2 (José): - drm_WARN_ON() is preferred over plain WARN_ON(), since it gives information on the originating device. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/248Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Anusha Srivatsa authored
Add missing device info for Rocketlake. While at it, also set the value for IS_ROCKETLAKE macro which is right now set to 0. v2: Also add abox_mask to the device info(Lucas) v3: rebase v4: Set IS_ROCKETLAKE (Anusha) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Tested-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>(v2) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
CI keeps triggering: xe 0000:03:00.0: [drm] Restricting VRAM size to PCI resource size (0x400000000->0x3fa000000) Due to usable_size vs vram_size differences. However, we only want to trigger the drm_warn() to let developers know that the system they are using is going clamp the VRAM size to match the IO size, where they can likely only use 256M of VRAM. Once we properly support small-bar we can revisit this. v2 (Lucas): Drop the TODO for now Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Anusha Srivatsa authored
Rocketlake uses TGL GuC and HuC Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
PCODE_WRITE_MIN_FREQ_TABLE is only applicable to platforms with an LLC. Change the discrete GPU check to an LLC check instead; this take care of skipping not only the discrete platforms, but also integrated platforms like MTL that do not have an LLC. Fixes MTL dmesg error: xe 0000:00:02.0: [drm] *ERROR* PCODE Mailbox failed: 1 Illegal Command Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230410183910.2696628-3-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Some driver initialization is conditional on the presence of an LLC. Add an extra feature flag to support this. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230410183910.2696628-2-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Replace 'bool' fields with single bits to allow the various device feature flags to pack more tightly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230410183910.2696628-1-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Brost authored
A VM had a runtime PM ref, a engine can't be created without a VM, and the engine holds a ref to the VM thus this is unnecessary. Beyond that taking a ref in the engine create IOCTL and dropping it in the destroy IOCTL is wrong as a user doesn't have to call the destroy IOCTL (e.g. they can just kill the process or close the driver FD). If a user does this PM refs are leaked. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
The media GT requires a valid gt->kernel_bb_pool during driver probe to allocate the WA and NOOP batchbuffers used to record default context images. Dynamically allocate the bb_pools so that the primary and media GT can use the same pool during driver init. The media GT still shouldn't be need the USM pool, so only hook up the kernel_bb_pool for now. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230410200229.2726648-1-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Niranjana Vishwanathapura authored
The wait_event_timeout() on g2h_fence.wq which is declared on stack can return before the wake_up() gets called, resulting in a stack out of bound access when wake_up() accesses the g2h_fene.wq. Do not declare g2h_fence related wait_queue_head_t on stack. Fixes the below KASAN BUG and associated kernel crashes. BUG: KASAN: stack-out-of-bounds in do_raw_spin_lock+0x6f/0x1e0 Read of size 4 at addr ffff88826252f4ac by task kworker/u128:5/467 CPU: 25 PID: 467 Comm: kworker/u128:5 Tainted: G U 6.3.0-rc4-xe #1 Workqueue: events_unbound g2h_worker_func [xe] Call Trace: <TASK> dump_stack_lvl+0x64/0xb0 print_report+0xc2/0x600 kasan_report+0x96/0xc0 do_raw_spin_lock+0x6f/0x1e0 _raw_spin_lock_irqsave+0x47/0x60 __wake_up_common_lock+0xc0/0x150 dequeue_one_g2h+0x20f/0x6a0 [xe] g2h_worker_func+0xa9/0x180 [xe] process_one_work+0x527/0x990 worker_thread+0x2d1/0x640 kthread+0x174/0x1b0 ret_from_fork+0x29/0x50 </TASK> Tested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Bruce Chang <yu.bruce.chang@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
This stopped working now that TTM treats moving a pinned object through ttm_bo_validate() as an error, for the general case. Add some new routines to handle the new special casing needed for suspend-resume. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/244Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Now that most of the characteristics of a device are associated with the graphics and media IPs, the remaining contents of xe_device_desc can be cleaned up a bit: * 'gt' is unused; drop it * DEV_INFO_FOR_EACH_FLAG only covers two flags and is only used in this one file; drop the unnecessary macro complexity * Convert .has_4tile to a single bitfield bit so that it can be packed with the other feature flags * Move 'platform' lower in the structure for better packing Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-10-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Add a simple KUnit test to ensure that the hardware engine lists for GMD_ID IP definitions are sensible (i.e., no graphics engines defined for the media IP and vice versa). Only the IP descriptors for GMD_ID platforms are checked for now. Presumably the engine lists on older pre-GMD_ID platforms shouldn't be changing. We can extend the KUnit testing in the future if we decide we want to check those as well. v2: - Add missing 'const' in xe_call_for_each_media_ip to avoid compiler warning. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-9-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
If graphics_desc and media_desc are not specified in a platform's xe_device_desc, treat this as an indication that the IP version should be determined from the hardware's GMD_ID register. Note that leaving media_desc unset for a platform that simply doesn't have the IP (e.g., PVC) is also okay --- a read of the GMD_ID register offset will be attempted, but since there's no register at that location a value of '0' will be returned, effectively disabling media support. Mapping of version -> IP description is done via a table lookup; this table will be re-used in future patches for some KUnit testing. v2: - Drop dummy structures. NULL can be safely used for both the GMD_ID cases and the "media not present case." - Use a table-based lookup of GMD_ID versions rather than a simple switch statement; the table will allow us to easily perform kunit testing of all the IP descriptors. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-8-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Printing the name, along with the IP version number, will help reduce confusion about which IP is present on a platform. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-7-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
The total number of GTs supported by a platform should be one primary GT, one media GT (if media version >= 13), and a number of remote tile GTs dependent on the graphics IP present. Express this more clearly in the device setup. Note that xe->info.tile_count is inaccurately named; the rest of the driver treats this as the GT count, not just the tile count. This will need to be cleaned up at some point down the road. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-6-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Break the top-level platform_engine_mask field into separate hw_engine_mask fields in the graphics and media structures. Since hardware has more flexibility to mix-and-match IP versions going forward, this allows each IP to list exactly which engines it provides; the final per-GT engine list can then be constructured from those: * On platforms without a standalone media GT (i.e., media IP versions prior to 13), the primary GT's engine list is the union of the graphics IP's engine list and the media IP's engine list. * Otherwise, GT0's engine list is the graphics IP's engine list. * For GT1 and beyond, the type of GT determines which IP's engine list is used. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-5-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Most of the traits currently in the device descriptor structures are either tied to the graphics IP or should be inferred from the graphics IP. This becomes important on MTL and beyond where IP versions are supposed to be detected from the hardware's GMD_ID registers rather than mapped from PCI devid. Engine masks are left where they are for now; they'll be dealt with separately in a future patch. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-4-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Set require_force_probe explicitly in each platform's description structure rather than embedding it within the FOO_FEATURES macros. Even though we expect all platforms currently supported by the Xe driver to be under force_probe protection, this will help prepare for some other upcoming restructuring. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-3-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Rather than storing all characteristics for an entire platform in the xe_device_desc structure, create secondary graphics and media structures to hold traits and feature flags specific to those IPs. This will eventually allow us to assign the graphics and media characteristics at runtime based on the contents of the relevant GMD_ID registers. For now, just move the IP versions into the new structures to keep things simple. Other IP-specific fields will migrate to these structures in future patches. Note that there's one functional change introduced by this: previously PVC was recognized as media version 12.60. That's technically true, but in practice the media engines are fused off on all production hardware. By simply not assigning a media IP structure to PVC it will effectively be treated as IP version 0.0 now (which the rest of the driver should treat as non-existent media). v2: - Split the new structures out to their own header. This will ease the addition of KUnit tests later. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230406235621.1914492-2-matthew.d.roper@intel.comSigned-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
When debugging issues related to GuC/HuC, it's important to know what is the firmware version being used. The version from the filename can't be relied upon, also because it normally only contains the major version (except for the ones under experimental support). Log the version from the blob after reading the CSS header. Example: xe 0000:03:00.0: [drm] Using GuC firmware (70.5) from i915/dg2_guc_70.bin Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230405224725.1993719-1-lucas.demarchi@intel.comSigned-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-