- Jun 13, 2023
-
-
Matthew Brost authoredXE_PTE_FLAG_READ_ONLY is specific to struct xe_vma, move it from xe_bo.h to xe_vm_types.h to reflect that. Reviewed-by:Francois Dugast <francois.dugast@intel.com> Signed-off-vy: Matthew Brost <matthew.brost@intel.com>
-
Matthew Brost authored
This define is for internal PTE flags rather than fields in the hardware PTEs, rename as such. This will help in an upcoming patch to avoid further confusion. Reviewed-by:
Matthew Brost <matthew.brost@intel.com>
-
Matthew Brost authored
drm/xe: Use Xe ordered workqueue for rebind worker A mix of the system unbound wq and Xe ordered wq was used for the rebind, only use the Xe ordered wq. This will ensure only 1 rebind is occuring at a time providing a somewhat clunky work around for short comings in TTM wrt to memory contention. Once the TTM memory contention is resolved we should be able to use a dedicated non-ordered workqueue. Also add helper to queue rebind worker to avoid using wrong workqueue going forward. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Matthew Brost authored
drm/xe: Handle unmapped userptr in analyze VM A corner exists where a userptr may have no mapping when analyze VM is called, handle this case. Reviewed-by:
-
Matthew Brost authored
A mix of the system unbound wq and Xe ordered wq was used for the rebind, only use the Xe ordered wq. This will ensure only 1 rebind is occuring at a time providing a somewhat clunky work around for short comings in TTM wrt to memory contention. Once the TTM memory contention is resolved we should be able to use a dedicated non-ordered workqueue. Also add helper to queue rebind worker to avoid using wrong workqueue going forward. Signed-off-by: -
Matthew Brost authored
A corner exists where a userptr may have no mapping when analyze VM is called, handle this case. Signed-off-by: -
Thomas Hellström authored
We need to flush render caches before fence signalling, where we might release the memory for reuse. We can't rely on userspace doing this, so flush render caches after the batch, but before user fence- and dma_fence signalling. Copy the cache flush from i915, but omit PIPE_CONTROL_FLUSH_L3, since it should be implied by the other flushes. Also omit PIPE_CONTROL_TLB_INVALIDATE since there should be no apparent need to invalidate TLB after batch completion. v2: - Update Makefile for OOB WA. Signed-off-by:
-
Thomas Hellström authored
For scratch table mode we need to cover the case where a scratch PTE might have been pre-fetched and cached and used instead of that of the newly bound vma. For compute vms, invalidate TLB globally using GuC before signalling bind complete. For !long-running vms, invalidate TLB at batch start. Also document how TLB invalidation works. v2: - Fix a pointer to the comment about TLB invalidation (Jose Souza). - Add a bool to the vm whether we want to invalidate TLB at batch start. - Invalidate TLB also on BCS- and video engines at batch start where needed. - Use BIT() macro instead of explicit shift. Signed-off-by:
-
- Jun 12, 2023
-
-
Gustavo Sousa authored
If RING_MAX_NONPRIV_SLOTS denotes the maximum number of whitelisting slots, then it makes sense to refuse going above it. v2: - Use xe_gt_err() instead of drm_err() for more detailed info in the error message. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230609143815.302540-3-gustavo.sousa@intel.com Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com>
-
Gustavo Sousa authored
All other parameters can be extracted from a single struct xe_hw_engine reference. This removes redundancy and simplifies the code. Reviewed-by:
-
- Jun 09, 2023
-
-
Matthew Brost authored
The HXG fields are DW1 not DW0, fix this. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
-
- Jun 08, 2023
-
-
Francois Dugast authored
Fix spacing, alignment, and repeated words in the documentation. Reported-by:
Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: -
Francois Dugast authored
Move the definition of drm_xe_engine_class_instance to group it with other engine related structs and to follow the ioctls order. Reported-by:
Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: -
Francois Dugast authored
Replace the license text with its SPDX-License-Identifier for quick identification of the license and consistency with the rest of the driver. Reported-by:
Oded Gabbay <ogabbay@kernel.org>
Signed-off-by:
-
- Jun 07, 2023
-
-
Matt Roper authored
Reviewed-by:
-
Matt Roper authored
Moving display-specific runtime info initialization into display/ makes the display code more self-contained and also makes it easier to call from the Xe driver. v2: - Drop unnecessary display/ prefix from #includes. (Jani) - Clear runtime info if fusing leaves no pipes remaining, the same as we do when fusing indicates the entire display controller is unavailable. (Jani) - Move adjustment of DRIVER_MODESET / DRIVER_ATOMIC after call to intel_display_device_info_runtime_init(); HAS_DISPLAY may have changed to false during the runtime init. (Jani) (cherry picked from commit 2d0cdf60) Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230602181450.1151368-1-matthew.d.roper@intel.com Link: https://lore.kernel.org/r/20230606235242.1895643-10-matthew.d.roper@intel.com Signed-off-by:
Matt Roper <matthew.d.roper@intel.com>
-
Matt Roper authored
If i915_driver_create() fails to create a valid 'i915' object, we should just disable the PCI device and return immediately without trying to call i915_probe_error() that relies on a valid i915 pointer. (cherry picked from commit 718551bb) Fixes: 12e6f6dc ("drm/i915/display: Handle GMD_ID identification in display code") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/55236f93-dcc5-481e-b788-9f7e95b129d8@kili.mountain/ Reviewed-by:
-
Matt Roper authored
Drop the unnecessary directory prefix. This also makes intel_display_device.h easier to use from the Xe driver. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Matt Roper authored
It makes sense to keep the display feature test macros centralized within the display code. (cherry picked from commit 95c08508) Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-7-matthew.d.roper@intel.com Link: https://lore.kernel.org/r/20230606235242.1895643-7-matthew.d.roper@intel.com Signed-off-by:
-
Matt Roper authored
For platforms with GMD_ID support (i.e., everything MTL and beyond), identification of the display IP present should be based on the contents of the GMD_ID register rather than a PCI devid match. Note that since GMD_ID readout requires access to the PCI BAR, a slight change to the driver init sequence is needed --- pci_enable_device() is now called before i915_driver_create(). v2: - Fix use of uninitialized i915 pointer in error path if pci_enable_device() fails before the i915 device is created. (lkp) - Use drm_device parameter to intel_display_device_probe. This goes against i915 conventions, but since the primary goal here is to make it easy to call this function from other drivers (like Xe) and since we don't need anything from the i915 structure, this seems like an exception where drm_device is a more natural fit. v3: - Go back do drm_i915_private for intel_display_device_probe. (Jani) - Move forward decl to top of header. (Jani) (cherry picked from commit 12e6f6dc) Reviewed-by:
-
Matt Roper authored
Rather than selecting the display IP and feature flags at the same time the general PCI probing happens, move this step into the display code itself so that it can be more easily re-used outside of i915 (i.e., by the Xe driver). v2: - Make intel_display_device_probe() always return a non-NULL pointer and simplify copying of runtime_defaults. (Andrzej) v3: - Redefine INTEL_VGA_DEVICE/INTEL_QUANTA_DEVICE to eliminate a cast and an include of linux/mod_devicetable.h. (Jani) - Keep explicit memcpy for runtime defaults. (Jani) (cherry picked from commit 69d43981) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Matt Roper authored
Move the runtime info specific to display into display-specific structures as has already been done with the constant display info. v2: - Rename __runtime to __runtime_defaults for more clarity on the purpose. (Andrzej) - Move introduction of DISPLAY_INFO() to previous patch. (Andrzej) - Drop NO_DISPLAY macro. (Andrzej) v3: - Use "{}" instead of "{ 0 }" for empty struct init. (Jani) (cherry picked from commit 18e0deee) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: -
Matt Roper authored
Rather than embeddeding the display's device info within the main device info structure, just provide a pointer to the display-specific structure. This is in preparation for moving the display device info definitions into the display code itself and for eventually allowing the pointer to be assigned at runtime on platforms that use GMD_ID for device identification. In the future, this will also eventually allow the same display device info structures to be used outside the current i915 code (e.g., from the Xe driver). v2: - Move introduction of DISPLAY_INFO() to this patch. (Andrzej) v3: - Also use DISPLAY_INFO() in intel_display_reg_defs.h. (Andrzej) - Use "{}" instead of "{ 0 }" for empty struct init. (Jani) (cherry picked from commit 5af5169d) Acked-by: -
Matt Roper authored
Moving display-specific substructure definitions will help keep display more self-contained and make it easier to re-use in other drivers (i.e., Xe) in the future. (cherry picked from commit 05aa8e01) Reviewed-by:
-
Matt Roper authored
Wa_14015795083 was already implemented for DG2 and PVC, but the workaround database has been updated to extend it to more platforms. It should now apply to all platforms with graphics versions 12.00 - 12.60, as well as A-step of Xe_LPG (12.70 / 12.71). Reviewed-by:
-
OpenGL stack makes scanout buffers exported as well because usually it will be exported from client application to compositor. Exported buffers needs to be placed in SMEM so it can be accessed by different GPUs if needed, so in discrete GPUs it is placed in SMEM+LMEM. But this combination is causing aplications like kmscube to not be able to create framebuffers. So here doing the same handling as i915 and allowing bos that can migrate to lmem0/vram0 to be promoted to framebuffer. At least all current discrete GPUs with display only have one lmem region, so we don't need to check for vram1 but we might need to extend it in future. Reviewed-by:
Matthew Auld <matthew.auld@intel.com>
-
Lucas De Marchi authored
Use a separate xe_display_driver prefix for functions dealing with the DRM driver struct or the early probe. This splits xe_display_set_driver_hooks() in 2: one to allow the driver to defer the probe if the display needs that and the other to set the additional hooks in the driver struct. Although the hooks are set by every device binding to the module, they only depend on the module param enable_display, so that is safe. Since unset_driver_hooks() is not really tweaking the driver, but rather the driver_features saved in the device, rename it to unset_display_features() to clarify that. Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20230510195424.3045127-5-lucas.demarchi@intel.com Signed-off-by:
-
Lucas De Marchi authored
Stop the dance of enabling the display-related driver_features to later disable them on display info init if the platform doesn't have display IP. Besides being needless work, it wasn't covering the ATS-M case that is the same platform as DG2, but without display. Since now the display is created after the complete device info is populated, the new has_display flag can be consider to enable it. References: drm/xe/kernel#265 Reviewed-by:
-
Lucas De Marchi authored
Some platforms don't have the display IP. Currently those are PVC and ATS-M. For PVC the current initialization order works as the display initialization can check by platform. However the display side can't differentiate ATS-M from DG2 to act accordingly. Reviewed-by:
-
Of the platforms supported by Xe, only TGL and DG1 has PSR HW tracking. Signed-off-by:
-
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: 2a0f49c7ae5b ("drm/xe/display: Move device info initialization to display") Signed-off-by:Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/20230310191430.2229799-1-lucas.demarchi@intel.com
-
DG2 has cdclk squash, without which we calculate the CDCLK wrongly. Alderlake-P is LPD, not gen 12 display. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: drm/xe/kernel#210 Reviewed-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:
-
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:
-
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:
-
