aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-12-21drm/xe: Only set xe_vma_op.map fields for GPUVA map operationsMatthew Brost1-41/+18
DRM_XE_VM_BIND_OP_MAP_* IOCTL operations can result in GPUVA unmap, remap, or map operations in vm_bind_ioctl_ops_create. The xe_vma_op.map fields are blindly set which is incorrect for GPUVA unmap or remap operations. Fix this by only setting xe_vma_op.map for GPUVA map operations. Also restructure a bit vm_bind_ioctl_ops_create to make the code a bit more readable. Reported-by: Dafna Hirschfeld <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Brian Welty <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Remove GEN[0-9]*_ prefixesLucas De Marchi11-52/+52
After noticing in logs there were still mentions to GEN6 registers, it was clear commit d9b79ad275e7 ("drm/xe: Drop gen afixes from registers") didn't take care of all the afixes. Some were added later, but there are also constants and strings still using that. Continue the cleanup removing the remaining ones. To keep it consistent with code nearby, a few other changes are made: - Remove prefix in INTEL_LEGACY_64B_CONTEXT - Remove GEN8_CTX_L3LLC_COHERENT since it's unused - Rename GEN9_FREQ_SCALER to GT_FREQUENCY_SCALER v2: Use XELP_ as prefix for NUM_MOCS_ENTRIES and remove changes to MOCS_ENTRIES as this is now done as part of a previous commit (Matt Roper) Reviewed-by: Matt Roper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/mocs: Bring comment about mocs back to realityLucas De Marchi1-21/+11
The mocs documentation was copied from i915 and doesn't match the reality in xe. Reword it so it matches what the code is doing. Reviewed-by: Matt Roper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fold GEN11_MOCS_ENTRIES into gen12_mocs_descLucas De Marchi1-116/+112
GEN11_MOCS_ENTRIES dates back from importing the table from the i915 module. The macro was used so the it could be maintained in a single place and platforms would just override with additional entries. With the platforms supported by xe, each of them is just defining individual tables without re-using this define. Move it inside gen12_mocs_desc that is the only user. Reviewed-by: Matt Roper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: don't hold dma-resv lock over drm_gem_handle_createMatthew Auld1-8/+12
This seems to create a locking inversion with object_name_lock. The lock is held by drm_prime_fd_to_handle when calling our xe_gem_prime_import hook, which might eventually go on to grab the dma-resv lock during the attach. However we also have the opposite locking order in xe_gem_create_ioctl which is holding the dma-resv lock when calling drm_gem_handle_create, which wants to eventually grab object_name_lock: -> #1 (reservation_ww_class_mutex){+.+.}-{3:3}: <4> [635.739288] lock_acquire+0x169/0x3d0 <4> [635.739294] __ww_mutex_lock.constprop.0+0x164/0x1e60 <4> [635.739300] ww_mutex_lock_interruptible+0x42/0x1a0 <4> [635.739305] drm_gem_shmem_pin+0x4b/0x140 [drm_shmem_helper] <4> [635.739317] dma_buf_dynamic_attach+0x101/0x430 <4> [635.739323] xe_gem_prime_import+0xcc/0x2e0 [xe] <4> [635.739499] drm_prime_fd_to_handle_ioctl+0x184/0x2e0 [drm] <4> [635.739594] drm_ioctl_kernel+0x16f/0x250 [drm] <4> [635.739693] drm_ioctl+0x35e/0x620 [drm] <4> [635.739789] __x64_sys_ioctl+0xb7/0xf0 <4> [635.739794] do_syscall_64+0x3c/0x90 <4> [635.739799] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 <4> [635.739805] -> #0 (&dev->object_name_lock){+.+.}-{3:3}: <4> [635.739813] check_prev_add+0x1ba/0x14a0 <4> [635.739818] __lock_acquire+0x203e/0x2ff0 <4> [635.739823] lock_acquire+0x169/0x3d0 <4> [635.739827] __mutex_lock+0x124/0x1310 <4> [635.739832] drm_gem_handle_create+0x32/0x50 [drm] <4> [635.739927] xe_gem_create_ioctl+0x1d3/0x550 [xe] <4> [635.740102] drm_ioctl_kernel+0x16f/0x250 [drm] <4> [635.740197] drm_ioctl+0x35e/0x620 [drm] <4> [635.740293] __x64_sys_ioctl+0xb7/0xf0 <4> [635.740297] do_syscall_64+0x3c/0x90 <4> [635.740302] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 <4> [635.740307] It looks like it should be safe to simply drop the dma-resv lock prior to publishing the object when calling drm_gem_handle_create. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/743 Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Use valid scratch register for posting readMichal Wajdeczko1-1/+1
There are only 4 scratch registers VF_SW_FLAG(0..3) on each GuC. We shouldn't use non-existing register VF_SW_FLAG(4) for posting read. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Fix handling of GUC_HXG_TYPE_NO_RESPONSE_BUSYMichal Wajdeczko1-3/+14
If GuC responds with the NO_RESPONSE_BUSY message, we extend our timeout while waiting for the actual response, but we wrongly assumed that the next message will be RESPONSE_SUCCESS, missing that we still can get RESPONSE_FAILURE. Change the condition for the expected message type, using only common bits from RESPONSE_SUCCESS and RESPONSE_FAILURE (as they differ, by ABI design, only by the last bit). v2: add comment/checks to the code (Matt) Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Copy response data from proper registersMichal Wajdeczko1-1/+1
While copying GuC response from the scratch registers to the buffer, formula to identify next scratch register is broken. Fix it. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Fix wrong assert about full_lenMichal Wajdeczko1-1/+1
This variable holds full length of the message, including header length so it should be checked against GUC_CTB_MSG_MAX_LEN. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/dg2: Wa_18028616096 now applies to all DG2Matt Roper1-6/+1
The workaround database was just updated to extend this workaround to DG2-G11 (whereas previously it applied only to G10 and G12). Reviewed-by: Gustavo Sousa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Be more specific about the vm_bind prefetch regionRodrigo Vivi1-7/+8
Let's bring a bit of clarity on this 'region' field that is part of vm_bind operation struct. Rename and document to make it more than obvious that it is a region instance and not a mask and also that it should only be used with the prefetch operation itself. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matt Roper <[email protected]>
2023-12-21drm/xe/uapi: Differentiate WAIT_OP from WAIT_MASKRodrigo Vivi1-7/+7
On one hand the WAIT_OP represents the operation use for waiting such as ==, !=, > and so on. On the other hand, the mask is applied to the value used for comparision. Split those two to bring clarity to the uapi. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matt Roper <[email protected]>
2023-12-21drm/xe/uapi: Standardize the FLAG naming and assignmentRodrigo Vivi1-1/+1
Only cosmetic things. No functional change on this patch. Define every flag with (1 << n) and use singular FLAG name. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]>
2023-12-21drm/xe/uapi: Rename query's mem_usage to mem_regionsRodrigo Vivi1-8/+8
'Usage' gives an impression of telemetry information where someone would query to see how the memory is currently used and available size, etc. However this API is more than this. It is about a global view of all the memory regions available in the system and user space needs to have this information so they can then use the mem_region masks that are returned for the engine access. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Rename *_mem_regions masksRodrigo Vivi1-4/+4
- 'native' doesn't make much sense on integrated devices. - 'slow' is not necessarily true and doesn't go well with opposition to 'native'. Instead, let's use 'near' vs 'far'. It makes sense with all the current Intel GPUs and it is future proof. Right now, there's absolutely no need to define among the 'far' memory, which ones are slower, either in terms of latency, nunmber of hops or bandwidth. In case of this might become a requirement in the future, a new query could be added to indicate the certain 'distance' between a given engine and a memory_region. But for now, this fulfill all of the current requirements in the most straightforward way for the userspace drivers. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Change rsvd to pad in struct drm_xe_class_instanceFrancois Dugast1-1/+4
Change rsvd to pad in struct drm_xe_class_instance to prevent the field from being used in future. v2: Change from fixup to regular commit because this touches the uAPI (Francois Dugast) Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Add _FLAG to uAPI constants usable for flagsFrancois Dugast4-30/+30
Most constants defined in xe_drm.h which can be used for flags are named DRM_XE_*_FLAG_*, which is helpful to identify them. Make this systematic and add _FLAG where it was missing. Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Add missing DRM_ prefix in uAPI constantsFrancois Dugast7-78/+78
Most constants defined in xe_drm.h use DRM_XE_ as prefix which is helpful to identify the name space. Make this systematic and add this prefix where it was missing. v2: - fix vertical alignment of define values - remove double DRM_ in some variables (José Roberto de Souza) v3: Rebase Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Make xe_mmio_tile_vram_size() staticBrian Welty3-7/+4
During xe_mmio_probe_vram(), we already store the values returned from xe_mmio_tile_vram_size() into the xe_tile structures. There is no need to call xe_mmio_tile_vram_size() again later during setup of the STOLEN region. Just use the values stored in the root tile. Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matt Roper <matthew.d.roper at intel.com> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/pmu: Drop interrupt pmu eventAravind Iddamsetty3-40/+5
Drop interrupt event from PMU as that is not useful and not being used by any UMD. Cc: Rodrigo Vivi <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Francois Dugast <[email protected]> Signed-off-by: Aravind Iddamsetty <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Remove unused QUERY_CONFIG_GT_COUNTFrancois Dugast1-1/+0
As part of uAPI cleanup, remove this constant which is not used. Number of GTs are provided as num_gt in drm_xe_query_gt_list. Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Remove unused QUERY_CONFIG_MEM_REGION_COUNTFrancois Dugast1-2/+0
As part of uAPI cleanup, remove this constant which is not used. Memory regions can be queried with DRM_XE_DEVICE_QUERY_MEM_USAGE. Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Kill VM_MADVISE IOCTLRodrigo Vivi6-321/+7
Remove unused IOCTL. Without any userspace using it we need to remove before we can be accepted upstream. At this point we are breaking the compatibility for good, so we don't need to break when we are in-tree. So, let's also use this breakage to sort out the IOCTL entries and fix all the small indentation and line issues. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Remove GT_TYPE_REMOTERodrigo Vivi1-2/+0
With the split between tile and gt, this is currently unused. Also it is bringing confusion because main vs remote would be more a concept of the tile itself and not about GT. So, the MAIN one is the traditional GT used for every operation in older platforms, and for render/graphics and compute on platforms that contains the stand-alone Media GT. Cc: Matt Roper <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Carl Zhang <[email protected]> Cc: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Remove useless XE_QUERY_CONFIG_NUM_PARAMFrancois Dugast1-1/+1
num_params can be used to retrieve the size of the info array for the specific version of the kernel being used. v2: Also remove XE_QUERY_CONFIG_NUM_PARAM (José Roberto de Souza) Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Promote guc_to_gt/xe helpers to .hMichal Wajdeczko7-60/+11
Duplicating these helpers in almost every .c file is a bad idea. Define them as inlines in .h file to allow proper reuse. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add writing of remapped dptJuha-Pekka Heikkila1-6/+46
Xe need to use remapped display page table for tiled framebuffers on anywhere else than DG2. Here add function to write such dpt and enable usage of remapped display page tables where needed. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Don't try to use vram if not availableJuha-Pekka Heikkila1-5/+6
Trying to get bo from vram when vram not available will cause WARN_ON() hence avoid touching vram if not available. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/hdcp: Define intel_hdcp_gsc_check_status in XeSuraj Kandpal1-0/+10
Define intel_hdcp_gsc_check_status in Xe to account for changes in i915 and Xe. intel_hdcp_check_status always returns false as gsc cs interface is not yet ported. intel_hdcp_gsc_cs_required always returns true as going forward gsc cs will always be required by upcoming platforms --v5 -Define intel_hdcp_gsc_cs_required() --v6 -Explain reasons for the return values [Chaitanya] Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Chaitanya Kumar Borah <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Create a dummy version for vga decodeUma Shankar2-0/+17
This introduces an exclusive version of vga decode for xe. Rest of the display changes will be re-used from i915. Currently it adds just a dummy implementation. VGA decode needs to be handled correctly in i915, proper implementation will be adopted once the i915 changes are finalized and merged in upstream. v2: Addressed Arun's review comments Signed-off-by: Uma Shankar <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add Xe implementation for fence checks used by fbc codeJouni Högander3-0/+14
Xe doesn't support legacy fences. Implement legacy fence and fence id checks accordingly. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add i915_gem.h compatibility headerJouni Högander2-0/+10
Add i915_gem.h compatibility header and include it in i915_drv.h. Add empty GEM_BUG_ON definition for fbc code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Xe stolen memory handling for fbc supportJouni Högander2-0/+80
Add Xe stolen memory handling for fbc. v3: - v2: Add parenthesis around parameter in i915_gem_stolen_node_allocated v2: - define i915_gem_stolen_area_address/size as !WARN_ON(1) - squash common type addition into this patch Signed-off-by: Jouni Högander <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add empty define for i915_ggtt_clear_scanoutJouni Högander1-0/+1
Add empty define for i915_ggtt_clear_scanout to avoid build failure. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add empty def for i915_gem_object_flush_if_displayJouni Högander1-0/+2
We don't need i915_gem_object_flush_if_display on Xe side. Add empty define to tackle compilation errors with display code where it's used. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add i915_active.h compatibility headerJouni Högander1-0/+22
Add empty definitions for i915_active_init/fini to kill ifdefs from frontbuffer tracking code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add frontbuffer setter/getter for xe_boJouni Högander1-0/+12
Xe is not carrying frontbuffer pointer in xe_bo. Define it's getter as NULL. Setter simply returns pointer which was provided as a parameter. v3: Do not take any references v2: Handle xe_bo_put as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add macro to get i915 device from xe_boJouni Högander1-0/+3
Add helper macro to kill couple of #ifdefs Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add struct i915_active for XeJouni Högander1-0/+13
Add empty definition for struct i915_active to kill ifdefs from frontbuffer tracking code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Use acpi_target_system_state only if ACPI_SLEEP is enabledFrancois Dugast1-2/+11
This fixes the build error below with CONFIG_ACPI_SLEEP=n: drivers/gpu/drm/xe/xe_display.c:334:23: error: implicit declaration of function ‘acpi_target_system_state’; did you mean ‘acpi_get_system_info’? [-Werror=implicit-function-declaration] 334 | bool s2idle = acpi_target_system_state() < ACPI_STATE_S3; Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: fix error handling flow when device probing failsKoby Elbaz1-2/+2
Upon device probe failure, rolling back the initialization should be done in reversed order. Signed-off-by: Koby Elbaz <[email protected]> Reviewed-by: Ohad Sharabi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: ensure clear-color surfaces are cpu mappableMatthew Auld1-0/+17
The KMD needs to access the clear-color value stored in the buffer via the CPU. On small-bar systems reject any buffers that are potentially not CPU accessible. Signed-off-by: Matthew Auld <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Gwan-gyeong Mun <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Filip Hazubski <[email protected]> Cc: Carl Zhang <[email protected]> Cc: Effie Yu <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> [ Split display-related changes from small-bar support ] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Silence kernel-doc warnings related to displayLucas De Marchi1-0/+2
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: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Lucas De Marchi <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Improve s2idle handling.Maarten Lankhorst3-14/+4
We accidentally always pass true as s2idle argument, instead of calculating it in the same way as i915. Suspend modes were removed to achieve compatibility with i915, but accidentally left in the source code. While at it, fix all other cases too, s2idle will go into a D1 state and setting a lower power state should be handled by PCI core. Maybe my laptop stops draining so much power during suspend now? I can only hope.. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Implement display supportMaarten Lankhorst59-51/+2873
As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. We do this by recompiling i915/display code twice. Now that i915 has been adapted to support the Xe build, we can add the xe/display support. This initial work is a collaboration of many people and unfortunately this squashed patch won't fully honor the proper credits. But let's try to add a few from the squashed patches: Co-developed-by: Matthew Brost <[email protected]> Co-developed-by: Jani Nikula <[email protected]> Co-developed-by: Lucas De Marchi <[email protected]> Co-developed-by: Matt Roper <[email protected]> Co-developed-by: Mauro Carvalho Chehab <[email protected]> Co-developed-by: Rodrigo Vivi <[email protected]> Co-developed-by: Dave Airlie <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]>
2023-12-21drm/xe: Use pool of ordered wq for GuC submissionMatthew Brost2-4/+71
To appease lockdep, use a pool of ordered wq for GuC submission rather tha leaving the ordered wq allocation to the drm sched. Without this change eventually lockdep runs out of hash entries (MAX_LOCKDEP_CHAINS is exceeded) as each user allocated exec queue adds more hash table entries to lockdep. A pool old of 256 ordered wq should be enough to have similar behavior with and without lockdep enabled. Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Raise GT frequency before GuC/HuC loadVinay Belgaumkar4-2/+57
Starting GT freq is usually RPn. Raising freq to RP0 will help speed up GuC load times. As an example, this data was collected on DG2- GuC Load time @RPn ~ 41 ms GuC Load time @RP0 ~ 11 ms v2: Raise GT freq before hwconfig init. This will speed up both HuC and GuC loads. Address review comments (Rodrigo). Also add a small usleep after requesting frequency which gives pcode some time to react. v3: Address checkpatch issue Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix build with KUNIT=mLucas De Marchi1-1/+1
Due to the current integration between "live" xe kunit tests and kunit, it's not possible to have a build with the following combination: CONFIG_DRM_XE=y CONFIG_KUNIT=m ... even if kconfig doesn't block it. The reason for the failure is that some compilation units are pulled in xe.ko: drivers/gpu/drm/xe/xe_bo.c:#include "tests/xe_bo.c" drivers/gpu/drm/xe/xe_dma_buf.c:#include "tests/xe_dma_buf.c" drivers/gpu/drm/xe/xe_migrate.c:#include "tests/xe_migrate.c" drivers/gpu/drm/xe/xe_pci.c:#include "tests/xe_pci.c" Those files shouldn't use symbols from kunit, which should be reserved to the tests/*_test.c files. Detangling this dependency doesn't seem very straightforward, so fix the immediate issue instructing kconfig to block the problematic configuration. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Drop EXECLIST_CONTROL from error state dumpMatt Roper2-6/+0
EXECLIST_CONTROL ($enginebase + 0x550) is a write-only register; we shouldn't be trying to read or report it as part of the device error state. Bspec: 45910, 60335 Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tests: Fix migrate testPallavi Mishra1-1/+1
Pass a valid vm to xe_migrate_update_pgtables. Resolves NPD crash seen with igt@xe_live_ktest@migrate Reviewed-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Pallavi Mishra <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.