In order to avoid  -Werror=missing-prototypes, add the prototypes
in a separate tests/<test-name>_test.h file that is included by both
the implementation (tests/xe_<testname>.c, injected in xe.ko) and the
kunit module (tests/xe_<testname>_test.c -> xe-<testname>-test.ko).

v2: Add header and don't add ifdef to files that are already not built
when not using kunit (Matt Auld)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

In local_pci_probe() the core kernel increments the rpm for the device,
just before calling into the probe hook. If the driver/device supports
runtime pm it is then meant to put this ref during probe (like we do in
xe_pm_runtime_init()). However when removing the device we then also
need to take the reference back, otherwise the ref that is put in
pci_device_remove() will be unbalanced when for example unloading the
driver, leading to warnings like:

    [ 3808.596345] xe 0000:03:00.0: Runtime PM usage count underflow!

Fix this by incrementing the rpm ref when removing the device.

v2:
  - Improve the terminology in the commit message; s/drop/put/ etc (Lucas & Rodrigo)
  - Also call pm_runtime_forbid(dev) (Rodrigo)

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/193Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

i915_regs.h is not needed, particularly in a header file. What is needed
is i915_reg_defs.h for use of _MMIO() and similar macros.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Use the more common "call cc-disable-warning" way to disable warnings.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

media_verx100 supersedes the info from media_ver. Leave media_ver in the
struct xe_device_desc, used in xe_pci.c since it's easier to define
common parts of the platforms like that. However all the rest of the
driver should be using media_verx100 that is more future proof.

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/216Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Make xe_wait_user_fence.c include xe_wait_user_fence.h so it doesn't
rely on indirect includes and also doesn't fail the build due to missing
prototype for xe_wait_user_fence_ioctl().
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Fix the following warning:

	../drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c:55: warning: Function
	parameter or member 'xe' not described in
	'xe_ttm_stolen_cpu_inaccessible'
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

xe_gt_topology_dss_group_mask and xe_gt_topology_count_dss are probably
leftover from initial implementation - they are not called from
anywhere. Remove those functions.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

LRC tunings were added after the gt ones and didn't add the call
in xe_gt_record_default_lrcs() to process them like is done for
workarounds. Add such a function and call it from
xe_gt_record_default_lrcs().
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

A few static functions not being declared like that break the build with
W=1, like e.g.

	cc1: all warnings being treated as errors
	make[2]: *** [../scripts/Makefile.build:250: drivers/gpu/drm/xe/xe_gt.o] Error 1
	../drivers/gpu/drm/xe/xe_guc.c:240:6: error: no previous prototype for ‘guc_write_params’ [-Werror=missing-prototypes]
	  240 | void guc_write_params(struct xe_guc *guc)
	      |      ^~~~~~~~~~~~~~~~

Make them static.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

There are also some reserved fields in here which are not currently
cleared when handing back to userspace. Otherwise we might run into
issues if we later wish to use them.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lucas De Marchi lucas.demarchi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

The driver should still be functional with small-bar, just that the vram
size is clamped to the BAR size (until we add proper support for tiered
vram). For stolen vram we shouldn't iomap anything if the BAR size
doesn't also contain the stolen portion, since on discrete the stolen
portion is always at the end of normal vram. Stolen should still be
functional, just that allocating CPU visible io memory will always
return an error.

v2 (Lucas)
  - Mention in the commit message that stolen vram is always as the end
    of normal vram, which is why stolen in not mappable on small-bar
    systems.
  - Just make xe_ttm_stolen_inaccessible() return true for such cases.
    Also rename to xe_ttm_stolen_cpu_inaccessible to better describe
    that we are talking about direct CPU access. Plus add some
    kernel-doc.

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/209Reported-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Make sure we properly release the forcewake ref on all error paths.

v2(Lucas):
  - Make it less verbose and just fold the unimplemented options into
    the default. The exact return value doesn't seem to matter for the
    corresponding IGT.
  - Replace the user triggerable WARN() with drm_dbg().
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

(!(gt->info.engine_mask & BIT(i))) cases are already
handled in the init function. And these masks are not
modified between the init and the prune.
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

The list of GTs got splitted a while back between GT1
and GT2 on TGL.

References: https://patchwork.freedesktop.org/patch/388414/
CC: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Carlos Santa <carlos.santa@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

