Select Git revision
Search by author
- Any Author
- authors
-
Aaron Watry awatry
-
Adam Jackson ajax
-
Adela Rybak adelaryb
-
Aditya Swarup aswarup
-
Alan Previn Teres Alexi alan_previn_intel
-
Alejandro Piñeiro
apinheiro
-
Alexander Usyskin
ausyskin
-
Alexander von Gluck kallisti5
-
Alex Deucher agd5f
-
Alex Smith aejsmith
-
Alok Hota
ahota
-
Alyssa Rosenzweig
alyssa
-
Andreas Baierl rellla
-
Andreas Boll ab
-
Andres Gomez tanty
-
Andres Rodriguez lostgoat
-
Andrey Grodzovsky
agrodzov
-
Andrzej Hajda andrzej.hajda
-
AnkithaRathod AnkithaRathod
-
Anshuman Gupta anshuma1
- Apr 20, 2023
-
-
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.com Signed-off-by:
Matt Roper <matthew.d.roper@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:
-
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:
-
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:
-
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:
-
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 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:
Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230405224725.1993719-1-lucas.demarchi@intel.com
-
Matthew Brost authoredIf CCS0 was fused we did not write this register thus CCS engine were not enabled resulting in driver load failures. Signed-off-by:
-
Lucas De Marchi authored
Update the logic to autoselect GuC/HuC for the platforms with the following improvements: - Document what is the firmware file that is expected to be loaded and what is checked from blob headers - When the platform is under force-probe it's desired to enforce the full-version requirement so the correct firmware is used before widespread adoption and backward-compatibility commitments - Directory from which we expect firmware blobs to be available in upstream linux-firmware repository depends on the platform: for the ones supported by i915 it uses the i915/ directory, but the ones expected to be supported by xe, it's on the xe/ directory. This means that for platforms in the intersection, the firmware is loaded from a different directory, but that is not much important in the firmware repo and it avoids firmware duplication. - Make the table with the firmware definitions clearly state the versions being expected. Now with macros to select the version it's possible to choose between full-version/major-version for GuC and full-version/no-version for HuC. These are similar to the macros used in i915, but implemented in a slightly different way to avoid duplicating the macros for each firmware/type and functionality, besides adding the support for different directories. - There is no check added regarding force-probe since xe should reuse the same firmware files published for i915 for past platforms. This can be improved later with additional kunit checking against a hardcoded list of platforms that falls in this category. - As mentioned in the TODO, the major version fallback was not implemented before as currently each platform only supports one major. That can be easily added later. - GuC version for MTL and PVC were updated to 70.6.4, using the exact full version, while the After this the GuC firmware used by PVC changes to pvc_guc_70.5.2.bin since it's using a file not published yet. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://lore.kernel.org/r/20230324051754.1346390-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
In order to avoid mistakes when populating the workarounds, it's good to be able to test if the entries added are all compatible for a certain platform. The platform itself is not needed as long as we create fake devices with enough configuration for the RTP helpers to process the tables. Common mistakes that can be avoided: - Entries clashing the bitfields being updated - Register type being mixed (MCR vs regular / masked vs regular) - Unexpected errors while adding the reg_sr entry To test, inject a duplicate entry in gt_was, but with platform == tigerlake rather than the currenct graphics version check: { XE_RTP_NAME("14011059788"), XE_RTP_RULES(PLATFORM(TIGERLAKE)), XE_RTP_ACTIONS(SET(GEN10_DFR_RATIO_EN_AND_CHICKEN, DFR_DISABLE)) }, This produces the following result: $ ./tools/testing/kunit/kunit.py run \ --kunitconfig drivers/gpu/drm/xe/.kunitconfig xe_wa [14:18:02] Starting KUnit Kernel (1/1)... [14:18:02] ============================================================ [14:18:02] ==================== xe_wa (1 subtest) ===================== [14:18:02] ======================== xe_wa_gt ========================= [14:18:02] [drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 9550 (clear: 00000200, set: 00000200, masked: no): ret=-22 [14:18:02] # xe_wa_gt: ASSERTION FAILED at drivers/gpu/drm/xe/tests/xe_wa_test.c:116 [14:18:02] Expected gt->reg_sr.errors == 0, but [14:18:02] gt->reg_sr.errors == 1 (0x1) [14:18:02] [FAILED] TIGERLAKE (B0) [14:18:02] [PASSED] DG1 (A0) [14:18:02] [PASSED] DG1 (B0) ... Signed-off-by:Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20230401085151.1786204-8-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Add some basic unit tests for rtp. This is intended to prove the functionality of the rtp itself, like coalescing entries, rejecting non-disjoint values, etc. Contrary to the other tests in xe, this is a unit test to test the sw-side only, so it can be executed on any machine - it doesn't interact with the real hardware. Running it produces the following output: $ ./tools/testing/kunit/kunit.py run --raw_output-kunit \ --kunitconfig drivers/gpu/drm/xe/.kunitconfig xe_rtp ... [01:26:27] Starting KUnit Kernel (1/1)... KTAP version 1 1..1 KTAP version 1 # Subtest: xe_rtp 1..1 KTAP version 1 # Subtest: xe_rtp_process_tests ok 1 coalesce-same-reg ok 2 no-match-no-add ok 3 no-match-no-add-multiple-rules ok 4 two-regs-two-entries ok 5 clr-one-set-other ok 6 set-field [drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000001, set: 00000001, masked: no): ret=-22 ok 7 conflict-duplicate [drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000003, set: 00000000, masked: no): ret=-22 ok 8 conflict-not-disjoint [drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000002, set: 00000002, masked: no): ret=-22 [drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000001, set: 00000001, masked: yes): ret=-22 ok 9 conflict-reg-type # xe_rtp_process_tests: pass:9 fail:0 skip:0 total:9 ok 1 xe_rtp_process_tests # Totals: pass:9 fail:0 skip:0 total:9 ok 1 xe_rtp ... Note that the ERRORs in the kernel log are expected since it's testing incompatible entries. v2: - Use parameterized table for tests (Michał Winiarski) - Move everything to the xe_rtp_test.ko and only add a few exports to the right namespace - Add more tests to cover FIELD_SET, CLR, partially true rules, etc Signed-off-by: -
Lucas De Marchi authored
When there's an entry that is dropped when xe_reg_sr_add(), there's not much we can do other than reporting the error - it's for certain a driver issue or conflicting workarounds/tunings. Save the number of errors to be used later by kunit to report where it happens. Signed-off-by:
-
Lucas De Marchi authored
Instead of requiring tests to initialize a fake device an keep it in sync with xe_pci.c when it's platform-dependent, export a function from xe_pci.c to be used and piggy back on the device info creation. For simpler tests that don't need any specific platform and just need a fake xe device to pass around, xe_pci_fake_device_init_any() can be used. Signed-off-by:
-
Lucas De Marchi authored
Instead of simply using EXPORT_SYMBOL() to export the functions needed in xe.ko to be be called across modules, use EXPORT_SYMBOL_IF_KUNIT() which will export the symbol under the EXPORTED_FOR_KUNIT_TESTING namespace. This avoids accidentally "leaking" these functions and letting them be called from outside the kunit tests. If these functiosn are accidentally called from another module, they receive a modpost error like below: ERROR: modpost: module XXXXXXX uses symbol xe_ccs_migrate_kunit from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it. Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/20230401085151.1786204-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Move code out of xe_pci.[ch] into tests/*.[ch], like is done in other similar compilation units. Even if this is not part of "tests for xe_pci.c", they are functions exported and required by other tests. It's better not to clutter the module headers and sources with them. Signed-off-by:
-
Lucas De Marchi authored
Extract the part setting up from xe->info from xe_pci_probe() into its own function. This pairs nicely with the display counterpart, avoids info initialization to be placed elsewhere and helps future improvements to build fake devices for tests. While at it, normalize the names a little bit: the _get() suffix may be mistaken by lock-related operation, so rename the function to "find_subplatform()". Also rename the variable to subplatform_desc to make it easier to understand, even if longer. Signed-off-by:
-
Matt Roper authored
Although our only multi-tile platform today (PVC) doesn't support display, it's possible that some future multi-tile platform will. If/when this happens, display interrupts (both traditional display and ASLE backlight interrupts raised as a Gunit interrupt) should be delivered to the primary tile. Save away tile0's master_ctl value so that it can still be used for display interrupt handling after the GT loop. Reviewed-by:
-
Matt Roper authored
Although the hardware team has set aside some register bits for extra media engines, no platform supported by the Xe driver today has VCS4-7 or VECS2-3. Drop the corresponding code (which was already commented out); we can bring it back easily enough if such engines show up on a future platform. Reviewed-by:
-
Matt Roper authored
The remaining "gen11_*" IRQ functions are common to all platforms supported by the Xe driver. Drop the unnecessary prefix. Reviewed-by:
-
Matt Roper authored
Platforms supported by the Xe driver handle top-level interrupts in one of two ways: - Xe_LP platforms only have a "graphics master" register and lack a "master tile" register, so top-level interrupt detection and enable/disable happens in the graphics master. - Xe_LP+ (aka DG1) and beyond have a "master tile" interrupt register that controls the enable/disable of top-level interrupts and must also be consulted to determine which tiles have received interrupts before the driver moves on the process the graphics master register. For functions that are only relevant to the first set of platforms, rename the function prefix to Xe_LP since "gen11" doesn't make sense in the Xe driver. Also add some comments briefly describing the two top-level handlers. Reviewed-by:
-
Matt Roper authored
Any interrupt registers that were introduced by platforms i915 considered to be "gen11" or "gen12" are present on all platforms that the Xe driver supports; drop the unnecessary prefixes. While working in the area, also convert a few open-coded bit manipulations over to REG_BIT and REG_FIELD_GET notation. v2: - Add missing renames in xe_display.c. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matt Roper authored
It's no longer necessary to wrap these operations in macros; a simple function will suffice. Also switch to function names that more clearly describe what operation is being performed: unmask_and_enable() and mask_and_disable(). Reviewed-by:
-
Matt Roper authored
For cases where IRQ_INIT and IRQ_RESET are used, the relevant interrupt registers are always consecutive and ordered ISR, IMR, IIR, IER. Adding helpers to look these up from a base offset will let us eliminate some of the CPP pasting and simplify other upcoming patches. v2: - s/_REGS/_OFFSET/ for consistency. (Lucas) - Move IMR/IIR/IER helpers into xe_irq.c; they aren't needed anywhere else. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matt Roper authored
"Gen" terminology should be avoided in the Xe driver and "gen3" refers to platforms that are 9 (!!) graphics generations earlier than the oldest supported by the Xe driver, so this prefix really doesn't make sense. Reviewed-by:
-
Bruce Chang authoredCurrently, unload pvc driver will generate a null dereference and the call stack is as below. [ 4850.618000] Call Trace: [ 4850.620740] <TASK> [ 4850.623134] ttm_bo_cleanup_memtype_use+0x3f/0x50 [ttm] [ 4850.628661] ttm_bo_release+0x154/0x2c0 [ttm] [ 4850.633317] ? drm_buddy_fini+0x62/0x80 [drm_buddy] [ 4850.638487] ? __kmem_cache_free+0x27d/0x2c0 [ 4850.643054] ttm_bo_put+0x38/0x60 [ttm] [ 4850.647190] xe_gem_object_free+0x1f/0x30 [xe] [ 4850.651945] drm_gem_object_free+0x1e/0x30 [drm] [ 4850.656904] ggtt_fini_noalloc+0x9d/0xe0 [xe] [ 4850.661574] drm_managed_release+0xb5/0x150 [drm] [ 4850.666617] drm_dev_release+0x30/0x50 [drm] [ 4850.671209] devm_drm_dev_init_release+0x3c/0x60 [drm] There are a couple issues, but the main one is due to TTM has only one TTM_PL_TT region, but since pvc has 2 tiles and tries to setup 1 TTM_PL_TT each tile. The second will overwrite the first one. During unload time, the first tile will reset the TTM_PL_TT manger and when the second tile is trying to free Bo and it will generate the null reference since the TTM manage is already got reset to 0. The fix is to use one global TTM_PL_TT manager. v2: make gtt mgr global and change the name to sys_mgr Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com> Signed-off-by:
Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Platform order in enum xe_platform started to be used by some parts of the code, like the GuC/HuC firmware loading logic. The order itself is not very important, but it's better to follow a convention: as was documented in the comment above the enum, reorder the platforms by graphics version. While at it, remove the gen terminology. v2: - Use "graphics version" instead of chronological order (Matt Roper) - Also change pciidlist to follow the same order - Remove "gen" from comments around enum xe_platform Signed-off-by:
-
Maarten Lankhorst authored
Rename intel_de.h to xe_de.h in order to remove #include_next, and change the ifdef guard to be the same as the rest of xe headers. This is consistent with the other files that are inside xe/display, and implement xe specific behavior. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> [mlankhorst: Remove BUILD_FOR_XE too] Acked-by:
Jani Nikula <jani.nikula@linux.intel.com>
-
Lucas De Marchi authored
When the device info initialization moved to the display part, one use case was left behind: platforms without display IP. In order to keep the knowledge about the display in xe_display.c, xe_display_info_init() should be the place where this is set. Remove the warning and set the info accordingly. This moves a later check from intel_device_info_runtime_init() into a very earlier one, when no HW access is being done yet. Fixes: 2a0f49c7 ("drm/xe/display: Move device info initialization to display") Signed-off-by:
-
Maarten Lankhorst authored
DG2 has cdclk squash, without which we calculate the CDCLK wrongly. Alderlake-P is LPD, not gen 12 display. Signed-off-by:
-
Lucas De Marchi authored
Add a "private:" comment to the part of the struct that is not expected to be documented, the one with display-related fields. This silence the following warnings: $ find drivers/gpu/drm/xe -name '*.[ch]' -not -path 'drivers/gpu/drm/xe/display/*' | xargs ./scripts/kernel-doc -Werror -none drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'display' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'pch_type' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'pch_id' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'wm_lv_0_adjust_needed' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_channels' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'symmetric_memory' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'type' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_qgv_points' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_psf_gv_points' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'dram_info' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'runtime_pm' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'sb_lock' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'skl_preferred_vco_freq' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'max_dotclk_freq' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'hti_state' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'snps_phy_failed_calibration' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'modeset_restore_state' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'global_obj_list' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'de_irq_mask' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'display_irqs_enabled' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'enabled_irq_mask' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'params' not described in 'xe_device' 22 warnings as Errors Fixes: 19026b7e ("drm/xe: Remove i915 header dependency when building without display") Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20230315004902.2622613-1-lucas.demarchi@intel.com
-
Maarten Lankhorst authored
Missed this when implementing display support. This allows the cursor to work properly on any pipe other than A. Signed-off-by: -
Lucas De Marchi authored
There is no such thing as GEN13 display. With the IP disaggregation the "gen" stopped being used. The display IP used in DG2 should be using XE_LPD as short name. For Meterlake, it's XE_LPDP, so go ahead and define that macro for it. Signed-off-by:
-
Lucas De Marchi authored
Instead of initializing the display info together with the platform in xe_pci.c, let the display part initialize it. The small disadvantage is that the description struct is not automatically mapped from the PCI ID, but just doing a switch on the platform, that should already be set during display initialization should be ok. This allows to encapsulate the display details inside the display compilation units. Also use __diag_push() / __diag_pop() like in xe_step to handle the few places where -Woverride-init should be disabled. Signed-off-by:
-
Lucas De Marchi authored
Instead of having all the fields initialized in xe_device_create(), move the display part to xe_display_create(). Right now the name "_create()" is not so good as it's basically initializing the fields from xe_device. There is still work needed to move fields to the display substruct so it can be an opaque struct. However, there are already several _init_*() functions, so use the create() suffix in the hope the struct will be made opaque soon. Signed-off-by:
-
Lucas De Marchi authored
Rename xe_display_enable() so it doesn't appear that the IP is being enabled at this point: it's very early in the initialization phase and this is actually setting up the SW part in the DRM driver to be able do drive display. While at it, add the kernel doc. Signed-off-by:
-
Lucas De Marchi authored
Return negative EPROBE_DEFER to be propagated up the stack for it to be correctly handled. Signed-off-by:
-
Matthew Auld authored
One of the remaining issues affecting module unload (DG2 + display) appears to be some kind of BO leak: WARNING: CPU: 1 PID: 1198 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2e/0xc0 WARNING: CPU: 1 PID: 1198 at drivers/gpu/drm/drm_buddy.c:174 drm_buddy_fini+0x5e/0x70 [drm_buddy] Turning on more debugging points at: [drm:drm_mm_takedown] *ERROR* node [00e10000 + 00e11000]: inserted at drm_mm_insert_node_in_range+0x2c8/0x500 __xe_ggtt_insert_bo_at+0xb0/0x120 [xe] xe_bo_create_locked_range+0x255/0x2d0 [xe] xe_bo_create_pin_map_at+0x4d/0x170 [xe] intel_alloc_initial_plane_obj.isra.0+0x175/0x340 [xe] intel_crtc_initial_plane_config+0x7e/0x270 [xe] intel_modeset_init_nogem+0x341/0x8b0 [xe] xe_display_init_noaccel+0x1e/0x50 [xe] xe_device_probe+0x1fa/0x2a0 [xe] So looks like we are leaking the object ref for the initial fb. Looking at the i915 code we also drop the driver reference to the underlying BO, which appears to just leave the drm framebuffer holding the last ref. Do the same for Xe. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matthew Auld authored
On ADL-P we currently trigger: xe 0000:00:02.0: drm_WARN_ON(!((dev_priv)->info.platform == XE_ALDERLAKE_S) && !(dev_priv && 0)) WARNING: CPU: 3 PID: 338 at drivers/gpu/drm/xe/display/ext/intel_pch.c:32 intel_pch_type+0xce/0x2f0 [xe] References: #231 Signed-off-by:
-
Maarten Lankhorst authored
We cannot re-use the initial position of the GGTT, at least not on TGL, as it's put immediately into the beginning of GGTT, which is reserved for WOPCM. Since on DGFX there is no 1:1 mapping between VRAM and GGTT, there's also the potential of a similar bug in DG2 where it attempts to scanout scratch pages. To prevent all of this, we allocate a second GGTT entry at a higher position, and immediately force an async flip to the new position. As a small optimization, we also force pin the initial scanout GGTT on all platforms, and make the pin to GGTT a NOOP. Signed-off-by:
-
Matthew Auld authored
Now that the GGTT scratch page is in system memory, on DG2 we suddenly get a massive flood of: xe 0000:03:00.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 The cause turns out to be the initial fb, which currently just gets nuked with scratch pages when initialising the GGTT, and trying to scanout from system memory on dgpu is not really allowed. On discrete the pre-programmed GGTT range and physical VRAM range are not 1:1 mapped. Also it's not allocated in stolen, but normally somewhere at the start of VRAM, which ensures it's still CPU mappable on even small-bar. Since we currently only reserve the GGTT range for non-CPU accessible stolen in xe_bo_create_pin_map_at(), we can instead just reserve it manually for discrete (or integrated platforms with CPU accessible stolen), to ensure we don't trample it later. Signed-off-by:
-
