[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Stop using flush_scheduled_work on driver remove
== Series Details == Series: drm/i915: Stop using flush_scheduled_work on driver remove URL : https://patchwork.freedesktop.org/series/108970/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12175_full -> Patchwork_108970v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108970v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108970v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 10) -- Additional (1): shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108970v1_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@cursor: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-tglb7/igt@i915_pm_...@cursor.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-tglb8/igt@i915_pm_...@cursor.html Known issues Here are the changes found in Patchwork_108970v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [FAIL][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4386]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/shard-apl6/boot.html [36]:
Re: [Intel-gfx] [PATCH] drm/i915: Remove unused function parameter
On Thu, Sep 22, 2022 at 02:39:16PM -0700, Niranjana Vishwanathapura wrote:
> The function parameter 'exclude' in funciton
> i915_sw_fence_await_reservation() is not used.
> Remove it.
>
> Reviewed-by: Tvrtko Ursulin
> Signed-off-by: Niranjana Vishwanathapura
pushed to drm-intel-next.
Thanks for the patch and review.
> ---
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 ++---
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
> drivers/gpu/drm/i915/i915_sw_fence.c | 1 -
> drivers/gpu/drm/i915/i915_sw_fence.h | 1 -
> 4 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index aaa6708256d5..ecb8d71d36c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -1005,7 +1005,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>*/
> if (intel_crtc_needs_modeset(crtc_state)) {
> ret =
> i915_sw_fence_await_reservation(>commit_ready,
> -
> old_obj->base.resv, NULL,
> +
> old_obj->base.resv,
> false, 0,
> GFP_KERNEL);
> if (ret < 0)
> @@ -1039,8 +1039,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> struct dma_fence *fence;
>
> ret = i915_sw_fence_await_reservation(>commit_ready,
> - obj->base.resv, NULL,
> - false,
> + obj->base.resv, false,
>
> i915_fence_timeout(dev_priv),
> GFP_KERNEL);
> if (ret < 0)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> index 0512afdd20d8..b3b398fe689c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> @@ -113,7 +113,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
> *obj,
> clflush = clflush_work_create(obj);
> if (clflush) {
> i915_sw_fence_await_reservation(>base.chain,
> - obj->base.resv, NULL, true,
> + obj->base.resv, true,
> i915_fence_timeout(i915),
> I915_FENCE_GFP);
> dma_resv_add_fence(obj->base.resv, >base.dma,
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> b/drivers/gpu/drm/i915/i915_sw_fence.c
> index 6fc0d1b89690..cc2a8821d22a 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -571,7 +571,6 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
> *fence,
>
> int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> struct dma_resv *resv,
> - const struct dma_fence_ops *exclude,
> bool write,
> unsigned long timeout,
> gfp_t gfp)
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
> b/drivers/gpu/drm/i915/i915_sw_fence.h
> index 619fc5a22f0c..f752bfc7c6e1 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.h
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.h
> @@ -91,7 +91,6 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
> *fence,
>
> int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> struct dma_resv *resv,
> - const struct dma_fence_ops *exclude,
> bool write,
> unsigned long timeout,
> gfp_t gfp);
> --
> 2.21.0.rc0.32.g243a4c7e27
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs
On Thu, Sep 22, 2022 at 12:51:27PM -0700, Nathan Chancellor wrote:
> [...]
> To make everything work properly, adjust certain functions to match the
> type of the ->show() and ->store() members in 'struct kobj_attribute'.
> Add a macro to generate functions for that can be called via both
> dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
> called through both kobject locations without violating kCFI and adjust
> the attribute groups to account for this.
This was quite a roller coaster! I think the solution looks good, even
if I'm suspicious of the original design that has the same stuff
available twice in different places. (I have a dim memory of rdma
needing a refactoring like this too?)
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Re: [Intel-gfx] [RFC v4 13/14] drm/i915/vm_bind: Skip vma_lookup for persistent vmas
On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote: On 21/09/2022 08:09, Niranjana Vishwanathapura wrote: vma_lookup is tied to segment of the object instead of section Can be, but not only that. It would be more accurate to say it is based of gtt views. Yah, but new code is also based on gtt views, the only difference is that now there can be multiple mappings (at different VAs) to the same gtt_view of the object. of VA space. Hence, it do not support aliasing (ie., multiple bindings to the same section of the object). Skip vma_lookup for persistent vmas as it supports aliasing. What's broken without this patch? If something is, should it go somewhere earlier in the series? If so should be mentioned in the commit message. Or is it just a performance optimisation to skip unused tracking? If so should also be mentioned in the commit message. No, it is not a performance optimization. The vma_lookup is based on the fact that there can be only one mapping for a given gtt_view of the object. So, it was looking for gtt_view to find the mapping. But now, as I mentioned above, there can be multiple mappings for a given gtt_view of the object. Hence the vma_lookup method won't work here. Hence, it is being skipped for persistent vmas. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +- .../drm/i915/display/intel_plane_initial.c| 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +- .../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 16 +++ .../i915/gem/selftests/i915_gem_client_blt.c | 2 +- .../drm/i915/gem/selftests/i915_gem_context.c | 12 ++--- .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 6 ++- .../drm/i915/gem/selftests/igt_gem_utils.c| 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_ring.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 4 +- drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- drivers/gpu/drm/i915/gt/mock_engine.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 +++ drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +-- drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +- .../gpu/drm/i915/gt/selftest_workarounds.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 26 +++ drivers/gpu/drm/i915/i915_vma.h | 3 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 44 +-- drivers/gpu/drm/i915/selftests/i915_request.c | 4 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +- .../drm/i915/selftests/intel_memory_region.c | 2 +- 37 files changed, 106 insertions(+), 93 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c b/drivers/gpu/drm/i915/display/intel_fb_pin.c index c86e5d4ee016..5a718b247bb3 100644 --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c @@ -47,7 +47,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb, goto err; } - vma = i915_vma_instance(obj, vm, view); + vma = i915_vma_instance(obj, vm, view, false); Hey why are you touching all the legacy paths? >:P if (IS_ERR(vma)) goto err; diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c index 76be796df255..7667e2faa3fb 100644 --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c @@ -136,7 +136,7 @@ initial_plane_vma(struct drm_i915_private *i915, goto err_obj; } - vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL); + vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL, false); if (IS_ERR(vma)) goto err_obj; diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 363b2a788cdf..0ee43cb601b5 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -876,7 +876,7 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions
On Thu, Sep 22, 2022 at 12:54:09PM +0300, Jani Nikula wrote:
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
new file mode 100644
index ..725febfd6a53
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_EXECBUFFER_COMMON_H
+#define __I915_GEM_EXECBUFFER_COMMON_H
+
+#include
+
+#include "gt/intel_context.h"
You don't need these includes. Most of it can be handled using forward
declarations. You'll need
Thanks Jani,
Sure, here and everywhere I will remove the unwanted includes and use
forward declarations instead.
+
+struct eb_fence {
+ struct drm_syncobj *syncobj;
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
+int __eb_pin_engine(struct intel_context *ce, struct i915_gem_ww_ctx *ww,
+ bool throttle, bool nonblock);
+void __eb_unpin_engine(struct intel_context *ce);
+int __eb_select_engine(struct intel_context *ce);
+void __eb_put_engine(struct intel_context *context, struct intel_gt *gt);
+
+struct intel_context *
+eb_find_context(struct intel_context *context, unsigned int context_number);
+
+int add_timeline_fence(struct drm_file *file, u32 handle, u64 point,
+ struct eb_fence *f, bool wait, bool signal);
+void put_fence_array(struct eb_fence *fences, u64 num_fences);
+int await_fence_array(struct eb_fence *fences, u64 num_fences,
+ struct i915_request *rq);
+void signal_fence_array(struct eb_fence *fences, u64 num_fences,
+ struct dma_fence * const fence);
+
+int eb_requests_add(struct i915_request **requests, unsigned int num_batches,
+ struct intel_context *context, struct i915_sched_attr sched,
struct i915_sched_attr is passed by value, so you either need to turn
that into a pointer, or you need the definition. The definition is just
a wrapper around an int. (For strict type safety or for future proofing
or what, I don't know.) And this all brings me to my pet peeve about
gem/gt headers.
To get that definition of a struct wrapper around an int, you need to
include i915_scheduler_types.h, which recursively includes a total of 16
headers. Touch any of those files, and you get a rebuild butterfly
effect.
28% of i915 header files, when modified, cause the rebuild of 83% of the
driver. Please let's not make it worse.
Ok. I think it is passed by value as it is just a wrapper around an int.
I am just moving this function to a separate file.
Will keep it as such, but will forward declare it insted of including
the i915_scheduler_types.h.
Regards,
Niranjana
BR,
Jani.
+ int err);
+void eb_requests_get(struct i915_request **requests, unsigned int num_batches);
+void eb_requests_put(struct i915_request **requests, unsigned int num_batches);
+
+struct dma_fence *__eb_composite_fence_create(struct i915_request **requests,
+ unsigned int num_batches,
+ struct intel_context *context);
+
+#endif /* __I915_GEM_EXECBUFFER_COMMON_H */
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/perf: Add OAG and OAR formats for DG2
On Fri, 23 Sep 2022 13:11:41 -0700, Umesh Nerlige Ramappa wrote: > Commit title probably now "Add 32 bit OAG and OAR formats for DG2"? > Add new OA formats for DG2. Some of the newer OA formats are not > multples of 64 bytes and are not powers of 2. For those formats, adjust > hw_tail accordingly when checking for new reports. We are not touching hw_tail now, should we delete this from the commit message? Thanks. -- Ashutosh
Re: [Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
On Fri, 23 Sep 2022 12:56:42 -0700, Badal Nilawar wrote: > > From: Ashutosh Dixit > > Expose power1_max_interval, that is the tau corresponding to PL1. I think let's change the above sentence to: "Expose power1_max_interval, that is the tau corresponding to PL1, as a custom hwmon attribute". This is the only custom attribute we are exposing so better to mention this in the commit message I think. Thanks. -- Ashutosh
Re: [Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
On Fri, 23 Sep 2022 12:56:40 -0700, Badal Nilawar wrote:
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.h
> b/drivers/gpu/drm/i915/i915_hwmon.h
> index 7ca9cf2c34c9..4e5b6c149f3a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.h
> +++ b/drivers/gpu/drm/i915/i915_hwmon.h
> @@ -17,4 +17,5 @@ static inline void i915_hwmon_register(struct
> drm_i915_private *i915) { };
> static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
> #endif
>
> +int i915_hwmon_energy_status_get(struct drm_i915_private *i915, long
> *energy);
We deleted this function definition, this is just leftover so please delete
this too.
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
On Fri, 23 Sep 2022 12:56:37 -0700, Badal Nilawar wrote:
>
Hi Badal,
Let me add this comment on the latest version so we don't forget about it:
> +void i915_hwmon_register(struct drm_i915_private *i915)
> +{
> + struct device *dev = i915->drm.dev;
> + struct i915_hwmon *hwmon;
> + struct device *hwmon_dev;
> + struct hwm_drvdata *ddat;
> +
> + /* hwmon is available only for dGfx */
> + if (!IS_DGFX(i915))
> + return;
> +
> + hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
If we are using devm_kzalloc we might as well replace all the
hwmon_device_register_with_info's (in Patch 1 and 7) with
devm_hwmon_device_register_with_info and then i915_hwmon_unregister is just
this:
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
fetch_and_zero(>hwmon);
}
Even the above statement is probably not needed but might as well retain it
for sanity. So this is a simple change.
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
On Wed, 21 Sep 2022 05:44:35 -0700, Andi Shyti wrote:
>
> > +void i915_hwmon_register(struct drm_i915_private *i915)
> > +{
> > + struct device *dev = i915->drm.dev;
> > + struct i915_hwmon *hwmon;
> > + struct device *hwmon_dev;
> > + struct hwm_drvdata *ddat;
> > +
> > + /* hwmon is available only for dGfx */
> > + if (!IS_DGFX(i915))
> > + return;
> > +
> > + hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
>
> why don't we use devm_kzalloc?
>
> > + if (!hwmon)
> > + return;
> > +
> > + i915->hwmon = hwmon;
> > + mutex_init(>hwmon_lock);
> > + ddat = >ddat;
> > +
> > + ddat->hwmon = hwmon;
> > + ddat->uncore = >uncore;
> > + snprintf(ddat->name, sizeof(ddat->name), "i915");
> > +
> > + hwm_get_preregistration_info(i915);
> > +
> > + /* hwmon_dev points to device hwmon */
> > + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> > + ddat,
> > + _chip_info,
> > + NULL);
> > + if (IS_ERR(hwmon_dev)) {
> > + mutex_destroy(>hwmon_lock);
>
> there is not such a big need to destroy the mutex. Destroying
> mutexes is more useful when you actually are creating/destroying
> and there is some debug need. I don't think that's the case.
>
> With the devm_kzalloc this would be just a return.
If we are using devm_kzalloc we might as well replace all the
hwmon_device_register_with_info's (in Patch 1 and 7) with
devm_hwmon_device_register_with_info and then i915_hwmon_unregister is just
this:
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
fetch_and_zero(>hwmon);
}
Even the above statement is probably not needed but might as well retain it
for sanity. So this is a simple change.
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/pxp: Add firmware status when ARB session fails
On Thu, Sep 22, 2022 at 11:44 PM Alan Previn wrote: > > Add firmware status using a drm_warn when ARB session fails > or else a drm_dbg when the ARB session register slot bit did > get set. > > Signed-off-by: Alan Previn > --- > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 1 + > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c > b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c > index 1bb5b5249157..c4f5c994ca51 100644 > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c > @@ -77,6 +77,7 @@ static int pxp_create_arb_session(struct intel_pxp *pxp) > drm_err(>i915->drm, "arb session failed to go in play\n"); > return ret; > } > + drm_dbg(>i915->drm, "PXP ARB session is alive\n"); > > if (!++pxp->key_instance) > ++pxp->key_instance; > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > index 4b6f5655fab5..a90905039216 100644 > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > @@ -174,6 +174,9 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp > *pxp, > > if (ret) > drm_err(>drm, "Failed to send tee msg ret=[%d]\n", ret); > + else if (msg_out.header.status != 0x0) > + drm_warn(>drm, "PXP firmware failed arb session init > request ret=[0x%08x]\n", > +msg_out.header.status); > > return ret; > } > -- > 2.25.1 > Reviewed-by: Juston Li
[Intel-gfx] ✓ Fi.CI.IGT: success for Add SLPC selftest live_slpc_power (rev2)
== Series Details == Series: Add SLPC selftest live_slpc_power (rev2) URL : https://patchwork.freedesktop.org/series/108900/ State : success == Summary == CI Bug Log - changes from CI_DRM_12174_full -> Patchwork_108900v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 9) -- Missing(1): shard-tglu Known issues Here are the changes found in Patchwork_108900v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-out-fence: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-iclb4/igt@gem_exec_balan...@parallel-out-fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-iclb5/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gen9_exec_parse@allowed-single: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#5566] / [i915#716]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-glk2/igt@gen9_exec_pa...@allowed-single.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-glk9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#3989] / [i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-iclb5/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-iclb3/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@sysfs-reader: - shard-apl: NOTRUN -> [DMESG-WARN][13] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@linear-32bpp-rotate-270: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +43 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl1/igt@kms_big...@linear-32bpp-rotate-270.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_color_chamelium@ctm-red-to-blue: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl1/igt@kms_color_chamel...@ctm-red-to-blue.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180] / [i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/shard-apl7/igt@kms_flip@flip-vs-susp...@a-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-apl8/igt@kms_flip@flip-vs-susp...@a-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#2672] / [i915#3555]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN ->
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915/mtl: Define engine context layouts
On Fri, Sep 23, 2022 at 03:48:51PM -0700, Lucas De Marchi wrote:
> On Thu, Sep 15, 2022 at 06:46:48PM -0700, Radhakrishna Sripada wrote:
> > From: Matt Roper
> >
> > The part of the media and blitter engine contexts that we care about for
> > setting up an initial state are the same on MTL as they were on DG2
> > (and PVC), so we need to update the driver conditions to re-use the DG2
> > context table.
>
> this paragraph doesn't match what you are doing in the patch. Which one
> is correct? From "v2" below it looks like the original intention was to
> just reuse and now they are changed.
>
> >
> > For render/compute engines, the part of the context images are nearly
> > the same, although the layout had a very slight change --- one POSH
> > register was removed and the placement of some LRI/noops adjusted
> > slightly to compensate.
> >
> > v2:
> > - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
> > - Add missing nop in xcs offsets(Bala)
> > v3:
> > - Fix the spacing for nop in xcs offset(MattR)
> > v4:
> > - Fix rcs register offset(MattR)
> >
> > Bspec: 46261, 46260, 45585
> > Cc: Balasubramani Vivekanandan
> > Signed-off-by: Matt Roper
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 84 -
> > 1 file changed, 82 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 3955292483a6..c7937d8d120a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -264,6 +264,39 @@ static const u8 dg2_xcs_offsets[] = {
> > END
> > };
> >
> > +static const u8 mtl_xcs_offsets[] = {
> > + NOP(1),
> > + LRI(13, POSTED),
> > + REG16(0x244),
> > + REG(0x034),
> > + REG(0x030),
> > + REG(0x038),
> > + REG(0x03c),
> > + REG(0x168),
> > + REG(0x140),
> > + REG(0x110),
> > + REG(0x1c0),
> > + REG(0x1c4),
> > + REG(0x1c8),
> > + REG(0x180),
> > + REG16(0x2b4),
>
> are we missing 0x120 here?
>
> > + NOP(4),
>
> NOP(2), but it seems this is here to
> overcome the missing 0x120?
If 0x120 were included, it's a 64-bit register so it would fill both of
the NOP slots (i.e., it would be listed as 0x120 and 0x124 in the code
here).
The bspec tagging/filtering doesn't seem to be working quite right here.
The project column of bspec 45585 indicates it should only be included
here on PVC (and all other platforms should have a 4-dword NOP instead).
But the filter option doesn't actually drop out the row of the table as
you'd expect. Also inspecting the tags directly leaves some ambiguity
about whether the final platform list is correct or not.
I suspect it doesn't actually really matter whether we include that
register here or not; the overall "shape" of the context image is
correct either way. The hardware should be able to do its initial
context switch with load suppressed regardless. After that the next
time a context switch happens the full context will get written out to
memory in the correct form. And 0x120 isn't a register we're actively
doing anything with in the driver that would require special care.
If need be, we could always look at a post-context switch context in
memory on actual hardware and see whether it includes 0x120 in this spot
or not.
>
> > +
> > + NOP(1),
> > + LRI(9, POSTED),
> > + REG16(0x3a8),
> > + REG16(0x28c),
> > + REG16(0x288),
> > + REG16(0x284),
> > + REG16(0x280),
> > + REG16(0x27c),
> > + REG16(0x278),
> > + REG16(0x274),
> > + REG16(0x270),
> > +
> > + END
> > +};
> > +
> > static const u8 gen8_rcs_offsets[] = {
> > NOP(1),
> > LRI(14, POSTED),
> > @@ -606,6 +639,49 @@ static const u8 dg2_rcs_offsets[] = {
> > END
> > };
> >
> > +static const u8 mtl_rcs_offsets[] = {
> > + NOP(1),
> > + LRI(15, POSTED),
> > + REG16(0x244),
> > + REG(0x034),
> > + REG(0x030),
> > + REG(0x038),
> > + REG(0x03c),
> > + REG(0x168),
> > + REG(0x140),
> > + REG(0x110),
> > + REG(0x1c0),
> > + REG(0x1c4),
> > + REG(0x1c8),
> > + REG(0x180),
> > + REG16(0x2b4),
> > + REG(0x120),
> > + REG(0x124),
> > +
> > + NOP(1),
> > + LRI(9, POSTED),
>
> humn... set_offsets() is forcing MI_LRI_LRM_CS_MMIO
> for ver >= 11, although here bspec shows this MI_LOAD_REGISTER_IMM
> doesn't have it set.
Since all of the offsets here are engine-relative offsets, that sounds
like a spec bug. Otherwise you'd be loading into absolute register
offsets 0x3a8, 0x28c, etc. rather than the proper registers. It's
probably a copy/paste from the render engine's page where they document
everything with the absolute 0x2XXX offsets.
Matt
>
> +Mika, +Chris
>
>
> Lucas De Marchi
>
> > + REG16(0x3a8),
> > + REG16(0x28c),
> > + REG16(0x288),
> > + REG16(0x284),
> > + REG16(0x280),
> > + REG16(0x27c),
> > + REG16(0x278),
> > + REG16(0x274),
> > + REG16(0x270),
> > +
> > + NOP(2),
> >
[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/108945/ State : success == Summary == CI Bug Log - changes from CI_DRM_12173_full -> Patchwork_108945v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108945v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [FAIL][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4386]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl2/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl2/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl6/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl6/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl1/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl1/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl3/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl3/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl2/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/shard-apl8/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl7/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl8/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl6/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl3/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl3/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl3/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl3/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/shard-apl2/boot.html
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915/mtl: Define engine context layouts
On Thu, Sep 15, 2022 at 06:46:48PM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.
this paragraph doesn't match what you are doing in the patch. Which one
is correct? From "v2" below it looks like the original intention was to
just reuse and now they are changed.
For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.
v2:
- Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
- Add missing nop in xcs offsets(Bala)
v3:
- Fix the spacing for nop in xcs offset(MattR)
v4:
- Fix rcs register offset(MattR)
Bspec: 46261, 46260, 45585
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 84 -
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3955292483a6..c7937d8d120a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -264,6 +264,39 @@ static const u8 dg2_xcs_offsets[] = {
END
};
+static const u8 mtl_xcs_offsets[] = {
+ NOP(1),
+ LRI(13, POSTED),
+ REG16(0x244),
+ REG(0x034),
+ REG(0x030),
+ REG(0x038),
+ REG(0x03c),
+ REG(0x168),
+ REG(0x140),
+ REG(0x110),
+ REG(0x1c0),
+ REG(0x1c4),
+ REG(0x1c8),
+ REG(0x180),
+ REG16(0x2b4),
are we missing 0x120 here?
+ NOP(4),
NOP(2), but it seems this is here to
overcome the missing 0x120?
+
+ NOP(1),
+ LRI(9, POSTED),
+ REG16(0x3a8),
+ REG16(0x28c),
+ REG16(0x288),
+ REG16(0x284),
+ REG16(0x280),
+ REG16(0x27c),
+ REG16(0x278),
+ REG16(0x274),
+ REG16(0x270),
+
+ END
+};
+
static const u8 gen8_rcs_offsets[] = {
NOP(1),
LRI(14, POSTED),
@@ -606,6 +639,49 @@ static const u8 dg2_rcs_offsets[] = {
END
};
+static const u8 mtl_rcs_offsets[] = {
+ NOP(1),
+ LRI(15, POSTED),
+ REG16(0x244),
+ REG(0x034),
+ REG(0x030),
+ REG(0x038),
+ REG(0x03c),
+ REG(0x168),
+ REG(0x140),
+ REG(0x110),
+ REG(0x1c0),
+ REG(0x1c4),
+ REG(0x1c8),
+ REG(0x180),
+ REG16(0x2b4),
+ REG(0x120),
+ REG(0x124),
+
+ NOP(1),
+ LRI(9, POSTED),
humn... set_offsets() is forcing MI_LRI_LRM_CS_MMIO
for ver >= 11, although here bspec shows this MI_LOAD_REGISTER_IMM
doesn't have it set.
+Mika, +Chris
Lucas De Marchi
+ REG16(0x3a8),
+ REG16(0x28c),
+ REG16(0x288),
+ REG16(0x284),
+ REG16(0x280),
+ REG16(0x27c),
+ REG16(0x278),
+ REG16(0x274),
+ REG16(0x270),
+
+ NOP(2),
+ LRI(2, POSTED),
+ REG16(0x5a8),
+ REG16(0x5ac),
+
+ NOP(6),
+ LRI(1, 0),
+ REG(0x0c8),
+
+ END
+};
+
#undef END
#undef REG16
#undef REG
@@ -624,7 +700,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
*engine)
!intel_engine_has_relative_mmio(engine));
if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
- if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+ return mtl_rcs_offsets;
+ else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_rcs_offsets;
else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
return xehp_rcs_offsets;
@@ -637,7 +715,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
*engine)
else
return gen8_rcs_offsets;
} else {
- if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+ return mtl_xcs_offsets;
+ else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_xcs_offsets;
else if (GRAPHICS_VER(engine->i915) >= 12)
return gen12_xcs_offsets;
--
2.34.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add DG2 OA support (rev3)
== Series Details == Series: Add DG2 OA support (rev3) URL : https://patchwork.freedesktop.org/series/107584/ State : warning == Summary == Error: dim checkpatch failed 7e3d54fda966 drm/i915/perf: Fix OA filtering logic for GuC mode cf4391110d50 drm/i915/perf: Add OAG and OAR formats for DG2 3b1ee9fc1bf9 drm/i915/perf: Fix noa wait predication for DG2 41fefad68a6d drm/i915/perf: Determine gen12 oa ctx offset at runtime -:38: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects? #38: FILE: drivers/gpu/drm/i915/i915_perf.c:1361: +#define __valid_oactxctrl_offset(x) ((x) && (x) != U32_MAX) total: 0 errors, 0 warnings, 1 checks, 234 lines checked a3f78042ac31 drm/i915/perf: Enable commands per clock reporting in OA a5a6c6b84c76 drm/i915/perf: Simply use stream->ctx 4f989fb92c02 drm/i915/perf: Move gt-specific data from i915->perf to gt->perf 2c50c8d01880 drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops 3af70ab98a20 drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers 0d2b0f1fca68 drm/i915/perf: Store a pointer to oa_format in oa_buffer 7418a83a2f3e drm/i915/perf: Add Wa_1508761755:dg2 fad73b7c1434 drm/i915/perf: Apply Wa_18013179988 fe1388485698 drm/i915/perf: Save/restore EU flex counters across reset 9decc23433d8 drm/i915/guc: Support OA when Wa_16011777198 is enabled 7556c283eabe drm/i915/perf: Enable OA for DG2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add HWMON support (rev7)
== Series Details ==
Series: drm/i915: Add HWMON support (rev7)
URL : https://patchwork.freedesktop.org/series/104278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12176 -> Patchwork_104278v7
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/index.html
Participating hosts (46 -> 44)
--
Missing(2): fi-bxt-dsi fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104278v7:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {bat-rpls-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12176/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_104278v7 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rc6_residency@rc6-fence:
- fi-icl-u2: NOTRUN -> [WARN][3] ([i915#2684]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-icl-u2/igt@i915_pm_rc6_reside...@rc6-fence.html
- fi-elk-e7500: NOTRUN -> [SKIP][4] ([fdo#109271]) +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-elk-e7500/igt@i915_pm_rc6_reside...@rc6-fence.html
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-pnv-d510/igt@i915_pm_rc6_reside...@rc6-fence.html
* igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- fi-ilk-650: NOTRUN -> [SKIP][6] ([fdo#109271]) +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-ilk-650/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
- fi-blb-e6850: NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-blb-e6850/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- fi-tgl-u2: NOTRUN -> [WARN][8] ([i915#2681]) +4 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-tgl-u2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
- fi-cfl-8109u: NOTRUN -> [WARN][9] ([i915#6405])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-cfl-8109u/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@i915_pm_rc6_residency@rc6-idle@vecs0:
- fi-hsw-g3258: NOTRUN -> [WARN][10] ([i915#1804])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-hsw-g3258/igt@i915_pm_rc6_residency@rc6-i...@vecs0.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12176/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][14] ([i915#2867]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12176/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
- {bat-adlm-1}: [DMESG-WARN][16] ([i915#2867]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12176/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][18] ([i915#5886]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12176/bat-dg2-9/igt@gem_ringf...@basic-all.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v7/bat-dg2-9/igt@gem_ringf...@basic-all.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1804]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add HWMON support (rev7)
== Series Details == Series: drm/i915: Add HWMON support (rev7) URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add HWMON support (rev7)
== Series Details == Series: drm/i915: Add HWMON support (rev7) URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim checkpatch failed 74f6e494d49e drm/i915/hwmon: Add HWMON infrastructure Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:87: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #87: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 191 lines checked 7be04adc6c27 drm/i915/hwmon: Add HWMON current voltage support -:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #27: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 104 lines checked 5d284b050cce drm/i915/hwmon: Power PL1 limit and TDP setting 4bfbd70ac2ff drm/i915/hwmon: Show device level energy usage 1d70ce5d0227 drm/i915/hwmon: Expose card reactive critical power 7b42f7992e87 drm/i915/hwmon: Expose power1_max_interval e4e7544946ac drm/i915/hwmon: Extend power/energy for XEHPSDV
[Intel-gfx] [PATCH v2 07/15] drm/i915/perf: Move gt-specific data from i915->perf to gt->perf
Make perf part of gt as the OAG buffer is specific to a gt. The refactor
eventually simplifies programming the right OA buffer and the right HW
registers when supporting multiple gts.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 75 +-
drivers/gpu/drm/i915/i915_perf_types.h | 39 +--
drivers/gpu/drm/i915/selftests/i915_perf.c | 16 +++--
5 files changed, 80 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f19c2de77ff6..9f653a347cad 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -20,6 +20,7 @@
#include "intel_gsc.h"
#include "i915_vma.h"
+#include "i915_perf_types.h"
#include "intel_engine_types.h"
#include "intel_gt_buffer_pool_types.h"
#include "intel_hwconfig.h"
@@ -286,6 +287,8 @@ struct intel_gt {
/* sysfs defaults per gt */
struct gt_defaults defaults;
struct kobject *sysfs_defaults;
+
+ struct i915_perf_gt perf;
};
struct intel_gt_definition {
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 66f21c735d54..6c6198a257ac 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -677,8 +677,8 @@ u32 intel_sseu_make_rpcs(struct intel_gt *gt,
* If i915/perf is active, we want a stable powergating configuration
* on the system. Use the configuration pinned by i915/perf.
*/
- if (i915->perf.exclusive_stream)
- req_sseu = >perf.sseu;
+ if (gt->perf.exclusive_stream)
+ req_sseu = >perf.sseu;
slices = hweight8(req_sseu->slice_mask);
subslices = hweight8(req_sseu->subslice_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2ec2da42a539..8b238268ca55 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1553,8 +1553,9 @@ free_noa_wait(struct i915_perf_stream *stream)
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
+ struct intel_gt *gt = stream->engine->gt;
- if (WARN_ON(stream != perf->exclusive_stream))
+ if (WARN_ON(stream != gt->perf.exclusive_stream))
return;
/*
@@ -1563,7 +1564,7 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
*
* See i915_oa_init_reg_state() and lrc_configure_all_contexts()
*/
- WRITE_ONCE(perf->exclusive_stream, NULL);
+ WRITE_ONCE(gt->perf.exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
free_oa_buffer(stream);
@@ -2556,10 +2557,11 @@ oa_configure_all_contexts(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct intel_engine_cs *engine;
+ struct intel_gt *gt = stream->engine->gt;
struct i915_gem_context *ctx, *cn;
int err;
- lockdep_assert_held(>perf->lock);
+ lockdep_assert_held(>perf.lock);
/*
* The OA register config is setup through the context image. This image
@@ -3080,6 +3082,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+ struct intel_gt *gt;
int format_size;
int ret;
@@ -3088,6 +3091,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
"OA engine not specified\n");
return -EINVAL;
}
+ gt = props->engine->gt;
/*
* If the sysfs metrics/ directory wasn't registered for some
@@ -3118,7 +3122,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
* counter reports and marshal to the appropriate client
* we currently only allow exclusive access
*/
- if (perf->exclusive_stream) {
+ if (gt->perf.exclusive_stream) {
drm_dbg(>perf->i915->drm,
"OA unit already in use\n");
return -EBUSY;
@@ -3198,8 +3202,8 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->ops = _oa_stream_ops;
- perf->sseu = props->sseu;
- WRITE_ONCE(perf->exclusive_stream, stream);
+ stream->engine->gt->perf.sseu = props->sseu;
+ WRITE_ONCE(gt->perf.exclusive_stream, stream);
ret = i915_perf_stream_enable_sync(stream);
if (ret) {
@@ -3221,7 +3225,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return 0;
err_enable:
- WRITE_ONCE(perf->exclusive_stream, NULL);
+
[Intel-gfx] [PATCH v2 03/15] drm/i915/perf: Fix noa wait predication for DG2
Predication for batch buffer commands changed in XEHPSDV.
MI_BATCH_BUFFER_START predicates based on MI_SET_PREDICATE_RESULT
register. The MI_SET_PREDICATE_RESULT register can only be modified
with MI_SET_PREDICATE command. When configured, the MI_SET_PREDICATE
command sets MI_SET_PREDICATE_RESULT based on bit 0 of
MI_PREDICATE_RESULT_2. Use this to configure predication in noa_wait.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
drivers/gpu/drm/i915/i915_perf.c| 24 +
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index fe1a0d5fd4b1..ee3efd06ee54 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -201,6 +201,7 @@
#define RING_CONTEXT_STATUS_PTR(base) _MMIO((base) + 0x3a0)
#define RING_CTX_TIMESTAMP(base) _MMIO((base) + 0x3a8) /* gen8+
*/
#define RING_PREDICATE_RESULT(base)_MMIO((base) + 0x3b8)
+#define MI_PREDICATE_RESULT_2_ENGINE(base) _MMIO((base) + 0x3bc)
#define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) *
4)
#define RING_FORCE_TO_NONPRIV_DENY REG_BIT(30)
#define RING_FORCE_TO_NONPRIV_ADDRESS_MASK REG_GENMASK(25, 2)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 41e9f620ee31..cd57b5836386 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -286,6 +286,7 @@ static u32 i915_perf_stream_paranoid = true;
#define OAREPORT_REASON_CTX_SWITCH (1<<3)
#define OAREPORT_REASON_CLK_RATIO (1<<5)
+#define HAS_MI_SET_PREDICATE(i915) (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
/* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
*
@@ -1762,6 +1763,9 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
DELTA_TARGET,
N_CS_GPR
};
+ i915_reg_t mi_predicate_result = HAS_MI_SET_PREDICATE(i915) ?
+ MI_PREDICATE_RESULT_2_ENGINE(base) :
+
MI_PREDICATE_RESULT_1(RENDER_RING_BASE);
bo = i915_gem_object_create_internal(i915, 4096);
if (IS_ERR(bo)) {
@@ -1799,7 +1803,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
stream, cs, true /* save */, CS_GPR(i),
INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
cs = save_restore_register(
- stream, cs, true /* save */,
MI_PREDICATE_RESULT_1(RENDER_RING_BASE),
+ stream, cs, true /* save */, mi_predicate_result,
INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
/* First timestamp snapshot location. */
@@ -1853,7 +1857,10 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
*/
*cs++ = MI_LOAD_REGISTER_REG | (3 - 2);
*cs++ = i915_mmio_reg_offset(CS_GPR(JUMP_PREDICATE));
- *cs++ = i915_mmio_reg_offset(MI_PREDICATE_RESULT_1(RENDER_RING_BASE));
+ *cs++ = i915_mmio_reg_offset(mi_predicate_result);
+
+ if (HAS_MI_SET_PREDICATE(i915))
+ *cs++ = MI_SET_PREDICATE | 1;
/* Restart from the beginning if we had timestamps roll over. */
*cs++ = (GRAPHICS_VER(i915) < 8 ?
@@ -1863,6 +1870,9 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
*cs++ = i915_ggtt_offset(vma) + (ts0 - batch) * 4;
*cs++ = 0;
+ if (HAS_MI_SET_PREDICATE(i915))
+ *cs++ = MI_SET_PREDICATE;
+
/*
* Now add the diff between to previous timestamps and add it to :
* (((1 * << 64) - 1) - delay_ns)
@@ -1890,7 +1900,10 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
*/
*cs++ = MI_LOAD_REGISTER_REG | (3 - 2);
*cs++ = i915_mmio_reg_offset(CS_GPR(JUMP_PREDICATE));
- *cs++ = i915_mmio_reg_offset(MI_PREDICATE_RESULT_1(RENDER_RING_BASE));
+ *cs++ = i915_mmio_reg_offset(mi_predicate_result);
+
+ if (HAS_MI_SET_PREDICATE(i915))
+ *cs++ = MI_SET_PREDICATE | 1;
/* Predicate the jump. */
*cs++ = (GRAPHICS_VER(i915) < 8 ?
@@ -1900,13 +1913,16 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
*cs++ = i915_ggtt_offset(vma) + (jump - batch) * 4;
*cs++ = 0;
+ if (HAS_MI_SET_PREDICATE(i915))
+ *cs++ = MI_SET_PREDICATE;
+
/* Restore registers. */
for (i = 0; i < N_CS_GPR; i++)
cs = save_restore_register(
stream, cs, false /* restore */, CS_GPR(i),
INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
cs = save_restore_register(
- stream, cs, false /* restore */,
MI_PREDICATE_RESULT_1(RENDER_RING_BASE),
+ stream, cs,
[Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Support OA when Wa_16011777198 is enabled
From: Vinay Belgaumkar
On DG2, a w/a resets RCS/CCS before it goes into RC6. This breaks OA
since OA does not expect engine resets during its use. Fix it by
disabling RC6.
v2: (Ashutosh)
- Bring back slpc_unset_param helper
- Update commit msg
- Use with_intel_runtime_pm helper for set/unset
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Umesh Nerlige Ramappa
---
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 9 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 66 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c | 29
4 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
index 4c840a2639dc..811add10c30d 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
@@ -128,6 +128,15 @@ enum slpc_media_ratio_mode {
SLPC_MEDIA_RATIO_MODE_FIXED_ONE_TO_TWO = 2,
};
+enum slpc_gucrc_mode {
+ SLPC_GUCRC_MODE_HW = 0,
+ SLPC_GUCRC_MODE_GUCRC_NO_RC6 = 1,
+ SLPC_GUCRC_MODE_GUCRC_STATIC_TIMEOUT = 2,
+ SLPC_GUCRC_MODE_GUCRC_DYNAMIC_HYSTERESIS = 3,
+
+ SLPC_GUCRC_MODE_MAX,
+};
+
enum slpc_event_id {
SLPC_EVENT_RESET = 0,
SLPC_EVENT_SHUTDOWN = 1,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index fdd895f73f9f..b3a4fb9e021f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -137,6 +137,17 @@ static int guc_action_slpc_set_param(struct intel_guc
*guc, u8 id, u32 value)
return ret > 0 ? -EPROTO : ret;
}
+static int guc_action_slpc_unset_param(struct intel_guc *guc, u8 id)
+{
+ u32 request[] = {
+ GUC_ACTION_HOST2GUC_PC_SLPC_REQUEST,
+ SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1),
+ id,
+ };
+
+ return intel_guc_send(guc, request, ARRAY_SIZE(request));
+}
+
static bool slpc_is_running(struct intel_guc_slpc *slpc)
{
return slpc_get_state(slpc) == SLPC_GLOBAL_STATE_RUNNING;
@@ -190,6 +201,15 @@ static int slpc_set_param(struct intel_guc_slpc *slpc, u8
id, u32 value)
return ret;
}
+static int slpc_unset_param(struct intel_guc_slpc *slpc, u8 id)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+
+ return guc_action_slpc_unset_param(guc, id);
+}
+
static int slpc_force_min_freq(struct intel_guc_slpc *slpc, u32 freq)
{
struct drm_i915_private *i915 = slpc_to_i915(slpc);
@@ -610,6 +630,52 @@ static void slpc_get_rp_values(struct intel_guc_slpc *slpc)
slpc->boost_freq = slpc->rp0_freq;
}
+/**
+ * intel_guc_slpc_override_gucrc_mode() - override GUCRC mode
+ * @slpc: pointer to intel_guc_slpc.
+ * @mode: new value of the mode.
+ *
+ * This function will override the GUCRC mode.
+ *
+ * Return: 0 on success, non-zero error code on failure.
+ */
+int intel_guc_slpc_override_gucrc_mode(struct intel_guc_slpc *slpc, u32 mode)
+{
+ int ret;
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+
+ if (mode >= SLPC_GUCRC_MODE_MAX)
+ return -EINVAL;
+
+ with_intel_runtime_pm(>runtime_pm, wakeref) {
+ ret = slpc_set_param(slpc, SLPC_PARAM_PWRGATE_RC_MODE, mode);
+ if (ret)
+ drm_err(>drm,
+ "Override gucrc mode %d failed %d\n",
+ mode, ret);
+ }
+
+ return ret;
+}
+
+int intel_guc_slpc_unset_gucrc_mode(struct intel_guc_slpc *slpc)
+{
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+ int ret = 0;
+
+ with_intel_runtime_pm(>runtime_pm, wakeref) {
+ ret = slpc_unset_param(slpc, SLPC_PARAM_PWRGATE_RC_MODE);
+ if (ret)
+ drm_err(>drm,
+ "Unsetting gucrc mode failed %d\n",
+ ret);
+ }
+
+ return ret;
+}
+
/*
* intel_guc_slpc_enable() - Start SLPC
* @slpc: pointer to intel_guc_slpc.
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
index 82a98f78f96c..ccf483730d9d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
@@ -42,5 +42,7 @@ int intel_guc_slpc_set_media_ratio_mode(struct intel_guc_slpc
*slpc, u32 val);
void intel_guc_pm_intrmsk_enable(struct intel_gt *gt);
void intel_guc_slpc_boost(struct intel_guc_slpc *slpc);
void intel_guc_slpc_dec_waiters(struct intel_guc_slpc *slpc);
+int intel_guc_slpc_unset_gucrc_mode(struct intel_guc_slpc *slpc);
+int intel_guc_slpc_override_gucrc_mode(struct intel_guc_slpc *slpc, u32 mode);
#endif
diff --git
[Intel-gfx] [PATCH v2 08/15] drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops
With multi-gt, user can access multiple OA buffers concurrently. Use
stream->lock instead of gt->perf.lock to serialize file operations.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 31 --
drivers/gpu/drm/i915/i915_perf_types.h | 5 +
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8b238268ca55..42a258578a5f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3221,6 +3221,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->poll_check_timer.function = oa_poll_check_timer_cb;
init_waitqueue_head(>poll_wq);
spin_lock_init(>oa_buffer.ptr_lock);
+ mutex_init(>lock);
return 0;
@@ -3284,7 +3285,6 @@ static ssize_t i915_perf_read(struct file *file,
loff_t *ppos)
{
struct i915_perf_stream *stream = file->private_data;
- struct intel_gt *gt = stream->engine->gt;
size_t offset = 0;
int ret;
@@ -3308,14 +3308,14 @@ static ssize_t i915_perf_read(struct file *file,
if (ret)
return ret;
- mutex_lock(>perf.lock);
+ mutex_lock(>lock);
ret = stream->ops->read(stream, buf, count, );
- mutex_unlock(>perf.lock);
+ mutex_unlock(>lock);
} while (!offset && !ret);
} else {
- mutex_lock(>perf.lock);
+ mutex_lock(>lock);
ret = stream->ops->read(stream, buf, count, );
- mutex_unlock(>perf.lock);
+ mutex_unlock(>lock);
}
/* We allow the poll checking to sometimes report false positive EPOLLIN
@@ -3362,9 +3362,6 @@ static enum hrtimer_restart oa_poll_check_timer_cb(struct
hrtimer *hrtimer)
* _perf_stream_ops->poll_wait to call poll_wait() with a wait queue that
* will be woken for new stream data.
*
- * Note: The >perf.lock mutex has been taken to serialize
- * with any non-file-operation driver hooks.
- *
* Returns: any poll events that are ready without sleeping
*/
static __poll_t i915_perf_poll_locked(struct i915_perf_stream *stream,
@@ -3403,12 +3400,11 @@ static __poll_t i915_perf_poll_locked(struct
i915_perf_stream *stream,
static __poll_t i915_perf_poll(struct file *file, poll_table *wait)
{
struct i915_perf_stream *stream = file->private_data;
- struct intel_gt *gt = stream->engine->gt;
__poll_t ret;
- mutex_lock(>perf.lock);
+ mutex_lock(>lock);
ret = i915_perf_poll_locked(stream, file, wait);
- mutex_unlock(>perf.lock);
+ mutex_unlock(>lock);
return ret;
}
@@ -3507,9 +3503,6 @@ static long i915_perf_config_locked(struct
i915_perf_stream *stream,
* @cmd: the ioctl request
* @arg: the ioctl data
*
- * Note: The >perf.lock mutex has been taken to serialize
- * with any non-file-operation driver hooks.
- *
* Returns: zero on success or a negative error code. Returns -EINVAL for
* an unknown ioctl request.
*/
@@ -3547,12 +3540,11 @@ static long i915_perf_ioctl(struct file *file,
unsigned long arg)
{
struct i915_perf_stream *stream = file->private_data;
- struct intel_gt *gt = stream->engine->gt;
long ret;
- mutex_lock(>perf.lock);
+ mutex_lock(>lock);
ret = i915_perf_ioctl_locked(stream, cmd, arg);
- mutex_unlock(>perf.lock);
+ mutex_unlock(>lock);
return ret;
}
@@ -3598,6 +3590,11 @@ static int i915_perf_release(struct inode *inode, struct
file *file)
struct i915_perf *perf = stream->perf;
struct intel_gt *gt = stream->engine->gt;
+ /*
+* Within this call, we know that the fd is being closed and we have no
+* other user of stream->lock. Use the perf lock to destroy the stream
+* here.
+*/
mutex_lock(>perf.lock);
i915_perf_destroy_locked(stream);
mutex_unlock(>perf.lock);
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index e888bfab478f..dc9bfd8086cf 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -146,6 +146,11 @@ struct i915_perf_stream {
*/
struct intel_engine_cs *engine;
+ /*
+* Lock associated with operations on stream
+*/
+ struct mutex lock;
+
/**
* @sample_flags: Flags representing the `DRM_I915_PERF_PROP_SAMPLE_*`
* properties given when opening a stream, representing the contents
--
2.25.1
[Intel-gfx] [PATCH v2 13/15] drm/i915/perf: Save/restore EU flex counters across reset
If a drm client is killed, then hw contexts used by the client are reset immediately. This reset clears the EU flex counter configuration. If an OA use case is running in parallel, it would start seeing zeroed eu counter values following the reset even if the drm client is restarted. Save/restore the EU flex counter config so that the EU counters can be monitored continuously across resets. Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Ashutosh Dixit --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c index 74cbe8eaf531..3e152219fcb2 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c @@ -375,6 +375,14 @@ static int guc_mmio_regset_init(struct temp_regset *regset, for (i = 0; i < GEN9_LNCFCMOCS_REG_COUNT; i++) ret |= GUC_MMIO_REG_ADD(gt, regset, GEN9_LNCFCMOCS(i), false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL0, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL1, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL2, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL3, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL4, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL5, false); + ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL6, false); + return ret ? -1 : 0; } -- 2.25.1
[Intel-gfx] [PATCH v2 01/15] drm/i915/perf: Fix OA filtering logic for GuC mode
With GuC mode of submission, GuC is in control of defining the context
id field that is part of the OA reports. To filter reports, UMD and KMD
must know what sw context id was chosen by GuC. There is not interface
between KMD and GuC to determine this, so read the upper-dword of
EXECLIST_STATUS to filter/squash OA reports for the specific context.
v2: Explain guc id stealing w.r.t OA use case
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c| 144
2 files changed, 127 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index a390f0813c8b..7111bae759f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -110,6 +110,8 @@ enum {
#define XEHP_SW_CTX_ID_WIDTH 16
#define XEHP_SW_COUNTER_SHIFT 58
#define XEHP_SW_COUNTER_WIDTH 6
+#define GEN12_GUC_SW_CTX_ID_SHIFT 39
+#define GEN12_GUC_SW_CTX_ID_WIDTH 16
static inline void lrc_runtime_start(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0defbb43ceea..315662329be3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1233,6 +1233,128 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
return stream->pinned_ctx;
}
+static int
+__store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32 ggtt_offset)
+{
+ u32 *cs, cmd;
+
+ cmd = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (GRAPHICS_VER(rq->engine->i915) >= 8)
+ cmd++;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = ggtt_offset;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int
+__read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+
+ err = __store_reg_to_mem(rq, reg, ggtt_offset);
+
+ i915_request_add(rq);
+ if (!err && i915_request_wait(rq, 0, HZ / 2) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ return err;
+}
+
+static int
+gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id)
+{
+ struct i915_vma *scratch;
+ u32 *val;
+ int err;
+
+ scratch =
__vm_create_scratch_for_read_pinned(>engine->gt->ggtt->vm, 4);
+ if (IS_ERR(scratch))
+ return PTR_ERR(scratch);
+
+ err = i915_vma_sync(scratch);
+ if (err)
+ goto err_scratch;
+
+ err = __read_reg(ce, RING_EXECLIST_STATUS_HI(ce->engine->mmio_base),
+i915_ggtt_offset(scratch));
+ if (err)
+ goto err_scratch;
+
+ val = i915_gem_object_pin_map_unlocked(scratch->obj, I915_MAP_WB);
+ if (IS_ERR(val)) {
+ err = PTR_ERR(val);
+ goto err_scratch;
+ }
+
+ *ctx_id = *val;
+ i915_gem_object_unpin_map(scratch->obj);
+
+err_scratch:
+ i915_vma_unpin_and_release(, 0);
+ return err;
+}
+
+/*
+ * For execlist mode of submission, pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts
+ * XXX_MAX_CONTEXT_HW_ID is used by idle context
+ *
+ * For GuC mode of submission read context id from the upper dword of the
+ * EXECLIST_STATUS register. Note that we read this value only once and expect
+ * that the value stays fixed for the entire OA use case. There are cases where
+ * GuC KMD implementation may deregister a context to reuse it's context id,
but
+ * we prevent that from happening to the OA context by pinning it.
+ */
+static int gen12_get_render_context_id(struct i915_perf_stream *stream)
+{
+ u32 ctx_id, mask;
+ int ret;
+
+ if (intel_engine_uses_guc(stream->engine)) {
+ ret = gen12_guc_sw_ctx_id(stream->pinned_ctx, _id);
+ if (ret)
+ return ret;
+
+ mask = ((1U << GEN12_GUC_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN12_GUC_SW_CTX_ID_SHIFT - 32);
+ } else if (GRAPHICS_VER_FULL(stream->engine->i915) >= IP_VER(12, 50)) {
+ ctx_id = (XEHP_MAX_CONTEXT_HW_ID - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << XEHP_SW_CTX_ID_WIDTH) - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+ } else {
+ ctx_id = (GEN12_MAX_CONTEXT_HW_ID - 1) <<
+(GEN11_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << GEN11_SW_CTX_ID_WIDTH) - 1) <<
+
[Intel-gfx] [PATCH v2 06/15] drm/i915/perf: Simply use stream->ctx
Earlier code used exclusive_stream to check for user passed context.
Simplify this by accessing stream->ctx.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 657dff8bf395..2ec2da42a539 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -777,7 +777,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* switches since it's not-uncommon for periodic samples to
* identify a switch before any 'context switch' report.
*/
- if (!stream->perf->exclusive_stream->ctx ||
+ if (!stream->ctx ||
stream->specific_ctx_id == ctx_id ||
stream->oa_buffer.last_ctx_id == stream->specific_ctx_id ||
reason & OAREPORT_REASON_CTX_SWITCH) {
@@ -786,7 +786,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* While filtering for a single context we avoid
* leaking the IDs of other contexts.
*/
- if (stream->perf->exclusive_stream->ctx &&
+ if (stream->ctx &&
stream->specific_ctx_id != ctx_id) {
report32[2] = INVALID_CTX_ID;
}
--
2.25.1
[Intel-gfx] [PATCH v2 02/15] drm/i915/perf: Add OAG and OAR formats for DG2
Add new OA formats for DG2. Some of the newer OA formats are not
multples of 64 bytes and are not powers of 2. For those formats, adjust
hw_tail accordingly when checking for new reports.
v2:
- Update commit title (Ashutosh)
- Coding style fixes (Lionel)
- 64 bit OA formats need UMD changes in GPUvis, drop for now and send in a
separate series with UMD changes
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin #1
Acked-by: Ashutosh Dixit #1
---
drivers/gpu/drm/i915/i915_perf.c | 7 +++
include/uapi/drm/i915_drm.h | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 315662329be3..41e9f620ee31 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -320,6 +320,8 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+ [I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
+ [I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -4517,6 +4519,11 @@ static void oa_init_supported_formats(struct i915_perf
*perf)
oa_format_add(perf, I915_OA_FORMAT_C4_B8);
break;
+ case INTEL_DG2:
+ oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8);
+ oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8);
+ break;
+
default:
MISSING_CASE(platform);
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 520ad2691a99..8b59590e06d4 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2650,6 +2650,10 @@ enum drm_i915_oa_format {
I915_OA_FORMAT_A12_B8_C8,
I915_OA_FORMAT_A32u40_A4u32_B8_C8,
+ /* DG2 */
+ I915_OAR_FORMAT_A32u40_A4u32_B8_C8,
+ I915_OA_FORMAT_A24u40_A14u32_B8_C8,
+
I915_OA_FORMAT_MAX /* non-ABI */
};
--
2.25.1
[Intel-gfx] [PATCH v2 10/15] drm/i915/perf: Store a pointer to oa_format in oa_buffer
DG2 introduces OA reports with 64 bit report header fields. Perf OA
would need more information about the OA format in order to process such
reports. Store all OA format info in oa_buffer instead of just the size
and format-id.
v2: Drop format_size variable (Ashutosh)
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 30 +++---
drivers/gpu/drm/i915/i915_perf_types.h | 3 +--
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e875d1722802..bd886ba4b927 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -465,7 +465,7 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream
*stream)
static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
{
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
unsigned long flags;
bool pollin;
u32 hw_tail;
@@ -602,7 +602,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
size_t *offset,
const u8 *report)
{
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
struct drm_i915_perf_record_header header;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
@@ -652,7 +652,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
size_t *offset)
{
struct intel_uncore *uncore = stream->uncore;
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
u8 *oa_buf_base = stream->oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
u32 mask = (OA_BUFFER_SIZE - 1);
@@ -946,7 +946,7 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
size_t *offset)
{
struct intel_uncore *uncore = stream->uncore;
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
u8 *oa_buf_base = stream->oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
u32 mask = (OA_BUFFER_SIZE - 1);
@@ -2494,7 +2494,7 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
{
int err;
struct intel_context *ce = stream->pinned_ctx;
- u32 format = stream->oa_buffer.format;
+ u32 format = stream->oa_buffer.format->format;
u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
@@ -2867,7 +2867,7 @@ static void gen7_oa_enable(struct i915_perf_stream
*stream)
u32 ctx_id = stream->specific_ctx_id;
bool periodic = stream->periodic;
u32 period_exponent = stream->period_exponent;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* Reset buf pointers so we don't forward reports from before now.
@@ -2893,7 +2893,7 @@ static void gen7_oa_enable(struct i915_perf_stream
*stream)
static void gen8_oa_enable(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* Reset buf pointers so we don't forward reports from before now.
@@ -2919,7 +2919,7 @@ static void gen8_oa_enable(struct i915_perf_stream
*stream)
static void gen12_oa_enable(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* If we don't want OA reports from the OA buffer, then we don't even
@@ -3100,7 +3100,6 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
struct intel_gt *gt;
- int format_size;
int ret;
if (!props->engine) {
@@ -3156,20 +3155,15 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->sample_size = sizeof(struct drm_i915_perf_record_header);
- format_size = perf->oa_formats[props->oa_format].size;
+ stream->oa_buffer.format = >oa_formats[props->oa_format];
+ if (drm_WARN_ON(>drm, stream->oa_buffer.format->size == 0))
+ return -EINVAL;
stream->sample_flags = props->sample_flags;
- stream->sample_size += format_size;
-
- stream->oa_buffer.format_size = format_size;
- if (drm_WARN_ON(>drm,
[Intel-gfx] [PATCH v2 09/15] drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers
User passes uabi engine class and instance to the perf OA interface. Use
gt corresponding to the engine to pin the buffers to the right ggtt.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 42a258578a5f..e875d1722802 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1742,6 +1742,7 @@ static void gen12_init_oa_buffer(struct i915_perf_stream
*stream)
static int alloc_oa_buffer(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
int ret;
@@ -1761,11 +1762,22 @@ static int alloc_oa_buffer(struct i915_perf_stream
*stream)
i915_gem_object_set_cache_coherency(bo, I915_CACHE_LLC);
/* PreHSW required 512K alignment, HSW requires 16M */
- vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto err_unref;
}
+
+ /*
+* PreHSW required 512K alignment.
+* HSW and onwards, align to requested size of OA buffer.
+*/
+ ret = i915_vma_pin(vma, 0, SZ_16M, PIN_GLOBAL | PIN_HIGH);
+ if (ret) {
+ drm_err(>i915->drm, "Failed to pin OA buffer %d\n", ret);
+ goto err_unref;
+ }
+
stream->oa_buffer.vma = vma;
stream->oa_buffer.vaddr =
@@ -1815,6 +1827,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
static int alloc_noa_wait(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
const u64 delay_ticks = 0x -
@@ -1855,12 +1868,16 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
* multiple OA config BOs will have a jump to this address and it
* needs to be fixed during the lifetime of the i915/perf stream.
*/
- vma = i915_gem_object_ggtt_pin_ww(bo, , NULL, 0, 0, PIN_HIGH);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto out_ww;
}
+ ret = i915_vma_pin_ww(vma, , 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto out_ww;
+
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
if (IS_ERR(batch)) {
ret = PTR_ERR(batch);
--
2.25.1
[Intel-gfx] [PATCH v2 12/15] drm/i915/perf: Apply Wa_18013179988
OA reports in the OA buffer contain an OA timestamp field that helps
user calculate delta between 2 OA reports. The calculation relies on the
CS timestamp frequency to convert the timestamp value to nanoseconds.
The CS timestamp frequency is a function of the CTC_SHIFT value in
RPM_CONFIG0.
In DG2, OA unit assumes that the CTC_SHIFT is 3, instead of using the
actual value from RPM_CONFIG0. At the user level, this results in an
error in calculating delta between 2 OA reports since the OA timestamp
is not shifted in the same manner as CS timestamp. Also the periodicity
of the reports is different from what the user configured because of
mismatch in the CS and OA frequencies.
The issue also affects MI_REPORT_PERF_COUNT command.
To resolve this, return actual OA timestamp frequency to the user in
i915_getparam_ioctl, so that user can calculate the right OA exponent as
well as interpret the reports correctly.
v2:
- Use REG_FIELD_GET (Ashutosh)
- Update commit msg
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_getparam.c | 3 +++
drivers/gpu/drm/i915/i915_perf.c | 30 ++--
drivers/gpu/drm/i915/i915_perf.h | 2 ++
include/uapi/drm/i915_drm.h | 6 ++
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 342c8ca6414e..3047e80e1163 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -175,6 +175,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+ case I915_PARAM_OA_TIMESTAMP_FREQUENCY:
+ value = i915_perf_oa_timestamp_frequency(i915);
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 15f3bc742126..432d18b6cc0d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3098,6 +3098,30 @@ get_sseu_config(struct intel_sseu *out_sseu,
return i915_gem_user_to_context_sseu(engine->gt, drm_sseu, out_sseu);
}
+/*
+ * OA timestamp frequency = CS timestamp frequency in most platforms. On some
+ * platforms OA unit ignores the CTC_SHIFT and the 2 timestamps differ. In such
+ * cases, return the adjusted CS timestamp frequency to the user.
+ */
+u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915)
+{
+ /* Wa_18013179988:dg2 */
+ if (IS_DG2(i915)) {
+ intel_wakeref_t wakeref;
+ u32 reg, shift;
+
+ with_intel_runtime_pm(to_gt(i915)->uncore->rpm, wakeref)
+ reg = intel_uncore_read(to_gt(i915)->uncore,
RPM_CONFIG0);
+
+ shift =
REG_FIELD_GET(GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK,
+ reg);
+
+ return to_gt(i915)->clock_frequency << (3 - shift);
+ }
+
+ return to_gt(i915)->clock_frequency;
+}
+
/**
* i915_oa_stream_init - validate combined props for OA stream and init
* @stream: An i915 perf stream
@@ -3819,8 +3843,10 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent)
{
- return intel_gt_clock_interval_to_ns(to_gt(perf->i915),
-2ULL << exponent);
+ u64 nom = (2ULL << exponent) * NSEC_PER_SEC;
+ u32 den = i915_perf_oa_timestamp_frequency(perf->i915);
+
+ return div_u64(nom + den - 1, den);
}
static __always_inline bool
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index 1d1329e5af3a..f96e09a4af04 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -57,4 +57,6 @@ static inline void i915_oa_config_put(struct i915_oa_config
*oa_config)
kref_put(_config->ref, i915_oa_config_release);
}
+u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915);
+
#endif /* __I915_PERF_H__ */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8b59590e06d4..3a714980b9f5 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -749,6 +749,12 @@ typedef struct drm_i915_irq_wait {
/* Query if the kernel supports the I915_USERPTR_PROBE flag. */
#define I915_PARAM_HAS_USERPTR_PROBE 56
+/*
+ * Frequency of the timestamps in OA reports. This used to be the same as the
CS
+ * timestamp frequency, but differs on some platforms.
+ */
+#define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
+
/* Must be kept compact -- no holes and well documented */
/**
--
2.25.1
[Intel-gfx] [PATCH v2 11/15] drm/i915/perf: Add Wa_1508761755:dg2
Disable Clock gating in EU when gathering the events so that EU events
are not lost.
v2: Fix checkpatch issues
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/i915_perf.c| 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..8bb1694035a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1131,6 +1131,7 @@
#define GEN12_DISABLE_EARLY_READ REG_BIT(14)
#define GEN12_ENABLE_LARGE_GRF_MODE REG_BIT(12)
#define GEN12_PUSH_CONST_DEREF_HOLD_DIS REG_BIT(8)
+#define GEN12_DISABLE_DOP_GATING REG_BIT(0)
#define RT_CTRL_MMIO(0xe530)
#define DIS_NULL_QUERY REG_BIT(10)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index bd886ba4b927..15f3bc742126 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2765,6 +2765,18 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
u32 sqcnt1;
int ret;
+ /*
+* Wa_1508761755:xehpsdv, dg2
+* EU NOA signals behave incorrectly if EU clock gating is enabled.
+* Disable thread stall DOP gating and EU DOP gating.
+*/
+ if (IS_XEHPSDV(i915) || IS_DG2(i915)) {
+ intel_uncore_write(uncore, GEN8_ROW_CHICKEN,
+
_MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE));
+ intel_uncore_write(uncore, GEN7_ROW_CHICKEN2,
+
_MASKED_BIT_ENABLE(GEN12_DISABLE_DOP_GATING));
+ }
+
intel_uncore_write(uncore, GEN12_OAG_OA_DEBUG,
/* Disable clk ratio reports, like previous Gens. */
_MASKED_BIT_ENABLE(GEN12_OAG_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS |
@@ -2843,6 +2855,17 @@ static void gen12_disable_metric_set(struct
i915_perf_stream *stream)
struct drm_i915_private *i915 = stream->perf->i915;
u32 sqcnt1;
+ /*
+* Wa_1508761755:xehpsdv, dg2
+* Enable thread stall DOP gating and EU DOP gating.
+*/
+ if (IS_XEHPSDV(i915) || IS_DG2(i915)) {
+ intel_uncore_write(uncore, GEN8_ROW_CHICKEN,
+
_MASKED_BIT_DISABLE(STALL_DOP_GATING_DISABLE));
+ intel_uncore_write(uncore, GEN7_ROW_CHICKEN2,
+
_MASKED_BIT_DISABLE(GEN12_DISABLE_DOP_GATING));
+ }
+
/* Reset all contexts' slices/subslices configurations. */
gen12_configure_all_contexts(stream, NULL, NULL);
--
2.25.1
[Intel-gfx] [PATCH v2 05/15] drm/i915/perf: Enable commands per clock reporting in OA
XEHPSDV and DG2 provide a way to configure bytes per clock vs commands
per clock reporting. Enable bytes per clock setting on enabling OA.
v2:
- Fix commit msg (Ashutosh)
- Fix checkpatch issues
Signed-off-by: Umesh Nerlige Ramappa
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 20
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 4
drivers/gpu/drm/i915/intel_device_info.h | 1 +
5 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..ccd54ff54002 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -902,6 +902,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_RUNTIME_PM(dev_priv) (INTEL_INFO(dev_priv)->has_runtime_pm)
#define HAS_64BIT_RELOC(dev_priv) (INTEL_INFO(dev_priv)->has_64bit_reloc)
+#define HAS_OA_BPC_REPORTING(dev_priv) \
+ (INTEL_INFO(dev_priv)->has_oa_bpc_reporting)
+
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
* device local memory access.
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..6b25e4cb6221 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1022,6 +1022,7 @@ static const struct intel_device_info adl_p_info = {
.has_logical_ring_contexts = 1, \
.has_logical_ring_elsq = 1, \
.has_mslice_steering = 1, \
+ .has_oa_bpc_reporting = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
.has_rps = 1, \
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index fb705f24705b..657dff8bf395 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2738,10 +2738,12 @@ static int
gen12_enable_metric_set(struct i915_perf_stream *stream,
struct i915_active *active)
{
+ struct drm_i915_private *i915 = stream->perf->i915;
struct intel_uncore *uncore = stream->uncore;
struct i915_oa_config *oa_config = stream->oa_config;
bool periodic = stream->periodic;
u32 period_exponent = stream->period_exponent;
+ u32 sqcnt1;
int ret;
intel_uncore_write(uncore, GEN12_OAG_OA_DEBUG,
@@ -2760,6 +2762,16 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
(period_exponent <<
GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
: 0);
+ /*
+* Initialize Super Queue Internal Cnt Register
+* Set PMON Enable in order to collect valid metrics.
+* Enable commands per clock reporting in OA for XEHPSDV onward.
+*/
+ sqcnt1 = GEN12_SQCNT1_PMON_ENABLE |
+(HAS_OA_BPC_REPORTING(i915) ? GEN12_SQCNT1_OABPC : 0);
+
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, 0, sqcnt1);
+
/*
* Update all contexts prior writing the mux configurations as we need
* to make sure all slices/subslices are ON before writing to NOA
@@ -2809,6 +2821,8 @@ static void gen11_disable_metric_set(struct
i915_perf_stream *stream)
static void gen12_disable_metric_set(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
+ struct drm_i915_private *i915 = stream->perf->i915;
+ u32 sqcnt1;
/* Reset all contexts' slices/subslices configurations. */
gen12_configure_all_contexts(stream, NULL, NULL);
@@ -2819,6 +2833,12 @@ static void gen12_disable_metric_set(struct
i915_perf_stream *stream)
/* Make sure we disable noa to save power. */
intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
+
+ sqcnt1 = GEN12_SQCNT1_PMON_ENABLE |
+(HAS_OA_BPC_REPORTING(i915) ? GEN12_SQCNT1_OABPC : 0);
+
+ /* Reset PMON Enable to save power. */
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, sqcnt1, 0);
}
static void gen7_oa_enable(struct i915_perf_stream *stream)
diff --git a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
index 0ef3562ff4aa..381d94101610 100644
--- a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
+++ b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
@@ -134,4 +134,8 @@
#define GDT_CHICKEN_BITS_MMIO(0x9840)
#define GT_NOA_ENABLE0x0080
+#define GEN12_SQCNT1 _MMIO(0x8718)
+#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
+#define GEN12_SQCNT1_OABPC REG_BIT(29)
+
#endif /* __INTEL_PERF_OA_REGS__ */
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 09b18910d3ab..1f7a842cd408 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -164,6 +164,7 @@ enum intel_ppgtt_type {
[Intel-gfx] [PATCH v2 15/15] drm/i915/perf: Enable OA for DG2
OA was disabled for DG2 as support was missing. Enable it back now.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 80016f860406..b62508e662a3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4778,12 +4778,6 @@ void i915_perf_init(struct drm_i915_private *i915)
{
struct i915_perf *perf = >perf;
- /* XXX const struct i915_perf_ops! */
-
- /* i915_perf is not enabled for DG2 yet */
- if (IS_DG2(i915))
- return;
-
perf->oa_formats = oa_formats;
if (IS_HASWELL(i915)) {
perf->ops.is_valid_b_counter_reg = gen7_is_valid_b_counter_addr;
--
2.25.1
[Intel-gfx] [PATCH v2 04/15] drm/i915/perf: Determine gen12 oa ctx offset at runtime
Some SKUs of same gen12 platform may have different oactxctrl
offsets. For gen12, determine oactxctrl offsets at runtime.
v2: (Lionel)
- Move MI definitions to intel_gpu_commands.h
- Ensure __find_reg_in_lri does read past context image size
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 4 +
drivers/gpu/drm/i915/i915_perf.c | 146 +++
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 2 +-
3 files changed, 121 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d4e9702d3c8e..f50ea92910d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -187,6 +187,10 @@
#define MI_BATCH_RESOURCE_STREAMER REG_BIT(10)
#define MI_BATCH_PREDICATE REG_BIT(15) /* HSW+ on RCS only*/
+#define MI_OPCODE(x) (((x) >> 23) & 0x3f)
+#define IS_MI_LRI_CMD(x) (MI_OPCODE(x) == MI_OPCODE(MI_INSTR(0x22, 0)))
+#define MI_LRI_LEN(x) (((x) & 0xff) + 1)
+
/*
* 3D instructions used by the kernel
*/
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index cd57b5836386..fb705f24705b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1358,6 +1358,64 @@ static int gen12_get_render_context_id(struct
i915_perf_stream *stream)
return 0;
}
+#define __valid_oactxctrl_offset(x) ((x) && (x) != U32_MAX)
+static bool __find_reg_in_lri(u32 *state, u32 reg, u32 *offset, u32 end)
+{
+ u32 idx = *offset;
+ u32 len = min(MI_LRI_LEN(state[idx]) + idx, end);
+
+ idx++;
+ for (; idx < len; idx += 2)
+ if (state[idx] == reg)
+ break;
+
+ *offset = idx;
+ return state[idx] == reg;
+}
+
+static u32 __context_image_offset(struct intel_context *ce, u32 reg)
+{
+ u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
+ u32 *state = ce->lrc_reg_state;
+
+ for (offset = 0; offset < len; ) {
+ if (IS_MI_LRI_CMD(state[offset])) {
+ if (__find_reg_in_lri(state, reg, , len))
+ break;
+ } else {
+ offset++;
+ }
+ }
+
+ return offset < len ? offset : U32_MAX;
+}
+
+static int __set_oa_ctx_ctrl_offset(struct intel_context *ce)
+{
+ i915_reg_t reg = GEN12_OACTXCONTROL(ce->engine->mmio_base);
+ struct i915_perf *perf = >engine->i915->perf;
+ u32 saved_offset = perf->ctx_oactxctrl_offset;
+ u32 offset;
+
+ /* Do this only once. Failure is stored as offset of U32_MAX */
+ if (saved_offset)
+ return 0;
+
+ offset = __context_image_offset(ce, i915_mmio_reg_offset(reg));
+ perf->ctx_oactxctrl_offset = offset;
+
+ drm_dbg(>engine->i915->drm,
+ "%s oa ctx control at 0x%08x dword offset\n",
+ ce->engine->name, offset);
+
+ return __valid_oactxctrl_offset(offset) ? 0 : -ENODEV;
+}
+
+static bool engine_supports_mi_query(struct intel_engine_cs *engine)
+{
+ return engine->class == RENDER_CLASS;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1377,6 +1435,17 @@ static int oa_get_render_ctx_id(struct i915_perf_stream
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
+ if (engine_supports_mi_query(stream->engine)) {
+ ret = __set_oa_ctx_ctrl_offset(ce);
+ if (ret && !(stream->sample_flags & SAMPLE_OA_REPORT)) {
+ intel_context_unpin(ce);
+ drm_err(>perf->i915->drm,
+ "Enabling perf query failed for %s\n",
+ stream->engine->name);
+ return ret;
+ }
+ }
+
switch (GRAPHICS_VER(ce->engine->i915)) {
case 7: {
/*
@@ -2408,10 +2477,11 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
int err;
struct intel_context *ce = stream->pinned_ctx;
u32 format = stream->oa_buffer.format;
+ u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
GEN8_OACTXCONTROL,
- stream->perf->ctx_oactxctrl_offset + 1,
+ offset + 1,
active ? GEN8_OA_COUNTER_RESUME : 0,
},
};
@@ -2436,15 +2506,18 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
},
};
- /* Modify the context image of pinned context with regs_context*/
- err = intel_context_lock_pinned(ce);
- if (err)
- return err;
+ /* Modify the context image of pinned context with
[Intel-gfx] [PATCH v2 00/15] Add DG2 OA support
Add OA format support for DG2 and various fixes for DG2. This series has 2 uapi changes listed below: 1) drm/i915/perf: Add OAG and OAR formats for DG2 DG2 has new OA formats defined that can be selected by the user. The UMD changes that are consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504456/?series=107633=5 2) drm/i915/perf: Apply Wa_18013179988 DG2 has a bug where the OA timestamp does not tick at the CS timestamp frequency. Instead it ticks at a multiple that is determined from the CTC_SHIFT value in RPM_CONFIG. Since the timestamp is used by UMD to make sense of all the counters in the report, expose the OA timestamp frequency to the user. The interface is generic and applies to all platforms. On platforms where the bug is not present, this returns the CS timestamp frequency. UMD specific changes consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504464/?series=107633=5 v2: - Add review comments - Update uapi changes in cover letter - Drop patches for non-production platforms drm/i915/perf: Use helpers to process reports w.r.t. OA buffer size drm/i915/perf: Add Wa_16010703925:dg2 - Drop 64-bit OA format changes for now drm/i915/perf: Parse 64bit report header formats correctly drm/i915/perf: Add Wa_1608133521:dg2 Test-with: 20220823183036.5270-1-umesh.nerlige.rama...@intel.com Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (14): drm/i915/perf: Fix OA filtering logic for GuC mode drm/i915/perf: Add OAG and OAR formats for DG2 drm/i915/perf: Fix noa wait predication for DG2 drm/i915/perf: Determine gen12 oa ctx offset at runtime drm/i915/perf: Enable commands per clock reporting in OA drm/i915/perf: Simply use stream->ctx drm/i915/perf: Move gt-specific data from i915->perf to gt->perf drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers drm/i915/perf: Store a pointer to oa_format in oa_buffer drm/i915/perf: Add Wa_1508761755:dg2 drm/i915/perf: Apply Wa_18013179988 drm/i915/perf: Save/restore EU flex counters across reset drm/i915/perf: Enable OA for DG2 Vinay Belgaumkar (1): drm/i915/guc: Support OA when Wa_16011777198 is enabled drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 4 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_lrc.h | 2 + drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 9 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 8 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 66 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 564 ++ drivers/gpu/drm/i915/i915_perf.h | 2 + drivers/gpu/drm/i915/i915_perf_oa_regs.h | 6 +- drivers/gpu/drm/i915/i915_perf_types.h| 47 +- drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_perf.c| 16 +- include/uapi/drm/i915_drm.h | 10 + 20 files changed, 606 insertions(+), 147 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
v4:
- Fixed review comments (Anshuman)
- In hwm_power1_max_interval_store() get PKG_MAX_WIN from
pkg_power_sku when it is valid (Ashutosh)
- KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 120 +-
drivers/gpu/drm/i915/intel_mchbar_regs.h | 7 +
3 files changed, 135 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index f9d6d3b08bba..19b9fe3ef237 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: February 2023
KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index f743ac5c59c4..b95f54d274be 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
+ * - time - milliseconds
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
+#define SF_TIME1000
struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -161,6 +164,120 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ if (i915_mmio_reg_valid(hwmon->rg.pkg_power_sku))
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read64(ddat->uncore,
hwmon->rg.pkg_power_sku);
+ else
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME,
[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 19b9fe3ef237..dbd16b0f56d0 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: February 2023
KernelVersion: 6.2
Contact: dri-de...@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index c7639ae79a8f..2d06610cbec9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1589,6 +1589,11 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
/*
* Standalone Media's non-engine GT registers are located at their regular GT
* offsets plus 0x38. This extra offset is stored inside the intel_uncore
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b95f54d274be..0c569bbfbeaf 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
mutex_lock(>hwmon_lock);
@@ -286,6 +293,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -415,7 +427,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -550,6 +565,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
+ default:
+
[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7525db243d74..f9d6d3b08bba 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: February 2023
KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 60da956fae0e..f743ac5c59c4 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, ) ||
+ !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
default:
[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2: Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 16e697b1db3d..7525db243d74 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 5d2e68217e8c..60da956fae0e 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_ENERGY 100
struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = >ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(>hwmon_lock);
+
+ return 0;
+}
+
static const struct
[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6: Fix review comments (Ashutosh)
v7:
- Define PCU_PACKAGE_POWER_SKU for DG1,DG2 and move
PKG_PKG_TDP to intel_mchbar_regs.h (Anshuman)
- KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/intel_mchbar_regs.h | 12 ++
3 files changed, 188 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cd9554c1a4f8..16e697b1db3d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7b6de7b9c8b1..5d2e68217e8c 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(>hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* 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;
+
[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm_ prefix for static functions (Ashutosh)
v5: Added unit of voltage as millivolts (Ashutosh)
v6: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Guenter Roeck
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
3 files changed, 63 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..cd9554c1a4f8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 755a2c101269..c7639ae79a8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1516,6 +1516,9 @@
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2847ca4e1a77..7b6de7b9c8b1 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage - millivolts
+ */
+#define SF_VOLTAGE 1000
struct hwm_reg {
+ i915_reg_t gt_perf_status;
};
struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
};
static const struct hwmon_channel_info *hwm_info[] = {
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_input:
+ return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ?
0444 : 0;
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->uncore,
hwmon->rg.gt_perf_status);
+ /* HW register value in units of 2.5 millivolt */
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static umode_t
hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
static void
hwm_get_preregistration_info(struct drm_i915_private *i915)
{
+ struct i915_hwmon *hwmon = i915->hwmon;
+
+ if (IS_DG1(i915) || IS_DG2(i915))
+ hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+ else
+ hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.25.1
[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
v6: s/kzalloc/devm_kzalloc/ (Andi)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 131 +
drivers/gpu/drm/i915/i915_hwmon.h | 20 +
5 files changed, 161 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
# graphics system controller (GSC) support
i915-y += gt/intel_gsc.o
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 9d1fc2477f80..ae0414037625 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -763,6 +764,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -795,6 +798,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
+ i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..3197aa9d35d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -350,6 +350,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..2847ca4e1a77
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = _ops,
+ .info = hwm_info,
+};
+
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct
[Intel-gfx] [PATCH 0/7] drm/i915: Add HWMON support
This series adds the HWMON support for DGFX Test-with: 20220919144408.251981-1-riana.ta...@intel.com v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) v6: - Fixed review comments (Ashutosh) - Updated date and kernel version in documentation v7: - Fixed review comments (Anshuman) - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko) Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval 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 Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 762 ++ drivers/gpu/drm/i915/i915_hwmon.h | 21 + drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 21 + 9 files changed, 903 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix a potential UAF at device unload
== Series Details == Series: series starting with [1/2] drm/i915: Fix a potential UAF at device unload URL : https://patchwork.freedesktop.org/series/108944/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108944v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108944v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108944v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108944v1_full: ### IGT changes ### Possible regressions * igt@gem_eio@hibernate: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-snb7/igt@gem_...@hibernate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-snb2/igt@gem_...@hibernate.html Known issues Here are the changes found in Patchwork_108944v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_buddy@all: - shard-iclb: NOTRUN -> [SKIP][3] ([i915#6433]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@drm_bu...@all.html * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify-ccs: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl6/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#4270]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#768]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl2/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl2/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110725] / [fdo#111614]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109278]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for Add PXP firmware respose on ARB failure
== Series Details == Series: Add PXP firmware respose on ARB failure URL : https://patchwork.freedesktop.org/series/108935/ State : success == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108935v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108935v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [FAIL][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22]) ([i915#5032]) -> ([PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl5/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [44]:
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, September 20, 2022 2:59 PM > > To: Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > ; Vivi, Rodrigo > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > To: Srivatsa, Anusha > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > ; Vivi, Rodrigo > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > This is a prep series for the actual cdclk refactoring that will > > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > > holds the following: > > > > > - cdclk action (squash, crawl or modeset) > > > > > - cdclk frequency > > > > > which gets populated in atomic check. Driver uses the populated > > > > > values during atomic commit to do the suitable sequence of actions > > > > > like programming squash ctl registers in case of squashing or PLL > > > > > sequence incase of modeset and so on. > > > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > > in the atomic commit phase will be sent shortly. > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > quickly. This to me seems like the most straightforward way to do what > > we need: > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > > approach should produce sane values. > > > Ville, > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > > purpose? > > > > You either > > - start at old, crawl to mid, then squash to new > > - start at old, squash to mid, then crawl to new > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to > understand the code but the mid cdclk config logic works. @Ville Syrjälä does > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your > new cdclk_crawl_and_squash in atomic check make sense? I don't think we should need any real logic at that point. If we can squash and crawl then I think we can always do the cdclk change w/o a modeset, at least with what we currently have defined in the cdclk tables. -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for Delay disabling GuC scheduling of an idle context
== Series Details == Series: Delay disabling GuC scheduling of an idle context URL : https://patchwork.freedesktop.org/series/108931/ State : success == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108931v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108931v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_buddy@all: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#6433]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@drm_bu...@all.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify-ccs: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-iclb: NOTRUN -> [SKIP][9] ([i915#4270]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#768]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gen9_exec_parse@allowed-single: - shard-apl: NOTRUN -> [DMESG-WARN][11] ([i915#5566] / [i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@gen9_exec_pa...@allowed-single.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl2/igt@i915_susp...@sysfs-reader.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#110725] / [fdo#111614]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109278]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs.html * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +5 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_color_chamelium@ctm-0-50: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl2/igt@kms_color_chamel...@ctm-0-50.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4103]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#2346]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html * igt@kms_flip@2x-nonexisting-fb: - shard-apl: NOTRUN -> [SKIP][21]
Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.
Rafael, could you please add your thoughts here?
On Thu, 2022-09-22 at 12:40 +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Gupta, Anshuman
> > Sent: Thursday, September 22, 2022 4:40 PM
> > To: Vivi, Rodrigo ; Tvrtko Ursulin
> >
> > Cc: Nikula, Jani ; intel-
> > g...@lists.freedesktop.org; Daniel
> > J Blueman ; Wysocki, Rafael J
> > ; sta...@vger.kernel.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not
> > actively
> > managing a known PCI device.
> >
> >
> >
> > On 9/22/2022 3:13 PM, Rodrigo Vivi wrote:
> > > On Thu, Sep 22, 2022 at 08:56:00AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 21/09/2022 18:39, Rodrigo Vivi wrote:
> > > > > The force_probe protection actively avoids the probe of i915
> > > > > to
> > > > > manage a device that is currently under development. It is a
> > > > > nice
> > > > > protection for future users when getting a new platform but
> > > > > using
> > > > > some older kernel.
> > > > >
> > > > > However, when we avoid the probe we don't take back the
> > > > > registration
> > > > > of the device. We cannot give up the registration anyway
> > > > > since we
> > > > > can have multiple devices present. For instance an integrated
> > > > > and a
> > > > > discrete one.
> > > > >
> > > > > When this scenario occurs, the user will not be able to
> > > > > change any
> > > > > of the runtime pm configuration of the unmanaged device. So,
> > > > > it will
> > > > > be blocked in D0 state wasting power. This is specially bad
> > > > > in the
> > > > > case where we have a discrete platform attached, but the user
> > > > > is
> > > > > able to fully use the integrated one for everything else.
> > > > >
> > > > > So, let's put the protected and unmanaged device in D3. So we
> > > > > can
> > > > > save some power.
> > > > >
> > > > > Reported-by: Daniel J Blueman
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: Daniel J Blueman
> > > > > Cc: Tvrtko Ursulin
> > > > > Cc: Anshuman Gupta
> > > > > Signed-off-by: Rodrigo Vivi
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_pci.c | 8
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > > > b/drivers/gpu/drm/i915/i915_pci.c index
> > > > > 77e7df21f539..fc3e7c69af2a
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > > @@ -25,6 +25,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include "gt/intel_gt_regs.h"
> > > > > #include "gt/intel_sa_media.h"
> > > > > @@ -1304,6 +1305,7 @@ static int i915_pci_probe(struct
> > > > > pci_dev *pdev,
> > const struct pci_device_id *ent)
> > > > > {
> > > > > struct intel_device_info *intel_info =
> > > > > (struct intel_device_info *) ent-
> > > > > >driver_data;
> > > > > + struct device *kdev = >dev;
> > > > > int err;
> > > > > if (intel_info->require_force_probe && @@ -1314,6
> > > > > +1316,12 @@
> > > > > static int i915_pci_probe(struct pci_dev *pdev, const struct
> > > > > pci_device_id
> > *ent)
> > > > > "module parameter or
> > CONFIG_DRM_I915_FORCE_PROBE=%04x configuration option,\n"
> > > > > "or (recommended) check for kernel
> > > > > updates.\n",
> > > > > pdev->device, pdev->device, pdev-
> > > > > >device);
> > > > > +
> > > > > + /* Let's not waste power if we are not
> > > > > managing the device */
> > > > > + pm_runtime_use_autosuspend(kdev);
> > > > > + pm_runtime_allow(kdev);
> > > > > + pm_runtime_put_autosuspend(kdev);
> > AFAIK we don't need to enable autosuspend here,
> > pm_runtime_put_autosuspend() will cause a NULL pointer de-reference
> > as it will
> > immediately call the intel_runtime_suspend()(because we haven't
> > called the
> > pm_runtime_mark_last_busy) without initializing i915.
I don't see any null pointer dereference here.
The problem is exactly that we do the initialization and the we give up
on the
device and end up blocking the runtime pm in some state that we cannot
change.
> >
> > Having said that we only need below, in order to let pci core keep
> > the pci dev in
> > D3.
> >
> > pm_runtime_put_noidle()
as for this one here I get:
[ 9036.357078] i915 :03:00.0: Runtime PM usage count underflow!
>
> Hi Rodrigo ,
> It seems playing with these runtime hooks, will only enable the
> "runtime suspend"
> but actual state in "PMCSR" pci config is D0 despite device is
> runtime suspended, when there is no driver.
> Example:
> root@DUT2135-DG2MRB:/home/gta# cat
> /sys/bus/pci/devices/\:03\:00.0/power/runtime_status
> suspended
> root@DUT2135-DG2MRB:/home/gta# setpci -s 03:00.0 0xd4.l
> 0008
> (Bits 00:01 are the power state in PMCSR(offset = 4) config register
> from PM Cap offset at
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve debug print in vm_fault_ttm (rev3)
== Series Details ==
Series: drm/i915: Improve debug print in vm_fault_ttm (rev3)
URL : https://patchwork.freedesktop.org/series/108887/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108887v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/index.html
Participating hosts (46 -> 44)
--
Missing(2): fi-hsw-4770 fi-skl-6700k2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108887v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}: [INCOMPLETE][1] ([i915#2411]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108887v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][5] -> [FAIL][6] ([i915#6298])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][7] ([i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][8] ([i915#6816]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6816]: https://gitlab.freedesktop.org/drm/intel/issues/6816
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108887v3
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108887v3: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
824c9b8b86b0 drm/i915: Improve debug print in vm_fault_ttm
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/index.html
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: introduce Wa_22015475538
On Wed, Sep 21, 2022 at 12:19:05AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dg2: introduce Wa_22015475538
> URL : https://patchwork.freedesktop.org/series/108795/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12161_full -> Patchwork_108795v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_108795v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_108795v1_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (9 -> 11)
> --
>
> Additional (2): shard-rkl shard-tglu
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_108795v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_pm_rpm@reg-read-ioctl:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-tglb7/igt@i915_pm_...@reg-read-ioctl.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglb8/igt@i915_pm_...@reg-read-ioctl.html
Random incomplete with no errors reported. Not related to this patch.
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@kms_color@ctm-0-75@pipe-a-hdmi-a-1:
> - {shard-tglu}: NOTRUN -> [FAIL][3] +7 similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglu-6/igt@kms_color@ctm-0...@pipe-a-hdmi-a-1.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_12161_full and
> Patchwork_108795v1_full:
>
> ### New IGT tests (2) ###
>
> * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-1:
> - Statuses : 1 pass(s)
> - Exec time: [0.05] s
>
> * igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-1:
> - Statuses : 1 pass(s)
> - Exec time: [0.15] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_108795v1_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-glk: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
> [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
> [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
> [PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], [PASS][25],
> [PASS][26], [PASS][27], [PASS][28]) ([i915#4392]) -> ([PASS][29], [PASS][30],
> [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
> [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
> [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
> [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Don't use port enum as register offset (rev3)
== Series Details ==
Series: drm/i915/display: Don't use port enum as register offset (rev3)
URL : https://patchwork.freedesktop.org/series/108833/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108833v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108833v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_lease@lease_unleased_connector@pipe-a-hdmi-a-1:
- {shard-tglu}: [PASS][1] -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglu-4/igt@kms_lease@lease_unleased_connec...@pipe-a-hdmi-a-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglu-2/igt@kms_lease@lease_unleased_connec...@pipe-a-hdmi-a-1.html
* igt@kms_lease@lease_unleased_connector@pipe-d-hdmi-a-1:
- {shard-tglu}: [PASS][3] -> [FAIL][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglu-4/igt@kms_lease@lease_unleased_connec...@pipe-d-hdmi-a-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglu-2/igt@kms_lease@lease_unleased_connec...@pipe-d-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_108833v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_buddy@all:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#6433])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@drm_bu...@all.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_nop@basic-series:
- shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk1/igt@gem_exec_...@basic-series.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk3/igt@gem_exec_...@basic-series.html
* igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-apl8/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html
* igt@gem_pxp@reject-modify-context-protection-off-1:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_...@reject-modify-context-protection-off-1.html
* igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#768])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_render_c...@linear-to-vebox-y-tiled.html
* igt@gem_userptr_blits@access-control:
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271]) +4 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk3/igt@gem_userptr_bl...@access-control.html
* igt@kms_big_fb@y-tiled-8bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#110725] / [fdo#111614])
[21]:
Re: [Intel-gfx] [PATCH] drm/i915/dg2: introduce Wa_22015475538
On Tue, Sep 20, 2022 at 01:43:59PM -0700, Matt Atwood wrote:
> Wa_22015475538 applies to all DG2 (and ATSM) skus. The workaround
> implementation is identical to Wa_16011620976. LSC_CHICKEN_BIT_0_UDW is
> a general render register instead of rcs so adding this move to the
> proper wa init function.
>
> bspec:54077
>
> Signed-off-by: Matt Atwood
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 6d2003d598e6..c16e9e3f0d6c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2108,9 +2108,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
> /* Wa_14013392000:dg2_g11 */
> wa_masked_en(wal, GEN7_ROW_CHICKEN2,
> GEN12_ENABLE_LARGE_GRF_MODE);
> -
> - /* Wa_16011620976:dg2_g11 */
> - wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
> }
>
> if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
> @@ -2780,6 +2777,14 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> wa_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> }
> +
> + if (IS_DG2(i915)) {
> + /*
> + * Wa_16011620976:dg2_g11
> + * Wa_22015475538:dg2
> + */
> + wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
> + }
> }
>
> static void
> --
> 2.37.3
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH v6 2/3] drm/i915: Parse and set stepping for platforms with GMD
On Thu, Sep 15, 2022 at 06:46:47PM -0700, Radhakrishna Sripada wrote:
From: José Roberto de Souza
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to STEP_A0, 1 to _A1, 2 to _A2, 3 to _A3, 4 to STEP_B0...
Future platforms might break this formulae and may require a table
mapping to decode GMD step compatible with the convention.
v2:
- Pass the updated ip version structure
v3:
- Skip using GMD to step table(MattR)
Cc: Balasubramani Vivekanandan
Cc: Matt Roper
Signed-off-by: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_step.c | 25 +
drivers/gpu/drm/i915/intel_step.h | 24 +++-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_step.c
b/drivers/gpu/drm/i915/intel_step.c
index 42b3133d8387..91e7c51991b0 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -135,6 +135,19 @@ static const struct intel_step_info adlp_n_revids[] = {
[0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
};
+static u8 gmd_to_intel_step(struct drm_i915_private *i915,
+ struct ip_version *gmd)
+{
+ u8 step = gmd->step + STEP_A0;
+
+ if (step >= STEP_FUTURE) {
+ drm_dbg(>drm, "Using future steppings\n");
+ return STEP_FUTURE;
+ }
+
+ return step;
+}
+
static void pvc_step_init(struct drm_i915_private *i915, int pci_revid);
void intel_step_init(struct drm_i915_private *i915)
@@ -144,6 +157,18 @@ void intel_step_init(struct drm_i915_private *i915)
int revid = INTEL_REVID(i915);
struct intel_step_info step = {};
+ if (HAS_GMD_ID(i915)) {
+ step.graphics_step = gmd_to_intel_step(i915,
+
_INFO(i915)->graphics.ip);
+ step.media_step = gmd_to_intel_step(i915,
+
_INFO(i915)->media.ip);
+ step.display_step = gmd_to_intel_step(i915,
+
_INFO(i915)->display.ip);
+ RUNTIME_INFO(i915)->step = step;
+
+ return;
+ }
+
if (IS_PONTEVECCHIO(i915)) {
pvc_step_init(i915, revid);
return;
diff --git a/drivers/gpu/drm/i915/intel_step.h
b/drivers/gpu/drm/i915/intel_step.h
index a6b12bfa9744..57b9928ddca6 100644
--- a/drivers/gpu/drm/i915/intel_step.h
+++ b/drivers/gpu/drm/i915/intel_step.h
@@ -23,21 +23,43 @@ struct intel_step_info {
missing comment in this struct that it's expected to have 4 number steps
per letter. I don't want someone to add a stepping B4 in future without
realizing that will render gmd_to_intel_step() invalid
with that added: Reviewed-by: Lucas De Marchi
Lucas De Marchi
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Read graphics/media/display arch version from hw
On Thu, Sep 15, 2022 at 06:46:46PM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space. New hardware programming
styles, features, and workarounds should be conditional solely on the
architecture version, and should no longer be derived from the PCI
device ID, revision ID, or platform-specific feature flags.
I'd just remove "New hardware programming ..." until the end, because:
1) Binding to the device will always happen by using the PCI ID.
2) I don't see us moving away from grouping them per-platform.
3) Flags may still be convenient to convey paths to take in the software
regardless of what the hardware provides.
Basically there is a new way to read the individual IP versions: we
didn't have that before and we were just hardcoding the info per
platform. And the new scheme for reading the stepping replaces what we
were reading before from PCI config space.
Bspec: 63361, 64111
v2:
- Move the IP version readout to intel_device_info.c
- Convert the macro into a function
v3:
- Move subplatform init to runtime early init
- Cache runtime ver, release info to compare with hardware values.
- Use IP_VER for snaity check(MattR)
v4:
- Minor doccumentation changes.
- Normalize HAS_GMD_ID macro value.(JaniN)
Signed-off-by: Matt Roper
Signed-off-by: Rodrigo Vivi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 +
drivers/gpu/drm/i915/i915_driver.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_device_info.c | 67 +++-
drivers/gpu/drm/i915/intel_device_info.h | 12 -
7 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..2d2044f2ed9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,8 @@
#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0xd84)
#define FORCEWAKE_ACK_MEDIA_GEN9_MMIO(0xd88)
+#define GMD_ID_GRAPHICS_MMIO(0xd8c)
+
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR _MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..e86798eaecb6 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -337,7 +337,8 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
- intel_device_info_subplatform_init(dev_priv);
+ intel_device_info_runtime_init_early(dev_priv);
+
intel_step_init(dev_priv);
intel_uncore_mmio_debug_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..7034ea848d65 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -940,6 +940,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
+#define HAS_GMD_ID(i915) (INTEL_INFO(i915)->has_gmd_id)
+
#define HAS_LSPCON(dev_priv) (IS_DISPLAY_VER(dev_priv, 9, 10))
#define HAS_L3_CCS_READ(i915) (INTEL_INFO(i915)->has_l3_ccs_read)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cace897e1db1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1143,6 +1143,7 @@ static const struct intel_device_info mtl_info = {
.display.has_modular_fia = 1,
.extra_gt_list = xelpmp_extra_gt,
.has_flat_ccs = 0,
+ .has_gmd_id = 1,
heh... this basically proves what I just said above ;)
.has_snoop = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a9bd829fc7e..acfcd155c8d0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5839,6 +5839,11 @@
#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz (1 << 29)
#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz (2 << 29)
+#define GMD_ID_DISPLAY _MMIO(0x510a0)
+#define GMD_ID_ARCH_MASK REG_GENMASK(31, 22)
+#define GMD_ID_RELEASE_MASK REG_GENMASK(21, 14)
+#define
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details ==
Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
URL : https://patchwork.freedesktop.org/series/108972/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108972v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/index.html
Participating hosts (46 -> 45)
--
Missing(1): fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_108972v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [PASS][1] -> [INCOMPLETE][2] ([i915#146] /
[i915#6712])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}: [DMESG-WARN][3] ([i915#2867]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[DMESG-FAIL][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5886]: https://gitlab.freedesktop.org/drm/intel/issues/5886
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108972v1
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108972v1: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
26360024b21d drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim checkpatch failed 09fac79aedc6 drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual -:122: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #122: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1136: + + } -:148: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #148: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:74: + gt->lmem_userfault_lock = drmm_kzalloc(>drm, sizeof(*gt->lmem_userfault_lock), GFP_KERNEL); -:160: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #160: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:821: + sizeof(*gt->lmem_userfault_lock), GFP_KERNEL); -:176: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #176: FILE: drivers/gpu/drm/i915/gt/intel_gt_types.h:156: + spinlock_t *lmem_userfault_lock; total: 0 errors, 2 warnings, 2 checks, 132 lines checked
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Tuesday, September 20, 2022 2:59 PM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > To: Srivatsa, Anusha > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > ; Vivi, Rodrigo > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > This is a prep series for the actual cdclk refactoring that will > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > holds the following: > > > > - cdclk action (squash, crawl or modeset) > > > > - cdclk frequency > > > > which gets populated in atomic check. Driver uses the populated > > > > values during atomic commit to do the suitable sequence of actions > > > > like programming squash ctl registers in case of squashing or PLL > > > > sequence incase of modeset and so on. > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > in the atomic commit phase will be sent shortly. > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > quickly. This to me seems like the most straightforward way to do what > we need: > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > approach should produce sane values. > > Ville, > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > purpose? > > You either > - start at old, crawl to mid, then squash to new > - start at old, squash to mid, then crawl to new Tested the changes on TGL(legacy) and DG2(squash). Took some time to understand the code but the mid cdclk config logic works. @Ville Syrjälä does replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic check make sense? Anusha > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH] drm/i915: Stop using flush_scheduled_work on driver remove
On Fri, Sep 23, 2022 at 03:29:34PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Kernel is trying to eliminate callers of flush_scheduled_work so lets > try to accommodate. > > We currently call it from intel_modeset_driver_remove_noirq on the driver > remove path but the comment next to it does not tell me what exact work it > wants to flush. > > I can spot three (or four) works using the system_wq: > > ..hotplug.reenable_work > ..hotplug.hotplug_work Looks like we at least try to shoot those down via intel_irq_uninstall() ->intel_hpd_cancel_work() ->cancel_delayed_work_sync() But I'm not sure how broken the hpd disable path is here. I know hpd cancel vs. irq disable has some known ordering issues during suspend at least, some of which I think may have gotten fixed recently. But hpd cancel is still a bit of a mess in general. Here we at least do cancel all the hpd works after irqs have been disabled, so I don't think any further flushing should help with whatever races we have left in there. > ..psr.dc3co_work I think the whole dc3co thing should be disabled atm, so nothing should ever schedule this. We should probably garbage collect the whole thing... > ..crtc->drrs.work That one should have been killed in intel_display_driver_unregister() ->drm_atomic_helper_shutdown() ->... ->intel_drrs_deactivate() ->cancel_delayed_work_sync() > So if I replace it with intel_hpd_cancel_work() that appears would handle > the first two. What about the other two? Other stuff that comes to mind is the pps vdd_off work. But looks like that should get taken down in the encoder->destroy() hook at the latest (via intel_mode_config_cleanup()). psr.work at least has a cancel_work_sync() in intel_psr_disable(), so should hopefully get killed the same way as drrs. opregion.asle_work seems to get cancelled from the unregister path. The ones that look broken to me are dmc.work and fbc underrun_work. > > Signed-off-by: Tvrtko Ursulin > Cc: Jani Nikula > Cc: Ville Syrjälä > Cc: Tetsuo Handa > --- > I am clueless about the display paths and only send this because Jani > convinced me to send a patch to kick off the discussion. No expectations > whatsoever this is correct or complete. > --- > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 2d0018ae34b1..0eb72530a003 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8980,7 +8980,7 @@ void intel_modeset_driver_remove_noirq(struct > drm_i915_private *i915) > intel_unregister_dsm_handler(); > > /* flush any delayed tasks or pending work */ > - flush_scheduled_work(); > + intel_hpd_cancel_work(i915); > > intel_hdcp_component_fini(i915); > > -- > 2.34.1 -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop using flush_scheduled_work on driver remove
== Series Details ==
Series: drm/i915: Stop using flush_scheduled_work on driver remove
URL : https://patchwork.freedesktop.org/series/108970/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108970v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/index.html
Participating hosts (46 -> 44)
--
Missing(2): fi-icl-u2 fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_108970v1 that come from known issues:
### IGT changes ###
Issues hit
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][1] -> [FAIL][2] ([i915#6298])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][3] ([i915#2867]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
- {bat-adlm-1}: [DMESG-WARN][5] ([i915#2867]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[DMESG-FAIL][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5828]: https://gitlab.freedesktop.org/drm/intel/issues/5828
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108970v1
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108970v1: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
36d2561cb127 drm/i915: Stop using flush_scheduled_work on driver remove
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/index.html
Re: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_ctx_persistence: adjust saturated-hostile test timeout
On 22.09.2022 10:13, Andrzej Hajda wrote:
GPU occasionally can hang during saturated-hostile test. Detection of
such case and reset can take up to 5 seconds. While at it fix typo in
definition of RESET_TIMEOUT_MS.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Signed-off-by: Andrzej Hajda
Please ignore the patch, it has been superseded by:
https://patchwork.freedesktop.org/patch/504450/
Regards
Andrzej
---
tests/i915/gem_ctx_persistence.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index 50196edb19f..603fdd84438 100644
--- a/tests/i915/gem_ctx_persistence.c
+++ b/tests/i915/gem_ctx_persistence.c
@@ -46,7 +46,8 @@
#include "intel_allocator.h"
#include "sw_sync.h"
-#define RESET_TIMEOUT_MS 2 * MSEC_PER_SEC; /* default: 640ms */
+#define RESET_TIMEOUT_MS (2 * MSEC_PER_SEC) /* default: 640ms */
+#define RESET_TIMEOUT_GPU_HANG_MS (1 * MSEC_PER_SEC)
static unsigned long reset_timeout_ms = RESET_TIMEOUT_MS;
#define NSEC_PER_MSEC (1000 * 1000ull)
@@ -370,7 +371,7 @@ static void test_nohangcheck_hostile(int i915, const intel_ctx_cfg_t *cfg)
igt_require(__enable_hangcheck(dir, false));
for_each_ctx_cfg_engine(i915, cfg, e) {
- int64_t timeout = 1 * NSEC_PER_MSEC;
+ int64_t timeout = RESET_TIMEOUT_GPU_HANG_MS;
const intel_ctx_t *ctx = intel_ctx_create(i915, cfg);
uint64_t ahnd = get_reloc_ahnd(i915, ctx->id);
igt_spin_t *spin;
@@ -951,7 +952,7 @@ test_saturated_hostile_all(int i915, const intel_ctx_t
*base_ctx,
intel_ctx_destroy(i915, ctx);
/* Hostile request requires a GPU reset to terminate */
- igt_assert_eq(wait_for_status(spin->out_fence, reset_timeout_ms), -EIO);
+ igt_assert_eq(wait_for_status(spin->out_fence,
RESET_TIMEOUT_GPU_HANG_MS), -EIO);
/* All other spinners should be left unharmed */
gem_quiescent_gpu(i915);
[Intel-gfx] [PATCH i-g-t] gem_ctx_persistence: adjust reset timeout
Tests on DG2 show that context cancel can take even 350ms,
due to error state capturing in guc_handle_context_reset.
Since it happens only in debug mode and tests runs in debug mode
it should be fine to adjust the timeout.
Let's double this value, to be on safe side.
It should fix multiple test timeout failures.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Signed-off-by: Andrzej Hajda
---
tests/i915/gem_ctx_persistence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index 50196edb19f..a844439de19 100644
--- a/tests/i915/gem_ctx_persistence.c
+++ b/tests/i915/gem_ctx_persistence.c
@@ -1214,7 +1214,7 @@ static void do_test(void (*test)(int i915, const
intel_ctx_cfg_t *cfg,
if (timeout != -1) {
igt_require(gem_engine_property_printf(i915, name,
ATTR, "%d", 50) > 0);
- reset_timeout_ms = 200;
+ reset_timeout_ms = 700;
}
test(i915, cfg, engine);
--
2.34.1
Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.
Based on code from Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/i915_drv.h | 9 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
* HuC-specific commands.
*/
+static bool vcs_supported(struct intel_gt *gt)
+{
+ intel_engine_mask_t mask = gt->info.engine_mask;
+
+ /*
+ * we can reach here from i915_driver_early_probe for primary
+ * GT with it being not fully setup hence fall back to the
device info's
+ * engine mask
+ */
+ if (!mask && gt_is_root(gt))
+ mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
Is it possible for all instances to be fused off? Wondering if the
function shouldn't just use platform_engine_mask.
The spec says that there is always going to be at least 1 VCS (bspec
55417 in case you want to double-check). I don't see that changing in
the future, because what's the point of having a media GT if you don't
have any enabled VCS engines on it?
Also, platform_engine_mask only contains the entries of the primary GT,
for the other GTs we'd have to navigate the array in the device info
structure and I don't think we want to do that from here when we've
already copied the mask inside gt->info.engine_mask.
Daniele
Regards,
Tvrtko
+
+ return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+ struct intel_gt *gt = huc_to_gt(huc);
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+ if (!vcs_supported(gt)) {
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+ return;
+ }
+
if (GRAPHICS_VER(i915) >= 11) {
huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private
*i915,
#define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
#define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
-#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({ \
unsigned int first__ = (first); \
unsigned int count__ = (count); \
- ((gt)->info.engine_mask & \
- GENMASK(first__ + count__ - 1, first__)) >> first__; \
+ ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__; \
})
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+ __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
#define RCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
#define BCS_MASK(gt) \
Re: [Intel-gfx] [PATCH 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On 9/23/2022 2:24 AM, Jani Nikula wrote:
On Thu, 22 Sep 2022, Daniele Ceraolo Spurio
wrote:
From: Aravind Iddamsetty
With MTL standalone media architecture the wopcm layout has changed with
separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.
+=+===> ++ <== WOPCM TOP
^ ^ ||
| | ||
|GCD| GCD RC6 Image|
|GuC|Power Context |
|WOPCM ||
|Size ++
| | | GCD GuC Image|
| | ||
| v ||
| +===> ++ <== SA Media GuC WOPCM Top
| ^ ||
| SA Media||
|GuC| SA Media RC6 Image |
| WOPCM |Power Context |
|Size ||
WOPCM | ++
| | ||
| | | SA Media GuC Image |
| v ||
| +===> ++ <== GuC WOPCM base
| | WOPCM RSVD |
| +--- + <== HuC Firmware Top
v | HuC FW|
+=> ++ <== WOPCM Base
Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
by the bios. Therefore, we can skip all the math for the partitioning
and just limit ourselves to sanity checking the values.
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 7 +--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
drivers/gpu/drm/i915/i915_driver.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 --
drivers/gpu/drm/i915/i915_gem.c | 5 ++-
11 files changed, 56 insertions(+), 32 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..6ed4c745b226 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -129,7 +129,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/intel_wopcm.o
The comment near the top of the file:
# Please keep these build lists sorted!
D'oh! My monkey brain saw that "wopcm" was correctly ordered after
"engines" and completely ignored the first part of the name :/
Will fix next rev.
Daniele
+
# x86 intel-gtt module support
gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
# autogenerated null render state
@@ -183,8 +185,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
- i915_vma_resource.o \
- intel_wopcm.o
+ i915_vma_resource.o
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 30cf5c3369d9..605e1aa674d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* why.
*/
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
- intel_wopcm_guc_size(>vm.i915->wopcm));
+ intel_wopcm_guc_size(>vm.gt->wopcm));
ret = intel_vgt_balloon(ggtt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b367cfff48d5..a95eb0b656d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
+ intel_wopcm_init_early(>wopcm);
intel_uc_init_early(>uc);
intel_rps_init_early(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f19c2de77ff6..c20a32d2700f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -30,6 +30,7 @@
#include "intel_migrate_types.h"
#include "intel_wakeref.h"
#include "pxp/intel_pxp_types.h"
Re: [Intel-gfx] [PATCH v2] drm/i915: Improve debug print in vm_fault_ttm
On 23.09.2022 10:45, Nirmoy Das wrote:
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das ---
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 e3fc38dd5db0..55455321f652 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU accessible(err =
%pe)\n", ERR_PTR(err));
Reviewed-by: Andrzej Hajda
Regards
Andrzej
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
[Intel-gfx] [PATCH v3] drm/i915: Improve debug print in vm_fault_ttm
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
v3: Fix dim checkpatch warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 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 e3fc38dd5db0..3dc6acfcf4ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n",
+ ERR_PTR(err));
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
--
2.37.3
[Intel-gfx] [PATCH] drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
We had already grabbed the rpm wakeref at obj destruction path,
but it also required to grab the wakeref when object moves.
When i915_gem_object_release_mmap_offset() gets called by
i915_ttm_move_notify(), it will release the mmap offset without
grabbing the wakeref. We want to avoid that therefore,
grab the wakreref at i915_ttm_unmap_virtual() accordingly.
While doing that also changed the lmem_userfault_lock from
mutex to spinlock, as spinlock widely used for list.
Also changed if (obj->userfault_count) to
GEM_BUG_ON(!obj->userfault_count).
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 39
drivers/gpu/drm/i915/gt/intel_gt.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
4 files changed, 45 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 73d9eda1d6b7..9da561c19a47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -557,11 +557,13 @@ void
i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *
drm_vma_node_unmap(>base.vma_node, bdev->dev_mapping);
- if (obj->userfault_count) {
- /* rpm wakeref provide exclusive access */
- list_del(>userfault_link);
- obj->userfault_count = 0;
- }
+ /*
+* We have exclusive access here via runtime suspend. All other callers
+* must first grab the rpm wakeref.
+*/
+ GEM_BUG_ON(!obj->userfault_count);
+ list_del(>userfault_link);
+ obj->userfault_count = 0;
}
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
@@ -587,13 +589,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_lock(>mmo.lock);
}
spin_unlock(>mmo.lock);
-
- if (obj->userfault_count) {
- mutex_lock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
- list_del(>userfault_link);
-
mutex_unlock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
- obj->userfault_count = 0;
- }
}
static struct i915_mmap_offset *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..0630eeca7316 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -509,18 +509,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object
*obj, unsigned int flags)
static void i915_ttm_delete_mem_notify(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- intel_wakeref_t wakeref = 0;
if (bo->resource && likely(obj)) {
- /* ttm_bo_release() already has dma_resv_lock */
- if (i915_ttm_cpu_maps_iomem(bo->resource))
- wakeref =
intel_runtime_pm_get(_i915(obj->base.dev)->runtime_pm);
-
__i915_gem_object_pages_fini(obj);
-
- if (wakeref)
-
intel_runtime_pm_put(_i915(obj->base.dev)->runtime_pm, wakeref);
-
i915_ttm_free_cached_io_rsgt(obj);
}
}
@@ -1052,12 +1043,15 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
goto out_rpm;
- /* ttm_bo_vm_reserve() already has dma_resv_lock */
+ /*
+* ttm_bo_vm_reserve() already has dma_resv_lock.
+* userfault_count is protected by dma_resv lock and rpm wakeref.
+*/
if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) {
obj->userfault_count = 1;
- mutex_lock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ spin_lock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
list_add(>userfault_link,
_gt(to_i915(obj->base.dev))->lmem_userfault_list);
-
mutex_unlock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ spin_unlock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
}
if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
@@ -1123,7 +1117,28 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static void i915_ttm_unmap_virtual(struct drm_i915_gem_object *obj)
{
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ intel_wakeref_t wakeref = 0;
+
+ assert_object_held_shared(obj);
+
+ if (i915_ttm_cpu_maps_iomem(bo->resource)) {
+ wakeref =
intel_runtime_pm_get(_i915(obj->base.dev)->runtime_pm);
+
+ /* userfault_count is protected by obj lock and rpm wakeref. */
+ if (obj->userfault_count) {
+
[Intel-gfx] [PATCH] drm/i915: Stop using flush_scheduled_work on driver remove
From: Tvrtko Ursulin Kernel is trying to eliminate callers of flush_scheduled_work so lets try to accommodate. We currently call it from intel_modeset_driver_remove_noirq on the driver remove path but the comment next to it does not tell me what exact work it wants to flush. I can spot three (or four) works using the system_wq: ..hotplug.reenable_work ..hotplug.hotplug_work ..psr.dc3co_work ..crtc->drrs.work So if I replace it with intel_hpd_cancel_work() that appears would handle the first two. What about the other two? Signed-off-by: Tvrtko Ursulin Cc: Jani Nikula Cc: Ville Syrjälä Cc: Tetsuo Handa --- I am clueless about the display paths and only send this because Jani convinced me to send a patch to kick off the discussion. No expectations whatsoever this is correct or complete. --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 2d0018ae34b1..0eb72530a003 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8980,7 +8980,7 @@ void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915) intel_unregister_dsm_handler(); /* flush any delayed tasks or pending work */ - flush_scheduled_work(); + intel_hpd_cancel_work(i915); intel_hdcp_component_fini(i915); -- 2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for Add SLPC selftest live_slpc_power (rev2)
== Series Details == Series: Add SLPC selftest live_slpc_power (rev2) URL : https://patchwork.freedesktop.org/series/108900/ State : success == Summary == CI Bug Log - changes from CI_DRM_12174 -> Patchwork_108900v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/index.html Participating hosts (42 -> 46) -- Additional (5): fi-kbl-soraka fi-cml-u2 fi-bxt-dsi fi-icl-u2 fi-hsw-4770 Missing(1): fi-bdw-samus Known issues Here are the changes found in Patchwork_108900v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-cml-u2: NOTRUN -> [SKIP][1] ([i915#1208]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@gem_huc_c...@huc-copy.html - fi-cml-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_huc_c...@huc-copy.html - fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-cml-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_lmem_swapp...@parallel-random-engines.html - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@gem_softpin@allocator-basic-reserve: - fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html * igt@gem_tiled_blits@basic: - fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271]) +12 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3012]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_heartbeat: - fi-bxt-dsi: NOTRUN -> [DMESG-FAIL][11] ([i915#5334]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html - fi-cml-u2: NOTRUN -> [SKIP][13] ([fdo#109284] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-bxt-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-cml-u2: NOTRUN -> [SKIP][16] ([i915#4213]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html - fi-icl-u2: NOTRUN -> [SKIP][17] ([i915#4103]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-connector-state: - fi-icl-u2: NOTRUN -> [WARN][18] ([i915#6008]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@force-load-detect: - fi-cml-u2: NOTRUN -> [SKIP][19] ([fdo#109285])
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve debug print in vm_fault_ttm (rev2)
== Series Details ==
Series: drm/i915: Improve debug print in vm_fault_ttm (rev2)
URL : https://patchwork.freedesktop.org/series/108887/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12174 -> Patchwork_108887v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/index.html
Participating hosts (42 -> 44)
--
Additional (3): fi-kbl-soraka fi-hsw-4770 fi-bxt-dsi
Missing(1): fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108887v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108887v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +12 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1072]) +3
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([fdo#109295] / [i915#3301])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][12] ([i915#6641])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][13] ([i915#2867]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][15] ([i915#6816]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]:
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 12:45 +, Hogander, Jouni wrote:
> On Fri, 2022-09-23 at 12:37 +, Souza, Jose wrote:
> > On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > > > Current PSR code is supposed to use TRANSCODER_EDP to force 0
> > > > > shift
> > > > > for
> > > > > bits in PSR_IMR/IIR registers:
> > > > >
> > > > > /*
> > > > > * gen12+ has registers relative to transcoder and one per
> > > > > transcoder
> > > > > * using the same bit definition: handle it as TRANSCODER_EDP
> > > > > to
> > > > > force
> > > > > * 0 shift in bit definition
> > > > > */
> > > > >
> > > > > At the time of writing the code assumption "TRANSCODER_EDP ==
> > > > > 0"
> > > > > was made.
> > > > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > > > shifted
> > > > > incorrectly if DISPLAY_VER >= 12.
> > > >
> > > > From where are you getting that TRANSCODER_EDP == 0?
> > >
> > > It's not. That is my point. If you look at this commit:
> > >
> > > https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> > >
> > > adding this comment:
> > >
> > > + /*
> > > + * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > > + * using the same bit definition: handle it as
> > > TRANSCODER_EDP
> > > to force
> > > + * 0 shift in bit definition
> > > + */
> > >
> > > and the code added by this commit is doing
> > >
> > > ...
> > > + trans_shift = 0;
> > > mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > >
> > > + mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > >
> > > and if we look at EDP_PSR_ERROR definition:
> > >
> > > ...
> > > #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> > > TRANSCODER_EDP ? \
> > > 0 : ((trans) -
> > > TRANSCODER_A + 1) * 8)
> > > ...
> > > #define EDP_PSR_ERROR(trans) (0x4 <<
> > > _EDP_PSR_TRANS_SHIFT(trans))
> > > ...
> > >
> > > EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> > > TRANSCODER_EDP as mentioned in the added comment:
> > > EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> > >
> > > My patch is doing what is in the comment. There are other way to
> > > fix
> > > this, but to my opinion original idea using TRANSCODER_EDP in
> > > commit
> > > 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> > > code pretty clean.
> > >
> > > >
> > > > enum pipe {
> > > > INVALID_PIPE = -1,
> > > >
> > > > PIPE_A = 0,
> > > > PIPE_B,
> > > > PIPE_C,
> > > > PIPE_D,
> > > > _PIPE_EDP,
> > > >
> > > > I915_MAX_PIPES = _PIPE_EDP
> > > > };
> > > >
> > > > #define pipe_name(p) ((p) + 'A')
> > > >
> > > > enum transcoder {
> > > > INVALID_TRANSCODER = -1,
> > > > /*
> > > > * The following transcoders have a 1:1 transcoder ->
> > > > pipe
> > > > mapping,
> > > > * keep their values fixed: the code assumes that
> > > > TRANSCODER_A=0, the
> > > > * rest have consecutive values and match the enum values
> > > > of
> > > > the pipes
> > > > * they map to.EDP_PSR_TRANS_
> > > > */
> > > > TRANSCODER_A = PIPE_A,
> > > > TRANSCODER_B = PIPE_B,
> > > > TRANSCODER_C = PIPE_C,
> > > > TRANSCODER_D = PIPE_D,
> > > >
> > > > /*
> > > > * The following transcoders can map to any pipe, their
> > > > enum
> > > > value
> > > > * doesn't need to stay fixed.
> > > > */
> > > > TRANSCODER_EDP,
> > > >
> > > > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> > > >
> > > > >
> > > > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > > > thought
> > > > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this
> > > > > way
> > > > > keeps
> > > > > code clean and readable.
> > > >
> > > > trans_shift = 0 is fine, we needed this because display12+
> > > > splited
> > > > from a single register with all transcoder to one register per
> > > > transcoder.
> > > >
> > >
> > > No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> > > EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would
> > > prevent
> > > misunderstanding here.
> >
> > Okay now I understood.
> > In my opinion the proper fix would be add TGL_X macros to be used in
> > diplay12+ paths and drop the EDP transcoder concept that do not exist
> > in TGL+.
>
> Ok, I started to look at this originally and it gets a bit messy as
> each bit in PSR_IMR/PSR_ISR needs separate handling. If we choose this
> then I was thinking adding similar _bit_get functions as we have for
> man_trk_ctl bits. What do you think?
If the code gets simpler go ahead with functions to return the bits.
>
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Improve debug print in vm_fault_ttm (rev2)
== Series Details == Series: drm/i915: Improve debug print in vm_fault_ttm (rev2) URL : https://patchwork.freedesktop.org/series/108887/ State : warning == Summary == Error: dim checkpatch failed 751ba3d859b3 drm/i915: Improve debug print in vm_fault_ttm -:24: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #24: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1037: + drm_dbg(dev, "Unable to make resource CPU accessible(err = %pe)\n", ERR_PTR(err)); total: 0 errors, 1 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 12:37 +, Souza, Jose wrote:
> On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > > Current PSR code is supposed to use TRANSCODER_EDP to force 0
> > > > shift
> > > > for
> > > > bits in PSR_IMR/IIR registers:
> > > >
> > > > /*
> > > > * gen12+ has registers relative to transcoder and one per
> > > > transcoder
> > > > * using the same bit definition: handle it as TRANSCODER_EDP
> > > > to
> > > > force
> > > > * 0 shift in bit definition
> > > > */
> > > >
> > > > At the time of writing the code assumption "TRANSCODER_EDP ==
> > > > 0"
> > > > was made.
> > > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > > shifted
> > > > incorrectly if DISPLAY_VER >= 12.
> > >
> > > From where are you getting that TRANSCODER_EDP == 0?
> >
> > It's not. That is my point. If you look at this commit:
> >
> > https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> >
> > adding this comment:
> >
> > + /*
> > + * gen12+ has registers relative to transcoder and one per
> > transcoder
> > + * using the same bit definition: handle it as
> > TRANSCODER_EDP
> > to force
> > + * 0 shift in bit definition
> > + */
> >
> > and the code added by this commit is doing
> >
> > ...
> > + trans_shift = 0;
> > mask = EDP_PSR_ERROR(trans_shift);
> > ...
> >
> > + mask = EDP_PSR_ERROR(trans_shift);
> > ...
> >
> > and if we look at EDP_PSR_ERROR definition:
> >
> > ...
> > #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> > TRANSCODER_EDP ? \
> > 0 : ((trans) -
> > TRANSCODER_A + 1) * 8)
> > ...
> > #define EDP_PSR_ERROR(trans) (0x4 <<
> > _EDP_PSR_TRANS_SHIFT(trans))
> > ...
> >
> > EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> > TRANSCODER_EDP as mentioned in the added comment:
> > EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> >
> > My patch is doing what is in the comment. There are other way to
> > fix
> > this, but to my opinion original idea using TRANSCODER_EDP in
> > commit
> > 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> > code pretty clean.
> >
> > >
> > > enum pipe {
> > > INVALID_PIPE = -1,
> > >
> > > PIPE_A = 0,
> > > PIPE_B,
> > > PIPE_C,
> > > PIPE_D,
> > > _PIPE_EDP,
> > >
> > > I915_MAX_PIPES = _PIPE_EDP
> > > };
> > >
> > > #define pipe_name(p) ((p) + 'A')
> > >
> > > enum transcoder {
> > > INVALID_TRANSCODER = -1,
> > > /*
> > > * The following transcoders have a 1:1 transcoder ->
> > > pipe
> > > mapping,
> > > * keep their values fixed: the code assumes that
> > > TRANSCODER_A=0, the
> > > * rest have consecutive values and match the enum values
> > > of
> > > the pipes
> > > * they map to.EDP_PSR_TRANS_
> > > */
> > > TRANSCODER_A = PIPE_A,
> > > TRANSCODER_B = PIPE_B,
> > > TRANSCODER_C = PIPE_C,
> > > TRANSCODER_D = PIPE_D,
> > >
> > > /*
> > > * The following transcoders can map to any pipe, their
> > > enum
> > > value
> > > * doesn't need to stay fixed.
> > > */
> > > TRANSCODER_EDP,
> > >
> > > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> > >
> > > >
> > > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > > thought
> > > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this
> > > > way
> > > > keeps
> > > > code clean and readable.
> > >
> > > trans_shift = 0 is fine, we needed this because display12+
> > > splited
> > > from a single register with all transcoder to one register per
> > > transcoder.
> > >
> >
> > No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> > EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would
> > prevent
> > misunderstanding here.
>
> Okay now I understood.
> In my opinion the proper fix would be add TGL_X macros to be used in
> diplay12+ paths and drop the EDP transcoder concept that do not exist
> in TGL+.
Ok, I started to look at this originally and it gets a bit messy as
each bit in PSR_IMR/PSR_ISR needs separate handling. If we choose this
then I was thinking adding similar _bit_get functions as we have for
man_trk_ctl bits. What do you think?
I would still consider current approach as forcing 0 shifting using
EDP_PSR_TRANS_* keeps it pretty simple.
>
> Also please include a fixes tag pointing to
> 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf so this gets backported.
>
> >
> > > >
> > > > v2: Improve commit message (José)
> > > >
> > > > Cc: Mika Kahola
> > > > Cc: José Roberto de Souza
> > > >
> > > > Signed-off-by: Jouni Högander
> > > > ---
> > > >
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift
> > > for
> > > bits in PSR_IMR/IIR registers:
> > >
> > > /*
> > > * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > > * using the same bit definition: handle it as TRANSCODER_EDP to
> > > force
> > > * 0 shift in bit definition
> > > */
> > >
> > > At the time of writing the code assumption "TRANSCODER_EDP == 0"
> > > was made.
> > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > shifted
> > > incorrectly if DISPLAY_VER >= 12.
> >
> > From where are you getting that TRANSCODER_EDP == 0?
>
> It's not. That is my point. If you look at this commit:
>
> https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
>
> adding this comment:
>
> + /*
> +* gen12+ has registers relative to transcoder and one per
> transcoder
> +* using the same bit definition: handle it as TRANSCODER_EDP
> to force
> +* 0 shift in bit definition
> +*/
>
> and the code added by this commit is doing
>
> ...
> + trans_shift = 0;
> mask = EDP_PSR_ERROR(trans_shift);
> ...
>
> + mask = EDP_PSR_ERROR(trans_shift);
> ...
>
> and if we look at EDP_PSR_ERROR definition:
>
> ...
> #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> TRANSCODER_EDP ? \
>0 : ((trans) -
> TRANSCODER_A + 1) * 8)
> ...
> #define EDP_PSR_ERROR(trans)(0x4 <<
> _EDP_PSR_TRANS_SHIFT(trans))
> ...
>
> EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> TRANSCODER_EDP as mentioned in the added comment:
> EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
>
> My patch is doing what is in the comment. There are other way to fix
> this, but to my opinion original idea using TRANSCODER_EDP in commit
> 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> code pretty clean.
>
> >
> > enum pipe {
> > INVALID_PIPE = -1,
> >
> > PIPE_A = 0,
> > PIPE_B,
> > PIPE_C,
> > PIPE_D,
> > _PIPE_EDP,
> >
> > I915_MAX_PIPES = _PIPE_EDP
> > };
> >
> > #define pipe_name(p) ((p) + 'A')
> >
> > enum transcoder {
> > INVALID_TRANSCODER = -1,
> > /*
> > * The following transcoders have a 1:1 transcoder -> pipe
> > mapping,
> > * keep their values fixed: the code assumes that
> > TRANSCODER_A=0, the
> > * rest have consecutive values and match the enum values of
> > the pipes
> > * they map to.EDP_PSR_TRANS_
> > */
> > TRANSCODER_A = PIPE_A,
> > TRANSCODER_B = PIPE_B,
> > TRANSCODER_C = PIPE_C,
> > TRANSCODER_D = PIPE_D,
> >
> > /*
> > * The following transcoders can map to any pipe, their enum
> > value
> > * doesn't need to stay fixed.
> > */
> > TRANSCODER_EDP,
> >
> > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> >
> > >
> > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > thought
> > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this way
> > > keeps
> > > code clean and readable.
> >
> > trans_shift = 0 is fine, we needed this because display12+ splited
> > from a single register with all transcoder to one register per
> > transcoder.
> >
>
> No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would prevent
> misunderstanding here.
Okay now I understood.
In my opinion the proper fix would be add TGL_X macros to be used in diplay12+
paths and drop the EDP transcoder concept that do not exist in TGL+.
Also please include a fixes tag pointing to
8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf so this gets backported.
>
> > >
> > > v2: Improve commit message (José)
> > >
> > > Cc: Mika Kahola
> > > Cc: José Roberto de Souza
> > >
> > > Signed-off-by: Jouni Högander
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 9def8d9fade6..9ecf1a9a1120 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -129,7 +129,7 @@ static void psr_irq_control(struct intel_dp
> > > *intel_dp)
> > > * 0 shift in bit definition
> > > */
> > > if (DISPLAY_VER(dev_priv) >= 12) {
> > > - trans_shift = 0;
> > > + trans_shift = TRANSCODER_EDP;
> > > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > > } else {
> >
[Intel-gfx] ✓ Fi.CI.IGT: success for Add PXP firmware respose on ARB failure
== Series Details == Series: Add PXP firmware respose on ARB failure URL : https://patchwork.freedesktop.org/series/108929/ State : success == Summary == CI Bug Log - changes from CI_DRM_12169_full -> Patchwork_108929v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108929v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4338]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [43]:
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On Thu, 22 Sep 2022, Maxime Ripard wrote:
> drm_connector_pick_cmdline_mode() is in charge of finding a proper
> drm_display_mode from the definition we got in the video= command line
> argument.
>
> Let's add some unit tests to make sure we're not getting any regressions
> there.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index bbc535cc50dd..d553e793e673 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
> *client, int mode)
> return ret;
> }
> EXPORT_SYMBOL(drm_client_modeset_dpms);
> +
> +#ifdef CONFIG_DRM_KUNIT_TEST
> +#include "tests/drm_client_modeset_test.c"
> +#endif
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> new file mode 100644
> index ..46335de7bc6b
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
[snip]
> +MODULE_AUTHOR("Maxime Ripard ");
> +MODULE_LICENSE("GPL");
I think these annotations are incompatible with including the unit test,
and, in this case, affect drm.ko.
And we'll have two kinds of tests, those that get built via
tests/Makefile, and those that get included, like this one, which should
not be mentioned in tests/Makefile.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/pxp: Add firmware status when ARB session fails
== Series Details == Series: series starting with [1/1] drm/i915/pxp: Add firmware status when ARB session fails URL : https://patchwork.freedesktop.org/series/108928/ State : success == Summary == CI Bug Log - changes from CI_DRM_12169_full -> Patchwork_108928v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108928v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4338]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [43]:
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On Fri, Sep 23, 2022 at 12:30:09PM +0200, Thomas Zimmermann wrote:
> Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
> > On 9/23/22 11:15, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 22.09.22 um 16:25 schrieb Maxime Ripard:
> > > > drm_connector_pick_cmdline_mode() is in charge of finding a proper
> > > > drm_display_mode from the definition we got in the video= command line
> > > > argument.
> > > >
> > > > Let's add some unit tests to make sure we're not getting any regressions
> > > > there.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > > > b/drivers/gpu/drm/drm_client_modeset.c
> > > > index bbc535cc50dd..d553e793e673 100644
> > > > --- a/drivers/gpu/drm/drm_client_modeset.c
> > > > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > > > @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
> > > > *client, int mode)
> > > > return ret;
> > > >}
> > > >EXPORT_SYMBOL(drm_client_modeset_dpms);
> > > > +
> > > > +#ifdef CONFIG_DRM_KUNIT_TEST
> > > > +#include "tests/drm_client_modeset_test.c"
> > > > +#endif
> > >
> > > I strongly dislike this style of including source files in each other.
> > > It's a recipe for all kind of build errors. Can you do something else?
> > >
> >
> > This seems to be the convention used to test static functions and what's
> > documented in the Kunit docs:
> > https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
>
> That document says "...one option is to conditionally #include the test
> file...". This doesn't sound like a strong requirement.
No, but this is the only option documented, which still indicates a very
strong preference.
> > I agree with you that's not ideal but I think that consistency with how
> > it is done by other subsystems is also important.
> > > As the tested function is an internal interface, maybe export a wrapper
> > > if tests are enabled, like this:
> > >
> > > #ifdef CONFIG_DRM_KUNIT_TEST
> > > struct drm_display_mode *
> > > drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
> > > {
> > > return drm_connector_pick_cmdline_mode(connector)
> > > }
> > > EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
> > > #endif
> > >
> > > The wrapper's declaration can be located in the kunit test file.
And I'm afraid this just doesn't scale. If we start testing more and
more static functions, do we really want to have that wrapper for each
of them?
> > But that's also not nice since we are artificially exposing these only
> > to allow the static functions to be called from unit tests. And would
> > be a different approach than the one used by all other subsystems...
> >
>
> There's the problem of interference between the source files when building
> the code. It's also not the same source code after including the test file.
> At a minimum, including the tests' source file further includes more files.
> also includes quite a few of Linux header files.
>
> IMHO the current convention (if any) is far from optimal and we should
> consider breaking it.
I mean... this is a discussion about theoretical issues. If there is
indeed some regular build errors on this, then sure, we can change it.
I'm confident that will affect pretty much every one using kunit equally
though, so I'm fairly sure the documentation itself will have changed.
But right now we're discussing an alternative because of a problem we
never experienced. I don't see the point of breaking the consistency
provided by the documentation for something not backed by any actual
problem.
Maxime
signature.asc
Description: PGP signature
[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/108945/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12173 -> Patchwork_108945v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/index.html
Participating hosts (43 -> 42)
--
Additional (1): fi-hsw-4770
Missing(2): fi-bdw-samus fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108945v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108945v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#4418])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1072]) +3
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][11] ([i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-rkl-guc/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][12] ([i915#6816]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][14] ([i915#2867]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][16] ([i915#3987]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hugepages:
- {bat-adln-1}: [DMESG-WARN][18] ([i915#5278]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-adln-1/igt@i915_selftest@l...@hugepages.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-adln-1/igt@i915_selftest@l...@hugepages.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][20] ([i915#6257] / [i915#6380]) ->
[PASS][21]
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On 9/23/22 12:30, Thomas Zimmermann wrote:
[...]
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
>>>
>>> I strongly dislike this style of including source files in each other.
>>> It's a recipe for all kind of build errors. Can you do something else?
>>>
>>
>> This seems to be the convention used to test static functions and what's
>> documented in the Kunit docs:
>> https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
>
> That document says "...one option is to conditionally #include the test
> file...". This doesn't sound like a strong requirement.
>
That's true.
>>
>> I agree with you that's not ideal but I think that consistency with how
>> it is done by other subsystems is also important.
>>
>>> As the tested function is an internal interface, maybe export a wrapper
>>> if tests are enabled, like this:
>>>
>>> #ifdef CONFIG_DRM_KUNIT_TEST
>>> struct drm_display_mode *
>>> drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
>>> {
>>> return drm_connector_pick_cmdline_mode(connector)
>>> }
>>> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
>>> #endif
>>>
>>> The wrapper's declaration can be located in the kunit test file.
>>>
>>
>> But that's also not nice since we are artificially exposing these only
>> to allow the static functions to be called from unit tests. And would
>> be a different approach than the one used by all other subsystems...
>>
>
> There's the problem of interference between the source files when
> building the code. It's also not the same source code after including
> the test file. At a minimum, including the tests' source file further
> includes more files. also includes quite a few of Linux
> header files.
>
> IMHO the current convention (if any) is far from optimal and we should
> consider breaking it.
>
Yes, I agree with that. But probably we should be explicit about the
wrapper export symbols to access static functions pattern in the KUnit
docs so other subsystems could do the same and it becomes a convention ?
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove flush_scheduled_work() from live_execlists
On 23/09/2022 11:32, Das, Nirmoy wrote:
Reviewed-by: Nirmoy Das
Thanks!
Pushed now. Should land with 6.2.
Regards,
Tvrtko
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.
Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync with the execlists capture state handling, but that is
not strictly required for the test to function and can be removed.
Signed-off-by: Tvrtko Ursulin
Cc: Tetsuo Handa
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 09f8cd2d0e2c..e62d089257ae 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -85,8 +85,6 @@ static int wait_for_reset(struct intel_engine_cs
*engine,
break;
} while (time_before(jiffies, timeout));
- flush_scheduled_work();
-
if (rq->fence.error != -EIO) {
pr_err("%s: hanging request %llx:%lld not reset\n",
engine->name,
[Intel-gfx] [PATCH 1/3] drm/i915/guc/slpc: Run SLPC selftests on all tiles
Run slpc selftests on all tiles
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 45 -
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index f8a1d27df272..928f74718881 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -270,26 +270,50 @@ static int run_test(struct intel_gt *gt, int test_type)
static int live_slpc_vary_min(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, VARY_MIN);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, VARY_MIN);
+ return ret;
}
static int live_slpc_vary_max(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, VARY_MAX);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, VARY_MAX);
+ return ret;
}
/* check if pcode can grant RP0 */
static int live_slpc_max_granted(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, MAX_GRANTED);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, MAX_GRANTED);
+ return ret;
}
int intel_slpc_live_selftests(struct drm_i915_private *i915)
@@ -300,8 +324,13 @@ int intel_slpc_live_selftests(struct drm_i915_private
*i915)
SUBTEST(live_slpc_max_granted),
};
- if (intel_gt_is_wedged(to_gt(i915)))
- return 0;
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i) {
+ if (intel_gt_is_wedged(gt))
+ return 0;
+ }
return i915_live_subtests(tests, i915);
}
--
2.25.1
[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Add helper function measure_power
move the power measurement and the triangle filter
to a different function. No functional changes.
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index cfb4708dd62e..99a372486fb7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -1107,21 +1107,27 @@ static u64 __measure_power(int duration_ms)
return div64_u64(1000 * 1000 * dE, dt);
}
-static u64 measure_power_at(struct intel_rps *rps, int *freq)
+static u64 measure_power(struct intel_rps *rps, int *freq)
{
u64 x[5];
int i;
- *freq = rps_set_check(rps, *freq);
for (i = 0; i < 5; i++)
x[i] = __measure_power(5);
- *freq = (*freq + read_cagf(rps)) / 2;
+
+ *freq = (*freq + intel_rps_read_actual_frequency(rps)) / 2;
/* A simple triangle filter for better result stability */
sort(x, 5, sizeof(*x), cmp_u64, NULL);
return div_u64(x[1] + 2 * x[2] + x[3], 4);
}
+static u64 measure_power_at(struct intel_rps *rps, int *freq)
+{
+ *freq = rps_set_check(rps, *freq);
+ return measure_power(rps, freq);
+}
+
int live_rps_power(void *arg)
{
struct intel_gt *gt = arg;
--
2.25.1
[Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Add SLPC selftest live_slpc_power
A fundamental assumption is that at lower frequencies,
not only do we run slower, but we save power compared to
higher frequencies.
live_slpc_power checks if running at low frequency saves power
v2: re-use code to measure power
fixed cosmetic review comments (Vinay)
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 127 ++--
1 file changed, 118 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index 928f74718881..4c6e9257e593 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -11,7 +11,8 @@
enum test_type {
VARY_MIN,
VARY_MAX,
- MAX_GRANTED
+ MAX_GRANTED,
+ SLPC_POWER,
};
static int slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 freq)
@@ -41,6 +42,39 @@ static int slpc_set_max_freq(struct intel_guc_slpc *slpc,
u32 freq)
return ret;
}
+static int slpc_set_freq(struct intel_gt *gt, u32 freq)
+{
+ int err;
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+
+ err = slpc_set_max_freq(slpc, freq);
+ if (err) {
+ pr_err("Unable to update max freq");
+ return err;
+ }
+
+ err = slpc_set_min_freq(slpc, freq);
+ if (err) {
+ pr_err("Unable to update min freq");
+ return err;
+ }
+
+ return err;
+}
+
+static u64 measure_power_at_freq(struct intel_gt *gt, int *freq, u64 *power)
+{
+ int err = 0;
+
+ err = slpc_set_freq(gt, *freq);
+ if (err)
+ return err;
+ *freq = intel_rps_read_actual_frequency(>rps);
+ *power = measure_power(>rps, freq);
+
+ return err;
+}
+
static int vary_max_freq(struct intel_guc_slpc *slpc, struct intel_rps *rps,
u32 *max_act_freq)
{
@@ -113,6 +147,58 @@ static int vary_min_freq(struct intel_guc_slpc *slpc,
struct intel_rps *rps,
return err;
}
+static int slpc_power(struct intel_gt *gt, struct intel_engine_cs *engine)
+{
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+ struct {
+ u64 power;
+ int freq;
+ } min, max;
+ int err = 0;
+
+ /*
+* Our fundamental assumption is that running at lower frequency
+* actually saves power. Let's see if our RAPL measurement supports
+* that theory.
+*/
+ if (!librapl_supported(gt->i915))
+ return 0;
+
+ min.freq = slpc->min_freq;
+ err = measure_power_at_freq(gt, , );
+
+ if (err)
+ return err;
+
+ max.freq = slpc->rp0_freq;
+ err = measure_power_at_freq(gt, , );
+
+ if (err)
+ return err;
+
+ pr_info("%s: min:%llumW @ %uMHz, max:%llumW @ %uMHz\n",
+ engine->name,
+ min.power, min.freq,
+ max.power, max.freq);
+
+ if (10 * min.freq >= 9 * max.freq) {
+ pr_notice("Could not control frequency, ran at [%uMHz,
%uMhz]\n",
+ min.freq, max.freq);
+ }
+
+ if (11 * min.power > 10 * max.power) {
+ pr_err("%s: did not conserve power when setting lower
frequency!\n",
+ engine->name);
+ err = -EINVAL;
+ }
+
+ /* Restore min/max frequencies */
+ slpc_set_max_freq(slpc, slpc->rp0_freq);
+ slpc_set_min_freq(slpc, slpc->min_freq);
+
+ return err;
+}
+
static int max_granted_freq(struct intel_guc_slpc *slpc, struct intel_rps
*rps, u32 *max_act_freq)
{
struct intel_gt *gt = rps_to_gt(rps);
@@ -233,17 +319,23 @@ static int run_test(struct intel_gt *gt, int test_type)
err = max_granted_freq(slpc, rps, _act_freq);
break;
+
+ case SLPC_POWER:
+ err = slpc_power(gt, engine);
+ break;
}
- pr_info("Max actual frequency for %s was %d\n",
- engine->name, max_act_freq);
+ if (test_type != SLPC_POWER) {
+ pr_info("Max actual frequency for %s was %d\n",
+ engine->name, max_act_freq);
- /* Actual frequency should rise above min */
- if (max_act_freq <= slpc_min_freq) {
- pr_err("Actual freq did not rise above min\n");
- pr_err("Perf Limit Reasons: 0x%x\n",
- intel_uncore_read(gt->uncore,
GT0_PERF_LIMIT_REASONS));
- err = -EINVAL;
+ /* Actual frequency should rise above min */
+ if (max_act_freq <= slpc_min_freq) {
+ pr_err("Actual freq did not rise above min\n");
+ pr_err("Perf Limit Reasons: 0x%x\n",
+
[Intel-gfx] [PATCH 0/3] Add SLPC selftest live_slpc_power
live_slpc_power tests if running at low frequency saves power Rev2 : Add multi-tile support Riana Tauro (3): drm/i915/guc/slpc: Run SLPC selftests on all tiles drm/i915/selftests: Add helper function measure_power drm/i915/guc/slpc: Add SLPC selftest live_slpc_power drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 172 +--- 2 files changed, 164 insertions(+), 20 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.
Based on code from Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/i915_drv.h| 9 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
* HuC-specific commands.
*/
+static bool vcs_supported(struct intel_gt *gt)
+{
+ intel_engine_mask_t mask = gt->info.engine_mask;
+
+ /*
+* we can reach here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence fall back to the device info's
+* engine mask
+*/
+ if (!mask && gt_is_root(gt))
+ mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
Is it possible for all instances to be fused off? Wondering if the
function shouldn't just use platform_engine_mask.
Regards,
Tvrtko
+
+ return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+ struct intel_gt *gt = huc_to_gt(huc);
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+ if (!vcs_supported(gt)) {
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+ return;
+ }
+
if (GRAPHICS_VER(i915) >= 11) {
huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
#define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
-#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({ \
unsigned int first__ = (first); \
unsigned int count__ = (count); \
- ((gt)->info.engine_mask &
\
-GENMASK(first__ + count__ - 1, first__)) >> first__; \
+ ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__;\
})
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+ __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
#define RCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
#define BCS_MASK(gt) \
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/108945/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/108945/
State : warning
== Summary ==
Error: dim checkpatch failed
c7e564bf76cd overflow: Allow mixed type arguments
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
[2]
https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong@intel.com
-:137: CHECK:SPACING: No space is necessary after a cast
#137: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t) DEFINE_TEST_ARRAY_TYPED(t, t, t)
-:137: CHECK:MACRO_ARG_REUSE: Macro argument reuse 't' - possible side-effects?
#137: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t) DEFINE_TEST_ARRAY_TYPED(t, t, t)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fmt' - possible
side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro
side-effect!\n"); \
+ KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro
side-effect!\n"); \
} while (0)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'sym' - possible
side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro
side-effect!\n"); \
+ KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro
side-effect!\n"); \
} while (0)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'a' - possible side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ##
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove flush_scheduled_work() from live_execlists
Reviewed-by: Nirmoy Das
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.
Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync with the execlists capture state handling, but that is
not strictly required for the test to function and can be removed.
Signed-off-by: Tvrtko Ursulin
Cc: Tetsuo Handa
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 09f8cd2d0e2c..e62d089257ae 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -85,8 +85,6 @@ static int wait_for_reset(struct intel_engine_cs *engine,
break;
} while (time_before(jiffies, timeout));
- flush_scheduled_work();
-
if (rq->fence.error != -EIO) {
pr_err("%s: hanging request %llx:%lld not reset\n",
engine->name,
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Hi
Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
On 9/23/22 11:15, Thomas Zimmermann wrote:
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
*client, int mode)
return ret;
}
EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
I strongly dislike this style of including source files in each other.
It's a recipe for all kind of build errors. Can you do something else?
This seems to be the convention used to test static functions and what's
documented in the Kunit docs:
https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
That document says "...one option is to conditionally #include the test
file...". This doesn't sound like a strong requirement.
I agree with you that's not ideal but I think that consistency with how
it is done by other subsystems is also important.
As the tested function is an internal interface, maybe export a wrapper
if tests are enabled, like this:
#ifdef CONFIG_DRM_KUNIT_TEST
struct drm_display_mode *
drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
{
return drm_connector_pick_cmdline_mode(connector)
}
EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
#endif
The wrapper's declaration can be located in the kunit test file.
But that's also not nice since we are artificially exposing these only
to allow the static functions to be called from unit tests. And would
be a different approach than the one used by all other subsystems...
There's the problem of interference between the source files when
building the code. It's also not the same source code after including
the test file. At a minimum, including the tests' source file further
includes more files. also includes quite a few of Linux
header files.
IMHO the current convention (if any) is far from optimal and we should
consider breaking it.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset
On Fri, Sep 23, 2022 at 12:52:48PM +0300, Jani Nikula wrote: > On Wed, 21 Sep 2022, Balasubramani Vivekanandan > wrote: > > Display DDI ports are enumerated as PORT_A,PORT_B... . The enums are > > also used as an index to access the DDI_BUF_CTL register for the port. > > > > With the introduction of TypeC ports, new enums PORT_TC1,PORT_TC2.. were > > added starting from enum value 4 to match the index position of the > > DDI_BUF_CTL register of those ports. Because those early platforms had > > only 3 non-TypeC ports PORT_A,PORT_B, PORT_C followed by TypeC ports. > > So the enums PORT_D,PORT_E.. and PORT_TC1,PORT_TC2.. used the same enum > > values. > > > > Driver also used the condition `if (port > PORT_TC1)` to identify if a > > port is a TypeC port or non-TypeC. > > > > From XELPD, additional non-TypeC ports were added in the platform > > calling them as PORT D, PORT E and the DDI registers for those ports > > were positioned after TypeC ports. So the enums PORT_D and PORT_E can't > > be used as their values do not match with register position. It led to > > creating new enums PORT_D_XELPD, PORT_E_XELPD for ports D and E. > > > > The condition `if (port > PORT_TC1)` was no more valid for XELPD to > > identify a TypeC port. Also it led to many additional special checks for > > ports PORT_D_XELPD/PORT_E_XELPD. > > > > With new platforms indicating that the DDI register positions of ports > > can vary across platforms it makes no more feasible to maintain the port > > enum values to match the DDI register position. > > > > Port DDI register position is now maintained in a separate datastructure > > part of the platform device info and ports are enumerated independently. > > With enums for TypeC ports defined at the bottom, driver can easily > > identify the TypeC ports. > > > > Removed a WARN_ON as it is no longer valid. The WARN was added in > > commit - "327f8d8c336d drm/i915: simplify setting of ddi_io_power_domain" > > The ddi_io_power_domain calculation has changed completely since the > > commit and doesn't need this WARN_ON anymore. > > > > Signed-off-by: Balasubramani Vivekanandan > > > > I agree with the premise that defining platform specific port enums such > as PORT_D_XELPD to tackle differences in register offsets is handling > the problem at the wrong abstraction level. > > I am not (at least not yet) convinced with the approach of adding > platform specific mappings in .display.ddi_offsets. The main problem I > have with that is adding yet another way to deal with different register > offsets. We already have many, and adding a new one isn't appealing. > > Not that this *is* different from .display.pipe_offsets and > .display.trans_offsets which are actual *offsets*. The solution here is > actually misnamed; it's about indexes, not offsets. > > Finally, even if we were to choose this approach, this should be split > to at least three separate patches. First, pass i915 to the register > macro, no other changes, totally non-functional. Second, use the > indexes. Third, remove PORT_D_XELPD etc. > > I'm still considering alternatives. In the mean time, please find some > random comments on the details inline. One of the earlier alternatives proposed was some kind of declarative struct to describe each port, which would include separate indexes needed for different things (among information on the type of DDI/PHY/etc.) I think there was some attempt at something like that, but IIRC it tried to do a bunch of other stuff too so it got bikeshedded to death. I guess one key question is: Do we need to freestanding DDI/AUX/etc. register accesses or can we assume the encoder struct is always there? That would dictate whether we need any magic in the register macros at all, or whether we can just trust the caller to pass in the right index. Oh, and the other key question is: Is an index enough, or are the register offsets going to get really random at some point? So far I'm not aware of any changes the status-quo in the forseeable future, so not really seeing this part as super urgent compared to the whole PHY mess, which has been much more volatile in recent times. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
Hi Am 23.09.22 um 11:18 schrieb Jani Nikula: On Fri, 23 Sep 2022, Thomas Zimmermann wrote: Am 22.09.22 um 16:25 schrieb Maxime Ripard: + drm_dbg_kms(dev, + "Generating a %ux%u%c, %u-line mode with a %lu kHz clock\n", + hactive, vactive, + interlace ? 'i' : 'p', + params->num_lines, + pixel_clock_hz / 1000); Divide by HZ_PER_KHZ here and in other places. https://elixir.bootlin.com/linux/latest/source/include/linux/units.h#L23 From the Department of Bikeshedding: I find "pixel_clock_hz / 1000" has much more clarity than "pixel_clock_hz / HZ_PER_KHZ". This one's easy to see because it tells you with the _hz postfix. Many places don't and then it quickly gets confusing what units the code's converting. Best regards Thomas I don't consider the SI prefixes magic numbers. BR, Jani. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset
On Wed, 21 Sep 2022, Balasubramani Vivekanandan
wrote:
> Display DDI ports are enumerated as PORT_A,PORT_B... . The enums are
> also used as an index to access the DDI_BUF_CTL register for the port.
>
> With the introduction of TypeC ports, new enums PORT_TC1,PORT_TC2.. were
> added starting from enum value 4 to match the index position of the
> DDI_BUF_CTL register of those ports. Because those early platforms had
> only 3 non-TypeC ports PORT_A,PORT_B, PORT_C followed by TypeC ports.
> So the enums PORT_D,PORT_E.. and PORT_TC1,PORT_TC2.. used the same enum
> values.
>
> Driver also used the condition `if (port > PORT_TC1)` to identify if a
> port is a TypeC port or non-TypeC.
>
> From XELPD, additional non-TypeC ports were added in the platform
> calling them as PORT D, PORT E and the DDI registers for those ports
> were positioned after TypeC ports. So the enums PORT_D and PORT_E can't
> be used as their values do not match with register position. It led to
> creating new enums PORT_D_XELPD, PORT_E_XELPD for ports D and E.
>
> The condition `if (port > PORT_TC1)` was no more valid for XELPD to
> identify a TypeC port. Also it led to many additional special checks for
> ports PORT_D_XELPD/PORT_E_XELPD.
>
> With new platforms indicating that the DDI register positions of ports
> can vary across platforms it makes no more feasible to maintain the port
> enum values to match the DDI register position.
>
> Port DDI register position is now maintained in a separate datastructure
> part of the platform device info and ports are enumerated independently.
> With enums for TypeC ports defined at the bottom, driver can easily
> identify the TypeC ports.
>
> Removed a WARN_ON as it is no longer valid. The WARN was added in
> commit - "327f8d8c336d drm/i915: simplify setting of ddi_io_power_domain"
> The ddi_io_power_domain calculation has changed completely since the
> commit and doesn't need this WARN_ON anymore.
>
> Signed-off-by: Balasubramani Vivekanandan
>
I agree with the premise that defining platform specific port enums such
as PORT_D_XELPD to tackle differences in register offsets is handling
the problem at the wrong abstraction level.
I am not (at least not yet) convinced with the approach of adding
platform specific mappings in .display.ddi_offsets. The main problem I
have with that is adding yet another way to deal with different register
offsets. We already have many, and adding a new one isn't appealing.
Not that this *is* different from .display.pipe_offsets and
.display.trans_offsets which are actual *offsets*. The solution here is
actually misnamed; it's about indexes, not offsets.
Finally, even if we were to choose this approach, this should be split
to at least three separate patches. First, pass i915 to the register
macro, no other changes, totally non-functional. Second, use the
indexes. Third, remove PORT_D_XELPD etc.
I'm still considering alternatives. In the mean time, please find some
random comments on the details inline.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 12 ++--
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 63 +++---
> drivers/gpu/drm/i915/display/intel_display.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 8 +--
> .../drm/i915/display/intel_display_power.c| 40 +--
> drivers/gpu/drm/i915/display/intel_fdi.c | 14 ++--
> drivers/gpu/drm/i915/display/intel_tc.c | 6 +-
> drivers/gpu/drm/i915/gvt/display.c| 30 -
> drivers/gpu/drm/i915/gvt/handlers.c | 17 +++--
> drivers/gpu/drm/i915/i915_pci.c | 66 ---
> drivers/gpu/drm/i915/i915_reg.h | 8 ++-
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 10 +--
> include/drm/i915_component.h | 2 +-
> 15 files changed, 144 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ed4d93942dbd..70098b67149b 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -548,11 +548,11 @@ static void gen11_dsi_enable_ddi_buffer(struct
> intel_encoder *encoder)
> enum port port;
>
> for_each_dsi_port(port, intel_dsi->ports) {
> - tmp = intel_de_read(dev_priv, DDI_BUF_CTL(port));
> + tmp = intel_de_read(dev_priv, DDI_BUF_CTL(dev_priv, port));
> tmp |= DDI_BUF_CTL_ENABLE;
> - intel_de_write(dev_priv, DDI_BUF_CTL(port), tmp);
> + intel_de_write(dev_priv, DDI_BUF_CTL(dev_priv, port), tmp);
>
> - if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
> + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(dev_priv,
> port)) &
> DDI_BUF_IS_IDLE),
>
Re: [Intel-gfx] [bug report] drm/i915/guc: Implement multi-lrc submission
On Thu, Sep 22, 2022 at 01:01:48PM -0700, John Harrison wrote:
> On 9/22/2022 07:26, Dan Carpenter wrote:
> > Hello Matthew Brost,
> >
> > The patch 6b540bf6f143: "drm/i915/guc: Implement multi-lrc
> > submission" from Oct 14, 2021, leads to the following Smatch static
> > checker warning:
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:752
> > __guc_add_request()
> > warn: refcount leak 'ce->ref.refcount.refs.counter': lines='752'
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > 672 static int __guc_add_request(struct intel_guc *guc, struct
> > i915_request *rq)
> > 673 {
> > 674 int err = 0;
> > 675 struct intel_context *ce =
> > request_to_scheduling_context(rq);
> > 676 u32 action[3];
> > 677 int len = 0;
> > 678 u32 g2h_len_dw = 0;
> > 679 bool enabled;
> > 680
> > 681 lockdep_assert_held(>engine->sched_engine->lock);
> > 682
> > 683 /*
> > 684 * Corner case where requests were sitting in the priority
> > list or a
> > 685 * request resubmitted after the context was banned.
> > 686 */
> > 687 if (unlikely(intel_context_is_banned(ce))) {
> > 688 i915_request_put(i915_request_mark_eio(rq));
> > 689 intel_engine_signal_breadcrumbs(ce->engine);
> > 690 return 0;
> > 691 }
> > 692
> > 693 GEM_BUG_ON(!atomic_read(>guc_id.ref));
> > 694 GEM_BUG_ON(context_guc_id_invalid(ce));
> > 695
> > 696 if (context_policy_required(ce)) {
> > 697 err = guc_context_policy_init_v70(ce, false);
> > 698 if (err)
> > 699 return err;
> > 700 }
> > 701
> > 702 spin_lock(>guc_state.lock);
> > 703
> > 704 /*
> > 705 * The request / context will be run on the hardware when
> > scheduling
> > 706 * gets enabled in the unblock. For multi-lrc we still
> > submit the
> > 707 * context to move the LRC tails.
> > 708 */
> > 709 if (unlikely(context_blocked(ce) &&
> > !intel_context_is_parent(ce)))
> > 710 goto out;
> > 711
> > 712 enabled = context_enabled(ce) || context_blocked(ce);
> > 713
> > 714 if (!enabled) {
> > 715 action[len++] =
> > INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET;
> > 716 action[len++] = ce->guc_id.id;
> > 717 action[len++] = GUC_CONTEXT_ENABLE;
> > 718 set_context_pending_enable(ce);
> > 719 intel_context_get(ce);
> > 720 g2h_len_dw = G2H_LEN_DW_SCHED_CONTEXT_MODE_SET;
> > 721 } else {
> > 722 action[len++] = INTEL_GUC_ACTION_SCHED_CONTEXT;
> > 723 action[len++] = ce->guc_id.id;
> > 724 }
> > 725
> > 726 err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
> > 727 if (!enabled && !err) {
> > 728 trace_intel_context_sched_enable(ce);
> > 729 atomic_inc(>outstanding_submission_g2h);
> > 730 set_context_enabled(ce);
> > 731
> > 732 /*
> > 733 * Without multi-lrc KMD does the submission step
> > (moving the
> > 734 * lrc tail) so enabling scheduling is sufficient
> > to submit the
> > 735 * context. This isn't the case in multi-lrc
> > submission as the
> > 736 * GuC needs to move the tails, hence the need for
> > another H2G
> > 737 * to submit a multi-lrc context after enabling
> > scheduling.
> > 738 */
> > 739 if (intel_context_is_parent(ce)) {
> > 740 action[0] = INTEL_GUC_ACTION_SCHED_CONTEXT;
> > 741 err = intel_guc_send_nb(guc, action, len -
> > 1, 0);
> >
> > Should this have a something like:
> >
> > if (err)
> > intel_context_put(ce);
> No.
>
> The ce has been marked as enabled above because the actual enable call
> succeeded.? This is a secondary call to 'poke' the context. If this fails,
> the context might not get scheduled in a timely manner but the tracking
> state is still correct. The context is now in use by GuC and therefore must
> be reference locked. And the 'context_enabled' flag is set on the i915 side
> to note that the reference count is held.
>
> If you want to unwind at this point, you would need to send a
> CONTEXT_MODE_SET(DISABLE) H2G message (amongst other things) and only once
> that call has completed, can you call
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On 9/23/22 11:15, Thomas Zimmermann wrote:
> Hi
>
> Am 22.09.22 um 16:25 schrieb Maxime Ripard:
>> drm_connector_pick_cmdline_mode() is in charge of finding a proper
>> drm_display_mode from the definition we got in the video= command line
>> argument.
>>
>> Let's add some unit tests to make sure we're not getting any regressions
>> there.
>>
>> Signed-off-by: Maxime Ripard
>>
>> diff --git a/drivers/gpu/drm/drm_client_modeset.c
>> b/drivers/gpu/drm/drm_client_modeset.c
>> index bbc535cc50dd..d553e793e673 100644
>> --- a/drivers/gpu/drm/drm_client_modeset.c
>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
>> *client, int mode)
>> return ret;
>> }
>> EXPORT_SYMBOL(drm_client_modeset_dpms);
>> +
>> +#ifdef CONFIG_DRM_KUNIT_TEST
>> +#include "tests/drm_client_modeset_test.c"
>> +#endif
>
> I strongly dislike this style of including source files in each other.
> It's a recipe for all kind of build errors. Can you do something else?
>
This seems to be the convention used to test static functions and what's
documented in the Kunit docs:
https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
I agree with you that's not ideal but I think that consistency with how
it is done by other subsystems is also important.
> As the tested function is an internal interface, maybe export a wrapper
> if tests are enabled, like this:
>
> #ifdef CONFIG_DRM_KUNIT_TEST
> struct drm_display_mode *
> drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
> {
>return drm_connector_pick_cmdline_mode(connector)
> }
> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
> #endif
>
> The wrapper's declaration can be located in the kunit test file.
>
But that's also not nice since we are artificially exposing these only
to allow the static functions to be called from unit tests. And would
be a different approach than the one used by all other subsystems...
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [PATCH 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On Thu, 22 Sep 2022, Daniele Ceraolo Spurio
wrote:
> From: Aravind Iddamsetty
>
> With MTL standalone media architecture the wopcm layout has changed with
> separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
> of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.
>
> +=+===> ++ <== WOPCM TOP
> ^ ^ ||
> | | ||
> |GCD| GCD RC6 Image|
> |GuC|Power Context |
> |WOPCM ||
> |Size ++
> | | | GCD GuC Image|
> | | ||
> | v ||
> | +===> ++ <== SA Media GuC WOPCM Top
> | ^ ||
> | SA Media||
> |GuC| SA Media RC6 Image |
> | WOPCM |Power Context |
> |Size ||
> WOPCM | ++
> | | ||
> | | | SA Media GuC Image |
> | v ||
> | +===> ++ <== GuC WOPCM base
> | | WOPCM RSVD |
> | +--- + <== HuC Firmware Top
> v | HuC FW|
> +=> ++ <== WOPCM Base
>
> Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
> by the bios. Therefore, we can skip all the math for the partitioning
> and just limit ourselves to sanity checking the values.
>
> Signed-off-by: Aravind Iddamsetty
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> Cc: John Harrison
> Cc: Alan Previn
> ---
> drivers/gpu/drm/i915/Makefile | 7 +--
> drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
> drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
> drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
> drivers/gpu/drm/i915/i915_driver.c | 2 -
> drivers/gpu/drm/i915/i915_drv.h | 3 --
> drivers/gpu/drm/i915/i915_gem.c | 5 ++-
> 11 files changed, 56 insertions(+), 32 deletions(-)
> rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
> rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index a26edcdadc21..6ed4c745b226 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -129,7 +129,9 @@ gt-y += \
> gt/intel_timeline.o \
> gt/intel_workarounds.o \
> gt/shmem_utils.o \
> - gt/sysfs_engines.o
> + gt/sysfs_engines.o \
> + gt/intel_wopcm.o
The comment near the top of the file:
# Please keep these build lists sorted!
> +
> # x86 intel-gtt module support
> gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
> # autogenerated null render state
> @@ -183,8 +185,7 @@ i915-y += \
> i915_trace_points.o \
> i915_ttm_buddy_manager.o \
> i915_vma.o \
> - i915_vma_resource.o \
> - intel_wopcm.o
> + i915_vma_resource.o
>
> # general-purpose microcontroller (GuC) support
> i915-y += gt/uc/intel_uc.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 30cf5c3369d9..605e1aa674d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
>* why.
>*/
> ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
> -intel_wopcm_guc_size(>vm.i915->wopcm));
> +intel_wopcm_guc_size(>vm.gt->wopcm));
>
> ret = intel_vgt_balloon(ggtt);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index b367cfff48d5..a95eb0b656d2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
> seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
> intel_gt_pm_init_early(gt);
>
> + intel_wopcm_init_early(>wopcm);
> intel_uc_init_early(>uc);
> intel_rps_init_early(>rps);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index f19c2de77ff6..c20a32d2700f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -30,6 +30,7 @@
> #include "intel_migrate_types.h"
> #include "intel_wakeref.h"
> #include "pxp/intel_pxp_types.h"
> +#include "intel_wopcm.h"
>
> struct drm_i915_private;
> struct
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: prepare for uC loading on MTL
== Series Details == Series: drm/i915: prepare for uC loading on MTL URL : https://patchwork.freedesktop.org/series/108925/ State : success == Summary == CI Bug Log - changes from CI_DRM_12168_full -> Patchwork_108925v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108925v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][2] ([i915#2842]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> [SKIP][5] ([fdo#109313]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_lmem_swapping@basic: - shard-iclb: NOTRUN -> [SKIP][6] ([i915#4613]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gem_lmem_swapp...@basic.html * igt@gem_pxp@create-regular-context-1: - shard-iclb: NOTRUN -> [SKIP][7] ([i915#4270]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_...@create-regular-context-1.html * igt@gem_render_copy@y-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][8] ([i915#768]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_render_c...@y-tiled-to-vebox-linear.html * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_soft...@evict-snoop-interruptible.html * igt@gem_userptr_blits@coherency-unsync: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#3297]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_userptr_bl...@coherency-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#3318]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_linear_blits: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109289]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gen3_render_linear_blits.html * igt@gen9_exec_parse@bb-start-param: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gen9_exec_pa...@bb-start-param.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#658]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#3989] / [i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-iclb6/igt@i915_pm...@dc6-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110892]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@i915_pm_...@modeset-non-lpsp.html * igt@i915_selftest@live@gt_heartbeat: - shard-glk: [PASS][18] -> [DMESG-FAIL][19] ([i915#5334]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-glk7/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_big_fb@4-tiled-8bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#5286]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@kms_big...@4-tiled-8bpp-rotate-180.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: -
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
On Fri, 23 Sep 2022, Thomas Zimmermann wrote: > Am 22.09.22 um 16:25 schrieb Maxime Ripard: >> +drm_dbg_kms(dev, >> +"Generating a %ux%u%c, %u-line mode with a %lu kHz clock\n", >> +hactive, vactive, >> +interlace ? 'i' : 'p', >> +params->num_lines, >> +pixel_clock_hz / 1000); > > Divide by HZ_PER_KHZ here and in other places. > >https://elixir.bootlin.com/linux/latest/source/include/linux/units.h#L23 >From the Department of Bikeshedding: I find "pixel_clock_hz / 1000" has much more clarity than "pixel_clock_hz / HZ_PER_KHZ". I don't consider the SI prefixes magic numbers. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
*client, int mode)
return ret;
}
EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
I strongly dislike this style of including source files in each other.
It's a recipe for all kind of build errors. Can you do something else?
As the tested function is an internal interface, maybe export a wrapper
if tests are enabled, like this:
#ifdef CONFIG_DRM_KUNIT_TEST
struct drm_display_mode *
drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
{
return drm_connector_pick_cmdline_mode(connector)
}
EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
#endif
The wrapper's declaration can be located in the kunit test file.
Best regards
Thomas
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
new file mode 100644
index ..46335de7bc6b
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm_kunit_helpers.h"
+
+struct drm_client_modeset_test_priv {
+ struct drm_device *drm;
+ struct drm_connector connector;
+};
+
+static int drm_client_modeset_connector_get_modes(struct drm_connector
*connector)
+{
+ struct drm_display_mode *mode;
+ int count;
+
+ count = drm_add_modes_noedid(connector, 1920, 1200);
+
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
drm_client_modeset_connector_helper_funcs = {
+ .get_modes = drm_client_modeset_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_client_modeset_connector_funcs = {
+};
+
+static int drm_client_modeset_test_init(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ test->priv = priv;
+
+ priv->drm = drm_kunit_device_init("drm-client-modeset-test");
+ if (IS_ERR(priv->drm))
+ return PTR_ERR(priv->drm);
+
+ ret = drmm_connector_init(priv->drm, >connector,
+ _client_modeset_connector_funcs,
+ DRM_MODE_CONNECTOR_Unknown,
+ NULL);
+ if (ret)
+ return ret;
+ drm_connector_helper_add(>connector,
_client_modeset_connector_helper_funcs);
+
+ return 0;
+}
+
+static void drm_client_modeset_test_exit(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+
+ drm_kunit_device_exit(priv->drm);
+}
+
+static void drm_pick_cmdline_res_1920_1080_60(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = >connector;
+ struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+ struct drm_display_mode *expected_mode, *mode;
+ const char *cmdline = "1920x1080@60";
+ int ret;
+
+ expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+ KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(>mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(>mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_pick_cmdline_tests[] = {
+ KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
+ {}
+};
+
+static struct kunit_suite drm_pick_cmdline_test_suite = {
+ .name = "drm_pick_cmdline",
+ .init = drm_client_modeset_test_init,
+ .exit = drm_client_modeset_test_exit,
+ .test_cases = drm_pick_cmdline_tests
+};
+
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..76ab700f56ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_probed_add);
+enum drm_mode_analog {
+ DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
+ DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
+};
+
+/*
+ * The timings come from:
+ * -
https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
+ * -
https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
+ * -
https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
+ */
+#define NTSC_LINE_DURATION_NS 63556U
+#define NTSC_LINES_NUMBER 525
+
+#define NTSC_HBLK_DURATION_TYP_NS 10900U
+#define NTSC_HBLK_DURATION_MIN_NS (NTSC_HBLK_DURATION_TYP_NS - 200)
+#define NTSC_HBLK_DURATION_MAX_NS (NTSC_HBLK_DURATION_TYP_NS + 200)
+
+#define NTSC_HACT_DURATION_TYP_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_TYP_NS)
+#define NTSC_HACT_DURATION_MIN_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MAX_NS)
+#define NTSC_HACT_DURATION_MAX_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MIN_NS)
+
+#define NTSC_HFP_DURATION_TYP_NS 1500
+#define NTSC_HFP_DURATION_MIN_NS 1270
+#define NTSC_HFP_DURATION_MAX_NS 2220
+
+#define NTSC_HSLEN_DURATION_TYP_NS 4700
+#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
+#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
+
+#define NTSC_HBP_DURATION_TYP_NS 4700
+
+/*
+ * I couldn't find the actual tolerance for the back porch, so let's
+ * just reuse the sync length ones.
+ */
+#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
+#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
+
+#define PAL_LINE_DURATION_NS 64000U
+#define PAL_LINES_NUMBER 625
+
+#define PAL_HACT_DURATION_TYP_NS 51950U
+#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
+#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
+
+#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_TYP_NS)
+#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MAX_NS)
+#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MIN_NS)
+
+#define PAL_HFP_DURATION_TYP_NS1650
+#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
+#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
+
+#define PAL_HSLEN_DURATION_TYP_NS 4700
+#define PAL_HSLEN_DURATION_MIN_NS (PAL_HSLEN_DURATION_TYP_NS - 200)
+#define PAL_HSLEN_DURATION_MAX_NS (PAL_HSLEN_DURATION_TYP_NS + 200)
+
+#define PAL_HBP_DURATION_TYP_NS5700
+#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
+#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
+
+struct analog_param_field {
+ unsigned int even, odd;
+};
+
+#define PARAM_FIELD(_odd, _even) \
+ { .even = _even, .odd = _odd }
+
+struct analog_param_range {
+ unsigned intmin, typ, max;
+};
+
+#define PARAM_RANGE(_min, _typ, _max) \
+ { .min = _min, .typ = _typ, .max = _max }
+
+struct analog_parameters {
+ unsigned intnum_lines;
+ unsigned intline_duration_ns;
+
+ struct analog_param_range hact_ns;
+ struct analog_param_range hfp_ns;
+ struct analog_param_range hslen_ns;
+ struct analog_param_range hbp_ns;
+ struct analog_param_range hblk_ns;
+
+ unsigned intbt601_hfp;
+
+ struct analog_param_field vfp_lines;
+ struct analog_param_field vslen_lines;
+ struct analog_param_field vbp_lines;
+};
+
+#define TV_MODE_PARAMETER(_mode, _lines, _line_dur, _hact, _hfp, _hslen, _hbp,
_hblk, _bt601_hfp, _vfp, _vslen, _vbp) \
+ [_mode] = { \
+ .num_lines = _lines,
