summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gt
AgeCommit message (Collapse)Author
2023-06-02drm/i915/gt: limit lmem allocation size to succeed on SmallBarsAndrzej Hajda
In case system is short on mappable memory (256MB on SmallBar) allocation of two 1GB buffers will fail. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8300 Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230601144450.792228-1-andrzej.hajda@intel.com
2023-06-02drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries, page}()Nathan Chancellor
When building with clang's -Wincompatible-function-pointer-types-strict, the following warnings occur: drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible function pointer types assigning to 'void (*)(struct i915_address_space *, dma_addr_t, u64, unsigned int, u32)' (aka 'void (*)(struct i915_address_space *, unsigned int, unsigned long long, unsigned int, unsigned int)') from 'void (struct i915_address_space *, dma_addr_t, u64, enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, unsigned int, unsigned long long, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.insert_page = gmch_ggtt_insert_page; ^ ~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:103:26: error: incompatible function pointer types assigning to 'void (*)(struct i915_address_space *, struct i915_vma_resource *, unsigned int, u32)' (aka 'void (*)(struct i915_address_space *, struct i915_vma_resource *, unsigned int, unsigned int)') from 'void (struct i915_address_space *, struct i915_vma_resource *, enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, struct i915_vma_resource *, enum i915_cache_level, unsigned int)') [-Werror, -Wincompatible-function-pointer-types-strict] ggtt->vm.insert_entries = gmch_ggtt_insert_entries; ^ ~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. The warning is pointing out that while 'enum i915_cache_level' and 'unsigned int' are ABI compatible, these indirect calls will fail clang's kernel Control Flow Integrity (kCFI) checks, as the callback's signature does not exactly match the prototype's signature. To fix this, replace the cache_level parameter with pat_index, as was done in other places within i915 where there is no difference between cache_level and pat_index on certain generations. Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Fei Yang <fei.yang@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230530-i915-gt-cache_level-wincompatible-function-pointer-types-strict-v1-2-54501d598229@kernel.org
2023-06-02drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacksNathan Chancellor
When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a CFI failure in ggtt_probe_common() when trying to call hsw_pte_encode() via an indirect call: [ 5.030027] CFI failure at ggtt_probe_common+0xd1/0x130 [i915] (target: hsw_pte_encode+0x0/0x30 [i915]; expected type: 0xf5c1d0fc) With kCFI, indirect calls are validated against their expected type versus actual type and failures occur when the two types do not match. clang's -Wincompatible-function-pointer-types-strict can catch this at compile time but it is not enabled for the kernel yet: drivers/gpu/drm/i915/gt/intel_ggtt.c:1155:23: error: incompatible function pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64 (dma_addr_t, enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.pte_encode = iris_pte_encode; ^ ~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_ggtt.c:1157:23: error: incompatible function pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64 (dma_addr_t, enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.pte_encode = hsw_pte_encode; ^ ~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_ggtt.c:1159:23: error: incompatible function pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64 (dma_addr_t, enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.pte_encode = byt_pte_encode; ^ ~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_ggtt.c:1161:23: error: incompatible function pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64 (dma_addr_t, enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.pte_encode = ivb_pte_encode; ^ ~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_ggtt.c:1163:23: error: incompatible function pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64 (dma_addr_t, enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] ggtt->vm.pte_encode = snb_pte_encode; ^ ~~~~~~~~~~~~~~ 5 errors generated. In this case, the pre-gen8 pte_encode functions have a second parameter type of 'enum i915_cache_level' whereas the function pointer prototype in 'struct i915_address_space' expects a second parameter type of 'unsigned int'. Update the second parameter of the callbacks and the comment above them noting that these statements are still valid, which matches other functions and files, to clear up the kCFI failures at run time. Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Fei Yang <fei.yang@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230530-i915-gt-cache_level-wincompatible-function-pointer-types-strict-v1-1-54501d598229@kernel.org
2023-06-01drm/i915/gt: Use the correct error value when kernel_context() failsAndi Shyti
kernel_context() returns an error pointer. Use pointer-error conversion functions to evaluate its return value, rather than checking for a '0' return. Fixes: eb5c10cbbc2f ("drm/i915: Remove I915_USER_PRIORITY_SHIFT") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.13+ Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526124138.2006110-1-andi.shyti@linux.intel.com
2023-05-31drm/i915/guc: Drop legacy CTB definitionsMichal Wajdeczko
We've already switched to new HXG definitions some time ago, drop legacy CTB definitions to avoid mistakes. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230509201103.538-1-michal.wajdeczko@intel.com
2023-05-31Merge drm/drm-next into drm-intel-nextJani Nikula
Sync the drm-intel-gt-next changes back to drm-intel-next via drm-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2023-05-30drm/i915/guc: Track all sent actions to GuCMichal Wajdeczko
For easier debug of any unexpected error responses from GuC that might be related to non-blocking fast requests, track action code (and stack if under DEBUG_GUC config) for every H2G request. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526235538.2230780-4-John.C.Harrison@Intel.com
2023-05-30drm/i915/guc: Update log for unsolicited CTB responseMichal Wajdeczko
Instead of printing message fence twice, include HXG header of the unexpected message and its len. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526235538.2230780-3-John.C.Harrison@Intel.com
2023-05-30drm/i915/guc: Use FAST_REQUEST for non-blocking H2G callsMichal Wajdeczko
In addition to the already defined REQUEST HXG message format, which is used when sender expects some confirmation or data, HXG protocol includes definition of the FAST REQUEST message, that may be used when sender does not expect any useful data to be returned. Using this instead of GUC_HXG_TYPE_EVENT for non-blocking CTB requests will allow GuC to send back GUC_HXG_TYPE_RESPONSE_FAILURE in case of errors. Note that it is not possible to return such errors to the caller, since this is for non-blocking calls and the related fence is not stored. Instead such messages are treated as unexpected, which will give an indication of potential GuC misprogramming that warrants extra debugging effort. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526235538.2230780-2-John.C.Harrison@Intel.com
2023-05-29Merge tag 'drm-intel-gt-next-2023-05-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - New getparam for querying PXP support and load status Cross-subsystem Changes: - GSC/MEI proxy driver Driver Changes: Fixes/improvements/new stuff: - Avoid clearing pre-allocated framebuffers with the TTM backend (Nirmoy Das) - Implement framebuffer mmap support (Nirmoy Das) - Disable sampler indirect state in bindless heap (Lionel Landwerlin) - Avoid out-of-bounds access when loading HuC (Lucas De Marchi) - Actually return an error if GuC version range check fails (John Harrison) - Get mutex and rpm ref just once in hwm_power_max_write (Ashutosh Dixit) - Disable PL1 power limit when loading GuC firmware (Ashutosh Dixit) - Block in hwmon while waiting for GuC reset to complete (Ashutosh Dixit) - Provide sysfs for SLPC efficient freq (Vinay Belgaumkar) - Add support for total context runtime for GuC back-end (Umesh Nerlige Ramappa) - Enable fdinfo for GuC backends (Umesh Nerlige Ramappa) - Don't capture Gen8 regs on Xe devices (John Harrison) - Fix error capture for virtual engines (John Harrison) - Track patch level versions on reduced version firmware files (John Harrison) - Decode another GuC load failure case (John Harrison) - GuC loading and firmware table handling fixes (John Harrison) - Fix confused register capture list creation (John Harrison) - Dump error capture to kernel log (John Harrison) - Dump error capture to dmesg on CTB error (John Harrison) - Disable rps_boost debugfs when SLPC is used (Vinay Belgaumkar) Future platform enablement: - Disable stolen memory backed FB for A0 [mtl] (Nirmoy Das) - Various refactors for multi-tile enablement (Andi Shyti, Tejas Upadhyay) - Extend Wa_22011802037 to MTL A-step (Madhumitha Tolakanahalli Pradeep) - WA to clear RDOP clock gating [mtl] (Haridhar Kalvala) - Set has_llc=0 [mtl] (Fei Yang) - Define MOCS and PAT tables for MTL (Madhumitha Tolakanahalli Pradeep) - Add PTE encode function [mtl] (Fei Yang) - fix mocs selftest [mtl] (Fei Yang) - Workaround coherency issue for Media [mtl] (Fei Yang) - Add workaround 14018778641 [mtl] (Tejas Upadhyay) - Implement Wa_14019141245 [mtl] (Radhakrishna Sripada) - Fix the wa number for Wa_22016670082 [mtl] (Radhakrishna Sripada) - Use correct huge page manager for MTL (Jonathan Cavitt) - GSC/MEI support for Meteorlake (Alexander Usyskin, Daniele Ceraolo Spurio) - Define GuC firmware version for MTL (John Harrison) - Drop FLAT CCS check [mtl] (Pallavi Mishra) - Add MTL for remapping CCS FBs [mtl] (Clint Taylor) - Meteorlake PXP enablement (Alan Previn) - Do not enable render power-gating on MTL (Andrzej Hajda) - Add MTL performance tuning changes (Radhakrishna Sripada) - Extend Wa_16014892111 to MTL A-step (Radhakrishna Sripada) - PMU multi-tile support (Tvrtko Ursulin) - End support for set caching ioctl [mtl] (Fei Yang) Driver refactors: - Use i915 instead of dev_priv insied the file_priv structure (Andi Shyti) - Use proper parameter naming in for_each_engine() (Andi Shyti) - Use gt_err for GT info (Tejas Upadhyay) - Consolidate duplicated capture list code (John Harrison) - Capture list naming clean up (John Harrison) - Use kernel-doc -Werror when CONFIG_DRM_I915_WERROR=y (Jani Nikula) - Preparation for using PAT index (Fei Yang) - Use pat_index instead of cache_level (Fei Yang) Miscellaneous: - Fix memory leaks in i915 selftests (Cong Liu) - Record GT error for gt failure (Tejas Upadhyay) - Migrate platform-dependent mock hugepage selftests to live (Jonathan Cavitt) - Update the SLPC selftest (Vinay Belgaumkar) - Throw out set() wrapper (Jani Nikula) - Large driver kernel doc cleanup (Jani Nikula) - Fix probe injection CI failures after recent change (John Harrison) - Make unexpected firmware versions an error in debug builds (John Harrison) - Silence UBSAN uninitialized bool variable warning (Ashutosh Dixit) - Fix memory leaks in function live_nop_switch (Cong Liu) Merges: - Merge drm/drm-next into drm-intel-gt-next (Joonas Lahtinen) Signed-off-by: Dave Airlie <airlied@redhat.com> # Conflicts: # drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZG5SxCWRSkZhTDtY@tursulin-desk
2023-05-26drm/i915/gsc: use system include style for drm headersJani Nikula
Use <> instead of "" for including headers from include/. Fixes: 8a9bf29546a1 ("drm/i915/gsc: add initial support for GSC proxy") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230525094942.941123-1-jani.nikula@intel.com
2023-05-22drm/i915/pmu: Transform PMU parking code to be GT basedTvrtko Ursulin
Trivial prep work for full multi-tile enablement later. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230519154946.3751971-5-umesh.nerlige.ramappa@intel.com
2023-05-18drm/i915/mtl: Extend Wa_16014892111 to MTL A-stepRadhakrishna Sripada
Like DG2, MTL a-step hardware is subject to Wa_16014892111 which requires that any changes made to the DRAW_WATERMARK register be done via an INDIRECT_CTX batch buffer rather than through a regular context workaround. The bspec gives the same non-default recommended tuning value for DRAW_WATERMARK as DG2, so we can re-use the INDIRECT_CTX code to apply that tuning setting on A-step hardware. Application of the tuning setting on B-step and later does not need INDIRECT_CTX handling and is already done in mtl_ctx_workarounds_init() as usual. v2: Limit the WA for A-step v3: Update the commit message. v4: Reorder platform checks and update commit message. Bspec: 68331 Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230517233111.297542-2-radhakrishna.sripada@intel.com
2023-05-18drm/i915/mtl: Add MTL performance tuning changesRadhakrishna Sripada
MTL reuses the tuning parameters for DG2. Extend the dg2 performance tuning parameters to MTL. v2: Add DRAW_WATERMARK tuning parameter. v3: Limit DRAW_WATERMARK tuning to non A0 step. v4: Reorder platform checks. Restrict Blend fill caching optimization to Render GT. v5: Move mtl tuning params to its own function Bspec: 68331 Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230517233111.297542-1-radhakrishna.sripada@intel.com
2023-05-18drm/i915/mtl: do not enable render power-gating on MTLAndrzej Hajda
Multiple CI tests fails with forcewake ack timeouts if render power gating is enabled. BSpec 52698 states it should be 0 for MTL, but apparently this info is outdated. Anyway since the patch makes MTL pass basic tests added FIXME tag informing this is temporary workaround. v2: added FIXME tag Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230517-mtl_disable_render_pg-v2-1-0b51180a43f0@intel.com
2023-05-17drm/i915/guc/slpc: Disable rps_boost debugfsVinay Belgaumkar
rps_boost debugfs shows host turbo related info. This is not valid when SLPC is enabled. guc_slpc_info already shows the number of boosts. Add num_waiters there as well and disable rps_boost when SLPC is enabled. v2: Replace Bug with Link to resolve checkpatch warning Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7632 Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230516154905.1048006-1-vinay.belgaumkar@intel.com
2023-05-17Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Backmerge to get some hwmon dependencies. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-05-16drm/i915/guc: Dump error capture to dmesg on CTB errorJohn Harrison
In the past, There have been sporadic CTB failures which proved hard to reproduce manually. The most effective solution was to dump the GuC log at the point of failure and let the CI system do the repro. It is preferable not to dump the GuC log via dmesg for all issues as it is not always necessary and is not helpful for end users. But rather than trying to re-invent the code to do this each time it is wanted, commit the code but for DEBUG_GUC builds only. v2: Use IS_ENABLED for testing config options. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418181744.3251240-3-John.C.Harrison@Intel.com
2023-05-16drm/i915/irq: split out display irq handlingJani Nikula
Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-3-jani.nikula@intel.com
2023-05-15drm/i915/hwmon: Silence UBSAN uninitialized bool variable warningAshutosh Dixit
Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL) causes the following warning: UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2 load of value 255 is not a valid value for type '_Bool' Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_load_invalid_value.cold+0x43/0x48 __uc_init_hw+0x76a/0x903 [i915] ... i915_driver_probe+0xfb1/0x1eb0 [i915] i915_pci_probe+0xbe/0x2d0 [i915] The warning happens because during probe i915_hwmon is still not available which results in the output boolean variable *old remaining uninitialized. Silence the warning by initializing the variable to an arbitrary value. v2: Move variable initialization to the declaration (Andi) Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512203735.2635237-1-ashutosh.dixit@intel.com
2023-05-12drm/i915/guc: Fix confused register capture list creationJohn Harrison
The GuC has a completely separate engine class enum when referring to register capture lists, which combines render and compute. The driver was using the 'normal' GuC specific engine class enum instead. That meant that it thought it was defining a capture list for compute engines, the list was actually being applied to the GSC engine. And if a platform didn't have a render engine, then it would get no compute register captures at all. Fix that. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512013544.3367606-1-John.C.Harrison@Intel.com
2023-05-12drm/i1915/guc: Fix probe injection CI failures after recent changeJohn Harrison
A recent change bumped a 'notice' message up to 'error' level for debug builds to help trap incorrect configurations in CI systems. Unfortunately, the error condition in question is triggered by the error injection probe test. So change the message again to be 'probe error' level instead. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Fixes: 760133d42f0a ("drm/i915/uc: Make unexpected firmware versions an error in debug builds") Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230510205556.312999-1-John.C.Harrison@Intel.com
2023-05-12drm/i915/gt: drop dependency on VLV_DISPLAY_BASEJani Nikula
CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV display base area. Add VLV_GUNIT_BASE to drop dependency on VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in intel_gt_regs.h. v2: Add VLV_GUNIT_BASE (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230511152153.986676-1-jani.nikula@intel.com
2023-05-11drm/i915/pxp: Add GSC-CS backend to send GSC fw messagesAlan Previn
Add GSC engine based method for sending PXP firmware packets to the GSC firmware for MTL (and future) products. Use the newly added helpers to populate the GSC-CS memory header and send the message packet to the FW by dispatching the GSC_HECI_CMD_PKT instruction on the GSC engine. We use non-priveleged batches for submission to GSC engine which require two buffers for the request: - a buffer for the HECI packet that contains PXP FW commands - a batch-buffer that contains the engine instruction for sending the HECI packet to the GSC firmware. Thus, add the allocation and freeing of these buffers in gsccs init and fini. The GSC-fw may reply to commands with a SUCCESS but with an additional pending-bit set in the reply packet. This bit means the GSC-FW is currently busy and the caller needs to try again with the gsc_message_handle the fw returned. Thus, add a wrapper to continuously retry send_message while replaying the gsc_message_handle. Retries need to follow the arch-spec count and delay until GSC-FW replies with the real SUCCESS or timeout after that spec'd delay. The GSC-fw requires a non-zero host_session_handle provided by the caller to enable gsc_message_handle tracking. Thus, allocate the host_session_handle at init and destroy it at fini (the latter requiring an FYI to the gsc-firmware). Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230511231738.1077674-5-alan.previn.teres.alexis@intel.com
2023-05-11drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSCAlan Previn
Add helper functions into a new file for heci-packet-submission. The helpers will handle generating the MTL GSC-CS Memory-Header and submission of the Heci-Cmd-Packet instructions to the engine. NOTE1: These common functions for heci-packet-submission will be used by different i915 callers: 1- GSC-SW-Proxy: This is pending upstream publication awaiting a few remaining opens 2- MTL-HDCP: An equivalent patch has also been published at: https://patchwork.freedesktop.org/series/111876/. (Patch 1) 3- PXP: This series. NOTE2: A difference in this patch vs what is appearing is in bullet 2 above is that HDCP (and SW-Proxy) will be using priveleged submission (GGTT and common gsc-uc-context) while PXP will be using non-priveleged PPGTT, context and batch buffer. Therefore this patch will only slightly overlap with the MTL-HDCP patches despite have very similar function names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT instructions require different flows and hw-specific code when done via PPGTT based submission (not different from other engines). MTL-HDCP contains the same intel_gsc_mtl_header_t structures as this but the helpers there are different. Both add the same new file names. NOTE3: Additional clarity about the heci-cmd-pkt layout and where the common helpers come in: - On MTL, when an i915 subsystem needs to send a command request to the security firmware, it will send that via the GSC- engine-command-streamer. - However those commands, (lets call them "gsc_specific_fw_api" calls), are not understood by the GSC command streamer hw. - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and passes it along to the GSC firmware. - The GSC FW on the other hand needs additional metadata to know which usage service is being called (PXP, HDCP, proxy, etc) along with session specific info. Thus an extra header called GSC-CS HECI Memory Header, (C) in below diagram is prepended before the FW specific API, (D). - Thus, the structural layout of the request submitted would need to look like the diagram below (for non-priv PXP). - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header) will populate blob (C) while additional helpers, different for PPGGTT (this patch) vs GGTT (HDCP series) will populate blobs (A) and (B) below. ___________________________________________________________ (A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) | | | | | _|________________________________________________ | | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in, | | | | pkt-addr-out, pkt-size-out) |-------- | | MI_BATCH_BUFFER_END | | | | |________________________________________________| | | | | | |_________________________________________________________| | | --------------------------------------------------------- | \|/ ______V___________________________________________ | _________________________________________ | |(C)| | | | | struct intel_gsc_mtl_header { | | | | validity marker | | | | heci_clent_id | | | | ... | | | | } | | | |_______________________________________| | |(D)| | | | | struct gsc_fw_specific_api_foobar { | | | | ... | | | | For an example, see | | | | 'struct pxp43_create_arb_in' at | | | | intel_pxp_cmd_interface_43.h | | | | | | | | } | | | | Struture depends on command type | | | | struct gsc_fw_specific_api_foobar { | | | |_______________________________________| | |________________________________________________| That said, this patch provides basic helpers but leaves the PXP subsystem (i.e. the caller) to handle (D) and everything else such as input/output size verification or handling the responses from security firmware (for example, requiring a retry). Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230511231738.1077674-4-alan.previn.teres.alexis@intel.com
2023-05-11drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operationAlan Previn
Add MTL hw-plumbing enabling for KCR operation under PXP which includes: 1. Updating 'pick-gt' to get the media tile for KCR interrupt handling 2. Adding MTL's KCR registers for PXP operation (init, status-checking, etc.). While doing #2, lets create a separate registers header file for PXP to be consistent with other i915 global subsystems. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230511231738.1077674-3-alan.previn.teres.alexis@intel.com
2023-05-11drm/i915: use pat_index instead of cache_levelFei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls the caching behavior in PTE has far more levels than what's defined in the enum. In addition, the PAT index is platform dependent, having to translate between i915_cache_level and PAT index is not reliable, and makes the code more complicated. From UMD's perspective there is also a necessity to set caching policy for performance fine tuning. It's much easier for the UMD to directly use PAT index because the behavior of each PAT index is clearly defined in Bspec. Having the abstracted i915_cache_level sitting in between would only cause more ambiguity. PAT is expected to work much like MOCS already works today, and by design userspace is expected to select the index that exactly matches the desired behavior described in the hardware specification. For these reasons this patch replaces i915_cache_level with PAT index. Also note, the cache_level is not completely removed yet, because the KMD still has the need of creating buffer objects with simple cache settings such as cached, uncached, or writethrough. For kernel objects, cache_level is used for simplicity and backward compatibility. For Pre-gen12 platforms PAT can have 1:1 mapping to i915_cache_level, so these two are interchangeable. see the use of LEGACY_CACHELEVEL. One consequence of this change is that gen8_pte_encode is no longer working for gen12 platforms due to the fact that gen12 platforms has different PAT definitions. In the meantime the mtl_pte_encode introduced specfically for MTL becomes generic for all gen12 platforms. This patch renames the MTL PTE encode function into gen12_pte_encode and apply it to all gen12. Even though this change looks unrelated, but separating them would temporarily break gen12 PTE encoding, thus squash them in one patch. Special note: this patch changes the way caching behavior is controlled in the sense that some objects are left to be managed by userspace. For such objects we need to be careful not to change the userspace settings.There are kerneldoc and comments added around obj->cache_coherent, cache_dirty, and how to bypass the checkings by i915_gem_object_has_cache_level. For full understanding, these changes need to be looked at together with the two follow-up patches, one disables the {set|get}_caching ioctl's and the other adds set_pat extension to the GEM_CREATE uAPI. Bspec: 63019 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-11drm/i915: preparation for using PAT indexFei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT index. Caching policy for buffer objects is set through the PAT index in PTE, the old i915_cache_level is not sufficient to represent all caching modes supported by the hardware. Preparing the transition by adding some platform dependent data structures and helper functions to translate the cache_level to pat_index. cachelevel_to_pat: a platform dependent array mapping cache_level to pat_index. max_pat_index: the maximum PAT index recommended in hardware specification Needed for validating the PAT index passed in from user space. i915_gem_get_pat_index: function to convert cache_level to PAT index. obj_to_i915(obj): macro moved to header file for wider usage. I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the convenience of coding. Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-2-fei.yang@intel.com
2023-05-11drm/i915/guc: Don't capture Gen8 regs on Xe devicesJohn Harrison
A pair of pre-Xe registers were being included in the Xe capture list. GuC was rejecting those as being invalid and logging errors about them. So, stop doing it. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state capture.") Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428185636.457407-2-John.C.Harrison@Intel.com (cherry picked from commit b049132d61336f643d8faf2f6574b063667088cf) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2023-05-08drm/i915/mtl: Fix the wa number for Wa_22016670082Radhakrishna Sripada
Fixes the right lineage number for the workaround. Fixes: a7fa1537b791 ("drm/i915/mtl: Implement Wa_14019141245") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230505234544.4029535-1-radhakrishna.sripada@intel.com
2023-05-08drm/i915/mtl: Drop FLAT CCS checkPallavi Mishra
Remove FLAT CCS check from XY_FAST_COLOR_BLT usage, thus enabling MTL to use it. Signed-off-by: Pallavi Mishra <pallavi.mishra@intel.com> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230505144005.23480-1-nirmoy.das@intel.com
2023-05-05drm/i915/uc: Make unexpected firmware versions an error in debug buildsJohn Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected firmware version' message from a notice to an error. This will ensure that the CI system treats such occurences as a failure and logs a bug about it (or fails the pre-merge testing). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502234007.1762014-7-John.C.Harrison@Intel.com
2023-05-05drm/i915/uc: Reject duplicate entries in firmware tableJohn Harrison
It was noticed that duplicate entries in the firmware table could cause an infinite loop in the firmware loading code if that entry failed to load. Duplicate entries are a bug anyway and so should never happen. Ensure they don't by tweaking the table validation code to reject duplicates. For full m/m/p files, that can be done by simply tweaking the patch level check to reject matching values. For reduced version entries, the filename itself must be compared. v2: Improve comment (review by Daniele) Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502234007.1762014-6-John.C.Harrison@Intel.com
2023-05-05drm/i915/uc: Enhancements to firmware table validationJohn Harrison
The validation of the firmware table was being done inside the code for scanning the table for the next available firmware blob. Which is unnecessary. So pull it out into a separate function that is only called once per blob type at init time. Also, drop the CONFIG_SELFTEST requirement and make errors terminal. It was mentioned that potential issues with backports would not be caught by regular pre-merge CI as that only occurs on tip not stable branches. Making the validation unconditional and failing driver load on detecting of a problem ensures that such backports will also be validated correctly. This requires adding a firmware global flag to indicate an issue with any of the per firmware tables. This is done rather than adding a new state enum as a new enum value would be a much more invasive change - lots of places would need updating to support the new error state. Note also that this change means that a table error will cause the driver to wedge even on platforms that don't require firmware files. This is intentional as per the above backport concern - someone doing backports is not guaranteed to test on every platform that they may potential affect. So forcing a failure on all platforms ensures that the problem will be noticed and corrected immediately. v2: Change to unconditionally fail module load on a validation error (review feedback/discussion with Daniele). v3: Add a new flag to track table validation errors (review feedback/discussion with Daniele). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502234007.1762014-5-John.C.Harrison@Intel.com
2023-05-05drm/i915/guc: Print status register when waiting for GuC to loadJohn Harrison
If the GuC load is taking an excessively long time, the wait loop currently prints the GT frequency. Extend that to include the GuC status as well so we can see if the GuC is actually making progress or not. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502234007.1762014-3-John.C.Harrison@Intel.com
2023-05-05drm/i915/guc: Decode another GuC load failure caseJohn Harrison
Explain another potential firmware failure mode and early exit the long wait if hit. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502234007.1762014-2-John.C.Harrison@Intel.com
2023-05-05Merge tag 'drm-next-2023-05-05' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull more drm fixes from Dave Airlie: "This is the fixes for the last couple of weeks for i915 and last 3 weeks for amdgpu, lots of them but pretty scattered around and all pretty small. amdgpu: - SR-IOV fixes - DCN 3.2 fixes - DC mclk handling fixes - eDP fixes - SubVP fixes - HDCP regression fix - DSC fixes - DC FP fixes - DCN 3.x fixes - Display flickering fix when switching between vram and gtt - Z8 power saving fix - Fix hang when skipping modeset - GPU reset fixes - Doorbell fix when resizing BARs - Fix spurious warnings in gmc - Locking fix for AMDGPU_SCHED IOCTL - SR-IOV fix - DCN 3.1.4 fix - DCN 3.2 fix - Fix job cleanup when CS is aborted i915: - skl pipe source size check - mtl transcoder mask fix - DSI power on sequence fix - GuC versioning corner case fix" * tag 'drm-next-2023-05-05' of git://anongit.freedesktop.org/drm/drm: (48 commits) drm/amdgpu: drop redundant sched job cleanup when cs is aborted drm/amd/display: filter out invalid bits in pipe_fuses drm/amd/display: Change default Z8 watermark values drm/amdgpu: disable SDMA WPTR_POLL_ENABLE for SR-IOV drm/amdgpu: add a missing lock for AMDGPU_SCHED drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini() drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini drm/amdgpu: Enable doorbell selfring after resize FB BAR drm/amdgpu: Use the default reset when loading or reloading the driver drm/amdgpu: Fix mode2 reset for sienna cichlid drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info drm/i915/guc: Actually return an error if GuC version range check fails drm/amd/display: Lowering min Z8 residency time drm/amd/display: fix flickering caused by S/G mode drm/amd/display: Set min_width and min_height capability for DCN30 drm/amd/display: Isolate remaining FPU code in DCN32 drm/amd/display: Update bounding box values for DCN321 drm/amd/display: Do not clear GPINT register when releasing DMUB from reset ...
2023-05-05drm/i915/mtl: Define GuC firmware version for MTLJohn Harrison
First release of GuC for Meteorlake. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230504202252.1104212-3-John.C.Harrison@Intel.com
2023-05-05drm/i915/uc: Track patch level versions on reduced version firmware filesJohn Harrison
When reduced version firmware files were added (matching major component being the only strict requirement), the minor version was still tracked and a notification reported if it was older. However, the patch version should really be tracked as well for the same reasons. The KMD can work without the change but if the effort has been taken to release a new firmware with the change then there must be a valid reason for doing so - important bug fix, security fix, etc. And in that case it would be good to alert the user if they are missing out on that new fix. v2: Use correct patch version number and drop redunant debug print (review by Daniele / CI results). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230504202252.1104212-2-John.C.Harrison@Intel.com
2023-05-04drm/i915/gsc: add support for GSC proxy interruptDaniele Ceraolo Spurio
The GSC notifies us of a proxy request via the HECI2 interrupt. The interrupt must be enabled both in the HECI layer and in our usual gt irq programming; for the latter, the interrupt is enabled via the same enable register as the GSC CS, but it does have its own mask register. When the interrupt is received, we also need to de-assert it in both layers. The handling of the proxy request is deferred to the same worker that we use for GSC load. New flags have been added to distinguish between the init case and the proxy interrupt. v2: Make sure not to set the reset bit when enabling/disabling the GSC interrupts, fix defines (Alan) v3: rebase on proxy status register check Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502163854.317653-5-daniele.ceraolospurio@intel.com
2023-05-04drm/i915/gsc: add initial support for GSC proxyDaniele Ceraolo Spurio
The GSC uC needs to communicate with the CSME to perform certain operations. Since the GSC can't perform this communication directly on platforms where it is integrated in GT, i915 needs to transfer the messages from GSC to CSME and back. The proxy flow is as follow: 1 - i915 submits a request to GSC asking for the message to CSME 2 - GSC replies with the proxy header + payload for CSME 3 - i915 sends the reply from GSC as-is to CSME via the mei proxy component 4 - CSME replies with the proxy header + payload for GSC 5 - i915 submits a request to GSC with the reply from CSME 6 - GSC replies either with a new header + payload (same as step 2, so we restart from there) or with an end message. After GSC load, i915 is expected to start the first proxy message chain, while all subsequent ones will be triggered by the GSC via interrupt. To communicate with the CSME, we use a dedicated mei component, which means that we need to wait for it to bind before we can initialize the proxies. This usually happens quite fast, but given that there is a chance that we'll have to wait a few seconds the GSC work has been moved to a dedicated WQ to not stall other processes. v2: fix code style, includes and variable naming (Alan) v3: add extra check for proxy status, fix includes and comments Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502163854.317653-4-daniele.ceraolospurio@intel.com
2023-05-04drm/i915/guc: add intel_guc_state_capture member docs for ads_null_cache and ↵Jani Nikula
max_mmio_per_node drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'ads_null_cache' not described in 'intel_guc_state_capture' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'max_mmio_per_node' not described in 'intel_guc_state_capture' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c83878163221ed3684a6de5d5e1c5373ddd5c06f.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/guc: drop lots of kernel-doc markersJani Nikula
The documentation is closer to not being kernel-doc, so just drop the kernel-doc markers. drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'size' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'data' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'rd' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'wr' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'link' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'is_partial' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_class' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_inst' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'guc_id' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'lrca' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'reginfo' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: * struct guc_debug_capture_list_header / struct guc_debug_capture_list drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:80: warning: wrong kernel-doc identifier on line: * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:105: warning: wrong kernel-doc identifier on line: * struct guc_state_capture_header_t / struct guc_state_capture_t / drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'is_valid' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'ptr' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'size' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'status' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'marker' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'read_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'write_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'size' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'sampled_write_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'wrap_offset' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flush_to_file' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'buffer_full_cnt' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'reserved' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flags' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'version' not described in 'guc_log_buffer_state' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9c210d53fdbd6da5fac42e435855d269504919d7.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/guc: add dbgfs_node member kernel-docJani Nikula
drivers/gpu/drm/i915/gt/uc/intel_guc.h:274: warning: Function parameter or member 'dbgfs_node' not described in 'intel_guc' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0f681dd82289dd86da78c6242411e8d812e51a1.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/engine: hide preempt_hang selftest member from kernel-docJani Nikula
drivers/gpu/drm/i915/gt/intel_engine_types.h:293: warning: Function parameter or member 'preempt_hang' not described in 'intel_engine_execlists' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/dafd771bb75cf14965dd3b666987c58a438de134.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/gtt: fix i915_vm_resv_put() kernel-doc parameter nameJani Nikula
drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Function parameter or member 'vm' not described in 'i915_vm_resv_put' drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Excess function parameter 'resv' description in 'i915_vm_resv_put' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c22e58e770019667980b3617f6e963b76d7e79a7.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/context: fix kernel-doc parameter descriptionsJani Nikula
drivers/gpu/drm/i915/gt/intel_context.h:108: warning: Function parameter or member 'ce' not described in 'intel_context_lock_pinned' drivers/gpu/drm/i915/gt/intel_context.h:123: warning: Function parameter or member 'ce' not described in 'intel_context_is_pinned' drivers/gpu/drm/i915/gt/intel_context.h:142: warning: Function parameter or member 'ce' not described in 'intel_context_unlock_pinned' Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8359a1cef6b5ab268a9dcc1a382281b6e39cfa64.1683041799.git.jani.nikula@intel.com
2023-05-04drm/i915/engine: fix kernel-doc function name for intel_engine_cleanup_common()Jani Nikula
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1525: warning: expecting prototype for intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() instead Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/33f8dfdf38be3e16675971e6983e3e300d4301a6.1683041799.git.jani.nikula@intel.com
2023-05-03drm/i915/guc: Fix error capture for virtual enginesJohn Harrison
GuC based register dumps in error capture logs were basically broken for virtual engines. This can be seen in igt@gem_exec_balancer@hang: [IGT] gem_exec_balancer: starting subtest hang [drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388] [drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D [drm] GPU HANG: ecode 12:4:00000000, in gem_exec_balanc [6388] [IGT] gem_exec_balancer: exiting, ret=0 The test causes a hang on both engines of a virtual engine context. The engine instance zero hang gets a valid error capture but the non-instance-zero hang does not. Fix that by scanning through the list of pending register captures when a hang notification for a virtual engine is received. That way, the hang can be assigned to the correct physical engine prior to starting the error capture process. So later on, when the error capture handler tries to find the engine register list, it looks for one on the correct engine. Also, sneak in a missing blank line before a comment in the node search code. v2: Fix null pointer deref on non-GuC platforms. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428185636.457407-5-John.C.Harrison@Intel.com
2023-05-03drm/i915/guc: Capture list naming clean upJohn Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with Gen8. Don't add Xe only GSC registers to pre-Xe devices that don't even have a GSC engine. Fix Xe_LP name. Don't use GEN9 as a prefix for register lists that contain all GEN8 registers. Rename the 'default_' register list prefix to 'gen8_' as that is the more accurate name. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428185636.457407-4-John.C.Harrison@Intel.com