Re: [RFC PATCH 0/3] Introducing I915_FORMAT_MOD_4_TILED_XE2_CCS Modifier for Xe2
Quoting Kenneth Graunke (2024-05-11 03:58:34) > On Tuesday, May 7, 2024 3:56:57 PM PDT Matt Roper wrote: > > On Mon, May 06, 2024 at 09:52:35PM +0300, Juha-Pekka Heikkila wrote: > > > These patches introduce I915_FORMAT_MOD_4_TILED_XE2_CCS modifier, which, > > > from the kernel's perspective, behaves similarly to > `I915_FORMAT_MOD_4_TILED`. > > > This new modifier is primarily intended for user space to effectively > monitor > > > compression status, especially when dealing with a mix of compressed and > > > uncompressed buffers. > > > > > > The addition of this modifier facilitates user space in managing > compression > > > status, particularly when utilizing both compressed and uncompressed > buffers > > > concurrently. To leverage compression for these buffers, user space > > > applications must configure the appropriate Page Attribute Table (PAT) > index. > > > Display engine will treat all Tile4 as if it were compressed under all > > > circumstances on Xe2 architecture. > > > > I may have missed some discussion about this, but I thought the previous > > consensus was that we didn't want/need new modifiers for compression on > > Xe2? If a userspace client (or the display hardware) receives a buffer > > of unknown origin and unknown compression status, it's always fine to > > select a compressed PAT when binding the buffer to read since even for > > uncompressed buffers the CCS metadata will accurately reflect the > > compression status. Unlike Xe1, where generating content without > > compression enabled would leave random garbage in the FlatCCS area, Xe2 > > will set the corresponding FlatCCS to '0x0' for each block, indicating > > uncompressed data. > > > > Can you explain more what the benefit of handling these modifiers > > explicitly is? > > > > > > Matt > > Thanks, Matt! I'm a bit late in getting up to speed with the Xe2 compression > changes; this is really good information. > > As I understand it...all blocks on the GPU behave in the way you mentioned, > where generating uncompressed data via the GPU will set FlatCCS = 0, so you > can assume a compressed PAT entry and everything works. > > One snag is...I've heard that CPU access doesn't work that way. So, if you > mmap a buffer on the CPU, and write data with the CPU, then I think we're > back > to the "FlatCCS contains uninitialized garbage" case, where it's unsafe to > assume a compressed PAT. And... we don't really know when sharing buffers > whether the other side is going to want to do CPU access. I think the previous discussion has specifically happened in the context of dma-buf, so not only CPU but other GPUs/accelerators/decoders/devices in the system are also relevant. It boils down to the fact that when exporting a dma-buf, one can't know it will be consumed only by the same GPU (or other device for that matter) unless there is an explicit negotiation between exporter and importers. > It would be really nice to assume compression by default, though, which got > me > thinking: if we mmap a buffer via DRM_XE_GEM_MMAP_OFFSET, could xe.ko disable > compression for us? So, resolve any outstanding CCS data, and then switch > any > PAT entries to uncompressed. Mapping would block until that resolve is done. > > It could leave compression off forever (once you CPU map a buffer, it's never > compressed again). Or it could turn CCS back on when map count reaches 0 > (but > frankly I'm not sure that's terribly important, and sounds more complex). This would only really work for a single device but the dma-buf is specifically targeting more generic sharing. There's no built-in mechanism to limit the sharing to subset of devices without explicit negotiation between the exporter and importers. So I think the "by default" mode needs to be interoperable, and the explicit negotiation can then use less compatible formats given those FD are never passed to importers that were not part of the negotiation. > As I understand it, at least on discrete GPUs, the kernel already has to do > something similar for eviction, when migrating BOs to system memory (which > doesn't support compression). So this would be doing basically the same > "resolve and disable CCS" step the kernel can presumably already do, but now > on mmap as well. So far the eviction strategy has been to copy both the backing store and compression bits in raw form. With Xe2 it would indeed be possible to do an implicit resolve IFF the buffer has not been shared to someone who doesn't understand compression and might have left garbage in the CCS bits. When evicting in raw form, kernel doesn't have to know if the CCS bits are garbage or not on any given moment. Regards, Joonas > > What do you think? Viable? Crazy? Have I missed something? > > --Ken
[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
Re: [PATCH] drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c
Pushed this, thanks for the review. Regards, Joonas Quoting Vivi, Rodrigo (2024-03-18 14:40:56) > On Thu, 2024-03-14 at 14:48 +0200, Joonas Lahtinen wrote: > > Quoting Rodrigo Vivi (2024-03-08 16:58:04) > > > On Fri, Mar 08, 2024 at 04:46:43PM +0200, Joonas Lahtinen wrote: > > > > Add standalone includes for BUG_ON and BUILD_BUG_ON to avoid > > > > build failure > > > > after linux-next include refactoring. > > > > > > any lore link so we can use with a 'Closes:' tag? > > > and perhaps a reported-by? > > > > The build failure seems to have happened in intel-gfx-ci.01.org but > > the > > failing build results are not uploaded so it's only visible in the > > background. > > > > From the CI page[1] we can see next-20240304 is the last successful > > build[2]. > > Failure seems to have started next-20240305 after which the results > > are > > not uploaded due to the failure. > > > > For future, I asked if we could improve the CI dashboard by alos > > showing the > > failing builds in the CI view. > > > > However, for now we don't have a reference, I guess. > > > > [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html? > > [2] https://intel-gfx-ci.01.org/tree/linux-next/next- > > 20240304/filelist.html > > > > > > > > > > > > > Signed-off-by: Joonas Lahtinen > > > > Cc: Chris Wilson > > > > Cc: Jani Nikula > > > > Cc: Rodrigo Vivi > > > > Cc: Tvrtko Ursulin > > > > --- > > > > drivers/gpu/drm/i915/i915_memcpy.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_memcpy.c > > > > b/drivers/gpu/drm/i915/i915_memcpy.c > > > > index ba82277254b7..cc41974cee74 100644 > > > > --- a/drivers/gpu/drm/i915/i915_memcpy.c > > > > +++ b/drivers/gpu/drm/i915/i915_memcpy.c > > > > @@ -25,6 +25,8 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > +#include > > > > > > git grep BUILD_BUG_ON drivers/gpu/drm/i915/ > > > output > > > > > > vs > > > > > > git grep build_bug.h drivers/gpu/drm/i915/ > > > output > > > > > > tells me that we likely need this in many more files... > > > > > > but not opposed to move with this faster and come back later with > > > other fixes if this unblocks people: > > > > Yeah, I made the same observation. > > > > Are you fine to merge this with the R-b even without the reference? > > sorry for having missed this. > > yes, the rv-b can be used even without the reference, let's just get > this in and fix the build issue. > > > > > Regards, Joonas > > > > > > > > Reviewed-by: Rodrigo Vivi > > > > > > > #include > > > > > > > > #include "i915_memcpy.h" > > > > -- > > > > 2.43.2 > > > > >
Re: [PATCH] drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c
Quoting Rodrigo Vivi (2024-03-08 16:58:04) > On Fri, Mar 08, 2024 at 04:46:43PM +0200, Joonas Lahtinen wrote: > > Add standalone includes for BUG_ON and BUILD_BUG_ON to avoid build failure > > after linux-next include refactoring. > > any lore link so we can use with a 'Closes:' tag? > and perhaps a reported-by? The build failure seems to have happened in intel-gfx-ci.01.org but the failing build results are not uploaded so it's only visible in the background. >From the CI page[1] we can see next-20240304 is the last successful build[2]. Failure seems to have started next-20240305 after which the results are not uploaded due to the failure. For future, I asked if we could improve the CI dashboard by alos showing the failing builds in the CI view. However, for now we don't have a reference, I guess. [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html? [2] https://intel-gfx-ci.01.org/tree/linux-next/next-20240304/filelist.html > > > > > Signed-off-by: Joonas Lahtinen > > Cc: Chris Wilson > > Cc: Jani Nikula > > Cc: Rodrigo Vivi > > Cc: Tvrtko Ursulin > > --- > > drivers/gpu/drm/i915/i915_memcpy.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_memcpy.c > > b/drivers/gpu/drm/i915/i915_memcpy.c > > index ba82277254b7..cc41974cee74 100644 > > --- a/drivers/gpu/drm/i915/i915_memcpy.c > > +++ b/drivers/gpu/drm/i915/i915_memcpy.c > > @@ -25,6 +25,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > git grep BUILD_BUG_ON drivers/gpu/drm/i915/ > output > > vs > > git grep build_bug.h drivers/gpu/drm/i915/ > output > > tells me that we likely need this in many more files... > > but not opposed to move with this faster and come back later with > other fixes if this unblocks people: Yeah, I made the same observation. Are you fine to merge this with the R-b even without the reference? Regards, Joonas > > Reviewed-by: Rodrigo Vivi > > > #include > > > > #include "i915_memcpy.h" > > -- > > 2.43.2 > >
[PATCH] drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c
Add standalone includes for BUG_ON and BUILD_BUG_ON to avoid build failure after linux-next include refactoring. Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_memcpy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/i915/i915_memcpy.c index ba82277254b7..cc41974cee74 100644 --- a/drivers/gpu/drm/i915/i915_memcpy.c +++ b/drivers/gpu/drm/i915/i915_memcpy.c @@ -25,6 +25,8 @@ #include #include #include +#include +#include #include #include "i915_memcpy.h" -- 2.43.2
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 = _gt(i915)->uc.guc;
> + const size_t size = sizeof(ver);
> + int ret;
> +
> + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> + return -ENODEV;
> +
> + ret = copy_query_item(, 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, , 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
> #define DRM_I915_QUERY_GEOMETRY_SU
Re: [RFC PATCH] drm/i915: Add GETPARAM for GuC submission version
Quoting Tvrtko Ursulin (2024-02-07 10:44:01)
>
> On 06/02/2024 20:51, Souza, Jose wrote:
> > On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
> >> On 2/6/2024 08:33, Tvrtko Ursulin wrote:
> >>> On 01/02/2024 18:25, Souza, Jose wrote:
> >>>> On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> >>>>> On 24/01/2024 08:19, Joonas Lahtinen wrote:
> >>>>>> Add reporting of the GuC submissio/VF interface version via GETPARAM
> >>>>>> properties. Mesa intends to use this information to check for old
> >>>>>> firmware versions with known bugs before enabling features like async
> >>>>>> compute.
> >>>>>
> >>>>> There was
> >>>>> https://patchwork.freedesktop.org/patch/560704/?series=124592=1
> >>>>> which does everything in one go so would be my preference.
> >>>>
> >>>> IMO Joonas version brings less burden to be maintained(no new struct).
> >>>> But both versions works, please just get into some agreement so we
> >>>> can move this forward.
> >>>
> >>> So I would really prefer the query. Simplified version would do like
> >>> the compile tested only:
> >> Vivaik's patch is definitely preferred. It is much cleaner to make one
> >> single call than having to make four separate calls. It is also
> >> extensible to other firmwares if required. The only blockage against it
> >> was whether it was a good thing to report at all. If that blockage is no
> >> longer valid then we should just merge the patch that has already been
> >> discussed, polished, fixed, etc. rather than starting the whole process
> >> from scratch.
> >
> > Agreed.
> >
> > Vivaik can you please rebase and send it again?
>
> Note there was review feedback not addressed so do that too please.
> AFAIR incorrect usage of copy item, pad/rsvd/mbz checking and questions
> about padding in general. Last is why I proposed a simplified version
> which is not future extensible and avoids the need for padding.
Yeah, I don't think there is point an adding an extensible interface as
we're not going to add further FW version queries. This only the
submission interface version we're going to expose:
* Note that the spec for the CSS header defines this version number
* as 'vf_version' as it was originally intended for virtualisation.
* However, it is applicable to native submission as well.
If somebody wants to work on the simplified version like Tvrtko
suggested below, I have no objection. We can also remove the reference
to the VF version even if that's used by the header definition.
But if there are just suggestions but no actual patches floated, then we
should be merging the GETPARAM version with the "VF" word removed.
We've already discussed on the topic for some months so doing the
minimal changes to fulfill Mesa requirements should be considered a
priority to avoid further delays.
>
> Regards,
>
> Tvrtko
>
> >
> >
> >>
> >> And note that it is four calls not three. The code below is missing the
> >> branch version number.
Not even kernel uses the 'build' version anywhere. I don't see how there
could be 'build' version for the VF interface version? It's not supposed
to version a concrete firmware build but the API contract implemented by
the build where patch version should already be incremented for each
fix.
So adding the build does not seem appropriate as there is no plan to
extend this API any further.
Regards, Joonas
> >>
> >> John.
> >>
> >>>
> >>> 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 = _gt(i915)->uc.guc;
> >>> + const size_t s
Re: [PULL] gvt-fixes
Hi Zhenyu,
I'm getting the following:
dim: ff833b32ccc4 ("drm/i915: Replace dead 01.org link"): mandatory review
missing.
dim: ERROR: issues in commits detected, aborting
Can you fix the commit?
Regards, Joonas
Quoting Zhenyu Wang (2024-01-31 11:38:51)
>
> Hi, Joonas
>
> Here is another gvt-fixes pull which contains fixes on doc link and
> one uninitialized variable in warning message, also update about Zhi's
> new mail address in MAINTAINERS.
>
> Thanks.
> ---
> The following changes since commit f9f031dd21a7ce13a13862fa5281d32e1029c70f:
>
> drm/i915/psr: Only allow PSR in LPSP mode on HSW non-ULT (2024-01-25
> 10:44:13 +0200)
>
> are available in the Git repository at:
>
> https://github.com/intel/gvt-linux tags/gvt-fixes-2024-01-31
>
> for you to fetch changes up to 88569fa2c3bc83d77a96580da94dd35edee0f893:
>
> MAINTAINERS: Update Zhi Wang's email address (2024-01-31 17:19:15 +0800)
>
>
> gvt-fixes-2024-01-31
>
> - Fix broken gvt doc link (Zhenyu)
> - Fix one uninitialized variable bug in warning (Dan)
> - Update Zhi's new email address in MAINTAINERS file. (Zhi)
>
>
> Dan Carpenter (1):
> drm/i915/gvt: Fix uninitialized variable in handle_mmio()
>
> 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(-)
[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(-)
[RFC PATCH] drm/i915: Add GETPARAM for GuC submission version
Add reporting of the GuC submissio/VF interface version via GETPARAM
properties. Mesa intends to use this information to check for old
firmware versions with known bugs before enabling features like async
compute.
Signed-off-by: Joonas Lahtinen
Cc: Kenneth Graunke
Cc: Jose Souza
Cc: Sagar Ghuge
Cc: Paulo Zanoni
Cc: John Harrison
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_getparam.c | 12
include/uapi/drm/i915_drm.h | 13 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 5c3fec63cb4c1..f176372debc54 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -113,6 +113,18 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+ case I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR:
+ case I915_PARAM_GUC_SUBMISSION_VERSION_MINOR:
+ case I915_PARAM_GUC_SUBMISSION_VERSION_PATCH:
+ if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+ return -ENODEV;
+ if (param->param == I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR)
+ value = to_gt(i915)->uc.guc.submission_version.major;
+ else if (param->param ==
I915_PARAM_GUC_SUBMISSION_VERSION_MINOR)
+ value = to_gt(i915)->uc.guc.submission_version.minor;
+ else
+ value = to_gt(i915)->uc.guc.submission_version.patch;
+ break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
* earlier versions as 0, in effect their value is undefined as
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index fd4f9574d177a..7d5a47f182542 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -806,6 +806,19 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_PXP_STATUS 58
+/*
+ * Query for the GuC submission/VF interface version number
+ *
+ * -ENODEV is returned if GuC submission is not used
+ *
+ * On success, returns the respective GuC submission/VF interface major,
+ * minor or patch version as per the requested parameter.
+ *
+ */
+#define I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR 59
+#define I915_PARAM_GUC_SUBMISSION_VERSION_MINOR 60
+#define I915_PARAM_GUC_SUBMISSION_VERSION_PATCH 61
+
/* Must be kept compact -- no holes and well documented */
/**
--
2.43.0
[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(-)
Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
Quoting Ville Syrjala (2023-12-13 02:42:29)
> From: Ville Syrjälä
>
> On MTL accessing stolen memory via the BARs is somehow borked,
> and it can hang the machine. As a workaround let's bypass the
> BARs and just go straight to DSMBASE/GSMBASE instead.
>
> Note that on every other platform this itself would hang the
> machine, but on MTL the system firmware is expected to relax
> the access permission guarding stolen memory to enable this
> workaround, and thus direct CPU accesses should be fine.
Shouldn't this have a proper workaround number assigned?
Regards, Joonas
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 -
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index ee237043c302..252fe5cd6ede 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -941,7 +941,16 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private
> *i915, u16 type,
> dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
> }
>
> - if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> + if (IS_METEORLAKE(i915)) {
> + /*
> +* Workaround: access via BAR can hang MTL, go directly to
> DSM.
> +*
> +* Normally this would not work but on MTL the system firmware
> +* should have relaxed the access permissions sufficiently.
> +*/
> + io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) &
> GEN12_BDSM_MASK;
> + io_size = dsm_size;
> + } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> io_start = 0;
> io_size = 0;
> } else {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 21a7e3191c18..ab71d74ec426 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -24,6 +24,7 @@
> #include "intel_ring.h"
> #include "i915_drv.h"
> #include "i915_pci.h"
> +#include "i915_reg.h"
> #include "i915_request.h"
> #include "i915_scatterlist.h"
> #include "i915_utils.h"
> @@ -1152,13 +1153,23 @@ static unsigned int gen6_gttadr_offset(struct
> drm_i915_private *i915)
> static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
> {
> struct drm_i915_private *i915 = ggtt->vm.i915;
> + struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> phys_addr_t phys_addr;
> u32 pte_flags;
> int ret;
>
> GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) !=
> gen6_gttmmadr_size(i915));
> - phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
> gen6_gttadr_offset(i915);
> + /*
> +* Workaround: access via BAR can hang MTL, go directly to GSM.
> +*
> +* Normally this would not work but on MTL the system firmware
> +* should have relaxed the access permissions sufficiently.
> +*/
> + if (IS_METEORLAKE(i915))
> + phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) &
> GEN12_BDSM_MASK;
> + else
> + phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
> gen6_gttadr_offset(i915);
>
> if (needs_wc_ggtt_mapping(i915))
> ggtt->gsm = ioremap_wc(phys_addr, size);
> --
> 2.41.0
>
[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
[Intel-gfx] [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(-)
[Intel-gfx] [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
[Intel-gfx] [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: [Intel-gfx] [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
[Intel-gfx] [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(-)
[Intel-gfx] [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(-)
[Intel-gfx] Extension detection by enumeration vs attempt to use extension (Was: Re: [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
[Intel-gfx] [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(-)
[Intel-gfx] [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(-)
[Intel-gfx] [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(-)
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEM_CREATE_EXTENSIONS query item
Hi Jordan,
This approach was specifically NACKed in the PAT index thread so please
at least mark any such series as RFC if they are intended to facilitate
further dialog on the topic.
I've still not seen any explanation why this would be needed at this specific
case for the PAT index setting feature. Repeating here: You should be able
to detect missing extension by trying to use it. Just because PXP has some
issues on that front doesn't mean we'll change the practices for all other
interfaces.
We should instead spend the time considering a better solution for PXP and
see how that can be implemented for the drm/xe driver.
Regards, Joonas
Quoting Jordan Justen (2023-05-02 23:57:44)
> Cc: Fei Yang
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Signed-off-by: Jordan Justen
> ---
> drivers/gpu/drm/i915/gem/i915_gem_create.c | 30 ++
> drivers/gpu/drm/i915/gem/i915_gem_create.h | 2 ++
> drivers/gpu/drm/i915/i915_query.c | 36 ++
> include/uapi/drm/i915_drm.h| 2 ++
> 4 files changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index bfe1dbda4cb7..56342a352599 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -399,6 +399,36 @@ static const i915_user_extension_fn create_extensions[]
> = {
> [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
> };
>
> +/**
> + * Fills buffer will known create_ext extensions
> + * @buffer: buffer to fill with extensions
> + * @buffer_size: size of the buffer in bytes
> + *
> + * If @buffer_size is 0, then @buffer is not accessed, and the
> + * required buffer size is returned.
> + *
> + * If @buffer_size != 0, but not large enough, then -EINVAL is
> + * returned.
> + *
> + * If @buffer_size is large enough, then @buffer will be filled as a
> + * u64 array of extension names.
> + */
> +int
> +i915_gem_create_ext_get_extensions(void *buffer, size_t buffer_size)
> +{
> + unsigned int i;
> +
> + if (buffer_size == 0)
> + return ARRAY_SIZE(create_extensions) * sizeof(u64);
> + else if (buffer_size < (ARRAY_SIZE(create_extensions) * sizeof(u64)))
> + return -EINVAL;
> +
> + for (i = 0; i < ARRAY_SIZE(create_extensions); i++)
> + ((u64*)buffer)[i] = i;
> +
> + return ARRAY_SIZE(create_extensions) * sizeof(u64);
> +}
> +
> /**
> * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle
> to it.
> * @dev: drm device pointer
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.h
> b/drivers/gpu/drm/i915/gem/i915_gem_create.h
> index 9536aa906001..e7ebef308038 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.h
> @@ -14,4 +14,6 @@ int i915_gem_dumb_create(struct drm_file *file_priv,
> struct drm_device *dev,
> struct drm_mode_create_dumb *args);
>
> +int i915_gem_create_ext_get_extensions(void *buffer, size_t buffer_size);
> +
> #endif /* __I915_GEM_CREATE_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 00871ef99792..f360f76516de 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -9,6 +9,7 @@
> #include "i915_drv.h"
> #include "i915_perf.h"
> #include "i915_query.h"
> +#include "gem/i915_gem_create.h"
> #include "gt/intel_engine_user.h"
> #include
>
> @@ -551,6 +552,40 @@ static int query_hwconfig_blob(struct drm_i915_private
> *i915,
> return hwconfig->size;
> }
>
> +static int query_gem_create_extensions(struct drm_i915_private *i915,
> + struct drm_i915_query_item *query_item)
> +{
> + void *buffer;
> + int buffer_size, fill_size;
> +
> + buffer_size = i915_gem_create_ext_get_extensions(NULL, 0);
> +
> + if (query_item->length == 0)
> + return buffer_size;
> +
> + if (query_item->length < buffer_size)
> + return -EINVAL;
> +
> + buffer = kzalloc(buffer_size, GFP_KERNEL);
> + if (!buffer)
> + return -ENOMEM;
> +
> + fill_size = i915_gem_create_ext_get_extensions(buffer, buffer_size);
> + if (fill_size != buffer_size) {
> + kfree(buffer);
> + return -EINVAL;
> + }
> +
> + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
> +
[Intel-gfx] [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(+)
[Intel-gfx] IOCTL feature detection (Was: Re: [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
[Intel-gfx] [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(-)
[Intel-gfx] [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(+)
[Intel-gfx] [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
[Intel-gfx] [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
Re: [Intel-gfx] [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.
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL
(Switching to my @linux.intel.com address) Quoting Umesh Nerlige Ramappa (2022-12-08 19:08:46) > On Wed, Nov 30, 2022 at 05:05:35PM -0800, Umesh Nerlige Ramappa wrote: > >Without an entry in oa_init_supported_formats, OA will not be functional > >in MTL. Enable OA support by enabling 32 bit OAG formats for MTL. > > > Thanks Lionel for sharing the Mesa MR for MTL - > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20228 We should not merge the userspace changes ahead of the kernel changes. They should be ready and reviewed, but not merged. Umesh and Lionel, please re-read the requirements for merging new uAPI: https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements The order is clearly documented there: "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." To follow that, please revert the Mesa changes for now and follow the right ordering. Regards, Joonas > > Regards, > Umesh > > >Signed-off-by: Umesh Nerlige Ramappa > >--- > > drivers/gpu/drm/i915/i915_perf.c | 1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/drivers/gpu/drm/i915/i915_perf.c > >b/drivers/gpu/drm/i915/i915_perf.c > >index 8369ae4b850d..a735b9540113 100644 > >--- a/drivers/gpu/drm/i915/i915_perf.c > >+++ b/drivers/gpu/drm/i915/i915_perf.c > >@@ -4772,6 +4772,7 @@ static void oa_init_supported_formats(struct i915_perf > >*perf) > > break; > > > > case INTEL_DG2: > >+ case INTEL_METEORLAKE: > > oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8); > > oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8); > > break; > >-- > >2.36.1 > >
[Intel-gfx] [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't deadlock busyness stats vs reset
[Intel-gfx] [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
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
Quoting Jani Nikula (2022-10-28 11:46:21)
> On Fri, 28 Oct 2022, Gwan-gyeong Mun wrote:
> > Resend, because some content was accidentally omitted from the previous
> > reply.
> > Please ignore the previous email.
> >
> > Hi all,
> >
> > I should have written the original commit message more accurately, but
> > it seems that it was written inaccurately.
> >
> > If the FIELD_PREP macro is expanded, the following macros are used.
> >
> > #define FIELD_PREP(_mask, _val)
> > \
> > ({ \
> > __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");\
> > ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
> > })
> >
> >
> > #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \
> > ({ \
> > BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
> >_pfx "mask is not constant"); \
> > BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");\
> > BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
> >~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
> >_pfx "value too large for the field"); \
> > BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
> >__bf_cast_unsigned(_reg, ~0ull), \
> >_pfx "type of reg too small for mask"); \
> > __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) + \
> > (1ULL << __bf_shf(_mask))); \
> > })
> >
> > Among them, a build error is generated by the lower part of the
> > __BF_FIELD_CHECK() macro.
> >
> > BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
> >__bf_cast_unsigned(_reg, ~0ull), \
> >_pfx "type of reg too small for mask"); \
> >
> >
> > Here, if you apply an argument to this macro, it will look like the
> > following.
> >
> > __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
> >
> > The result is always false because an unsigned int value of type
> > field_msk is not always greater than the maximum value of unsigned long
> > long .
> > So, a build error occurs due to the following part of the clang compiler
> > option.
> >
> > [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > You can simply override this warning in Clang by adding the build option
> > below, but this seems like a bad attempt
> >
> > i915/Makefile
> > CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
> >
> > The easiest way to solve this is to use a constant value, not a
> > variable, as an argument to FIELD_PREP.
> >
> > And since the REG_FIELD_PREP() macro suggested by Jani requires a const
> > expression as the first argument, it cannot be changed with this macro
> > alone in the existing code, it must be changed to input a constant value
> > as shown below.
>
> We've added REG_FIELD_PREP() precisely to avoid the problems with the
> types and ranges, as we want it to operate on u32. It also uses
> __is_constexpr() to avoid dependencies on compiler implementation and
> optimizations.
>
> Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
> interface if needed.
Ashutosh and GG, can we get a fix for this merged ASAP. It's currently
blocking the drm-intel-gt-next pull request.
Regards, Joonas
>
> BR,
> Jani.
>
>
>
>
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 08c921421a5f..abb3a194c548 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> > i915_reg_t rgadr,
> >
> > static void
> > hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > - const u32 field_msk, int nshift,
> > + int nshift,
> >unsigned int scale_factor, long lval)
> > {
> > u32 nval;
> > @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
> > i915_reg_t rgadr,
> > /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >
> > - bits_to_clear = field_msk;
> > - bits_to_set = REG_FIELD_PREP(field_msk, nval);
> > + bits_to_clear = PKG_PWR_LIM_1;
> > + bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
> >
> > hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > bits_to_clear, bits_to_set);
> > @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata
[Intel-gfx] [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
Re: [Intel-gfx] [PATCH] drm/i915/dgfx: Temporary hammer to keep autosuspend control 'on'
I think I commented on this already, but the patch subject should really be as
informative as possible like: "Disable PCI runtime PM on dGPUs" as that is
exactly
what the patch does.
Also bit unsure if the Fixes: tag should really point to the runtime PM
commit but maybe instead to the introduction of LMEM commit.
Regards, Joonas
Quoting Anshuman Gupta (2022-10-12 11:34:02)
> DGFX platforms has lmem and cpu can access the lmem objects
> via mmap and i915 internal i915_gem_object_pin_map() for
> i915 own usages. Both of these methods has pre-requisite
> requirement to keep GFX PCI endpoint in D0 for a supported
> iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
>
> Both DG1/DG2 have a hardware bug that violates the PCIe specs
> and support the iomem read write transaction over PCIe bus despite
> endpoint is D3 state.
> Due to above H/W bug, we had never observed any issue with i915 runtime
> PM versus lmem access.
> But this issue becomes visible when PCIe gfx endpoint's upstream
> bridge enters to D3, at this point any lmem read/write access will be
> returned as unsupported request. But again this issue is not observed
> on every platform because it has been observed on few host machines
> DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
> which really disables the PCIe power savings and leaves the bridge
> at D0 state.
>
> Till we fix all issues related to runtime PM, we need
> to keep autosupend control to 'on' on all discrete platforms with lmem.
>
> Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default")
> Suggested-by: Rodrigo Vivi
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6ed5786bcd29..410a5cb58a61 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm
> *rpm)
> pm_runtime_use_autosuspend(kdev);
> }
>
> - /* Enable by default */
> - pm_runtime_allow(kdev);
> + /*
> +* FIXME: Temp hammer to keep autosupend disable on lmem supported
> platforms.
> +* As per PCIe specs 5.3.1.4.1, all iomem read write request over a
> PCIe
> +* function will be unsupported in case PCIe endpoint function is in
> D3.
> +* Let's keep i915 autosuspend control 'on' till we fix all known
> issue
> +* with lmem access in D3.
> +*/
> + if (!HAS_LMEM(i915))
> + pm_runtime_allow(kdev);
>
> /*
> * The core calls the driver load handler with an RPM reference held.
> --
> 2.25.1
>
[Intel-gfx] [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 v2] drm/i915/DG{1, 2}: FIXME Temporary hammer to disable rpm
Quoting Anshuman Gupta (2022-09-14 19:13:29)
> DG1 and DG2 has lmem, and cpu can access the lmem objects
> via mmap and i915 internal i915_gem_object_pin_map() for
> i915 own usages. Both of these methods has pre-requisite
> requirement to keep GFX PCI endpoint in D0 for a supported
> iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
>
> Both DG1/DG2 have a hardware bug that violates the PCIe specs
> and support the iomem read write transaction over PCIe bus despite
> endpoint is D3 state.
> Due to above H/W bug, we had never observed any issue with i915 runtime
> PM versus lmem access.
> But this issue becomes visible when PCIe gfx endpoint's upstream
> bridge enters to D3, at this point any lmem read/write access will be
> returned as unsupported request. But again this issue is not observed
> on every platform because it has been observed on few host machines
> DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
> which really disables the PCIe poer power savings and leaves the bridge
> at D0 state.
>
> TODO:
> With respect to i915_gem_object_pin_map(), every caller
> has to grab a wakeref if gem object lies in lmem.
>
> Till we fix all issues related to runtime PM, we need
> to keep runtime PM disable on both DG1 and DG2.
>
> V2:
> - Keep a smaller FIXME code comment for both DG1/DG2.
I think we should also have Fixes: tags to cover both platforms.
Regards, Joonas
> Cc: Matthew Auld
> Cc: Rodrigo Vivi
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Andi Shyti
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/i915_pci.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 77e7df21f539..4a7d226b074f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -931,6 +931,14 @@ static const struct intel_device_info dg1_info = {
> BIT(VCS0) | BIT(VCS2),
> /* Wa_16011227922 */
> .__runtime.ppgtt_size = 47,
> +
> + /*
> +* FIXME: Temporary hammer to disable rpm.
> +* As per PCIe specs 5.3.1.4.1, all iomem read write request over a
> PCIe
> +* function will be unsupported in case PCIe endpoint function is in
> D3.
> +* Let's disable i915 rpm till we fix all known issue with lmem
> access in D3.
> +*/
> + .has_runtime_pm = 0,
> };
>
> static const struct intel_device_info adl_s_info = {
> @@ -1076,6 +1084,13 @@ static const struct intel_device_info dg2_info = {
> XE_LPD_FEATURES,
> .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) |
> BIT(TRANSCODER_B) |
>BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> + /*
> +* FIXME: Temporary hammer to disable rpm.
> +* As per PCIe specs 5.3.1.4.1, all iomem read write request over a
> PCIe
> +* function will be unsupported in case PCIe endpoint function is in
> D3.
> +* Let's disable i915 rpm till we fix all known issue with lmem
> access in D3.
> +*/
> + .has_runtime_pm = 0,
> .require_force_probe = 1,
> };
>
> --
> 2.26.2
>
Re: [Intel-gfx] [PATCH v2] drm/i915/DG{1, 2}: FIXME Temporary hammer to disable rpm
On the patch subject, could we aim to be a bit more readable and
concise. Something like:
"drm/i915: Temporarily disable RPM on DG1/DG2"
The patch title definitely should not have a FIXME in it if we're going
to merge it in that form.
There's nothing to be fixed about the patch itself, we are applying a
workaround until we've fixed the rootcause, which is business as usual.
Regards, Joonas
Quoting Anshuman Gupta (2022-09-14 19:13:29)
> DG1 and DG2 has lmem, and cpu can access the lmem objects
> via mmap and i915 internal i915_gem_object_pin_map() for
> i915 own usages. Both of these methods has pre-requisite
> requirement to keep GFX PCI endpoint in D0 for a supported
> iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
>
> Both DG1/DG2 have a hardware bug that violates the PCIe specs
> and support the iomem read write transaction over PCIe bus despite
> endpoint is D3 state.
> Due to above H/W bug, we had never observed any issue with i915 runtime
> PM versus lmem access.
> But this issue becomes visible when PCIe gfx endpoint's upstream
> bridge enters to D3, at this point any lmem read/write access will be
> returned as unsupported request. But again this issue is not observed
> on every platform because it has been observed on few host machines
> DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
> which really disables the PCIe poer power savings and leaves the bridge
> at D0 state.
>
> TODO:
> With respect to i915_gem_object_pin_map(), every caller
> has to grab a wakeref if gem object lies in lmem.
>
> Till we fix all issues related to runtime PM, we need
> to keep runtime PM disable on both DG1 and DG2.
>
> V2:
> - Keep a smaller FIXME code comment for both DG1/DG2.
>
> Cc: Matthew Auld
> Cc: Rodrigo Vivi
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Andi Shyti
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/i915_pci.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 77e7df21f539..4a7d226b074f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -931,6 +931,14 @@ static const struct intel_device_info dg1_info = {
> BIT(VCS0) | BIT(VCS2),
> /* Wa_16011227922 */
> .__runtime.ppgtt_size = 47,
> +
> + /*
> +* FIXME: Temporary hammer to disable rpm.
> +* As per PCIe specs 5.3.1.4.1, all iomem read write request over a
> PCIe
> +* function will be unsupported in case PCIe endpoint function is in
> D3.
> +* Let's disable i915 rpm till we fix all known issue with lmem
> access in D3.
> +*/
> + .has_runtime_pm = 0,
> };
>
> static const struct intel_device_info adl_s_info = {
> @@ -1076,6 +1084,13 @@ static const struct intel_device_info dg2_info = {
> XE_LPD_FEATURES,
> .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) |
> BIT(TRANSCODER_B) |
>BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> + /*
> +* FIXME: Temporary hammer to disable rpm.
> +* As per PCIe specs 5.3.1.4.1, all iomem read write request over a
> PCIe
> +* function will be unsupported in case PCIe endpoint function is in
> D3.
> +* Let's disable i915 rpm till we fix all known issue with lmem
> access in D3.
> +*/
> + .has_runtime_pm = 0,
> .require_force_probe = 1,
> };
>
> --
> 2.26.2
>
Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2
Quoting Vivi, Rodrigo (2022-09-09 19:33:45) > On Fri, 2022-09-09 at 08:17 -0700, Ceraolo Spurio, Daniele wrote: > > > > > > On 9/9/2022 3:24 AM, Joonas Lahtinen wrote: > > > Dave, do you have a preference how to deal with the mishap here, > > > shall I do a > > > force-push to drm-intel-gt-next to correctly record the Acked-by or > > > revert and > > > re-push? Or just leave it as is? > > Dave and Daniel, this question is still pertinent. Discussed with Dave and I did a force-push to add the missing Acked-by's. Daniele, I think the tradition is that you have volunteered yourself to improve dim to nag about missing Acked-by's for patches outside of i915 when pushing to drm-intel-gt-next. Regards, Joonas > > > > > > > Quoting Greg Kroah-Hartman (2022-09-01 18:09:09) > > > > On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote: > > > > > Add GSC support for XeHP SDV and DG2 platforms. > > > > > > > > > > The series includes changes for the mei driver: > > > > > - add ability to use polling instead of interrupts > > > > > - add ability to use extended timeouts > > > > > - setup extended operational memory for GSC > > > > > > > > > > The series includes changes for the i915 driver: > > > > > - allocate extended operational memory for GSC > > > > > - GSC on XeHP SDV offsets and definitions > > > > > > > > > > This patch set should be merged via gfx tree as > > > > > the auxiliary device belongs there. > > > > > Greg, your ACK is required for the drives/misc/mei code base, > > > > > please review the patches. > > > > With the exception that you all don't know what year it is: > > > > > > > > Acked-by: Greg Kroah-Hartman > > > Daniele, why were the patches applied without this A-b? > > > > Apologies, I usually rely on dim to pick up all the correct r-bs and > > acks from the ML and to warn me if something is missing, and I didn't > > realize that it hadn't automagically picked up the ack. > > I understand the feeling. Recently I merged a patch from Vinay relying > on patchwork to get the reviewed-by and I forgot to double check. > > dim picks up the "Link:", but I don't believe it picks any ack or rv-b > from the mailing list. Patchwork does if you use pwclient or something > like that. > > Anyway, lesson to both of us to always double-check, regardless the > tool used. > > > > > > > > > I'm just preparing the drm-intel-gt-next pull request and now it > > > appears > > > like we're pushing a lot of commits outside of drm without any > > > Acks. > > > > > > Please reach out to the maintainers *before* pushing code for other > > > subsystems. Unless you get an explicit ack to do so, do not push > > > such > > > code. > > > > I'm assuming you mean the i915 maintainers here, given that there is > > an > > ack from Greg in this email? Rodrigo was in the loop of us needing to > > merge this via drm, so I thought I was good on that side. I'll make > > sure > > to have an explicit ack on the ML next time (which is coming > > relatively > > soon, because there are some more mei patches in the DG2 HuC series). > > That's my fault indeed. I was following the movement, but I failed > to step up right after I saw Greg's ack. > Although I also noticed some re-send and reviews in progress even > after the ack, I should had been more active there. > > Sorry, > Rodrigo. > > > > > > > > > Quoting from the committer guidelines[1] the first rule is: > > > "Only push patches changing drivers/gpu/drm/i915." > > > > > > In those cases, please ping a maintainer and don't rush things. > > > > Will do. And apologies again for the mistake. > > > > Daniele > > > > > Regards, Joonas > > > > > > [1] https://drm.pages.freedesktop.org/maintainer-tools/committer- > > > drm-intel.html#high-level-guidelines > > > > > >
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
[Intel-gfx] [PULL] drm-intel-gt-next
e 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.h | 8 +- drivers/gpu/drm/i915/gt/uc/selftest_guc.c
Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2
Dave, do you have a preference how to deal with the mishap here, shall I do a force-push to drm-intel-gt-next to correctly record the Acked-by or revert and re-push? Or just leave it as is? Quoting Greg Kroah-Hartman (2022-09-01 18:09:09) > On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote: > > Add GSC support for XeHP SDV and DG2 platforms. > > > > The series includes changes for the mei driver: > > - add ability to use polling instead of interrupts > > - add ability to use extended timeouts > > - setup extended operational memory for GSC > > > > The series includes changes for the i915 driver: > > - allocate extended operational memory for GSC > > - GSC on XeHP SDV offsets and definitions > > > > This patch set should be merged via gfx tree as > > the auxiliary device belongs there. > > Greg, your ACK is required for the drives/misc/mei code base, > > please review the patches. > > With the exception that you all don't know what year it is: > > Acked-by: Greg Kroah-Hartman Daniele, why were the patches applied without this A-b? I'm just preparing the drm-intel-gt-next pull request and now it appears like we're pushing a lot of commits outside of drm without any Acks. Please reach out to the maintainers *before* pushing code for other subsystems. Unless you get an explicit ack to do so, do not push such code. Quoting from the committer guidelines[1] the first rule is: "Only push patches changing drivers/gpu/drm/i915." In those cases, please ping a maintainer and don't rush things. Regards, Joonas [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#high-level-guidelines
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
>
Re: ✓ Fi.CI.BAT: success for drm/i915/guc: Remove log size module parameters (rev2)
Quoting Patchwork (2022-08-26 13:54:30)
> Patch Details
>
> Series: drm/i915/guc: Remove log size module parameters (rev2)
> URL: https://patchwork.freedesktop.org/series/107780/
> State: success
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107780v2/index.html
>
> CI Bug Log - changes from CI_DRM_12031 -> Patchwork_107780v2
>
> Summary
>
> SUCCESS
>
> No regressions found.
Pushed the patch. Thanks for the reviews.
Regards, Joonas
>
> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107780v2/
> index.html
>
> Participating hosts (38 -> 37)
>
> Additional (2): bat-adln-1 bat-dg1-5
> Missing (3): fi-hsw-4770 bat-rpls-2 bat-dg2-10
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_107780v2:
>
> IGT changes
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> • igt@i915_pm_rps@basic-api:
> □ {bat-adln-1}: NOTRUN -> SKIP
>
> Known issues
>
> Here are the changes found in Patchwork_107780v2 that come from known issues:
>
> IGT changes
>
> Issues hit
>
> • igt@fbdev@read:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#2582) +4 similar issues
> • igt@gem_mmap@basic:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4083)
> • igt@gem_tiled_fence_blits@basic:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4077) +2 similar issues
> • igt@gem_tiled_pread_basic:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4079) +1 similar issue
> • igt@i915_pm_backlight@basic-brightness:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#1155)
> • igt@i915_pm_rps@basic-api:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#6621)
> • igt@i915_selftest@live@gt_engines:
>
> □ bat-dg1-5: NOTRUN -> INCOMPLETE (i915#4418)
> • igt@i915_suspend@basic-s3-without-i915:
>
> □ fi-rkl-11600: PASS -> INCOMPLETE (i915#5982)
> • igt@kms_addfb_basic@basic-x-tiled-legacy:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4212) +7 similar issues
> • igt@kms_addfb_basic@basic-y-tiled-legacy:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4215)
> • igt@kms_busy@basic:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#1845 / i915#4303)
> • igt@kms_chamelium@hdmi-hpd-fast:
>
> □ bat-dg1-5: NOTRUN -> SKIP (fdo#111827) +7 similar issues
> • igt@kms_force_connector_basic@force-load-detect:
>
> □ bat-dg1-5: NOTRUN -> SKIP (fdo#109285)
> • igt@kms_pipe_crc_basic@nonblocking-crc:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#4078) +13 similar issues
> • igt@kms_psr@sprite_plane_onoff:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#1072 / i915#4078) +3 similar issues
> • igt@kms_setmode@basic-clone-single-crtc:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#3555)
> • igt@prime_vgem@basic-fence-flip:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#1845 / i915#3708)
> • igt@prime_vgem@basic-fence-read:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#3708) +2 similar issues
> • igt@prime_vgem@basic-gtt:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#3708 / i915#4077) +1 similar issue
> • igt@prime_vgem@basic-userptr:
>
> □ bat-dg1-5: NOTRUN -> SKIP (i915#3708 / i915#4873)
> • igt@runner@aborted:
>
> □ bat-dg1-5: NOTRUN -> FAIL (i915#4312 / i915#5257)
>
> Possible fixes
>
> • igt@i915_selftest@live@hangcheck:
>
> □ {fi-ehl-2}: INCOMPLETE (i915#5153) -> PASS
>
> □ {bat-dg2-11}: INCOMPLETE -> PASS
>
> • igt@i915_selftest@live@requests:
>
> □ {bat-rpls-1}: INCOMPLETE (i915#4983 / i915#6257 / i915#6380) -> PASS
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> Build changes
>
> • Linux: CI_DRM_12031 -> Patchwork_107780v2
>
> CI-20190529: 20190529
> CI_DRM_12031: 3a648e054afa78544f00531084cad2d3c18c5b9f @ git://
> anongit.freedesktop.org/gfx-ci/linux
> IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @ https://
> gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_107780v2: 3a648e054afa78544f00531084cad2d3c18c5b9f @ git://
> anongit.freedesktop.org/gfx-ci/linux
>
> Linux commits
>
> 86ecb944c399 drm/i915/guc: Remove log size module parameters
>
[Intel-gfx] [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
[Intel-gfx] [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 > >>> > >>> Quoting john.c.harri...@intel.com (2022-07-28 05:20:27) > >>>> From: John Harriso
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));
> >> - BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> >> - B
[Intel-gfx] [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
Re: [Intel-gfx] [PATCH v2] drm/i915/dg2: Add Wa_1509727124
Quoting Matt Roper (2022-08-02 18:09:16) > On Mon, Aug 01, 2022 at 02:38:39PM -0700, Harish Chegondi wrote: > > Bspec: 46052 > > Reviewed-by: Matt Roper > > Signed-off-by: Harish Chegondi > > Applied to drm-intel-gt-next. Thanks for the patch. This patch is completely lacking the commit message. That is unacceptable, please make sure there is a proper commit message for any merged patches going forward. Please do explain the patch rationale in this mail thread so it at least becomes available from the Link: that gets added by DIM when this was committed. Regards, Joonas
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 = >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(>log);
>
> if (min_size < 0)
> drm_warn(>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 > buffer_size)
>
[Intel-gfx] [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(-)
[Intel-gfx] [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(-)
[Intel-gfx] [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(-)
Re: [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db from device info
Quoting Souza, Jose (2022-05-09 17:19:28)
> On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen wrote:
> > Quoting José Roberto de Souza (2022-05-07 16:28:50)
> > > No need to have this parameter in intel_device_info struct
> > > as this feature is supported by Broadwell, Haswell all platforms with
> > > display version 9 or newer.
> >
> > This is opposite of the direction we want to move to.
> >
> > We want to embrace the has_xyz flags, instead of the macro trickery.
>
> This ever growing flag definition is causing problems when defining new
> platforms.
The ever growing macros that change between kernel versions are much
more painful than easily printable list per SKU.
Just to make it clear, a strict NACK from me for merging any patches
into this direction.
Regards, Joonas
>
> There is too many features to check if a new platform supports each one of
> it, what is leading to platform definition errors.
>
> Also usually when a feature is dropped a HSD will be filed, so the person
> taking care of that can just adjust the macro upper platform or IP bound and
> disable it for good.
>
> >
> > > As a side effect of the of removal this flag, it will not be printed
> > > in dmesg during driver load anymore and developers will have to rely
> > > on to check the macro and compare with platform being used and IP
> > > versions of it.
> >
> > This is not a very good rationale. If the platform has something, but it
> > becomes disabled in runtime, then we should add an another print after
> > the runtime sanitization has been done.
>
> In my opinion this flags should only change in runtime if the feature is
> fused off like is done for has_dsc and has_dmc.
>
> >
> > Regards, Joonas
> >
> > >
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 4 +++-
> > > drivers/gpu/drm/i915/i915_pci.c | 3 ---
> > > drivers/gpu/drm/i915/intel_device_info.h | 1 -
> > > 3 files changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 4b1025dbaab2a..4a1edf48d37b9 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1306,7 +1306,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > > IS_BROADWELL(dev_priv) || \
> > > IS_HASWELL(dev_priv))
> > > #define HAS_DP_MST(dev_priv)(HAS_DDI(dev_priv))
> > > -#define HAS_FPGA_DBG_UNCLAIMED(dev_priv)
> > > (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> > > +#define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (DISPLAY_VER(dev_priv) >= 9 || \
> > > + IS_BROADWELL(dev_priv) || \
> > > + IS_HASWELL(dev_priv))
> > > #define HAS_PSR(dev_priv) (DISPLAY_VER(dev_priv) >= 9)
> > > #define HAS_PSR2_SEL_FETCH(dev_priv)(DISPLAY_VER(dev_priv) >= 12)
> > > #define HAS_TRANSCODER(dev_priv, trans)
> > > ((INTEL_INFO(dev_priv)->display.cpu_transcoder_mask & BIT(trans)) != 0)
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 5a42acb162a15..6a5b70b3ea2d7 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -523,7 +523,6 @@ static const struct intel_device_info vlv_info = {
> > > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) |
> > > BIT(VECS0), \
> > > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) |
> > > BIT(TRANSCODER_B) | \
> > > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > > - .display.has_fpga_dbg = 1, \
> > > HSW_PIPE_OFFSETS
> > >
> > > #define HSW_PLATFORM \
> > > @@ -657,7 +656,6 @@ static const struct intel_device_info skl_gt4_info = {
> > > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) |
> > > BIT(TRANSCODER_B) | \
> > > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> > > BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> > > - .display.has_fpga_dbg = 1, \
> > > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > > .display.has_hdcp = 1, \
> > > .display.has_dmc = 1, \
> > > @@ -894
Re: [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db from device info
Quoting José Roberto de Souza (2022-05-07 16:28:50)
> No need to have this parameter in intel_device_info struct
> as this feature is supported by Broadwell, Haswell all platforms with
> display version 9 or newer.
This is opposite of the direction we want to move to.
We want to embrace the has_xyz flags, instead of the macro trickery.
> As a side effect of the of removal this flag, it will not be printed
> in dmesg during driver load anymore and developers will have to rely
> on to check the macro and compare with platform being used and IP
> versions of it.
This is not a very good rationale. If the platform has something, but it
becomes disabled in runtime, then we should add an another print after
the runtime sanitization has been done.
Regards, Joonas
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 +++-
> drivers/gpu/drm/i915/i915_pci.c | 3 ---
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4b1025dbaab2a..4a1edf48d37b9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1306,7 +1306,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_BROADWELL(dev_priv) || \
> IS_HASWELL(dev_priv))
> #define HAS_DP_MST(dev_priv)(HAS_DDI(dev_priv))
> -#define HAS_FPGA_DBG_UNCLAIMED(dev_priv)
> (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> +#define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (DISPLAY_VER(dev_priv) >= 9 || \
> + IS_BROADWELL(dev_priv) || \
> + IS_HASWELL(dev_priv))
> #define HAS_PSR(dev_priv) (DISPLAY_VER(dev_priv) >= 9)
> #define HAS_PSR2_SEL_FETCH(dev_priv)(DISPLAY_VER(dev_priv) >= 12)
> #define HAS_TRANSCODER(dev_priv, trans)
> ((INTEL_INFO(dev_priv)->display.cpu_transcoder_mask & BIT(trans)) != 0)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 5a42acb162a15..6a5b70b3ea2d7 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -523,7 +523,6 @@ static const struct intel_device_info vlv_info = {
> .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) |
> BIT(VECS0), \
> .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B)
> | \
> BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> - .display.has_fpga_dbg = 1, \
> HSW_PIPE_OFFSETS
>
> #define HSW_PLATFORM \
> @@ -657,7 +656,6 @@ static const struct intel_device_info skl_gt4_info = {
> .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B)
> | \
> BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> - .display.has_fpga_dbg = 1, \
> .display.fbc_mask = BIT(INTEL_FBC_A), \
> .display.has_hdcp = 1, \
> .display.has_dmc = 1, \
> @@ -894,7 +892,6 @@ static const struct intel_device_info adl_s_info = {
> .display.has_dmc = 1,
> \
> .display.has_dsc = 1,
> \
> .display.fbc_mask = BIT(INTEL_FBC_A),
> \
> - .display.has_fpga_dbg = 1,
> \
> .display.has_hdcp = 1,
> \
> .display.has_hotplug = 1,
> \
> .display.ver = 13,
> \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 7581ef4a68f94..e61a334b611ac 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -157,7 +157,6 @@ enum intel_ppgtt_type {
> func(has_cdclk_crawl); \
> func(has_dmc); \
> func(has_dsc); \
> - func(has_fpga_dbg); \
> func(has_gmch); \
> func(has_hdcp); \
> func(has_hotplug); \
> --
> 2.36.0
>
[Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [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
Re: [Intel-gfx] [PATCH] drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines
Quoting Ville Syrjälä (2022-04-20 19:23:57)
> On Wed, Apr 20, 2022 at 05:32:43PM +0200, Hans de Goede wrote:
> > Hi Ville,
> >
> > On 4/20/22 16:03, Ville Syrjälä wrote:
> > > On Mon, Apr 18, 2022 at 05:09:36PM +0200, Hans de Goede wrote:
> > >> Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane
> > >> registers")
> > >> introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
> > >> their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
> > >>
> > >> This breaks the primary display pane on at least pineview machines, fix
> > >> the mask to fix the primary display pane only showing black.
> > >>
> > >> Tested on an Acer One AO532h with an Intel N450 SoC.
> > >>
> > >> Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane
> > >> registers")
> > >> Cc: José Roberto de Souza
> > >> Cc: Ville Syrjälä
> > >> Signed-off-by: Hans de Goede
> > >> ---
> > >> Note this fixes a regression in 5.18-rc# and I'm not entirely sure what
> > >> the procedure is here. Once I get a Reviewed-by or Acked-by and I push
> > >> this to drm-intel-next (where it also is necessary), should I then also
> > >> push it to drm-intel-fixes or will the current drm-intel-fixes
> > >> maintainer pick it up?
> > >> ---
> > >> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> > >> 1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > >> b/drivers/gpu/drm/i915/i915_reg.h
> > >> index 51f46fe45c72..5f1f38684d65 100644
> > >> --- a/drivers/gpu/drm/i915/i915_reg.h
> > >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> > >> @@ -4352,12 +4352,12 @@
> > >> #define _DSPAADDR 0x70184
> > >> #define _DSPASTRIDE 0x70188
> > >> #define _DSPAPOS 0x7018C /* reserved */
> > >> -#define DISP_POS_Y_MASK REG_GENMASK(31, 0)
> > >> +#define DISP_POS_Y_MASK REG_GENMASK(31, 16)
> > >
> > > Doh. I guess I only tested it on plane A where the plane gets its size
> > > from PIPESRC instead. And looks like the failure mode is such that
> > > the likes of kms_plane/pixel-formats still gets consistent looking CRCs
> > > even with the misconfigured plane size :/
> > >
> > > Thanks for the fix. Pushed to drm-intel-next.
> >
> > Thank you pushing this out, will you (or someone else from Intel)
> > also take care of getting this on its way to 5.18-rc# ?
>
> It has a fixes tag so it should get cherry-picked for fixes.
Yeah, it sould get picked up for next week's drm-intel-fixes PR.
For both drm-intel-next and drm-intel-gt-next, committers only push to
the -next branches and the rest is handled by tooling and maintainers as
long as the Fixes: tags are correct.
If a Fixes: tag has been missed when committing, only then you need to
manually let maintainers know to pick the patch up.
Regards, Joonas
>
> --
> Ville Syrjälä
> Intel
[Intel-gfx] [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: [Intel-gfx] [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(_tt->ttm, bo, page_flags, caching);
> > > > + ret = ttm_tt_init(_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(_be->ttm, bo, page_flags, ttm_write_combined)) {
> > > > + if (ttm_tt_init(_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
> > > > +++
[Intel-gfx] [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(-)
Re: [Intel-gfx] Small bar recovery vs compressed content on DG2
Quoting Thomas Hellström (2022-03-16 09:25:16) > Hi! > > Do we somehow need to clarify in the headers the semantics for this? > > From my understanding when discussing the CCS migration series with > Ram, the kernel will never do any resolving (compressing / > decompressing) migrations or evictions which basically implies the > following: > > *) Compressed data must have LMEM only placement, otherwise the GPU > would read garbage if accessing from SMEM. This has always been the case, so it should be documented in the uAPI headers and kerneldocs. > *) Compressed data can't be assumed to be mappable by the CPU, because > in order to ensure that on small BAR, the placement needs to be LMEM+SMEM. Not strictly true, as we could always migrate to the mappable region in the CPU fault handler. Will need the same set of tricks as with limited mappable GGTT in past. > *) Neither can compressed data be part of a CAPTURE buffer, because that > requires the data to be CPU-mappable. Especially this will be too big of a limitation which we can't really afford when it comes to debugging. Regards, Joonas > Are we (and user-mode drivers) OK with these restrictions, or do we need > to rethink? > > Thanks, > > Thomas > >
[Intel-gfx] [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
[Intel-gfx] [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(-)
Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next
Quoting Wang, Zhi A (2022-03-08 12:07:04) > Which suits better for you? For me, I am OK with both. If you are not in a > rush of closing the window, I can submit through drm-intel-next-fixes. I pulled this into drm-intel-next-fixes now. For future reference, let's have fixes only PRs as gvt-fixes and PRs with features as gvt-next and each as a new mail thread instead of a reply to older, so they will be easy to spot :) Regards, Joonas > > Thanks, > Zhi. > > On 3/8/22 9:56 AM, Nikula, Jani wrote: > > On Tue, 08 Mar 2022, "Wang, Zhi A" wrote: > >> Hi folks: > >> > >> Here is a new pull request of gvt-next. It contains a small patch to add > >> the missing > >> mdev attribute name, which will be used by the middleware, like kubevirt. > > > > I'm wondering if I should pull this to drm-intel-next, which is already > > targeting v5.19, or if it should be pulled to drm-intel-next-fixes > > targeting v5.18. It does look like a fix. > > > > BR, > > Jani. > > > > > >> > >> This pull has been tested by: > >> > >> $ dim apply-pull drm-intel-next < this_email.eml > >> > >> The following changes since commit > >> 30424ebae8df0f786835e7a31ad790fa00764f35: > >> > >> Merge tag 'drm-intel-gt-next-2022-02-17' of > >> git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next > >> (2022-02-23 15:03:51 -0500) > >> > >> are available in the Git repository at: > >> > >> https://github.com/intel/gvt-linux tags/gvt-next-2022-03-07 > >> > >> for you to fetch changes up to 43d26c4fc6c446d766253d546f0083d78023d34a: > >> > >> drm/i915/gvt: add the missing mdev attribute "name" (2022-03-07 12:21:58 > >> -0500) > >> > >> > >> - add the missing attribute "name" in VFIO mdev hierarchy. > >> > >> > >> Zhi Wang (1): > >> drm/i915/gvt: add the missing mdev attribute "name" > >> > >> drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +++ > >> 1 file changed, 15 insertions(+) > >> > > >
[Intel-gfx] [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
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
[Intel-gfx] [PULL] drm-intel-gt-next
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 pages during pending vma binds d
Re: [Intel-gfx] [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
[Intel-gfx] [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 + > >
Re: [Intel-gfx] [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(>num_pending) <= 0;
> > + if (atomic_read(>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: [Intel-gfx] linux-next: build failure after merge of the drm-intel-gt tree
+ intel-gfx mailing list (Stephen, can you include this going forward?)
Adding Thomas for this specific patch.
Regards, Joonas
Quoting Stephen Rothwell (2021-11-17 01:02:23)
> Hi all,
>
> After merging the etnaviv tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'vm_fault_ttm':
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:862:9: error: too many arguments to
> function 'ttm_bo_vm_fault_reserved'
> 862 | ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> | ^~~~
> In file included from include/drm/ttm/ttm_bo_driver.h:42,
> from drivers/gpu/drm/i915/gem/i915_gem_ttm.c:6:
> include/drm/ttm/ttm_bo_api.h:585:12: note: declared here
> 585 | vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
> |^~~~
>
> Caused by commit
>
> ebd4a8ec7799 ("drm/i915/ttm: move shrinker management into adjust_lru")
>
> interacting with commit
>
> 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
>
> from Linus' tree.
>
> I applied the following merge fix patch.
>
> From: Stephen Rothwell
> Date: Wed, 17 Nov 2021 09:57:09 +1100
> Subject: [PATCH] fix up for "drm/ttm: remove ttm_bo_vm_insert_huge()"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index d08a270b0921..68cfe6e9ceab 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -860,7 +860,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
>
> if (drm_dev_enter(dev, )) {
> ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> - TTM_BO_VM_NUM_PREFAULT, 1);
> + TTM_BO_VM_NUM_PREFAULT);
> drm_dev_exit(idx);
> } else {
> ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
> --
> 2.33.0
>
> --
> Cheers,
> Stephen Rothwell
Re: [Intel-gfx] 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: [Intel-gfx] 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: [Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [PATCH v8] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
Quoting Tvrtko Ursulin (2021-11-01 12:15:19)
>
> On 25/10/2021 05:26, Cooper Chiou wrote:
> > This implements WaProgramMgsrForCorrectSliceSpecificMmioReads which
> > was omitted by mistake from Gen9 documentation, while it is actually
> > applicable to fused off parts.
> >
> > Workaround consists of making sure MCR packet control register is
> > programmed to point to enabled slice/subslice pair before doing any
> > MMIO reads from the affected registers.
> >
> > Failure do to this can result in complete system hangs when running
> > certain workloads. Two known cases which can cause system hangs are:
> >
> > 1. "test_basic progvar_prog_scope_uninit" test which is part of
> > Khronos OpenCL conformance suite
> > (https://github.com/KhronosGroup/OpenCL-CTS) with the Intel
> > OpenCL driver (https://github.com/intel/compute-runtime).
> >
> > 2. VP8 media hardware encoding using the full-feature build of the
> > Intel media-driver (https://github.com/intel/media-driver) and
> > ffmpeg.
> >
> > For the former case patch was verified to fix the hard system hang
> > when executing the OCL test on Intel Pentium CPU 6405U which contains
> > fused off GT1 graphics.
> >
> > Reference: HSD#1508045018,1405586840, BSID#0575
> >
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: William Tseng
> > Cc: Shawn C Lee
> > Cc: Pawel Wilma
> > Signed-off-by: Cooper Chiou
>
> Reviewed-by: Tvrtko Ursulin
Thanks for following through with all the testing and validation for the
patch!
Acked-by: Joonas Lahtinen
Regards, Joonas
>
> Regards,
>
> Tvrtko
>
> P.S. You could have preserved my r-b from an earlier version since it is
> the same code, just different commit message.
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 41 +
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index e1f362530889..8ae24da601b0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -877,11 +877,52 @@ hsw_gt_workarounds_init(struct intel_gt *gt, struct
> > i915_wa_list *wal)
> > wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> > }
> >
> > +static void
> > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> > +{
> > + const struct sseu_dev_info *sseu = >gt.info.sseu;
> > + unsigned int slice, subslice;
> > + u32 mcr, mcr_mask;
> > +
> > + GEM_BUG_ON(GRAPHICS_VER(i915) != 9);
> > +
> > + /*
> > + * WaProgramMgsrForCorrectSliceSpecificMmioReads:gen9,glk,kbl,cml
> > + * Before any MMIO read into slice/subslice specific registers, MCR
> > + * packet control register needs to be programmed to point to any
> > + * enabled s/ss pair. Otherwise, incorrect values will be returned.
> > + * This means each subsequent MMIO read will be forwarded to an
> > + * specific s/ss combination, but this is OK since these registers
> > + * are consistent across s/ss in almost all cases. In the rare
> > + * occasions, such as INSTDONE, where this value is dependent
> > + * on s/ss combo, the read should be done with read_subslice_reg.
> > + */
> > + slice = ffs(sseu->slice_mask) - 1;
> > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > + subslice = ffs(intel_sseu_get_subslices(sseu, slice));
> > + GEM_BUG_ON(!subslice);
> > + subslice--;
> > +
> > + /*
> > + * We use GEN8_MCR..() macros to calculate the |mcr| value for
> > + * Gen9 to address WaProgramMgsrForCorrectSliceSpecificMmioReads
> > + */
> > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > +
> > + drm_dbg(>drm, "MCR slice:%d/subslice:%d = %x\n", slice,
> > subslice, mcr);
> > +
> > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > +}
> > +
> > static void
> > gen9_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> > {
> > struct drm_i915_private *i915 = gt->i915;
> >
> > + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml,gen9 */
> > + gen9_wa_init_mcr(i915, wal);
> > +
> > /* WaDisableKillLogic:bxt,skl,kbl */
> > if (!IS_COFFEELAKE(i915) && !IS_COMETLAKE(i915))
> > wa_write_or(wal,
> >