ret is not initialized in mcr_lock() when running in platforms with
graphics IP version < 1270, this could cause drm_WARN_ON_ONCE()
to hit eventually(what just happened to me).

Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Just like there is support for multiple rules per entry in an rtp table,
also support multiple actions. This makes it easier to add support for
workarounds that need to change multiple registers. It also makes it
slightly more readable as now the action part resembles the rule part.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Entry flags is meant for the whole entry, including the rule
evaluation. Action flags are for flags applied to the register or
action being taken. Since there's only one action per entry, the
distinction was not important and a u8 was spared. However more and more
workarounds are needing multiple actions. This prepares for multiple
action support.

Right now there are these action flags:

 - XE_RTP_ACTION_FLAG_MASKED_REG: register in the action is a masked
   register
 - XE_RTP_ACTION_FLAG_ENGINE_BASE: the engine base should be added to
   the register in order to form the real address

And this entry flag:

 - XE_RTP_ENTRY_FLAG_FOREACH_ENGINE: the rules should be evaluated for
   each engine on the gt. It also automatically implies
   XE_RTP_ACTION_FLAG_ENGINE_BASE.

Since there are likely not that many rules, reduce n_rules to u8 so the
overall entry size doesn't increase more than needed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

It's true that the struct records the register and the value (in form of
2 masks) to restore, but it also records more fields important to
the application of workarounds/tuning, etc. One important part is what
is the macro used to record these fields: SET/CLR/WR/FIELD_SET/etc.

Thinking of the table as a set of rules + actions is more intuitive than
rules + regval.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Like detailed in commit 927dfdd0 ("drm/i915/dg2: Add SQIDI
steering"), some registers are expected to have the selector
initialized just once and never set to anything else. For xe, the
registers with SQIDI replication type (SF and MCFG) were missing,
resulting in warnings like:

	[  410.685565] xe 0000:03:00.0: Did not find MCR register 0x8724 in any MCR steering table

While adding these registers, abstract the handling for
"dg2_gam_ranges", moving them together with SF/MCFG to a dedicated
table. This also avoids that range to be checked for platforms other
than DG2. For DG2, this is the new steering output:

	# cat /sys/kernel/debug/dri/0/gt0/steering
	...
	IMPLICIT steering: group=0x0, instance=0x0
		0x000b00 - 0x000bff
		0x001000 - 0x001fff
		0x004000 - 0x004aff
		0x008700 - 0x0087ff
		0x00c800 - 0x00cfff
		0x00f000 - 0x00ffff
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

There is already a BUILD_BUG_ON() check to make sure the size follow the
number of steering types. Also make sure the right index is being used
for each steering type.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

LRC workarounds are already implemented: remove leftover TODO.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

The function pointer is already present as match_func, inside
struct xe_rtp_rule and handled as so instead of inside rtp_regval as
originally thought out when this was written.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

xe_tuning.c should include xe_tuning.h, not xe_wa.h
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Add missing "multicast" word and adapt/wrap the rest of the sentence.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Adding a debugfs dump of GGTT was useful for some debugging I did,
and easy to add. Might be useful for others too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Now that we issue TLB invalidations on unbinds and rebind from execs we
no longer need to issue TLB invalidations from the ring operations.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

If we add an TLB invalidation fence for rebinds issued from execs we
should be able to drop the TLB invalidation from the ring operations.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Rather than alias supports_usm to ASIS support, add an explicit
variable to indicate ASID support.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

This means we are in the middle of a GT reset and no need to do TLB
invalidation so just signal invalidation fence immediately.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

If a VM unbind hits an error, do not issue a TLB invalidation and
propagate the error the invalidation fence.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Make lockdep happy as we required to hold the GGTT when calling
xe_ggtt_map_bo.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Only the GuC should be issuing TLB invalidations if it is enabled. Part
of this patch is sanitize the device on driver unload to ensure we do
not send GuC based TLB invalidations during driver unload.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

If an bind operation fails we need to report it via the async fence.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

If the platform supports range based TLB invalidations use them. Hide
these details in the xe_gt_tlb_invalidation layer.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

This will help implementing range based TLB invalidations.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Not used, let's remove this.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

This will help with TLB invalidation as the ASID in TLB invalidate
should be zero for platforms that do not support a ASID.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Endless fences are not good, add a TDR to cleanup any invalidation
fences which have not received an invalidation message within a timeout
period.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

This will help debug issues with TLB invalidation fences.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>