aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2024-04-18drm/xe: Remove useless mem_access during probeRodrigo Vivi5-34/+5
xe_pm_init is the very last thing during the xe_pci_probe(), hence these protections are useless from the point of view of ensuring that the device is awake. Let's remove it so we continue towards the goal of killing xe_device_mem_access. v2: Adding more cases v3: Provide a separate fix for xe_tile_init_noalloc return (Matt) Adding a new case where display HDCP init calls which are also called at display probe time. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-5-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-18drm/xe: Move lockdep protection from mem_access to xe_pm_runtimeRodrigo Vivi3-35/+37
The mem_access itself is not holding any lock, but attempting to train lockdep with possible scarring locks happening during runtime pm. We are going soon to kill the mem_access get and put helpers in favor of direct xe_pm_runtime calls, so let's just move this lock around to where it now belongs. v2: s/lockdep_training/lockdep_prime (Matt Auld) Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-4-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-18drm/i915/display: convert inner wakeref get towards get_if_in_useRodrigo Vivi1-1/+1
This patch brings no functional change. Since at this point of the code we are already asserting a wakeref was held, it means that we are with runtime_pm 'in_use' and in practical terms we are only bumping the pm_runtime usage counter and moving on. However, xe driver has a lockdep annotation that warned us that if a sync resume was actually called at this point, we could have a deadlock because we are inside the power_domains->lock locked area and the resume would call the irq_reset, which would also try to get the power_domains->lock. For this reason, let's convert this call to a safer option and calm lockdep on. v2: use _noresume variant instead of get_in_use (Ville, Imre) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-18drm/xe: Introduce intel_runtime_pm_get_noresume at compat-i915-headers for displayRodrigo Vivi1-0/+8
The i915-display will start using the intel_runtime_pm_noresume. So we need to add the compat header before it. Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-18drm/xe: Introduce xe_pm_runtime_get_noresume for inner callersRodrigo Vivi3-2/+23
Let's ensure that we have an option for inner callers that will raise WARN if device is not active and not protected by outer callers. Make this also a void function forcing every caller to unconditionally put the reference back afterwards. This will be very important for cases where we want to hold the reference before scheduling a work in a queue. Then the work job will be responsible for putting it back. While at this, already convert a case from mem_access_get_ongoing where it is not checking for the reference and put it back, what would cause the underflow. v2: Fix identation. v3: Convert equivalent missing put from mem_access towards pm_runtime. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-17drm/xe/lnl: Apply GuC Wa_13011645652Vinay Belgaumkar3-0/+40
Enable WA for a bug that could cause the C6 state machine to hang during RC6 exit. v2: Add comment clarifying the WA (John H) v3: Add more details to the comment (John H) Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417054802.1766359-1-vinay.belgaumkar@intel.com
2024-04-17drm/xe/vm: don't include xe_gt.hMatthew Auld1-1/+0
clangd complains here, since nothing in xe_gt.h seems to be needed. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412113144.259426-6-matthew.auld@intel.com
2024-04-17drm/xe/vm: drop vm->destroy_workMatthew Auld2-22/+2
Now that we no longer grab the usm.lock mutex (which might sleep) it looks like it should be safe to directly perform xe_vm_free when vm refcount reaches zero, instead of punting that off to some worker. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412113144.259426-5-matthew.auld@intel.com
2024-04-17drm/xe/vm: prevent UAF with asid based lookupMatthew Auld1-10/+11
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: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1594 Signed-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
2024-04-17drm/xe/stolen: ignore first page for FBCMatthew Auld1-1/+6
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: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412150301.273344-4-matthew.auld@intel.com
2024-04-17drm/xe/stolen: lower the default alignmentMatthew Auld1-6/+2
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: Matthew Auld <matthew.auld@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412150301.273344-3-matthew.auld@intel.com
2024-04-16drm/xe: select X86_PLATFORM_DEVICES when ACPI_WMI is selectedLu Yao1-0/+1
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.cn Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-16drm/xe/bmg: Some LNL workarounds also apply to BMGJohn Harrison1-2/+4
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
2024-04-16drm/xe/lnl: Enable more GuC based workaroundsJohn Harrison3-0/+13
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: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410002646.3002394-2-John.C.Harrison@Intel.com
2024-04-16drm/xe/pf: Add support to configure SR-IOV VFsMichal Wajdeczko5-1/+2089
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
2024-04-16drm/xe/pf: Add SR-IOV PF specific early GT initializationMichal Wajdeczko5-0/+89
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 <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-6-michal.wajdeczko@intel.com
2024-04-16drm/xe/guc: Add PF2GUC_UPDATE_VF_CFG to ABIMichal Wajdeczko1-0/+55
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: 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-5-michal.wajdeczko@intel.com
2024-04-16drm/xe: Add xe_ttm_vram_get_availMichal Wajdeczko2-0/+13
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: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-4-michal.wajdeczko@intel.com
2024-04-16drm/xe: Allow to assign GGTT region to the VFMichal Wajdeczko3-0/+50
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-3-michal.wajdeczko@intel.com
2024-04-16drm/xe: Add helper to format SR-IOV function nameMichal Wajdeczko2-0/+18
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-2-michal.wajdeczko@intel.com
2024-04-15drm/xe/gt: Add L3 bank mask to GT topologyFrancois Dugast3-4/+124
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410123723.7-2-francois.dugast@intel.com
2024-04-12drm/xe/pf: Add support to configure GuC SR-IOV policiesMichal Wajdeczko6-0/+502
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 <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410170338.1199-6-michal.wajdeczko@intel.com
2024-04-12drm/xe/guc: Add helpers for GuC KLVsMichal Wajdeczko3-0/+186
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Acked-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410170338.1199-5-michal.wajdeczko@intel.com
2024-04-12drm/xe/guc: Add PF2GUC_UPDATE_VGT_POLICY to ABIMichal Wajdeczko1-0/+47
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410170338.1199-4-michal.wajdeczko@intel.com
2024-04-12drm/xe/pf: Introduce helper functions for use by PFMichal Wajdeczko2-0/+81
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410170338.1199-3-michal.wajdeczko@intel.com
2024-04-12drm/xe/pf: Introduce mutex to protect VFs configurationsMichal Wajdeczko4-0/+32
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: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410170338.1199-2-michal.wajdeczko@intel.com
2024-04-12drm/xe: Use hmm_range_fault to populate user pagesOak Zeng1-111/+6
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: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Oak Zeng <oak.zeng@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412095237.1048599-3-himal.prasad.ghimiray@intel.com
2024-04-12drm/xe: Introduce helper to populate userptrOak Zeng4-0/+267
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: Oak Zeng <oak.zeng@intel.com> Co-developed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: Brian Welty <brian.welty@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412095237.1048599-2-himal.prasad.ghimiray@intel.com
2024-04-12drm/xe: Fix bo leak in intel_fb_bo_framebuffer_initMaarten Lankhorst1-2/+6
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404090302.68422-1-maarten.lankhorst@linux.intel.com
2024-04-11drm/xe: Remove devcoredump during driver releaseJosé Roberto de Souza3-1/+22
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.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-11devcoredump: Add dev_coredump_put()José Roberto de Souza2-0/+28
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: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409200206.108452-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-10drm/xe: Add xe_guc_ads.c to uses_generated_oobNathan Chancellor1-0/+1
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: c151ff5c9053 ("drm/xe/lnl: Enable GuC Wa_14019882105") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410-drm-xe-fix-xe_guc_ads-using-xe_wa_oob-v1-1-441f2d8e5d83@kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-10drm/xe/guc: Prefer GT oriented asserts in CTB codeMichal Wajdeczko1-22/+22
GuC CTB is related to the GT, so best to use xe_gt_assert(). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404193647.759-2-michal.wajdeczko@intel.com
2024-04-10drm/xe/guc: Prefer GT oriented logs in GuC CTB codeMichal Wajdeczko1-32/+30
A platform can have more than one GuC, so we should use GT-oriented logs to refer to specific GuC. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404193647.759-1-michal.wajdeczko@intel.com
2024-04-10drm/xe: re-order lmem init check and wait for initialization to completeRiana Tauro3-28/+59
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410085005.1126343-3-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-10drm/xe: check pcode init status only on root gt of root tileRiana Tauro4-64/+94
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: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410085005.1126343-2-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-10drm/bridge: imx8mp-hdmi-pvi: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240304090555.716327-2-u.kleine-koenig@pengutronix.de
2024-04-10drm: tilcdc: don't use devm_pinctrl_get_select_default() in probeWolfram Sang1-6/+0
Since commit ab78029ecc34 ("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
2024-04-10drm/omap: dmm_tiler: drop driver owner assignmentKrzysztof Kozlowski1-1/+0
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: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240330202804.83936-1-krzysztof.kozlowski@linaro.org
2024-04-10drm: xlnx: db: fix a memory leak in probeDan Carpenter1-1/+1
Free "dp" before returning. Fixes: be318d01a903 ("drm: xlnx: dp: Reset DisplayPort IP") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/86def134-9537-4939-912e-3a424e3a75b6@moroto.mountain
2024-04-10MAINTAINERS: Add myself as maintainer for Xilinx DRM driversTomi Valkeinen1-0/+1
Add myself as a co-maintainer for Xilinx DRM drivers to help Laurent. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327-xilinx-maintainer-v1-1-c5fdc115f448@ideasonboard.com
2024-04-10drm/xe: Add SR-IOV info attribute to debugfsMichal Wajdeczko3-0/+28
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404154431.583-4-michal.wajdeczko@intel.com
2024-04-10drm/xe: Add proper detection of the SR-IOV PF modeMichal Wajdeczko6-1/+137
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404154431.583-3-michal.wajdeczko@intel.com
2024-04-10drm/xe: Add max_vfs module parameterMichal Wajdeczko2-0/+10
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404154431.583-2-michal.wajdeczko@intel.com
2024-04-10drm/xe: Check pat.ops before dumping PAT settingsMichal Wajdeczko1-1/+1
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 <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409105106.1067-2-michal.wajdeczko@intel.com
2024-04-10drm/xe: Assert pat.ops function pointersMichal Wajdeczko1-0/+4
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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409105106.1067-1-michal.wajdeczko@intel.com
2024-04-10drm: remove unused header gma_drm.hJani Nikula1-13/+0
gma_drm.h has become an empty, unused header. Remove. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408104230.3191827-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-09drm/xe/xe2hpm: Add initial set of workaroundsGustavo Sousa2-0/+36
Define the initial set of workarounds for Xe2_HPM. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-12-balasubramani.vivekanandan@intel.com
2024-04-09drm/xe/xe2hpg: Introduce performance tuning changes for Xe2_HPG.Shekhar Chauhan1-3/+3
Introduces performance tuning guide changes for Xe_HPG. v2: Switched to open upper bound for "Tuning: L3 Cache" setting. BSpec: 72161 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-11-balasubramani.vivekanandan@intel.com
2024-04-09drm/xe/xe2hpg: Add initial GT workaroundsHaridhar Kalvala2-2/+70
Add the initial set of Xe2_HPG gt/engine/lrc workarounds. v2: Removed WA_16020183090 which is no more applicable Extended WA_18033852989,18034896535 also to xe2hpg Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Dnyaneshar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-10-balasubramani.vivekanandan@intel.com