Michal Wajdeczko [Fri, 19 Apr 2024 15:03:51 +0000 (17:03 +0200)]
drm/xe/guc: Fix arguments passed to relay G2H handlers
By default CT code was passing just payload of the G2H event
message, while Relay code expects full G2H message including
HXG header which contains DATA0 field. Fix that.
Let's simply convert all the current callers towards direct
xe_pm_runtime access and remove this extra layer of indirection.
No functional change is expected with this patch since
xe_mem_access_get was already using the xe_pm_runtime_get_noresume
at this point.
v2: Convert all the current callers instead of a big refactor
at once.
v3: - Rebased
- Squashed the GSC/HDCP
- Added a new case: sriov_pf_policy
- Improved commit message to highlight that
there's no functional change in this patch.
Matt Roper [Wed, 17 Apr 2024 15:26:22 +0000 (08:26 -0700)]
drm/xe: Define all possible engines in media IP descriptors
Rather than trying to identify exactly which engines are available on
each platform in the IP descriptor, just include the list of all media
engines that the IP could theoretically support (i.e., 8 VCS + 4 VECS).
We still rely on the media fuse registers to tell us which specific
engine instances are actually present on a given platform, so there
shouldn't be any functional change. This will help prevent mistakes
with engine numbering (for example ambiguity about whether the 2nd VCS
engine on a platform with exactly two engines is numbered "VCS1" or
"VCS2") and will also future-proof the code a bit more in case new SKUs
or platform refreshes extend the engine list in the future.
Note that the media fuse register technically has an 8-bit field for
VECS engine presence starting on Xe2. However there's still no MMIO
register range reserved for VE engines above VECS3, so VE0-VE3 is still
consider the "maximum" VE engine mask that the driver can support for
now.
drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref
In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer the case
and this function was totally unused until it started to be used again
by display with commit 77e619a82fc3 ("drm/i915/display: convert inner
wakeref get towards get_if_in_use")
However, on the display code, most of the callers are using the
raw wakeref, rather then the wakelock version. What caused a
major regression caught by CI.
Another option to this patch is to go with the original plan and
use the get_if_in_use variant in the display code, what is enough
to fulfil our needs. Then, an extra patch to delete the unused
_noresume variant.
v2: Keep grabbing wakelock but only assert for wakeref. (Imre)
Cc: Imre Deak <imre.deak@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 77e619a82fc3 ("drm/i915/display: convert inner wakeref get towards get_if_in_use") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10875 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240418223756.68427-1-rodrigo.vivi@intel.com
Ashutosh Dixit [Wed, 17 Apr 2024 14:56:46 +0000 (07:56 -0700)]
drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
xe_pm_init may encounter failures for various reasons, such as a failure
in initializing drmm_mutex, or when dealing with a d3cold-capable device
for vram_threshold sysfs creation and setting default threshold.
Presently, all these potential failures are disregarded.
Move d3cold.lock initialization to xe_pm_init_early and cause driver
abort if mutex initialization has failed.
For xe_pm_init failures cleanup the driver and return error code
drm/xe/tile: Abort driver load for sysfs creation failure
Ensure that the status of all tile associated sysfs entries creation is
relayed to xe_tile_init_noalloc, leading to a driver load abort if any
sysfs creation failures occur.
drm/xe/gt: Abort driver load for sysfs creation failure
Instead of allowing the driver to load with incomplete sysfs entries in
case of sysfs creation failure, we should terminate the driver loading.
This change ensures that the status of all gt associated sysfs entries
creation is relayed to xe_gt_init, leading to a driver load abort if any
sysfs creation failures occur.
-v2
use err_force_wake label instead of new. (Lucas)
Avoid unnecessary warn/error messages. (Lucas)
drm/xe: call free_gsc_pkt only once on action add failure
The drmm_add_action_or_reset function automatically invokes the
action (free_gsc_pkt) in the event of a failure; therefore, there's no
necessity to call it within the return check.
-v2
Fix commit message. (Lucas)
Fixes: d8b1571312b7 ("drm/xe/huc: HuC authentication via GSC") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412181211.1155732-4-himal.prasad.ghimiray@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
drm/xe: Remove sysfs only once on action add failure
The drmm_add_action_or_reset function automatically invokes the action
(sysfs removal) in the event of a failure; therefore, there's no
necessity to call it within the return check.
Modify the return type of xe_gt_ccs_mode_sysfs_init to int, allowing the
caller to pass errors up the call chain. Should sysfs creation or
drmm_add_action_or_reset fail, error propagation will prompt a driver
load abort.
-v2
Edit commit message (Nikula/Lucas)
use err_force_wake label instead of new. (Lucas)
Avoid unnecessary warn/error messages. (Lucas)
Fixes: f3bc5bb4d53d ("drm/xe: Allow userspace to configure CCS mode") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412181211.1155732-3-himal.prasad.ghimiray@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
drm/xe: Simplify function return using drmm_add_action_or_reset()
Instead of assigning the value of drmm_add_action_or_reset() to err and
returning err in case of failure and 0 in case of success, simply return
the result of drmm_add_action_or_reset().
drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf
Any kunit doing any memory access should get their own runtime_pm
outer references since they don't use the standard driver API
entries. In special this dma_buf from the same driver.
Found by pre-merge CI on adding WARN calls for unprotected
inner callers:
drm/xe: Ensure all the inner access are using the _noresume variant
At this point mem_access references should be only used as inner
points of the execution and a get with synchronous resume previously
called at an outer point.
So, before killing mem_acces in favor of direct accsess, let's
ensure that we first convert them towards the new _noresume
variant that will WARN us if no inner caller happened.
drm/xe: Convert mem_access_if_ongoing to direct xe_pm_runtime_get_if_active
Now that assert_mem_access is relying directly on the pm_runtime state
instead of the counters, there's no reason why we cannot use
the pm_runtime functions directly.
drm/xe: Convert xe_gem_fault to use direct xe_pm_runtime calls
The gem page fault is one of the outer bound protections where
we want to ensure that the hardware is in D0 before proceeding
with memory access. Let's convert it towards the xe_pm_runtime
functions directly so we can then convert the mem_access to be
inner protection only and then Kill it for good.
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.
drm/xe: Move lockdep protection from mem_access to xe_pm_runtime
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.
drm/i915/display: convert inner wakeref get towards get_if_in_use
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)
drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers
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.
Matthew Auld [Fri, 12 Apr 2024 11:31:46 +0000 (12:31 +0100)]
drm/xe/vm: drop vm->destroy_work
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.
Matthew Auld [Fri, 12 Apr 2024 11:31:45 +0000 (12:31 +0100)]
drm/xe/vm: prevent UAF with asid based lookup
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
Matthew Auld [Fri, 12 Apr 2024 15:03:02 +0000 (16:03 +0100)]
drm/xe/stolen: lower the default alignment
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.
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:37 +0000 (19:39 +0200)]
drm/xe/pf: Add support to configure SR-IOV VFs
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.
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:36 +0000 (19:39 +0200)]
drm/xe/pf: Add SR-IOV PF specific early GT initialization
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.
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:35 +0000 (19:39 +0200)]
drm/xe/guc: Add PF2GUC_UPDATE_VF_CFG to ABI
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
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:34 +0000 (19:39 +0200)]
drm/xe: Add xe_ttm_vram_get_avail
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.
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:33 +0000 (19:39 +0200)]
drm/xe: Allow to assign GGTT region to the VF
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.
Michal Wajdeczko [Mon, 15 Apr 2024 17:39:32 +0000 (19:39 +0200)]
drm/xe: Add helper to format SR-IOV function name
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.
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)
Michal Wajdeczko [Wed, 10 Apr 2024 17:03:38 +0000 (19:03 +0200)]
drm/xe/pf: Add support to configure GuC SR-IOV policies
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.
Michal Wajdeczko [Wed, 10 Apr 2024 17:03:37 +0000 (19:03 +0200)]
drm/xe/guc: Add helpers for GuC KLVs
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.
Michal Wajdeczko [Wed, 10 Apr 2024 17:03:36 +0000 (19:03 +0200)]
drm/xe/guc: Add PF2GUC_UPDATE_VGT_POLICY to ABI
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.
Michal Wajdeczko [Wed, 10 Apr 2024 17:03:35 +0000 (19:03 +0200)]
drm/xe/pf: Introduce helper functions for use by PF
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.
Michal Wajdeczko [Wed, 10 Apr 2024 17:03:34 +0000 (19:03 +0200)]
drm/xe/pf: Introduce mutex to protect VFs configurations
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.
Oak Zeng [Fri, 12 Apr 2024 09:52:37 +0000 (15:22 +0530)]
drm/xe: Use hmm_range_fault to populate user pages
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.
Oak Zeng [Fri, 12 Apr 2024 09:52:36 +0000 (15:22 +0530)]
drm/xe: Introduce helper to populate userptr
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
José Roberto de Souza [Tue, 9 Apr 2024 20:02:06 +0000 (13:02 -0700)]
drm/xe: Remove devcoredump during driver release
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>
José Roberto de Souza [Tue, 9 Apr 2024 20:02:05 +0000 (13:02 -0700)]
devcoredump: Add dev_coredump_put()
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.
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
drm/xe: re-order lmem init check and wait for initialization to complete
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)
drm/xe: check pcode init status only on root gt of root tile
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)
Uwe Kleine-König [Mon, 4 Mar 2024 09:05:56 +0000 (10:05 +0100)]
drm/bridge: imx8mp-hdmi-pvi: Convert to platform remove callback returning void
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.
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:28:04 +0000 (21:28 +0100)]
drm/omap: dmm_tiler: drop driver owner assignment
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().
Michal Wajdeczko [Thu, 4 Apr 2024 15:44:30 +0000 (17:44 +0200)]
drm/xe: Add proper detection of the SR-IOV PF mode
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.
Michal Wajdeczko [Thu, 4 Apr 2024 15:44:29 +0000 (17:44 +0200)]
drm/xe: Add max_vfs module parameter
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.
Michal Wajdeczko [Tue, 9 Apr 2024 10:51:06 +0000 (12:51 +0200)]
drm/xe: Check pat.ops before dumping PAT settings
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.
drm/xe/xe2hpg: Remove extra allocation of CCS pages for dgfx
On Xe2 dGPU, compression is only supported with VRAM. When copying from
VRAM -> system memory the KMD uses mapping with uncompressed PAT
so the copy in system memory is guaranteed to be uncompressed.
When restoring such buffers from system memory -> VRAM the KMD can't
easily know which pages were originally compressed, so we always use
uncompressed -> uncompressed here.
so this means that there's no need for extra CCS storage on such
platforms.
Matt Roper [Mon, 8 Apr 2024 17:05:39 +0000 (22:35 +0530)]
drm/xe/bmg: Program an additional discrete-specific PAT setting
Discrete Xe2 platforms require programming of one additional row of PAT
settings which controls the access characteristics for PPGTT and LMTT
page tables. Integrated GPUs do not need this programming and will
leave the register at its hardware default value.
Matt Roper [Mon, 8 Apr 2024 17:05:37 +0000 (22:35 +0530)]
drm/xe/bmg: Add BMG platform definition
BMG is a discrete GPU based on the Xe2 architecture.
No device ids are bound to the BMG platform descriptor yet.
BMG device ids will be added once we have all the basic required
platform enabling patches landed.
v2: Removed device ids, deferring it to a later patch
v3: Squash in compat header IS_BATTLEMAGE() patch. (Lucas)
Enable GuC Wa_14019882105 to block interrupts during C6 flow
when the memory path has been blocked
v2: Make helper function generic and name it as
guc_waklv_enable_simple (John Harrison)
v3: Make warning descriptive (John Harrison)
v4: s/drm_WARN/xe_gt_WARN/ (Michal)
To prevent running out of bits, new workaround (w/a) enable flags are
being added via a KLV system instead of a 32 bit flags word.
v2: GuC version check > 70.10 is not needed as base line xe doesnot
support anything below < 70.19
v3: Use 64 bit ggtt address for future
compatibility (John Harrison/Daniele)
v4: %s/PAGE_SIZE/SZ_4K/ (Michal)
Matthew Brost [Fri, 5 Apr 2024 21:16:31 +0000 (14:16 -0700)]
drm/xe: Always capture exec queues on snapshot
Always capture exec queues on snapshot regardless if exec queue has
pending jobs or not. Having jobs or not does indicate whether the exec
queue capture is useful.
Example bugs that would not be easily detected by skipping capture when
pending job list is empty:
- Jobs pending on exec queue have dependencies
- Leaking exec queue refs
- GuC protocol issues (i.e. losing G2H)
In addition to above bugs, in general it just useful to see every exec
queue registered with the GuC and its state.
Francois Dugast [Fri, 29 Mar 2024 12:44:03 +0000 (12:44 +0000)]
drm/xe/uapi: Restore flags VM_BIND_FLAG_READONLY and VM_BIND_FLAG_IMMEDIATE
The commit 84a1ed5e6756 ("drm/xe/uapi: Remove unused flags") is partially
reverted. At the time, flags not used by user space were removed during
cleanup. Some flags now needed by the compute runtime are brought back in
this commit:
- DRM_XE_VM_BIND_FLAG_READONLY is used to write protect kernel ISA thus
preventing accidental overwrites.
- DRM_XE_VM_BIND_FLAG_IMMEDIATE is used to trigger mapping at the time of
binding in order to prevent faulting at execution time.
The changes in the compute runtime are ready and approved, see link below.
v2: Include a link to the PR in the commit message (Matthew Brost)
v3: Update kernel doc and improve commit message (Lucas De Marchi)
Lucas De Marchi [Mon, 8 Apr 2024 15:13:12 +0000 (08:13 -0700)]
drm/xe: Remove dead clock code
xe_gt_clock_cycles_to_ns() is not called from anywhere after PMU
handling was removed in commit 90a8b23f9b85 ("drm/xe/pmu: Remove PMU
from Xe till uapi is finalized"). Drop it.
Aleksandr Mishin [Mon, 8 Apr 2024 12:58:10 +0000 (15:58 +0300)]
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
assigned to mhdp_state->current_mode, and there is a dereference of it in
drm_mode_set_name(), which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state->current_mode.
Lucas De Marchi [Fri, 5 Apr 2024 20:07:11 +0000 (13:07 -0700)]
drm/xe/display: Fix double mutex initialization
All of these mutexes are already initialized by the display side since
commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display
code"), so the xe shouldn´t initialize them.
Michal Wajdeczko [Thu, 4 Apr 2024 17:38:14 +0000 (19:38 +0200)]
drm/xe/vf: Mark supported firmwares as preloaded
On current platforms supported firmwares, like GuC and HuC, must
be loaded by the PF driver. Mark those firmwares as 'preloaded'
so we will skip fetching and loading them on the VF drivers but
still correctly report them as 'running'.
Michal Wajdeczko [Sat, 6 Apr 2024 14:39:46 +0000 (16:39 +0200)]
drm/xe/guc: Initialize GuC ID manager sooner
The GuC submission cleanup code may depend on the GuC ID manager,
thus we can't initialize it after registering a submission cleanup
action, as reverse cleanup sequence will destroy GuC ID manager
prior to a call to guc_submit_fini().
Move GuC ID manager initialization up, right after managed mutex
initialization, to have it available during guc_submit_fini().
projects / users / jedix / linux-maple.git / log