[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes towards v6.12-rc5. Just one Kconfig fix for GVT. Regards, Joonas *** drm-intel-fixes-2024-10-24: - Fix DRM_I915_GVT_KVMGT dependencies in Kconfig The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924: Linux 6.12-rc4 (2024-10-20 15:19:38 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-10-24 for you to fetch changes up to 338b655a1178900ac05aca7ac66dc28b05100430: i915: fix DRM_I915_GVT_KVMGT dependencies (2024-10-21 09:51:05 +0300) - Fix DRM_I915_GVT_KVMGT dependencies in Kconfig Arnd Bergmann (1): i915: fix DRM_I915_GVT_KVMGT dependencies drivers/gpu/drm/i915/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes towards v6.12-rc4. Just two DP MST fixes this round. Regards, Joonas *** drm-intel-fixes-2024-10-17: - Two DP bandwidth related MST fixes The following changes since commit 8e929cb546ee42c9a61d24fae60605e9e3192354: Linux 6.12-rc3 (2024-10-13 14:33:32 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-10-17 for you to fetch changes up to 2f54e71359eb2abc0bdf6619cd356e5e350ff27b: drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible mode (2024-10-16 14:56:40 +0300) - Two DP bandwidth related MST fixes Imre Deak (2): drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible mode drivers/gpu/drm/i915/display/intel_dp_mst.c | 40 + 1 file changed, 30 insertions(+), 10 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes PR towards v6.12-rc3. Just one HDCP refcount fix. Regards, Joonas drm-intel-fixes-2024-10-10: - HDCP refcount fix The following changes since commit 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b: Linux 6.12-rc2 (2024-10-06 15:32:27 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-10-10 for you to fetch changes up to 4cc2718f621a6a57a02581125bb6d914ce74d23b: drm/i915/hdcp: fix connector refcounting (2024-10-07 06:18:46 +0300) - HDCP refcount fix Jani Nikula (1): drm/i915/hdcp: fix connector refcounting drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes toward v6.12-rc2. Just one & vs && fixup into PM code that should only trigger with debug Kconfig options. Regards, Joonas *** drm-intel-fixes-2024-10-02: - One fix for bitwise and logical "and" mixup in PM code The following changes since commit 9852d85ec9d492ebef56dc5f229416c925758edc: Linux 6.12-rc1 (2024-09-29 15:06:19 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-10-02 for you to fetch changes up to 394b52462020b6cceff1f7f47fdebd03589574f3: drm/i915/gem: fix bitwise and logical AND mixup (2024-10-01 10:28:29 +0300) - One fix for bitwise and logical "and" mixup in PM code Jani Nikula (1): drm/i915/gem: fix bitwise and logical AND mixup drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PULL] drm-intel-next-fixes
Hi Dave & Sima, Here goes final drm-intel-next-fixes towards v6.12. Just one fix for DP colorimetry detection. Regards, Joonas *** drm-intel-next-fixes-2024-09-26: - Fix colorimetry detection for DP The following changes since commit d7126c0cfc137a580eba92bd82b6d288bd43961d: Merge tag 'drm-xe-next-fixes-2024-09-19' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next (2024-09-25 12:11:10 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-next-fixes-2024-09-26 for you to fetch changes up to e860513f56d8428fcb2bd0282ac8ab691a53fc6c: drm/i915/dp: Fix colorimetry detection (2024-09-25 11:56:23 +0300) - Fix colorimetry detection for DP Ville Syrjälä (1): drm/i915/dp: Fix colorimetry detection drivers/gpu/drm/i915/display/intel_dp.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Sima, Here goes drm-intel-next-fixes PR towards 6.12. Three display fixes; One to limit BMG to UHBR13.5 and two PSR ones. Regards, Joonas *** drm-intel-next-fixes-2024-09-19: - Fix BMG support to UHBR13.5 - Two PSR fixes The following changes since commit bf05aeac230e390a5aee4bd3dc978b0c4d7e745f: Merge tag 'drm-intel-next-fixes-2024-09-12' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next (2024-09-13 16:26:05 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-next-fixes-2024-09-19 for you to fetch changes up to ec2231b8dd2dc515912ff7816c420153b4a95e92: drm/i915/dp: Fix AUX IO power enabling for eDP PSR (2024-09-16 09:11:48 +0300) - Fix BMG support to UHBR13.5 - Two PSR fixes Arun R Murthy (1): drm/i915/display: BMG supports UHBR13.5 Imre Deak (1): drm/i915/dp: Fix AUX IO power enabling for eDP PSR Jouni Högander (1): drm/i915/psr: Do not wait for PSR being idle on on Panel Replay drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_dp.c | 13 +++-- drivers/gpu/drm/i915/display/intel_psr.c | 32 +--- drivers/gpu/drm/i915/display/intel_psr.h | 2 ++ 4 files changed, 35 insertions(+), 14 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Sima, Just two fixes this week in drm-intel-next-fixes towards v6.12-rc1. CI baseline is bit upset afted drm-next, but not getting worse with the two patches at least. Regards, Joonas *** drm-intel-next-fixes-2024-09-12: - Add missing I915_FORMAT_MOD_4_TILED_BMG_CCS modifier for BMG - Printk formatting fix The following changes since commit 741d73f587d5cc86db5e65cc107e031263302616: Merge tag 'amd-drm-next-6.12-2024-09-06' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2024-09-11 11:22:47 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-next-fixes-2024-09-12 for you to fetch changes up to 0289507609dcb7690e45e79fbcc3680d9298ec77: drm/i915/bios: fix printk format width (2024-09-11 11:01:00 +0300) - Add missing I915_FORMAT_MOD_4_TILED_BMG_CCS modifier for BMG - Printk formatting fix Jani Nikula (1): drm/i915/bios: fix printk format width Juha-Pekka Heikkila (1): drm/i915/display: Fix BMG CCS modifiers drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
[PULL] drm-intel-gt-next
Hi Dave & Sima, Here goes the final drm-intel-gt-next towards 6.12. Primarily addition of fan speed hwmon, W/A fixups for ARL, add missing register for userspace into DG2/MTL/ARL. Then a few smaller fixes. Regards, Joonas *** drm-intel-gt-next-2024-09-06: Driver Changes: - Expose fan speed via hwmon (Raag) - Correction to Wa_14019159160 on ARL (John H) - Whitelist COMMON_SLICE_CHICKEN1 for UMD access on DG2/MTL/ARL (Dnyaneshwar) - Do not attempt to load the GSC multiple times to avoid hanging GSC HW (Daniele) - Populate /sys/class/drm/cardX/engines/ even if one engine fails (Andi) - Use kmemdup_array instead of kmemdup for multiple allocation (Yu) - Remove extra unlikely() (Hongbo) The following changes since commit 255fc1703e42321b5afdedc8259ad03c7cc533ec: drm/i915/gem: Calculate object page offset for partial memory mapping (2024-08-21 15:28:33 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-gt-next-2024-09-06 for you to fetch changes up to 596a7f1084e49cc65072c458c348861e9b9ceab9: drm/i915: Remove extra unlikely helper (2024-09-05 15:44:37 -0400) Driver Changes: - Expose fan speed via hwmon (Raag) - Correction to Wa_14019159160 on ARL (John H) - Whitelist COMMON_SLICE_CHICKEN1 for UMD access on DG2/MTL/ARL (Dnyaneshwar) - Do not attempt to load the GSC multiple times to avoid hanging GSC HW (Daniele) - Populate /sys/class/drm/cardX/engines/ even if one engine fails (Andi) - Use kmemdup_array instead of kmemdup for multiple allocation (Yu) - Remove extra unlikely() (Hongbo) Andi Shyti (1): drm/i915/gt: Continue creating engine sysfs files even after a failure Daniele Ceraolo Spurio (1): drm/i915: Do not attempt to load the GSC multiple times Dnyaneshwar Bhadane (1): drm/i915/gt: Whitelist COMMON_SLICE_CHICKEN1 for UMD access. Hongbo Li (1): drm/i915: Remove extra unlikely helper John Harrison (1): drm/i915/guc: Fix missing enable of Wa_14019159160 on ARL Raag Jadav (1): drm/i915/hwmon: expose fan speed Yu Jiaoliang (1): drm/i915/gt: Use kmemdup_array instead of kmemdup for multiple allocation .../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h| 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c| 9 +-- drivers/gpu/drm/i915/gt/sysfs_engines.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 5 ++ drivers/gpu/drm/i915/i915_hwmon.c | 88 ++ 9 files changed, 112 insertions(+), 11 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes towards v6.11-rc6. Fix for USB type-C docks, backlight fix for Lenovo Yoga Tab 3 2G version and ARL GuC firmware version correction. Regards, Joonas *** drm-intel-fixes-2024-08-29: - Fix #11195: The external display connect via USB type-C dock stays blank after re-connect the dock - Make DSI backlight work for 2G version of Lenovo Yoga Tab 3 X90F . Move ARL GuC firmware to correct version - The following changes since commit 5be63fc19fcaa4c236b307420483578a56986a37: Linux 6.11-rc5 (2024-08-25 19:07:11 +1200) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-08-29 for you to fetch changes up to a2ccc33b88e2953a6bf0b309e7e8849cc5320018: drm/i915/dp_mst: Fix MST state after a sink reset (2024-08-28 11:32:25 +0300) - Fix #11195: The external display connect via USB type-C dock stays blank after re-connect the dock - Make DSI backlight work for 2G version of Lenovo Yoga Tab 3 X90F . Move ARL GuC firmware to correct version - Hans de Goede (1): drm/i915/dsi: Make Lenovo Yoga Tab 3 X90F DMI match less strict Imre Deak (1): drm/i915/dp_mst: Fix MST state after a sink reset John Harrison (1): drm/i915: ARL requires a newer GSC firmware drivers/gpu/drm/i915/display/intel_dp.c | 12 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 40 + drivers/gpu/drm/i915/display/intel_dp_mst.h | 1 + drivers/gpu/drm/i915/display/vlv_dsi.c | 1 - drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 31 ++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 10 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.c| 7 + drivers/gpu/drm/i915/intel_device_info.h| 3 +++ include/drm/intel/i915_pciids.h | 11 +--- 10 files changed, 111 insertions(+), 7 deletions(-)
[PULL] drm-intel-gt-next
Hi Dave & Sima, Mostly fixes in this drm-intel-gt-next PR at this time. One thing to pay attention is the limitation of number of relocations to INT_MAX which might impact synthetic tests, but no real workloads. Regards, Joonas *** drm-intel-gt-next-2024-08-23: UAPI Changes: - drm/i915: 2 GiB of relocations ought to be enough for anybody* Limit the number of relocations to INT_MAX. Only impact should be onsynthetic tests. Driver Changes: - Fix for #11396: GPU Hang and rcs0 reset on Cherrytrail platform - Fix Virtual Memory mapping boundaries calculation (Andi) - Fix for #11255: Long hangs in buddy allocator with DG2/A380 without Resizable BAR since 6.9 (David) - Mark the GT as dead when mmio is unreliable (Chris, Andi) - Workaround additions / fixes for MTL, ARL and DG2 (John H, Nitin) - Enable partial memory mapping of GPU virtual memory (Andi, Chris) - Prevent NULL deref on intel_memory_regions_hw_probe (Jonathan, Dan) - Avoid UAF on intel_engines_release (Krzysztof) - Don't update PWR_CLK_STATE starting Gen12 (Umesh) - Code and dmesg cleanups (Andi, Jesus, Luca) The following changes since commit 3b85152cb167bd24fe84ceb91b719b5904ca354f: drm/i915/gem: Suppress oom warning in favour of ENOMEM to userspace (2024-06-28 00:11:01 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-gt-next-2024-08-23 for you to fetch changes up to 255fc1703e42321b5afdedc8259ad03c7cc533ec: drm/i915/gem: Calculate object page offset for partial memory mapping (2024-08-21 15:28:33 +0200) UAPI Changes: - Limit the number of relocations to INT_MAX (Tvrtko) Only impact should be synthetic tests. Driver Changes: - Fix for #11396: GPU Hang and rcs0 reset on Cherrytrail platform - Fix Virtual Memory mapping boundaries calculation (Andi) - Fix for #11255: Long hangs in buddy allocator with DG2/A380 without Resizable BAR since 6.9 (David) - Mark the GT as dead when mmio is unreliable (Chris, Andi) - Workaround additions / fixes for MTL, ARL and DG2 (John H, Nitin) - Enable partial memory mapping of GPU virtual memory (Andi, Chris) - Prevent NULL deref on intel_memory_regions_hw_probe (Jonathan, Dan) - Avoid UAF on intel_engines_release (Krzysztof) - Don't update PWR_CLK_STATE starting Gen12 (Umesh) - Code and dmesg cleanups (Andi, Jesus, Luca) Andi Shyti (6): drm/i915/gem: Adjust vma offset for framebuffer mmap offset drm/i915/gem: Fix Virtual Memory mapping boundaries calculation drm/i915/gem: Improve pfn calculation readability in vm_fault_gtt() drm/i915: Replace double blank with single blank after comma in gem/ and gt/ drm/i915/gem: Do not look for the exact address in node drm/i915/gem: Calculate object page offset for partial memory mapping Chris Wilson (1): drm/i915/gt: Mark the GT as dead when mmio is unreliable David Gow (2): drm/i915: Allow evicting to use the requested placement drm/i915: Attempt to get pages without eviction first Jesus Narvaez (1): drm/i915/guc: Change GEM_WARN_ON to guc_err to prevent taints in CI John Harrison (2): drm/i915/arl: Enable Wa_14019159160 for ARL drm/i915/guc: Extend w/a 14019159160 Jonathan Cavitt (1): drm/i915: Allow NULL memory region Krzysztof Niemiec (1): drm/i915/gt: Empty uabi engines list during intel_engines_release() Luca Coelho (1): drm/i915/gt: remove stray declaration of intel_gt_release_all() Nitin Gote (2): drm/i915/gt: Do not consider preemption during execlists_dequeue for gen8 drm/i915/gt: Add Wa_14019789679 Tvrtko Ursulin (1): drm/i915: 2 GiB of relocations ought to be enough for anybody* Umesh Nerlige Ramappa (1): i915/perf: Remove code to update PWR_CLK_STATE for gen12 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 73 +++--- drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 13 ++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 6 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_gt.h | 7 ++- drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/gt/intel_reset.c | 12 +++- drivers/gpu/drm/i915/gt/intel_workarounds.c| 16 - drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +- drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 18 +++--- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i91
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes towards v6.11-rc5. Just one HDCP timeout fix this week. Regards, Joonas *** drm-intel-fixes-2024-08-22: - Fix for HDCP timeouts The following changes since commit 47ac09b91befbb6a235ab620c32af719f8208399: Linux 6.11-rc4 (2024-08-18 13:17:27 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-08-22 for you to fetch changes up to 5d41eeb6725e3e24853629e5d7635e4bc45d736e: drm/i915/hdcp: Use correct cp_irq_count (2024-08-19 06:40:57 +0300) - Fix for HDCP timeouts Suraj Kandpal (1): drm/i915/hdcp: Use correct cp_irq_count drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Re: [PATCH v2 0/2] Fix mmap memory boundary calculation
Quoting Jann Horn (2024-08-09 18:40:45) > On Fri, Aug 9, 2024 at 4:48 PM Jann Horn wrote: > > On Tue, Aug 6, 2024 at 2:08 PM Joonas Lahtinen > > wrote: > > > Quoting Andi Shyti (2024-08-06 12:46:07) > > > > Hi Greg, > > > > > > > > same question without the stable mailing list not to trigger the > > > > automatic reply. > > > > > > > > > Andi Shyti (2): > > > > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > > > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > > > > > > > I have forgotten to actually Cc the stable mailing list here. > > > > These two patches need to be merged together even if only the > > > > second patch has the "Fixes:" tag. > > > > > > > > I could have used the "Requires:" tag, but the commit id would > > > > change in between merges and rebases. > > > > > > The patches were the top two in drm-intel-gt-next and committed > > > only few hours ago so I fixed up the patches adding Cc: stable > > > and Requires: > > > > I'm not very familiar with how the DRM trees work - shouldn't fixes in > > i915 go on the separate drm-intel-fixes branch so that they don't have > > to wait for a merge window? > > Ah, nevermind, I see it is already in drm-intel-fixes. Sorry for the noise. Yeah, the DRM subsystem has a rather specific process. Jann, do you consider the fix released already now that it is in -rc3 or will you start the 30 day count from when 6.11 gets released? I hope the latter, but just want to make sure there are no surprises. Regards, Joonas
Re: [PULL] drm-intel-fixes
Quoting Krzysztof Kozlowski (2024-08-08 21:44:39) > On 08/08/2024 20:35, Krzysztof Kozlowski wrote: > > On 08/08/2024 10:45, Tvrtko Ursulin wrote: > >> > >> Hi Dave, Sima, > >> > >> A small bunch of fixes for the weekly cycle: > > > > ... > > > >> > >> > >> Andi Shyti (2): > >> drm/i915/gem: Adjust vma offset for framebuffer mmap offset > >> drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > >> > >> David Gow (2): > >> drm/i915: Allow evicting to use the requested placement > >> drm/i915: Attempt to get pages without eviction first > >> > >> Dnyaneshwar Bhadane (1): > >> drm/i915/display: correct dual pps handling for MTL_PCH+ > > > > Several commits have issues. Look: > > > > Signed-off-by: Joonas Lahtinen > > Link: https://patchwork.freedesktop.org/patch/msgid ... > > (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) > > Signed-off-by: Joonas Lahtinen > > > > > > 1. Duplicated committer SoB. > > You added SoB. No need to add two. It does not get stronger. You do not > > change the DCO rules by adding two SoBs. You cannot confirm something > > more or twice. Read DCO one more time... Hi Krzysztof, As a self-proclaimed quite active kernel developer (by a quick web search) you might have already ventured to look at the GIT history of the subsytem tree for the patch in question. If you did that, you might have implied that the second S-o-b is added by automation -- and it indeed is. While appreciating the report, maybe not so much the the condescending style of the communication. You now slightly come through as a troll hoping to be fed - I hope that is not the case. Seems like we've had such a double S-o-b regularly generated by DIM (Drm Inglorious Maintainer scripts) at least since 2016 as the first occurrance seems to have been in ccda3a728f70 . So rest of the ecosystem seems to deal with them just fine. Is the double S-o-b issue purely cosmetic for you? Not a lawyer but I don't think there is any legal problem in stating the same thing twice. [1] Or are you maybe running into some more concrete issues with upstream kernel process related scripts or other automation processing of the commit? Regards, Joonas [1] When it comes to the commit rights model in DRM subsystem, stripping the final S-o-b after the cherry-pick would make it less obvious who did the pick. If there are multiple S-o-bs and the cherry-picking person happened to be one of them, that information would be lost. Less predictable outcome for the patch form for no actual gain in my opinion. On the other hand, removing the S-o-b line from above the "(cherry-picked.." line would modify the cherry-picked commit description itself and I would assume everyone agrees that should not be done.
Re: [PATCH] drm/i915: 2 GiB of relocations ought to be enough for anybody*
Quoting Tvrtko Ursulin (2024-05-21 13:12:01)
> From: Tvrtko Ursulin
>
> Kernel test robot reports i915 can hit a warn in kvmalloc_node which has
> a purpose of dissalowing crazy size kernel allocations. This was added in
> 7661809d493b ("mm: don't allow oversized kvmalloc() calls"):
>
>/* Don't even allow crazy sizes */
>if (WARN_ON_ONCE(size > INT_MAX))
>return NULL;
>
> This would be kind of okay since i915 at one point dropped the need for
> making a shadow copy of the relocation list, but then it got re-added in
> fd1500fcd442 ("Revert "drm/i915/gem: Drop relocation slowpath".") a year
> after Linus added the above warning.
>
> It is plausible that the issue was not seen until now because to trigger
> gem_exec_reloc test requires a combination of an relatively older
> generation hardware but with at least 8GiB of RAM installed. Probably even
> more depending on runtime checks.
>
> Lets cap what we allow userspace to pass in using the matching limit.
> There should be no issue for real userspace since we are talking about
> "crazy" number of relocations which have no practical purpose.
>
> *) Well IGT tests might get upset but they can be easily adjusted.
>
> Signed-off-by: Tvrtko Ursulin
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-lkp/202405151008.6ddd1aaf-oliver.s...@intel.com
> Cc: Kees Cook
> Cc: Kent Overstreet
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d3a771afb083..4b34bf4fde77 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1533,7 +1533,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
> struct eb_vma *ev)
> u64_to_user_ptr(entry->relocs_ptr);
> unsigned long remain = entry->relocation_count;
>
> - if (unlikely(remain > N_RELOC(ULONG_MAX)))
> + if (unlikely(remain > N_RELOC(INT_MAX)))
> return -EINVAL;
Yeah, nobody will realistically need that many relocations.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
>
> /*
> @@ -1641,7 +1641,7 @@ static int check_relocations(const struct
> drm_i915_gem_exec_object2 *entry)
> if (size == 0)
> return 0;
>
> - if (size > N_RELOC(ULONG_MAX))
> + if (size > N_RELOC(INT_MAX))
> return -EINVAL;
>
> addr = u64_to_user_ptr(entry->relocs_ptr);
> --
> 2.44.0
>
Re: [PATCH v2 0/2] Fix mmap memory boundary calculation
Quoting Andi Shyti (2024-08-06 12:46:07) > Hi Greg, > > same question without the stable mailing list not to trigger the > automatic reply. > > > Andi Shyti (2): > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > I have forgotten to actually Cc the stable mailing list here. > These two patches need to be merged together even if only the > second patch has the "Fixes:" tag. > > I could have used the "Requires:" tag, but the commit id would > change in between merges and rebases. The patches were the top two in drm-intel-gt-next and committed only few hours ago so I fixed up the patches adding Cc: stable and Requires: Regards, Joonas > > Is there anything I should still do here? Do you want me to > take care and send the backports for kernels starting from 4.19? > > Thanks, > Andi
[PULL] drm-intel-fixes
Hi Dave & Sima, Just three smaller fixups. CI is again all over the place after -rc1, but below changes shouldn't make it any worse. Regards, Joonas *** drm-intel-fixes-2024-08-01: - Static analysis fix for int overflow - Fix for HDCP2_STREAM_STATUS macro and removal of PWR_CLK_STATE for gen12 The following changes since commit 8400291e289ee6b2bf9779ff1c83a291501f017b: Linux 6.11-rc1 (2024-07-28 14:19:55 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-08-01 for you to fetch changes up to 5b511572660190db1dc8ba412efd0be0d3781ab6: drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll() (2024-07-30 16:57:24 +0300) - Static analysis fix for int overflow - Fix for HDCP2_STREAM_STATUS macro and removal of PWR_CLK_STATE for gen12 Nikita Zhandarovich (1): drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll() Suraj Kandpal (1): drm/i915/hdcp: Fix HDCP2_STREAM_STATUS macro Umesh Nerlige Ramappa (1): i915/perf: Remove code to update PWR_CLK_STATE for gen12 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 ++--- drivers/gpu/drm/i915/display/intel_hdcp_regs.h | 2 +- drivers/gpu/drm/i915/i915_perf.c | 33 -- 3 files changed, 4 insertions(+), 37 deletions(-)
[PULL] drm-intel-gt-next
Hi Dave & Sima, Here's the drm-intel-gt-next PR for v6.10 in one shot. We are adding a new uAPI for Mesa to request higher GT frequency for compute contexts on GuC platform. Then there is a W/A for DG2 to move to fixed CCS load balancing and make all DG2 SKUs appear with single CCS with all the EUs attached by default. Read more below under "UAPI Changes". There is one reported regression against it which we're working on resolving, so expect to see -next-fixes shortly once that happens. Beyond that we have a bunch of workaround updates/fixes, fix for UAF that has been hunted down for a while, GT reset fix for platforms that load GuC but don't submit via it, fix for execlists priority submission, proper capture of EIR register on hang. THe rest is usual code cleanups/refactoring and selftest fixes. Regards, Joonas *** drm-intel-gt-next-2024-04-26: UAPI Changes: - drm/i915/guc: Use context hints for GT frequency Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq for this context more slowly. We also disable waitboost for this context as that will interfere with the strategy. We need to enable the use of SLPC Compute strategy during init, but it will apply only to contexts that set this bit during context creation. Userland can check whether this feature is supported using a new param- I915_PARAM_HAS_CONTEXT_FREQ_HINT. This flag is true for all guc submission enabled platforms as they use SLPC for frequency management. The Mesa usage model for this flag is here - https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint - drm/i915/gt: Enable only one CCS for compute workload Enable only one CCS engine by default with all the compute sices allocated to it. While generating the list of UABI engines to be exposed to the user, exclude any additional CCS engines beyond the first instance *** NOTE: This W/A will make all DG2 SKUs appear like single CCS SKUs by default to mitigate a hardware bug. All the EUs will still remain usable, and all the userspace drivers have been confirmed to be able to dynamically detect the change in number of CCS engines and adjust. For the smaller percent of applications that get perf benefit from letting the userspace driver dispatch across all 4 CCS engines we will be introducing a sysfs control as a later patch to choose 4 CCS each with 25% EUs (or 50% if 2 CCS). NOTE: A regression has been reported at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 However Andi has been triaging the issue and we're closing in a fix to the gap in the W/A implementation: https://lists.freedesktop.org/archives/intel-gfx/2024-April/348747.html Driver Changes: - Add new and fix to existing workarounds: Wa_14018575942 (MTL), Wa_16019325821 (Gen12.70), Wa_14019159160 (MTL), Wa_16015675438, Wa_14020495402 (Gen12.70) (Tejas, John, Lucas) - Fix UAF on destroy against retire race and remove two earlier partial fixes (Janusz) - Limit the reserved VM space to only the platforms that need it (Andi) - Reset queue_priority_hint on parking for execlist platforms (Chris) - Fix gt reset with GuC submission is disabled (Nirmoy) - Correct capture of EIR register on hang (John) - Remove usage of the deprecated ida_simple_xx() API - Refactor confusing __intel_gt_reset() (Nirmoy) - Fix the fix for GuC reset lock confusion (John) - Simplify/extend platform check for Wa_14018913170 (John) - Replace dev_priv with i915 (Andi) - Add and use gt_to_guc() wrapper (Andi) - Remove bogus null check (Rodrigo, Dan) . Selftest improvements (Janusz, Nirmoy, Daniele) The following changes since commit db7bbd13f08774cde0332c705f042e327fe21e73: drm/i915: Check before removing mm notifier (2024-02-28 13:11:32 +) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-gt-next-2024-04-26 for you to fetch changes up to 4d3421e04c5dc38baf15224c051256204f223c15: drm/i915: Fix gt reset with GuC submission is disabled (2024-04-24 18:48:32 +0200) UAPI Changes: - drm/i915/guc: Use context hints for GT frequency Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq for this context more slowly. We also disable waitboost for this context as that will interfere with the strategy. We need to enable the use of SLPC C
Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Quoting Stephen Rothwell (2024-03-07 04:10:27)
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_dp.c
>
> between commit:
>
> 984318aaf7b6 ("drm/i915/panelreplay: Move out psr_init_dpcd() from
> init_connector()")
>
> from the drm-intel-fixes tree and commit:
>
> e60cff453b82 ("drm/i915/dp: Enable DP tunnel BW allocation mode")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/display/intel_dp.c
> index 94d2a15d8444,6ece2c563c7a..
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@@ -5699,9 -5702,13 +5702,16 @@@ intel_dp_detect(struct drm_connector *c
> goto out;
> }
>
> + ret = intel_dp_tunnel_detect(intel_dp, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (ret == 1)
> + intel_connector->base.epoch_counter++;
> +
> + if (!intel_dp_is_edp(intel_dp))
> + intel_psr_init_dpcd(intel_dp);
> +
Hi,
This is the right resolution, should be cleared up shortly once the
drm-intel-fixes PR is pulled.
Regards, Joonas
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> intel_dp_configure_mst(intel_dp);
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes the final drm-intel-fixes for v6.8. This PR will appear to contain more patches than it does. It's 4 patches on top of drm-fixes after Sima pulled the previous PR as you can observe from git log. Fixes for kernel crash on UHD 730, boot delay regression on PSR, DP DSC WARN splat and smaller fix for selftest. Regards, Joonas *** drm-intel-fixes-2024-03-07: - Fix for #10184: Kernel crash on UHD Graphics 730 (Cc stable) . Fix for #10284: Boot delay regresion with PSR - Fix DP connector DSC HW state readout - Selftest fix to convert msecs to jiffies The following changes since commit 90d35da658da8cff0d4ecbb5113f5fac9d00eb72: Linux 6.8-rc7 (2024-03-03 13:02:52 -0800) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-03-07 for you to fetch changes up to 984318aaf7b6516d03a2971a4a37bab4ea648461: drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector() (2024-03-06 15:41:16 +0200) - Fix for #10184: Kernel crash on UHD Graphics 730 (Cc stable) . Fix for #10284: Boot delay regresion with PSR - Fix DP connector DSC HW state readout - Selftest fix to convert msecs to jiffies Animesh Manna (1): drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector() Daniel Vetter (1): Merge tag 'drm-intel-fixes-2024-03-01' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes Imre Deak (1): drm/i915/dp: Fix connector DSC HW state readout Janusz Krzysztofik (1): drm/i915/selftests: Fix dependency of some timeouts on HZ Nirmoy Das (1): drm/i915: Check before removing mm notifier Suraj Kandpal (3): drm/i915/hdcp: Move to direct reads for HDCP drm/i915/hdcp: Remove additional timing for reading mst hdcp message drm/i915/hdcp: Extract hdcp structure from correct connector Tvrtko Ursulin (1): MAINTAINERS: Update email address for Tvrtko Ursulin Ville Syrjälä (1): drm/i915: Don't explode when the dig port we don't have an AUX CH .mailmap | 5 +++ MAINTAINERS| 2 +- .../drm/i915/display/intel_display_power_well.c| 17 ++-- drivers/gpu/drm/i915/display/intel_display_types.h | 7 drivers/gpu/drm/i915/display/intel_dp.c| 16 drivers/gpu/drm/i915/display/intel_dp.h| 2 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 47 -- drivers/gpu/drm/i915/display/intel_dp_mst.c| 1 + drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++--- drivers/gpu/drm/i915/display/intel_psr.c | 3 -- drivers/gpu/drm/i915/gem/i915_gem_userptr.c| 3 ++ .../drm/i915/selftests/intel_scheduler_helpers.c | 6 ++- 12 files changed, 75 insertions(+), 47 deletions(-)
Re: [PATCH v3 1/4] drm/i915/gt: Refactor uabi engine class/instance list creation
Quoting Andi Shyti (2024-03-01 01:28:56)
> For the upcoming changes we need a cleaner way to build the list
> of uabi engines.
>
> Suggested-by: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 833987015b8b..cf8f24ad88f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -203,7 +203,7 @@ static void engine_rename(struct intel_engine_cs *engine,
> const char *name, u16
>
> void intel_engines_driver_register(struct drm_i915_private *i915)
> {
> - u16 name_instance, other_instance = 0;
> + u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 1] = { };
Do you mean this to be size I915_LAST_UABI_ENGINE_CLASS + 2? Because ...
> @@ -222,15 +224,14 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
>
> GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
> engine->uabi_class = uabi_classes[engine->class];
> - if (engine->uabi_class == I915_NO_UABI_CLASS) {
> - name_instance = other_instance++;
> - } else {
> - GEM_BUG_ON(engine->uabi_class >=
> - ARRAY_SIZE(i915->engine_uabi_class_count));
> - name_instance =
> -
> i915->engine_uabi_class_count[engine->uabi_class]++;
> - }
> - engine->uabi_instance = name_instance;
> +
> + if (engine->uabi_class == I915_NO_UABI_CLASS)
> + uabi_class = I915_LAST_UABI_ENGINE_CLASS + 1;
.. otherwise this ...
> + else
> + uabi_class = engine->uabi_class;
> +
> + GEM_BUG_ON(uabi_class >= ARRAY_SIZE(class_instance));
.. will trigger this assertion?
Regards, Joonas
[PULL] drm-intel-fixes
Hi Dave & Sima, Here's the drm-intel-fixes towards v6.8(-rc7). One NULL check for mmu notifier and HDCP fix to read from primary connector. Regards, Joonas *** drm-intel-fixes-2024-03-01: - Fix to extract HDCP information from primary connector - Check for NULL mmu_interval_notifier before removing The following changes since commit d206a76d7d2726f3b096037f2079ce0bd3ba329b: Linux 6.8-rc6 (2024-02-25 15:46:06 -0800) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-03-01 for you to fetch changes up to 01bb1ae35006e473138c90711bad1a6b614a1823: drm/i915: Check before removing mm notifier (2024-02-29 14:14:40 +0200) - Fix to extract HDCP information from primary connector - Check for NULL mmu_interval_notifier before removing Nirmoy Das (1): drm/i915: Check before removing mm notifier Suraj Kandpal (3): drm/i915/hdcp: Move to direct reads for HDCP drm/i915/hdcp: Remove additional timing for reading mst hdcp message drm/i915/hdcp: Extract hdcp structure from correct connector drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 47 ++-- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++ 2 files changed, 19 insertions(+), 31 deletions(-)
Re: [PATCH] MAINTAINERS: Update email address for Tvrtko Ursulin
Quoting Tvrtko Ursulin (2024-02-28 16:22:40) > From: Tvrtko Ursulin > > I will lose access to my @.*intel.com e-mail addresses soon so let me > adjust the maintainers entry and update the mailmap too. > > While at it consolidate a few other of my old emails to point to the > main one. > > Signed-off-by: Tvrtko Ursulin > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi Acked-by: Joonas Lahtinen Regards, Joonas
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes for v6.8-rc6. Just a single fixup patch for TV mode. Best Regards, Joonas *** drm-intel-fixes-2024-02-22: - Fixup for TV mode The following changes since commit b401b621758e46812da61fa58a67c3fd8d91de0d: Linux 6.8-rc5 (2024-02-18 12:56:25 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2024-02-22 for you to fetch changes up to fb1e881273f432e593f8789f99e725b09304cc97: drm/i915/tv: Fix TV mode (2024-02-21 09:30:20 +0200) - Fixup for TV mode Maxime Ripard (1): drm/i915/tv: Fix TV mode drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +- drivers/gpu/drm/i915/display/intel_tv.c | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-)
Re: [PULL] drm-intel-gt-next
Quoting Joonas Lahtinen (2024-02-16 11:41:44) > (+ Jonathan) > > Quoting Dave Airlie (2024-02-16 04:58:03) > > On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin > > wrote: > > > > > > Hi Dave, Daniel, > > > > > > First pull request for 6.9 with probably one more coming in one to two > > > weeks. > > > > > > Nothing to interesting in this one, mostly a sprinkle of small fixes in > > > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms and some > > > code cleanups. > > > > > > One new uapi in the form of a GuC submission version query which Mesa > > > wants for implementing Vulkan async compute queues. > > > > > > Regards, > > > > > > Tvrtko > > > > > > drm-intel-gt-next-2024-02-15: > > > UAPI Changes: > > > > > > - Add GuC submission interface version query (Tvrtko Ursulin) > > > > > > Driver Changes: > > > > > > Fixes/improvements/new stuff: > > > > > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt) > > > > I've pulled this, but the above patch is triggering my this seems > > wrong spider sense. > > > > This and probably the preceeding patch that this references seem to > > move i915 to a long term pinning of userptr in memory with what I can > > see no accounting, and away from what the desired behaviour for > > drivers should be. > > I asked Thomas to take a more detailed look. Jonathan, Thomas really should > have been Cc'd in the original patch as the patch was explicitly referred > in the text even. > > > It also feels like the authorship on this might be lies which also worries > > me. > > Fear not. This can probably be blamed on the i915 maintainers. > > When we have an internal patch which has many revisions and is then > essentially rewritten for upstreaming, we specifically asked NOT to keep > the "From:" line intact, but instead swap in person who rewrote the patch[1]. Just to state the obvious for the public record: This should never be done lightly or without reaching out to the original author. This should only be for the exceptional cases where the patch has significantly changed. This was just the explanation why it's not an immediate red flag to see such a patch. Based on the discussion around the topic we should be more explicit if such a case has happened or if there simply has been an error in the patch handling. So we'll work on clarifying the instructions here. Regards, Joonas > To document credits/involvement of the original author we've recommended > to keep the Signed-off-by line however. "Co-developed-by" does not really > express the situation correctly. "Based on patch by" style pure textual > credit reference was also discussed but is hard to grep. > > Discussed with Sima who suggested if we should consider something like > "Original-patch-by:" tag to better express this situation? > > Regards, Joonas > > [1] If the "From: " line is not updated, it sometimes leads to > situation where you can see a patch with "From:" pointing to you, that > doesn't contain a single unmodified line anymore. > > > > > Dave.
Re: [PULL] drm-intel-gt-next
(+ Jonathan) Quoting Dave Airlie (2024-02-16 04:58:03) > On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin > wrote: > > > > Hi Dave, Daniel, > > > > First pull request for 6.9 with probably one more coming in one to two > > weeks. > > > > Nothing to interesting in this one, mostly a sprinkle of small fixes in > > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms and some > > code cleanups. > > > > One new uapi in the form of a GuC submission version query which Mesa > > wants for implementing Vulkan async compute queues. > > > > Regards, > > > > Tvrtko > > > > drm-intel-gt-next-2024-02-15: > > UAPI Changes: > > > > - Add GuC submission interface version query (Tvrtko Ursulin) > > > > Driver Changes: > > > > Fixes/improvements/new stuff: > > > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt) > > I've pulled this, but the above patch is triggering my this seems > wrong spider sense. > > This and probably the preceeding patch that this references seem to > move i915 to a long term pinning of userptr in memory with what I can > see no accounting, and away from what the desired behaviour for > drivers should be. I asked Thomas to take a more detailed look. Jonathan, Thomas really should have been Cc'd in the original patch as the patch was explicitly referred in the text even. > It also feels like the authorship on this might be lies which also worries me. Fear not. This can probably be blamed on the i915 maintainers. When we have an internal patch which has many revisions and is then essentially rewritten for upstreaming, we specifically asked NOT to keep the "From:" line intact, but instead swap in person who rewrote the patch[1]. To document credits/involvement of the original author we've recommended to keep the Signed-off-by line however. "Co-developed-by" does not really express the situation correctly. "Based on patch by" style pure textual credit reference was also discussed but is hard to grep. Discussed with Sima who suggested if we should consider something like "Original-patch-by:" tag to better express this situation? Regards, Joonas [1] If the "From: " line is not updated, it sometimes leads to situation where you can see a patch with "From:" pointing to you, that doesn't contain a single unmodified line anymore. > > Dave.
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes towards v6.8-rc5. Two fixes. Fix for #10172 (blank screen on JSL Chromebooks) and limiting SST link rate within supported range. Best Regards, Joonas *** drm-intel-fixes-2024-02-15: Fix for #10172: Blank screen on JSL Chromebooks. Stable fix to limit DP SST link rate to <=8.1Gbps. The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de: Linux 6.8-rc4 (2024-02-11 12:18:13 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2024-02-15 for you to fetch changes up to ad26d56d080780bbfcc1696ca0c0cce3e2124ef6: drm/i915/dp: Limit SST link rate to <=8.1Gbps (2024-02-12 11:39:19 +0200) Fix for #10172: Blank screen on JSL Chromebooks. Stable fix to limit DP SST link rate to <=8.1Gbps. Manasi Navare (1): drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address Ville Syrjälä (1): drm/i915/dp: Limit SST link rate to <=8.1Gbps drivers/gpu/drm/i915/display/intel_dp.c| 3 +++ drivers/gpu/drm/i915/display/intel_vdsc_regs.h | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Sima, Here goes drm-intel-fixes, which is just the gvt-fixes PR for this week. Regards, Joonas *** drm-intel-fixes-2024-02-08: - Just includes gvt-fixes-2024-02-05 The following changes since commit 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478: Linux 6.8-rc3 (2024-02-04 12:20:36 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2024-02-08 for you to fetch changes up to a99682e839af7be11a606bf802cba5b2bf93b8e9: Merge tag 'gvt-fixes-2024-02-05' of https://github.com/intel/gvt-linux into drm-intel-fixes (2024-02-05 15:56:47 +0200) - Just includes gvt-fixes-2024-02-05 Dan Carpenter (1): drm/i915/gvt: Fix uninitialized variable in handle_mmio() Joonas Lahtinen (1): Merge tag 'gvt-fixes-2024-02-05' of https://github.com/intel/gvt-linux into drm-intel-fixes Zhenyu Wang (1): drm/i915: Replace dead 01.org link Zhi Wang (1): MAINTAINERS: Update Zhi Wang's email address MAINTAINERS | 4 ++-- drivers/gpu/drm/i915/Kconfig| 2 +- drivers/gpu/drm/i915/gvt/handlers.c | 3 +-- drivers/gpu/drm/i915/intel_gvt.c| 2 +- 4 files changed, 5 insertions(+), 6 deletions(-)
Re: [RFC] drm/i915: Add GuC submission interface version query
Quoting Tvrtko Ursulin (2024-02-07 13:56:12)
> From: Tvrtko Ursulin
>
> Add a new query to the GuC submission interface version.
>
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
> simultaneously can cause GPU hangs due issues in firmware scheduling.
>
> Based on patches from Vivaik and Joonas.
>
> There is a little bit of an open around the width required for versions.
> While the GuC FW iface tells they are u8, i915 GuC code uses u32:
>
> #define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
> #define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
> #define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
> ...
> struct intel_uc_fw_ver {
> u32 major;
> u32 minor;
> u32 patch;
> u32 build;
> };
>
> So we could make the query u8, and refactor the struct intel_uc_fw_ver
> to use u8, or not. To avoid any doubts on why are we assigning u32 to
> u8 I simply opted to use u64. Which avoids the need to add any padding
> too.
This a single-shot init time query so I guess u64 is fine too, to keep
the code straightforward.
> Compile tested only.
If Mesa folks confirm this is working for them and after you add link to
the Mesa PR, then you can add my:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> Signed-off-by: Tvrtko Ursulin
> Cc: Kenneth Graunke
> Cc: Jose Souza
> Cc: Sagar Ghuge
> Cc: Paulo Zanoni
> Cc: John Harrison
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Tvrtko Ursulin
> Cc: Vivaik Balasubrawmanian
> ---
> drivers/gpu/drm/i915/i915_query.c | 32 +++
> include/uapi/drm/i915_drm.h | 11 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 00871ef99792..999687f6a3d4 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -551,6 +551,37 @@ static int query_hwconfig_blob(struct drm_i915_private
> *i915,
> return hwconfig->size;
> }
>
> +static int
> +query_guc_submission_version(struct drm_i915_private *i915,
> +struct drm_i915_query_item *query)
> +{
> + struct drm_i915_query_guc_submission_version __user *query_ptr =
> + u64_to_user_ptr(query->data_ptr);
> + struct drm_i915_query_guc_submission_version ver;
> + struct intel_guc *guc = &to_gt(i915)->uc.guc;
> + const size_t size = sizeof(ver);
> + int ret;
> +
> + if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
> + return -ENODEV;
> +
> + ret = copy_query_item(&ver, size, size, query);
> + if (ret != 0)
> + return ret;
> +
> + if (ver.major || ver.minor || ver.patch)
> + return -EINVAL;
> +
> + ver.major = guc->submission_version.major;
> + ver.minor = guc->submission_version.minor;
> + ver.patch = guc->submission_version.patch;
> +
> + if (copy_to_user(query_ptr, &ver, size))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
> struct drm_i915_query_item
> *query_item) = {
> query_topology_info,
> @@ -559,6 +590,7 @@ static int (* const i915_query_funcs[])(struct
> drm_i915_private *dev_priv,
> query_memregion_info,
> query_hwconfig_blob,
> query_geometry_subslices,
> + query_guc_submission_version,
> };
>
> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
> *file)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 550c496ce76d..d80d9b5e1eda 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
> * - %DRM_I915_QUERY_MEMORY_REGIONS (see struct
> drm_i915_query_memory_regions)
> * - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob uAPI`)
> * - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct
> drm_i915_query_topology_info)
> +* - %DRM_I915_QUERY_GUC_SUBMISSION_VERSION (see struct
> drm_i915_query_guc_submission_version)
> */
> __u64 query_id;
> #define DRM_I915_QUERY_TOPOLOGY_INFO 1
> @@ -3046,6 +3047,7 @@ struct drm_i915_query_item {
> #define DRM_I915_QUERY_MEMORY_REGIONS 4
> #define DRM_I915_QUERY_HWCONFIG_BLOB 5
> #d
[PULL] drm-intel-fixes
Hi Dave & Sima, Just one Cc stable patch (the rest was already in drm-intel-next-fixes). Tried to wait for CI results, but none yet. Best Regards, Joonas *** drm-intel-fixes-2024-01-26: - PSR fix for HSW The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d: Linux 6.8-rc1 (2024-01-21 14:11:32 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2024-01-26 for you to fetch changes up to f9f031dd21a7ce13a13862fa5281d32e1029c70f: drm/i915/psr: Only allow PSR in LPSP mode on HSW non-ULT (2024-01-25 10:44:13 +0200) - PSR fix for HSW Ville Syrjälä (1): drm/i915/psr: Only allow PSR in LPSP mode on HSW non-ULT drivers/gpu/drm/i915/display/intel_psr.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Sima, Here goes drm-intel-next-fixes for v6.8. Build warning fix for GCC11, fix for #10071 and DP test pattern fix, one OA fix for XeHP+. Regards, Joonas *** drm-intel-next-fixes-2024-01-19: - DSI sequence revert to fix GitLab #10071 and DP test-pattern fix - Drop -Wstringop-overflow (broken on GCC11) - OA fix on XeHP+ The following changes since commit d505a16e00c35919fd9fe5735894645e0f70a415: drm/i915/perf: reconcile Excess struct member kernel-doc warnings (2024-01-10 11:56:58 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2024-01-19 for you to fetch changes up to 84b5ece64477df4394d362d494a2496bf0878985: drm/i915: Drop -Wstringop-overflow (2024-01-18 13:04:36 +0200) - DSI sequence revert to fix GitLab #10071 and DP test-pattern fix - Drop -Wstringop-overflow (broken on GCC11) - OA fix on XeHP+ Khaled Almahallawy (1): drm/i915/dp: Fix passing the correct DPCD_REV for drm_dp_set_phy_test_pattern Lucas De Marchi (1): drm/i915: Drop -Wstringop-overflow Umesh Nerlige Ramappa (1): drm/i915/perf: Update handling of MMIO triggered reports Ville Syrjälä (1): Revert "drm/i915/dsi: Do display on sequence later on icl+" drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/display/icl_dsi.c | 3 +-- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/i915_perf.c| 39 - 4 files changed, 36 insertions(+), 9 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Sima, Here goes drm-intel-next-fixes towards 6.8 merge window now that drm-intel-gt-next is also merged. Most importantly fixes for linux-next added build warnings and then a couple display fixes. CI results for drm-next seem to have regressed with regards to the shard runs somewhere in the past, so bit limited to assess for regressions but BAT looks reasonable. Best Regards, Joonas *** drm-intel-next-fixes-2024-01-11: - Fixes for kernel-doc warnings enforced in linux-next - Another build warning fix for string formatting of intel_wakeref_t - Display fixes for DP DSC BPC and C20 PLL state verification The following changes since commit b76c01f1d950425924ee1c1377760de3c024ef78: Merge tag 'drm-intel-gt-next-2023-12-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2024-01-10 11:36:47 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2024-01-11 for you to fetch changes up to d505a16e00c35919fd9fe5735894645e0f70a415: drm/i915/perf: reconcile Excess struct member kernel-doc warnings (2024-01-10 11:56:58 +0200) - Fixes for kernel-doc warnings enforced in linux-next - Another build warning fix for string formatting of intel_wakeref_t - Display fixes for DP DSC BPC and C20 PLL state verification Ankit Nautiyal (1): drm/i915/dp: Fix the max DSC bpc supported by source Imre Deak (1): drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors Jani Nikula (1): drm/i915: don't make assumptions about intel_wakeref_t type Mika Kahola (1): drm/i915/display: Fix C20 pll selection for state verification Randy Dunlap (4): drm/i915/gem: reconcile Excess struct member kernel-doc warnings drm/i915/gt: reconcile Excess struct member kernel-doc warnings drm/i915/guc: reconcile Excess struct member kernel-doc warnings drm/i915/perf: reconcile Excess struct member kernel-doc warnings drivers/gpu/drm/i915/display/intel_cx0_phy.c | 25 +--- drivers/gpu/drm/i915/display/intel_display_power.c | 4 +- drivers/gpu/drm/i915/display/intel_dp.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 10 +-- drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 4 +- drivers/gpu/drm/i915/gt/intel_gsc.h| 7 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 75 -- drivers/gpu/drm/i915/i915_perf_types.h | 9 ++- 8 files changed, 78 insertions(+), 58 deletions(-)
Re: disable large folios for shmem file used by xfs xfile
Quoting Joonas Lahtinen (2024-01-10 17:20:24) > Quoting Matthew Wilcox (2024-01-10 14:37:18) > > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote: > > > Hi all, > > > > > > Darrick reported that the fairly new XFS xfile code blows up when force > > > enabling large folio for shmem. This series fixes this quickly by > > > disabling > > > large folios for this particular shmem file for now until it can be fixed > > > properly, which will be a lot more invasive. > > > > > > I've added most of you to the CC list as I suspect most other users of > > > shmem_file_setup and friends will have similar issues. > > > > The graphics users _want_ to use large folios. I'm pretty sure they've > > been tested with this. > > Correct. We've done quite a bit of optimization in userspace and > enabling in kernel to take advantage of page sizes of 2M and beyond. > > However we specifically pass "huge=within_size" to vfs_kern_mount when > creating a private mount of tmpfs for the purpose of i915 created > allocations. > > Older hardware also had some address hashing bugs where 2M aligned > memory caused a lot of collisions in TLB so we don't enable it always. > > You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function > i915_gemfs_init for details and references. > > So in short, functionality wise we should be fine either default > for using 2M pages or not. If they become the default, we'd probably > want an option that would still be able to prevent them for performance > regression reasons on older hardware. To maybe write out my concern better: Is there plan to enable huge pages by default in shmem? If not I guess we should be pretty good with the way current code is, force enabling them just might bring out some performance, so we might want to add a warning for that. If there is, then we'll probably want to in sync with those default changes apply a similar call to block them on older HW. Regards, Joonas > > Regards, Joonas > > > It's just XFS that didn't know about this > > feature of shmem.
Re: disable large folios for shmem file used by xfs xfile
Quoting Matthew Wilcox (2024-01-10 14:37:18) > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote: > > Hi all, > > > > Darrick reported that the fairly new XFS xfile code blows up when force > > enabling large folio for shmem. This series fixes this quickly by disabling > > large folios for this particular shmem file for now until it can be fixed > > properly, which will be a lot more invasive. > > > > I've added most of you to the CC list as I suspect most other users of > > shmem_file_setup and friends will have similar issues. > > The graphics users _want_ to use large folios. I'm pretty sure they've > been tested with this. Correct. We've done quite a bit of optimization in userspace and enabling in kernel to take advantage of page sizes of 2M and beyond. However we specifically pass "huge=within_size" to vfs_kern_mount when creating a private mount of tmpfs for the purpose of i915 created allocations. Older hardware also had some address hashing bugs where 2M aligned memory caused a lot of collisions in TLB so we don't enable it always. You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function i915_gemfs_init for details and references. So in short, functionality wise we should be fine either default for using 2M pages or not. If they become the default, we'd probably want an option that would still be able to prevent them for performance regression reasons on older hardware. Regards, Joonas > It's just XFS that didn't know about this > feature of shmem.
Re: [PATCH v2 1/3] drm/i915/gt: Support fixed CCS mode
Quoting Tvrtko Ursulin (2024-01-05 12:39:31)
>
> On 04/01/2024 21:23, Andi Shyti wrote:
> >>> +void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> >>> +{
> >>> + mutex_lock(>->ccs.mutex);
> >>> + __intel_gt_apply_ccs_mode(gt);
> >>> + mutex_unlock(>->ccs.mutex);
> >>> +}
> >>> +
> >>> +void intel_gt_init_ccs_mode(struct intel_gt *gt)
> >>> +{
> >>> + mutex_init(>->ccs.mutex);
> >>> + gt->ccs.mode = 1;
> >>
> >> What is '1'? And this question carries over to the sysfs interface in the
> >> following patch - who will use it and where it is documented how to use it?
> >
> > The value '1' is explained in the comment above[1] and in the
>
> Do you mean this is mode '1':
>
> * With 1 engine (ccs0):
> * slice 0, 1, 2, 3: ccs0
>
> ?
>
> But I don't see where it says what do different modes mean on different
> SKU configurations.
>
> It also does not say what should the num_slices sysfs file be used for.
>
> Does "mode N" mean "assign each command streamer N compute slices"? Or
> "assign each compute slice N command streamers"?
>
> I wonder if we should add something user friendly into
> Documentation/ABI/*/sysfs-... Joonas your thoughts?
We definitely should always properly document all sysfs additions, just
seems like we less frequently remember to do so. So yeah, this should be
documented just like other uAPI.
I also like the idea of not exposing the the file at all if the value
can't be modified.
The ccs_mode is just supposed to allow user to select how many CCS
engines they want to expose, and always make an even split of slices
between them, nothing more nothing less.
Regards, Joonas
Re: [PATCH 1/3] drm/i915/gt: Support fixed CCS mode
Quoting Andi Shyti (2023-12-21 19:08:22)
> The CCS mode involves assigning CCS engines to slices depending
> on the number of slices and the number of engines the user wishes
> to set.
>
> In this patch, the default CCS setting is established during the
> initial GT settings. It involves assigning only one CCS to all
> the slices.
>
> Based on a patch by Chris Wilson
> and Tejas Upadhyay .
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Niranjana Vishwanathapura
> Cc: Tejas Upadhyay
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -207,6 +207,26 @@ struct intel_gt {
> [MAX_ENGINE_INSTANCE + 1];
> enum intel_submission_method submission_method;
>
> + /*
> +* Track fixed mapping between CCS engines and compute slices.
> +*
> +* In order to w/a HW that has the inability to dynamically load
> +* balance between CCS engines and EU in the compute slices, we have
> to
> +* reconfigure a static mapping on the fly. We track the current CCS
> +* configuration (determined by inspection of the user's engine
> +* selection during execbuf) and compare it against the current
> +* CCS_MODE (which maps CCS engines to compute slices). If there is
> +* only a single engine selected, we can map it to all available
> +* compute slices for maximal single task performance (fast/narrow).
> If
> +* there are more then one engine selected, we have to reduce the
> +* number of slices allocated to each engine (wide/slow), fairly
> +* distributing the EU between the equivalent engines.
> +*/
This comment is outdated as we don't consider execbuf but the sysfs
configuration.
Regards, Joonas
> + struct {
> + struct mutex mutex;
> + u32 mode;
> + } ccs;
> +
> /*
> * Default address space (either GGTT or ppGTT depending on arch).
> *
[PULL] drm-intel-gt-next
Hi Dave & Sima, Final drm-intel-gt-next PR for v6.8. Elimination of kmap_atomic() from the driver to allow kernel wide cleanup. One new DG2 W/A and static checker/spelling fixes. Best Regards, Joonas *** drm-intel-gt-next-2023-12-15: Driver Changes: - Eliminate use of kmap_atomic() in i915 (Zhao) - Add Wa_14019877138 for DG2 (Haridhar) - Static checker and spelling fixes (Colin, Karthik, Randy) - The following changes since commit be5bcc4be9d9d3ae294072441a66fe39b74e5bba: drm/i915/guc: Create the guc_to_i915() wrapper (2023-12-08 12:31:01 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-12-15 for you to fetch changes up to 31accc37eaee98a90b25809ed58c6ee4956ab642: drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c (2023-12-15 09:34:31 +) Driver Changes: - Eliminate use of kmap_atomic() in i915 (Zhao) - Add Wa_14019877138 for DG2 (Haridhar) - Static checker and spelling fixes (Colin, Karthik, Randy) - Colin Ian King (1): drm/i915/selftests: Fix spelling mistake "initialiased" -> "initialised" Haridhar Kalvala (1): drm/i915: Add Wa_14019877138 Karthik Poosa (1): drm/i915/hwmon: Fix static analysis tool reported issues Randy Dunlap (1): drm/i915/uapi: fix typos/spellos and punctuation Zhao Liu (9): drm/i915: Use kmap_local_page() in gem/i915_gem_object.c drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c drm/i915: Use kmap_local_page() in i915_cmd_parser.c drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++- drivers/gpu/drm/i915/gem/i915_gem_phys.c| 10 ++ drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 -- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 5 + drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_hwmon.c | 4 ++-- include/uapi/drm/i915_drm.h | 12 ++-- 14 files changed, 43 insertions(+), 50 deletions(-)
[PULL] drm-intel-gt-next
Hi Dave & Sima, A rather late first drm-intel-gt-next PR towards v6.8. As most significant change we have addition of the DRM fdinfo memory stats functionality. Then DG2 and MTL workaround additions and fixes and a few for older platforms as well. PMU WARN_ON splat cleanup. The rest is mostly code cleanups and fixes for odd corner cases. Best Regards, Joonas *** drm-intel-gt-next-2023-12-08: UAPI Changes: - drm/i915: Implement fdinfo memory stats printing Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. Cross-subsystem Changes: - Backmerge of drm-next (to bring drm-intel-next for PXP changes) Driver Changes: - Wa_18028616096 now applies to all DG2 (Matt R) - Drop Wa_22014600077 on all DG2 (Matt R) - Add new ATS-M device ID (Haridhar) - More Meteorlake (MTL) workarounds (Matt R, Dnyaneshwar, Jonathan, Gustavo, Radhakrishna) - PMU WARN_ON cleanup on driver unbind (Umesh) - Limit GGTT WC flushing workaround to pre BXT/ICL platforms - Complement implementation for Wa_16018031267 / Wa_16018063123 (Andrzej, Jonathan, Nirmoy, Chris) - Properly print internal GSC engine in trace logs (Tvrtko) - Track gt pm wakerefs (Andrzej) - Fix null deref bugs on perf code when perf is disabled (Harshit, Tvrtko) - Fix __i915_request_create memory leak on driver unbind (Andrzej) - Remove spurious unsupported HuC message on MTL (Daniele) - Read a shadowed mmio register for ggtt flush (Vinay) - Add missing new-line to GT_TRACE (Andrzej) - Add drm_dbgs for critical PXP events (Alan) - Skip pxp init if gt is wedged (Zhanjun) - Replace custom intel runtime_pm tracker with ref_tracker library (Andrzej) - Compiler warning/static checker/coding style cleanups (Arnd, Nirmoy, Soumya, Gilbert, Dorcas, Kunwu, Sam, Tvrtko) - Code structure and helper cleanups (Jani, Tvrtko, Andi) - Selftest improvements (John, Tvrtko, Andrzej) The following changes since commit 11ae5eb516b656e8a0e4efbea90ea24c152a346d: Merge tag 'topic/vmemdup-user-array-2023-10-24-1' of git://anongit.freedesktop.org/drm/drm into drm-next (2023-10-24 11:13:29 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-12-08 for you to fetch changes up to be5bcc4be9d9d3ae294072441a66fe39b74e5bba: drm/i915/guc: Create the guc_to_i915() wrapper (2023-12-08 12:31:01 +0100) UAPI Changes: - drm/i915: Implement fdinfo memory stats printing Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. Cross-subsystem Changes: - Backmerge of drm-next (to bring drm-intel-next for PXP changes) Driver Changes: - Wa_18028616096 now applies to all DG2 (Matt R) - Drop Wa_22014600077 on all DG2 (Matt R) - Add new ATS-M device ID (Haridhar) - More Meteorlake (MTL) workarounds (Matt R, Dnyaneshwar, Jonathan, Gustavo, Radhakrishna) - PMU WARN_ON cleanup on driver unbind (Umesh) - Limit GGTT WC flushing workaround to pre BXT/ICL platforms - Complement implementation for Wa_16018031267 / Wa_16018063123 (Andrzej, Jonathan, Nirmoy, Chris) - Properly print internal GSC engine in trace logs (Tvrtko) - Track gt pm wakerefs (Andrzej) - Fix null deref bugs on perf code when perf is disabled (Harshit, Tvrtko) - Fix __i915_request_create memory leak on driver unbind (Andrzej) - Remove spurious unsupported HuC message on MTL (Daniele) - Read a shadowed mmio register for ggtt flush (Vinay) - Add missing new-line to GT_TRACE (Andrzej) - Add drm_dbgs for critical PXP events (Alan) - Skip pxp init if gt is wedged (Zhanjun) - Replace custom intel runtime_pm tracker with ref_tracker library (Andrzej) - Compiler warning/static checker/coding style cleanups (Arnd, Nirmoy, Soumya, Gilbert, Dorcas, Kunwu, Sam, Tvrtko) - Code structure and helper cleanups (Jani, Tvrtko, Andi) - Selftest improvements (John, Tvrtko, Andrzej) Alan Previn (1): drm/i915/pxp: Add drm_dbgs for critical PXP events. Andi Shyti (1): drm/i915/guc: Create the guc_to_i915() wrapper Andrzej Hajda (8): drm/i915: Reserve some kernel space per vm drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 drm/i915/gt: add selftest to exercise WABB drm/i915/gt: add missing new-line to GT_TRACE drm/i915: do not clean GT table on error path drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library drm/i915: Track gt pm wakerefs drm/i915/selftests: wait for active i
Re: [PATCH v2 0/4] drm/xe: Support optional pinning of userptr pages
Quoting Thomas Hellström (2023-08-22 19:21:32) > This series adds a flag at VM_BIND time to pin the memory backing a VMA. > Initially this is needed for long-running workloads on hardware that > neither support mid-thread preemption nor pagefaults, since without it > the userptr MMU notifier will wait for preemption until preemption times > out. >From terminology perspective we have a lot of folks in the userspace and kernel developers who have come to understand pinned memory as something that is locked in place while a dependent context is active on the hardware. And that has been related to lack of page-fault support. As here the plan is to go a step forward and never move that memory, would it be worthy to call such memory LOCKED (would also align with CPU side). And per my understanding the aspiration is to keep supporting locking memory in place (within sysadmin configured limits) even if page-faults will become de-facto usage. So, in short, should we do s/pinned/locked/, to avoid terminology confusion between new and old drivers which userspace may have to deal from same codebase? Regards, Joonas > > Moving forward this could be supported also for bo-backed VMAs given > a proper accounting takes place. A sysadmin could then optionally configure > a system to be optimized for dealing with a single GPU application > at a time. > > The series will be followed up with an igt series to exercise the uAPI. > > v2: > - Address review comments by Matthew Brost. > > Thomas Hellström (4): > drm/xe/vm: Use onion unwind for xe_vma_userptr_pin_pages() > drm/xe/vm: Implement userptr page pinning > drm/xe/vm: Perform accounting of userptr pinned pages > drm/xe/uapi: Support pinning of userptr vmas > > drivers/gpu/drm/xe/xe_vm.c | 194 --- > drivers/gpu/drm/xe/xe_vm.h | 9 ++ > drivers/gpu/drm/xe/xe_vm_types.h | 14 +++ > include/uapi/drm/xe_drm.h| 18 +++ > 4 files changed, 190 insertions(+), 45 deletions(-) > > -- > 2.41.0 >
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here's the final drm-intel-gt-next PR for v6.6. Not too many patches as the previous PR was later than usual. Just one more workaround fix for MTL, some object coherency refactoring and selftest fix. Note that there is a backmerge of drm-next[1], too. Regards, Joonas [1] As prep for https://patchwork.freedesktop.org/series/121735/ but the series started failing CI after rebasing and continues to be investigated so not landing here yet. *** drm-intel-gt-next-2023-08-11: Cross-subsystem Changes: - Backmerge of drm-next Driver Changes: - Apply workaround 22016122933 correctly (Jonathan, Matt R) - Simplify shmem_create_from_object map_type selection (Jonathan, Tvrtko) - Make i915_coherent_map_type GT-centric (Jonathan, Matt R) - Selftest improvements (John) The following changes since commit d9aa1da9a8cfb0387eb5703c15bd1f54421460ac: Merge tag 'drm-intel-gt-next-2023-08-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-08-07 13:49:25 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-08-11 for you to fetch changes up to 788568fad4015406fa84fc86cefbef7c470c7c1f: drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test (2023-08-10 16:02:01 -0700) Cross-subsystem Changes: - Backmerge of drm-next Driver Changes: - Apply workaround 22016122933 correctly (Jonathan, Matt R) - Simplify shmem_create_from_object map_type selection (Jonathan, Tvrtko) - Make i915_coherent_map_type GT-centric (Jonathan, Matt R) - Selftest improvements (John) John Harrison (1): drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test Jonathan Cavitt (3): drm/i915/gt: Simplify shmem_create_from_object map_type selection drm/i915: Make i915_coherent_map_type GT-centric drm/i915/gt: Apply workaround 22016122933 correctly Joonas Lahtinen (1): Merge drm/drm-next into drm-intel-gt-next drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 3 ++- drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 15 --- drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 16 drivers/gpu/drm/i915/gt/intel_gt.h| 10 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_lrc.c | 13 +++-- drivers/gpu/drm/i915/gt/intel_ring.c | 3 ++- drivers/gpu/drm/i915/gt/selftest_context.c| 5 +++-- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++-- drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +++--- drivers/gpu/drm/i915/gt/shmem_utils.c | 3 +-- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 7 +-- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 11 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 3 +-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 6 +++--- drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 3 ++- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 - drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +- 23 files changed, 75 insertions(+), 69 deletions(-)
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the first drm-intel-gt-next PR for v6.6. We have a fix for infinite GPU wait race condition found by CI, then improved tweakability of RPS algo and fixes to GuC SLPC for tuning the frequency behavior of the system. OA report zeroing fix, Aux CCS invalidation fix on Gen12 and addition of missing W/A for TGL, RKL, DG1, DG2 and ADL. Then some Meteorlake enabling patches and the usual amount of debugging and code structure improvements, static checker fixes and fixes for potential UAF and error handling paths. Regards, Joonas PS. Hoping to backmerge drm-next early next week to bring in some drm-intel-gt-next dependencies before the final PR. drm-intel-gt-next-2023-08-04: Driver Changes: - Avoid infinite GPU waits by avoiding premature release of request's reusable memory (Chris, Janusz) - Expose RPS thresholds in sysfs (Tvrtko) - Apply GuC SLPC min frequency softlimit correctly (Vinay) - Restore SLPC efficient freq earlier (Vinay) - Consider OA buffer boundary when zeroing out reports (Umesh) - Extend Wa_14015795083 to TGL, RKL, DG1 and ADL (Matt R) - Fix context workarounds with non-masked regs on MTL/DG2 (Lucas) - Enable the CCS_FLUSH bit in the pipe control and in the CS for MTL+ (Andi) - Update MTL workarounds 14018778641, 22016122933 (Tejas, Zhanjun) - Ensure memory quiesced before AUX CCS invalidation (Jonathan) - Add a gsc_info debugfs (Daniele) - Invalidate the TLBs on each GT on multi-GT device (Chris) - Fix a VMA UAF for multi-gt platform (Nirmoy) - Do not use stolen on MTL due to HW bug (Nirmoy) - Check HuC and GuC version compatibility on MTL (Daniele) - Dump perf_limit_reasons for slow GuC init debug (Vinay) - Replace kmap() with kmap_local_page() (Sumitra, Ira) - Add sentinel to xehp_oa_b_counters for KASAN (Andrzej) - Add the gen12_needs_ccs_aux_inv helper (Andi) - Fixes and updates for GSC memory allocation (Daniele) - Fix one wrong caching mode enum usage (Tvrtko) - Fixes for GSC wakeref (Alan) - Static checker fixes (Harshit, Arnd, Dan, Cristophe, David, Andi) - Rename flags with bit_group_X according to the datasheet (Andi) - Use direct alias for i915 in requests (Andrzej) - Replace i915->gt0 with to_gt(i915) (Andi) - Use the i915_vma_flush_writes helper (Tvrtko) - Selftest improvements (Alan) - Remove dead code (Tvrtko) The following changes since commit 24335848e543dc95c9e2ffa0108d879ffefd0442: drm/i915/gsc: Fix error code in intel_gsc_uc_heci_cmd_submit_nonpriv() (2023-06-08 02:11:04 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-08-04 for you to fetch changes up to 28e671114fb0f28f334fac8d0a6b9c395c7b0498: drm/i915/guc/slpc: Restore efficient freq earlier (2023-08-02 11:08:02 -0700) Driver Changes: - Avoid infinite GPU waits by avoidin premature release of request's reusable memory (Chris, Janusz) - Expose RPS thresholds in sysfs (Tvrtko) - Apply GuC SLPC min frequency softlimit correctly (Vinay) - Restore SLPC efficient freq earlier (Vinay) - Consider OA buffer boundary when zeroing out reports (Umesh) - Extend Wa_14015795083 to TGL, RKL, DG1 and ADL (Matt R) - Fix context workarounds with non-masked regs on MTL/DG2 (Lucas) - Enable the CCS_FLUSH bit in the pipe control and in the CS for MTL+ (Andi) - Update MTL workarounds 14018778641, 22016122933 (Tejas, Zhanjun) - Ensure memory quiesced before AUX CCS invalidation (Jonathan) - Add a gsc_info debugfs (Daniele) - Invalidate the TLBs on each GT on multi-GT device (Chris) - Fix a VMA UAF for multi-gt platform (Nirmoy) - Do not use stolen on MTL due to HW bug (Nirmoy) - Check HuC and GuC version compatibility on MTL (Daniele) - Dump perf_limit_reasons for slow GuC init debug (Vinay) - Replace kmap() with kmap_local_page() (Sumitra, Ira) - Add sentinel to xehp_oa_b_counters for KASAN (Andrzej) - Add the gen12_needs_ccs_aux_inv helper (Andi) - Fixes and updates for GSC memory allocation (Daniele) - Fix one wrong caching mode enum usage (Tvrtko) - Fixes for GSC wakeref (Alan) - Static checker fixes (Harshit, Arnd, Dan, Cristophe, David, Andi) - Rename flags with bit_group_X according to the datasheet (Andi) - Use direct alias for i915 in requests (Andrzej) - Replace i915->gt0 with to_gt(i915) (Andi) - Use the i915_vma_flush_writes helper (Tvrtko) - Selftest improvements (Alan) - Remove dead code (Tvrtko) Alan Previn (3): drm/i915/gsc: take a wakeref for the proxy-init-completion check drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefs drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests Andi Shyti (8): drm/i915: Replace i915->gt0 with to_gt(i915) drm/i915/gt: Cleanup aux invalidation registers drm/i915: Add the gen12_needs_ccs_aux_inv helper drm/i915/gt: Rename flags with bit_group_X according to the
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here's the drm-intel-fixes PR for v6.4-rc6. Couple of display compatibility fixes and two static checker fixes for selftests. Regards, Joonas *** drm-intel-fixes-2023-06-08: CDCLK voltage fix for ADL-P and eDP wake sync pulse fix. Two error handling fixes to selftests (to appease static checkers) The following changes since commit 9561de3a55bed6bdd44a12820ba81ec416e705a7: Linux 6.4-rc5 (2023-06-04 14:04:27 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-06-08 for you to fetch changes up to 79d0150d2d983a4f6efee676cea06027f586fcd0: drm/i915/selftests: Add some missing error propagation (2023-06-07 12:43:22 +0300) CDCLK voltage fix for ADL-P and eDP wake sync pulse fix. Two error handling fixes to selftests (to appease static checkers) Andi Shyti (1): drm/i915/gt: Use the correct error value when kernel_context() fails Chaitanya Kumar Borah (1): drm/i915/display: Set correct voltage level for 480MHz CDCLK Jouni Högander (1): drm/i915: Use 18 fast wake AUX sync len Tvrtko Ursulin (1): drm/i915/selftests: Add some missing error propagation drivers/gpu/drm/i915/display/intel_cdclk.c | 30 +++--- drivers/gpu/drm/i915/display/intel_dp_aux.c| 2 +- .../gpu/drm/i915/gem/selftests/i915_gem_context.c | 14 +++--- drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 ++--- 4 files changed, 45 insertions(+), 13 deletions(-)
Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
Quoting Andi Shyti (2023-06-06 13:18:06)
> On Tue, Jun 06, 2023 at 11:10:04AM +0100, Tvrtko Ursulin wrote:
> >
> > On 06/06/2023 11:00, Andi Shyti wrote:
> > > From: Fei Yang
> > >
> > > To comply with the design that buffer objects shall have immutable
> > > cache setting through out their life cycle, {set, get}_caching ioctl's
> > > are no longer supported from MTL onward. With that change caching
> > > policy can only be set at object creation time. The current code
> > > applies a default (platform dependent) cache setting for all objects.
> > > However this is not optimal for performance tuning. The patch extends
> > > the existing gem_create uAPI to let user set PAT index for the object
> > > at creation time.
> > > The new extension is platform independent, so UMD's can switch to using
> > > this extension for older platforms as well, while {set, get}_caching are
> > > still supported on these legacy paltforms for compatibility reason.
> > > However, since PAT index was not clearly defined for platforms prior to
> > > GEN12 (TGL), so we are limiting this externsion to GEN12+ platforms
> > > only. See ext_set_pat() in for the implementation details.
> > >
> > > Note: The documentation related to the PAT/MOCS tables is currently
> > > available for Tiger Lake here:
> > > https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/tiger-lake.html
> > >
> > > BSpec: 45101
> > >
> > > Mesa support has been submitted in this merge request:
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > >
> > > The media driver is supported by the following commits:
> > > https://github.com/intel/media-driver/commit/92c00a857433ebb34ec575e9834f473c6fcb6341
> > > https://github.com/intel/media-driver/commit/fd375cf2c5e1f6bf6b43258ff797b3134aadc9fd
> > > https://github.com/intel/media-driver/commit/08dd244b22484770a33464c2c8ae85430e548000
Andi, let's still get these corrected before merging once the media-driver
revert is completed.
Regards, Joonas
> > > The IGT test related to this change is
> > > igt@gem_create@create-ext-set-pat
> > >
> > > Signed-off-by: Fei Yang
> > > Cc: Chris Wilson
> > > Cc: Matt Roper
> > > Cc: Andi Shyti
> > > Reviewed-by: Andi Shyti
> > > Acked-by: Jordan Justen
> > > Tested-by: Jordan Justen
> > > Acked-by: Carl Zhang
> > > Tested-by: Lihao Gu
> > > Signed-off-by: Andi Shyti
> >
> > Acked-by: Tvrtko Ursulin
>
> Fiuuu! Thanks a lot, Tvrtko!
>
> As soon as CI gives green light, I will get this in.
>
> Andi
Re: [Intel-gfx] [PATCH v15 1/1] drm/i915: Allow user to set cache at BO creation
Quoting Yang, Fei (2023-06-06 09:51:06)
> >> On 31/05/2023 18:10, fei.y...@intel.com wrote:
> >>> From: Fei Yang
> >>>
> >>> To comply with the design that buffer objects shall have immutable
> >>> cache setting through out their life cycle, {set, get}_caching ioctl's
> >>> are no longer supported from MTL onward. With that change caching
> >>> policy can only be set at object creation time. The current code
> >>> applies a default (platform dependent) cache setting for all objects.
> >>> However this is not optimal for performance tuning. The patch extends
> >>> the existing gem_create uAPI to let user set PAT index for the object
> >>> at creation time.
> >>> The new extension is platform independent, so UMD's can switch to using
> >>> this extension for older platforms as well, while {set, get}_caching are
> >>> still supported on these legacy paltforms for compatibility reason.
> >>>
> >>> Note: The detailed description of PAT index is missing in current PRM
> >>> even for older hardware and will be added by the next PRM update under
> >>> chapter name "Memory Views".
> >>>
> >>> BSpec: 45101
> >>>
> >>> Mesa support has been submitted in this merge request:
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> >>>
> >>> The media driver is supported by the following commits:
> >>> https://github.com/intel/media-driver/commit/
> 92c00a857433ebb34ec575e9834f473c6fcb6341
> >>> https://github.com/intel/media-driver/commit/
> fd375cf2c5e1f6bf6b43258ff797b3134aadc9fd
> >>> https://github.com/intel/media-driver/commit/
> 08dd244b22484770a33464c2c8ae85430e548000
We absolutely should not have merged this code to master branch yet.
These should be reverted immediately and any releases that include the code
must be pulled back.
This is clearly explained in:
https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements
"The kernel patch can only be merged after all the above requirements
are met, but it *must* be merged to either drm-next or drm-misc-next
*before* the userspace patches land. uAPI always flows from the kernel,
doing things the other way round risks divergence of the uAPI
definitions and header files."
> >> On which platforms will media-driver use the uapi? I couldn't easily
> >> figure out myself from the links above and also in the master branch I
> >> couldn't find the implementation of CachePolicyGetPATIndex.
> >
> > These commits look like platform independent. Carl, could you chime in here?
>
> Confirmed with Carl and Lihao offline that the media driver is calling set_pat
> extension in common code path, so the use of set_pat extension is platform
> independent. The only problem right now is that the gmm library is not
> returning
> correct PAT index for all hardware platforms, so on some platforms the call
> would
> be bypassed and fall back to the old way.
That means the code is unused for older platforms. The fact that there
is potential to be used is not alone a reason for merging it.
So I agree with Tvrtko that we should only limit this to the newer
platforms where we have actual use that is ready and reviewed.
We can extend to older platforms later, but in order not to block the
progress please move the code for older platform to later series and
only apply to platforms where this is needed.
> I think this is the correct implementation. It should be platform independent
> as
> long as the application knows what PAT index to set. Updating the gmm library
> to
> understand PAT index for each hardware platform is a separate issue.
If we don't have userspace ready, we don't merge the code.
Regards, Joonas
> >> Now that PRMs for Tigerlake have been published and Meteorlake situation
> >> is documented indirectly in Mesa code, my only remaining concern is with
> >> the older platforms. So if there is no particular reason to have the
> >> extension working on those, I would strongly suggest we disable there.
> >
> > What's the concern? There is no change required for older platforms,
> > existing
> > user space code should continue to work. And this extension should be made
> > available for any new development because the cache settings for BO's need
> > to be immutable. And that is platform independent.
> >
> >> For a precedent see I915_CONTEXT_PARAM_SSEU and how it allows the
> >> extension only on Gen11 and only for a very specific usecase (see
> >> restrictions in set_sseu() and i915_gem_user_to_context_sseu()).
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>>
> >>> The IGT test related to this change is
> >>> igt@gem_create@create-ext-set-pat
> >>>
> >>> Signed-off-by: Fei Yang
> >>> Cc: Chris Wilson
> >>> Cc: Matt Roper
> >>> Cc: Andi Shyti
> >>> Reviewed-by: Andi Shyti
> >>> Acked-by: Jordan Justen
> >>> Tested-by: Jordan Justen
> >>> Acked-by: Carl Zhang
> >>> Tested-by: Lihao Gu
> >>> ---
> >>> drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
> >>> drivers/gpu/drm/i915/gem/i915_gem_object.c
[PULL] drm-intel-fixes
Hi Dave & Daniel, One fix appeared this morning, related to OA API for non-power-of-two reports. Full CI results not in yet, BAT is looking good so please check before pulling the trigger. Regards, Joonas *** drm-intel-fixes-2023-06-01: - Fix for OA reporting to allow detecting non-power-of-two reports The following changes since commit 7877cb91f1081754a1487c144d85dc0d2e2e7fc4: Linux 6.4-rc4 (2023-05-28 07:49:00 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-06-01 for you to fetch changes up to 62fe398761cd06a428e6f367aba84732a2f1c268: drm/i915/perf: Clear out entire reports after reading if not power of 2 size (2023-06-01 09:41:58 +0300) - Fix for OA reporting to allow detecting non-power-of-two reports Ashutosh Dixit (1): drm/i915/perf: Clear out entire reports after reading if not power of 2 size drivers/gpu/drm/i915/i915_perf.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes for v4.6-rc4. Again just one fix, for pipejoiner config pipe disabling. Regards, Joonas *** drm-intel-fixes-2023-05-25: PIPEDMC disabling fix for bigjoiner config The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511: Linux 6.4-rc3 (2023-05-21 14:05:48 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-25 for you to fetch changes up to 45dfbd992923f4df174db4e23b96fca7e30d73e2: drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration (2023-05-22 17:10:11 +0300) PIPEDMC disabling fix for bigjoiner config Imre Deak (1): drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration drivers/gpu/drm/i915/display/intel_display.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-)
Extension detection by enumeration vs attempt to use extension (Was: Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation)
Quoting Jordan Justen (2023-05-21 07:30:52)
> On 2023-05-18 22:11:03, wrote:
> > From: Fei Yang
> >
> > To comply with the design that buffer objects shall have immutable
> > cache setting through out their life cycle, {set, get}_caching ioctl's
> > are no longer supported from MTL onward. With that change caching
> > policy can only be set at object creation time. The current code
> > applies a default (platform dependent) cache setting for all objects.
> > However this is not optimal for performance tuning. The patch extends
> > the existing gem_create uAPI to let user set PAT index for the object
> > at creation time.
> > The new extension is platform independent, so UMD's can switch to using
> > this extension for older platforms as well, while {set, get}_caching are
> > still supported on these legacy paltforms for compatibility reason.
> >
> > Test igt@gem_create@create_ext_set_pat posted at
> > https://patchwork.freedesktop.org/series/117695/
> >
> > Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> >
> > Signed-off-by: Fei Yang
> > Cc: Chris Wilson
> > Cc: Matt Roper
> > Cc: Andi Shyti
> > Reviewed-by: Andi Shyti
> > Acked-by: Jordan Justen
>
> Nevertheless, I'm still disappointed my suggestion was so quickly shot
> down.
Sorry to hear that you feel that your suggestion was shot down quickly.
The intent was not to be rude. Attempt was just to make sure we're not
blocking an important patch due to repeat of an orthogonal discussion
which has been discussed to exhaustion in past.
There are pros and cons to both solutions, some of which were recapped
in the thread quickly. We can surely continue the discussion on the
details now that the patch is not blocked.
> I tried to look over our usage Mesa of i915 extensions, and found
> this:
>
> I915_GEM_CREATE_EXT_MEMORY_REGIONS:
>
> * If DRM_I915_QUERY_MEMORY_REGIONS is found
>
> I915_GEM_CREATE_EXT_PROTECTED_CONTENT:
>
> * Probed via the current "robust" method. Resulted in 8s driver
>startup delay in some bad scenarios.
I think this is an another orthogonal topic. Just listing the existence
of that extension in the kernel codebase would not really help.
The fact that an uAPI is known at compile time by kernel doesn't mean it
would not be defunctional / disabled / fused out on the specific system.
> * Will be guarded by I915_PARAM_PXP_STATUS when available in future
>
> I915_CONTEXT_CREATE_EXT_SETPARAM (I915_CONTEXT_PARAM_ENGINES):
>
> * If DRM_I915_QUERY_ENGINE_INFO is found
>
> I915_GEM_CREATE_EXT_SET_PAT:
>
> * When platform is mtl or newer
>
> I think we will continue to try to find workarounds that imply the
> extension's existence,
You're not supposed to just probe for existence of an extension in the
kernel codebase, but also check that the extension works on that system.
So probing for the extension array is just half the work. If the KMD
started to block out extensions from the array dynamically, then we
would be doing that based on adding heuristics that are better added in
the userspace. Ultimately you need to have the error handling for the
initialization added anyway to userspace, so there should not be that
much new code that needs adding.
Regards, Joonas
> but it could be nice to have a generic way to
> find out what extensions the kernel knows about.
>
> -Jordan
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes for v6.4-rc3. Just one missing null check addition for HDCP code. Regards, Joonas *** drm-intel-fixes-2023-05-17: Add missing null check for HDCP code. The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6: Linux 6.4-rc2 (2023-05-14 12:51:40 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-17 for you to fetch changes up to 5896f2d363d5cfb7510856c90d5e0ed934a1d340: drm/i915/hdcp: Check if media_gt exists (2023-05-15 10:42:35 +0300) Add missing null check for HDCP code. Suraj Kandpal (1): drm/i915/hdcp: Check if media_gt exists drivers/gpu/drm/i915/display/intel_hdcp.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes for v6.4-rc2. Important fix to taint kernel when force_probe is used, two display fixes (null deref/div-by-zero) and a GuC error capture register list correction. Regards, Joonas PS. Again had to remove one commit with incorrect Fixes: tag so check CI for results before you merge. *** drm-intel-fixes-2023-05-11-1: - Fix to taint kernel when force_probe is used - Null deref and div-by-zero fixes for display - GuC error capture fix for Xe devices The following changes since commit ac9a78681b921877518763ba0e89202254349d1b: Linux 6.4-rc1 (2023-05-07 13:34:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-11-1 for you to fetch changes up to 79c901c93562bdf1c84ce6c1b744fbbe4389a6eb: drm/i915: taint kernel when force probing unsupported devices (2023-05-11 14:11:59 +0300) - Fix to taint kernel when force_probe is used - Null deref and div-by-zero fixes for display - GuC error capture fix for Xe devices Jani Nikula (1): drm/i915: taint kernel when force probing unsupported devices John Harrison (1): drm/i915/guc: Don't capture Gen8 regs on Xe devices Nikita Zhandarovich (1): drm/i915/dp: prevent potential div-by-zero Stanislav Lisovskiy (1): drm/i915: Fix NULL ptr deref by checking new_crtc_state drivers/gpu/drm/i915/Kconfig | 12 +++- drivers/gpu/drm/i915/display/intel_atomic_plane.c | 4 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 5 + drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 7 +-- drivers/gpu/drm/i915/i915_pci.c | 6 ++ 5 files changed, 25 insertions(+), 9 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, One Cc stable DSI sequence fix and missing CPU transcoders for MTL plus a smaller GuC cornern case fix. Best Regards, Joonas *** drm-intel-next-fixes-2023-05-04-1: Add missing GPU transcoder masks for MTL and fix DSI power on sequence for Nextbook Ares 8A. Fix GuC version corner case. The following changes since commit 2c69679626d5daa680d71c77ad58af0088db537f: drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams (2023-04-19 17:25:29 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-05-04-1 for you to fetch changes up to c8c2969bfcba5fcba3a5b078315c1b586d927d9f: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (2023-05-03 08:31:24 +0300) Add missing GPU transcoder masks for MTL and fix DSI power on sequence for Nextbook Ares 8A. Fix GuC version corner case. Hans de Goede (1): drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() John Harrison (1): drm/i915/guc: Actually return an error if GuC version range check fails Radhakrishna Sripada (1): drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info Ville Syrjälä (1): drm/i915: Check pipe source size when using skl+ scalers drivers/gpu/drm/i915/display/icl_dsi.c | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 --- drivers/gpu/drm/i915/display/intel_dsi_vbt.h | 1 - drivers/gpu/drm/i915/display/skl_scaler.c| 17 + drivers/gpu/drm/i915/display/vlv_dsi.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 drivers/gpu/drm/i915/i915_pci.c | 2 ++ 7 files changed, 37 insertions(+), 38 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one Cc stable SKL+ pipe source size fix for #8357: CML-U: external 5120x2160 monitor can't play video. Best Regards, Joonas *** drm-intel-next-fixes-2023-04-27: One cc stable for pipe source size check on SKL+ The following changes since commit 2c69679626d5daa680d71c77ad58af0088db537f: drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams (2023-04-19 17:25:29 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-04-27 for you to fetch changes up to d944eafed618a8507270b324ad9d5405bb7f0b3e: drm/i915: Check pipe source size when using skl+ scalers (2023-04-24 14:48:42 +0300) One cc stable for pipe source size check on SKL+ Ville Syrjälä (1): drm/i915: Check pipe source size when using skl+ scalers drivers/gpu/drm/i915/display/skl_scaler.c | 17 + 1 file changed, 17 insertions(+)
IOCTL feature detection (Was: Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation)
(+ Faith and Daniel as they have been involved in previous discussions) Quoting Jordan Justen (2023-04-24 20:13:00) > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote: > > > > Being able to "list" supported extensions sounds like a reasonable > > principle, albeit a departure from the design direction to date. > > Which means there are probably no quick solutions. Also, AFAIU, only > > PXP context create is the problematic one, right? Everything else is > > pretty much instant or delayed allocation so super cheap to probe by > > attempting to use. > > > > If I got that right and given this series is about > > drm_i915_gem_create_ext I don't think this side discussion should be > > blocking it. > > This still leaves the issue of no reasonable detection mechanism for > the extension. I remember this exact discussion being repeated at least a few times in the past 5 years. Previously the conclusion was always that detection by trying to use the extension leads to least amount of uAPI surface. There is also no concern of having mismatch in backporting of the query and the functionality patches. Why exactly do you think it is more reasonable to do the following? check_if_extension_query_is_supported(); check_if_extension_xyz_is_supported(); VS create_[context,buffer,whatever]_with_extension(); destroy_[context,buffer,whatever](); For contexts and buffers there's no overhead, and we're keeping the uAPI surface smaller (less bugs, less validation effort). Additionally we support checking combinations of extensions A, B and C without extra effort. If we're not returning enough clear errnos, then that is something to make sure we do. Regards, Joonas > If the discussion gets too complicated, then can we add > a GET_PARAM for the SET_PAT extension? I'm hoping we could either come > up with something better reasonably quickly, or i915/Xe can add a new > param for each new extensions until a better approach is available. > > > Furthermore the PXP context create story is even more complicated, > > in a way that it is not just about querying whether the extension is > > supported, but the expensive check is something more complicated. > > > > Going back to implementation details for this proposed new feature, > > one alternative to query could be something like: > > > >drm_i915_gem_create_ext.flags |= > > I915_GEM_CREATE_EXT_FLAG_PROBE_EXTENSIONS; > > > > That would be somewhat more light weight to implement that the > > i915_query route. And it appears it would work for all ioctls which > > support extensions apart for i915_context_param_engines. > > This seems little better than the "try it, and if it works then it's > supported". > > I'm not suggesting that userspace should be able to check that > scenario x+y+z will work, but more a list of extensions that > conceivably could work. Normally this should just a matter of the > kernel unconditionally adding the newly implemented extension to the > list returned in the query call. > > If a GET_PARAM can be made for the PXP case, then it seems like a > query item returning CONTEXT_CREATE extensions could conditionally > omit that extension just as easily as implementing the proposed new > GET_PARAM. > > -Jordan
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Here's another drm-intel-next-fixes pull request. One Cc stable CSC plane index fix, then MST PLL fix and smaller null/oob/leak fixes. Regards, Joonas *** drm-intel-next-fixes-2023-04-20-1: Active port PLL MST fix for second stream, CSC plane index fix, null and oob array deref fixes and selftest memory leak fix. The following changes since commit 81900e3a37750d8c6ad705045310e002f6dd0356: drm/i915: disable sampler indirect state in bindless heap (2023-04-12 11:36:09 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-04-20-1 for you to fetch changes up to 2c69679626d5daa680d71c77ad58af0088db537f: drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams (2023-04-19 17:25:29 +0300) Active port PLL MST fix for second stream, CSC plane index fix, null and oob array deref fixes and selftest memory leak fix. Chaitanya Kumar Borah (1): drm/i915/color: Fix typo for Plane CSC indexes Cong Liu (1): drm/i915: Fix memory leaks in i915 selftests Imre Deak (1): drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams Lucas De Marchi (1): drm/i915/gt: Avoid out-of-bounds access when loading HuC Ville Syrjälä (1): drm/i915: Make intel_get_crtc_new_encoder() less oopsy drivers/gpu/drm/i915/display/intel_ddi.c | 27 --- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +++ drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 +++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 21 + drivers/gpu/drm/i915/i915_reg.h | 4 ++-- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++- 7 files changed, 53 insertions(+), 15 deletions(-)
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one Cc:stable fix for indirect sampler state this week on drm-intel-next-fixes. Regards, Joonas *** drm-intel-next-fixes-2023-04-13: Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585: Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next (2023-04-11 12:28:10 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-04-13 for you to fetch changes up to 81900e3a37750d8c6ad705045310e002f6dd0356: drm/i915: disable sampler indirect state in bindless heap (2023-04-12 11:36:09 +0300) Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. Lionel Landwerlin (1): drm/i915: disable sampler indirect state in bindless heap drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 19 +++ 2 files changed, 20 insertions(+)
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the final drm-intel-gt-next pull request for v6.4. As top items we have a fix for context runtime accounting, Meteorlake enabling, DMAR error noise elimination due to GPU error capture, BAR resizing forcewake fix and memory contents clearing fix for discrete. More robust GuC loading on systems with IFWI that leaves GPU to slow frequency and a potential UAF closed on perf add_config IOCTL. There is also change to the uAPI headers to eliminate flexible-array member kernel-wide request, which does not impact binaries and also should not impact compilation. Then the usual amount of smaller fixes and cleanups. A good amount of kerneldoc fixes included. Best Regards, Joonas *** drm-intel-gt-next-2023-04-06: UAPI Changes: - (Build-time only, should not have any impact) drm/i915/uapi: Replace fake flex-array with flexible-array member "Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead." This is on core kernel request moving towards GCC 13. Driver Changes: - Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko) - Add support for OA media units on MTL (Umesh) - Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar) - Fix sysfs to read actual frequency for MTL and Gen6 and earlier (Ashutosh) - Synchronize i915/BIOS on C6 enabling on MTL (Vinay) - Fix DMAR error noise due to GPU error capture (Andrej) - Fix forcewake during BAR resize on discrete (Andrzej) - Flush lmem contents after construction on discrete (Chris) - Fix GuC loading timeout on systems where IFWI programs low boot frequency (John) - Fix race condition UAF in i915_perf_add_config_ioctl (Min) - Sanitycheck MMIO access early in driver load and during forcewake (Matt) - Wakeref fixes for GuC RC error scenario and active VM tracking (Chris) - Cancel HuC delayed load timer on reset (Daniele) - Limit double GT reset to pre-MTL (Daniele) - Use i915 instead of dev_priv insied the file_priv structure (Andi) - Improve GuC load error reporting (John) - Simplify VCS/BSD engine selection logic (Tvrtko) - Perform uc late init after probe error injection (Andrzej) - Fix format for perf_limit_reasons in debugfs (Vinay) - Create per-gt debugfs files (Andi) - Documentation and kerneldoc fixes (Nirmoy, Lee) - Selftest improvements (Fei, Jonathan) The following changes since commit d2a9692ad4295e227e3352fdbf14b8491b01e1c9: drm/i915/gt: make kobj attributes const (2023-03-15 12:20:11 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-04-06 for you to fetch changes up to 4b51210f98c2b89ce37aede5b8dc5105be0572c6: drm/i915/mtl: Add Wa_14017856879 (2023-04-05 07:59:12 -0700) UAPI Changes: - (Build-time only, should not have any impact) drm/i915/uapi: Replace fake flex-array with flexible-array member "Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead." This is on core kernel request moving towards GCC 13. Driver Changes: - Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko) - Add support for OA media units on MTL (Umesh) - Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar) - Fix sysfs to read actual frequency for MTL and Gen6 and earlier (Ashutosh) - Synchronize i915/BIOS on C6 enabling on MTL (Vinay) - Fix DMAR error noise due to GPU error capture (Andrej) - Fix forcewake during BAR resize on discrete (Andrzej) - Flush lmem contents after construction on discrete (Chris) - Fix GuC loading timeout on systems where IFWI programs low boot frequency (John) - Fix race condition UAF in i915_perf_add_config_ioctl (Min) - Sanitycheck MMIO access early in driver load and during forcewake (Matt) - Wakeref fixes for GuC RC error scenario and active VM tracking (Chris) - Cancel HuC delayed load timer on reset (Daniele) - Limit double GT reset to pre-MTL (Daniele) - Use i915 instead of dev_priv insied the file_priv structure (Andi) - Improve GuC load error reporting (John) - Simplify VCS/BSD engine selection logic (Tvrtko) - Perform uc late init after probe error injection (Andrzej) - Fix format for perf_limit_reasons in debugfs (Vinay) - Create per-gt debugfs files (Andi) - Documentation and kerneldoc fixes (Nirmoy, Lee) - Selftest improvements (Fei, Jonathan) Andi Shyti (3): drm/i915/gt: Create per-gt debugfs files drm/i915/debugfs: Enable upper layer interfaces to act on all gt's drm/i915: Use i915 instead of dev_priv insied the file_priv structure Andrzej Hajda (4): drm/i915/gt: prevent forcewake releases during BAR resize drm/i915/gt: introduce vm->scratch_range callback drm/i915: add guard page to ggtt->error_capture drm/i915/
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here's the first batch of drm-intel-gt-next towards v6.4. There is an important performance monitoring fix (#6333), more resiliency to pcode load delay and avoiding caching problems on LLC systems for ring buffers. Stolen memory probing fix and a missing register whitelisting for Gen12. Fix for potential OOB access on SSEU max_subslices array. Improvements to error capture on GuC, corrections to workarounds power domains across Gen11/Gen12 with subject to runtime PM. Then the regular bunch of smaller tweaks, restructuring and cleanups not to forget documentation, sparse and selftest improvements. Regards, Joonas *** drm-intel-gt-next-2023-03-16: Driver Changes: - Fix issue #6333: "list_add corruption" and full system lockup from performance monitoring (Janusz) - Give the punit time to settle before fatally failing (Aravind, Chris) - Don't use stolen memory or BAR for ring buffers on LLC platforms (John) - Add missing ecodes and correct timeline seqno on GuC error captures (John) - Make sure DSM size has correct 1MiB granularity on Gen12+ (Nirmoy, Lucas) - Fix potential SSEU max_subslices array-index-out-of-bounds access on Gen11 (Andrea) - Whitelist COMMON_SLICE_CHICKEN3 for UMD access on Gen12+ (Matt R.) - Apply Wa_1408615072/Wa_1407596294 correctly on Gen11 (Matt R) - Apply LNCF/LBCF workarounds correctly on XeHP SDV/PVC/DG2 (Matt R) - Implement Wa_1606376872 for Xe_LP (Gustavo) - Consider GSI offset when doing MCR lookups on Meteorlake+ (Matt R.) - Add engine TLB invalidation for Meteorlake (Matt R.) - Fix GSC Driver-FLR completion on Meteorlake (Alan) - Fix GSC races on driver load/unload on Meteorlake+ (Daniele) - Disable MC6 for MTL A step (Badal) - Consolidate TLB invalidation flow (Tvrtko) - Improve debug GuC/HuC debug messages (Michal Wa., John) - Move fd_install after last use of fence (Rob) - Initialize the obj flags for shmem objects (Aravind) - Fix missing debug object activation (Nirmoy) - Probe lmem before the stolen portion (Matt A) - Improve clean up of GuC busyness stats worker (John) - Fix missing return code checks in GuC submission init (John) - Annotate two more workaround/tuning registers as MCR on PVC (Matt R) - Fix GEN8_MISCCPCTL definition and remove unused INF_UNIT_LEVEL_CLKGATE (Lucas) - Use sysfs_emit() and sysfs_emit_at() (Nirmoy) - Make kobj_type structures constant (Thomas W.) - make kobj attributes const on gt/ (Jani) - Remove the unused virtualized start hack on buddy allocator (Matt A) - Remove redundant check for DG1 (Lucas) - Move DG2 tuning to the right function (Lucas) - Rename dev_priv to i915 for private data naming consistency in gt/ (Andi) - Remove unnecessary whitelisting of CS_CTX_TIMESTAMP on Xe_HP platforms (Matt R.) - - Escape wildcard in method names in kerneldoc (Bagas) - Selftest improvements (Chris, Jonathan, Tvrtko, Anshuman, Tejas) - Fix sparse warnings (Jani) The following changes since commit 003e11ed2ef4af01b808f0f193eaa5a32f32383b: drm/i915/mtl: Wa_22011802037: don't complain about missing regs on MTL (2023-01-31 15:17:30 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-03-16 for you to fetch changes up to d2a9692ad4295e227e3352fdbf14b8491b01e1c9: drm/i915/gt: make kobj attributes const (2023-03-15 12:20:11 +0200) Driver Changes: - Fix issue #6333: "list_add corruption" and full system lockup from performance monitoring (Janusz) - Give the punit time to settle before fatally failing (Aravind, Chris) - Don't use stolen memory or BAR for ring buffers on LLC platforms (John) - Add missing ecodes and correct timeline seqno on GuC error captures (John) - Make sure DSM size has correct 1MiB granularity on Gen12+ (Nirmoy, Lucas) - Fix potential SSEU max_subslices array-index-out-of-bounds access on Gen11 (Andrea) - Whitelist COMMON_SLICE_CHICKEN3 for UMD access on Gen12+ (Matt R.) - Apply Wa_1408615072/Wa_1407596294 correctly on Gen11 (Matt R) - Apply LNCF/LBCF workarounds correctly on XeHP SDV/PVC/DG2 (Matt R) - Implement Wa_1606376872 for Xe_LP (Gustavo) - Consider GSI offset when doing MCR lookups on Meteorlake+ (Matt R.) - Add engine TLB invalidation for Meteorlake (Matt R.) - Fix GSC Driver-FLR completion on Meteorlake (Alan) - Fix GSC races on driver load/unload on Meteorlake+ (Daniele) - Disable MC6 for MTL A step (Badal) - Consolidate TLB invalidation flow (Tvrtko) - Improve debug GuC/HuC debug messages (Michal Wa., John) - Move fd_install after last use of fence (Rob) - Initialize the obj flags for shmem objects (Aravind) - Fix missing debug object activation (Nirmoy) - Probe lmem before the stolen portion (Matt A) - Improve clean up of GuC busyness stats worker (John) - Fix missing return code checks in GuC submission init (John) - Annotate two more workaround/tuning registers as MCR on PVC (Matt R) - Fix GEN8_MISCCPCTL definition and remove unused INF_UNIT_LE
Re: [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
(+ Tvrtko as FYI) Zhenyu, can you take a look at the patch ASAP. Regards, Joonas Quoting Dave Airlie (2022-10-27 08:12:31) > On Thu, 27 Oct 2022 at 13:26, Zheng Hacker wrote: > > > > Dave Airlie 于2022年10月27日周四 08:01写道： > > > > > > On Fri, 7 Oct 2022 at 11:38, Zheng Wang wrote: > > > > > > > > If intel_gvt_dma_map_guest_page failed, it will call > > > > ppgtt_invalidate_spt, which will finally free the spt. > > > > But the caller does not notice that, it will free spt again in error > > > > path. > > > > > > > > Fix this by spliting invalidate and free in ppgtt_invalidate_spt. > > > > Only free spt when in good case. > > > > > > > > Reported-by: Zheng Wang > > > > Signed-off-by: Zheng Wang > > > > > > Has this landed in a tree yet, since it's a possible CVE, might be > > > good to merge it somewhere. > > > > > > Dave. > > > > > > > Hi Dave, > > > > This patched hasn't been merged yet. Could you please help with this? > > I'll add some more people who can probably look at it. > > Dave.
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the last drm-intel-gt-next feature pull req for v6.2. We have a couple of important fixes around memory management (TTM and userptr), then demoting GuC kernel contexts to normal priority and Meteorlake enabling. Beyond that it's smaller fixes to code structure and corner cases. Note the backmerge of drm-next to bring in v6.1-rc1 which had needed dependencies for which I gave heads-up in IRC. Regards, Joonas ** drm-intel-gt-next-2022-11-18: Core Changes: - Backmerge of drm-next Driver Changes: - Restore probe_range behaviour for userptr (Matt A) - Fix use-after-free on lmem_userfault_list (Matt A) - Never purge busy TTM objects (Matt A) - Meteorlake enabling (Daniele, Badal, Daniele, Stuart, Aravind, Alan) - Demote GuC kernel contexts to normal priority (John) - Use RC6 residency types as arguments to residency functions (Ashutosh, Rodrigo, Jani) - Convert some legacy DRM debugging macros to new ones (Tvrtko) - Don't deadlock GuC busyness stats vs reset (John) - Remove excessive line feeds in GuC state dumps (John) - Use i915_sg_dma_sizes() for all backends (Matt A) - Prefer REG_FIELD_GET in intel_rps_get_cagf (Ashutosh, Rodrigo) - Use GEN12_RPSTAT register for GT freq (Don, Badal, Ashutosh) - Remove unwanted TTM ghost obj check (Matt A) - Update workaround documentation (Lucas) - Coding style and static checker fixes and cleanups (Jani, Umesh, Tvrtko, Lucas, Andrzej) - Selftest improvements (Chris, Daniele, Riana, Andrzej) The following changes since commit 60ba8c5bd94e17ab4b024f5cecf8b48e2cf36412: Merge tag 'drm-intel-gt-next-2022-11-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-04 17:33:34 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-11-18 for you to fetch changes up to 4bb9ca7ee07455bec0a802ecf0aa5b09496888e2: drm/i915/mtl: C6 residency and C state type for MTL SAMedia (2022-11-17 10:47:12 -0500) Core Changes: - Backmerge of drm-next Driver Changes: - Restore probe_range behaviour for userptr (Matt A) - Fix use-after-free on lmem_userfault_list (Matt A) - Never purge busy TTM objects (Matt A) - Meteorlake enabling (Daniele, Badal, Daniele, Stuart, Aravind, Alan) - Demote GuC kernel contexts to normal priority (John) - Use RC6 residency types as arguments to residency functions (Ashutosh, Rodrigo, Jani) - Convert some legacy DRM debugging macros to new ones (Tvrtko) - Don't deadlock GuC busyness stats vs reset (John) - Remove excessive line feeds in GuC state dumps (John) - Use i915_sg_dma_sizes() for all backends (Matt A) - Prefer REG_FIELD_GET in intel_rps_get_cagf (Ashutosh, Rodrigo) - Use GEN12_RPSTAT register for GT freq (Don, Badal, Ashutosh) - Remove unwanted TTM ghost obj check (Matt A) - Update workaround documentation (Lucas) - Coding style and static checker fixes and cleanups (Jani, Umesh, Tvrtko, Lucas, Andrzej) - Selftest improvements (Chris, Daniele, Riana, Andrzej) Alan Previn (1): drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43 Andrzej Hajda (2): drm/i915: call i915_request_await_object from _i915_vma_move_to_active drm/i915/selftests: add igt_vma_move_to_active_unlocked Aravind Iddamsetty (1): drm/i915/mtl: Handle wopcm per-GT and limit calculations. Ashutosh Dixit (2): drm/i915/rps: Prefer REG_FIELD_GET in intel_rps_get_cagf drm/i915/gt: Use RC6 residency types as arguments to residency functions Badal Nilawar (3): drm/i915/mtl: Add Wa_14017073508 for SAMedia drm/i915/mtl: Modify CAGF functions for MTL drm/i915/mtl: C6 residency and C state type for MTL SAMedia Chris Wilson (1): drm/i915/selftests: Reduce oversaturation of request smoketesting Daniele Ceraolo Spurio (12): drm/i915/mtl: add initial definitions for GSC CS drm/i915/mtl: pass the GSC CS info to the GuC drm/i915/mtl: add GSC CS interrupt support drm/i915/mtl: add GSC CS reset support drm/i915/mtl: don't expose GSC command streamer to the user drm/i915/guc: don't hardcode BCS0 in guc_hang selftest drm/i915/huc: only load HuC on GTs that have VCS engines drm/i915/uc: fetch uc firmwares for each GT drm/i915/uc: use different ggtt pin offsets for uc loads drm/i915/guc: define media GT GuC send regs drm/i915/guc: handle interrupts from media GuC drm/i915/guc: add the GSC CS to the GuC capture list Don Hiatt (1): drm/i915: Use GEN12_RPSTAT register for GT freq Jani Nikula (1): drm/i915/pxp: use <> instead of "" for headers in include/ John Harrison (3): drm/i915/guc: Remove excessive line feeds in state dumps drm/i915/guc: Properly initialise kernel contexts drm/i915/guc: Don
[PULL] drm-intel-gt-next
Hi Dave & Daniel, This amends the previous PR that did cause a build error with clang: https://lists.freedesktop.org/archives/dri-devel/2022-October/377713.html Quite naturally, it includes a fix to the hwmon code tested with Clang version 14.0.5 and GCC 12.2.1. Additionally there is a screen flickering fix for DG2 (#7306) abd one more DG2 W/A. Eliminating spurious WARN on DG1. Dust up Gen2-Gen5 machines to apply and test the latest CS timestamping fixes for from Ville (archeologist, neutral, human). Then a few more smaller cleanups and selftest additions. Regards, Joonas *** drm-intel-gt-next-2022-11-03: Driver Changes: - Fix for #7306: [Arc A380] white flickering when using arc as a secondary gpu (Matt A) - Add Wa_18017747507 for DG2 (Wayne) - Avoid spurious WARN on DG1 due to incorrect cache_dirty flag (Niranjana, Matt A) - Corrections to CS timestamp support for Gen5 and earlier (Ville) - Fix a build error used with clang compiler on hwmon (GG) - Improvements to LMEM handling with RPM (Anshuman, Matt A) - Cleanups in dmabuf code (Mike) - Selftest improvements (Matt A) The following changes since commit 7860d720a84c74b2761c6b7995392a798ab0a3cb: drm/msm: Fix build break with recent mm tree (2022-09-30 10:13:49 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-11-03 for you to fetch changes up to 8f956e9a2c9bdb22ac50c8b7656e2ea29c2e656c: drm/i915/hwmon: Fix a build error used with clang compiler (2022-11-03 09:34:22 +0200) Driver Changes: - Fix for #7306: [Arc A380] white flickering when using arc as a secondary gpu (Matt A) - Add Wa_18017747507 for DG2 (Wayne) - Avoid spurious WARN on DG1 due to incorrect cache_dirty flag (Niranjana, Matt A) - Corrections to CS timestamp support for Gen5 and earlier (Ville) - Fix a build error used with clang compiler on hwmon (GG) - Improvements to LMEM handling with RPM (Anshuman, Matt A) - Cleanups in dmabuf code (Mike) - Selftest improvements (Matt A) Alan Previn (4): drm/i915/guc: Add error-capture init warnings when needed drm/i915/guc: Add compute reglist for guc err capture drm/i915/guc: Fix GuC error capture sizing estimation and reporting drm/i915/guc: Remove intel_context:number_committed_requests counter Andi Shyti (1): drm/i915/trace: Remove unused frequency trace Andrzej Hajda (2): drm/i915: use intel_uncore_rmw when appropriate drm/i915/gt: use intel_uncore_rmw when appropriate Anshuman Gupta (2): drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual Aravind Iddamsetty (1): drm/i915/mtl: enable local stolen memory Ashutosh Dixit (5): drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL drm/i915/rps: Freq caps for MTL drm/i915: Perf_limit_reasons are only available for Gen11+ drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Chris Wilson (6): drm/i915/gt: Cleanup partial engine discovery failures drm/i915/gem: Really move i915_gem_context.link under ref protection drm/i915/gt: Restrict forced preemption to the active context drm/i915/gt: Use i915_vm_put on ppgtt_create error paths drm/i915/gt: Move scratch page into system memory on all platforms drm/i915/gt: Bump the reset-failure timeout to 60s Colin Ian King (2): drm/i915/gem: remove redundant assignments to variable ret drm/i915/perf: remove redundant variable 'taken' Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Daniele Ceraolo Spurio (7): drm/i915/pxp: load the pxp module when we have a gsc-loaded huc drm/i915/dg2: setup HuC loading via GSC drm/i915/huc: track delayed HuC load with a fence drm/i915/huc: stall media submission until HuC is loaded drm/i915/huc: better define HuC status getparam possible return values. drm/i915/huc: define gsc-compatible HuC fw for DG2 drm/i915/huc: bump timeout for delayed load and reduce print verbosity Gustavo Sousa (1): drm/i915/xelp: Add Wa_1806527549 Gwan-gyeong Mun (2): drm/i915/gt: Remove unused function prototype drm/i915/hwmon: Fix a build error used with clang compiler Jani Nikula (1): drm/i915: move i915_coherent_map_type() to i915_gem_pages.c and un-inline Janusz Krzysztofik (1): drm/i915/gem: Flush contexts on driver release John Harrison (6): drm/i915/guc: Fix release build bug in 'remove log size module parameters' drm/i915/guc: Enable compute scheduling on DG2 drm/i915/guc: Limit scheduling properties to avoi
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes first drm-intel-gt-next pull req towards 6.2. We have a fix for #6222 (kernel memory corruption issue) and fix for display regression after resume. A missing W/A for Gen12 iGPUs and extension of compute pre-emption timeout to 7.5 seconds to account for compute corner cases. Improvements to GuC compute error capture, scheduling hysteresis and SLPC. Fixes to EHL MOCS tables. Better docs for I915_PARAM_HUC_STATUS and pre-emption control policy. Extending the grace period for full GPU reset timeout to 60 seconds to better capture logs or recover, as opposed to just giving up on whole device in 5 seconds. We're starting to add HWMON metrics for recent devices. More MTL enabling, DG2 workarounds, DG2 HuC support, OA for DG2 is enabled. Small bar enabling, PS64 support added for DG2 page tables. ptrace support for local memory objects, local-memory migration for display surfaces. Note that there is drm/drm-next backmerge and then MEI subsystem patches around GSC/PXP which are intertwined with i915 change so merged here as agreed with Tomas and Greg. Additionally the usual amount of refactoring, cleanups, debugging improvements and static checker fixes. Regards, Joonas PS. Once you have pulled this, I will backmerge drm-next to bring in more dependencies for upcoming patches. *** drm-intel-gt-next-2022-10-31: - Start adding HWMON metrics (Dale, Ashutosh, Riana, Badal) See Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon Cross-subsystem Changes: - MEI subsystem patches for GSC/PXP (Vitaly, Tomas) * R-b'd by Greg, agreed to merge via drm-intel-gt-next - Backmerge of drm/drm-next to pull misc/mei changes for DG2 HuC Driver Changes: - Fix for #6222: Kernel memory corruption when running piglit with OA enabled (Chris) - Add Wa_1806527549 for Gen12 iGPU (Gustavo) - Fix display problems after resume regression (Thomas) - Extend pre-emption timeout to 7.5 seconds on compute capable engines on Gen12 (John) - Add error compute registers to GuC error capture list (Alan) - Delay disabling guc_id scheduling for better hysteresis (Matt B) - Use platform min/max frequency with GuC SLPC (Vinay) - Meteorlake (MTL) enabling (Ashutosh, Matt R, Aravind) - Add more DG2 workarounds (Matt A) - DG2 HuC loading (Daniele) - Enable OA support for DG2 (Umesh, Vinay, Lionel) - Better document I915_PARAM_HUC_STATUS error codes (Daniele) - Enable compute scheduling on DG2 (John) - Small bar enabling for dGPU (Matt A) - Enable PS64 support for DG2 (Matt A) - Handle migration to local-memory for display surfaces (Matt A) - Update MOCS table for EHL (Tejas) - Limit GuC scheduling properties to avoid overflow (John) - Update forcewake domain for CCS register ranges for PVC (Matt R) - Implement access_memory for local memory to enable ptrace (Matt A) - Document and future-proof preemption control policy (Matt R) - Restrict forced preemption to the active context (Chris) - Move scratch page into system memory on all platforms (Chris) - Flush to global observation point before breadcrumb write (Prathap, Nirmoy) - Bump the reset-failure timeout to 60s (Chris) - Codebase restructuring for more clarity (Lucas, Jani, Vinay, Nirmoy, Ville, Andrzej) - Stop abusing swiotlb_max_segment (Robert, Christoph) - Fix a potential UAF at device unload (Nirmoy, Chris) - Fix revocation of non-persistent contexts with GuC (Tvrtko) - Fix GuC error capture sizing estimation and reporting (Alan) - Make failure to setup stolen non-fatal on dGPU (Lucas) - Fixes to perf_limit_reasons and add to debugfs (Ashutosh, Tilak) - Release build fix for GuC log size removal (John) - Cleanup partial engine discovery failures (Chris) - Do not cleanup obj with NULL bo->resource (Nirmoy) - Split GAM and MSLICE steering (Matt R) - Flush GEM contexts on driver release (Janusz, Chris) - Multi GT suspend and resume enabling (Tvrtko) - Use i915_vm_put on ppgtt_create error paths (Chris) - Remove leftover code from previous cleanups (Niranjana, Nirmoy, Gwan-gyeong, Matt A, Andi, Alan, Karolina) - Selftest and debugging improvements (Tvrtko, Nirmoy, Riana, Vinay) - Static checker fixups (Colin, Nathan) - Documentation improvements (Lucas) The following changes since commit 7860d720a84c74b2761c6b7995392a798ab0a3cb: drm/msm: Fix build break with recent mm tree (2022-09-30 10:13:49 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-10-31 for you to fetch changes up to 876e9047a91839ee5be0ba099036d19883e52ca2: drm/i915/mtl: Add missing steering table terminators (2022-10-28 17:36:56 -0700) - Start adding HWMON metrics (Dale, Ashutosh, Riana, Badal) See Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon Cross-subsystem Changes: - MEI subsystem patches for GSC/PXP (Vitaly, Tomas) * R-b'd by Greg, agreed to merge via drm-intel-gt-next - Backmerge of drm/drm-next to pull mi
[PULL] drm-intel-gt-next
Hi Dave & Daniel,
Here goes the final drm-intel-gt-next towards 6.1.
For stable platforms we have fixes for throttle reasons decoding to sysfs, GuC
version update to 7.5, XeHP SDV GSC support and the usual pile of smaller fixes.
DG2 and DG1 runtime PM is now mostly fixed for LMEM access via mmap, but kernel
internal usages still need to be reviewed. There's also at least one LMEM code
NULL deref bug to resolve [1]. Finally a bunch of Meteorlake (MTL) enabling
patches.
Note that this PR includes patches going to mei subsystem, due to the tight
coupling of the MEI/GSC code. Those are Acked-by Greg.
Regards, Joonas
[1]
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12135/bat-dg2-11/igt@gem_lmem_swapping@ba...@lmem0.html
***
drm-intel-gt-next-2022-09-16:
Cross-subsystem Changes:
- MEI subsystem pieces for XeHP SDV GSC support
These are Acked-by Greg.
Driver Changes:
- Release mmaps on RPM suspend on discrete GPUs (Anshuman)
- Update GuC version to 7.5 on DG1, DG2 and ADL
- Revert "drm/i915/dg2: extend Wa_1409120013 to DG2" (Lucas)
- MTL enabling incl. standalone media (Matt R, Lucas)
- Explicitly clear BB_OFFSET for new contexts on Gen8+ (Chris)
- Fix throttling / perf limit reason decoding (Ashutosh)
- XeHP SDV GSC support (Vitaly, Alexander, Tomas)
- Fix issues with overrding firmware file paths (John)
- Invert if-else ladders to check latest version first (Lucas)
- Cancel GuC engine busyness worker synchronously (Umesh)
- Skip applying copy engine fuses outside PVC (Lucas)
- Eliminate Gen10 frequency read function (Lucas)
- Static code checker fixes (Gaosheng)
- Selftest improvements (Chris)
The following changes since commit 04f7eb3d4582a0a4da67c86e55fda7de2df86d91:
drm/i915: Set correct domains values at _i915_vma_move_to_active (2022-09-08
11:06:35 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-09-16
for you to fetch changes up to 8adc718881e0a70127f8843dd70e69a80de39352:
drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
(2022-09-15 18:43:33 -0700)
Cross-subsystem Changes:
- MEI subsystem pieces for XeHP SDV GSC support
These are Acked-by Greg.
Driver Changes:
- Release mmaps on RPM suspend on discrete GPUs (Anshuman)
- Update GuC version to 7.5 on DG1, DG2 and ADL
- Revert "drm/i915/dg2: extend Wa_1409120013 to DG2" (Lucas)
- MTL enabling incl. standalone media (Matt R, Lucas)
- Explicitly clear BB_OFFSET for new contexts on Gen8+ (Chris)
- Fix throttling / perf limit reason decoding (Ashutosh)
- XeHP SDV GSC support (Vitaly, Alexander, Tomas)
- Fix issues with overrding firmware file paths (John)
- Invert if-else ladders to check latest version first (Lucas)
- Cancel GuC engine busyness worker synchronously (Umesh)
- Skip applying copy engine fuses outside PVC (Lucas)
- Eliminate Gen10 frequency read function (Lucas)
- Static code checker fixes (Gaosheng)
- Selftest improvements (Chris)
Alexander Usyskin (5):
drm/i915/gsc: add slow_firmware flag to the gsc device definition
drm/i915/gsc: add GSC XeHP SDV platform definition
mei: gsc: wait for reset thread on stop
mei: extend timeouts on slow devices
mei: drop ready bits check after start
Anshuman Gupta (2):
drm/i915: Refactor userfault_wakeref to re-use
drm/i915/dgfx: Release mmap on rpm suspend
Ashutosh Dixit (1):
drm/i915/gt: Fix perf limit reasons bit positions
Chris Wilson (4):
drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
drm/i915/selftests: Check for incomplete LRI from the context image
drm/i915/selftest: Always cancel semaphore on error
drm/i915/selftest: Clear the output buffers before GPU writes
Gaosheng Cui (1):
drm/i915: remove unused i915_gem_lmem_obj_ops declaration
John Harrison (2):
drm/i915/uc: Fix issues with overriding firmware files
drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
Lucas De Marchi (7):
Revert "drm/i915/dg2: extend Wa_1409120013 to DG2"
drm/i915/gt: Use MEDIA_VER() when handling media fuses
drm/i915/gt: Extract function to apply media fuses
drm/i915: Skip applying copy engine fuses
drm/i915: Invert if/else ladder for frequency read
drm/i915/gt: Extract per-platform function for frequency read
drm/i915: Invert if/else ladder for stolen init
Matt Roper (14):
drm/i915: Move locking and unclaimed check into mmio_debug_{suspend,
resume}
drm/i915: Only hook up uncore->debug for primary uncore
drm/i915: Use managed allocations for extra uncore objects
drm/i915: Drop intel_gt_tile_cleanup()
drm/i915: Prepare more multi-GT initialization
drm/i915: Rename and expose common GT early init routine
drm/i915: Use a DRM-managed action to release the PCI bridge device
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting Joonas Lahtinen (2022-08-26 09:23:08) > Quoting John Harrison (2022-08-25 19:31:39) > > On 8/25/2022 00:15, Joonas Lahtinen wrote: > > > Quoting John Harrison (2022-08-24 21:45:09) > > >> We also don't want to tie the GuC logging buffer size to the DRM > > >> debugging output. Enabling kernel debug output can change timings and > > >> prevent the issue that one is trying to capture in the GuC log. And it > > >> seems unlikely we could add an entire new top level DRM debug flag just > > >> for an internal i915 only log buffer size. Plus drm.debug is explicitly > > >> stated as being dynamically changeable via sysfs at any time. The GuC > > >> log buffer size cannot be changed without reloading the i915 driver. Or > > >> at least, not without reloading the GuC, but we definitely don't want to > > >> create a UAPI for arbitrarily reloading the GuC. > > >> > > >> We can make these parameters 'unsafe' so that they taint the kernel if > > >> used. But this is exactly what module parameters are for - configuration > > >> that we don't want to hardcode as CONFIG options but which must be set > > >> at module load time. > > > It's better to have sane defaults. And if somebody wants something > > > strange, they can have a Kconfig behind EXPERT option. But even then > > > there should really be need for it. > > Define sane. > > I was hoping you would be the expert on that as you've suggested the > patch to begin with. > > Try to aim to cover >90% of the debug scenarios (that are only 0.001%) and > we're already only needing to recompile kernel in 1 per million cases. > > We can live with that. > > I will push a fixup to remove the module parameters, please figure the > rest out in a timely manner. John, what is the status of the followup patch here to configure those reasonable defaults? We shouldn't be ignoring this and proceed to pile other GuC patches on top. Regards, Joonas
[PULL] drm-intel-gt-next
ei_pxp bind (Juston) - Remove leftover verbose debug logging from GuC error capture (John) - Abort suspend on low system memory conditions (Nirmoy, Matt A, Chris) - Add DG2 Wa_16014892111 (Matt R) - Rename ggtt_view as gtt_view (Niranjana) - Consider HAS_FLAT_CCS() in needs_ccs_pages (Matt A) - Don't try to disable host RPS when this was never enabled. (Rodrigo) - Clear stalled GuC CT request after a reset (Daniele) - Remove runtime info printing from GuC time stamp logging (Jani) - Skip Bit12 fw domain reset for gen12+ (Sushma, Radhakrishna) - Make GuC log sizes runtime configurable (John) - Selftest improvements (Daniele, Matt B, Andrzej) Andrzej Hajda (1): drm/i915/selftests: allow misaligned_pin test work with unmappable memory Daniele Ceraolo Spurio (2): drm/i915/guc: skip scrub_ctbs selftest if reset is disabled drm/i915/guc: clear stalled request after a reset Jani Nikula (1): drm/i915/guc: remove runtime info printing from time stamp logging John Harrison (4): drm/i915/guc: Make GuC log sizes runtime configurable drm/i915/guc: Reduce spam from error capture drm/i915/uc: Support for version reduced and multiple firmware files drm/i915/uc: Add patch level version number support Joonas Lahtinen (1): drm/i915/guc: Remove log size module parameters Juston Li (1): drm/i915/pxp: don't start pxp without mei_pxp bind Matt Roper (5): drm/i915/mtl: MMIO range is now 4MB drm/i915/mtl: Don't mask off CCS according to DSS fusing drm/i915/dg2: Incorporate Wa_16014892111 into DRAW_WATERMARK tuning Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709" drm/i915/ats-m: Add thread execution tuning setting Matthew Auld (2): Revert "drm/i915/guc: Add delay to disable scheduling after pin count goes to zero" drm/i915: consider HAS_FLAT_CCS() in needs_ccs_pages Matthew Brost (2): drm/i915/selftests: Use correct selfest calls for live tests drm/i915/guc: Add delay to disable scheduling after pin count goes to zero Niranjana Vishwanathapura (1): drm/i915: Rename ggtt_view as gtt_view Nirmoy Das (2): drm/i915/ttm: Abort suspend on i915_ttm_backup failure drm/i915: Set correct domains values at _i915_vma_move_to_active Radhakrishna Sripada (1): drm/i915: Skip Bit12 fw domain reset for gen12+ Rodrigo Vivi (3): drm/i915/slpc: Fix inconsistent locked return drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC drm/i915: Don't try to disable host RPS when this was never enabled. Vinay Belgaumkar (1): drm/i915/guc/slpc: Allow SLPC to use efficient frequency drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_display.h | 2 +- drivers/gpu/drm/i915/display/intel_display_types.h | 2 +- drivers/gpu/drm/i915/display/intel_fb.c| 18 +- drivers/gpu/drm/i915/display/intel_fb_pin.c| 4 +- drivers/gpu/drm/i915/display/intel_fb_pin.h| 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 16 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c| 2 +- .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 6 +- .../gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h| 2 + drivers/gpu/drm/i915/gt/intel_llc.c| 19 +- drivers/gpu/drm/i915/gt/intel_lrc.c| 21 + drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/intel_rps.c| 60 ++- drivers/gpu/drm/i915/gt/intel_rps.h| 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c| 13 +- drivers/gpu/drm/i915/gt/selftest_slpc.c| 9 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 55 +-- drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 81 ++-- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 175 +++- drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 42 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c| 86 +--- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 462 ++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 39 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi
Re: [Intel-gfx] [PATCH] Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709"
Quoting Matt Roper (2022-08-27 00:02:33)
> This reverts commit ca6920811aa5428270dd78af0a7a36b10119065a.
>
> The intent of Wa_14015141709 was to inform us that userspace can no
> longer control object-level preemption as it has on past platforms
> (i.e., by twiddling register bit CS_CHICKEN1[0]). The description of
> the workaround in the spec wasn't terribly well-written, and when we
> requested clarification from the hardware teams we were told that on the
> kernel side we should also probably stop setting
> FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the
> hardware to honor the settings in per-context register CS_CHICKEN1. It
> turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a
> mistake; even though CS_CHICKEN1[0] is non-operational and useless to
> userspace, there are other bits in the register that do still work and
> might need to be adjusted by userspace in the future (e.g., to implement
> other workarounds that show up). If we don't set
> FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would
> not take effect.
Here we should be referencing Mesa/Compute runtime/etc. patches that
intend to use these other bits.
This is to ensure that they're actually aware of the hardware changes
ongoing and we end up with fully functional stack and not kernel doing
something other than the userspace attempts to do.
> This miscommunication came to light because another workaround
> (Wa_16013994831) has now shown up that requires userspace to adjust the
> value of CS_CHICKEN[10] in certain circumstances. To ensure userspace's
> updates to this chicken bit are handled properly by the hardware, we
> need to make sure that FF_SLICE_CS_CHICKEN1[14] is once again set by the
> kernel.
>
> Signed-off-by: Matt Roper
Not too many Cc:s for a patch that impacts uAPI. Even the original patch
being reverted definitely should have Cc:d mesa and some mesa devs.
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 ---
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3cdb8294e13f..69a0c6a74474 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2389,7 +2389,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> FF_DOP_CLOCK_GATE_DISABLE);
> }
>
> - if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
> + if (IS_GRAPHICS_VER(i915, 9, 12)) {
> /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
According to the commit description, this is not the W/A being supported
anymore by the whitelisting. Even if it's the same register we're talking about
different bits and different reasons.
We should clearly indicate that.
Can we have a followup patch where the reasoning is explained more
clearly and the userspace side changes are being referenced and at least
some userspace folks Cc'd?
Regards, Joonas
> wa_masked_en(wal,
> GEN7_FF_SLICE_CS_CHICKEN1,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b00ef3626db..d6a1ab6f65de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1352,9 +1352,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define HAS_GUC_DEPRIVILEGE(dev_priv) \
> (INTEL_INFO(dev_priv)->has_guc_deprivilege)
>
> -#define HAS_PERCTX_PREEMPT_CTRL(i915) \
> - ((GRAPHICS_VER(i915) >= 9) && GRAPHICS_VER_FULL(i915) < IP_VER(12,
> 55))
> -
> #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
> IS_ALDERLAKE_S(dev_priv))
>
> --
> 2.37.2
>
[PATCH v2] drm/i915/guc: Remove log size module parameters
Remove the module parameters for configuring GuC log size.
We should instead rely on tuning the defaults to be usable for
reporting bugs.
v2:
- Use correct 1M unit
Fixes: 8ad0152afb1b ("drm/i915/guc: Make GuC log sizes runtime configurable")
Signed-off-by: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: John Harrison
Cc: Alan Previn
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 7 +++
drivers/gpu/drm/i915/i915_params.c | 12
drivers/gpu/drm/i915/i915_params.h | 3 ---
3 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 3a2243b4ac9f..55d4b8f8e33e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -79,9 +79,9 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
}
};
s32 params[GUC_LOG_SECTIONS_LIMIT] = {
- i915->params.guc_log_size_crash,
- i915->params.guc_log_size_debug,
- i915->params.guc_log_size_capture,
+ GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE / SZ_1M,
+ GUC_LOG_DEFAULT_DEBUG_BUFFER_SIZE / SZ_1M,
+ GUC_LOG_DEFAULT_CAPTURE_BUFFER_SIZE / SZ_1M,
};
int i;
@@ -90,7 +90,6 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
/* If debug size > 1MB then bump default crash size to keep the same
units */
if (log->sizes[GUC_LOG_SECTIONS_DEBUG].bytes >= SZ_1M &&
- (i915->params.guc_log_size_crash == -1) &&
GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE < SZ_1M)
log->sizes[GUC_LOG_SECTIONS_CRASH].bytes = SZ_1M;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 06ca5b822111..6fc475a5db61 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -171,18 +171,6 @@ i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
"(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)");
-i915_param_named(guc_log_size_crash, int, 0400,
- "GuC firmware logging buffer size for crash dumps (in MB)"
- "(-1=auto [default], NB: max = 4, other restrictions apply)");
-
-i915_param_named(guc_log_size_debug, int, 0400,
- "GuC firmware logging buffer size for debug logs (in MB)"
- "(-1=auto [default], NB: max = 16, other restrictions apply)");
-
-i915_param_named(guc_log_size_capture, int, 0400,
- "GuC error capture register dump buffer size (in MB)"
- "(-1=auto [default], NB: max = 4, other restrictions apply)");
-
i915_param_named_unsafe(guc_firmware_path, charp, 0400,
"GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index f684d1ab8707..2733cb6cfe09 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,9 +61,6 @@ struct drm_printer;
param(int, invert_brightness, 0, 0600) \
param(int, enable_guc, -1, 0400) \
param(int, guc_log_level, -1, 0400) \
- param(int, guc_log_size_crash, -1, 0400) \
- param(int, guc_log_size_debug, -1, 0400) \
- param(int, guc_log_size_capture, -1, 0400) \
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \
param(char *, dmc_firmware_path, NULL, 0400) \
--
2.37.2
[PATCH] drm/i915/guc: Remove log size module parameters
Remove the module parameters for configuring GuC log size.
We should instead rely on tuning the defaults to be usable for
reporting bugs.
Fixes: 8ad0152afb1b ("drm/i915/guc: Make GuC log sizes runtime configurable")
Signed-off-by: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 7 +++
drivers/gpu/drm/i915/i915_params.c | 12
drivers/gpu/drm/i915/i915_params.h | 3 ---
3 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 3a2243b4ac9f..909e5079657b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -79,9 +79,9 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
}
};
s32 params[GUC_LOG_SECTIONS_LIMIT] = {
- i915->params.guc_log_size_crash,
- i915->params.guc_log_size_debug,
- i915->params.guc_log_size_capture,
+ GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE,
+ GUC_LOG_DEFAULT_DEBUG_BUFFER_SIZE,
+ GUC_LOG_DEFAULT_CAPTURE_BUFFER_SIZE,
};
int i;
@@ -90,7 +90,6 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
/* If debug size > 1MB then bump default crash size to keep the same
units */
if (log->sizes[GUC_LOG_SECTIONS_DEBUG].bytes >= SZ_1M &&
- (i915->params.guc_log_size_crash == -1) &&
GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE < SZ_1M)
log->sizes[GUC_LOG_SECTIONS_CRASH].bytes = SZ_1M;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 06ca5b822111..6fc475a5db61 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -171,18 +171,6 @@ i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
"(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)");
-i915_param_named(guc_log_size_crash, int, 0400,
- "GuC firmware logging buffer size for crash dumps (in MB)"
- "(-1=auto [default], NB: max = 4, other restrictions apply)");
-
-i915_param_named(guc_log_size_debug, int, 0400,
- "GuC firmware logging buffer size for debug logs (in MB)"
- "(-1=auto [default], NB: max = 16, other restrictions apply)");
-
-i915_param_named(guc_log_size_capture, int, 0400,
- "GuC error capture register dump buffer size (in MB)"
- "(-1=auto [default], NB: max = 4, other restrictions apply)");
-
i915_param_named_unsafe(guc_firmware_path, charp, 0400,
"GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index f684d1ab8707..2733cb6cfe09 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,9 +61,6 @@ struct drm_printer;
param(int, invert_brightness, 0, 0600) \
param(int, enable_guc, -1, 0400) \
param(int, guc_log_level, -1, 0400) \
- param(int, guc_log_size_crash, -1, 0400) \
- param(int, guc_log_size_debug, -1, 0400) \
- param(int, guc_log_size_capture, -1, 0400) \
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \
param(char *, dmc_firmware_path, NULL, 0400) \
--
2.37.2
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-25 19:31:39) > On 8/25/2022 00:15, Joonas Lahtinen wrote: > > Quoting John Harrison (2022-08-24 21:45:09) > >> On 8/24/2022 02:01, Joonas Lahtinen wrote: > >>> NACK on this one. Let's get this reverted or fixed to eliminate > >>> new module parameters. > >>> > >>> What prevents us just from using the maximum sizes? Or alternatively > >>> we could check the already existing drm.debug variable or anything else > >>> but addding 3 new module parameters. > >> We don't want to waste 24MB of memory for all users when 99.999% of them > >> don't care about GuC logs. > > It is not exactly wasting memory if it is what is needed to capture > > the error logs to properly debug a system. And it's definitely not much > > on any modern system where you will have a GPU. You can always leave > > the Kconfig options in place for the cases where it matters. > > > > On the other hand, if 99.999% don't need this, then it could just stay > > as a kernel config time option as well? > No. The point is that we need to able to ask customers to increase the > log size, repro an issue and send us the results. Or we could just ask them to provide the logs for each bug report and save one round trip time. > All on a pre-installed > system where they do not have the option to build a custom kernel. If you argue that way, they don't always have an easy way to change the kernel cmdline options either. Accounting for initrd, update-grub etc. > Either we always allocate the maximum and waste the memory for all end > users or we have a runtime configuration option. Doesn't have to be maximum (as there seems to be limitations in log readback speeds also), just something that is useful for most of the debug scenarios. > Compile time is not > acceptable for some important customers/situations. Yet spending the time discussing how to make the debug logs useful with the issue reporter wouldn't be an issue in such urgency? One can argue what is most convenient way, but there's no way to beat sane default. If somebody has problem with that extra memory usage, then we have the config options to reduce/disable. > >> We also don't want to tie the GuC logging buffer size to the DRM > >> debugging output. Enabling kernel debug output can change timings and > >> prevent the issue that one is trying to capture in the GuC log. And it > >> seems unlikely we could add an entire new top level DRM debug flag just > >> for an internal i915 only log buffer size. Plus drm.debug is explicitly > >> stated as being dynamically changeable via sysfs at any time. The GuC > >> log buffer size cannot be changed without reloading the i915 driver. Or > >> at least, not without reloading the GuC, but we definitely don't want to > >> create a UAPI for arbitrarily reloading the GuC. > >> > >> We can make these parameters 'unsafe' so that they taint the kernel if > >> used. But this is exactly what module parameters are for - configuration > >> that we don't want to hardcode as CONFIG options but which must be set > >> at module load time. > > It's better to have sane defaults. And if somebody wants something > > strange, they can have a Kconfig behind EXPERT option. But even then > > there should really be need for it. > Define sane. I was hoping you would be the expert on that as you've suggested the patch to begin with. Try to aim to cover >90% of the debug scenarios (that are only 0.001%) and we're already only needing to recompile kernel in 1 per million cases. We can live with that. I will push a fixup to remove the module parameters, please figure the rest out in a timely manner. Regards, Joonas > > Sane for most users is to not allocate 24MB of memory for an internal > debug only buffer they will never use. And which completely swamps any > error capture log with the ASCII encoding of said buffer. > > But as above, we need a way to (very occasionally) get larger GuC logs > from customers without rebuilding the kernel. > > John. > > > > > So for now, let's get the module parameters reverted and go with > > reasonable default buffer sizes when GuC is enabled. The compile time > > options can be left in place. > > > > Thank you in advance. > > > > Regards, Joonas > > > >> John. > >> > >>> For future reference, please do Cc maintainers when adding new uAPI > >>> like module parameters. > >>> > >>> Regards, Joonas > >>> > >>> Quotin
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-24 21:45:09)
> On 8/24/2022 02:01, Joonas Lahtinen wrote:
> > NACK on this one. Let's get this reverted or fixed to eliminate
> > new module parameters.
> >
> > What prevents us just from using the maximum sizes? Or alternatively
> > we could check the already existing drm.debug variable or anything else
> > but addding 3 new module parameters.
> We don't want to waste 24MB of memory for all users when 99.999% of them
> don't care about GuC logs.
It is not exactly wasting memory if it is what is needed to capture
the error logs to properly debug a system. And it's definitely not much
on any modern system where you will have a GPU. You can always leave
the Kconfig options in place for the cases where it matters.
On the other hand, if 99.999% don't need this, then it could just stay
as a kernel config time option as well?
> We also don't want to tie the GuC logging buffer size to the DRM
> debugging output. Enabling kernel debug output can change timings and
> prevent the issue that one is trying to capture in the GuC log. And it
> seems unlikely we could add an entire new top level DRM debug flag just
> for an internal i915 only log buffer size. Plus drm.debug is explicitly
> stated as being dynamically changeable via sysfs at any time. The GuC
> log buffer size cannot be changed without reloading the i915 driver. Or
> at least, not without reloading the GuC, but we definitely don't want to
> create a UAPI for arbitrarily reloading the GuC.
>
> We can make these parameters 'unsafe' so that they taint the kernel if
> used. But this is exactly what module parameters are for - configuration
> that we don't want to hardcode as CONFIG options but which must be set
> at module load time.
It's better to have sane defaults. And if somebody wants something
strange, they can have a Kconfig behind EXPERT option. But even then
there should really be need for it.
So for now, let's get the module parameters reverted and go with
reasonable default buffer sizes when GuC is enabled. The compile time
options can be left in place.
Thank you in advance.
Regards, Joonas
>
> John.
>
> >
> > For future reference, please do Cc maintainers when adding new uAPI
> > like module parameters.
> >
> > Regards, Joonas
> >
> > Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
> >> From: John Harrison
> >>
> >> The GuC log buffer sizes had to be configured statically at compile
> >> time. This can be quite troublesome when needing to get larger logs
> >> out of a released driver. So re-organise the code to allow a boot time
> >> module parameter override.
> >>
> >> Signed-off-by: John Harrison
> >> ---
> >> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
> >> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
> >> drivers/gpu/drm/i915/i915_params.c| 12 ++
> >> drivers/gpu/drm/i915/i915_params.h| 3 +
> >> 6 files changed, 226 insertions(+), 74 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> index ab4aacc516aa4..01f2705cb94a3 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> @@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc
> >> *guc)
> >>
> >> static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
> >> {
> >> - u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >>
> >> PAGE_SHIFT;
> >> - u32 flags;
> >> -
> >> - #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define LOG_UNIT SZ_1M
> >> - #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
> >> - #else
> >> - #define LOG_UNIT SZ_4K
> >> - #define LOG_FLAG 0
> >> - #endif
> >> -
> >> - #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define CAPTURE_UNIT SZ_1M
> >> - #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
> >> - #else
> >> - #define CAPTURE_UNIT SZ_4K
> >> - #define CAPTURE_FLAG 0
> >> - #endif
> >> -
> >> - BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> >> - BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
> >> -
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the first drm-intel-gt-next PR towards 6.1. Quite a small one. As primary things, there's the parallel support of GuC v69 and v70 which already went in via -fixes, improvements to the TLB invalidation performance regressions, further DG2 enabling and improved debugging for GuC errors. On top of that, locking simplification for freeing objects to avoid potential system freeze, addition of gt/gtN/.defaults (including freq to start), silencing some messages that are not errors. Regards, Joonas PS. I left a few commits out from top of drm-intel-gt-next as there is fixup needed for at least one. I will include those in the next PR. *** drm-intel-gt-next-2022-08-24: UAPI Changes: - Create gt/gtN/.defaults/ for per gt sysfs defaults Create a gt/gtN/.defaults/ directory (similar to engine//.defaults/) to expose default parameter values for each gt in sysfs. This allows userspace to restore default parameter values after they have changed. Driver Changes: - Support GuC v69 in parallel to v70 (Daniele) - Improve TLB invalidation to limit performance regression (Chris, Mauro) - Expose per-gt RPS defaults in sysfs (Ashutosh) - Suppress OOM warning for shmemfs object allocation failure (Chris, Nirmoy) - Disable PCI resize on 32-bit machines (Nirmoy) - Update DG2 to GuC v70.4.1 (John) - Fix CCS data copying on DG2 during swapping (Matt A) - Add DG2 performance tuning setting recommended by spec (Matt R) - Add GuC <-> kernel time stamp translation information to error logs (John) - Record GuC CTB info in error logs (John) - Route semaphores to GuC for Gen12+ when enabled (Michal Wi, John) - Improve resilency to bug #3575: Handle reset timeouts under unrelated kernel hangs (Chris, Ashutosh) - Avoid system freeze by removing shared locking on freeing objects (Chris, Nirmoy) - Demote GuC error "No response for request" into debug when expected (Zhanjun) - Fix GuC capture size warning and bump the size (John) - Use streaming loads to speed up dumping the GuC log (Chris, John) - Don't abort on CTB_UNUSED status from GuC (John) - Don't send spurious policy update for GuC child contexts (Daniele) - Don't leak the CCS state (Matt A) - Prefer drm_err over pr_err (John) - Eliminate unused calc_ctrl_surf_instr_size (Matt A) - Add dedicated function for non-ctx register tuning settings (Matt R) - Style and typo fixes, documentation improvements (Jason Wang, Mauro) - Selftest improvements (Matt B, Rahul, John) The following changes since commit 17cd10a44a8962860ff4ba351b2a290e752dbbde: drm/i915: Add lmem_bar_size modparam (2022-07-13 17:47:51 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-08-24 for you to fetch changes up to 5ece208ab05e4042c80ed1e6fe6d7ce236eee89b: drm/i915/guc: Use streaming loads to speed up dumping the guc log (2022-08-17 10:07:03 -0700) UAPI Changes: - Create gt/gtN/.defaults/ for per gt sysfs defaults Create a gt/gtN/.defaults/ directory (similar to engine//.defaults/) to expose default parameter values for each gt in sysfs. This allows userspace to restore default parameter values after they have changed. Driver Changes: - Support GuC v69 in parallel to v70 (Daniele) - Improve TLB invalidation to limit performance regression (Chris, Mauro) - Expose per-gt RPS defaults in sysfs (Ashutosh) - Suppress OOM warning for shmemfs object allocation failure (Chris, Nirmoy) - Disable PCI resize on 32-bit machines (Nirmoy) - Update DG2 to GuC v70.4.1 (John) - Fix CCS data copying on DG2 during swapping (Matt A) - Add DG2 performance tuning setting recommended by spec (Matt R) - Add GuC <-> kernel time stamp translation information to error logs (John) - Record GuC CTB info in error logs (John) - Route semaphores to GuC for Gen12+ when enabled (Michal Wi, John) - Improve resilency to bug #3575: Handle reset timeouts under unrelated kernel hangs (Chris, Ashutosh) - Avoid system freeze by removing shared locking on freeing objects (Chris, Nirmoy) - Demote GuC error "No response for request" into debug when expected (Zhanjun) - Fix GuC capture size warning and bump the size (John) - Use streaming loads to speed up dumping the GuC log (Chris, John) - Don't abort on CTB_UNUSED status from GuC (John) - Don't send spurious policy update for GuC child contexts (Daniele) - Don't leak the CCS state (Matt A) - Prefer drm_err over pr_err (John) - Eliminate unused calc_ctrl_surf_instr_size (Matt A) - Add dedicated function for non-ctx register tuning settings (Matt R) - Style and typo fixes, documentation improvements (Jason Wang, Mauro) - Selftest improvements (Matt B, Rahul, John) Alan Previn (1): drm/i915/guc: Add a helper for log buffer size Ashutosh Dixit (2): drm/i915/gt: Create gt/gtN/.defaults/ for per gt sysfs defaults drm/i915/
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we could check the already existing drm.debug variable or anything else
but addding 3 new module parameters.
For future reference, please do Cc maintainers when adding new uAPI
like module parameters.
Regards, Joonas
Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
> From: John Harrison
>
> The GuC log buffer sizes had to be configured statically at compile
> time. This can be quite troublesome when needing to get larger logs
> out of a released driver. So re-organise the code to allow a boot time
> module parameter override.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
> drivers/gpu/drm/i915/i915_params.c| 12 ++
> drivers/gpu/drm/i915/i915_params.h| 3 +
> 6 files changed, 226 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index ab4aacc516aa4..01f2705cb94a3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
>
> static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
> {
> - u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
> - u32 flags;
> -
> - #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
> - #define LOG_UNIT SZ_1M
> - #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
> - #else
> - #define LOG_UNIT SZ_4K
> - #define LOG_FLAG 0
> - #endif
> -
> - #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
> - #define CAPTURE_UNIT SZ_1M
> - #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
> - #else
> - #define CAPTURE_UNIT SZ_4K
> - #define CAPTURE_FLAG 0
> - #endif
> -
> - BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
> - BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, LOG_UNIT));
> - BUILD_BUG_ON(!CAPTURE_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(CAPTURE_BUFFER_SIZE, CAPTURE_UNIT));
> -
> - BUILD_BUG_ON((CRASH_BUFFER_SIZE / LOG_UNIT - 1) >
> - (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> - BUILD_BUG_ON((DEBUG_BUFFER_SIZE / LOG_UNIT - 1) >
> - (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
> - BUILD_BUG_ON((CAPTURE_BUFFER_SIZE / CAPTURE_UNIT - 1) >
> - (GUC_LOG_CAPTURE_MASK >> GUC_LOG_CAPTURE_SHIFT));
> + struct intel_guc_log *log = &guc->log;
> + u32 offset, flags;
> +
> + GEM_BUG_ON(!log->sizes_initialised);
> +
> + offset = intel_guc_ggtt_offset(guc, log->vma) >> PAGE_SHIFT;
>
> flags = GUC_LOG_VALID |
> GUC_LOG_NOTIFY_ON_HALF_FULL |
> - CAPTURE_FLAG |
> - LOG_FLAG |
> - ((CRASH_BUFFER_SIZE / LOG_UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
> - ((DEBUG_BUFFER_SIZE / LOG_UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
> - ((CAPTURE_BUFFER_SIZE / CAPTURE_UNIT - 1) <<
> GUC_LOG_CAPTURE_SHIFT) |
> + log->sizes[GUC_LOG_SECTIONS_DEBUG].flag |
> + log->sizes[GUC_LOG_SECTIONS_CAPTURE].flag |
> + (log->sizes[GUC_LOG_SECTIONS_CRASH].count <<
> GUC_LOG_CRASH_SHIFT) |
> + (log->sizes[GUC_LOG_SECTIONS_DEBUG].count <<
> GUC_LOG_DEBUG_SHIFT) |
> + (log->sizes[GUC_LOG_SECTIONS_CAPTURE].count <<
> GUC_LOG_CAPTURE_SHIFT) |
> (offset << GUC_LOG_BUF_ADDR_SHIFT);
>
> - #undef LOG_UNIT
> - #undef LOG_FLAG
> - #undef CAPTURE_UNIT
> - #undef CAPTURE_FLAG
> -
> return flags;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index b54b7883320b1..d2ac53d4f3b6e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -656,16 +656,17 @@ static void check_guc_capture_size(struct intel_guc
> *guc)
> struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> int min_size = guc_capture_output_min_size_est(guc);
> int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
> + u32 buffer_size = intel_guc_log_section_size_capture(&guc->log);
>
> if (min_size < 0)
> drm_warn(&i915->drm, "Failed to calculate GuC error state
> capture buffer minimum size: %d!\n",
> min_size);
> - else if (min_size > CAPTURE_BUFFER_SIZE)
> + else if (min_size > bu
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here's the previous PR + additional fix for regression #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45. Was also discussed here: https://lore.kernel.org/all/CAHk-=wj0ghsg6iw3d8ufptm9a_dvtsqrrofy9wopobbybyu...@mail.gmail.com/ Regards, Joonas *** drm-intel-fixes-2022-05-20: - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-20 for you to fetch changes up to 7b1d6924f27ba24b9e47abb9bd53d0bbc430a835: drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap (2022-05-19 12:49:49 +0300) - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 Anusha Srivatsa (1): drm/i915/dmc: Add MMIO range restrictions Maarten Lankhorst (1): drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap Umesh Nerlige Ramappa (1): i915/guc/reset: Make __guc_reset_context aware of guilty engines drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++-- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +- drivers/gpu/drm/i915/i915_reg.h | 16 + 8 files changed, 74 insertions(+), 16 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Two final -fixes for v5.18. One is to reject DMC with out-of-spec MMIO (Cc: stable) and another to correctly mark guilty contexts on GuC reset. Regards, Joonas *** drm-intel-fixes-2022-05-19: - Reject DMC firmware with out-of-spec MMIO addresses. - Correctly mark guilty context on GuC reset The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-19 for you to fetch changes up to 89e96d822bd51f7afe2d3e95a34099480b5c3d55: i915/guc/reset: Make __guc_reset_context aware of guilty engines (2022-05-16 10:13:39 +0300) - Reject DMC firmware with out-of-spec MMIO addresses. - Correctly mark guilty context on GuC reset Anusha Srivatsa (1): drm/i915/dmc: Add MMIO range restrictions Umesh Nerlige Ramappa (1): i915/guc/reset: Make __guc_reset_context aware of guilty engines drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++ drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +- drivers/gpu/drm/i915/i915_reg.h | 16 + 7 files changed, 72 insertions(+), 12 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, One fix for memory corruption under heavy load (#5732, Cc: stable). Regards, Joonas *** drm-intel-fixes-2022-05-12: Fix for #5732: (Cc stable) kernel memory corruption when running a lot of OpenCL tests in parallel The following changes since commit c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a: Linux 5.18-rc6 (2022-05-08 13:54:17 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-12 for you to fetch changes up to 3220c3b2115102bb35f8f07d90d2989a3f5eb452: drm/i915: Fix race in __i915_vma_remove_closed (2022-05-09 10:36:49 +0300) Fix for #5732: (Cc stable) kernel memory corruption when running a lot of OpenCL tests in parallel Karol Herbst (1): drm/i915: Fix race in __i915_vma_remove_closed drivers/gpu/drm/i915/i915_vma.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes PR for v5.18-rc5. Fixes for backlight control on XMG Core 15 e21 (#5284, regression since 5.15) and black display plane on Acer One AO532h. Then two smaller display fixes picked up by tooling. Regards, Joonas *** drm-intel-fixes-2022-04-28: - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-28 for you to fetch changes up to f7e1089f43761ca221914aea9a755b23dc7cbc33: drm/i915/fbc: Consult hw.crtc instead of uapi.crtc (2022-04-26 10:12:36 +0300) - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - Hans de Goede (1): drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines Imre Deak (1): drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses Jouni Högander (1): drm/i915: Check EDID for HDR static metadata when choosing blc Ville Syrjälä (1): drm/i915/fbc: Consult hw.crtc instead of uapi.crtc .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 34 +- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/i915_reg.h| 6 ++-- 3 files changed, 30 insertions(+), 12 deletions(-)
Re: [PULL v2] gvt-next
+ Tvrtko Quoting Christoph Hellwig (2022-04-21 08:47:38) > On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote: > > Is it possible that I can send two different pull based on the same branch? > > I was thinking I can remove this line in the original patch and then add a > > small patch to add this line back on the top. Then make two different tags > > before and after that small patch, send one pull with tag that includes that > > small patch to i915 and the other pull with tag that doesn't includes it to > > VFIO? > > Yes, you can do that as long as the small fixup commit is the very last > one.
Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile
+ Tvrtko Quoting Jason Gunthorpe (2022-04-13 17:45:48) > On Wed, Apr 13, 2022 at 02:26:23PM +, Wang, Zhi A wrote: > > On 4/13/22 1:43 PM, Jason Gunthorpe wrote: > > > On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote: > > > > > >> It seems Jani's makefile clean patch has already included this one, I can > > >> just simply drop this one so that Christoph won't need to re-send > > >> everything. > > >> > > >> For the branch to move on, I am merging the patches and will re-generate > > >> the > > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and > > >> other > > >> gvt branches. > > >> > > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you > > >> can use > > >> gvt-staging branch until my pull request landed in drm-intel-next. > > >> > > >> Also our QA will test gvt-staging-branch before the pull request. I > > >> suppose > > >> it will take one or two days. > > > > > > When you are wrangling the branches it would be great if Christoph's > > > series and it's minimal dependencies could be on a single branch that > > > could reasonably be pulled to the VFIO tree too, thanks > > > > > > Jason > > > > > > > Hi Jason: > > > > I am thinking about the process of merging process. Here are the dependence: > > > > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to > > go through drm. > > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. > > > > 2) Christoph's patches depends on my patches, but part of them are for VFIO. > > > > a. If they are fully going through VFIO repo, they might have to wait my > > patches to get landed first. > > > > b. If only the GVT-g parts goes through GVT repo, and rest of them goes > > through VFIO, the rest part still needs to wait. > > > > What would be a better process? > > You should organize everything onto one simple branch based on a rc to > make this all work. > > Make your #1 patch as a single patch PR based on rc to drm-intel so it > gets to the right tree > > Make your MMIO series as PR on the branch above that first PR and merge to > the gvt tree > > Make Christoph's series as a PR on the branch above the second PR's > MMIO series and merge to the gvt tree > > Merge the gvt toward DRM in the normal way - ie the main merge path for > this should be through DRM. > > Then ask Alex to merge the 3rd PR as well. > > I don't see any intel-next stuff in linux-next yet so hopefully it is > early enough to get #1 OK. > > Jason
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here go drm-intel-fixes for v5.18-rc4. Two display fixes: Disable VRR if user disables it from panel settings and avoid claiming PSR2 is enabled when it is not supported by config. Regards, Joonas *** drm-intel-fixes-2022-04-20: - Unset enable_psr2_sel_fetch if PSR2 detection fails - Fix to detect when VRR is turned off from panel settings The following changes since commit b2d229d4ddb17db541098b83524d901257e93845: Linux 5.18-rc3 (2022-04-17 13:57:31 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-20 for you to fetch changes up to bb02330408a7bde33b5f46aa14fd5d7bfe6093b7: drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails (2022-04-20 07:51:14 +0300) - Unset enable_psr2_sel_fetch if PSR2 detection fails - Fix to detect when VRR is turned off from panel settings José Roberto de Souza (1): drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails Manasi Navare (1): drm/i915/display/vrr: Reset VRR capable property on a long hpd drivers/gpu/drm/i915/display/intel_dp.c | 17 +- drivers/gpu/drm/i915/display/intel_psr.c | 38 ++-- 2 files changed, 32 insertions(+), 23 deletions(-)
Re: [PATCH v7 7/9] drm/ttm: Add a parameter to add extra pages into ttm_tt
(+ Tvrtko and Jani)
Quoting Ramalingam C (2022-04-02 06:02:38)
> On 2022-04-01 at 16:31:19 +0200, Christian König wrote:
> > I would be nicer to push this through drm-misc-next, but the intel branch
> > works for me as well.
> Hi Christian
>
> I have pushed this patch into drm-misc-next.
I've now backmerged drm-next containing this commit to drm-intel-gt-next
in order to unblock merging the rest of the series.
> Regards,
> Ram.
> >
> > Regards,
> > Christian.
> >
> > Am 01.04.22 um 16:28 schrieb Ramalingam C:
> > > Christian, Joonas and vivi
> > >
> > > Once the premerge results are greeen, if this patch can be merged into
> > > drm-intel-gt-next along with other patches could you please ack the
> > > request to merge into drm-intel-gt-next?
For future reference, when in doubt who are the right ones to handle,
add all the maintainers and wait for them to reply before proceeding.
Then we can avoid some unnecessary churn where there are more
straightforward options like here: merge via drm-intel-gt-next as
nobody else needs the new functions yet.
Regards, Joonas
> > > Thanks
> > > Ram
> > >
> > > On 2022-04-01 at 18:07:49 +0530, Ramalingam C wrote:
> > > > Add a parameter called "extra_pages" for ttm_tt_init, to indicate that
> > > > driver needs extra pages in ttm_tt.
> > > >
> > > > v2:
> > > >Used imperative wording [Thomas and Christian]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > cc: Christian Koenig
> > > > cc: Hellstrom Thomas
> > > > Reviewed-by: Thomas Hellstrom
> > > > Reviewed-by: Christian Konig
> > > > Reviewed-by: Nirmoy Das
> > > > ---
> > > > drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
> > > > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> > > > drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
> > > > drivers/gpu/drm/ttm/ttm_tt.c | 12 +++-
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
> > > > include/drm/ttm/ttm_tt.h | 4 +++-
> > > > 7 files changed, 15 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > index dc7f938bfff2..123045b58fec 100644
> > > > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > @@ -867,7 +867,7 @@ static struct ttm_tt
> > > > *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo,
> > > > if (!tt)
> > > > return NULL;
> > > > - ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
> > > > + ret = ttm_tt_init(tt, bo, page_flags, ttm_cached, 0);
> > > > if (ret < 0)
> > > > goto err_ttm_tt_init;
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > index c40aca99442f..a878910a563c 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > @@ -293,7 +293,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > i915_tt->is_shmem = true;
> > > > }
> > > > - ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching);
> > > > + ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, 0);
> > > > if (ret)
> > > > goto err_free;
> > > > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > index 95df5750f47f..9ba871bd19b1 100644
> > > > --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > @@ -113,7 +113,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > ttm = kzalloc(sizeof(struct ttm_tt), GFP_KERNEL);
> > > > if (ttm == NULL)
> > > > return NULL;
> > > > - if (ttm_tt_init(ttm, bo, page_flags, ttm_cached)) {
> > > > + if (ttm_tt_init(ttm, bo, page_flags, ttm_cached, 0)) {
> > > > kfree(ttm);
> > > > return NULL;
> > > > }
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > index 6ddc16f0fe2b..d27691f2e451 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > @@ -134,7 +134,7 @@ struct ttm_tt *ttm_agp_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > agp_be->mem = NULL;
> > > > agp_be->bridge = bridge;
> > > > - if (ttm_tt_init(&agp_be->ttm, bo, page_flags, ttm_write_combined)) {
> > > > + if (ttm_tt_init(&agp_be->ttm, bo, page_flags, ttm_write_combined, 0))
> > > > {
> > > > kfree(agp_be);
> > > > return NULL;
> > > > }
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > index d234aab800a0..1a66d9fc589a 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_tt.c
[PULL] drm-intel-fixes
Hi Dave & Daniel, Just one fix towards v5.18-rc3. Fix to align code with drm-tip to make sure full graphics IP version is used for legacy mmap disable check. Regards, Joonas *** drm-intel-fixes-2022-04-13: - Correct legacy mmap disabling to use GRAPHICS_VER_FULL The following changes since commit ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e: Linux 5.18-rc2 (2022-04-10 14:21:36 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-13 for you to fetch changes up to 1acb34e7dd7720a1fff00cbd4d000ec3219dc9d6: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (2022-04-11 09:11:21 +0300) - Correct legacy mmap disabling to use GRAPHICS_VER_FULL Matt Roper (1): drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Fix for vm_access() out-of-bounds access and PSR not staying disabled during fastset once determined not reliable. Then a naming fix to avoid conflicts for potential future fixes. Regards, Joonas *** drm-intel-next-fixes-2022-03-17: - Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) The following changes since commit 5e7f44b5c2c035fe2e5458193c2bbee56db6a090: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (2022-03-09 08:34:55 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-03-17 for you to fetch changes up to 278da06c03655c2bb9bc36ebdf45b90a079b3bfd: drm/i915/display: Do not re-enable PSR after it was marked as not reliable (2022-03-16 08:17:40 +0200) - Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) José Roberto de Souza (2): drm/i915/display: Fix HPD short pulse handling for eDP drm/i915/display: Do not re-enable PSR after it was marked as not reliable Mastan Katragadda (1): drm/i915/gem: add missing boundary check in vm_access drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_pps.c | 6 +++--- drivers/gpu/drm/i915/display/intel_pps.h | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 4 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 5 files changed, 10 insertions(+), 6 deletions(-)
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Quoting Tvrtko Ursulin (2022-03-14 17:35:17)
>
> On 12/03/2022 04:16, Matt Atwood wrote:
> > On Thu, Mar 10, 2022 at 12:26:12PM +, Tvrtko Ursulin wrote:
> >>
> >> On 10/03/2022 05:18, Matt Atwood wrote:
> >>> Newer platforms have DSS that aren't necessarily available for both
> >>> geometry and compute, two queries will need to exist. This introduces
> >>> the first, when passing a valid engine class and engine instance in the
> >>> flags returns a topology describing geometry.
> >>>
> >>> v2: fix white space errors
> >>>
> >>> Cc: Ashutosh Dixit
> >>> Cc: Matt Roper
> >>> Cc: Joonas Lahtinen
> >>> UMD (mesa):
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
> >>> Signed-off-by: Matt Atwood
> >>> @@ -2714,6 +2715,9 @@ struct drm_i915_query_item {
> >>> * - DRM_I915_QUERY_PERF_CONFIG_LIST
> >>> * - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> >>> * - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> >>> +*
> >>> +* When query_id == DRM_I915_QUERY_GEOMETRY_SUBSLICES must have bits
> >>> 0:7 set
> >>> +* as a valid engine class, and bits 8:15 must have a valid engine
> >>> instance.
> >>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
>
> Yes, shrug... Neither I can't guess if we are ever likely to hit a
> problem by having fewer bits for class:instance here compared to other
> uapi, or if stuffing struct i915_engine_class_instance into flags would
> just be too ugly. I mean there is option to define a new struct and not
> use flags at all but that's probably to complicated for what it is.
>
> Anyone else with an opinion? Consistency or should be fine even like it is?
Stuffing a full i915_engine_class_instance was definitely intended when
putting it into the flags was suggested.
If that is hit with a complication, the next proposed alternative was a
new struct. That's why the query interface was made easily extensible,
after all...
Regards, Joonas
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Here's a batch of -next-fixes from drm-intel-next/drm-intel-gt-next. On GT side just a fix to relax GGTT alignment down 64K from 2M. Addition of missing "name" attribute for GVT mdev device. On display side async flip fixes and a static checker fix. CI results had some display errors on TGL, the display has been rebooted to fix those so should cause no worries. Regards, Joonas *** drm-intel-next-fixes-2022-03-10: - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) The following changes since commit 6de7e4f02640fba2ffa6ac04e2be13785d614175: Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next (2022-03-04 14:39:00 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-03-10 for you to fetch changes up to 5e7f44b5c2c035fe2e5458193c2bbee56db6a090: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (2022-03-09 08:34:55 +0200) - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) ---- Joonas Lahtinen (1): Merge tag 'gvt-next-2022-03-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Matthew Auld (1): drm/i915/gtt: reduce overzealous alignment constraints for GGTT Ville Syrjälä (4): drm/i915: Avoid negative shift due to bigjoiner_pipes==0 drm/i915: Don't skip ddb allocation if data_rate==0 drm/i915: Check async flip capability early on drm/i915: Fix the async flip wm0/ddb optimization Zhi Wang (1): drm/i915/gvt: add the missing mdev attribute "name" drivers/gpu/drm/i915/display/intel_atomic.c| 1 + drivers/gpu/drm/i915/display/intel_atomic_plane.c | 7 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 122 + drivers/gpu/drm/i915/display/intel_display_types.h | 6 +- drivers/gpu/drm/i915/gt/intel_gtt.c| 3 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +++ drivers/gpu/drm/i915/intel_pm.c| 30 ++--- 8 files changed, 136 insertions(+), 52 deletions(-)
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here is the last feature PR for v5.18. For new platforms we have got more DG2 enabling: small BAR foundations, 64K page support and accelerated migration. For XeHP SDV we've got flat CCS detection and compute command streamer being added. Disabling i915 build on PREEMPT_RT for now due to deadlocks and warnings. Fixes to GuC data structure accesses on ARM platforms. A couple of other GuC init and SLPC fixes. Then the usual bits of cleanup and smaller fixes. Regards, Joonas *** drm-intel-gt-next-2022-03-03: Cross-subsystem Changes: - drm-next backmerge for buddy allocator changes Driver Changes: - Skip i915_perf init for DG2 as it is not yet enabled (Ram) - Add missing workarounds for DG2 (Clint) - Add 64K page/align support for platforms like DG2 that require it (Matt A, Ram, Bob) - Add accelerated migration support for DG2 (Matt A) - Add flat CCS support for XeHP SDV (Abdiel, Ram) - Add Compute Command Streamer (CCS) engine support for XeHP SDV (Michel, Daniele, Aravind, Matt R) - Don't support parallel submission on compute / render (Matt B, Matt R) - Disable i915 build on PREEMPT_RT until RT behaviour fixed (Sebastian) - Remove RPS interrupt support for TGL+ (Jose) - Fix S/R with PM_EARLY for non-GTT mappable objects on DG2 (Matt, Lucas) - Skip stolen memory init if it is fully reserved (Jose) - Use iosys_map for GuC data structures that may be in LMEM BAR or SMEM (Lucas) - Do not complain about stale GuC reset notifications for banned contexts (John) - Move context descriptor fields to intel_lrc.h (Matt R) - Start adding support for small BAR (Matt A) - Clarify vma lifetime (Thomas) - Simplify subplatform detection on TGL (Jose) - Correct the param count for unset GuC SLPC param (Vinay, Umesh) - Read RP_STATE_CAP correctly on Gen12 with GuC SLPC (Vinay) - Initialize GuC submission locks and queues early (Daniele) - Fix GuC flag query helper function to not modify state (John) - Drop fake lmem support now we have real hardware available (Lucas) - Move misplaced W/A to their correct locations (Srinivasan) - Use get_reset_domain() helper (Tejas) - Move context descriptor fields to intel_lrc.h (Matt R) - Selftest improvements (Matt A) The following changes since commit 54f43c17d681f6d9523fcfaeefc9df77993802e1: Merge tag 'drm-misc-next-2022-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2022-02-25 05:50:18 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-03-03 for you to fetch changes up to b2006061ae28fe7e84af6c9757ee89c4e505e92b: drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds (2022-03-02 06:52:42 -0800) Cross-subsystem Changes: - drm-next backmerge for buddy allocator changes Driver Changes: - Skip i915_perf init for DG2 as it is not yet enabled (Ram) - Add missing workarounds for DG2 (Clint) - Add 64K page/align support for platforms like DG2 that require it (Matt A, Ram, Bob) - Add accelerated migration support for DG2 (Matt A) - Add flat CCS support for XeHP SDV (Abdiel, Ram) - Add Compute Command Streamer (CCS) engine support for XeHP SDV (Michel, Daniele, Aravind, Matt R) - Don't support parallel submission on compute / render (Matt B, Matt R) - Disable i915 build on PREEMPT_RT until RT behaviour fixed (Sebastian) - Remove RPS interrupt support for TGL+ (Jose) - Fix S/R with PM_EARLY for non-GTT mappable objects on DG2 (Matt, Lucas) - Skip stolen memory init if it is fully reserved (Jose) - Use iosys_map for GuC data structures that may be in LMEM BAR or SMEM (Lucas) - Do not complain about stale GuC reset notifications for banned contexts (John) - Move context descriptor fields to intel_lrc.h - Start adding support for small BAR (Matt A) - Clarify vma lifetime (Thomas) - Simplify subplatform detection on TGL (Jose) - Correct the param count for unset GuC SLPC param (Vinay, Umesh) - Read RP_STATE_CAP correctly on Gen12 with GuC SLPC (Vinay) - Initialize GuC submission locks and queues early (Daniele) - Fix GuC flag query helper function to not modify state (John) - Drop fake lmem support now we have real hardware available (Lucas) - Move misplaced W/A to their correct locations (Srinivasan) - Use get_reset_domain() helper (Tejas) - Move context descriptor fields to intel_lrc.h (Matt R) - Selftest improvements (Matt A) Abdiel Janulgue (1): drm/i915/lmem: Enable lmem for platforms with Flat CCS CQ Tang (1): drm/i915/xehpsdv: Add has_flat_ccs to device info Clint Taylor (1): drm/i915/dg2: add Wa_14014947963 Daniele Ceraolo Spurio (4): drm/i915/guc: Initialize GuC submission locks and queues early drm/i915/xehp: compute engine pipe_control drm/i915/xehp/guc: enable compute engine inside GuC drm/i915/xehp: handle fused off CCS engines John Harrison (2):
Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface
Quoting Andi Shyti (2022-02-17 17:53:58) > Hi Tvrtko, > > > > Now tiles have their own sysfs interfaces under the gt/ > > > directory. Because RC6 is a property that can be configured on a > > > tile basis, then each tile should have its own interface > > > > > > The new sysfs structure will have a similar layout for the 4 tile > > > case: > > > > > > /sys/.../card0 > > > \u251c\u2500\u2500 gt > > > \u2502 \u251c\u2500\u2500 gt0 > > > \u2502 \u2502 \u251c\u2500\u2500 id > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > . . . > > > . . . > > > . . > > > \u2502 \u2514\u2500\u2500 gtN > > > \u2502 \u251c\u2500\u2500 id > > > \u2502 \u251c\u2500\u2500 rc6_enable > > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > \u2502 . > > > \u2502 . > > > \u2502 > > > \u2514\u2500\u2500 power/-+ > > >\u251c\u2500\u2500 rc6_enable|Original > > > interface > > >\u251c\u2500\u2500 rc6_residency_ms +-> kept as existing > > > ABI; > > >. |it multiplexes over > > >. |the GTs > > > -+ > > > > > > The existing interfaces have been kept in their original location > > > to preserve the existing ABI. They act on all the GTs: when > > > reading they provide the average value from all the GTs. > > > > Average feels very odd to me. I'd ask if we can get away providing an errno > > instead? Or tile zero data? Tile zero data is always wrong, in my opinion. If we have round-robin scaling workloads like some media cases, part of the system load might just disappear when it goes to tile 1. > Real multiplexing would be providing something when reading and > when writing. The idea of average came while revieweing with > Chris the write multiplexing. Indeed it makes sense to provide > some common value, but I don't know how useful it can be to the > user (still if the user needs any average). I think all read/write controls like min/max/boost_freq should return an error from the global interface if all the tiles don't return same value. Write will always overwrite per-tile values. When we have frequency readbacks without control, returning MAX() across tiles would be the logical thing. The fact that parts of the hardware can be clocked lower when one part is fully utilized is the "new feature". After that we're only really left with the rc6_residency_ms. And that is the tough one. I'm inclined that MIN() across tiles would be the right answer. If you are fully utilizing a single tile, you should be able to see it. This all would be what feels natural for an user who has their setup tuned for single-tile device. And would allow simple round-robing balancing across the tiles in somewhat coherent manner. Regards, Joonas > > Joonas, Chris... any idea? > > > Case in point, and please correct me if I am wrong, legacy rc6_enable > > returns tile zero, while residency returns average. > > As the interface is done now, the rc6_enable is just returning > whether the gpu (i.e. i915, not gt) supports RC6 or not. I think > there is a patch later. > > > Even the deprecated message gets logged with every access right? > > > > Btw is the deperecated message limited to multi-tile platforms (can't see > > that it is) and what is the plan for that? > > yes, at this point the message would need to be removed and I > forgot to do it. > > > It's a tough problem, no easy answers even after all this time. :D > > yeah! quite hard to get it conceptually right! > > Thanks Tvrtko, > Andi
[PULL] drm-intel-gt-next
move errors instead of trying memcpy move (Thomas) - Fix a race between vma / object destruction and unbinding (Thomas) - Remove short-term pins from execbuf (Maarten) - Update to GuC version 69.0.3 (John, Michal Wa.) - Improvements to GT reset paths in GuC backend (Matt B.) - Use shrinker_release_pages instead of writeback in shmem object hooks (Matt A., Tvrtko) - Use trylock instead of blocking lock when freeing GEM objects (Maarten) - Allocate intel_engine_coredump_alloc with ALLOW_FAIL (Matt B.) - Fixes to object unmapping and purging (Matt A) - Check for wedged device in GuC backend (John) - Avoid lockdep splat by locking dpt_obj around set_cache_level (Maarten) - Allow dead vm to unbind vma's without lock (Maarten) - s/engine->i915/i915/ for DG2 engine workarounds (Matt R) - Use to_gt() helper for GGTT accesses (Michal Wi.) - Selftest improvements (Matt B., Thomas, Ram) - Coding style and compiler warning fixes (Matt B., Jasmine, Andi, Colin, Gustavo, Dan) Andi Shyti (2): drm/i915: Remove unused i915->ggtt drm/i915: fix header file inclusion for might_alloc() Anusha Srivatsa (1): drm/i915/rpl-s: Add stepping info Bruce Chang (1): drm/i915/dg2: Add Wa_22011100796 Colin Ian King (1): i915: make array flex_regs static const Dan Carpenter (1): drm/i915: delete shadow "ret" variable Daniele Ceraolo Spurio (2): drm/i915/wopcm: Handle pre-programmed WOPCM registers drm/i915/guc: Update guc shim control programming on newer platforms Gustavo A. R. Silva (1): drm/i915/guc: Use struct_size() helper in kmalloc() Jasmine Newsome (1): drm/i915/gem: Use local pointer ttm for __i915_ttm_move John Harrison (5): drm/i915/guc: Report error on invalid reset notification drm/i915/guc: Check for wedged before doing stuff drm/i915/guc: Temporarily bump the GuC load timeout drm/i915/guc: Update to GuC version 69.0.3 drm/i915/guc: Improve GuC loading status check/error reports Joonas Lahtinen (1): Merge drm/drm-next into drm-intel-gt-next Juston Li (1): drm/i915/pxp: Hold RPM wakelock during PXP unbind Lucas De Marchi (2): drm/i915/guc: Prepare for error propagation drm/i915/guc: Use a single pass to calculate regset Maarten Lankhorst (8): drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors, v2. drm/i915: Add locking to i915_gem_evict_vm(), v3. drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something, v2. drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2. drm/i915: Remove support for unlocked i915_vma unbind drm/i915: Remove short-term pins from execbuf, v6. drm/i915: Lock dpt_obj around set_cache_level, v2. drm/i915: Allow dead vm to unbind vma's without lock. Matt Roper (4): drm/i915/dg2: Add Wa_18018781329 drm/i915/dg2: Add Wa_14015227452 drm/i915/dg2: s/engine->i915/i915/ for engine workarounds drm/i915: Introduce G12 subplatform of DG2 Matthew Auld (7): drm/i915: remove writeback hook drm/i915: clean up shrinker_release_pages drm/i915: don't call free_mmap_offset when purging drm/i915/ttm: only fault WILLNEED objects drm/i915/ttm: add unmap_virtual callback drm/i915/ttm: ensure we unmap when purging drm/i915/ttm: tweak priority hint selection Matthew Brost (11): drm/i915/execlists: Weak parallel submission support for execlists drm/i915: Fix possible uninitialized variable in parallel extension drm/i915: Increment composite fence seqno drm/i915/selftests: Add a cancel request selftest that triggers a reset drm/i915/guc: Remove hacks for reset and schedule disable G2H being received out of order drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915/guc: Add work queue to trigger a GT reset drm/i915/guc: Flush G2H handler during a GT reset drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct drm/i915/selftests: Use less in contexts steal guc id test Michał Winiarski (5): drm/i915/gt: Use to_gt() helper for GGTT accesses drm/i915: Use to_gt() helper for GGTT accesses drm/i915/gem: Use to_gt() helper for GGTT accesses drm/i915/display: Use to_gt() helper for GGTT accesses drm/i915/selftests: Use to_gt() helper for GGTT accesses Ramalingam C (3): drm/i915/dg2: Add Wa_22011450934 drm/i915: align the plane_vma to min_page_size of stolen mem drm/i915: More gt idling time with guc submission Thomas Hellström (9): drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Don't pin the object pag
Re: [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
Quoting Jani Nikula (2022-02-07 12:48:08) > On Mon, 07 Feb 2022, Christoph Hellwig wrote: > > On Mon, Feb 07, 2022 at 08:28:13AM +, Wang, Zhi A wrote: > >> 1) About having the mmio_table.h, I would like to keep the stuff in a > >> dedicated header as putting them in intel_gvt.h might needs i915 guys > >> to maintain it. > >> 2) The other one is about if we should move the mmio_table.c into > >> i915 folder. I guess we need the some comments from Jani. In the > >> current version that I am testing, it's still in GVT folder. Guess we > >> can submit a patch to move it to i915 folder later if Jani is ok > >> about that. > > > > Yes, let's have Jani chime in on these. They're basically one and the > > same issue. This code will have to be built into into the core i915 > > driver even with my planned split, which is kindof the point of this > > exercise. I think it makes sense to use the subdirectories as boundaries > > for where the code ends up and not to declarare maintainership boundaries, > > but it will be up to the i915 and gvt maintainers to decide that. > > Agreed. If there's going to be a gvt.ko, I think all of gvt/ should be > part of that module, nothing more, nothing less. > > The gvt related files in i915/ should probably be named intel_gvt* or > something, ditto for function naming, and we'll probably want patches > touching them be Cc'd to intel-gfx list. > > Joonas, Rodrigo, Tvrtko, thoughts? Agreed on above. I don't think we expect much changes on the golden MMIO state capture set. Regards, Joonas
[PULL] drm-intel-fixes
Hi Dave & Daniel, Tvrtko is out today, so sending the -rc3 -fixes PR on behalf of him (picked and CI tested by Tvtko). Major items are fix for GitLab #4698 (Dell DA310 Type-C dock issue) and engine busyness inconsitent value/timeout fixes when running with GuC. Then two fixes for error paths and a smatch detected divide by zero fix. Regards, Joonas *** drm-intel-fixes-2022-02-03: Fix GitLab issue #4698: DP monitor through Type-C dock(Dell DA310) doesn't work. Fixes for inconsistent engine busyness value and read timeout with GuC. Fix to use ALLOW_FAIL for error capture buffer allocation. Don't use interruptible lock on error path. Smatch fix to reject zero sized overlays. The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-02-03 for you to fetch changes up to 7d73c602154df56802a9e75ac212505fc1e9a2b6: drm/i915/pmu: Fix KMD and GuC race on accessing busyness (2022-02-01 08:59:25 +) Fix GitLab issue #4698: DP monitor through Type-C dock(Dell DA310) doesn't work. Fixes for inconsistent engine busyness value and read timeout with GuC. Fix to use ALLOW_FAIL for error capture buffer allocation. Don't use interruptible lock on error path. Smatch fix to reject zero sized overlays. Dan Carpenter (1): drm/i915/overlay: Prevent divide by zero bugs in scaling Imre Deak (1): drm/i915/adlp: Fix TypeC PHY-ready status readout Matthew Brost (2): drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline Umesh Nerlige Ramappa (2): drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for reference drm/i915/pmu: Fix KMD and GuC race on accessing busyness drivers/gpu/drm/i915/display/intel_overlay.c | 3 + drivers/gpu/drm/i915/display/intel_tc.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 ++ drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 3 +- 7 files changed, 117 insertions(+), 22 deletions(-)
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Tvrtko Ursulin (2022-01-17 18:02:50) > > On 17/01/2022 15:09, Andi Shyti wrote: > > The GT has its own properties and in sysfs they should be grouped > > in the 'gt/' directory. > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > directories related to each tile configured in the GPU. Move the > > power management files inside those directories. > > > > The previous power management files are kept in their original > > root directory to avoid breaking the ABI. They point to the tile > > '0' and a warning message is printed whenever accessed to. This is wrong. They should act as multiplexers to all the tiles. Needs to be fixed before merging. > > The > > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 > > flag in order to be generated. > > CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least > does not appear to contain it so please update the commit message to > reflect current state. > > Adding Joonas to help address the question of how strict are userspace > requirements for sysfs additions. Personally sysadmin use sounds fine to > me, although it needs to be mentioned/documented as Matt requested, but > I fear it may not be enough to upstream. Is Level0 at the stage where we > can upstream for it I am also not sure. Sysadmin usage is fine for the simple interfaces that can truly be used from the command line. This patch seems to just expose the existing interface in per-tile manner, so should not be a concern. However, the controls not under gt directories, need to be converted to apply to all tiles. (I've definitely given that feedback multiple times). Otherwise it will be very unexpected to the end user when what previously applied to whole device would only apply to part of it. Regards, Joonas > > While I am here I also left some nits below (not full review). > > > > > The new sysfs structure will have a similar layout for the 4 tile > > case: > > > > /sys/.../card0 > > \u251c\u2500\u2500 gt > > \u2502 \u251c\u2500\u2500 gt0 > > \u2502 \u2502 \u251c\u2500\u2500 id > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > >. . > >. . > >. . > > \u2502 \u2514\u2500\u2500 gt3 > > \u2502 \u251c\u2500\u2500 id > > \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > > \u251c\u2500\u2500 gt_act_freq_mhz -+ > > \u251c\u2500\u2500 gt_boost_freq_mhz | > > \u251c\u2500\u2500 gt_cur_freq_mhz|Original interface > > \u251c\u2500\u2500 gt_max_freq_mhz+\u2500-> kept as existing > > ABI; > > \u251c\u2500\u2500 gt_min_freq_mhz|it points to gt0/ > > \u251c\u2500\u2500 gt_RP0_freq_mhz| > > \u2514\u2500\u2500 gt_RP1_freq_mhz| > > \u2514\u2500\u2500 gt_RPn_freq_mhz -+ > > > > As soon as multitile platforms will start being supported, this > > interface will allow to control the power (either manually or > > with tools) on each tile, instead of affecting only tile 0 and > > getting incomplete results. > > > > Signed-off-by: Andi Shyti > > Signed-off-by: Lucas De Marchi > > Cc: Matt Roper > > Cc: Sujaritha Sundaresan > > Cc: Tvrtko Ursulin > > Reviewed-by: Sujaritha Sundaresan > > --- > > drivers/gpu/drm/i915/Makefile | 4 +- > > drivers/gpu/drm/i915/gt/intel_gt.c| 2 + > > drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 + > > drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++ > > drivers/gpu/drm/i915/i915_drv.h | 2 + > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > drivers/gpu/drm/i915/i915
Re: [PATCH] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
(Switching to my @linux.intel.com address)
Quoting Christian König (2021-11-29 14:55:37)
> Am 29.11.21 um 13:46 schrieb Thomas Hellström:
> > On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> >> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> >>> Hi, Christian,
> >>>
> >>> On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > If a dma_fence_array is reported signaled by a call to
> > dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
> >
> > Fix this by clearing the PENDING_ERROR status if we return true
> > in
> > dma_fence_array_signaled().
> >
> > Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-
> > array container")
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Christian König
> > Cc: Chris Wilson
> > Signed-off-by: Thomas Hellström
> >
> Reviewed-by: Christian König
> >>> How are the dma-buf / dma-fence patches typically merged? If i915
> >>> is
> >>> the only fence->error user, could we take this through drm-intel to
> >>> avoid a backmerge for upcoming i915 work?
> >> Well that one here looks like a bugfix to me, so either through
> >> drm-misc-fixes ore some i915 -fixes branch sounds fine to me.
> >>
> >> If you have any new development based on that a backmerge of the -
> >> fixes
> >> into your -next branch is unavoidable anyway.
> > Ok, I'll check with Joonas if I can take it through
> > drm-intel-gt-next, since fixes are cherry-picked from that one. Patch
> > will then appear in both the -fixes and the -next branch.
>
> Well exactly that's the stuff Daniel told me to avoid :)
>
> But maybe your i915 workflow is somehow better handling that than the
> AMD workflow.
If it's a bugfix to a patch that merged through drm-misc-next, I'd
always be inclined to merge the fixup using the same process (which
would be drm-next-fixes).
In i915 we do always merge the patches to -next first, and never do a
backmerge of -fixes (as it's a cherry-picked branch) so the workflows
differ there.
Here the time between the fixup and the previous patch is so long that
either way is fine with. So feel free to apply to drm-intel-gt-next.
Regards, Joonas
> Christian.
>
> >
> > Thanks,
> > /Thomas
> >
> >
> >> Regards,
> >> Christian.
> >>
> >>> /Thomas
> >>>
> >>>
> > ---
> > drivers/dma-buf/dma-fence-array.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-
> > buf/dma-fence-array.c
> > index d3fbd950be94..3e07f961e2f3 100644
> > --- a/drivers/dma-buf/dma-fence-array.c
> > +++ b/drivers/dma-buf/dma-fence-array.c
> > @@ -104,7 +104,11 @@ static bool
> > dma_fence_array_signaled(struct
> > dma_fence *fence)
> > {
> > struct dma_fence_array *array =
> > to_dma_fence_array(fence);
> >
> > - return atomic_read(&array->num_pending) <= 0;
> > + if (atomic_read(&array->num_pending) > 0)
> > + return false;
> > +
> > + dma_fence_array_clear_pending_error(array);
> > + return true;
> > }
> >
> > static void dma_fence_array_release(struct dma_fence *fence)
> >
>
Re: refactor the i915 GVT support and move to the modern mdev API v2
Quoting Christoph Hellwig (2021-11-09 09:59:57) > On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote: > > The minimal we should do is to eliminate the double underscore > > prefixed functions. But I would prefer to have the symbol exports by > > default so that we can enable the functionality just by loading the > > module. > > I'm fine with exporting by default, but just loading won't really work > even with that: > > - there are a bunch of IS_ENABLED conditionals in the i915 (although >they look like minor optimizations to me). I'd assume the golden state capture being the one with biggest impact. > - the enable_gvt needs to be set, although after this refactor this >option is completely pointless and should probably be enabled Indeed. Hope is that modprobe/rmmod would be enough to enable/disable. This should help any distros intending to enable the feature, too. So mostly about making sure the IS_ENABLED portions in base i915 operation are not too invasive. > - the enable_guc option needs to be disable for gvt to work. On the GVT supported platforms GuC is disabled by default, so it should be fine. We can change the logic to opposite to disable the feature if the enable_guc unsafe modparam is used. Regards, Joonas
Re: refactor the i915 GVT support and move to the modern mdev API v2
Hi Zhenyu and Zhi, Can you have somebody from the GVT team to review the patches that are fully contained in gvt/ ? I also started discussion on patch 6 which is about defining the interface between the modules. I remember there is prior work to shrink the interface. Do you have links to such patches? The minimal we should do is to eliminate the double underscore prefixed functions. But I would prefer to have the symbol exports by default so that we can enable the functionality just by loading the module. Regards, Joonas Quoting Christoph Hellwig (2021-11-02 09:05:32) > Hi all, > > the GVT code in the i915 is a bit of a mess right now due to strange > abstractions and lots of indirect calls. This series refactors various > bits to clean that up. The main user visible change is that almost all > of the GVT code moves out of the main i915 driver and into the kvmgt > module. > > Tested on my Thinkpad with a Kaby Lake CPU and integrated graphics. > > Git tree: > > git://git.infradead.org/users/hch/misc.git i915-gvt > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-gvt > > Changes since v1: > - rebased on Linux 5.15 > - allow the kvmgvt module to be loaded at any time and thus solve >the deadlock when both i915 amd kvmgvt are modular > - include the conversion to the modern mdev API > > Note that I do expect to rebased this again against 5.16-rc1 once > released, but I'd like to get this out for review ASAP. > > Diffstat: > b/drivers/gpu/drm/i915/Kconfig | 33 > b/drivers/gpu/drm/i915/Makefile | 31 > b/drivers/gpu/drm/i915/gvt/cfg_space.c | 89 -- > b/drivers/gpu/drm/i915/gvt/cmd_parser.c |4 > b/drivers/gpu/drm/i915/gvt/dmabuf.c | 36 - > b/drivers/gpu/drm/i915/gvt/execlist.c | 12 > b/drivers/gpu/drm/i915/gvt/gtt.c| 55 + > b/drivers/gpu/drm/i915/gvt/gvt.h| 125 ++- > b/drivers/gpu/drm/i915/gvt/interrupt.c | 38 + > b/drivers/gpu/drm/i915/gvt/kvmgt.c | 1099 > +++- > b/drivers/gpu/drm/i915/gvt/mmio.c |4 > b/drivers/gpu/drm/i915/gvt/opregion.c | 148 > b/drivers/gpu/drm/i915/gvt/page_track.c |8 > b/drivers/gpu/drm/i915/gvt/scheduler.c | 37 - > b/drivers/gpu/drm/i915/gvt/trace.h |2 > b/drivers/gpu/drm/i915/gvt/vgpu.c | 22 > b/drivers/gpu/drm/i915/i915_drv.c |7 > b/drivers/gpu/drm/i915/i915_drv.h |1 > b/drivers/gpu/drm/i915/i915_trace.h |1 > b/drivers/gpu/drm/i915/intel_gvt.c | 162 +++- > b/drivers/gpu/drm/i915/intel_gvt.h | 17 > drivers/gpu/drm/i915/gvt/Makefile |9 > drivers/gpu/drm/i915/gvt/gvt.c | 340 - > drivers/gpu/drm/i915/gvt/hypercall.h| 82 -- > drivers/gpu/drm/i915/gvt/mpt.h | 400 --- > 25 files changed, 929 insertions(+), 1833 deletions(-)
Re: [PATCH 06/29] drm/i915/gvt: move the gvt code into kvmgt.ko
+ Thomas, Maarten and Matt (Also, Zhi and Zhenyu, please see down) Quoting Christoph Hellwig (2021-11-02 09:05:38) > Instead of having an option to build the gvt code into the main i915 > module, just move it into the kvmgt.ko module. This only requires > a new struct with three entries that the KVMGT modules needs to register > with the main i915 module, and a proper list of GVT-enabled devices > instead of global device pointer. > > Signed-off-by: Christoph Hellwig > +/* > + * Exported here so that the exports only get created when GVT support is > + * actually enabled. > + */ > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_alloc, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_create_shmem, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_ggtt_pin_ww, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_set_to_cpu_domain, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_flush_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_set_pages, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_gtt_insert, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_prime_export, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_backoff, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_fini, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_ppgtt_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_add, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_wait, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_reserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_unreserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vm_release, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vma_move_to_active, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_context_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT); This is where the module conversion got stuck last time. Conditionally exporting is kind of a partial remedy. Previously the intention for the rewrite was to define a clear interface between the two modules which would be well defined enough that we could avoid frequent clashes and hopefully get GVT into drm-tip, too. The absolute minimum requirement is not to have any of the double underscore symbols in this list. As that convention is specifically used to mark functions which are expected to have reduced error checking because of the exact point they are being called from. With that done we should be where we can enable the exports by default and modprobe would be all that is required. I think Zhenyu and Zhi took an AR back in time to see how small they could shrink this list. Would we have some followup patches available to shrink this interface? Also, the golden MMIO state capture remains something that leaks the hypervisor state into the guests. For example the fact which bug W/A are applied in hypervisor, and I would rather have that code path isolated before enabling by default. Regards, Joonas
Re: [PATCH 02/29] drm/i915/gvt: integrate into the main Makefile
Quoting Christoph Hellwig (2021-11-02 09:05:34) > Remove the separately included Makefile and just use the relative > reference from the main i915 Makefile as for source files in other > subdirectories. The thinking behind the split is to avoid any merge conflicts as the gvt/ subdirectory is handled through separate pull request flow and are note part of drm-tip. The other subdirectories are part of drm-intel-next/drm-intel-gt-next and are part of drm-tip. So I would rather still see the Makefile live in gvt/ directory. Regards, Joonas > Signed-off-by: Christoph Hellwig > --- > drivers/gpu/drm/i915/Makefile | 29 - > drivers/gpu/drm/i915/gvt/Makefile | 9 - > drivers/gpu/drm/i915/gvt/trace.h | 2 +- > 3 files changed, 25 insertions(+), 15 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 335ba9f43d8f7..63523032eea26 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -295,11 +295,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \ > > # virtual gpu code > i915-y += i915_vgpu.o > - > -ifeq ($(CONFIG_DRM_I915_GVT),y) > -i915-y += intel_gvt.o > -include $(src)/gvt/Makefile > -endif > +i915-$(CONFIG_DRM_I915_GVT) += \ > + intel_gvt.o \ > + gvt/gvt.o \ > + gvt/aperture_gm.o \ > + gvt/handlers.o \ > + gvt/vgpu.o \ > + gvt/trace_points.o \ > + gvt/firmware.o \ > + gvt/interrupt.o \ > + gvt/gtt.o \ > + gvt/cfg_space.o \ > + gvt/opregion.o \ > + gvt/mmio.o \ > + gvt/display.o \ > + gvt/edid.o \ > + gvt/execlist.o \ > + gvt/scheduler.o \ > + gvt/sched_policy.o \ > + gvt/mmio_context.o \ > + gvt/cmd_parser.o \ > + gvt/debugfs.o \ > + gvt/fb_decoder.o \ > + gvt/dmabuf.o \ > + gvt/page_track.o > > obj-$(CONFIG_DRM_I915) += i915.o > obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o > diff --git a/drivers/gpu/drm/i915/gvt/Makefile > b/drivers/gpu/drm/i915/gvt/Makefile > deleted file mode 100644 > index ea8324abc784a..0 > --- a/drivers/gpu/drm/i915/gvt/Makefile > +++ /dev/null > @@ -1,9 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0 > -GVT_DIR := gvt > -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o > firmware.o \ > - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \ > - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o > debugfs.o \ > - fb_decoder.o dmabuf.o page_track.o > - > -ccflags-y += -I $(srctree)/$(src) -I > $(srctree)/$(src)/$(GVT_DIR)/ > -i915-y += $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > diff --git a/drivers/gpu/drm/i915/gvt/trace.h > b/drivers/gpu/drm/i915/gvt/trace.h > index 6d787750d279f..348f57f8301db 100644 > --- a/drivers/gpu/drm/i915/gvt/trace.h > +++ b/drivers/gpu/drm/i915/gvt/trace.h > @@ -379,5 +379,5 @@ TRACE_EVENT(render_mmio, > #undef TRACE_INCLUDE_PATH > #define TRACE_INCLUDE_PATH . > #undef TRACE_INCLUDE_FILE > -#define TRACE_INCLUDE_FILE trace > +#define TRACE_INCLUDE_FILE gvt/trace > #include > -- > 2.30.2 >
Re: linux-next: manual merge of the drm tree with Linus' tree
Quoting Stephen Rothwell (2021-10-29 03:48:40)
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_trace.h
>
> between commit:
>
> 9a4aa3a2f160 ("drm/i915: Revert 'guc_id' from i915_request tracepoint")
>
> from Linus' tree and commit:
>
> 3cb3e3434b9f ("drm/i915/guc: Move fields protected by guc->contexts_lock
> into sub structure")
>
> from the drm tree.
>
> I fixed it up (I used the former version) and can carry the fix as
> necessary.
The resolution for the conflict is to drop the guc_id field completely
in linux-next.
Regards, Joonas
> This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
Re: linux-next: build warning after merge of the drm tree
Quoting Stephen Rothwell (2021-10-27 23:51:55) > Hi Joonas, > > On Wed, 27 Oct 2021 15:12:44 +0300 Joonas Lahtinen > wrote: > > > > We should be now good to go and add drm-intel-gt-next to linux-next. > > > > The branch would be as follows: > > > > drm-intel-gt-next git://anongit.freedesktop.org/drm-intel > > for-linux-next-gt > > > > Notice the "-gt" and the end of the for-linux-next branch name. This should > > eliminate > > the gap we have been having. > > I have added it to linux-next from today. Thanks! > I called it just > "drm-intel-gt" for consistency with the other drm trees in linux-next. We use the drm-intel-gt-next as the branch name in repo and DIM tolling, so if we are after consistenty consistency, using the full name probably makes sense. drm-intel-gt-next for name keeps open the option for separating the drm-intel-gt-fixes too, if we decide to do so in the future. > Currently I just have you listed as a contact, is there anyone else (or > a list) that I should add? Please do add Tvrtko (Cc'd). I guess it might make sense adding Jani and Rodrigo too, as backups. Similarly Tvrtko could be added to the other drm-intel-* trees. Doesn't hurt to have more eyes especially if some folks are on a vacation. Regards, Joonas > Thanks for adding your subsystem tree as a participant of linux-next. As > you may know, this is not a judgement of your code. The purpose of > linux-next is for integration testing and to lower the impact of > conflicts between subsystems in the next merge window. > > You will need to ensure that the patches/commits in your tree/series have > been: > * submitted under GPL v2 (or later) and include the Contributor's > Signed-off-by, > * posted to the relevant mailing list, > * reviewed by you (or another maintainer of your subsystem tree), > * successfully unit tested, and > * destined for the current or next Linux merge window. > > Basically, this should be just what you would send to Linus (or ask him > to fetch). It is allowed to be rebased if you deem it necessary. > > -- > Cheers, > Stephen Rothwell > s...@canb.auug.org.au > > -- > Cheers, > Stephen Rothwell
Re: linux-next: build warning after merge of the drm tree
(+ Tvrtko who was recently added as a drm/i915 co-maintainer) Quoting Daniel Vetter (2021-01-22 10:40:48) > On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell > wrote: > > > > Hi Daniel, > > > > On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote: > > > > > > Hm that has been in drm-intel-gt-next for a few days, is that tree not > > > in linux-next? > > > > It is not. Hi Stephen, We should be now good to go and add drm-intel-gt-next to linux-next. The branch would be as follows: drm-intel-gt-next git://anongit.freedesktop.org/drm-intel for-linux-next-gt Notice the "-gt" and the end of the for-linux-next branch name. This should eliminate the gap we have been having. The change to add it to the DIM tool is here: https://gitlab.freedesktop.org/drm/maintainer-tools/-/commit/7b5c2c29cdbc054e8c8fce38f095c56290fc4833 So once all developers have updated their tooling (for which they will get an automatic nag message) we should be all up-to-date for future merge windows. Regards, Joonas > Adding -intel maintainers to get that sorted. > -Daniel > > > These are the drm branches currently in linux-next: > > Oh for ordering maybe put drm-misc ahead of the other subtrees, -misc > is where nowadays a lot of refactorings and core changes land. > Probably doesn't matter in practice. > -Daniel > > > drm-fixes git://git.freedesktop.org/git/drm/drm.git drm-fixes > > amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux drm-fixes > > drm-intel-fixes git://anongit.freedesktop.org/drm-intel > > for-linux-next-fixes > > drm-misc-fixes git://anongit.freedesktop.org/drm/drm-misc > > for-linux-next-fixes > > drm git://git.freedesktop.org/git/drm/drm.git drm-next > > amdgpu https://gitlab.freedesktop.org/agd5f/linux drm-next > > drm-intel git://anongit.freedesktop.org/drm-intel > > for-linux-next > > drm-tegra git://anongit.freedesktop.org/tegra/linux.git > > drm/tegra/for-next > > drm-miscgit://anongit.freedesktop.org/drm/drm-misc > > for-linux-next > > drm-msm https://gitlab.freedesktop.org/drm/msm.git msm-next > > imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next > > etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next > > > > -- > > Cheers, > > Stephen Rothwell > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
Quoting Matthew Brost (2021-10-25 19:34:04)
> Hide the guc_id and tail fields, for request trace points, behind
> CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> are ABI (maybe?) so don't change them without kernel developers Kconfig
> options.
I've pushed the simple fix to eliminate the 'guc_id' field.
In my opinion a separate tracepoint with more information would be a
better choice here compared to mutating an existing one.
The idea with LOW_LEVEL_TRACEPOINTS is to make sure there are two sets
of tracepoints: one that is quasi stable and the other that is unstable.
Mutating the other set when the unstable set is enabled kind of breaks
that clean split.
Regards, Joonas
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/i915_trace.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 9795f456cccf..4f5238d02b51 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
> __entry->ctx, __entry->seqno, __entry->flags)
> );
>
> +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> DECLARE_EVENT_CLASS(i915_request,
> TP_PROTO(struct i915_request *rq),
> TP_ARGS(rq),
> @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
> __entry->guc_id, __entry->ctx, __entry->seqno,
> __entry->tail)
> );
> +#else
> +DECLARE_EVENT_CLASS(i915_request,
> + TP_PROTO(struct i915_request *rq),
> + TP_ARGS(rq),
> +
> + TP_STRUCT__entry(
> +__field(u32, dev)
> +__field(u64, ctx)
> +__field(u16, class)
> +__field(u16, instance)
> +__field(u32, seqno)
> +),
> +
> + TP_fast_assign(
> + __entry->dev =
> rq->engine->i915->drm.primary->index;
> + __entry->class = rq->engine->uabi_class;
> + __entry->instance = rq->engine->uabi_instance;
> + __entry->ctx = rq->fence.context;
> + __entry->seqno = rq->fence.seqno;
> + ),
> +
> + TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> + __entry->dev, __entry->class, __entry->instance,
> + __entry->ctx, __entry->seqno)
> +);
> +#endif
>
> DEFINE_EVENT(i915_request, i915_request_add,
> TP_PROTO(struct i915_request *rq),
> --
> 2.32.0
>
Re: [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
Quoting Dave Airlie (2021-10-26 03:34:52) > On Mon, 25 Oct 2021 at 23:51, Daniel Vetter wrote: > > > > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen > > wrote: > > > > > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. > > > Tvrtko will bring added bandwidth and focus to the GT/GEM domain > > > (drm-intel-gt-next). > > > > > > This will help with the increased driver maintenance efforts, allows > > > alternating the drm-intel-gt-next pull requests and also should increase > > > the coverage for the maintenance in general. > > > > > > Signed-off-by: Joonas Lahtinen > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Acked-by: Jani Nikula > > > Acked-by: Rodrigo Vivi > > > Acked-by: Tvrtko Ursulin > > > Cc: Sean Paul > > > Cc: Maarten Lankhorst > > > Cc: Maxime Ripard > > > Cc: dri-devel@lists.freedesktop.org > > > > Acked-by: Daniel Vetter > > Acked-by: Dave Airlie Thanks for the Acks, this is now merged. Regards, Joonas
Re: [PATCH 00/47] GuC submission support
Quoting Matthew Brost (2021-10-26 18:51:17) > On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote: > > Quoting Matthew Brost (2021-10-25 18:15:09) > > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > > > > > Hi Matt & John, > > > > > > > > > > > > Can you please queue patches with the right Fixes: references to > > > > > > convert > > > > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > > > > > protection for now. Please do so before next Wednesday so we get it > > > > > > queued in drm-intel-next-fixes. > > > > > > > > > > > > > > > > Don't we already do that? I checked i915_trace.h and every tracepoint > > > > > I > > > > > added (intel_context class, i915_request_guc_submit) is protected by > > > > > LOW_LEVEL_TRACEPOINTS. > > > > > > > > > > The only thing I changed outside of that protection is adding the > > > > > guc_id > > > > > field to existing i915_request class tracepoints. > > > > > > > > It's the first search hit for "guc" inside the i915_trace.h file :) > > > > > > > > > Without the guc_id in > > > > > those tracepoints these are basically useless with GuC submission. We > > > > > could revert that if it is a huge deal but as I said then they are > > > > > useless... > > > > > > > > Let's eliminate it for now and restore the tracepoint exactly as it was. > > > > > > > > > > Don't really agree - let's render tracepoints to be useless? Are > > > tracepoints ABI? I googled this and couldn't really find a definie > > > answer. If tracepoints are ABI, then OK I can revert this change but > > > still this is a poor technical decision (tracepoints should not be ABI). > > > > Thats a very heated discussion in general. But the fact is that if > > tracepoint changes have caused regressions to applications, they have > > been forced to be remain untouched. You are free to raise the discussion > > with Linus/LKML if you feel that should not be the case. So the end > > result is that tracepoints are effectively in limbo, not ABI unless some > > application uses them like ABI. > > > > Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look > > for threads with many replies. It's not that I would not agree, it's more > > that I'm not in the mood for repeating that discussion over and over again > > and always land in the same spot. > > > > So for now, we don't add anything new to tracepoints we can't guarantee > > to always be there untouched. Similarly, we don't guarantee any of them > > to remain stable. So we try to be compatible with the limbo. > > > > I'm long overdue waiting for some stable consumer to step up for the > > tracepoints, so we can then start discussion what would actually be the > > best way of getting that information out for them. In ~5 years that has > > not happened. > > > > > > If there is an immediate need, we should instead have an auxilary > > > > tracepoint > > > > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the > > > > information of the basic tracepoint. > > > > > > > > > > Regardless of what I said above, I'll post 2 patches. The 1st just > > > remove the GuC, the 2nd modify the tracepoint to include guc_id if > > > LOW_LEVEL_TRACEPOINTS is defined. > > > > Thanks. Let's get a patch merged which simply drops the guc_id for now > > to unblock things. > > > > For the second, an auxilary tracepoint will be preferred instead of > > mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS). > > > > I only noticed a patch that mutates the tracepoints, can you > > double-check sending the first patch? > > Sorry for the double reply - missed this one in the first. > > I changed my plans / mind after I send the original email. I only sent a > patch which includes guc_id when LOW_LEVEL_TRACEPOINTS is enabled. That > is the bear minimum I live with. Without it any time there is a problem > results in hacking the kernel. I can't do t
Re: [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Quoting Matthew Brost (2021-10-25 20:13:22)
> On Mon, Oct 25, 2021 at 03:23:00PM +0300, Joonas Lahtinen wrote:
> > Quoting Thomas Hellström (2021-10-21 08:39:48)
> > > On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> >
> >
> >
> > > > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > > > pinned with GuC submission")
> > > > Signed-off-by: Matthew Brost
> > > > Cc: sta...@vger.kernel.org
> >
> > This Cc: stable annotation is unnecessary.
> >
> > Please always use "dim fixes 1a52faed31311" for helping to decide which
> > Cc's are needed. In this case stable is not needed. If it was, there
> > would be an indication of kernel version. In this case this is fine to
> > be picked up by in drm-intel-next-fixes PR.
> >
> > Let's pay attention to the right Fixes: annotation while submitting and
> > reviewing patches.
> >
>
> Will do. Working on getting push rights. Is there any documentation with
> all the rules when pushing as it seems like there are a lot of rules.
Yes, we have the documentation here:
https://drm.pages.freedesktop.org/maintainer-tools/committer-guidelines.html
And more specifically this topic:
https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#labeling-fixes-before-pushing
I could even recommend to at least do a cursory read through the wider
documentation about how the different trees interact:
https://drm.pages.freedesktop.org/maintainer-tools/index.html
Makes it easier to understand how the tags are used.
Regards, Joonas
>
> Matt
>
> > Regards, Joonas
Re: [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
Quoting John Harrison (2021-10-26 00:06:54)
> On 10/25/2021 09:34, Matthew Brost wrote:
> > Hide the guc_id and tail fields, for request trace points, behind
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> > are ABI (maybe?) so don't change them without kernel developers Kconfig
> > options.
> The i915 sw arch team have previously hard blocked requests for changes
> to trace points from user land tool developers on the grounds that trace
> points are not ABI and are free to change at whim as and when the i915
> internal implementation changes. They are purely for use of developers
> to debug the i915 driver as the i915 driver currently stands at any
> given instant.
Correct. That is indicated by the LOW_LEVEL_TRACEPOINTS.
All the discussions about stable usage really revolve around the low level
backend specific scheduling tracepoints to analyze hardware utilization.
And those even become infeasible to expose when GuC scheduling is enabled
as the information really goes to GuC log.
Luckily we have added the mechanism to get the actual utilization
through OA via gpuvis tool, so we don't have to guesstimate it from the
KMD scheduling tracepoints (which are for KMD debugging).
> So I don't see how it can be argued that we must not update any trace
> points to allow for debugging of i915 scheduling issues on current
> platforms. And having to enable extra config options just to keep
> existing higher level trace points usable seems broken.
We can update them (even outside LOW_LEVEL_TRACEPOINTS) but there should
not be any backend specific data added outside the LOW_LEVEL_TRACEPOINTS,
just to prevent anyone from starting to use them in some
visualization/analysis tooling.
If you have the energy to drive the general LKML/Linux Plumbers level
discussion about tracepoint stability limbo into a conclusion, I'll be
more than happy to see it resolved :)
Regards, Joonas
>
> John.
>
>
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/i915_trace.h | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h
> > b/drivers/gpu/drm/i915/i915_trace.h
> > index 9795f456cccf..4f5238d02b51 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
> > __entry->ctx, __entry->seqno, __entry->flags)
> > );
> >
> > +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> > DECLARE_EVENT_CLASS(i915_request,
> > TP_PROTO(struct i915_request *rq),
> > TP_ARGS(rq),
> > @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
> > __entry->guc_id, __entry->ctx, __entry->seqno,
> > __entry->tail)
> > );
> > +#else
> > +DECLARE_EVENT_CLASS(i915_request,
> > + TP_PROTO(struct i915_request *rq),
> > + TP_ARGS(rq),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, dev)
> > + __field(u64, ctx)
> > + __field(u16, class)
> > + __field(u16, instance)
> > + __field(u32, seqno)
> > + ),
> > +
> > + TP_fast_assign(
> > +__entry->dev =
> > rq->engine->i915->drm.primary->index;
> > +__entry->class = rq->engine->uabi_class;
> > +__entry->instance = rq->engine->uabi_instance;
> > +__entry->ctx = rq->fence.context;
> > +__entry->seqno = rq->fence.seqno;
> > +),
> > +
> > + TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> > + __entry->dev, __entry->class, __entry->instance,
> > + __entry->ctx, __entry->seqno)
> > +);
> > +#endif
> >
> > DEFINE_EVENT(i915_request, i915_request_add,
> >TP_PROTO(struct i915_request *rq),
>
