- 17 Apr, 2024 3 commits
-
-
Matthew Auld authored
The asid is only erased from the xarray when the vm refcount reaches zero, however this leads to potential UAF since the xe_vm_get() only works on a vm with refcount != 0. Since the asid is allocated in the vm create ioctl, rather erase it when closing the vm, prior to dropping the potential last ref. This should also work when user closes driver fd without explicit vm destroy. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1594Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412113144.259426-4-matthew.auld@intel.com
-
Matthew Auld authored
We have observed underruns on some platforms if the CFB offset is within the first page of stolen. Just like i915 skip the first page. v2 (Maarten) - Also align the start. BSpec: 50214 Reported-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412150301.273344-4-matthew.auld@intel.com
-
Matthew Auld authored
No need to be so aggressive here. The upper layers will already apply the needed alignment, plus some allocations might wish to skip it. Main issue is that we might want to have start/end bias range which doesn't match the default alignment which is rejected by the allocator. Signed-off-by:
-
- 16 Apr, 2024 9 commits
-
-
Lu Yao authored
ACPI_WMI is a subitem of X86_PLATFORM_DEVICES. And X86_PLATFORM_DEVICES is not selected in the current Kconfig, and may cause Kconfig warnings: WARNING: unmet direct dependencies detected for ACPI_WMI Depends on [n]: X86_PLATFORM_DEVICES [=n] && ACPI [=y] Selected by [m]: - DRM_XE [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y] && (m && MODULES [=y] || y && KUNIT [=y]=y) && X86 [=y] && ACPI [=y] Signed-off-by:Lu Yao <yaolu@kylinos.cn> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415025215.15811-1-yaolu@kylinos.cnSigned-off-by:
-
John Harrison authored
Enable a couple of existing workarounds for a new platform. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410002646.3002394-3-John.C.Harrison@Intel.com
-
John Harrison authored
There are a couple of new workarounds for LNL that are implemented in the GuC firmware. The KMD needs to enable them explicitly. Signed-off-by:
-
Michal Wajdeczko authored
To run correctly, each Virtual Function must be provisioned with some chunk of shared hardware or firmware resources (like GGTT, device memory, GuC doorbell IDs, GuC context IDs) and scheduling parameters (execution quantum or preemption timeout). All resources assigned to VFs must be excluded from the PF driver use and may require some additional preparation steps (like setup of the LMTT or update of the GGTT PTE). Those provisioning details must be then sent to the GuC firmware as most of those details will be shared later with the VF drivers during their boot. Add basic functions to provision VFs with all hardware resources or scheduling parameters. We will use them shortly in upcoming patches either in manual provisioning over debugfs, exposed to the advanced users, or automatic provisioning done by PF driver during VFs enabling. Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-7-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
The PF driver must maintain additional GT level data per each VF. This additional per-VF data will be added in upcoming patches and will include: provisioning configuration (like GGTT space or LMEM allocation sizes or scheduling parameters), monitoring thresholds and counters, and more. As number of supported VFs varies across platforms use flexible array where first entry will contain metadata for the PF itself (if such configuration parameter is applicable for the PF) and all remaining entries will contain data for potential VFs. Reviewed-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to change VFs configuration and will need to use PF2GUC_UPDATE_VF_CFG messages. Add necessary definitions to our GuC firmware ABI header. Definitions of the GuC VF Configuration KLVs used by this action are already present in abi/guc_klvs_abi.h Reviewed-by:
-
Michal Wajdeczko authored
The PF driver will need to know size of the remaining available VRAM to estimate fair VRAM allocations that could be used across all VFs in automatic VFs provisioning mode. Add helper function for that. We will use it in upcoming patch. Reviewed-by:
-
Michal Wajdeczko authored
VF's drivers can't modify GGTT PTEs except the range explicitly assigned by the PF driver. To allow hardware enforcement of this requirement, each GGTT PTE has a field with the VF number that identifies which VF can modify that particular GGTT PTE entry. Only PF driver can modify this field and PF driver shall do that before VF drivers will be loaded. Add function to prepare PTEs. Since it will be used only by the PF driver, make it available only for CONFIG_PCI_IOV=y. Bspec: 45015, 52395 Reviewed-by:
-
Michal Wajdeczko authored
While the GuC firmware and the Xe driver are using VF identifier VFID(0) to represent the Physical Function, we should avoid using "VF0" name and use proper "PF" name in all user facing messages related to the Physical Function and use "VFn" name only when referrinf to the true Virtual Function. Add simple helper to get properly formatted function name based on the function number. Reviewed-by:
-
- 15 Apr, 2024 1 commit
-
-
Francois Dugast authored
Generate the mask of enabled L3 banks for the GT. It is stored with the rest of the GT topology in a consistent representation across platforms. For now the L3 bank mask is just printed in the log for developers to easily figure out the fusing characteristics of machines that they are trying to debug issues on. Later it can be used to replace existing code in the driver that requires the L3 bank count (not mask). Also the mask can easily be exposed to user space in a new query if needed. v2: Better naming of variable and function (Matt Roper) Bspec: 52545, 52546, 62482 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
- 12 Apr, 2024 9 commits
-
-
Michal Wajdeczko authored
There are few knobs inside GuC firmware to control VFs scheduling. Add basic functions to support their reconfigurations. We will start using them shortly once we prepare debugfs. Signed-off-by:
-
Michal Wajdeczko authored
Many of the GuC actions use KLVs to pass additional parameters or configuration data. Add few helper functions for better reporting any information related to KLVs. Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to change GuC policies and will need to use PF2GUC_UPDATE_VGT_POLICY messages. Add necessary definitions to our GuC firmware ABI header. Reviewed-by:
-
Michal Wajdeczko authored
PF driver will maintain VF's configuration data mostly on the GT level, but some internal data is located at the device level. To allow easy access to that data from the GT level functions, and to minimize code duplications, introduce set of helper functions and macros for explicit use by the PF driver. We will use these helpers in upcoming patches. Reviewed-by:
-
Michal Wajdeczko authored
PF driver will maintain configurations and resources for every VF and this data could span multiple tiles and/or GTs. Prepare mutex to protect data that we will add in upcoming patches. Reviewed-by:
-
Thomas Hellström authored
Backmerging drm-next in order to get up-to-date and in particular to access commit 9ca5facd. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Oak Zeng authored
This is an effort to unify hmmptr (aka system allocator) and userptr code. hmm_range_fault is used to populate a virtual address range for both hmmptr and userptr, instead of hmmptr using hmm_range_fault and userptr using get_user_pages_fast. This also aligns with AMD gpu driver's behavior. In long term, we plan to put some common helpers in this area to drm layer so it can be re-used by different vendors. -v1 use the function with parameter to confirm whether lock is acquired by the caller or needs to be acquired in hmm_range_fault. Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Signed-off-by:
-
Oak Zeng authored
Introduce a helper function xe_userptr_populate_range to populate a userptr range. This functions calls hmm_range_fault to read CPU page tables and populate all pfns/pages of this virtual address range. For system memory page, dma-mapping is performed to get a dma-address which can be used later for GPU to access pages. v1: Address review comments: separate a npage_in_range function (Matt) reparameterize function xe_userptr_populate_range function (Matt) move mmu_interval_read_begin() call into while loop (Thomas) s/mark_range_accessed/xe_mark_range_accessed (Thomas) use set_page_dirty_lock (vs set_page_dirty) (Thomas) move a few checking in xe_vma_userptr_pin_pages to hmm.c (Matt) v2: Remove device private page support. Only support system pages for now. use dma-map-sg rather than dma-map-page (Matt/Thomas) v3: Address review comments: Squash patch "drm/xe: Introduce a helper to free sg table" to current patch (Matt) start and end addresses are already page aligned (Matt) Do mmap_read_lock and mmap_read_unlock for hmm_range_fault incase of non system allocator call. (Matt) Drop kthread_use_mm and kthread_unuse_mm. (Matt) No need of kernel-doc for static functions.(Matt) Modify function names. (Matt) Free sgtable incase of dma_map_sgtable failure.(Matt) Modify loop for hmm_range_fault.(Matt) v4: Remove the dummy function for xe_hmm_userptr_populate_range since CONFIG_HMM_MIRROR is needed. (Matt) Change variable names start/end to userptr_start/userptr_end.(Matt) v5: Remove device private page support info from commit message. Since the patch doesn't support device page handling. (Thomas) Signed-off-by:Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Add a unreference bo in the error path, to prevent leaking a bo ref. Return 0 on success to clarify the success path. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404090302.68422-1-maarten.lankhorst@linux.intel.com
-
- 11 Apr, 2024 3 commits
-
-
José Roberto de Souza authored
This will remove devcoredump from file system and free its resources during driver unload. This fix the driver unload after gpu hang happened, otherwise this it would report that Xe KMD is still in use and it would leave the kernel in a state that Xe KMD can't be unload without a reboot. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409200206.108452-2-jose.souza@intel.comSigned-off-by:
-
José Roberto de Souza authored
It is useful for modules that do not want to keep coredump available after its unload. Otherwise, the coredump would only be removed after DEVCD_TIMEOUT seconds. v2: - dev_coredump_put() documentation updated (Mukesh) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mukesh Ojha <quic_mojha@quicinc.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409200206.108452-1-jose.souza@intel.comSigned-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-2024-04-10' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.10: Cross-subsystem Changes: - Add Tomi as Xilinx maintainer. - Add sound bindings to DT. Core Changes: - Make DP helper depend on KMS helper. Driver Changes: - Assorted small fixes to bridge/dw-hdmi, bridge/cdns-mhdp8456, xlnx, omap, tilcdc, bridge/imx8mp-hdmi-pvi. - Add debugfs entries to qaic. - Add conservative fallback to panel eDP. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/dc690de5-17da-4af6-93a9-8078c99245fd@linux.intel.com
-
- 10 Apr, 2024 15 commits
-
-
Nathan Chancellor authored
A recent change added a use of xe_wa_oob.h without adding the file that uses it to uses_generated_oob, which means xe_wa_oob.h does not get properly generated before attempting to build the object file: LINK resolve_btfids CC [M] drivers/gpu/drm/xe/xe_guc_ads.o drivers/gpu/drm/xe/xe_guc_ads.c:10:10: fatal error: generated/xe_wa_oob.h: No such file or directory 10 | #include <generated/xe_wa_oob.h> | ^~~~~~~~~~~~~~~~~~~~~~~ After adding '$(obj)/xe_guc_ads.o' to uses_generated_oob, xe_wa_oob.h is always generated before building the file, resulting in no errors: LINK resolve_btfids HOSTCC drivers/gpu/drm/xe/xe_gen_wa_oob GEN xe_wa_oob.c xe_wa_oob.h CC [M] drivers/gpu/drm/xe/xe_guc_ads.o Fixes: c151ff5c ("drm/xe/lnl: Enable GuC Wa_14019882105") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
-
Michal Wajdeczko authored
GuC CTB is related to the GT, so best to use xe_gt_assert(). Signed-off-by:
-
Michal Wajdeczko authored
A platform can have more than one GuC, so we should use GT-oriented logs to refer to specific GuC. Signed-off-by:
-
Riana Tauro authored
Lmem init check should be done only after pcode initialization status is complete. Move lmem init check after pcode status check. Also wait for a short while after pcode status check to allow completion of the task. Failing to do so, can lead to aborting the module load leaving the system unusable. Wait until the lmem initialization is complete within a timeout (60s) or till the user aborts. v2: use bool as return type re-order the code comment (Rodrigo) add comment for deferring probe (Himal) v3: rebase Signed-off-by:Riana Tauro <riana.tauro@intel.com> Acked-by:
-
Riana Tauro authored
The root tile indicates the pcode initialization is complete when all tiles have completed their initialization. So the mailbox can be polled only on the root tile. Check pcode init status only on root tile and move it to device probe early as root tile is initialized there. Also make similar changes in resume paths. v2: add lock/unlocked version of pcode_mailbox_rw to allow pcode init to be called in device early probe (Rodrigo) v3: add code description about using root tile change function names to xe_pcode_probe_early and xe_pcode_init (Rodrigo) Signed-off-by: -
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
Wolfram Sang authored
Since commit ab78029e ("drivers/pinctrl: grab default handles from device core"), we can rely on device core for setting the default pins. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230922073714.6164-1-wsa+renesas@sang-engineering.com
-
Krzysztof Kozlowski authored
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Dan Carpenter authored
Free "dp" before returning. Fixes: be318d01 ("drm: xlnx: dp: Reset DisplayPort IP") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Tomi Valkeinen authored
Add myself as a co-maintainer for Xilinx DRM drivers to help Laurent. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Michal Wajdeczko authored
As SR-IOV support varies between platforms and the driver can run in different SR-IOV modes, add debugfs file with these details. Signed-off-by:
-
Michal Wajdeczko authored
SR-IOV PF mode detection is based on PCI capability as reported by the PCI dev_is_pf() function and additionally on 'max_vfs' module parameter which could be also used to disable PF capability even if SR-IOV PF capability is reported by the hardware. Signed-off-by:
-
Michal Wajdeczko authored
We want to have an option to limit the number of the VFs that the PF driver will be able to manage. With this limit set to zero we will also have a way to completely disable the PF functionality. Since we currently don't support SR-IOV on any platform, we start with this limit set to zero by default. Signed-off-by:
-
Michal Wajdeczko authored
We may leave pat.ops unset when running on brand new platform or when running as a VF. While the former is unlikely, the latter is valid (future) use case and will cause NPD when someone will try to dump PAT settings by debugfs. It's better to check pointer to pat.ops instead of specific .dump hook, as we have this hook always defined for every .ops variant. Signed-off-by:
-
Michal Wajdeczko authored
Make sure that pat.ops (if selected) has all required function pointers setup. Only .program_media may be omitted if we have older media version. This should help avoid late runtime checks against individual function pointers. Signed-off-by:
-
