- 02 Apr, 2024 2 commits
-
-
Lucas De Marchi authored
The flags stored in the BO grew over time without following much a naming pattern. First of all, get rid of the _BIT suffix that was banned from everywhere else due to the guideline in drivers/gpu/drm/i915/i915_reg.h that xe kind of follows: Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the name. Here the flags aren't for a register, but it's good practice to keep it consistent. Second divergence on names is the use or not of "CREATE". This is because most of the flags are passed to xe_bo_create*() family of functions, changing its behavior. However, since the flags are also stored in the bo itself and checked elsewhere in the code, it seems better to just omit the CREATE part. With those 2 guidelines, all the flags are given the form XE_BO_FLAG_<FLAG_NAME> with the following commands: git grep -le "XE_BO_" -- drivers/gpu/drm/xe | xargs sed -i \ -e "s/XE_BO_\([_A-Z0-9]*\)_BIT/XE_BO_\1/g" \ -e 's/XE_BO_CREATE_/XE_BO_FLAG_/g' git grep -le "XE_BO_" -- drivers/gpu/drm/xe | xargs sed -i -r \ -e 's/XE_BO_(DEFER_BACKING|SCANOUT|FIXED_PLACEMENT|PAGETABLE|NEEDS_CPU_ACCESS|NEEDS_UC|INTERNAL_TEST|INTERNAL_64K|GGTT_INVALIDATE)/XE_BO_FLAG_\1/g' And then the defines in drivers/gpu/drm/xe/xe_bo.h are adjusted to follow the coding style. Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322142702.186529-3-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Lucas De Marchi authored
It's quite redundant to pass XE_BO_CREATE_USER_BIT to xe_bo_create_user() since the only difference of that function is to force that flag. Stop passing the flag in the few cases that were explicitly doing so. Reviewed-by:
-
- 29 Mar, 2024 5 commits
-
-
Himal Prasad Ghimiray authored
Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328123739.3633428-1-himal.prasad.ghimiray@intel.comSigned-off-by:
-
Karthik Poosa authored
Add infra to support card power and energy attributes through channel 0. Package attributes will be now exposed through channel 1 rather than channel 0 as shown below. Channel 0 i.e power1/energy1_xxx used for card and channel 1 i.e power2/energy2_xxx used for package power,energy attributes. power1/curr1_crit and in0_input are moved to channel 1, i.e. power2/curr2_crit and in1_input as these are available for package only. This would be needed for future platforms where they might be separate registers for package and card power and energy. Each discrete GPU supported by Xe driver, would have a directory in /sys/class/hwmon/ with multiple channels under it. Each channel would have attributes for power, energy etc. Ex: /sys/class/hwmon/hwmon2/power1_max /power1_label /energy1_input /energy1_label Attributes will have a label to get more description of it. Labelling is as below. power1_label/energy1_label - "card", power2_label/energy2_label - "pkg". v2: Fix checkpatch errors. v3: - Update intel-xe-hwmon documentation. (Riana, Badal) - Rename hwmon card channel enum from CHANNEL_PLATFORM to CHANNEL_CARD. (Riana) v4: - Remove unrelated changes from patch. (Anshuman) - Fix typo in commit msg. v5: - Update commit message and intel-xe-hwmon documentation with "Xe" instead of xe when using it as a name. (Rodrigo) Signed-off-by:Karthik Poosa <karthik.poosa@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328175435.3870957-1-karthik.poosa@intel.comSigned-off-by:
-
Michal Wajdeczko authored
We are abusing struct drm_info_list.data by storing there pointer to the xe_gt, while it shouldn't be used for any device specific data. Use recently introduced xe_gt_debugfs_simple_show() that hides all details how to obtain the xe_gt pointer. This will also remove the need for making copies of the struct drm_info_list to get GT specific definitions. Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328162808.451-4-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Many of our debugfs files are GT specific and require a pointer to struct xe_gt to correctly show its content. Our initial approach to use drm_info_list.data field to pass pointer not only requires extra steps (like copying template per each GT) but also abuses the rule that this data field should not be device specific. Introduce helper function that will use xe_gt pointer stored at parent directory level and use .data only to pass actual print function that would expects xe_gt pointer as a parameter. Reviewed-by:
-
Michal Wajdeczko authored
Attributes added under 'gt/' directories may wish to use that in case they can't obtain it from elsewhere. Reviewed-by:
-
- 28 Mar, 2024 11 commits
-
-
Francois Dugast authored
The topology type is an index (not a mask) so define the values like other indexes instead of using powers of 2. This is also to make clear that the next type can use value 3. This commit does not change the existing values so it does not break compatibility. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/intel-xe/20240327232317.GI718896@mdroper-desk1.amr.corp.intel.com/Reviewed-by:
-
Daniele Ceraolo Spurio authored
The WA states that we need to keep the primary GT powered up during GSC load to allow the GSC FW to access its registers. We also need to make sure that one of the registers is locked before starting the load. v2: fix location of register def (Matt) Bspec: 55928 Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
GuC will use VF_STATE_NOTIFY events to notify the PF about changes of the VF state, in particular when a VF FLR was requested. Add very minimal support for such events to avoid reporting errors due to unexpected G2H. We will improve handling of these messages later. While around also add few basic functions to control the VF state (pause, resume, stop) as we will also exercise them soon. Signed-off-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240326191518.363-3-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to handle the GUC2PF_VF_STATE_NOTIFY events and to send PF2GUC_VF_CONTROL request messages. Add necessary definitions to our GuC firmware ABI header. Signed-off-by:
-
Michal Wajdeczko authored
SR-IOV VF mode detection is based on testing VF capability bit on the register that is accessible from both the PF and enabled VFs. Bspec: 49904, 53227 Signed-off-by:
-
Michal Wajdeczko authored
SR-IOV mode detection requires access to the MMIO register and this can be done now in xe_device_probe_early(). We can also drop explicit has_sriov parameter as this flag is now already available from xe->info. Signed-off-by:
-
Michal Wajdeczko authored
We can setup root tile registers mapping at the same time as we do early mapping of the entire MMIO BAR and keep mandatory VRAM checkout as a separate step. This will allow us to perform SR-IOV VF mode detection between those two steps using regular MMIO regs access functions. Signed-off-by:
-
Thomas Hellström authored
Rebinding might allocate page-table bos, causing evictions. To support blocking locking during these evictions, perform the rebinding in the drm_exec locking loop. Also Reserve fence slots where actually needed rather than trying to predict how many fence slots will be needed over a complete wound-wait transaction. v2: - Remove a leftover call to xe_vm_rebind() (Matt Brost) - Add a helper function xe_vm_validate_rebind() (Matt Brost) v3: - Add comments and squash with previous patch (Matt Brost) Fixes: 24f947d5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted objects") Fixes: 29f424eb ("drm/xe/exec: move fence reservation") Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327091136.3271-5-thomas.hellstrom@linux.intel.com
-
Thomas Hellström authored
They can actually complete out-of-order, so allocate a unique fence context for each fence. Fixes: 5387e865 ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
Thomas Hellström authored
Instead of handling the vm's rebind fence separately, which is error prone if they are not strictly ordered, attach rebind fences as kernel fences to the vm's resv. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
Thomas Hellström authored
For each rebind we insert a GuC TLB invalidation and add a corresponding unordered TLB invalidation fence. This might add a huge number of TLB invalidation fences to wait for so rather than doing that, defer the TLB invalidation to the next ring ops for each affected exec queue. Since the TLB is invalidated on exec_queue switch, we need to invalidate once for each affected exec_queue. v2: - Simplify if-statements around the tlb_flush_seqno. (Matthew Brost) - Add some comments and asserts. Fixes: 5387e865 ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
- 27 Mar, 2024 6 commits
-
-
Michal Wajdeczko authored
We are ready to replace private guc_ids management code with separate GuC ID Manager that can be shared with upcoming SR-IOV PF provisioning code. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Before we switch-over submission code to use new GuC context ID Manager, lets add some kunit tests to make sure that ID manager works as expected. Signed-off-by:
-
Michal Wajdeczko authored
While we are already managing GuC IDs directly in GuC submission code, using bitmap() for MLRC and ida() for SLRC, this code can't be easily extended to meet additional requirements for SR-IOV use cases, like limited number of IDs available on VFs, or ID range reservation for provisioning VFs by the PF. Add a separate component for managing GuC IDs, that will replace existing ID management. Start with bitmap() based implementation that could be optimized later based on perf data. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
This macro represents GuC firmware capability and shall be defined in the firmware ABI header. Move it to xe_guc_fwif.h file. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Use include guard macro name that follows naming used by the other GuC ABI files. Signed-off-by:
-
Michal Wajdeczko authored
It's better to keep all hardware GGTT definitions separated from the driver code. It also helps to avoid duplicated definitions. Signed-off-by:
-
- 26 Mar, 2024 4 commits
-
-
Nirmoy Das authored
Refactor xe_sync_entry_signal so it doesn't have to modify xe_sched_job struct instead create a new helper function to set user fence values for a job. v2: Move the sync type check to xe_sched_job_init_user_fence(Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
Vinay Belgaumkar authored
SLPC shutdown is called in reset and suspend paths. In the reset path, it is possible that the H2G call gets lost as GuC is in the process of being reset. There is no value in stopping SLPC when it will happen anyways. In the suspend path, we disable communication with GuC, so there is no need to explicitly shutdown SLPC. v2: Rebase Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
-
Ravi Kumar Vodapalli authored
New PCI IDs are added in Bspec for DG2 platform, add them in driver Bspec: 44477 Signed-off-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Reviewed-by:
-
Niranjana Vishwanathapura authored
Use FIELD_PREP for setting lrc descriptor fields instead of shifting values to fields. v2: Use ULL macro variants v3: Do not use FIELD_PREP for 1-bit values Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
-
- 22 Mar, 2024 9 commits
-
-
Lucas De Marchi authored
xe_device.h implements these helpers, just use them. Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240321213818.72311-1-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
mips declares an END macro in its headers so it can't be used without namespace in a driver like xe. Instead of coming up with a longer name, just remove the macro and replace its use with 0 since it's still clear what that means: set_offsets() was already using that implicitly when checking the data variable. Reported-by:
Guenter Roeck <linux@roeck-us.net> Closes: http://kisskb.ellerman.id.au/kisskb/buildresult/15143996/Tested-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322145037.196548-1-lucas.demarchi@intel.comSigned-off-by:
-
Daniele Ceraolo Spurio authored
The initialization via drmm_mutex_init can fail, so we need to check the return code and escalate the failure. The mutex initialization has been moved after all the other init steps that can't fail, so we're always guaranteed to have those done and don't have to check in the cleanup code. Signed-off-by:
-
Vinay Belgaumkar authored
Return failures from pc_adjust_freq_bounds. Signed-off-by:
-
José Roberto de Souza authored
This is a left over of commit f1a9abc0 ("drm/xe/uapi: Remove support for persistent exec_queues"). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
My testing machine has only 8GB of RAM and while running piglit tests I can reach the OOM cache in xe_vm_snapshot_capture() snap allocaiton sometimes. So to differentiate the OOM from race between capture and UMDs unbinbind VMs here I'm adding a '[0].error: -12' to devcoredump. v2: - fix returned errno values Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
This makes VM error consistent with [x].length and [x].data. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
modeset_restore_state has been unused since commit 6af0ffc0 ("drm/i915/display: move restore state and ctx under display sub-struct"). member global_obj_list has been unused since commit e2925e19 ("drm/i915/display: move global_obj_list under display sub-struct"). hti_state has been unused since commit 62749912 ("drm/i915/display: move hti under display sub-struct"). snps_phy_failed_calibration has been unused since commit 3a7e2d58 ("drm/i915: move snps_phy_failed_calibration to display sub-struct under snps"). Reviewed-by:
-
Matthew Auld authored
The user provided gt_id should always be less than the XE_MAX_GT_PER_TILE. Fixes: 7793d00d ("drm/xe: Correlate engine and cpu timestamps with better accuracy") Signed-off-by:
-
- 21 Mar, 2024 3 commits
-
-
Matthew Brost authored
Extra debug is useful when working on VM issues. Signed-off-by:
-
Himal Prasad Ghimiray authored
Use USEC_PER_MSEC rather than the hard coded value of 1000. Static analyzer Reported "casting either timeout_ms or 1000U to type u64" to avoid overflow-before-widen. Using USEC_PER_MSEC seems better and will help with static analyzer report cleanup. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Auld authored
The q->width should always be exactly one here for migration queue/vm. The width will anyway be overridden later since we need to emit two jumps for special migration jobs. Enforce that here to ensure caller is not doing something strange. While here also convert to the helper to determine if the queue is migration based. Signed-off-by:
-
