summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-21drm/xe: Use a flags field instead of bools for VMA createMatthew Brost
Use a flags field instead of severval bools for VMA create as it is easier to read and less bug prone. Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use DRM_GPUVM_RESV_PROTECTED for gpuvmThomas Hellström
Use DRM_GPUVM_RESV_PROTECTED to use corse-grained locking for the evict and external object list. Since we are already holding the relevant RESV locks, for now at least, we don't need the fine-grained locking. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231212100144.6833-3-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use DRM GPUVM helpers for external- and evicted objectsThomas Hellström
Adapt to the DRM_GPUVM helpers moving removing a lot of complicated driver-specific code. For now this uses fine-grained locking for the evict list and external object list, which may incur a slight performance penalty in some situations. v2: - Don't lock all bos and validate on LR exec submissions (Matthew Brost) - Add some kerneldoc Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231212100144.6833-2-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Fix lockdep warning in xe_force_wake callsAravind Iddamsetty
Use spin_lock_irqsave, spin_unlock_irqrestore Fix for below: [13994.811263] ======================================================== [13994.811295] WARNING: possible irq lock inversion dependency detected [13994.811326] 6.6.0-rc3-xe #2 Tainted: G U [13994.811358] -------------------------------------------------------- [13994.811388] swapper/0/0 just changed the state of lock: [13994.811416] ffff895c7e044db8 (&cpuctx_lock){-...}-{2:2}, at: __perf_event_read+0xb7/0x3a0 [13994.811494] but this lock took another, HARDIRQ-unsafe lock in the past: [13994.811528] (&fw->lock){+.+.}-{2:2} [13994.811544] and interrupts could create inverse lock ordering between them. [13994.811606] other info that might help us debug this: [13994.811636] Possible interrupt unsafe locking scenario: [13994.811667] CPU0 CPU1 [13994.811691] ---- ---- [13994.811715] lock(&fw->lock); [13994.811744] local_irq_disable(); [13994.811773] lock(&cpuctx_lock); [13994.811810] lock(&fw->lock); [13994.811846] <Interrupt> [13994.811865] lock(&cpuctx_lock); [13994.811895] *** DEADLOCK *** v2: Use spin_lock in atomic context and spin_lock_irq in a non atomic context (Matthew Brost) v3: just use spin_lock_irqsave/restore Cc: Matthew Brost <matthew.brost@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Check skip_guc_pc before disabling gucrcVinay Belgaumkar
Also, use the new C6 helper instead of duplicating that code. v2: Check skip flag at the beginning of the function (Rodrigo) Fixes: 975e4a3795d4 ("drm/xe: Manually setup C6 when skip_guc_pc is set") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use NULL PTEs as scratch PTEsThomas Hellström
Currently scratch PTEs are write-enabled and points to a single scratch page. This has the side effect that buggy applications with out-of-bounds memory accesses may not notice the bad access since what's written may be read back. Instead use NULL PTEs as scratch PTEs. These always return 0 when reading, and writing has no effect. As a slight benefit, we can also use huge NULL PTEs. One drawback pointed out is that debugging may be hampered since previously when inspecting the content of the scratch page, it might be possible to detect writes to out-of-bound addresses and possibly also from where the out-of-bounds address originated. However since the scratch page-table structure is kept, it will be easy to add back the single RW-enabled scratch page under a debug define if needed. Also update the kerneldoc accordingly and move the function to create the scratch page-tables from xe_pt.c to xe_pt.h since it is accessing vm structure internals and this also makes it possible to make it static. v2: - Don't try to encode scratch PTEs larger than 1GiB. - Move xe_pt_create_scratch(), Update kerneldoc. v3: - Rebase. Cc: Brian Welty <brian.welty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> #for general direction. Reviewed-by: Brian Welty <brian.welty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209151843.7903-3-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Restrict huge PTEs to 1GiBThomas Hellström
Add a define for the highest level for which we can encode a huge PTE, and use it for page-table building. Also update an assert that checks that we don't try to encode for larger sizes. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209151843.7903-2-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add frequency throttle reasons sysfs attributesSujaritha Sundaresan
Add throttle reasons sysfs attributes under a separate directory. /device/tile<n>/gt<n>/freq0/throttle |- reason_pl1 |- reason_pl2 |- reason_pl4 |- reason_prochot |- reason_ratl |- reason_vr_tdc |- reason_vr_thermalert |- status v2: Remove unnecessary headers and clean-up action (Riana) Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Create a xe_gt_freq component for raw management and sysfsRodrigo Vivi
Goals of this new xe_gt_freq component: 1. Detach sysfs controls and raw freq management from GuC SLPC. 2. Create a directory that could later be aligned with devfreq. 3. Encapsulate all the freq control in a single directory. Although we only have one freq domain per GT, already start with a numbered freq0 directory so it could be expanded in the future if multiple domains or PLL are needed. Note: Although in the goal #1, the raw freq management control is mentioned, this patch only starts by the sysfs control. The RP freq configuration and init freq selection are still under the guc_pc, but should be moved to this component in a follow-up patch. v2: - Add /tile# to the doc and remove unnecessary kobject_put (Riana) - s/ssize_t/int on some ret variables (Vinay) Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Change the name of frequency sysfs attributesSujaritha Sundaresan
Switching the names of frequency sysfs attrbutes to align with required devfreq changes. The name changes are as below; -freq_act -> act_freq -freq_cur -> cur_freq -freq_rpn -> rpn_freq -freq_rpe -> rpe_freq -freq_rp0 -> rp0_freq -freq_min -> min_freq -freq_max -> max_freq Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/vm: Avoid asid lookup if none allocatedMika Kuoppala
The destroy path can and will get called for incomplete vm objects on error paths, where the asid is not yet allocated. This leads to lookup fail and assert triggered. Fix this by not asserting of asid existence if vm never got assigned one. Cc: Ohad Sharabi <osharabi@habana.ai> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Rename info.supports_* to info.has_*Lucas De Marchi
Rename supports_mmio_ext and supports_usm to use a has_ prefix so the flags are grouped together. This settles on just one variant for positive info matching ("has_") and one for negative ("skip_"). Also make sure the has_* flags are grouped together in xe_pci.c. Reviewed-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20231205145235.2114761-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Add test for LMTT operationsMichal Wajdeczko
The LMTT variants are abstracted with xe_lmtt_ops. Make sure that both 2L and ML ops implementations are correct. Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-6-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Enable CONFIG_PCI_IOV in .kunitconfigMichal Wajdeczko
We will add kunit tests for the PF specific code that is by default enabled only under CONFIG_PCI_IOV. Update our .kunitconfig to allow running those test cases by our CI. Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-5-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/pf: Introduce Local Memory Translation TableMichal Wajdeczko
The Local Memory Translation Table (LMTT) provides additional abstraction for Virtual Functions (VF) accessing device VRAM. This code is based on prior work of Michal Winiarski. In this patch we focus only on LMTT initialization. Remaining LMTT functions will be used once we add a VF provisioning to the PF. Bspec: 44117, 52404, 59314 Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-4-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Introduce SR-IOV logging macrosMichal Wajdeczko
To simplify logging and help identify SR-IOV specific messages define set of helper macros that will prefix messages based on the current SR-IOV mode. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-3-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Define DRM_XE_DEBUG_SRIOV configMichal Wajdeczko
We will be using extra logs during enabling of the SR-IOV features or when adding support for new platforms. Define separate config flag to keep that low level logs disabled if we're not debugging. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-2-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Avoid any races around ccs_mode updateNiranjana Vishwanathapura
Ensure that there are no drm clients when changing CCS mode. Allow exec_queue creation only with enabled CCS engines. v2: Rebase Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Allow userspace to configure CCS modeNiranjana Vishwanathapura
Allow user to configure the CCS mode setting through a 'ccs_mode' sysfs interface. Also report the current CCS mode configuration and number of compute slices available through this interface. v2: Rebase, make it platform agnostic v3: Separte out num_cslices sysfs interface and make xe_gt_ccs_mode_sysfs_init() return void Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Enable Fixed CCS mode settingNiranjana Vishwanathapura
Disable dynamic HW load balancing of compute resource assignment to engines and instead enabled fixed mode of mapping compute resources to engines on all platforms with more than one compute engine. By default enable only one CCS engine with all compute slices assigned to it. This is the desired configuration for common workloads. PVC platform supports only the fixed CCS mode (workaround 16016805146). v2: Rebase, make it platform agnostic v3: Minor code refactoring Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/xe2: Add workaround 18032095049 and 16021639441Tejas Upadhyay
This workaround applies to graphics 20.04 on all engines. Workaround has three parts : 1. Pipe flush before MI_ATOMIC - This part isn't relevant to Xe (at least not right now) since we don't use MI_ATOMIC anywhere in the kernel mode driver. 2. Memory-based interrupt masking - Memory-based interrupt processing isn't supported on physical functions, only virtual functions, according to bspec 60352. So this is probably only relevant once SRIOV support lands in the driver. 3. Disabling CSB/timestamp updates to the ghwsp and pphwsp - Workaround is added by this change. The CSB reports to gHWSP and ppHWSP have been discussed as part of a different topic on some internal threads and we've confirmed that neither the KMD nor the GuC firmware use those for anything, so disabling them is always "safe" and should have no functional or performance impact on system operation. The same is true for the timestamp updates in the ppHWSP as well. Given that, it might make sense to just combine these two workarounds into a single record (and single patch) and apply it on all steppings. Disabling the reports for RCS on higher steppings doesn't have any kind of negative impact and will simplify the overall situation. V3(MattR): - Combine WA apply same WA for all engines, no performance impact V2(MattR): - Mention detail in commit message - Reorder bit define - Improve bit naming - Remove workaround part which isnt relevant Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/xe2: Add workaround 14019988906Tejas Upadhyay
This workaround applies to Graphics 20.04 as engine workaround V2(MattR): - Reorder bit define - Apply WA for RCS only Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/huc: HuC authentication via GSCDaniele Ceraolo Spurio
HuC authentication via GSC is performed by submitting the appropriate PXP packet to the GSC FW. This packet can trigger a "pending" reply from the FW, so we need to handle that and resubmit. Note that the auth via GSC can only be performed if the HuC has already been authenticated by the GuC. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/huc: Prepare for 2-step HuC authenticationDaniele Ceraolo Spurio
Starting on MTL, the HuC is authenticated twice, once via GuC (same as with older integrated platforms) and once via GSC; the first authentication allows the HuC to be used for clear-media workloads, while the second one unlocks support for protected content. Ahead of adding the authentication flow via GSC, this patch adds support for differentiating the 2 auth steps and checking if they're complete. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Test WAs for MTL and LNLLucas De Marchi
Now that the kunit infra has proper support for GMD_ID platforms, add a few variants of MTL and LNL. v2: Remove bogus check for setting both media and graphics version in test (Matt Roper) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231129232807.1499826-6-lucas.demarchi@intel.com Link: https://lore.kernel.org/r/20231205133954.2089546-4-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Add stub to read_gmdidLucas De Marchi
Currently it's not possible to test the WAs for platforms using gmdid since they don't have the IP information on the descriptor struct. In order to allow that, add a stub function for read_gmdid() that is activated when the test executes, replacing the iomap and read of the real register. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231129232807.1499826-5-lucas.demarchi@intel.com Link: https://lore.kernel.org/r/20231205133954.2089546-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Move fake pci data to test-privLucas De Marchi
Instead of passing as parameter to xe_pci_fake_device_init(), use test->priv to pass parameters down the call stack. The main advantage is that then the data is readily available on other functions by using kunit_get_current_test(). This is a preparation to fix the initialization of fake devices when they were supposed to be using GMD_ID. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231129232807.1499826-4-lucas.demarchi@intel.com Link: https://lore.kernel.org/r/20231205133954.2089546-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/kunit: Remove handling of XE_TEST_SUBPLATFORM_ANYLucas De Marchi
The only user passing XE_TEST_SUBPLATFORM_ANY is xe_pci_fake_device_init_any(), but then the function would return earlier when handling XE_TEST_PLATFORM_ANY. Platforms without a subplatform use XE_SUBPLATFORM_NONE. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231129232807.1499826-3-lucas.demarchi@intel.com Link: https://lore.kernel.org/r/20231129232807.1499826-6-lucas.demarchi@intel.com Link: https://lore.kernel.org/r/20231205133954.2089546-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Expand XE_REG_OPTION_MASKED documentationLucas De Marchi
Expand documentation and add an example to make clear this isn't about generic masks in registers. Also, fix the doc regarding read operations: the mask part has no effect on them. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231205155820.2133813-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Kill exec_queue_set_propertyRodrigo Vivi
All the properties should be immutable and set upon exec_queue creation using the existent extension. So, let's kill this useless and dangerous uapi. Cc: Francois Dugast <francois.dugast@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2023-12-21drm/xe: Remove unused extension definitionRodrigo Vivi
The vm_create ioctl function doesn't accept any extension. Remove this left over. A backward compatible change. Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Use LR abbrev for long-running vmsThomas Hellström
Currently we're using "compute mode" for long running VMs using preempt-fences for memory management, and "fault mode" for long running VMs using page faults. Change this to use the terminology "long-running" abbreviated as LR for long-running VMs. These VMs can then either be in preempt-fence mode or fault mode. The user can force fault mode at creation time, but otherwise the driver can choose to use fault- or preempt-fence mode for long-running vms depending on the device capabilities. Initially unless fault-mode is specified, the driver uses preempt-fence mode. v2: - Fix commit message wording and the documentation around CREATE_FLAG_LR_MODE and CREATE_FLAG_FAULT_MODE Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Move xe_exec after xe_exec_queueRodrigo Vivi
Although the exec ioctl is a very important one, it makes no sense to explain xe_exec before explaining the exec_queue. So, let's move this down to help bring a better flow on the documentation and code readability. It is important to highlight that this patch is changing all the ioctl numbers in a non-backward compatible way. However, we are doing this final uapi clean-up before we submit our first pull-request to be part of the upstream Kernel. Once we get there, no other change like this will ever happen and all the backward compatibility will be respected. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Fix various struct padding for 64b alignmentRodrigo Vivi
Let's respect Documentation/process/botching-up-ioctls.rst and add the proper padding for a 64b alignment with all as well as all the required checks and settings for the pads and the reserved entries. v2: Fix remaining holes and double check with pahole (Jose) Ensure with pahole that both 32b and 64b have exact same layout (Thomas) Do not set query's pad and reserved bits to zero since it is redundant and already done by kzalloc (Matt) v3: Fix alignment after rebase (José Roberto de Souza) v4: Fix pad check (Francois Dugast) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Add Tile ID information to the GT info queryRodrigo Vivi
As an information only. So Userspace can use this information and be able to correlate different GTs. Make API symmetric between Engine and GT info. There's no need right now to include a tile_query entry since there's no other information that we need from tile that is not already exposed through different queries. However, this could be added later if we have different Tile information that could matter to userspace. But let's keep the API ready for a direct reference to Tile ID based on the GT entry. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Crystal Reference Clock updatesRodrigo Vivi
First of all, let's remove the duplication. But also, let's rename it to remove the word 'frequency' out of it. In general, the first thing people think of frequency is the frequency in which the GTs are operating to execute the GPU instructions. While this frequency here is a crystal reference clock frequency which is the base of everything else, and in this case of this uAPI it is used to calculate a better and precise timestamp. v2: (Suggested by Jose) Remove the engine_cs and keep the GT info one since it might be useful for other SRIOV cases where the engine_cs will be zeroed. So, grabbing from the GT_LIST should be cleaner. v3: Keep comment on put_user() call (José Roberto de Souza) Cc: Matt Roper <matthew.d.roper@intel.com> Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Jose Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Kill tile_maskRodrigo Vivi
It is currently unused, so by the rules it cannot go upstream. Also there was the desire to convert that to align with the engine_class_instance selection, but the consensus on that one is to remain with the global gt_id. So we are keeping the gt_id there, not converting to a generic sched_group and also killing this tile_mask and only using the default behavior of 0 that is to create a mapping / page_table entry on every tile, similar to what i915. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Split xe_sync types from flagsRodrigo Vivi
Let's continue on the uapi clean-up with more splits with stuff into their own exclusive fields instead of reusing stuff. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (engines)Francois Dugast
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for engines by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } Instead of directly returning an array of struct drm_xe_query_engine_info, a new struct drm_xe_query_engines is introduced. It contains itself an array of struct drm_xe_engine which holds the information about each engine. v2: Use plural for struct drm_xe_query_engines as multiple engines are returned (José Roberto de Souza) Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (gt)Francois Dugast
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. However, aligning on the new common pattern: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } ... would mean bringing back the name "gts" which is avoided per commit fca54ba12470 ("drm/xe/uapi: Rename gts to gt_list") so make an exception for gt and leave gt_list. Also, this change removes "query" in the name of struct drm_xe_query_gt as it is not returned from the query IOCTL. There is no functional change. v2: Leave gt_list (Matt Roper) Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (memory regions)Francois Dugast
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for memory regions by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } This removes "query" in the name of struct drm_xe_query_mem_region as it is not returned from the query IOCTL. There is no functional change. v2: Only rename drm_xe_query_mem_region to drm_xe_mem_region (José Roberto de Souza) v3: Rename usage to mem_regions in xe_query.c (José Roberto de Souza) Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Reject bo creation of unaligned sizeMauro Carvalho Chehab
For xe bo creation we request passing size which matches system or vram minimum page alignment. This way we want to ensure userspace is aware of region constraints and not aligned allocations will be rejected returning EINVAL. v2: - Rebase, Update uAPI documentation. (Thomas) v3: - Adjust the dma-buf kunit test accordingly. (Thomas) v4: - Fixed rebase conflicts and updated commit message. (Francois) Signed-off-by: Mauro Carvalho Chehab <mauro.chehab@linux.intel.com> Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proofJosé Roberto de Souza
We have at least 2 future features(OA and future media engines capabilities) that will require Xe to provide more information about engines to UMDs. But this information should not just be added to drm_xe_engine_class_instance for a couple of reasons: - drm_xe_engine_class_instance is used as input to other structs/uAPIs and those uAPIs don't care about any of these future new engine fields - those new fields are useless information after initialization for some UMDs, so it should not need to carry that around So here my proposal is to make DRM_XE_DEVICE_QUERY_ENGINES return an array of drm_xe_query_engine_info that contain drm_xe_engine_class_instance and 3 u64s to be used for future features. Reference OA: https://patchwork.freedesktop.org/patch/558362/?series=121084&rev=6 v2: Reduce reserved[] to 3 u64 (Matthew Brost) Cc: Francois Dugast <francois.dugast@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo Rebased] Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe/uapi: Separate bo_create placement from flagsRodrigo Vivi
Although the flags are about the creation, the memory placement of the BO deserves a proper dedicated field in the uapi. Besides getting more clear, it also allows to remove the 'magic' shifts from the flags that was a concern during the uapi reviews. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2023-12-21drm/xe: Extend drm_xe_vm_bind_opMika Kuoppala
The bind api is extensible but for a single bind op, there is not a mechanism to extend. Add extensions field to struct drm_xe_vm_bind_op. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: add some debug info for d3coldMatthew Auld
From the CI logs we want to easily know if the machine is capable and allowed to enter d3cold, and can therefore potentially trigger the d3cold RPM suspend and resume path. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig"Michał Winiarski
Move params that are not used for initial "hwconfig" load to "post-hwconfig" phase. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Extract xe_uc_sanitize_resetMichał Winiarski
Earlier GuC load will require more fine-grained control over reset. Extract it outside of xe_uc_init_hw. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Store firmware binary in system-memory backed BOMichał Winiarski
The firmware loading for GuC is about to be moved, and will happen much earlier in the probe process, when local-memory is not yet available. While this has the potential to make the firmware loading process slower, this is only happening during probe and full device reset. Since both are not hot-paths - store all UC-like firmware in system memory. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Split xe_uc_fw_initMichał Winiarski
The function does a driver specific "request firmware" step that includes validating the input, followed by wrapping the firmware binary into a buffer object. Split it into smaller parts. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 21:28:25 +0000