aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-31drm/i915/guc: drop guc_communication_enabledDaniele Ceraolo Spurio1-8/+3
The function is only used from within GEM_BUG_ON(), which is causing warnings with Wunneeded-internal-declaration in some builds. Since the function is a simple wrapper around a CT function, we can just call the CT function directly instead. Fixes: 1fb12c587152 ("drm/i915/guc: skip disabling CTBs before sanitizing the GuC") Reported-by: kernel test robot <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Matthew Brost <[email protected]> Cc: John Harrison <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-27drm/i915: Actually delete gpu reloc selftestsDaniel Vetter1-190/+0
In commit 8e02cceb1f1f ("drm/i915: delete gpu reloc code") I deleted the gpu relocation code and the selftest include and enabling, but accidentally forgot about the selftest source code. Fix this oversight. Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Jon Bloomfield <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: "Thomas Hellström" <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-26drm/i915: Ensure wa_init_finish() is called for ctx workaround listMatt Roper1-1/+2
A recent restructuring of our context workaround list initialization added an early return for non-render engines; this caused us to potentially miss the wa_init_finish() call at the end of the function. The mistake is pretty harmless --- the only impact is that non-render engines on graphics version 12.50+ platforms we don't trim down the workaround list to reclaim some memory, and we don't print the usual "Initialized 1 context workaround" message in dmesg. Let's change the early return to a jump down to the wa_init_finish() call at the bottom of the function. Reported-by: Tvrtko Ursulin <[email protected]> Fixes: 9e9dfd080201 ("drm/i915/dg2: Maintain backward-compatible nested batch behavior") Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-26drm/i915/pci: rename functions to have i915_pci prefixJani Nikula3-8/+12
Follow the usual naming conventions. While at it, fix i915_pci.h SPDX license comment format and add header include guards. Cc: Daniel Vetter <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-25drm/ttm, drm/i915: Update ttm_move_memcpy for async useThomas Hellström3-12/+12
The buffer object argument to ttm_move_memcpy was only used to determine whether the destination memory should be cleared only or whether we should copy data. Replace it with a "clear" bool, and update the callers. The intention here is to be able to use ttm_move_memcpy() async under a dma-fence as a fallback if an accelerated blit fails in a security- critical path where data might leak if the blit is not properly performed. For that purpose the bo is an unsuitable argument since its relevant members might already have changed at call time. Finally, update the ttm_move_memcpy kerneldoc that seems to have ended up with a stale version. Cc: Christian König <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-25drm/i915/ttm: Reorganize the ttm move code somewhatThomas Hellström1-33/+44
In order to make the code a bit more readable and to facilitate async memcpy moves, reorganize the move code a little. Determine at an early stage whether to copy or to clear. v2: - Don't set up the memcpy iterators unless we are actually going to memcpy. Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-24drm/i915/dg2: Add new LRI reg offsetsAkeem G Abodunrin1-2/+83
New LRI register offsets were introduced for DG2, this patch adds those extra registers, and create new register table for setting offsets to compare with HW generated context image - especially for gt_lrc test. Also updates general purpose register with scratch offset for DG2, in order to use it for live_lrc_fixed selftest. Cc: Chris P Wilson <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Signed-off-by: Akeem G Abodunrin <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-24drm/i915/selftests: Increase timeout in i915_gem_contexts selftestsMatthew Brost1-1/+1
Like in the case of several other selftests, generating lots of requests in a loop takes a bit longer with GuC submission. Increase a timeout in i915_gem_contexts selftest to take this into account. Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-25drm/i915: s/0/NULL/Ville Syrjälä1-1/+1
Use NULL where appropriate. drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain integer as NULL pointer Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]>
2021-08-24drm/i915/selftest: Fix use of err in igt_reset_{fail, nop}_engine()Nathan Chancellor1-2/+2
Clang warns: In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable 'err' is uninitialized when used here [-Wuninitialized] pr_err("[%s] Create context failed: %d!\n", engine->name, err); ^~~ ... drivers/gpu/drm/i915/gt/selftest_hangcheck.c:580:62: warning: variable 'err' is uninitialized when used here [-Wuninitialized] pr_err("[%s] Create context failed: %d!\n", engine->name, err); ^~~ ... 2 warnings generated. This appears to be a copy and paste issue. Use ce directly using the %pe specifier to pretty print the error code so that err is not used uninitialized in these functions. Fixes: 3a7b72665ea5 ("drm/i915/selftest: Bump selftest timeouts for hangcheck") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-20drm/i915/dg1: remove __maybe_unused leftoverLucas De Marchi1-1/+1
This was added in commit 05e265841f7e ("drm/i915/dg1: add initial DG-1 definitions") so we could continue to add support for DG1 without risk to expose a broken UAPI. Now that we added DG1 to the PCI ID list i915 may bind to, remove the leftover. Fixes: d5ef86b38e4c ("drm/i915: Add pci ids and uapi for DG1") Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-20drm/i915/gt: Potential error pointer dereference in pinned_context()Dan Carpenter1-1/+1
If the intel_engine_create_pinned_context() function returns an error pointer, then dereferencing "ce" will Oops. Use "vm" instead of "ce->vm". Fixes: cf586021642d ("drm/i915/gt: Pipelined page migration") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210813113600.GC30697@kili
2021-08-20drm/i915/debugfs: hook up ttm_resource_manager_debugMatthew Auld3-2/+18
This should give a more complete view of the various bits of internal resource manager state, for device local-memory. v2(Thomas): - Move the region printing into a nice helper Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-20drm/i915/buddy: add some pretty printingMatthew Auld3-1/+72
Implement the debug hook for the buddy resource manager. For this we want to print out the status of the memory manager, including how much memory is still allocatable, what page sizes we have etc. This will be triggered when TTM is unable to fulfil an allocation request for device local-memory. v2(Thomas): - s/MB/MiB - s/KB/KiB Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-20drm/i915: Ditch the i915_gem_ww_ctx loop memberThomas Hellström1-17/+8
It's only used by the for_i915_gem_ww() macro and we can use the (typically) on-stack _err variable in its place. v2: - Don't clear the _err variable when entering the loop (Matthew Auld, Maarten Lankhorst). - Use parentheses around the _err macro argument. - Fix up comment. Cc: Matthew Auld <[email protected]> Suggested-by: Maarten Lankhorst <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-19drm/i915: Fix syncmap memory leakMatthew Brost1-0/+9
A small race exists between intel_gt_retire_requests_timeout and intel_timeline_exit which could result in the syncmap not getting free'd. Rather than work to hard to seal this race, simply cleanup the syncmap on fini. unreferenced object 0xffff88813bc53b18 (size 96): comm "gem_close_race", pid 5410, jiffies 4294917818 (age 1105.600s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 ................ 00 00 00 00 00 00 00 00 6b 6b 6b 6b 06 00 00 00 ........kkkk.... backtrace: [<00000000120b863a>] __sync_alloc_leaf+0x1e/0x40 [i915] [<00000000042f6959>] __sync_set+0x1bb/0x240 [i915] [<0000000090f0e90f>] i915_request_await_dma_fence+0x1c7/0x400 [i915] [<0000000056a48219>] i915_request_await_object+0x222/0x360 [i915] [<00000000aaac4ee3>] i915_gem_do_execbuffer+0x1bd0/0x2250 [i915] [<000000003c9d830f>] i915_gem_execbuffer2_ioctl+0x405/0xce0 [i915] [<00000000fd7a8e68>] drm_ioctl_kernel+0xb0/0xf0 [drm] [<00000000e721ee87>] drm_ioctl+0x305/0x3c0 [drm] [<000000008b0d8986>] __x64_sys_ioctl+0x71/0xb0 [<0000000076c362a4>] do_syscall_64+0x33/0x80 [<00000000eb7a4831>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Matthew Brost <[email protected]> Fixes: 531958f6f357 ("drm/i915/gt: Track timeline activeness in enter/exit") Cc: <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-18drm/i915/dg2: Maintain backward-compatible nested batch behaviorMatt Roper2-2/+38
For tgl+, the per-context setting of MI_MODE[12] determines whether the bits of a nested MI_BATCH_BUFFER_START instruction should be interpreted in the traditional manner or whether they should instead use a new tgl+ meaning that breaks backward compatibility, but allows nesting into 3rd-level batchbuffers. For previous platforms, the hardware default for this register bit is to maintain backward-compatible behavior unless a context intentionally opts into the new behavior; however Xe_HPG flips the hardware default behavior. From a SW perspective, we want to maintain the backward-compatible behavior for userspace, so we'll apply a fake workaround to set it back to the legacy behavior on platforms where the hardware default is to break compatibility. At the moment there is no Linux userspace that utilizes third-level batchbuffers, so this will avoid userspace from needing to make any changes. using the legacy meaning is the correct thing to do. If/when we have userspace consumers that want to utilize third-level batch nesting, we can provide a context parameter to allow them to opt-in. Bspec: 45974, 45718 Cc: John Harrison <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Anusha Srivatsa <[email protected]>
2021-08-18drm/i915: Use designated initializers for init/exit tableKees Cook1-13/+24
The kernel builds with -Werror=designated-init, and __designated_init is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all function pointer) structures. Include the field names in the init/exit table. Avoids warnings like: drivers/gpu/drm/i915/i915_module.c:59:4: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init] Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: a04ea6ae7c67 ("drm/i915: Use a table for i915_init/exit (v2)") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-13drm/i915: Add pci ids and uapi for DG1Maarten Lankhorst3-6/+1
DG1 has support for local memory, which requires the usage of the lmem placement extension for creating bo's, and memregion queries to obtain the size. Because of this, those parts of the uapi are no longer guarded behind FAKE_LMEM. According to the pull request referenced below, mesa should be mostly ready for DG1. VK_EXT_memory_budget is not hooked up yet, but we should definitely just enable the uapi parts by default. Signed-off-by: Maarten Lankhorst <[email protected]> References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584 Cc: Jordan Justen <[email protected]> Cc: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
2021-08-12drm/i915/xehpsdv: Read correct RP_STATE_CAP registerMatt Roper2-1/+4
The RP_STATE_CAP register is no longer part of the MCHBAR on XEHPSDV; this register is now a per-tile register at GTTMMADDR offset 0x250014. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-12drm/i915/xehpsdv: factor out function to read RP_STATE_CAPLucas De Marchi4-15/+19
Instead of maintaining the same if ladder in 3 different places, add a function to read RP_STATE_CAP. Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-12drm/i915: Use locked access to ctx->engines in set_priorityDaniel Vetter1-58/+14
This essentially reverts commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc Author: Chris Wilson <[email protected]> Date: Thu Apr 2 13:42:18 2020 +0100 drm/i915/gem: Utilize rcu iteration of context engines Note that the other use of __context_engines_await have disappeard in the following commits: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running contexts (v4)") c7a71fc8ee04 ("drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES") 4a766ae40ec8 ("drm/i915: Drop the CONTEXT_CLONE API (v2)") None of these have any business to optimize their engine lookup with rcu, unless extremely convincing benchmark data and a solid analysis why we can't make that workload (whatever it is that does) faster with a proper design fix. Also since there's only one caller of context_apply_all left and it's really just a loop, inline it and then inline the lopp body too. This is how all other callers that take the engine lock loop over engines, it's much simpler. Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-11drm/i915/xehpsdv: Add compute DSS typeStuart Summers3-17/+50
Starting in XeHP, the concept of slice has been removed in favor of DSS (Dual-Subslice) masks for various workload types. These workloads have been divided into those enabled for geometry and those enabled for compute. i915 currently maintains a single set of S/SS/EU masks for the device. The goal of this patch set is to minimize the amount of impact to prior generations while still giving the user maximum flexibility. v2: - Generalize a comment about uapi access to geometry/compute masks; the proposed uapi has changed since the comment was first written, and will show up in a future series once the userspace code is published. (Lucas) v3: - Eliminate unnecessary has_compute_dss flag. (Lucas) - Drop unwanted comment change in uapi header. (Lucas) Bspec: 33117, 33118, 20376 Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Matt Roper <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: Stuart Summers <[email protected]> Signed-off-by: Steve Hampson <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-11drm/i915/dg2: Report INSTDONE_GEOM values in error stateMatt Roper4-2/+19
Xe_HPG adds some additional INSTDONE_GEOM debug registers; the Mesa team has indicated that having these reported in the error state would be useful for debugging GPU hangs. These registers are replicated per-DSS with gslice steering. Cc: Lionel Landwerlin <[email protected]> Signed-off-by: Matt Roper <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-11drm/i915/xehp: Loop over all gslices for INSTDONE processingMatt Roper4-33/+66
We no longer have traditional slices on Xe_HP platforms, but the INSTDONE registers are replicated according to gslice representation which is similar. We can mostly re-use the existing instdone code with just a few modifications: * Create an alternate instdone loop macro that will iterate over the flat DSS space, but still provide the gslice/dss steering values for compatibility with the legacy code. * We should allocate INSTDONE storage space according to the maximum number of gslices rather than the maximum number of legacy slices to ensure we have enough storage space to hold all of the values. XeHP design has 8 gslices, whereas older platforms never had more than 3 slices. Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-11drm/doc/rfc: drop lmem uapi sectionDaniel Vetter1-109/+0
We still have quite a bit more work to do with overall reworking of the ttm-based dg1 code, but the uapi stuff is now finalized with the latest pull. So remove that. This also fixes kerneldoc build warnings because we've included the same headers in two places, resulting in sphinx complaining about duplicated symbols. This regression has been created when we moved the uapi definitions to the real include/uapi/ folder in 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") v2: Fix a few references that I missed, the htmldocs build took forever. Acked-by: Jason Ekstrand <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Tested-by Stephen Rothwell <[email protected]> (v1) References: https://lore.kernel.org/dri-devel/[email protected]/ Reported-by: Stephen Rothwell <[email protected]> Cc: Stephen Rothwell <[email protected]> Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") Cc: Matthew Auld <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915/xehp: Xe_HP shadowed registers are a strict superset of gen12Matt Roper2-40/+13
The list of shadowed registers on XeHP is identical to the set for earlier gen12 platforms, with additional ranges added for the new VCS and VECS engines. Since those register ranges were reserved on earlier gen12 platforms, it's safe to consolidate to a single gen12 table rather than tracking Xe_HP separately. Bspec: 52077 Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915/gen12: Update shadowed register tableMatt Roper1-9/+14
The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 52077 Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915/gen11: Update shadowed register tableMatt Roper1-8/+14
The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 18333 Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915: Make shadow tables range-basedMatt Roper4-103/+108
Rather than defining our shadow tables as a list of individual registers, provide them as a list of register ranges; we'll have some ranges of multiple registers being added soon (and we already have a couple adjacent registers that we can squash into a single range now). This change also defines the table with hex literal values rather than symbolic register names; since that's how the tables are defined in the bspec, this change will make it easier to review the tables overall. v2: - Force signed comparison on range overlap sanity check Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915: Re-use gen11 forcewake read functions on gen12Matt Roper1-5/+1
The forcewake read logic is identical between gen11 and gen12, only the forcewake table data (which is tracked separately) differs; there's no need to generate a separate set of gen12 read functions when the gen11 functions will work just as well. We'll keep the separate write functions for now since the generated code directly references different shadow tables between the two platforms. Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-10drm/i915: correct name of GT forcewake domain in error messagesMatt Roper1-1/+1
For historical reasons, the GT forcewake domain used to be referred to as the "blitter" domain; that name is no longer accurate since the GT domain contains a lot of additional registers and functionality besides just the blitter. Although we renamed the domain in the driver in commit 55e3c170950f ("drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GT"), we neglected to update the string that gets printed in driver error messages; let's do that now to avoid confusion. Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-06drm/i915: Disable bonding on gen12+ platformsMatthew Brost1-0/+7
Disable bonding on gen12+ platforms aside from ones already supported by the i915 - TGL, RKL, and ADL-S. Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: John Harrison <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915/dg2: Add SQIDI steeringMatt Roper2-5/+25
Although DG2_G10 platforms will always have all SQIDI's present and don't need steering for registers in a SQIDI MMIO range, this isn't true for DG2_G11 platforms; only SQIDI's 2 and 3 can be used on those. We handle SQIDI ranges a bit differently from other types of explicit steering. The SQIDI ranges belong to either the MCFG unit or the SF unit, both of which have their own dedicated steering registers and do not use the typical 0xFDC steering control that all other types of ranges use. Thus we only need to worry about picking a valid initial value for the MCFG and SF steering registers (0xFD0 and 0xFD8 respectively) at driver init; they won't change after we set them up so we don't need to worry about re-steering them explicitly at runtime. Given that any SQIDI value should work fine for DG2-G10 and XeHP SDV, while only values of 2 and 3 are valid for DG2-G11, we'll just initialize the MCFG and SF steering registers to a constant value of "2" for all XeHP-based platforms for simplicity --- that will work in all cases. Bspec: 66534 Cc: Radhakrishna Sripada <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915/dg2: Update steering tablesMatt Roper1-1/+10
DG2's replicated register ranges are almost the same at XeHP SDV with the exception of one LNCF sub-range that switches to gslice steering. We can re-use the XeHP SDV mslice steering table and just provide a DG2-specific LNCF steering table. Bspec: 66534 Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915/xehpsdv: Define steering tablesMatt Roper2-3/+27
Define and initialize the MMIO ranges for which XeHP SDV requires MSLICE and LNCF steering. Bspec: 66534 Cc: Tvrtko Ursulin <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915/xehp: handle new steering optionsDaniele Ceraolo Spurio10-6/+163
Xe_HP is more modular than its predecessors and as a consequence it has more types of replicated registers. As with l3bank regions on previous platforms, we may need to explicitly re-steer accesses to these new types of ranges at runtime if we can't find a single default steering value that satisfies the fusing of all types. v2: - Add a local 'i915' variable to reduce gt->i915 usage. (Caz) - Drop unused 'intel_gt_read_register' prototype. (Caz) v3: - Drop unnecessary comment text. (Lucas) - Drop unused register bit definition. (Lucas) Bspec: 66534 Cc: Tvrtko Ursulin <[email protected]> Cc: Caz Yokoyama <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915/userptr: Probe existence of backing struct pages upon creationChris Wilson3-1/+61
Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a complete set of pages upon creation. To be more efficient than simply populating the userptr using get_user_pages() (as done by the call to set-domain or execbuf), we can walk the tree of vm_area_struct and check for gaps or vma not backed by struct page (VM_PFNMAP). The question is how to handle VM_MIXEDMAP which may be either struct page or pfn backed... With discrete we are going to drop support for set_domain(), so offering a way to probe the pages, without having to resort to dummy batches has been requested. v2: - add new query param for the PROBE flag, so userspace can easily check if the kernel supports it(Jason). - use mmap_read_{lock, unlock}. - add some kernel-doc. v3: - In the docs also mention that PROBE doesn't guarantee that the pages will remain valid by the time they are actually used(Tvrtko). - Add a small comment for the hole finding logic(Jason). - Move the param next to all the other params which just return true. Testcase: igt/gem_userptr_blits/probe Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Jordan Justen <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ramalingam C <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915: delete gpu reloc codeDaniel Vetter2-360/+1
It's already removed, this just garbage collects it all. v2: Rebase over s/GEN/GRAPHICS_VER/ v3: Also ditch eb.reloc_pool and eb.reloc_context (Maarten) Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Jon Bloomfield <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: "Thomas Hellström" <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-05drm/i915: Disable gpu relocationsDaniel Vetter1-25/+18
Media userspace was the last userspace to still use them, and they converted now too: https://github.com/intel/media-driver/commit/144020c37770083974bedf59902b70b8f444c799 This means no reason anymore to make relocations faster than they've been for the first 9 years of gem. This code was added in commit 7dd4f6729f9243bd7046c6f04c107a456bda38eb Author: Chris Wilson <[email protected]> Date: Fri Jun 16 15:05:24 2017 +0100 drm/i915: Async GPU relocation processing Furthermore there's pretty strong indications it's buggy, since the code to use it by default as the only option had to be reverted: commit ad5d95e4d538737ed3fa25493777decf264a3011 Author: Dave Airlie <[email protected]> Date: Tue Sep 8 15:41:17 2020 +1000 Revert "drm/i915/gem: Async GPU relocations only" This code just disables gpu relocations, leaving the garbage collection for later patches and more importantly, much less confusing diff. Also given how much headaches this code has caused in the past, letting this soak for a bit seems justified. Acked-by: Dave Airlie <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Jon Bloomfield <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Thomas Hellström" <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/dg2: DG2 uses the same sseu limits as XeHP SDVMatt Roper1-1/+1
DG2 supports compute DSS and has the same maximum number of DSS and EU as XeHP SDV. Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/xehpsdv: Add maximum sseu limitsMatt Roper3-3/+6
Due to the removal of legacy slices and the transition to a gslice/cslice/mslice/etc. design, we'll internally store all DSS under "slice0." Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Caz Yokoyama <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/xehp: Changes to ss/eu definitionsMatthew Auld3-6/+27
Xe_HP no longer has "slices" in the same way that old platforms did. There are new concepts (gslices, cslices, mslices) that apply in various contexts, but for the purposes of fusing slices no longer exist and we just have one large pool of dual-subslices (DSS) to work with. Furthermore, the meaning of the DSS fuse is inverted compared to past platforms --- it now specifies which DSS are enabled rather than which ones are disabled. Cc: Rodrigo Vivi <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Signed-off-by: Stuart Summers <[email protected]> Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Prasad Nallani <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/dg2: Add forcewake tableMatt Roper1-137/+168
The DG2 forcewake table is very similar to the one used by XeHP SDV (and both platforms are even presented as a single table in the bspec). For the most part DG2 starts using a few additional ranges that were 'reserved' on XeHP SDV and stops using some others. However there is a single range (0xd800-0xd87f) that needs to be handled differently between the two platforms (it needs GT wake on XeHP SDV, but render wake on DG2) so unless we want to wake both domains (which could waste power) or define new types of forcewake domains for this special case we need to have separate tables for the two platforms. Let's define the ranges for both platforms with a parameterized macro so that we don't actually need to duplicate everything in the code. It should be fine for DG2 to re-use the Xe_HP shadow register list so we can continue to use the 'xehpsdv' MMIO write functions and don't need to spin up a separate DG2 instance. Bspec: 66534 Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/rc: Setup and enable GuCRC featureVinay Belgaumkar8-15/+155
This feature hands over the control of HW RC6 to the GuC. GuC decides when to put HW into RC6 based on it's internal busyness algorithms. GuCRC needs GuC submission to be enabled, and only supported on Gen12+ for now. When GuCRC is enabled, do not set HW RC6. Use a H2G message to tell GuC to enable GuCRC. When disabling RC6, tell GuC to revert RC6 control back to KMD. KMD is still responsible for enabling everything related to Coarse Power Gating though. v2: Address comments (Michal W) v3: Don't set hysterisis values when GuCRC is used (Matt Roper) v4: checkpatch() Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/slpc: Add SLPC selftestVinay Belgaumkar3-0/+313
Tests that exercise the SLPC get/set frequency interfaces. Clamp_max will set max frequency to multiple levels and check that SLPC requests frequency lower than or equal to it. Clamp_min will set min frequency to different levels and check if SLPC requests are higher or equal to those levels. v2: Address review comments (Michal W) v3: Checkpatch() corrections v4: Remove unnecessary header file (Matthew Brost) v5: checkpatch() and define const for 50/3 (Matthew Brost) Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/slpc: Sysfs hooks for SLPCVinay Belgaumkar5-67/+207
Update the get/set min/max freq hooks to work for SLPC case as well. Consolidate helpers for requested/min/max frequency get/set to intel_rps where the proper action can be taken depending on whether SLPC is enabled. v2: Add wrappers for getting rp0/1/n frequencies, update softlimits in set min/max SLPC functions. Also check for boundary conditions before setting them. v3: Address review comments (Michal W) v4: Add helper for host part of intel_rps_set_freq helpers (Michal W) v5: checkpatch() Reviewed-by: Michal Wajdeczko <[email protected]> Acked-by: Michal Wajdeczko <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Sujaritha Sundaresan <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/slpc: Cache platform frequency limitsVinay Belgaumkar3-0/+151
Cache rp0, rp1 and rpn platform limits into SLPC structure for range checking while setting min/max frequencies. Also add "soft" limits which keep track of frequency changes made from userland. These are initially set to platform min and max. v2: Address review comments (Michal W) v3: Formatting (Michal W) v4: Add separate function to parse rp values (Michal W) v5: Perform range checking for set min/max (Michal W) v6: checkpatch() and rename static functions (Michal W) v7: check ret code while setting SLPC limits (Michal W) Signed-off-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/slpc: Enable ARAT timer interruptVinay Belgaumkar3-0/+27
This interrupt is enabled during RPS initialization, and now needs to be done by SLPC code. It allows ARAT timer expiry interrupts to get forwarded to GuC. v2: Fix comment (Matthew Brost) v3: checkpatch() Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-08-03drm/i915/guc/slpc: Add debugfs for SLPC infoVinay Belgaumkar3-0/+54
This prints out relevant SLPC info from the SLPC shared structure. We will send a H2G message which forces SLPC to update the shared data structure with latest information before reading it. v2: Address review comments (Michal W) v3: Remove unnecessary tasks from slpc_info (Michal W) v4: Rename function to intel_guc_slpc_print_info() (Michal W) v5: checkpatch() Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: Sundaresan Sujaritha <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.