Re: [Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power

[Gupta, Anshuman]

On 9/22/2022 8:47 AM, Dixit, Ashutosh wrote:

On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote:




Hi Anshuman,


diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55c35903adca..956e5298ef1e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6644,6 +6644,12 @@
   #define   DG1_PCODE_STATUS   0x7E
   #define DG1_UNCORE_GET_INIT_STATUS   0x0
   #define DG1_UNCORE_INIT_STATUS_COMPLETE  0x1
+#define   PCODE_POWER_SETUP0x7C
+#define POWER_SETUP_SUBCOMMAND_READ_I1 0x4
+#define POWER_SETUP_SUBCOMMAND_WRITE_I10x5
+#definePOWER_SETUP_I1_WATTSREG_BIT(31)
+#definePOWER_SETUP_I1_SHIFT6   /* 10.6 fixed 
point format */

Could please add some comment to explain, why POWER_SETUP_I1_SHIFT  = 6,
what is excatly 10.6 fixed point format ?
With that.
Reviewed-by: Anshuman Gupta 


10.6 fixed point format means a 16 bit number is represented as x.y where x
are the top 10 bits and y are the bottom 6 bits. The float value of this 16
bit number is (x + (y / 2^6)), so (x + (y / 64)). For example the number
0x8008 will have the value (1 * 2^9 + 8 / 2^6) == 512.125. Note that the
hexadecimal number 0x8008 == 32776 and 512.125 == 32776 / 64 which is why
POWER_SETUP_I1_SHIFT is 6 (2^6 == 64).

Similarly, the 8.8 fixed point format is explained in
gt/intel_gt_sysfs_pm.c. Do you think this needs a comment? I thought "10.6
fixed point format" is a sufficient hint (fixed point numbers are fairly
well known).

An even trickier data format is in the patch "drm/i915/hwmon: Expose
power1_max_interval" in hwm_power1_max_interval_show() but I think I have a
long comment there.

Thanks for explaining this, i was unaware of fixed point representation.
My RB can can be used without any change.
Br,
Anshuman.



Thanks.
--
Ashutosh

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unused function parameter

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unused function parameter
URL   : https://patchwork.freedesktop.org/series/108863/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12166 -> Patchwork_108863v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/index.html

Participating hosts (45 -> 46)
--

  Additional (2): fi-icl-u2 fi-tgl-dsi 
  Missing(1): fi-bdw-samus 

Known issues


  Here are the changes found in Patchwork_108863v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([fdo#111827]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([i915#4103])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/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][5] ([i915#6008])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([fdo#109285])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([i915#3555])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([fdo#109295] / [i915#3301])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-icl-u2/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][9] ([i915#4312])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][12] ([i915#5334]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
- fi-glk-j4005:   [DMESG-FAIL][14] ([i915#5334]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-rpls-1}:   [INCOMPLETE][16] -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-dp-2:
- {bat-dg2-11}:   [FAIL][18] ([i915#6818]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-2.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-2.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  

Re: [Intel-gfx] [PATCH v3 15/15] vfio: Add struct device to vfio_device

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Thursday, September 22, 2022 12:10 AM
> 
> On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote:
> > > From: Alex Williamson 
> > > Sent: Wednesday, September 21, 2022 4:27 AM
> > >
> > > On Fri,  9 Sep 2022 18:22:47 +0800
> > > Kevin Tian  wrote:
> > >
> > > > From: Yi Liu 
> > > >
> > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > > > sysfs path of the parent, indicating the device is bound to a vfio
> > > > driver, e.g.:
> > > >
> > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
> > > >
> > > > It is also a preparatory step toward adding cdev for supporting future
> > > > device-oriented uAPI.
> > > >
> > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
> > > >
> > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in
> > > > /proc/devices.
> > >
> > > What's the risk/reward here, is this just more aesthetically pleasing
> > > symmetry vs 'vfio-dev'?  The char major number to name association in
> > > /proc/devices seems pretty obscure, but what due diligence have we
> done
> > > to make sure this doesn't break anyone?  Thanks,
> >
> > I'm not sure whether the content of /proc/devices is considered as ABI.
> >
> > @Jason?
> 
> Ah, I've forgotten why we got here - didn't we have a naming conflict
> with the new stuff that is being introduced?

No, we don't have. There is no new char dev introduced in this series.

Later when device cdev is added a new device major will be allocated for
'vfio-dev'. It's at that time renaming existing 'vfio' to 'vfio-group' is 
probably
clearer, which is what I understood from your earlier suggestion.

> 
> ABI wise it is not a problem unless there is a real user, I'm not
> aware of anything scanning /proc, that has been obsoleted by sysfs a
> long time ago.
> 

This is a good news.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove unused function parameter

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unused function parameter
URL   : https://patchwork.freedesktop.org/series/108863/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH] drm/i915: Remove unused function parameter

[Niranjana Vishwanathapura]

The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.

Signed-off-by: Niranjana Vishwanathapura 
---
 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 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode

[Dixit, Ashutosh]

On Mon, 19 Sep 2022 20:22:40 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 15 Sep 2022 15:49:27 -0700, Umesh Nerlige Ramappa wrote:
> >
> > On Wed, Sep 14, 2022 at 04:13:41PM -0700, Umesh Nerlige Ramappa wrote:
> > > On Wed, Sep 14, 2022 at 03:26:15PM -0700, Umesh Nerlige Ramappa wrote:
> > >> On Tue, Sep 06, 2022 at 09:39:33PM +0300, Lionel Landwerlin wrote:
> > >>> On 06/09/2022 20:39, Umesh Nerlige Ramappa wrote:
> >  On Tue, Sep 06, 2022 at 05:33:00PM +0300, Lionel Landwerlin wrote:
> > > On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
> > >> 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.
> > >>
> > >> Signed-off-by: Umesh Nerlige Ramappa 
> > >> 
> > >
> > >
> > > I assume you checked with GuC that this doesn't change as the context
> > > is running?
> > 
> >  Correct.
> > 
> > >
> > > With i915/execlist submission mode, we had to ask i915 to pin the
> > > sw_id/ctx_id.
> > >
> > 
> >  From GuC perspective, the context id can change once KMD de-registers
> >  the context and that will not happen while the context is in use.
> > 
> >  Thanks,
> >  Umesh
> > >>>
> > >>>
> > >>> Thanks Umesh,
> > >>>
> > >>>
> > >>> Maybe I should have been more precise in my question :
> > >>>
> > >>>
> > >>> Can the ID change while the i915-perf stream is opened?
> > >>>
> > >>> Because the ID not changing while the context is running makes sense.
> > >>>
> > >>> But since the number of available IDs is limited to 2k or something on
> > >>> Gfx12, it's possible the GuC has to reuse IDs if too many apps want to
> > >>> run during the period of time while i915-perf is active and filtering.
> > >>>
> > >>
> > >> available guc ids are 64k with 4k reserved for multi-lrc, so GuC may
> > >> have to reuse ids once 60k ids are used up.
> > >
> > > Spoke to the GuC team again and if there are a lot of contexts (> 60K)
> > > running, there is a possibility of the context id being recycled. In that
> > > case, the capture would be broken. I would track this as a separate JIRA
> > > and follow up on a solution.
> > >
> > > From OA use case perspective, are we interested in monitoring just one
> > > hardware context? If we make sure this context is not stolen, are we
> > > good?
> > >
> >
> > + John
> >
> > Based on John's inputs - if a context is pinned, then KMD does not steal
> > it's id. It would just look for something else or wait for a context to be
> > available (pin count 0 I believe).
> >
> > Since we pin the context for the duration of the OA use case, we should be
> > good here.
>
> Since this appears to be true I am thinking of okay'ing this patch rather
> than define a new interface with GuC for this. Let me know if there are any
> objections about this.

With the above comments/assumptions this is:

Reviewed-by: Ashutosh Dixit 

Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode

[Dixit, Ashutosh]

On Wed, 21 Sep 2022 20:44:57 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 09 Sep 2022 16:47:36 -0700, Dixit, Ashutosh wrote:
> >
> > On Tue, 23 Aug 2022 13:41:37 -0700, Umesh Nerlige Ramappa wrote:
> > >
> > > +/*
> > > + * 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.
> > > + */
> > > +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) <<
> > > + (GEN11_SW_CTX_ID_SHIFT - 32);
> >
> > Previously I missed that these ctx_id's for non-GuC cases are just
> > constants. How does it work in these cases?
>
> For the record, offline reply from Umesh for this question:
>
> Looks like the SW context id is set to a unique value by the KMD for
> execlist mode here - __execlists_schedule_in() as ccid. Later it is written
> to the execlist port here (as lrc.desc) - execlists_submit_ports(). It's
> just a unique value that the kmd determines. For OA we are setting a
> ce->tag when OA use case is active and it used by the
> __execlists_schedule_in().
>
> Related commit from Chris - 2935ed5339c49
>
> I think the reason why OA is setting it is because this value is not
> assigned until __execlists_schedule_in() is called. For OA context, this
> may happen much later. The code that Chris has added, just assigns a value
> in OA and then uses it later in the __execlists_schedule_in() path.

I would still think this should not be a constant value but something which
depends on the context or the context id. Anyway since this is a
pre-existing issue not introducd in this patch, I will disregard this and
continue reviewing this patch.

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode

[Dixit, Ashutosh]

On Fri, 09 Sep 2022 16:47:36 -0700, Dixit, Ashutosh wrote:
>
> On Tue, 23 Aug 2022 13:41:37 -0700, Umesh Nerlige Ramappa wrote:
> >
> > +/*
> > + * 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.
> > + */
> > +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) <<
> > +   (GEN11_SW_CTX_ID_SHIFT - 32);
>
> Previously I missed that these ctx_id's for non-GuC cases are just
> constants. How does it work in these cases?

For the record, offline reply from Umesh for this question:

Looks like the SW context id is set to a unique value by the KMD for
execlist mode here - __execlists_schedule_in() as ccid. Later it is written
to the execlist port here (as lrc.desc) - execlists_submit_ports(). It's
just a unique value that the kmd determines. For OA we are setting a
ce->tag when OA use case is active and it used by the
__execlists_schedule_in().

Related commit from Chris - 2935ed5339c49

I think the reason why OA is setting it is because this value is not
assigned until __execlists_schedule_in() is called. For OA context, this
may happen much later. The code that Chris has added, just assigns a value
in OA and then uses it later in the __execlists_schedule_in() path.

Re: [Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power

[Dixit, Ashutosh]

On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote:
>

Hi Anshuman,

> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 55c35903adca..956e5298ef1e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6644,6 +6644,12 @@
> >   #define   DG1_PCODE_STATUS0x7E
> >   #define DG1_UNCORE_GET_INIT_STATUS0x0
> >   #define DG1_UNCORE_INIT_STATUS_COMPLETE   0x1
> > +#define   PCODE_POWER_SETUP0x7C
> > +#define POWER_SETUP_SUBCOMMAND_READ_I1 0x4
> > +#define POWER_SETUP_SUBCOMMAND_WRITE_I10x5
> > +#definePOWER_SETUP_I1_WATTSREG_BIT(31)
> > +#definePOWER_SETUP_I1_SHIFT6   /* 10.6 fixed 
> > point format */
> Could please add some comment to explain, why POWER_SETUP_I1_SHIFT  = 6,
> what is excatly 10.6 fixed point format ?
> With that.
> Reviewed-by: Anshuman Gupta 

10.6 fixed point format means a 16 bit number is represented as x.y where x
are the top 10 bits and y are the bottom 6 bits. The float value of this 16
bit number is (x + (y / 2^6)), so (x + (y / 64)). For example the number
0x8008 will have the value (1 * 2^9 + 8 / 2^6) == 512.125. Note that the
hexadecimal number 0x8008 == 32776 and 512.125 == 32776 / 64 which is why
POWER_SETUP_I1_SHIFT is 6 (2^6 == 64).

Similarly, the 8.8 fixed point format is explained in
gt/intel_gt_sysfs_pm.c. Do you think this needs a comment? I thought "10.6
fixed point format" is a sufficient hint (fixed point numbers are fairly
well known).

An even trickier data format is in the patch "drm/i915/hwmon: Expose
power1_max_interval" in hwm_power1_max_interval_show() but I think I have a
long comment there.

Thanks.
--
Ashutosh

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix TC port PLLs after readout

[Patchwork]

== Series Details ==

Series: drm/i915: Fix TC port PLLs after readout
URL   : https://patchwork.freedesktop.org/series/108847/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12166_full -> Patchwork_108847v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108847v1_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_cursor_crc@cursor-sliding-128x42:
- {shard-rkl}:NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-rkl-5/igt@kms_cursor_...@cursor-sliding-128x42.html

  
Known issues


  Here are the changes found in Patchwork_108847v1_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([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], [PASS][23], [PASS][24]) 
([i915#5032]) -> ([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])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl10/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl10/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/shard-skl10/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl5/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl4/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl4/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/shard-skl4/boot.html
   [39]: 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis

[Teres Alexis, Alan Previn]

On Fri, 2022-09-16 at 08:36 -0700, Ceraolo Spurio, Daniele wrote:
> 
> On 9/16/2022 1:58 AM, Tvrtko Ursulin wrote:
> > On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> > > > On 15/09/2022 03:12, Alan Previn wrote:
> > > > > 
> > > > 
alan: [snip]

> > > > IMO it creates less readable code for the benefit of not repeating
> > > > with_intel_runtime_pm -> __guc_context_sched_disable two times. Dunno..
> > > > it's ugly but I have no suggestions. Hm does it have to send using the
> > > > busy loop? It couldn't just queue the request and then wait for 
> > > > reply if
> > > > disable message was emitted?
> > > > 
> > > I agree that the above code lacks readability - will see if i can 
> > > break it down to smaller
> > > functions with cleaner in-function lock/unlock pairs. I agree that a 
> > > little code duplication
> > > is better than less readable code. It was inherited code i didn't 
> > > want to modify but I'll
> > > go ahead and refactor this.
> > > 
> > > On the busy loop - im assuming you are refering to the actual ct 
> > > sending. I'll consult my
> > > team if i am missing anything more but based on comments, I believe 
> > > callers must use that
> > > function to guarantee reservation of space in the G2H CTB to always 
> > > have space to capture
> > > responses for actions that MUST be acknowledged from GuC 
> > > (acknowledged by either replying
> > > with a success or failure). This is necessary for coherent guc-id 
> > > state machine (because the
> > > GuC firmware will drop requests for guc-id's that are not registered 
> > > or not in a
> > > 'sched-enabled' state).
> 
> > Maybe to explain what I meant a bit better. I thought that the reason 
> > for strange unlock pattern is the with_runtime_pm which needs to 
> > happen for the CT send/receive loop. What I meant was would it be 
> > possible to do it like this:
> > 
> > state lock
> > ...
> > sent = queue_msg_2_guc (this would be i915 only, no runtime pm needed)
> > ...
> > state unlock
> > 
> > if (sent)
> >   with_runtime_pm:
> >  send/receive queued guc messages (only this would talk to guc)
> > 
> > But I have truly no idea if the CT messaging infrastructure supports 
> > something like this.
> > 
> > Anyway, see what it is possible and if it is not or too hard for now 
> > leave it be.
> > 
alan: I consulted with my team mates on above and they said that discussion has 
happened
in the past and the CT infrastructure currently does not support that but the 
benefit
comes into question because such an undertaking would be an expensive redesign 
that
has wider impact (changes across all callers). I guess for now i will leave 
above code
as it is as this would be a whole separate feature change on its own.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis

[Teres Alexis, Alan Previn]

On Fri, 2022-09-16 at 09:58 +0100, Tvrtko Ursulin wrote:
> On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
> > On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> > > On 15/09/2022 03:12, Alan Previn wrote:
> > > > From: Matthew Brost 
> > > > 
> > > > +static void guc_flush_all_delayed_disable_sched_contexts(struct 
> > > > intel_guc *guc)
> > > > +{
> > > > +   struct intel_context *ce;
> > > > +   unsigned long index;
> > > > +   unsigned long flags;
> > > > +   unsigned long ceflags;
> > > >
> > > > -   with_intel_runtime_pm(runtime_pm, wakeref)
> > > > -   __guc_context_sched_disable(guc, ce, guc_id);
> > > > +   xa_lock_irqsave(>context_lookup, flags);
> > > > +   xa_for_each(>context_lookup, index, ce) {
> > > > +   if (!kref_get_unless_zero(>ref))
> > > > +   continue;
> > > > +   xa_unlock(>context_lookup);
> > > 
> > > So this whole loop _needs_ to run with interrupts disabled? Explaining
> > > why in a comment would be good.
> > > 
> > Being mid-reset, the locking mode is consistent with other functions also 
> > used
> > as part of the reset preparation that parses and potentially modifies 
> > contexts.
> > I believe the goal is to handle all of this parsing without getting 
> > conflicting
> > latent G2H replies that breaks the preparation flow (that herds active 
> > contexts
> > into a fewer set of states as part of reset) - but i will double check
> > with my colleagues.
> > 
Alan: Update i realize the guc-reset-preparation code disable irqs for the guc 
being reset
prior to this function so in fact, we really ought not to see any change to 
that xa_array
because of a context-id change that is coming via a interrupt that is 
orthogonal to this
thread. I will change to xa_lock.

> > > > +   if (test_bit(CONTEXT_GUC_INIT, >flags) &&
> > > > +   
> > > > cancel_delayed_work(>guc_state.sched_disable_delay)) {
> > > > +   spin_lock_irqsave(>guc_state.lock, ceflags);
> > > > +   spin_unlock_irqrestore(>guc_state.lock, 
> > > > ceflags);
> > > 
> > > This deserves a comment about what lock toggling wants to ensure.
> > > 
> > I realize this might have been my local rebasing mistake, the intention was 
> > to
> > handle cases where sched_disable_delay wasn't pending but potentially still
> > executing do_sched_disable. I believe I could try cancel_delayed_work_sync 
> > (but
> > not sure if i can call that might-sleep funtion mid reset while not-
> > interruptible). Else, i would move that lock-unlock to if the
> > cancel_delayed_work did not return true (as per original intent before my
> > rebase error).
> 
> Okay a comment like "flush any currently executing do_sched_disable" 
> above the lock toggling would do then. Even better if you add what 
> happens if that flushing isn't done.
> 
> > > Also, if the loops runs with interrupts disabled what is the point of
> > > irqsave variant in here??
> > Yes - its redundant, let me fix that, apologies for that.
> > 
same thing here, a context's guc state should not change in response to an IRQ
from that guc since we disabled it while we are in reset preparatoin
- so actually "not needed" as opposed to "redundant"

> > > Also2, what is the reason for dropping the lock? intel_context_put?
> > Being consistent with other reset preparation code that closes contexts,
> > the lock is dropped before the intel_context_put.
> > (I hope i am not misunderstanding your question).
> 
> Right, okay.. so for locking inversion issues - intel_context_put must 
> not be called with guc_state.lock held, yes?
> 
> Not a mandatory request, but if you want you could look into the option 
> of avoiding lock dropping and instead doing xa_erase and recording the 
> list of contexts for sched disable or put in a local list, and doing 
> them all in one block outside the locked/irq disabled section. Although 
> tbh I am not sure if that would improve anything. Probably not in this 
> case of a reset path, but if there are other places in GuC code which do 
> this it may be beneficial for less hammering on the CPU and core 
> synchronisation for atomics.
> 
apologies my ignorance - perhaps i misunderstood how these functions work but
I assumed that calling kref_get_unless_zero with a non-zero return that lead us
here meant that there is still a ref on the context that didnt come from the
reset path so i am just following the correct rules to release that ref 
and not destroy the contexts yet - but leaving it in the pending-disable
that will be handled in scrub_guc_desc_for_outstanding_g2h that gets called
later in the reset preparation.

Actually i realize that the better option might be to move above code
into the loop already present inside of scrub_guc_desc_for_outstanding_g2h
just prior to its checking of whether a context is pending-disable.
That would ensure we take all these context locks once in the same 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix TC port PLLs after readout

[Patchwork]

== Series Details ==

Series: drm/i915: Fix TC port PLLs after readout
URL   : https://patchwork.freedesktop.org/series/108847/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12166 -> Patchwork_108847v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/index.html

Participating hosts (45 -> 44)
--

  Missing(1): fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108847v1:

### 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_12166/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_108847v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html

  
Known issues


  Here are the changes found in Patchwork_108847v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([fdo#111827])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/fi-hsw-4770/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][5] ([i915#2867]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][7] ([i915#5334]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
- fi-glk-j4005:   [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [INCOMPLETE][11] ([i915#5982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12166/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.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#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380


Build changes
-

  * Linux: CI_DRM_12166 -> Patchwork_108847v1

  CI-20190529: 20190529
  CI_DRM_12166: 3e89f6dc5d22dcc4f56bed3abade8107c95815b3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6659: 1becf700a737a7a98555a0cfbe8566355377afb2 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108847v1: 3e89f6dc5d22dcc4f56bed3abade8107c95815b3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

0c503ed09a3c drm/i915: WARN if PLL ref/unref got messed up
ab32962af64e drm/i915: Pimp DPLL ref/unref debugs
5b545725ad63 drm/i915: Don't bail early from intel_dp_initial_fastset_check()
857bf1902478 drm/i915: Force DPLL calculation for TC ports after readout

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108847v1/index.html

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix TC port PLLs after readout

[Patchwork]

== Series Details ==

Series: drm/i915: Fix TC port PLLs after readout
URL   : https://patchwork.freedesktop.org/series/108847/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Allow D3 when we are not actively managing a known PCI device.

[Patchwork]

== Series Details ==

Series: drm/i915: Allow D3 when we are not actively managing a known PCI device.
URL   : https://patchwork.freedesktop.org/series/108841/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12164_full -> Patchwork_108841v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_108841v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108841v1_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_108841v1_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_partial_pwrite_pread@write-uncached:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-iclb6/igt@gem_partial_pwrite_pr...@write-uncached.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-iclb4/igt@gem_partial_pwrite_pr...@write-uncached.html

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-edp-1:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-tglb5/igt@kms_cursor_crc@cursor-rapid-movement-128...@pipe-d-edp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-tglb8/igt@kms_cursor_crc@cursor-rapid-movement-128...@pipe-d-edp-1.html

  
 Warnings 

  * igt@runner@aborted:
- shard-skl:  ([FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], 
[FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], 
[FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], 
[FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24]) ([i915#6884]) -> ([FAIL][25], 
[FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], 
[FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], 
[FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], 
[FAIL][44]) ([i915#6641])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl1/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl1/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl5/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl7/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl4/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl4/igt@run...@aborted.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl6/igt@run...@aborted.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl6/igt@run...@aborted.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl10/igt@run...@aborted.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl1/igt@run...@aborted.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl3/igt@run...@aborted.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/shard-skl6/igt@run...@aborted.html
   [31]: 

[Intel-gfx] [PATCH 3/4] drm/i915: Pimp DPLL ref/unref debugs

[Ville Syrjala]

From: Ville Syrjälä 

We currently have a debug message in intel_reference_shared_dpll()
but no counterpart in intel_unreference_shared_dpll(). Add one.

Switch to the [CRTC:...] notation for the pipe name while at it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e5fb66a5dd02..c21818cb6fe2 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -384,20 +384,25 @@ intel_reference_shared_dpll(struct intel_atomic_state 
*state,
if (shared_dpll[id].pipe_mask == 0)
shared_dpll[id].hw_state = *pll_state;
 
-   drm_dbg(>drm, "using %s for pipe %c\n", pll->info->name,
-   pipe_name(crtc->pipe));
-
shared_dpll[id].pipe_mask |= BIT(crtc->pipe);
+
+   drm_dbg(>drm, "[CRTC:%d:%s] reserving %s\n",
+   crtc->base.base.id, crtc->base.name, pll->info->name);
 }
 
 static void intel_unreference_shared_dpll(struct intel_atomic_state *state,
  const struct intel_crtc *crtc,
  const struct intel_shared_dpll *pll)
 {
+   struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
+
shared_dpll[pll->info->id].pipe_mask &= ~BIT(crtc->pipe);
+
+   drm_dbg(>drm, "[CRTC:%d:%s] releasing %s\n",
+   crtc->base.base.id, crtc->base.name, pll->info->name);
 }
 
 static void intel_put_dpll(struct intel_atomic_state *state,
-- 
2.35.1

[Intel-gfx] [PATCH 4/4] drm/i915: WARN if PLL ref/unref got messed up

[Ville Syrjala]

From: Ville Syrjälä 

Spew a WARN if we try to ref/unref the same DPLL multiple
times for the same pipe.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index c21818cb6fe2..2a6ef1398c84 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -384,6 +384,8 @@ intel_reference_shared_dpll(struct intel_atomic_state 
*state,
if (shared_dpll[id].pipe_mask == 0)
shared_dpll[id].hw_state = *pll_state;
 
+   drm_WARN_ON(>drm, (shared_dpll[id].pipe_mask & BIT(crtc->pipe)) 
!= 0);
+
shared_dpll[id].pipe_mask |= BIT(crtc->pipe);
 
drm_dbg(>drm, "[CRTC:%d:%s] reserving %s\n",
@@ -396,10 +398,13 @@ static void intel_unreference_shared_dpll(struct 
intel_atomic_state *state,
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
+   const enum intel_dpll_id id = pll->info->id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
 
-   shared_dpll[pll->info->id].pipe_mask &= ~BIT(crtc->pipe);
+   drm_WARN_ON(>drm, (shared_dpll[id].pipe_mask & BIT(crtc->pipe)) 
== 0);
+
+   shared_dpll[id].pipe_mask &= ~BIT(crtc->pipe);
 
drm_dbg(>drm, "[CRTC:%d:%s] releasing %s\n",
crtc->base.base.id, crtc->base.name, pll->info->name);
-- 
2.35.1

[Intel-gfx] [PATCH 2/4] drm/i915: Don't bail early from intel_dp_initial_fastset_check()

[Ville Syrjala]

From: Ville Syrjälä 

Do all the checks in intel_dp_initial_fastset_check() instead
of bailing out on the first condition that triggers.

This makes for better debug logs since we see all the reasons
why the full modeset computation is forced.

Also avoid the risk of someone accidentally adding a check
later in the function that would require connectors_changed=true
(ie. no fastset at all), but an earlier check may have already
bailed out with just mode_changed=true (ie. fastset is still
possible).

Pimp the debugs with the encoder id+name while at it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c9be61d2348e..73c4db4db20b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2306,6 +2306,7 @@ bool intel_dp_initial_fastset_check(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   bool ret = true;
 
/*
 * If BIOS has set an unsupported or non-standard link rate for some
@@ -2313,9 +2314,10 @@ bool intel_dp_initial_fastset_check(struct intel_encoder 
*encoder,
 */
if (intel_dp_rate_index(intel_dp->source_rates, 
intel_dp->num_source_rates,
crtc_state->port_clock) < 0) {
-   drm_dbg_kms(>drm, "Forcing full modeset due to 
unsupported link rate\n");
+   drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset 
due to unsupported link rate\n",
+   encoder->base.base.id, encoder->base.name);
crtc_state->uapi.connectors_changed = true;
-   return false;
+   ret = false;
}
 
/*
@@ -2326,18 +2328,20 @@ bool intel_dp_initial_fastset_check(struct 
intel_encoder *encoder,
 * Remove once we have readout for DSC.
 */
if (crtc_state->dsc.compression_enable) {
-   drm_dbg_kms(>drm, "Forcing full modeset due to DSC being 
enabled\n");
+   drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset 
due to DSC being enabled\n",
+   encoder->base.base.id, encoder->base.name);
crtc_state->uapi.mode_changed = true;
-   return false;
+   ret = false;
}
 
if (CAN_PSR(intel_dp)) {
-   drm_dbg_kms(>drm, "Forcing full modeset to compute PSR 
state\n");
+   drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset 
to compute PSR state\n",
+   encoder->base.base.id, encoder->base.name);
crtc_state->uapi.mode_changed = true;
-   return false;
+   ret = false;
}
 
-   return true;
+   return ret;
 }
 
 static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
-- 
2.35.1

[Intel-gfx] [PATCH 1/4] drm/i915: Force DPLL calculation for TC ports after readout

[Ville Syrjala]

From: Ville Syrjälä 

We always allocate two DPLLs (TC and TBT) for TC ports. This
is because we can't know ahead of time wherher we need to put
the PHY into DP-Alt or TBT mode.

However during readout we can obviously only read out the state
of the DPLL that the port is actually using. Thus the state after
readout will not have both DPLLs populated.

We run into problems if during readout the TC port is in DP-Alt
mode, but we then perform a modeset on the port without going
through the full .compute_config() machinery, and during said
modeset the port cannot be switched back into DP-Alt mode and
we need to take the TBT fallback path. Such a modeset can
happen eg. due to cdclk reprogramming.

This wasn't a problem earlier because we did all the DPLL
calculations much later in the modeset. So even if flagged
a modeset very late we'd still have gone through the DPLL
calculations. But now all the DPLL calculations happen much
earlier and so we need to deal with it, or else we'll attempt
a modeset without a DPLL.

To guarantee that we always have both DPLLs fully cal/ulated
for TC ports force a full modeset computation during the
initial commit.

Reported-by: Lee Shawn C 
Fixes: b000abd3b3d2 ("drm/i915: Do .crtc_compute_clock() earlier")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 643832d55c28..6278b8ea5bf1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3600,10 +3600,21 @@ static void intel_ddi_sync_state(struct intel_encoder 
*encoder,
 static bool intel_ddi_initial_fastset_check(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state)
 {
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+   bool ret = true;
+
+   if (intel_phy_is_tc(i915, phy)) {
+   drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset 
to compute TC port DPLLs\n",
+   encoder->base.base.id, encoder->base.name);
+   crtc_state->uapi.mode_changed = true;
+   ret = false;
+   }
+
if (intel_crtc_has_dp_encoder(crtc_state))
-   return intel_dp_initial_fastset_check(encoder, crtc_state);
+   ret &= intel_dp_initial_fastset_check(encoder, crtc_state);
 
-   return true;
+   return ret;
 }
 
 static enum intel_output_type
-- 
2.35.1

[Intel-gfx] [PATCH 0/4] drm/i915: Fix TC port PLLs after readout

[Ville Syrjala]

From: Ville Syrjälä 

I broke the dp-alt->tbt fallback for TC ports a bit. Try to fix it.
Also pimp the debugs around those parts a bit.

Ville Syrjälä (4):
  drm/i915: Force DPLL calculation for TC ports after readout
  drm/i915: Don't bail early from intel_dp_initial_fastset_check()
  drm/i915: Pimp DPLL ref/unref debugs
  drm/i915: WARN if PLL ref/unref got messed up

 drivers/gpu/drm/i915/display/intel_ddi.c  | 15 +--
 drivers/gpu/drm/i915/display/intel_dp.c   | 18 +++---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16 +---
 3 files changed, 37 insertions(+), 12 deletions(-)

-- 
2.35.1

[Intel-gfx] [CI] PR for DMC v2.071 for DG2

[Tolakanahalli Pradeep, Madhumitha]

The following changes since commit f09bebf31b0590bdc875d7236aa705279510cfd0:

  amdgpu: update yellow carp DMCUB firmware (2022-09-13 08:02:23 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.071

for you to fetch changes up to 4b05845b82d82f8fc153261a2ef6e2ecda81:

  i915: Add DMC v2.071 for DG2 (2022-09-21 13:48:45 -0700)


Madhumitha Tolakanahalli Pradeep (1):
  i915: Add DMC v2.071 for DG2

 WHENCE|   3 +++
 i915/dg2_dmc_ver2_071.bin | Bin 0 -> 22232 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/dg2_dmc_ver2_071.bin

[Intel-gfx] [PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes drm-intel-fixes-2022-09-21:

2 gem context related fixes:
- to avoid a general protection failure when using perf/OA (Chris)
- to avoid kernel warnings on driver release (Janusz)

Thanks,
Rodrigo.

The following changes since commit 521a547ced6477c54b4b0cc206000406c221b4d6:

  Linux 6.0-rc6 (2022-09-18 13:44:14 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-09-21

for you to fetch changes up to d119888b09bd567e07c6b93a07f175df88857e02:

  drm/i915/gem: Really move i915_gem_context.link under ref protection 
(2022-09-20 10:19:05 -0400)


2 gem context related fixes:
- to avoid a general protection failure when using perf/OA (Chris)
- to avoid kernel warnings on driver release (Janusz)


Chris Wilson (1):
  drm/i915/gem: Really move i915_gem_context.link under ref protection

Janusz Krzysztofik (1):
  drm/i915/gem: Flush contexts on driver release

 drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 
 drivers/gpu/drm/i915/i915_gem.c | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

[Intel-gfx] ✓ Fi.CI.IGT: success for Delay disabling GuC scheduling of an idle context (rev2)

[Patchwork]

== Series Details ==

Series: Delay disabling GuC scheduling of an idle context (rev2)
URL   : https://patchwork.freedesktop.org/series/108587/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164_full -> Patchwork_108587v2_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_108587v2_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108587v2_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_108587v2_full:

### IGT changes ###

 Warnings 

  * igt@runner@aborted:
- shard-skl:  ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4], 
[FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], 
[FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], 
[FAIL][18], [FAIL][19], [FAIL][20]) ([i915#6884]) -> ([FAIL][21], [FAIL][22], 
[FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], 
[FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], 
[FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], 
[FAIL][41], [FAIL][42]) ([i915#6641])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl1/igt@run...@aborted.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl1/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl10/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl3/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl5/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl7/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl9/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl4/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl6/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-skl4/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl3/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl9/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl4/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl6/igt@run...@aborted.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl7/igt@run...@aborted.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl3/igt@run...@aborted.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl7/igt@run...@aborted.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl6/igt@run...@aborted.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl5/igt@run...@aborted.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl1/igt@run...@aborted.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl4/igt@run...@aborted.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl6/igt@run...@aborted.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl9/igt@run...@aborted.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/shard-skl4/igt@run...@aborted.html
   [35]: 

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Split GAM and MSLICE steering

[Matt Roper]

On Fri, Sep 16, 2022 at 08:41:54AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Split GAM and MSLICE steering
> URL   : https://patchwork.freedesktop.org/series/108627/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12144_full -> Patchwork_108627v1_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 

Applied to drm-intel-gt-next.  Thanks Prathap for the review.


Matt

>   
> 
> Participating hosts (11 -> 11)
> --
> 
>   No changes in participating hosts
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_108627v1_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#3070])
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb7/igt@gem_...@unwedge-stress.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb5/igt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_balancer@parallel-keep-in-fence:
> - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +2 similar 
> issues
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb3/igt@gem_exec_balan...@parallel-keep-in-fence.html
> 
>   * igt@gem_exec_fair@basic-flow@rcs0:
> - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html
> 
>   * igt@gem_exec_fair@basic-none@vecs0:
> - shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html
> 
>   * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
> 
>   * igt@gem_huc_copy@huc-copy:
> - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb3/igt@gem_huc_c...@huc-copy.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html
> 
>   * igt@gem_lmem_swapping@verify-random:
> - shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@gem_lmem_swapp...@verify-random.html
> 
>   * igt@gem_pxp@reject-modify-context-protection-off-3:
> - shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271]) +44 similar 
> issues
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@gem_...@reject-modify-context-protection-off-3.html
> 
>   * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
> - shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) 
> +2 similar issues
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
> 
>   * igt@kms_chamelium@dp-hpd-with-enabled-mode:
> - shard-apl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@kms_chamel...@dp-hpd-with-enabled-mode.html
> 
>   * igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-hdmi-a1-hdmi-a2:
> - shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2122])
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk9/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-glk9/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html
> 
>   * 
> igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
> - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2587] / [i915#2672]) +3 
> similar issues
>[20]: 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow D3 when we are not actively managing a known PCI device.

[Patchwork]

== Series Details ==

Series: drm/i915: Allow D3 when we are not actively managing a known PCI device.
URL   : https://patchwork.freedesktop.org/series/108841/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108841v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/index.html

Participating hosts (34 -> 41)
--

  Additional (10): bat-dg1-5 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-adlp-6 
bat-adln-1 bat-jsl-3 bat-rplp-1 bat-rpls-1 bat-dg2-11 
  Missing(3): fi-hsw-4770 fi-bdw-samus fi-tgl-mst 

Known issues


  Here are the changes found in Patchwork_108841v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@fb...@nullptr.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_108841v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][4] ([i915#4083])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#1155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4215])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_busy@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#1845] / [i915#4303])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_b...@basic.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([fdo#111827]) +8 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([i915#4103])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/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][15] ([i915#6008])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#4078]) +14 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108841v1/bat-dg1-5/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  * igt@kms_psr@primary_page_flip:
- bat-dg1-5:  NOTRUN -> [SKIP][19] 

Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering

[Kumar Valsan, Prathap]

On Wed, Sep 21, 2022 at 12:26:17PM -0700, Matt Roper wrote:
> On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> > On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > > > 
> > > > On 16/09/2022 02:43, Matt Roper wrote:
> > > > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > > > that a subset of these are of a "GAM" subclass that has unique rules 
> > > > > and
> > > > > doesn't followed regular mslice steering behavior.
> > > > > 
> > > > >   * Xe_HP SDV:  GAM ranges must always be steered to 0,0.  These
> > > > > registers share the regular steering control register (0xFDC) with
> > > > > other steering types
> > > > > 
> > > > >   * DG2:  GAM ranges must always be steered to 1,0.  GAM registers 
> > > > > have a
> > > > > dedicated steering control register (0xFE0) so we can set the 
> > > > > value
> > > > > once at startup and rely on implicit steering.  Technically the
> > > > > hardware default should already be set to 1,0 properly, but it 
> > > > > never
> > > > > hurts to ensure that in the driver.
> > > > 
> > > > Do you have any data on whether the "technically should" holds in 
> > > > practice?
> > > > What would be the consequences of some platform/machine surprising us 
> > > > here?
> > > 
> > > The bspec indicates the hardware default value is already the necessary
> > > 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> > > it to 0,0 by accident.  I don't have any evidence that has ever actually
> > > happened, but explicitly re-programming it to 1,0 in the patch here is a
> > > defensive measure just to be safe.
> > > 
> > > If we didn't have this patch _and_ some firmware screwed up the GAM
> > > steering target, then presumably we might read back garbage or 0 from
> > > GAM registers in places where we should have received a real value.
> > Will firmware ever touch the steering target registers. As i was going
> > through the respective hsd. The software driver impact is marked as none
> > so wondering if this change is really required ?
> 
> The GAM only has a dedicated steering register on DG2; on XEHPSDV it
> shares 0xFDC with all the other kinds of steering, so it is important to
> handle this range independently of the MSLICE range and make sure we
> properly re-steer GAM accesses to the primary instance (and not just any
> random MSLICE) there.
Ok. I missed that part.
> 
> On DG2, if we assume firmware behaves properly, the dedicated steering
> register is initialized properly and we don't need to explicitly
> re-steer.  However this patch will ensure that we don't needlessly
> re-program 0xFDC according to MSLICE rules when accessing a GAM
> register.
> 
> There's also the worry that firmware may try to "sanitize" the registers
> at startup by programming them to what it thinks are appropriate default
> values.  Given that DG2's primary GAM is unusual (instance 1, instead of
> instance 0 as on other platforms), this feels like a place where
> firmware bugs could creep in.  They hopefully/probably won't, but
> ensuring we forcefully initialize 0xFE0 to the proper value just ensures
> that we don't even have to worry about it.
Got it.
> 
> Finally, splitting the GAM from MSLICE ensures we get more accurate
> debug messages from the drm_printer in dmesg and debugfs.
> 
Looks good to me.

Reviewed-by: Prathap Kumar Valsan 
> 
> Matt
> 
> > 
> > Thanks,
> > Prathap
> > > 
> > > 
> > > Matt
> > > 
> > > > 
> > > > Regards,
> > > > 
> > > > Tvrtko
> > > > 
> > > > > 
> > > > > Bspec: 66534
> > > > > Signed-off-by: Matt Roper 
> > > > > ---
> > > > >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 24 
> > > > > +++--
> > > > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
> > > > >   drivers/gpu/drm/i915/gt/intel_gt_types.h|  1 +
> > > > >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > > > >   4 files changed, 34 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > > > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > index e79405a45312..a2047a68ea7a 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > > > >   "L3BANK",
> > > > >   "MSLICE",
> > > > >   "LNCF",
> > > > > + "GAM",
> > > > >   "INSTANCE 0",
> > > > >   };
> > > > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range 
> > > > > icl_l3bank_steering_table[] = {
> > > > >   {},
> > > > >   };
> > > > > +/*
> > > > > + * Although the bspec lists more "MSLICE" ranges than shown here, 
> > > > > some of those
> > > > > + * are of a "GAM" subclass that has special rules.  Thus we use a 
> > > > > separate
> > > > > + * GAM table farther down for those.
> > > > > + */
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering

[Matt Roper]

On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 16/09/2022 02:43, Matt Roper wrote:
> > > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > > that a subset of these are of a "GAM" subclass that has unique rules and
> > > > doesn't followed regular mslice steering behavior.
> > > > 
> > > >   * Xe_HP SDV:  GAM ranges must always be steered to 0,0.  These
> > > > registers share the regular steering control register (0xFDC) with
> > > > other steering types
> > > > 
> > > >   * DG2:  GAM ranges must always be steered to 1,0.  GAM registers have 
> > > > a
> > > > dedicated steering control register (0xFE0) so we can set the value
> > > > once at startup and rely on implicit steering.  Technically the
> > > > hardware default should already be set to 1,0 properly, but it never
> > > > hurts to ensure that in the driver.
> > > 
> > > Do you have any data on whether the "technically should" holds in 
> > > practice?
> > > What would be the consequences of some platform/machine surprising us 
> > > here?
> > 
> > The bspec indicates the hardware default value is already the necessary
> > 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> > it to 0,0 by accident.  I don't have any evidence that has ever actually
> > happened, but explicitly re-programming it to 1,0 in the patch here is a
> > defensive measure just to be safe.
> > 
> > If we didn't have this patch _and_ some firmware screwed up the GAM
> > steering target, then presumably we might read back garbage or 0 from
> > GAM registers in places where we should have received a real value.
> Will firmware ever touch the steering target registers. As i was going
> through the respective hsd. The software driver impact is marked as none
> so wondering if this change is really required ?

The GAM only has a dedicated steering register on DG2; on XEHPSDV it
shares 0xFDC with all the other kinds of steering, so it is important to
handle this range independently of the MSLICE range and make sure we
properly re-steer GAM accesses to the primary instance (and not just any
random MSLICE) there.

On DG2, if we assume firmware behaves properly, the dedicated steering
register is initialized properly and we don't need to explicitly
re-steer.  However this patch will ensure that we don't needlessly
re-program 0xFDC according to MSLICE rules when accessing a GAM
register.

There's also the worry that firmware may try to "sanitize" the registers
at startup by programming them to what it thinks are appropriate default
values.  Given that DG2's primary GAM is unusual (instance 1, instead of
instance 0 as on other platforms), this feels like a place where
firmware bugs could creep in.  They hopefully/probably won't, but
ensuring we forcefully initialize 0xFE0 to the proper value just ensures
that we don't even have to worry about it.

Finally, splitting the GAM from MSLICE ensures we get more accurate
debug messages from the drm_printer in dmesg and debugfs.


Matt

> 
> Thanks,
> Prathap
> > 
> > 
> > Matt
> > 
> > > 
> > > Regards,
> > > 
> > > Tvrtko
> > > 
> > > > 
> > > > Bspec: 66534
> > > > Signed-off-by: Matt Roper 
> > > > ---
> > > >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 24 +++--
> > > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
> > > >   drivers/gpu/drm/i915/gt/intel_gt_types.h|  1 +
> > > >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > > >   4 files changed, 34 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > index e79405a45312..a2047a68ea7a 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > > > "L3BANK",
> > > > "MSLICE",
> > > > "LNCF",
> > > > +   "GAM",
> > > > "INSTANCE 0",
> > > >   };
> > > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range 
> > > > icl_l3bank_steering_table[] = {
> > > > {},
> > > >   };
> > > > +/*
> > > > + * Although the bspec lists more "MSLICE" ranges than shown here, some 
> > > > of those
> > > > + * are of a "GAM" subclass that has special rules.  Thus we use a 
> > > > separate
> > > > + * GAM table farther down for those.
> > > > + */
> > > >   static const struct intel_mmio_range xehpsdv_mslice_steering_table[] 
> > > > = {
> > > > -   { 0x004000, 0x004AFF },
> > > > -   { 0x00C800, 0x00CFFF },
> > > > { 0x00DD00, 0x00DDFF },
> > > > { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > > > {},
> > > >   };
> > > > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > > > 

[Intel-gfx] ✓ Fi.CI.BAT: success for Delay disabling GuC scheduling of an idle context (rev2)

[Patchwork]

== Series Details ==

Series: Delay disabling GuC scheduling of an idle context (rev2)
URL   : https://patchwork.freedesktop.org/series/108587/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108587v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/index.html

Participating hosts (34 -> 43)
--

  Additional (11): fi-rkl-11600 bat-dg1-5 bat-dg2-8 bat-adlm-1 fi-icl-u2 
bat-adlp-6 bat-adln-1 bat-jsl-3 bat-rplp-1 bat-rpls-1 bat-dg2-11 
  Missing(2): fi-hsw-4770 fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108587v2:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html

  
Known issues


  Here are the changes found in Patchwork_108587v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@fb...@nullptr.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][4] ([i915#6179])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4083])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4077]) +2 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3282])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#4079]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3012])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#1155])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][16] ([i915#4418])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [FAIL][17] ([fdo#103375])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#4212]) +7 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108587v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([i915#4215])
   [19]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Delay disabling GuC scheduling of an idle context (rev2)

[Patchwork]

== Series Details ==

Series: Delay disabling GuC scheduling of an idle context (rev2)
URL   : https://patchwork.freedesktop.org/series/108587/
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.BAT: failure for drm/i915/display: Don't use port enum as register offset (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: Don't use port enum as register offset (rev2)
URL   : https://patchwork.freedesktop.org/series/108833/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108833v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_108833v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108833v2, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/index.html

Participating hosts (34 -> 44)
--

  Additional (11): fi-rkl-11600 bat-dg1-5 bat-dg2-8 bat-adlm-1 bat-dg2-9 
bat-adlp-6 bat-adln-1 bat-jsl-3 bat-rplp-1 bat-rpls-1 bat-dg2-11 
  Missing(1): fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108833v2:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-adl-ddr5:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-adl-ddr5/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/fi-adl-ddr5/igt@i915_module_l...@load.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_module_load@load:
- {bat-adln-1}:   NOTRUN -> [DMESG-WARN][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-adln-1/igt@i915_module_l...@load.html
- {bat-rplp-1}:   NOTRUN -> [DMESG-WARN][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-rplp-1/igt@i915_module_l...@load.html
- {bat-dg2-9}:NOTRUN -> [DMESG-WARN][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg2-9/igt@i915_module_l...@load.html
- {bat-adlp-6}:   NOTRUN -> [DMESG-WARN][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-adlp-6/igt@i915_module_l...@load.html
- {bat-dg2-11}:   NOTRUN -> [DMESG-WARN][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg2-11/igt@i915_module_l...@load.html
- {bat-adlm-1}:   NOTRUN -> [DMESG-WARN][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-adlm-1/igt@i915_module_l...@load.html
- {bat-dg2-8}:NOTRUN -> [DMESG-WARN][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg2-8/igt@i915_module_l...@load.html

  
Known issues


  Here are the changes found in Patchwork_108833v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#2582]) +4 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg1-5/igt@fb...@nullptr.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4613]) +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][13] ([i915#4083])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4077]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3282])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([i915#4079]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#3012])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#1155])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v2/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 

Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions

[Niranjana Vishwanathapura]

On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:


On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common functionalities into a separate file where possible.


Looks like a good start to me. A couple comments/questions below.


Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 507 ++---
 .../drm/i915/gem/i915_gem_execbuffer_common.c | 530 ++
 .../drm/i915/gem/i915_gem_execbuffer_common.h |  47 ++
 4 files changed, 612 insertions(+), 473 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bf939ef18ea..bf952f478555 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+   gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 33d989a20227..363b2a788cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -9,8 +9,6 @@
 #include 
 #include 
-#include 
-
 #include "display/intel_frontbuffer.h"
 #include "gem/i915_gem_ioctls.h"
@@ -28,6 +26,7 @@
 #include "i915_file_private.h"
 #include "i915_gem_clflush.h"
 #include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
 #include "i915_gem_evict.h"
 #include "i915_gem_ioctls.h"
 #include "i915_trace.h"
@@ -235,13 +234,6 @@ enum {
  * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
  */
-struct eb_fence {
-   struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
-   struct dma_fence *dma_fence;
-   u64 value;
-   struct dma_fence_chain *chain_fence;
-};
-
 struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2446,164 +2438,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX]   = VECS0
 };
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct 
intel_context *ce)
-{
-   struct intel_ring *ring = ce->ring;
-   struct intel_timeline *tl = ce->timeline;
-   struct i915_request *rq;
-
-   /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
-   if (intel_ring_update_space(ring) >= PAGE_SIZE)
-   return NULL;
-
-   /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
-   list_for_each_entry(rq, >requests, link) {
-   if (rq->ring != ring)
-   continue;
-
-   if (__intel_ring_space(rq->postfix,
-  ring->emit, ring->size) > ring->size / 2)
-   break;
-   }
-   if (>link == >requests)
-   return NULL; /* weird, we will check again later for real */
-
-   return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context 
*ce,
-  bool throttle)
-{
-   struct intel_timeline *tl;
-   struct i915_request *rq = NULL;
-
-   /*
-* Take a local wakeref for preparing to dispatch the execbuf as
-* we expect to access the hardware fairly frequently in the
-* process, and require the engine to be kept awake between accesses.
-* Upon dispatch, we acquire another prolonged wakeref that we hold
-* until the timeline is idle, which in turn releases the wakeref
-* taken on the engine, and the parent device.
-*/
-   tl = intel_context_timeline_lock(ce);
-   if (IS_ERR(tl))
-   return PTR_ERR(tl);
-
-   intel_context_enter(ce);
-   if (throttle)
-   rq = eb_throttle(eb, ce);
-   intel_context_timeline_unlock(tl);
-
-   if (rq) {
-   bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
-   long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
-   if (i915_request_wait(rq, 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset

[Ville Syrjälä]

On Wed, Sep 21, 2022 at 10:52:59PM +0530, 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.

No one should really be doing that, apart from a few exceptions
during initialization. Apart from that I don't think enum port
should really be doing anything else these days than being the
register block offset we pass to the port registers.

Well, the VBT code does screw over that idea kinda. I've been
occasionally pondering some kind of separate namespace for ports
for the VBT code but haven't really it throught it through in
any detail.

> 
> >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.

Do we know that it's going to get even more messy?

Anyways, we have the exact same thing with AUX CH, so trying to
change one but not the other isn't really going to help.

And on top of that we have the horrorshow in intel_port_to_phy()
& co. I think the phy stuff is probably what we should try to sort
out next, since IMO it's the bigger mess.

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Don't use port enum as register offset (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: Don't use port enum as register offset (rev2)
URL   : https://patchwork.freedesktop.org/series/108833/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()

[Niranjana Vishwanathapura]

On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:


On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 ++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
 #include "pxp/intel_pxp.h"
 #include "i915_drv.h"
+#include "i915_gem_context.h"


I can't spot that you are adding any code which would need this? 
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.


This include should have been added in a later patch for calling
i915_gem_vm_lookup(). But got added here while patch refactoring.
Will fix.




 #include "i915_gem_create.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region **placements,
-   unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements:  list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
 {
-   u32 max_page_size = 0;
+   u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct intel_memory_region 
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
-   GEM_BUG_ON(!max_page_size);
return max_page_size;
 }
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private 
*i915, u64 size,
i915_gem_flush_free_objects(i915);
-   size = round_up(size, object_max_page_size(placements, n_placements));
+   size = round_up(size, i915_gem_object_max_page_size(placements,
+   n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);


Because of the changes above this path is now unreachable. I suppose 
it was meant to tell the user "you have supplied no placements"? But 
then GEM_BUG_ON (which you remove) used to be wrong.




Yah, looks like an existing problem. May be this "size == 0" check
should have been made before we do the round_up()? ie., check input 'size'
paramter is not 0?
I think for now, I will remove this check as it was unreachable anyhow.

Niranjana


Regards,

Tvrtko


diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..8c97bddad921 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
 }
 void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
 void i915_objects_module_exit(void);
 int i915_objects_module_init(void);

Re: [Intel-gfx] [RFC v4 02/14] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()

[Niranjana Vishwanathapura]

On Wed, Sep 21, 2022 at 10:06:48AM +0100, Tvrtko Ursulin wrote:


On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 25 ++---
 drivers/gpu/drm/i915/i915_sw_fence.h |  7 ++-
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..0ce8f4efc1ed 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -569,12 +569,11 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
return ret;
 }
-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)
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp)
 {
struct dma_resv_iter cursor;
struct dma_fence *f;
@@ -583,7 +582,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
-   dma_resv_iter_begin(, resv, dma_resv_usage_rw(write));
+   dma_resv_iter_begin(, resv, usage);
dma_resv_for_each_fence_unlocked(, f) {
pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
@@ -598,6 +597,18 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
return ret;
 }
+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)
+{
+   return __i915_sw_fence_await_reservation(fence, resv,
+dma_resv_usage_rw(write),
+timeout, gfp);
+}


Drive by observation - it looked dodgy that you create a wrapper here 
which ignores one function parameter.


On a more detailed look it seems no callers actually use exclude and 
it's even unused inside this function since 1b5bdf071e62 ("drm/i915: 
use the new iterator in i915_sw_fence_await_reservation v3").


So a cleanup patch before this one?



Thanks Tvrtko.
Yah, I noticed it, but did not want to fix that here.
Sure, will post a patch beforehand to fix that.

Niranjana


Regards,

Tvrtko



+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/lib_sw_fence.c"
 #include "selftests/i915_sw_fence.c"
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h 
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 619fc5a22f0c..3cf4b6e16f35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -10,13 +10,13 @@
 #define _I915_SW_FENCE_H_
 #include 
+#include 
 #include 
 #include 
 #include  /* for NOTIFY_DONE */
 #include 
 struct completion;
-struct dma_resv;
 struct i915_sw_fence;
 enum i915_sw_fence_notify {
@@ -89,6 +89,11 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
  unsigned long timeout,
  gfp_t gfp);
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp);
 int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
const struct dma_fence_ops *exclude,

[Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.

[Rodrigo Vivi]

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);
+
return -ENODEV;
}
 
-- 
2.37.2

[Intel-gfx] [PATCH v2 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis

[Alan Previn]

From: Matthew Brost 

Add a delay, configurable via debugfs (default 34ms), to disable
scheduling of a context after the pin count goes to zero. Disable
scheduling is a costly operation as it requires synchronizing with
the GuC. So the idea is that a delay allows the user to resubmit
something before doing this operation. This delay is only done if
the context isn't closed and less than a given threshold
(default is 3/4) of the guc_ids are in use.

Alan Previn: Matt Brost first introduced this patch back in Oct 2021.
However no real world workload with measured performance impact was
available to prove the intended results. Today, this series is being
republished in response to a real world workload that benefited greatly
from it along with measured performance improvement.

Workload description: 36 containers were created on a DG2 device where
each container was performing a combination of 720p 3d game rendering
and 30fps video encoding. The workload density was configured in a way
that guaranteed each container to ALWAYS be able to render and
encode no less than 30fps with a predefined maximum render + encode
latency time. That means the totality of all 36 containers and their
workloads were not saturating the engines to their max (in order to
maintain just enough headrooom to meet the min fps and max latencies
of incoming container submissions).

Problem statement: It was observed that the CPU core processing the i915
soft IRQ work was experiencing severe load. Using tracelogs and an
instrumentation patch to count specific i915 IRQ events, it was confirmed
that the majority of the CPU cycles were caused by the
gen11_other_irq_handler() -> guc_irq_handler() code path. The vast
majority of the cycles was determined to be processing a specific G2H
IRQ: i.e. INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE. These IRQs are sent
by GuC in response to i915 KMD sending H2G requests:
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET. Those H2G requests are sent
whenever a context goes idle so that we can unpin the context from GuC.
The high CPU utilization % symptom was limiting density scaling.

Root Cause Analysis: Because the incoming execution buffers were spread
across 36 different containers (each with multiple contexts) but the
system in totality was NOT saturated to the max, it was assumed that each
context was constantly idling between submissions. This was causing
a thrashing of unpinning contexts from GuC at one moment, followed quickly
by repinning them due to incoming workload the very next moment. These
event-pairs were being triggered across multiple contexts per container,
across all containers at the rate of > 30 times per sec per context.

Metrics: When running this workload without this patch, we measured an
average of ~69K INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE events every 10
seconds or ~10 million times over ~25+ mins. With this patch, the count
reduced to ~480 every 10 seconds or about ~28K over ~10 mins. The
improvement observed is ~99% for the average counts per 10 seconds.

Design awareness: Selftest impact.
As temporary WA disable this feature for the selftests. Selftests are
very timing sensitive and any change in timing can cause failure. A
follow up patch will fixup the selftests to understand this delay.

Design awareness: Race between guc_request_alloc and guc_context_close.
If a context close is issued while there is a request submission in
flight and a delayed schedule disable is pending, guc_context_close
and guc_request_alloc will race to cancel the delayed disable.
To close the race, make sure that guc_request_alloc waits for
guc_context_close to finish running before checking any state.

Design awareness: GT Reset event.
If a gt reset is triggered, as preparation steps, add an additional step
to ensure all contexts that have a pending delay-disable-schedule task
be flushed of it. Move them directly into the closed state after cancelling
the worker. This is okay because the existing flow flushes all
yet-to-arrive G2H's dropping them anyway.

Signed-off-by: Matthew Brost 
Signed-off-by: Alan Previn 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_context.h   |   8 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  16 ++
 .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c|  61 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 207 +++---
 drivers/gpu/drm/i915/i915_selftest.h  |   2 +
 7 files changed, 276 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 0bcde53c50c6..5b56b36e3c32 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1458,7 +1458,7 @@ static void engines_idle_release(struct i915_gem_context 
*ctx,
int err;
 
/* serialises with execbuf */

[Intel-gfx] [PATCH v2 0/1] Delay disabling GuC scheduling of an idle context

[Alan Previn]

This series adds a delay before disabling scheduling of the guc-context
when a context has become idle to avoid costly re-registration that may
occur immediately after. The 2nd patch should explain it quite well.

The origin of this series was posted by Matthew Brost back in Oct 2021
(https://patchwork.freedesktop.org/series/96167/). However no real
world workload performance impact was available until recently proving
it's intended results.

This series is a redo of a prior patch that was reverted:
2ccddb758079d0c62ce03e69ee8929bb212f7799 drm/i915/guc: Add delay to
disable scheduling after pin count goes to zero

The cause for the reversion is now fixed here (was not caught due to
issues with CI reporting at that time). Two additional changes included
in this redo and restarting as new series / revs:
 - Resolve race between guc_request_alloc and guc_context_close in
completing the delayed disable-guc-scheduling worker.
 - GT Reset flow properly cancelling delayed disable-sched worker and
   closing contexts that were were still awaiting that delayed task.

Changes from prior revs:
   v1: - Changed the added guc's sched_disable_foo debugfs tunable knobs
 to unsigned int type (Tvrtko Ursulin)
   - Added more comments in the race-resolution code change
 between guc_request_alloc and context-close (Tvrtko Ursulin)
   - Increased the timeout on the race-resolution code change
 between guc_request_alloc and context-close (Daniele Ceraolo Spurio)
   - As part of guc reset preparation flow, instead of creating a new
 function (taking a whole round of locks) to deal with the contexts 
 that are in the midst of awaiting the delayed-disable-sched worker
 move that code inside scrub_guc_desc_for_outstanding_g2h before
 we check for 'pending_disable' contexts.

Matthew Brost (1):
  drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis

 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_context.h   |   8 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  16 ++
 .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c|  61 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 207 +++---
 drivers/gpu/drm/i915/i915_selftest.h  |   2 +
 7 files changed, 276 insertions(+), 27 deletions(-)


base-commit: a1f63e144e545f0ce8f41f41005f2dfc552eb836
-- 
2.25.1

[Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset

[Balasubramani Vivekanandan]

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 
---
 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),
  500))
drm_err(_priv->drm, "DDI port:%c buffer idle\n",
@@ -1400,11 +1400,11 @@ static void gen11_dsi_disable_port(struct intel_encoder 
*encoder)
 
gen11_dsi_ungate_clocks(encoder);
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),
 8))
drm_err(_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4c543e8205ca..ab472fa757d8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2436,8 +2436,8 @@ static enum port dvo_port_to_port(struct 

Re: [Intel-gfx] [topic/core-for-CI] Revert "iommu/dma: Fix race condition during iova_domain initialization"

[Janusz Krzysztofik]

Hi Robin,

On Wednesday, 14 September 2022 17:54:36 CEST Robin Murphy wrote:
> On 2022-09-14 16:01, Lucas De Marchi wrote:
> > On Wed, Sep 14, 2022 at 02:40:45PM +0200, Karolina Drobnik wrote:
> >> This reverts commit ac9a5d522bb80be50ea84965699e1c8257d745ce.
> >>
> >> This change introduces a regression on Alder Lake that completely
> >> blocks testing. To enable CI and avoid possible circular locking
> >> warning, revert the patch.
> > 
> > We are already on rc5. Are iommu authors involved aware of this issue?
> > We could do this in our "for CI only" branch, but it's equally important
> > that this is fixed for 6.0
> > 
> > Cc'ing them.
> 
> The lockdep report doesn't make much sense to me - the deadlock cycle 
> it's reporting doesn't even involve the mutex added by that commit, and 
> otherwise the lock ordering between the IOMMU bus notifier(s) and 
> cpu_hotplug_lock has existed for ages. 

Indeed, that lockdep report is not quite related, but there are other lockdep 
reports in our CI results that better justify the revert.

https://intel-gfx-ci.01.org/tree/drm-tip/TrybotIGT_595/bat-dg2-8/igt@core_hotunp...@unplug-rescan.html

...
<7> [181.565177] [IGT] core_hotunplug: unplugging the device
<7> [181.565372] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling DC_off
<7> [181.565708] i915 :03:00.0: [drm:gen9_set_dc_state.part.15 [i915]] 
Setting DC state from 01 to 00
<7> [181.566060] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling PW_2
<7> [181.566216] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling PW_A
<7> [181.566447] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling PW_B
<7> [181.566607] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling PW_C
<7> [181.566765] i915 :03:00.0: [drm:intel_power_well_enable [i915]] 
enabling PW_D
<7> [181.570683] intel_gt_set_wedged called from 
intel_gt_set_wedged_on_fini+0x9/0x30 [i915]
<7> [181.659480] i915 :03:00.0: [drm:drm_client_release] drm_fb_helper
<6> [181.773310] pci :03:00.0: Removing from iommu group 1
<7> [181.774416] [IGT] core_hotunplug: rediscovering the device
<6> [181.775800] pci :03:00.0: [8086:56a0] type 00 class 0x03
<6> [181.775833] pci :03:00.0: reg 0x10: [mem 0x9000-0x90ff 64bit]
<6> [181.775852] pci :03:00.0: reg 0x18: [mem 0x40-0x43 
64bit pref]
<6> [181.775886] pci :03:00.0: reg 0x30: [mem 0xffe0-0x pref]
<6> [181.776058] pci :03:00.0: ASPM: overriding L1 acceptable latency from 
0x0 to 0x7
<6> [181.776073] pci :03:00.0: Video device with shadowed ROM at [mem 
0x000c-0x000d]
<6> [181.776209] pci :03:00.0: PME# supported from D0 D3hot
<6> [181.776869] pci :03:00.0: vgaarb: setting as boot VGA device
<6> [181.776878] pci :03:00.0: vgaarb: bridge control possible
<6> [181.776881] pci :03:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
<6> [181.777052] pci :03:00.0: Adding to iommu group 1
<4> [181.777164] 
<4> [181.777169] ==
<4> [181.777176] WARNING: possible circular locking dependency detected
<4> [181.777182] 6.0.0-rc5-CI_DRM_12145-g2dc9ea03abff+ #1 Not tainted
<4> [181.777189] --
<4> [181.777196] core_hotunplug/1240 is trying to acquire lock:
<4> [181.777202] 8881029b33b0 (>iova_cookie->mutex){+.+.}-{3:3}, 
at: iommu_setup_dma_ops+0xd7/0x440
<4> [181.777218] 
but task is already holding lock:
<4> [181.777225] 8881010c9e78 (&(>bus_notifier)->rwsem){}-{3:3}, 
at: blocking_notifier_call_chain+0x20/0x50
<4> [181.777242] 
which lock already depends on the new lock.
<4> [181.777250] 
the existing dependency chain (in reverse order) is:
<4> [181.777258] 
-> #3 (&(>bus_notifier)->rwsem){}-{3:3}:
<4> [181.777268]lock_acquire+0xd3/0x310
<4> [181.777274]down_read+0x39/0x140
<4> [181.777281]blocking_notifier_call_chain+0x20/0x50
<4> [181.777289]device_add+0x3c1/0x900
<4> [181.777295]platform_device_add+0x108/0x240
<4> [181.777302]coretemp_cpu_online+0xe1/0x15e [coretemp]
<4> [181.777310]cpuhp_invoke_callback+0x181/0x8a0
<4> [181.777318]cpuhp_thread_fun+0x188/0x1f0
<4> [181.777325]smpboot_thread_fn+0x1b5/0x260
<4> [181.777332]kthread+0xed/0x120
<4> [181.777337]ret_from_fork+0x1f/0x30
<4> [181.777343] 
-> #2 (cpuhp_state-up){+.+.}-{0:0}:
<4> [181.777352]lock_acquire+0xd3/0x310
<4> [181.777358]cpuhp_thread_fun+0xa6/0x1f0
<4> [181.777364]smpboot_thread_fn+0x1b5/0x260
<4> [181.777370]kthread+0xed/0x120
<4> [181.777375]ret_from_fork+0x1f/0x30
<4> [181.777381] 
-> #1 (cpu_hotplug_lock){}-{0:0}:
<4> [181.777390]lock_acquire+0xd3/0x310
<4> [181.777395]__cpuhp_state_add_instance+0x43/0x1c0
<4> [181.777402]iova_domain_init_rcaches+0x199/0x1c0
<4> [181.777409]

Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering

[Kumar Valsan, Prathap]

On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > 
> > On 16/09/2022 02:43, Matt Roper wrote:
> > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > that a subset of these are of a "GAM" subclass that has unique rules and
> > > doesn't followed regular mslice steering behavior.
> > > 
> > >   * Xe_HP SDV:  GAM ranges must always be steered to 0,0.  These
> > > registers share the regular steering control register (0xFDC) with
> > > other steering types
> > > 
> > >   * DG2:  GAM ranges must always be steered to 1,0.  GAM registers have a
> > > dedicated steering control register (0xFE0) so we can set the value
> > > once at startup and rely on implicit steering.  Technically the
> > > hardware default should already be set to 1,0 properly, but it never
> > > hurts to ensure that in the driver.
> > 
> > Do you have any data on whether the "technically should" holds in practice?
> > What would be the consequences of some platform/machine surprising us here?
> 
> The bspec indicates the hardware default value is already the necessary
> 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> it to 0,0 by accident.  I don't have any evidence that has ever actually
> happened, but explicitly re-programming it to 1,0 in the patch here is a
> defensive measure just to be safe.
> 
> If we didn't have this patch _and_ some firmware screwed up the GAM
> steering target, then presumably we might read back garbage or 0 from
> GAM registers in places where we should have received a real value.
Will firmware ever touch the steering target registers. As i was going
through the respective hsd. The software driver impact is marked as none
so wondering if this change is really required ?

Thanks,
Prathap
> 
> 
> Matt
> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > 
> > > Bspec: 66534
> > > Signed-off-by: Matt Roper 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 24 +++--
> > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
> > >   drivers/gpu/drm/i915/gt/intel_gt_types.h|  1 +
> > >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > >   4 files changed, 34 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > index e79405a45312..a2047a68ea7a 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > >   "L3BANK",
> > >   "MSLICE",
> > >   "LNCF",
> > > + "GAM",
> > >   "INSTANCE 0",
> > >   };
> > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range 
> > > icl_l3bank_steering_table[] = {
> > >   {},
> > >   };
> > > +/*
> > > + * Although the bspec lists more "MSLICE" ranges than shown here, some 
> > > of those
> > > + * are of a "GAM" subclass that has special rules.  Thus we use a 
> > > separate
> > > + * GAM table farther down for those.
> > > + */
> > >   static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
> > > - { 0x004000, 0x004AFF },
> > > - { 0x00C800, 0x00CFFF },
> > >   { 0x00DD00, 0x00DDFF },
> > >   { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > >   {},
> > >   };
> > > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > > + { 0x004000, 0x004AFF },
> > > + { 0x00C800, 0x00CFFF },
> > > + {},
> > > +};
> > > +
> > >   static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
> > >   { 0x00B000, 0x00B0FF },
> > >   { 0x00D800, 0x00D8FF },
> > > @@ -114,9 +124,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > >   } else if (IS_DG2(i915)) {
> > >   gt->steering_table[MSLICE] = 
> > > xehpsdv_mslice_steering_table;
> > >   gt->steering_table[LNCF] = dg2_lncf_steering_table;
> > > + /*
> > > +  * No need to hook up the GAM table since it has a dedicated
> > > +  * steering control register on DG2 and can use implicit
> > > +  * steering.
> > > +  */
> > >   } else if (IS_XEHPSDV(i915)) {
> > >   gt->steering_table[MSLICE] = 
> > > xehpsdv_mslice_steering_table;
> > >   gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
> > > + gt->steering_table[GAM] = xehpsdv_gam_steering_table;
> > >   } else if (GRAPHICS_VER(i915) >= 11 &&
> > >  GRAPHICS_VER_FULL(i915) < IP_VER(12, 50)) {
> > >   gt->steering_table[L3BANK] = icl_l3bank_steering_table;
> > > @@ -351,6 +367,10 @@ static void get_nonterminated_steering(struct 
> > > intel_gt *gt,
> > >   *group = __ffs(gt->info.mslice_mask) << 1;
> > >   *instance = 0;  /* unused */
> > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Restrict forced preemption to the active context

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Restrict forced preemption to the active context
URL   : https://patchwork.freedesktop.org/series/108830/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164_full -> Patchwork_108830v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-tglu 

Known issues


  Here are the changes found in Patchwork_108830v1_full that come from known 
issues:

### CI changes ###

 Issues hit 

  * 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], [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], [FAIL][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50]) ([i915#4338])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb7/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb7/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-snb2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb7/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb7/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb5/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/shard-snb4/boot.html
   [43]: 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload

[Das, Nirmoy]

On 9/9/2022 10:55 AM, Tvrtko Ursulin wrote:


On 08/09/2022 21:07, Nirmoy Das wrote:

i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.

Call i915_gem_drain_workqueue() to catch all RCU delayed work.

Suggested-by: Chris Wilson 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/i915_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 0f49ec9d494a..e8a053eaaa89 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1254,7 +1254,7 @@ void i915_gem_init_early(struct 
drm_i915_private *dev_priv)

    void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
  {
-    i915_gem_drain_freed_objects(dev_priv);
+    i915_gem_drain_workqueue(dev_priv);
  GEM_BUG_ON(!llist_empty(_priv->mm.free_list));
  GEM_BUG_ON(atomic_read(_priv->mm.free_count));
  drm_WARN_ON(_priv->drm, dev_priv->mm.shrink_count);



Help me spot the place where RCU free worker schedules itself back to 
free more objects - if I got the rationale here right?

(Sorry for late reply, was on leave last week.)

I had to clarify this with Chris. So when driver frees a obj, it does 
dma_resv_fini() which will drop reference


for all the fences in it and a fence might  reference to an object and 
upon release of that fence can trigger a  release reference to an object.


Regards,

Nirmoy





Regards,

Tvrtko

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Don't use port enum as register offset

[Patchwork]

== Series Details ==

Series: drm/i915/display: Don't use port enum as register offset
URL   : https://patchwork.freedesktop.org/series/108833/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108833v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_108833v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108833v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/index.html

Participating hosts (34 -> 45)
--

  Additional (12): fi-rkl-11600 bat-dg1-5 bat-dg2-8 bat-adlm-1 fi-icl-u2 
bat-dg2-9 bat-adlp-6 bat-adln-1 bat-jsl-3 bat-rplp-1 bat-rpls-1 bat-dg2-11 
  Missing(1): fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108833v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-rkl-11600:   NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-rkl-11600/igt@i915_module_l...@load.html
- bat-dg1-5:  NOTRUN -> [DMESG-WARN][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-dg1-5/igt@i915_module_l...@load.html
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-rkl-guc/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-rkl-guc/igt@i915_module_l...@load.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_module_load@load:
- {bat-rpls-1}:   NOTRUN -> [DMESG-WARN][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-rpls-1/igt@i915_module_l...@load.html
- {bat-adln-1}:   NOTRUN -> [DMESG-WARN][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-adln-1/igt@i915_module_l...@load.html
- {bat-rplp-1}:   NOTRUN -> [DMESG-WARN][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-rplp-1/igt@i915_module_l...@load.html
- {bat-dg2-9}:NOTRUN -> [DMESG-WARN][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-dg2-9/igt@i915_module_l...@load.html
- {bat-adlp-6}:   NOTRUN -> [DMESG-WARN][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-adlp-6/igt@i915_module_l...@load.html
- {bat-adlm-1}:   NOTRUN -> [DMESG-WARN][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-adlm-1/igt@i915_module_l...@load.html
- {bat-dg2-8}:NOTRUN -> [DMESG-WARN][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/bat-dg2-8/igt@i915_module_l...@load.html

  
Known issues


  Here are the changes found in Patchwork_108833v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][13] ([i915#4613]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@i915_module_load@load:
- fi-adl-ddr5:[PASS][14] -> [INCOMPLETE][15] ([i915#1982])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-adl-ddr5/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-adl-ddr5/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][16] -> [INCOMPLETE][17] ([i915#4785])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][18] -> [INCOMPLETE][19] ([i915#146] / 
[i915#6712])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][20] ([fdo#111827]) +8 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

 

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

[Andi Shyti]

Hi Badal,

> > > +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,
> > > +};
> > 
> > what's the point for splitting so much? Can't you just send the
> > hwmon driver all at once? With this patch you are not actually
> > doing anything useful. In my opinion this should be squashed with
> > the next ones.

> During discussion in cover letter of rev0 series we decided to create
> separate infrastructure patch, as we wanted to keep kconfig, i915 hwmon
> structures and new file addition in separate patch. Further feature wise we
> kept adding new patches.

I don't really like this patch splitting, but it's my fault I
haven't reviewed it already in v1. Please, ignore then.

Andi

Re: [Intel-gfx] [PATCH] drm/i915/gt: Restrict forced preemption to the active context

[Andi Shyti]

Hi Andrzej and Chris,

On Wed, Sep 21, 2022 at 03:52:58PM +0200, Andrzej Hajda wrote:
> From: Chris Wilson 
> 
> When we submit a new pair of contexts to ELSP for execution, we start a
> timer by which point we expect the HW to have switched execution to the
> pending contexts. If the promotion to the new pair of contexts has not
> occurred, we declare the executing context to have hung and force the
> preemption to take place by resetting the engine and resubmitting the
> new contexts.
> 
> This can lead to an unfair situation where almost all of the preemption
> timeout is consumed by the first context which just switches into the
> second context immediately prior to the timer firing and triggering the
> preemption reset (assuming that the timer interrupts before we process
> the CS events for the context switch). The second context hasn't yet had
> a chance to yield to the incoming ELSP (and send the ACk for the
> promotion) and so ends up being blamed for the reset.
> 
> If we see that a context switch has occurred since setting the
> preemption timeout, but have not yet received the ACK for the ELSP
> promotion, rearm the preemption timer and check again. This is
> especially significant if the first context was not schedulable and so
> we used the shortest timer possible, greatly increasing the chance of
> accidentally blaming the second innocent context.
> 
> Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
> Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on 
> schedule-out")
> Reported-by: Tvrtko Ursulin 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Andi Shyti 
> Reviewed-by: Andrzej Hajda 
> Tested-by: Andrzej Hajda 
> Cc:  # v5.5+
> ---
> Hi,
> 
> This patch is upstreamed from internal branch. So I have removed
> R-B by Andi. Andi let me know if your R-B still apply.

yes, I know this patch and my r-b holds:

Reviewed-by: Andi Shyti 

Anyway, thanks Chris for the comments and the clear explanation
both in the commit log and in between the code.

Andi

> Regards
> Andrzej
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_types.h  | 15 +
>  .../drm/i915/gt/intel_execlists_submission.c  | 21 ++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 633a7e5dba3b4b..6b5d4ea22b673b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -165,6 +165,21 @@ struct intel_engine_execlists {
>*/
>   struct timer_list preempt;
>  
> + /**
> +  * @preempt_target: active request at the time of the preemption request
> +  *
> +  * We force a preemption to occur if the pending contexts have not
> +  * been promoted to active upon receipt of the CS ack event within
> +  * the timeout. This timeout maybe chosen based on the target,
> +  * using a very short timeout if the context is no longer schedulable.
> +  * That short timeout may not be applicable to other contexts, so
> +  * if a context switch should happen within before the preemption
> +  * timeout, we may shoot early at an innocent context. To prevent this,
> +  * we record which context was active at the time of the preemption
> +  * request and only reset that context upon the timeout.
> +  */
> + const struct i915_request *preempt_target;
> +
>   /**
>* @ccid: identifier for contexts submitted to this engine
>*/
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 4b909cb88cdfb7..c718e6dc40b515 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1241,6 +1241,9 @@ static unsigned long active_preempt_timeout(struct 
> intel_engine_cs *engine,
>   if (!rq)
>   return 0;
>  
> + /* Only allow ourselves to force reset the currently active context */
> + engine->execlists.preempt_target = rq;
> +
>   /* Force a fast reset for terminated contexts (ignoring sysfs!) */
>   if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
>   return INTEL_CONTEXT_BANNED_PREEMPT_TIMEOUT_MS;
> @@ -2427,8 +2430,24 @@ static void execlists_submission_tasklet(struct 
> tasklet_struct *t)
>   GEM_BUG_ON(inactive - post > ARRAY_SIZE(post));
>  
>   if (unlikely(preempt_timeout(engine))) {
> + const struct i915_request *rq = *engine->execlists.active;
> +
> + /*
> +  * If after the preempt-timeout expired, we are still on the
> +  * same active request/context as before we initiated the
> +  * preemption, reset the engine.
> +  *
> +  * However, if we have processed a CS event to switch contexts,
> +  * but not yet processed 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Don't use port enum as register offset

[Patchwork]

== Series Details ==

Series: drm/i915/display: Don't use port enum as register offset
URL   : https://patchwork.freedesktop.org/series/108833/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

[Nilawar, Badal]

On 21-09-2022 18:14, Andi Shyti wrote:

Hi Badal,


+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,
+};


what's the point for splitting so much? Can't you just send the
hwmon driver all at once? With this patch you are not actually
doing anything useful. In my opinion this should be squashed with
the next ones.
During discussion in cover letter of rev0 series we decided to create 
separate infrastructure patch, as we wanted to keep kconfig, i915 hwmon 
structures and new file addition in separate patch. Further feature wise 
we kept adding new patches.



+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+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.

I think we can switch to devm_kzalloc.

Regards,
Badal


Andi


+   i915->hwmon = NULL;
+   kfree(hwmon);
+   return;
+   }
+
+   ddat->hwmon_dev = hwmon_dev;
+}
+
+void i915_hwmon_unregister(struct drm_i915_private *i915)
+{
+   struct i915_hwmon *hwmon;
+   struct hwm_drvdata *ddat;
+
+   hwmon = fetch_and_zero(>hwmon);
+   if (!hwmon)
+   return;
+
+   ddat = >ddat;
+   if (ddat->hwmon_dev)
+   hwmon_device_unregister(ddat->hwmon_dev);
+
+   mutex_destroy(>hwmon_lock);
+   kfree(hwmon);
+}
diff --git a/drivers/gpu/drm/i915/i915_hwmon.h 
b/drivers/gpu/drm/i915/i915_hwmon.h
new file mode 100644
index ..7ca9cf2c34c9
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_HWMON_H__
+#define __I915_HWMON_H__
+
+struct drm_i915_private;
+
+#if IS_REACHABLE(CONFIG_HWMON)
+void i915_hwmon_register(struct drm_i915_private *i915);
+void i915_hwmon_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_hwmon_register(struct drm_i915_private *i915) { };
+static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
+#endif
+
+#endif /* __I915_HWMON_H__ */
--
2.25.1

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: Add missing invalidate to g4x wm readout

[Lisovskiy, Stanislav]

On Wed, Jun 22, 2022 at 06:54:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's not forget to mark the unused watermark levels as invalid
> after the readout. The vlv/chv codepath has this but the g4x
> didn't for some reason.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 45ec00e2e3c4..734deb0bd867 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6915,6 +6915,8 @@ void g4x_wm_get_hw_state(struct drm_i915_private 
> *dev_priv)
>plane_id, USHRT_MAX);
>   g4x_raw_fbc_wm_set(crtc_state, level, USHRT_MAX);
>  
> + g4x_invalidate_wms(crtc, active, level);
> +
>   crtc_state->wm.g4x.optimal = *active;
>   crtc_state->wm.g4x.intermediate = *active;
>  
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Simplify up vlv watermark sanitation

[Lisovskiy, Stanislav]

On Wed, Jun 22, 2022 at 06:54:47PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We can simplify the vlv watermark sanitation by reusing the
> second half of vlv_compute_pipe_wm() to convert the sanitized
> raw watermarks into the proper form to be used as the
> optimal/intermediate watermarks.
> 
> Also to be consistent with normal watermark computation the sanitized
> watermarks should be all 0 for any disabled plane. Previously we
> zeroed out the watermarks only up to the level (ie. PM2/5/DVDFS)
> that was enabled.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 556fcdfb75f1..45ec00e2e3c4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7100,30 +7100,27 @@ void vlv_wm_sanitize(struct drm_i915_private 
> *dev_priv)
>   to_intel_crtc_state(crtc->base.state);
>   struct intel_plane_state *plane_state =
>   to_intel_plane_state(plane->base.state);
> - struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
> - const struct vlv_fifo_state *fifo_state =
> - _state->wm.vlv.fifo_state;
>   enum plane_id plane_id = plane->id;
> - int level;
> + int level, num_levels = intel_wm_num_levels(dev_priv);
>  
>   if (plane_state->uapi.visible)
>   continue;
>  
> - for (level = 0; level < wm_state->num_levels; level++) {
> + for (level = 0; level < num_levels; level++) {
>   struct g4x_pipe_wm *raw =
>   _state->wm.vlv.raw[level];
>  
>   raw->plane[plane_id] = 0;
> -
> - wm_state->wm[level].plane[plane_id] =
> - vlv_invert_wm_value(raw->plane[plane_id],
> - 
> fifo_state->plane[plane_id]);
>   }
>   }
>  
>   for_each_intel_crtc(_priv->drm, crtc) {
>   struct intel_crtc_state *crtc_state =
>   to_intel_crtc_state(crtc->base.state);
> + int ret;
> +
> + ret = _vlv_compute_pipe_wm(crtc_state);
> + drm_WARN_ON(_priv->drm, ret);
>  
>   crtc_state->wm.vlv.intermediate =
>   crtc_state->wm.vlv.optimal;
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Simplify up g4x watermark sanitation

[Lisovskiy, Stanislav]

On Wed, Jun 22, 2022 at 06:54:46PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We can simplify the g4x watermark sanitation by reusing the
> second half of g4x_compute_pipe_wm() to convert the sanitized
> raw watermarks into the proper form to be used as the
> optimal/intermediate watermarks.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 21 +++--
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4ea43fa73075..556fcdfb75f1 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6951,37 +6951,30 @@ void g4x_wm_sanitize(struct drm_i915_private 
> *dev_priv)
>   to_intel_crtc_state(crtc->base.state);
>   struct intel_plane_state *plane_state =
>   to_intel_plane_state(plane->base.state);
> - struct g4x_wm_state *wm_state = _state->wm.g4x.optimal;
>   enum plane_id plane_id = plane->id;
> - int level;
> + int level, num_levels = intel_wm_num_levels(dev_priv);
>  
>   if (plane_state->uapi.visible)
>   continue;
>  
> - for (level = 0; level < 3; level++) {
> + for (level = 0; level < num_levels; level++) {
>   struct g4x_pipe_wm *raw =
>   _state->wm.g4x.raw[level];
>  
>   raw->plane[plane_id] = 0;
> - wm_state->wm.plane[plane_id] = 0;
> - }
>  
> - if (plane_id == PLANE_PRIMARY) {
> - for (level = 0; level < 3; level++) {
> - struct g4x_pipe_wm *raw =
> - _state->wm.g4x.raw[level];
> + if (plane_id == PLANE_PRIMARY)
>   raw->fbc = 0;
> - }
> -
> - wm_state->sr.fbc = 0;
> - wm_state->hpll.fbc = 0;
> - wm_state->fbc_en = false;
>   }
>   }
>  
>   for_each_intel_crtc(_priv->drm, crtc) {
>   struct intel_crtc_state *crtc_state =
>   to_intel_crtc_state(crtc->base.state);
> + int ret;
> +
> + ret = _g4x_compute_pipe_wm(crtc_state);
> + drm_WARN_ON(_priv->drm, ret);
>  
>   crtc_state->wm.g4x.intermediate =
>   crtc_state->wm.g4x.optimal;
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power

[Gupta, Anshuman]

On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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: Updated date, kernel version in documentation

Cc: Sujaritha Sundaresan 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
---
  .../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 94101f818a70..cc70596fff44 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:  September 2022
+KernelVersion: 6
+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:  September 2022
+KernelVersion: 6
+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: September 2022
  KernelVersion:6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index a42cfad78bef..bd9ba312c474 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_VOLTAGE1000
  #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)) 

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Split vlv_compute_pipe_wm() into two

[Lisovskiy, Stanislav]

On Wed, Jun 22, 2022 at 06:54:45PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Split vlv_compute_pipe_wm() into two halves. The first half computes
> the new raw watermarks, and the second half munges those up into real
> watermarks for the particular pipe.
> 
> We can reuse the second half for watermark sanitation as well.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 114 ++--
>  1 file changed, 64 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 395ed3c832d6..4ea43fa73075 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1904,64 +1904,17 @@ static bool vlv_raw_crtc_wm_is_valid(const struct 
> intel_crtc_state *crtc_state,
>   vlv_raw_plane_wm_is_valid(crtc_state, PLANE_CURSOR, level);
>  }
>  
> -static int vlv_compute_pipe_wm(struct intel_atomic_state *state,
> -struct intel_crtc *crtc)
> +static int _vlv_compute_pipe_wm(struct intel_crtc_state *crtc_state)
>  {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct intel_crtc_state *crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
>   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
>   const struct vlv_fifo_state *fifo_state =
>   _state->wm.vlv.fifo_state;
>   u8 active_planes = crtc_state->active_planes & ~BIT(PLANE_CURSOR);
>   int num_active_planes = hweight8(active_planes);
> - bool needs_modeset = drm_atomic_crtc_needs_modeset(_state->uapi);
> - const struct intel_plane_state *old_plane_state;
> - const struct intel_plane_state *new_plane_state;
> - struct intel_plane *plane;
>   enum plane_id plane_id;
> - int level, ret, i;
> - unsigned int dirty = 0;
> -
> - for_each_oldnew_intel_plane_in_state(state, plane,
> -  old_plane_state,
> -  new_plane_state, i) {
> - if (new_plane_state->hw.crtc != >base &&
> - old_plane_state->hw.crtc != >base)
> - continue;
> -
> - if (vlv_raw_plane_wm_compute(crtc_state, new_plane_state))
> - dirty |= BIT(plane->id);
> - }
> -
> - /*
> -  * DSPARB registers may have been reset due to the
> -  * power well being turned off. Make sure we restore
> -  * them to a consistent state even if no primary/sprite
> -  * planes are initially active.
> -  */
> - if (needs_modeset)
> - crtc_state->fifo_changed = true;
> -
> - if (!dirty)
> - return 0;
> -
> - /* cursor changes don't warrant a FIFO recompute */
> - if (dirty & ~BIT(PLANE_CURSOR)) {
> - const struct intel_crtc_state *old_crtc_state =
> - intel_atomic_get_old_crtc_state(state, crtc);
> - const struct vlv_fifo_state *old_fifo_state =
> - _crtc_state->wm.vlv.fifo_state;
> -
> - ret = vlv_compute_fifo(crtc_state);
> - if (ret)
> - return ret;
> -
> - if (needs_modeset ||
> - memcmp(old_fifo_state, fifo_state,
> -sizeof(*fifo_state)) != 0)
> - crtc_state->fifo_changed = true;
> - }
> + int level;
>  
>   /* initially allow all levels */
>   wm_state->num_levels = intel_wm_num_levels(dev_priv);
> @@ -2008,6 +1961,67 @@ static int vlv_compute_pipe_wm(struct 
> intel_atomic_state *state,
>   return 0;
>  }
>  
> +static int vlv_compute_pipe_wm(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> +{
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + bool needs_modeset = drm_atomic_crtc_needs_modeset(_state->uapi);
> + const struct intel_plane_state *old_plane_state;
> + const struct intel_plane_state *new_plane_state;
> + struct intel_plane *plane;
> + unsigned int dirty = 0;
> + int i;
> +
> + for_each_oldnew_intel_plane_in_state(state, plane,
> +  old_plane_state,
> +  new_plane_state, i) {
> + if (new_plane_state->hw.crtc != >base &&
> + old_plane_state->hw.crtc != >base)
> + continue;
> +
> + if (vlv_raw_plane_wm_compute(crtc_state, new_plane_state))
> + dirty |= BIT(plane->id);
> + }
> +
> + /*
> +  * DSPARB registers may have been reset due to the
> +  * power well being turned off. Make sure we restore
> +  * them to a consistent state even if no primary/sprite
> +  * planes are 

Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes

[Maxime Ripard]

Hi,

On Sun, Sep 11, 2022 at 06:48:50AM +0200, Mateusz Kwiatkowski wrote:
> >> Those extra vbp lines will be treated as a black bar at the top of the 
> >> frame,
> >> and extra vfp lines will be at the bottom of the frame.
> >>
> >> However if someone specifies e.g. 720x604, there's nothing more you could
> >> remove from vfp, so your only option is to reduce vbp compared to the 
> >> standard
> >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will 
> >> not be
> >> centered, the topmost lines will get cropped out, but that's the best we 
> >> can do
> >> and if someone is requesting such resolution, they most likely want to 
> >> actually
> >> access the VBI to e.g. emit teletext.
> >>
> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then
> >> increases both vfp and vbp proportionately. This puts vsync dead center in 
> >> the
> >> VBI, which is not how it's supposed to be - and that in turn causes the 
> >> image
> >> to be significantly shifted upwards.
> >>
> >> I hope this makes more sense to you now.
> >
> > I'm really struggling with this, so thanks for explaining this further
> > (and patiently ;))
> >
> > If I get this right, what you'd like to change is this part of the
> > calculus (simplified a bit, and using PAL, 576i):
> >
> >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5
> >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6
> >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6
> >
> >   porches = params->num_lines - vactive - vslen; // 43
> >   porches_rem = porches - vfp_min - vbp_min; // 32
> >
> >   vfp = vfp_min + (porches_rem / 2); // 21
> >   vbp = porches - vfp; // 22
> >
> > Which is indeed having sync centered.
> >
> > I initially changed it to:
> >
> >   vfp = vfp_min; // 6
> >   vbp = num_lines - vactive - vslen - vfp; // 38
> >
> > Which is close enough for 576i, but at 480i/50Hz would end up with 134,
> > so still fairly far off.
> >
> > I guess your suggestion would be along the line of:
> >
> >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5
> >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38
> >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6
> >
> >   porches = params->num_lines - vactive - vslen; // 0
> >   porches_rem = porches - vfp_min - vbp_min; // 0
> >
> >   vfp = vfp_min + (porches_rem / 2); // 5
> >   vbp = porches - vfp; // 38
> >
> > Which is still close enough for 576i, but for 480i would end up with:
> >
> >   porches = params->num_lines - vactive - vslen; // 139
> >   porches_rem = porches - vfp_min - vbp_min; // 96
> >
> >   vfp = vfp_min + (porches_rem / 2); // 53
> >   vbp = porches - vfp; // 86
> >
> > Right?
> 
> Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also
> "close enough" to the values I suggested above.
> 
> If you substitute values for true 60 Hz "NTSC" 480i, you should also get 
> values
> that are "close enough" to the official spec.
> 
> The only thing I'd conceptually change is that the 38 lines is not really
> "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to 
> lower
> this value if someone wants more active lines than the official 486/576.

porches_rem is an int, so if vactive > (num_lines + vslen + vfp_min +
vbp_min), porches_rem is going to be negative and we'll remove equally
between vfp and vbp to match what's been asked

So I believe this should work fine?

Maxime


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting

[Nilawar, Badal]

On 21-09-2022 17:15, Gupta, Anshuman wrote:



On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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)
   - Update date, kernel version in documentation

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 
---
  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 +++
  drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
  drivers/gpu/drm/i915/i915_reg.h   |   5 +
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |   6 +
  4 files changed, 187 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

index e2974f928e58..bc061238e35c 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:    September 2022
+KernelVersion:    6
+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:    September 2022
+KernelVersion:    6
+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 45745afa5c5b..5183cf51a49b 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;
+    bits_to_set = FIELD_PREP(field_msk, nval);
+
+    hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
+    bits_to_clear, bits_to_set);
+}
+
  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Restrict forced preemption to the active context

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Restrict forced preemption to the active context
URL   : https://patchwork.freedesktop.org/series/108830/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108830v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/index.html

Participating hosts (34 -> 44)
--

  Additional (11): fi-rkl-11600 bat-dg1-5 bat-dg2-8 bat-adlm-1 fi-icl-u2 
bat-dg2-9 bat-adlp-6 bat-adln-1 bat-jsl-3 bat-rpls-1 bat-dg2-11 
  Missing(1): fi-bdw-samus 

Known issues


  Here are the changes found in Patchwork_108830v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@fb...@nullptr.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_108830v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4079]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3012])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#1155])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#6621])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4215])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_busy@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#1845] / [i915#4303])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@kms_b...@basic.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([fdo#111827]) +8 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([i915#4103])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108830v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
- fi-icl-u2:  NOTRUN -> [SKIP][20] 

[Intel-gfx] [PATCH] drm/i915/display: Don't use port enum as register offset

[Balasubramani Vivekanandan]

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.

Signed-off-by: Balasubramani Vivekanandan 
---
 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  | 62 +++--
 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(+), 148 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),
  500))
drm_err(_priv->drm, "DDI port:%c buffer idle\n",
@@ -1400,11 +1400,11 @@ static void gen11_dsi_disable_port(struct intel_encoder 
*encoder)
 
gen11_dsi_ungate_clocks(encoder);
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),
 8))
drm_err(_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4c543e8205ca..ab472fa757d8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2436,8 +2436,8 @@ static enum port dvo_port_to_port(struct drm_i915_private 
*i915,
[PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1 },
[PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1 },
[PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1 },
-   [PORT_D_XELPD] = { DVO_PORT_HDMID, 

Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes

[Maxime Ripard]

Hi,

Thanks again for your help

On Sun, Sep 11, 2022 at 06:30:39AM +0200, kFYatek wrote:
> W dniu 9.09.2022 o 16:00, Maxime Ripard pisze:
> > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> >> The "canonical" modelines (at least for vc4's VEC, see the notes below):
> >>
> >> - (vfp==4, vsync==6, vbp==39) for 576i
> >> - (vfp==7, vsync==6, vbp==32) for 480i
> >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally 
> >> specified)
> >
> > It's not clear to me either how you come up with those timings?
> 
> Well, experimentally ;)
> 
> The values for 480i and 576i are the values currently used by the downstream
> kernel, and those in turn has been copied from the firmware (or more 
> precisely,
> I chose them so that the PV registers end up the same as the values set by the
> firmware).
> 
> I also checked with an oscilloscope that the waveforms look as they should.
> VEC doesn't exactly handle the half-lines at the start and end of the odd 
> field
> right, but otherwise, the blanking and sync pulses are where they should be.
> 
> The 486i values has been constructed from the 480i ones according to the
> calculations from cross-referencing SMPTE documents, see my previous e-mail.
> 
> I know this is perhaps unsatisfactory ;) I don't have access to the VC4
> documentation, so this was _almost_ reverse engineering for me.

It's not really that it's unsatisfactory, but the function here is
supposed to be generic and thus generate a mode that is supposed to be a
somewhat reasonable for a given set of parameters.

If the vc4 driver needs some adjustments, then it needs to be out of
that function and into the vc4 driver. And this is pretty much what I
struggle with: I have a hard time (on top of everything else) figuring
out what is supposed to be specific to vc4, and what isn't.

I guess your 480i example, since it follows the spec, is fine, but I'm
not sure for 576i.
Maxime


signature.asc
Description: PGP signature

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Restrict forced preemption to the active context

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Restrict forced preemption to the active context
URL   : https://patchwork.freedesktop.org/series/108830/
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/gt: Restrict forced preemption to the active context

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Restrict forced preemption to the active context
URL   : https://patchwork.freedesktop.org/series/108830/
State : warning

== Summary ==

Error: dim checkpatch failed
1f75a439c5ab drm/i915/gt: Restrict forced preemption to the active context
-:103: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Chris Wilson ' != 'Signed-off-by: 
Chris Wilson '

total: 0 errors, 1 warnings, 0 checks, 55 lines checked

Re: [Intel-gfx] [PATCH v10 3/9] compiler_types.h: Add assert_type to catch type mis-match while compiling

[Gwan-gyeong Mun]

On 9/13/22 3:01 PM, Kees Cook wrote:

On Fri, Sep 09, 2022 at 07:59:07PM +0900, Gwan-gyeong Mun wrote:

It adds assert_type and assert_typable macros to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added assert_type() macro uses the _Static_assert() keyword (which is
introduced in C11) to generate a build break when the types are different
and can be used to detect explicit build errors.
Unlike the assert_type() macro, assert_typable() macro allows a constant
value as the second argument.

Suggested-by: Kees Cook 
Signed-off-by: Gwan-gyeong Mun 
Cc: Thomas Hellström 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Jani Nikula 
Cc: Andi Shyti 
Cc: Mauro Carvalho Chehab 
Cc: Andrzej Hajda 
Cc: Kees Cook 
---
  include/linux/compiler_types.h | 39 ++
  1 file changed, 39 insertions(+)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 4f2a819fd60a..19cc125918bb 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -294,6 +294,45 @@ struct ftrace_likely_data {
  /* Are two types/vars the same type (ignoring qualifiers)? */
  #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
  
+/**

+ * assert_type - break compile if the first argument's data type and the second
+ *   argument's data type are not the same
+ *
+ * @t1: data type or variable
+ * @t2: data type or variable
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). It determines whether the first argument's data type and the second
+ * argument's data type are the same while compiling, and it breaks compile if
+ * the two types are not the same.
+ * See also assert_typable().
+ */
+#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
+
+/**
+ * assert_typable - break compile if the first argument's data type and the
+ *  second argument's data type are not the same
+ *
+ * @t: data type or variable
+ * @n: data type or variable or constant value
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). Unlike the assert_type() macro, this macro allows a constant value
+ * as the second argument. And if the second argument is a constant value, it
+ * always passes. And it doesn't mean that the types are explicitly the same.
+ * When a constant value is used as the second argument, if you need an
+ * overflow check when assigning a constant value to a variable of the type of
+ * the first argument, you can use the overflows_type() macro. When a constant


I wonder if the overflows_type() check should happen in this test? It
seems weird that assert_typable(u8, 1024) would pass...

Yes, that's right. If a constant is used as an argument here, it seems 
necessary to check whether an overflow occurs when the constant value is 
assigned to the target type or target variable.



+ * value is not used as a second argument, it determines whether the first
+ * argument's data type and the second argument's data type are the same while
+ * compiling, and it breaks compile if the two types are not the same.
+ * See also assert_type() and overflows_type().
+ */
+#define assert_typable(t, n) _Static_assert(__builtin_constant_p(n) || \
+   __same_type(t, typeof(n)))


Totally untested -- I'm not sure if this gets the right semantics for
constant expressoins, etc...

static_assert(__builtin_choose_expression(__builtin_constant_p(n), \
overflows_type(n, typeof(t)), \
__same_type(t, typeof(n


However, if we change the macro in the form below, the "error: 
expression in static assertion is not constant" error occurs due to the 
restriction [1][2] of _Static_assert() as you mentioned.
( overflows_type() internally uses the __builtin_add_overflow() builtin 
function [3], which returns a bool type.)


#define assert_same_typable(t, n) static_assert( \
__builtin_choose_expr(__builtin_constant_p(n),   \
  overflows_type(n, typeof(t)) == false, \
  __same_type(t, typeof(n

Can I have your opinion on the new addition of 
overflows_type_return_const_expr(), which returns a constant value at 
compile time to check whether an overflow occurs when assigning a 
constant value to an argument type?
If it is allowable to add the macro,   I would try to use the macro that 
returns "an integer constant expression" after checking for overflow 
between the constant value and the argument type at compile time with 
reference to implemented in the previous version. [4] or [5]


#define assert_same_typable(t, n) 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Start cleaning up the DPLL ID mess

[Patchwork]

== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess
URL   : https://patchwork.freedesktop.org/series/108827/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164_full -> Patchwork_108827v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_108827v1_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([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], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24]) ([i915#4392]) -> ([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], 
[PASS][47], [PASS][48], [PASS][49])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk2/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk2/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk2/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk3/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk3/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk3/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk5/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk6/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk6/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk7/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk7/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/shard-glk7/boot.html
   [43]: 

Re: [Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements

[Maxime Ripard]

On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 07.09.2022 12.36, skrev Stefan Wahren:
> > Hi Maxime,
> > 
> > Am 05.09.22 um 16:57 schrieb Maxime Ripard:
> >> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
> >>>
> >>> Den 01.09.2022 21.35, skrev Noralf Trønnes:
> 
>  I have finally found a workaround for my kernel hangs.
> 
>  Dom had a look at my kernel and found that the VideoCore was fine, and
>  he said this:
> 
> > That suggests cause of lockup was on arm side rather than VC side.
> >
> > But it's hard to diagnose further. Once you've had a peripheral not
> > respond, the AXI bus locks up and no further operations are possible.
> > Usual causes of this are required clocks being stopped or domains
> > disabled and then trying to access the hardware.
> >
>  So when I got this on my 64-bit build:
> 
>  [  166.702171] SError Interrupt on CPU1, code 0xbf02 --
>  SError
>  [  166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: G    W
>   5.19.0-rc6-00096-gba7973977976-dirty #1
>  [  166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
>  [  166.702206] Workqueue: events_freezable_power_
>  thermal_zone_device_check
>  [  166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS
>  BTYPE=--)
>  [  166.702242] pc : regmap_mmio_read32le+0x10/0x28
>  [  166.702261] lr : regmap_mmio_read+0x44/0x70
>  ...
>  [  166.702606]  bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal]
> 
>  I wondered if that reg read was stalled due to a clock being stopped.
> 
>  Lo and behold, disabling runtime pm and keeping the vec clock running
>  all the time fixed it[1].
> 
>  I don't know what the problem is, but at least I can now test this
>  patchset.
> 
>  [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065
> 
> >>> It turns out I didn't have to disable runtime pm:
> >>> https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2
> >> If the bcm2711_thermal IP needs that clock to be enabled, it should grab
> >> a reference itself, but it looks like even the device tree binding
> >> doesn't ask for one.
> > The missing clock in the device tree binding is expected, because
> > despite of the code there is not much information about the BCM2711
> > clock tree. But i'm skeptical that the AVS IP actually needs the VEC
> > clock, i think it's more likely that the VEC clock parent is changed and
> > that cause this issue. I could take care of the bcm2711 binding & driver
> > if i know which clock is really necessary.
> 
> Seems you're right, keeping the parent always enabled is enough:
> 
>   clk_prepare_enable(clk_get_parent(vec->clock)); // pllc_per
> 
> I tried enabling just the grandparent clock as well, but that didn't help.

Yeah, adding tracing to the clock framework shows that it indeed
disables PLLC_PER. So there's probably some other device that depends on
it but doesn't take a reference to it.

I had a look, but it's not really obvious what that might be.

This patch makes sure that the PLL*_PER are never disabled, could you
test it? It seems to work for me.


diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 48a1eb9f2d55..3839261ee419 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLA_LOADPER,
.hold_mask = CM_PLLA_HOLDPER,
.fixed_divider = 1,
-   .flags = CLK_SET_RATE_PARENT),
+   .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
[BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV(
SOC_ALL,
.name = "plla_dsi0",
@@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLC_LOADPER,
.hold_mask = CM_PLLC_HOLDPER,
.fixed_divider = 1,
-   .flags = CLK_SET_RATE_PARENT),
+   .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),

/*
 * PLLD is the display PLL, used to drive DSI display panels.
@@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLH_LOADAUX,
.hold_mask = 0,
.fixed_divider = 1,
-   .flags = CLK_SET_RATE_PARENT),
+   .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
[BCM2835_PLLH_PIX]  = REGISTER_PLL_DIV(
SOC_BCM2835,
.name = "pllh_pix",


Maxime


signature.asc
Description: PGP signature

[Intel-gfx] [PATCH] drm/i915/gt: Restrict forced preemption to the active context

[Andrzej Hajda]

From: Chris Wilson 

When we submit a new pair of contexts to ELSP for execution, we start a
timer by which point we expect the HW to have switched execution to the
pending contexts. If the promotion to the new pair of contexts has not
occurred, we declare the executing context to have hung and force the
preemption to take place by resetting the engine and resubmitting the
new contexts.

This can lead to an unfair situation where almost all of the preemption
timeout is consumed by the first context which just switches into the
second context immediately prior to the timer firing and triggering the
preemption reset (assuming that the timer interrupts before we process
the CS events for the context switch). The second context hasn't yet had
a chance to yield to the incoming ELSP (and send the ACk for the
promotion) and so ends up being blamed for the reset.

If we see that a context switch has occurred since setting the
preemption timeout, but have not yet received the ACK for the ELSP
promotion, rearm the preemption timer and check again. This is
especially significant if the first context was not schedulable and so
we used the shortest timer possible, greatly increasing the chance of
accidentally blaming the second innocent context.

Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on 
schedule-out")
Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Andi Shyti 
Reviewed-by: Andrzej Hajda 
Tested-by: Andrzej Hajda 
Cc:  # v5.5+
---
Hi,

This patch is upstreamed from internal branch. So I have removed
R-B by Andi. Andi let me know if your R-B still apply.

Regards
Andrzej
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  | 15 +
 .../drm/i915/gt/intel_execlists_submission.c  | 21 ++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 633a7e5dba3b4b..6b5d4ea22b673b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -165,6 +165,21 @@ struct intel_engine_execlists {
 */
struct timer_list preempt;
 
+   /**
+* @preempt_target: active request at the time of the preemption request
+*
+* We force a preemption to occur if the pending contexts have not
+* been promoted to active upon receipt of the CS ack event within
+* the timeout. This timeout maybe chosen based on the target,
+* using a very short timeout if the context is no longer schedulable.
+* That short timeout may not be applicable to other contexts, so
+* if a context switch should happen within before the preemption
+* timeout, we may shoot early at an innocent context. To prevent this,
+* we record which context was active at the time of the preemption
+* request and only reset that context upon the timeout.
+*/
+   const struct i915_request *preempt_target;
+
/**
 * @ccid: identifier for contexts submitted to this engine
 */
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4b909cb88cdfb7..c718e6dc40b515 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1241,6 +1241,9 @@ static unsigned long active_preempt_timeout(struct 
intel_engine_cs *engine,
if (!rq)
return 0;
 
+   /* Only allow ourselves to force reset the currently active context */
+   engine->execlists.preempt_target = rq;
+
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return INTEL_CONTEXT_BANNED_PREEMPT_TIMEOUT_MS;
@@ -2427,8 +2430,24 @@ static void execlists_submission_tasklet(struct 
tasklet_struct *t)
GEM_BUG_ON(inactive - post > ARRAY_SIZE(post));
 
if (unlikely(preempt_timeout(engine))) {
+   const struct i915_request *rq = *engine->execlists.active;
+
+   /*
+* If after the preempt-timeout expired, we are still on the
+* same active request/context as before we initiated the
+* preemption, reset the engine.
+*
+* However, if we have processed a CS event to switch contexts,
+* but not yet processed the CS event for the pending
+* preemption, reset the timer allowing the new context to
+* gracefully exit.
+*/
cancel_timer(>execlists.preempt);
-   engine->execlists.error_interrupt |= ERROR_PREEMPT;
+   if (rq == engine->execlists.preempt_target)
+   engine->execlists.error_interrupt |= 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix PSR_IMR/IIR field handling

[Souza, Jose]

On Wed, 2022-09-21 at 09:24 +0300, Jouni Högander wrote:
> Current PSR code is assuming TRANSCODER_EDP == 0. This is not the case
> and all fields in PSR_IMR and PSR_IIR are shifted incorrectly if
> DISPLAY_VER >= 12.

There is no EDP transcoder in display 12 and newer.

> 
> Fix this by using TRANSCODER_EDP definition instead of 0.
> 
> 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 {
>   trans_shift = intel_dp->psr.transcoder;
> @@ -195,7 +195,7 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, u32 
> psr_iir)
>   i915_reg_t imr_reg;
>  
>   if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + trans_shift = TRANSCODER_EDP;
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
>   } else {
>   trans_shift = intel_dp->psr.transcoder;
> @@ -1197,7 +1197,7 @@ static bool psr_interrupt_error_check(struct intel_dp 
> *intel_dp)
>   if (DISPLAY_VER(dev_priv) >= 12) {
>   val = intel_de_read(dev_priv,
>   TRANS_PSR_IIR(intel_dp->psr.transcoder));
> - val &= EDP_PSR_ERROR(0);
> + val &= EDP_PSR_ERROR(TRANSCODER_EDP);
>   } else {
>   val = intel_de_read(dev_priv, EDP_PSR_IIR);
>   val &= EDP_PSR_ERROR(intel_dp->psr.transcoder);

[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable YCbCr420 for VDSC

[Patchwork]

== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/108824/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12164_full -> Patchwork_108824v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_108824v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108824v1_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_108824v1_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html

  
Known issues


  Here are the changes found in Patchwork_108824v1_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([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], [FAIL][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26]) ([i915#4392]) -> ([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], [PASS][51])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk1/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk2/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk2/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk2/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk3/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk3/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/shard-glk3/boot.html
   [36]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Start cleaning up the DPLL ID mess

[Patchwork]

== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess
URL   : https://patchwork.freedesktop.org/series/108827/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108827v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/index.html

Participating hosts (34 -> 41)
--

  Additional (8): fi-rkl-11600 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adln-1 bat-jsl-3 bat-rpls-1 
  Missing(1): fi-bdw-samus 

Known issues


  Here are the changes found in Patchwork_108827v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][5] ([i915#5982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([fdo#111827]) +7 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4103])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([fdo#109285] / [i915#4098])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#1072]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3555] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-guc: [FAIL][13] ([i915#6219] / [i915#6884]) -> [FAIL][14] 
([i915#6641] / [i915#6884])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-kbl-guc/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-8809g:   [FAIL][15] ([i915#6219] / [i915#6884]) -> [FAIL][16] 
([i915#6641] / [i915#6884])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-kbl-8809g/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-kbl-8809g/igt@run...@aborted.html
- fi-apl-guc: [FAIL][17] ([i915#6884]) -> [FAIL][18] ([i915#6641] / 
[i915#6884])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-apl-guc/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-apl-guc/igt@run...@aborted.html
- fi-skl-guc: [FAIL][19] ([i915#6884]) -> [FAIL][20] ([i915#6641] / 
[i915#6884])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-skl-guc/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v1/fi-skl-guc/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][21] ([i915#6219] / [i915#6884]) -> [FAIL][22] 
([i915#6641] / [i915#6884] 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Start cleaning up the DPLL ID mess

[Patchwork]

== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess
URL   : https://patchwork.freedesktop.org/series/108827/
State : warning

== Summary ==

Error: dim checkpatch failed
e566d547b93b drm/i915: Always initialize dpll.lock
081d1cb10d41 drm/i915: Nuke intel_get_shared_dpll_id()
5a44789e2cb2 drm/i915: Stop requiring PLL index == PLL ID
-:156: CHECK:SPACING: No space is necessary after a cast
#156: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:542:
+   id = (enum intel_dpll_id) crtc->pipe;

total: 0 errors, 0 warnings, 1 checks, 160 lines checked
da8ead688b1b drm/i915: Decouple I915_NUM_PLLS from PLL IDs

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

[Andi Shyti]

Hi Badal,

> +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,
> +};

what's the point for splitting so much? Can't you just send the
hwmon driver all at once? With this patch you are not actually
doing anything useful. In my opinion this should be squashed with
the next ones.

> +static void
> +hwm_get_preregistration_info(struct drm_i915_private *i915)
> +{
> +}
> +
> +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.

Andi

> + i915->hwmon = NULL;
> + kfree(hwmon);
> + return;
> + }
> +
> + ddat->hwmon_dev = hwmon_dev;
> +}
> +
> +void i915_hwmon_unregister(struct drm_i915_private *i915)
> +{
> + struct i915_hwmon *hwmon;
> + struct hwm_drvdata *ddat;
> +
> + hwmon = fetch_and_zero(>hwmon);
> + if (!hwmon)
> + return;
> +
> + ddat = >ddat;
> + if (ddat->hwmon_dev)
> + hwmon_device_unregister(ddat->hwmon_dev);
> +
> + mutex_destroy(>hwmon_lock);
> + kfree(hwmon);
> +}
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.h 
> b/drivers/gpu/drm/i915/i915_hwmon.h
> new file mode 100644
> index ..7ca9cf2c34c9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_hwmon.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_HWMON_H__
> +#define __I915_HWMON_H__
> +
> +struct drm_i915_private;
> +
> +#if IS_REACHABLE(CONFIG_HWMON)
> +void i915_hwmon_register(struct drm_i915_private *i915);
> +void i915_hwmon_unregister(struct drm_i915_private *i915);
> +#else
> +static inline void i915_hwmon_register(struct drm_i915_private *i915) { };
> +static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
> +#endif
> +
> +#endif /* __I915_HWMON_H__ */
> -- 
> 2.25.1

[Intel-gfx] [PATCH 4/4] drm/i915: Decouple I915_NUM_PLLS from PLL IDs

[Ville Syrjala]

From: Ville Syrjälä 

Stop assuming the size of PLL ID based bitmask is restricted
to I915_NUM_PLLS bits. This is the last thing coupling the
two things together and thus artificially limiting PLL IDs.

We could just pass any arbitrary (large enough) size to
for_each_set_bit() and be done with it, but the WARN
requiring the caller to not pass in a bogus bitmask seems
potentially useful to keep around. So let's just calculate
the full bitmask on the spot.

And while at it let's assert that the PLL IDs will fit
into the bitmask we use for them.

TODO: could also get rid of I915_NUM_PLLS entirely and just
dynamically allocate i915->shared_dplls[] and state->shared_dpll[].
But that would involve error handling in the modeset init path. Uff.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 24 +--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index fb09029cc4aa..ee04b63d2696 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -315,6 +315,21 @@ void intel_disable_shared_dpll(const struct 
intel_crtc_state *crtc_state)
mutex_unlock(_priv->display.dpll.lock);
 }
 
+static unsigned long
+intel_dpll_mask_all(struct drm_i915_private *i915)
+{
+   unsigned long dpll_mask = 0;
+   int i;
+
+   for (i = 0; i < i915->display.dpll.num_shared_dpll; i++) {
+   struct intel_shared_dpll *pll = 
>display.dpll.shared_dplls[i];
+
+   dpll_mask |= BIT(pll->info->id);
+   }
+
+   return dpll_mask;
+}
+
 static struct intel_shared_dpll *
 intel_find_shared_dpll(struct intel_atomic_state *state,
   const struct intel_crtc *crtc,
@@ -322,15 +337,16 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
   unsigned long dpll_mask)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   unsigned long dpll_mask_all = intel_dpll_mask_all(dev_priv);
struct intel_shared_dpll_state *shared_dpll;
struct intel_shared_dpll *unused_pll = NULL;
enum intel_dpll_id id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
 
-   drm_WARN_ON(_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
+   drm_WARN_ON(_priv->drm, dpll_mask & ~dpll_mask_all);
 
-   for_each_set_bit(id, _mask, I915_NUM_PLLS) {
+   for_each_set_bit(id, _mask, fls(dpll_mask_all)) {
struct intel_shared_dpll *pll;
int i;
 
@@ -4234,6 +4250,10 @@ void intel_shared_dpll_init(struct drm_i915_private 
*dev_priv)
i >= 
ARRAY_SIZE(dev_priv->display.dpll.shared_dplls)))
break;
 
+   /* must fit into unsigned long bitmask on 32bit */
+   if (drm_WARN_ON(_priv->drm, dpll_info[i].id >= 32))
+   break;
+
dev_priv->display.dpll.shared_dplls[i].info = _info[i];
}
 
-- 
2.35.1

[Intel-gfx] [PATCH 3/4] drm/i915: Stop requiring PLL index == PLL ID

[Ville Syrjala]

From: Ville Syrjälä 

There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.

Both i915->shared_dplls[] and state->shared_dpll[] are indexed
by the same thing now, which is just the index we get at
initialization from dpll_mgr->dpll_info[]. The rest is all about
PLL IDs now.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 64 +--
 .../gpu/drm/i915/display/intel_pch_refclk.c   |  5 +-
 2 files changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index f900c4c73cc6..fb09029cc4aa 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -110,7 +110,7 @@ static void
 intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
  struct intel_shared_dpll_state *shared_dpll)
 {
-   enum intel_dpll_id i;
+   int i;
 
/* Copy shared dpll state */
for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
@@ -137,6 +137,13 @@ intel_atomic_get_shared_dpll_state(struct drm_atomic_state 
*s)
return state->shared_dpll;
 }
 
+static int
+intel_shared_dpll_idx(struct drm_i915_private *i915,
+ const struct intel_shared_dpll *pll)
+{
+   return pll - >display.dpll.shared_dplls[0];
+}
+
 /**
  * intel_get_shared_dpll_by_id - get a DPLL given its id
  * @dev_priv: i915 device instance
@@ -149,7 +156,17 @@ struct intel_shared_dpll *
 intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
enum intel_dpll_id id)
 {
-   return _priv->display.dpll.shared_dplls[id];
+   int i;
+
+   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
+   struct intel_shared_dpll *pll = 
_priv->display.dpll.shared_dplls[i];
+
+   if (pll->info->id == id)
+   return pll;
+   }
+
+   MISSING_CASE(id);
+   return NULL;
 }
 
 /* For ILK+ */
@@ -305,16 +322,23 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
   unsigned long dpll_mask)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_shared_dpll *pll, *unused_pll = NULL;
struct intel_shared_dpll_state *shared_dpll;
-   enum intel_dpll_id i;
+   struct intel_shared_dpll *unused_pll = NULL;
+   enum intel_dpll_id id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
 
drm_WARN_ON(_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
 
-   for_each_set_bit(i, _mask, I915_NUM_PLLS) {
-   pll = _priv->display.dpll.shared_dplls[i];
+   for_each_set_bit(id, _mask, I915_NUM_PLLS) {
+   struct intel_shared_dpll *pll;
+   int i;
+
+   pll = intel_get_shared_dpll_by_id(dev_priv, id);
+   if (!pll)
+   continue;
+
+   i = intel_shared_dpll_idx(dev_priv, pll);
 
/* Only want to check enabled timings first */
if (shared_dpll[i].pipe_mask == 0) {
@@ -355,27 +379,29 @@ intel_reference_shared_dpll(struct intel_atomic_state 
*state,
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
-   const enum intel_dpll_id id = pll->info->id;
+   int i = intel_shared_dpll_idx(i915, pll);
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
 
-   if (shared_dpll[id].pipe_mask == 0)
-   shared_dpll[id].hw_state = *pll_state;
+   if (shared_dpll[i].pipe_mask == 0)
+   shared_dpll[i].hw_state = *pll_state;
 
drm_dbg(>drm, "using %s for pipe %c\n", pll->info->name,
pipe_name(crtc->pipe));
 
-   shared_dpll[id].pipe_mask |= BIT(crtc->pipe);
+   shared_dpll[i].pipe_mask |= BIT(crtc->pipe);
 }
 
 static void intel_unreference_shared_dpll(struct intel_atomic_state *state,
  const struct intel_crtc *crtc,
  const struct intel_shared_dpll *pll)
 {
+   struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
+   int i = intel_shared_dpll_idx(i915, pll);
 
shared_dpll = intel_atomic_get_shared_dpll_state(>base);
-   shared_dpll[pll->info->id].pipe_mask &= ~BIT(crtc->pipe);
+   shared_dpll[i].pipe_mask &= ~BIT(crtc->pipe);
 }
 
 static void intel_put_dpll(struct intel_atomic_state *state,
@@ -409,14 +435,13 @@ void intel_shared_dpll_swap_state(struct 
intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll = state->shared_dpll;
-   enum intel_dpll_id i;
+   int i;
 
if (!state->dpll_set)
return;
 
for (i = 0; i < 

[Intel-gfx] [PATCH 2/4] drm/i915: Nuke intel_get_shared_dpll_id()

[Ville Syrjala]

From: Ville Syrjälä 

Each PLL knows its own ID so intel_get_shared_dpll_id() is
pointless. Get rid of it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  4 ++--
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 22 ---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  3 ---
 3 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 643832d55c28..5057ee3c93fc 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3536,7 +3536,7 @@ static void icl_ddi_tc_get_clock(struct intel_encoder 
*encoder,
if (drm_WARN_ON(>drm, !pll))
return;
 
-   if (intel_get_shared_dpll_id(i915, pll) == DPLL_ID_ICL_TBTPLL)
+   if (pll->info->id == DPLL_ID_ICL_TBTPLL)
port_dpll_id = ICL_PORT_DPLL_DEFAULT;
else
port_dpll_id = ICL_PORT_DPLL_MG_PHY;
@@ -3549,7 +3549,7 @@ static void icl_ddi_tc_get_clock(struct intel_encoder 
*encoder,
 
icl_set_active_port_dpll(crtc_state, port_dpll_id);
 
-   if (intel_get_shared_dpll_id(i915, crtc_state->shared_dpll) == 
DPLL_ID_ICL_TBTPLL)
+   if (crtc_state->shared_dpll->info->id == DPLL_ID_ICL_TBTPLL)
crtc_state->port_clock = icl_calc_tbt_pll_link(i915, 
encoder->port);
else
crtc_state->port_clock = intel_dpll_get_freq(i915, 
crtc_state->shared_dpll,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 9c60cf69cde1..f900c4c73cc6 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -152,28 +152,6 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
*dev_priv,
return _priv->display.dpll.shared_dplls[id];
 }
 
-/**
- * intel_get_shared_dpll_id - get the id of a DPLL
- * @dev_priv: i915 device instance
- * @pll: the DPLL
- *
- * Returns:
- * The id of @pll
- */
-enum intel_dpll_id
-intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
-struct intel_shared_dpll *pll)
-{
-   long pll_idx = pll - dev_priv->display.dpll.shared_dplls;
-
-   if (drm_WARN_ON(_priv->drm,
-   pll_idx < 0 ||
-   pll_idx >= dev_priv->display.dpll.num_shared_dpll))
-   return -1;
-
-   return pll_idx;
-}
-
 /* For ILK+ */
 void assert_shared_dpll(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 3247dc300ae4..3854f1b4299a 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -328,9 +328,6 @@ struct intel_shared_dpll {
 struct intel_shared_dpll *
 intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
enum intel_dpll_id id);
-enum intel_dpll_id
-intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
-struct intel_shared_dpll *pll);
 void assert_shared_dpll(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
bool state);
-- 
2.35.1

[Intel-gfx] [PATCH 1/4] drm/i915: Always initialize dpll.lock

[Ville Syrjala]

From: Ville Syrjälä 

Initialize the dll.lock mutex whether or not we manage to
initialize the rest of the dpll mgr.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e5fb66a5dd02..9c60cf69cde1 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -4193,6 +4193,8 @@ void intel_shared_dpll_init(struct drm_i915_private 
*dev_priv)
const struct dpll_info *dpll_info;
int i;
 
+   mutex_init(_priv->display.dpll.lock);
+
if (IS_DG2(dev_priv))
/* No shared DPLLs on DG2; port PLLs are part of the PHY */
dpll_mgr = NULL;
@@ -4237,7 +4239,6 @@ void intel_shared_dpll_init(struct drm_i915_private 
*dev_priv)
 
dev_priv->display.dpll.mgr = dpll_mgr;
dev_priv->display.dpll.num_shared_dpll = i;
-   mutex_init(_priv->display.dpll.lock);
 }
 
 /**
-- 
2.35.1

[Intel-gfx] [PATCH 0/4] drm/i915: Start cleaning up the DPLL ID mess

[Ville Syrjala]

From: Ville Syrjälä 

Start to clean up the mess around DPLL IDs a bit by removing
the nasty assumption that the index of the DPLL in the
arrays matches its ID. Fortunately we did have a WARN
i nthere to cathc mistakes, but better to not has such
silly assumptions i nthe first place.

There's still a lot of mess left since the DPLL IDs in
the hardware are a mess as well. Eg. the index of the
register instance often differs from the index used
to select the DPLL in clock routing thing. So we could
probably clean up more of that, perhaps by declaring
separate IDs for each PLL for each use case...

Ville Syrjälä (4):
  drm/i915: Always initialize dpll.lock
  drm/i915: Nuke intel_get_shared_dpll_id()
  drm/i915: Stop requiring PLL index == PLL ID
  drm/i915: Decouple I915_NUM_PLLS from PLL IDs

 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 105 +++---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |   3 -
 .../gpu/drm/i915/display/intel_pch_refclk.c   |   5 +-
 4 files changed, 69 insertions(+), 48 deletions(-)

-- 
2.35.1

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC

[Patchwork]

== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/108824/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12164 -> Patchwork_108824v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/index.html

Participating hosts (34 -> 34)
--

  Additional (2): fi-rkl-11600 fi-icl-u2 
  Missing(2): fi-bdw-samus fi-tgl-mst 

Known issues


  Here are the changes found in Patchwork_108824v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12164/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][9] ([i915#5982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-icl-u2:  NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4103])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
- fi-icl-u2:  NOTRUN -> [SKIP][13] ([i915#4103])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/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][14] ([i915#6008])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109285] / [i915#4098])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
- fi-icl-u2:  NOTRUN -> [SKIP][19] ([i915#3555])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108824v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][20] ([fdo#109295] / [i915#3291] / 

Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper

[Gustavo Sousa]

On Wed, Sep 21, 2022 at 11:21:00AM +0300, Jani Nikula wrote:
> On Tue, 20 Sep 2022, Gustavo Sousa  wrote:
> > Hi, Jani.
> >
> > On Tue, Sep 20, 2022 at 10:19:53AM +0300, Jani Nikula wrote:
> >> On Mon, 19 Sep 2022, Gustavo Sousa  wrote:
> >> > Make the code more readable, which will be more apparent as new
> >> > platforms with different hotplug inversion needs are added.
> >> >
> >> > Signed-off-by: Gustavo Sousa 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_irq.c | 25 -
> >> >  1 file changed, 16 insertions(+), 9 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> > b/drivers/gpu/drm/i915/i915_irq.c
> >> > index de06f293e173..c53d21ae197f 100644
> >> > --- a/drivers/gpu/drm/i915/i915_irq.c
> >> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct 
> >> > drm_i915_private *dev_priv)
> >> >  spin_unlock_irq(_priv->irq_lock);
> >> >  }
> >> >  
> >> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
> >> > +{
> >> > +u32 invert_bits;
> >> > +
> >> > +if (HAS_PCH_DG1(dev_priv))
> >> > +invert_bits = INVERT_DDIA_HPD |
> >> > +  INVERT_DDIB_HPD |
> >> > +  INVERT_DDIC_HPD |
> >> > +  INVERT_DDID_HPD;
> >> 
> >> Nitpick, the indentation will be off compared to automated indentation.
> >
> > What do you mean by automated indentation?
> 
> For example, hit TAB on the lines using a smart enough editor, which has
> been configured to follow kernel coding style. ;)
> 

I'm not sure I completely understand the issue. Could you provide an example of
such a configuration?

Is the problem here the spaces after the tabs to align each INVERT_DDI*? Would
you suggest I just use tabs and do not align them to the first one?

E.g.:

invert_bits = INVERT_DDIA_HPD |
INVERT_DDIB_HPD |
INVERT_DDIC_HPD |
INVERT_DDID_HPD;

Another one:

invert_bits = INVERT_DDIA_HPD |
INVERT_DDIB_HPD |
INVERT_DDIC_HPD |
INVERT_DDID_HPD;


Note: I'm using 8 spaces for instead tabs in the above examples for proper
visual, but they would be tab characters in the source.

--
Gustavo Sousa

Re: [Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage

[Gupta, Anshuman]

On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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)
   - Updated date, kernel version in documentation

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 |   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 bc061238e35c..94101f818a70 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:  September 2022
+KernelVersion: 6
+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 5183cf51a49b..a42cfad78bef 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_VOLTAGE1000
  #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 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable YCbCr420 for VDSC

[Patchwork]

== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/108824/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:58:9: warning: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable YCbCr420 for VDSC

[Patchwork]

== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/108824/
State : warning

== Summary ==

Error: dim checkpatch failed
3f358f4298a9 drm/i915/dp: Check if DSC supports the given output_format
40dde02e9f75 drm/i915/vdsc: Enable YCbCr420 for VDSC
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_row' - possible 
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420)  do { \
+   if (bpc == (_bpc)) {\
+   if (_is_420)\
+   return 
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+   else\
+   return 
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+   }   \
 } while (0)

-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_col' - possible 
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420)  do { \
+   if (bpc == (_bpc)) {\
+   if (_is_420)\
+   return 
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+   else\
+   return 
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+   }   \
 } while (0)

total: 0 errors, 0 warnings, 2 checks, 228 lines checked
e48d0e6f0585 drm/i915/display: Fill in native_420 field

Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting

[Gupta, Anshuman]

On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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)
   - Update date, kernel version in documentation

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 
---
  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 +++
  drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
  drivers/gpu/drm/i915/i915_reg.h   |   5 +
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |   6 +
  4 files changed, 187 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 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:  September 2022
+KernelVersion: 6
+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:  September 2022
+KernelVersion: 6
+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 45745afa5c5b..5183cf51a49b 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_VOLTAGE1000
+#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;
+   bits_to_set = 

Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting

[Tvrtko Ursulin]

On 21/09/2022 01:02, Dixit, Ashutosh wrote:

On Fri, 16 Sep 2022 08:00:50 -0700, Badal Nilawar wrote:


diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 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:  September 2022
+KernelVersion: 6


Maybe we should ask someone but even if we merge this today to drm-tip this
will appear in kernel.org Linus' version only in 6.2. So I think we should
set this as 6.2 on all patches.


Correct, if merged today it will appear in 6.2 so please change to that 
before merging.


As for the date that's harder to predict and I am not really sure how 
best to handle it. Crystal ball predicts February 2023 fwiw so maybe go 
with that for now. Seems less important than the release for me anyway.


Regards,

Tvrtko


Except for this, thanks for making the changes, this is:

Reviewed-by: Ashutosh Dixit 

Re: [Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support

[Gupta, Anshuman]

On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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)
   - Updated date, kernel version in documentation

Cc: Guenter Roeck 
Cc: Anshuman Gupta 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 

Looks good to me.
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 ..e2974f928e58
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What:  /sys/devices/.../hwmon/hwmon/in0_input
+Date:  September 2022
+KernelVersion: 6
+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 2275ee47da95..65336514554d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1510,6 +1510,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 103dd543a214..45745afa5c5b 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 = 

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

[Gupta, Anshuman]

On 9/16/2022 8:30 PM, Badal Nilawar wrote:

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)

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  | 136 +
  drivers/gpu/drm/i915/i915_hwmon.h  |  20 +
  5 files changed, 166 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 c459eb362c47..75655adb7bd3 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 9f9372931fd2..01a2caf42635 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -353,6 +353,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 ..103dd543a214
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,136 @@
+// 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 

[Intel-gfx] [PATCH 3/3] drm/i915/display: Fill in native_420 field

[Kandpal, Suraj]

From: Suraj Kandpal 

Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 --
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 ---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 16 +++-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ed4d93942dbd..9d2710edd27e 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1625,8 +1625,6 @@ static int gen11_dsi_dsc_compute_config(struct 
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
 
-   vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f2f77856df83..50f8e121 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1440,9 +1440,6 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
 
-   vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP 
- DP_DSC_SUPPORT] &
-   DP_DSC_RGB;
-
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
drm_dbg_kms(>drm,
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index a642975a1b61..1ab2a2286c74 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -462,14 +462,28 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
 pipe_config->dsc.slice_count);
+   /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb 
is 0
+* else 1
+*/
+   vdsc_cfg->convert_rgb = !(pipe_config->output_format == 
INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ pipe_config->output_format == 
INTEL_OUTPUT_FORMAT_YCBCR444);
 
-   /* Gen 11 does not support YCbCr */
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   vdsc_cfg->native_420 = true;
+   /* Gen 11 does not support YCbCr422 */
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
 
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+   /*
+* According to DSC 1.2 specs if native_420 is set we need to double 
the current bpp
+*/
+   if (vdsc_cfg->native_420)
+   vdsc_cfg->bits_per_pixel <<= 1;
+
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
 
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
-- 
2.25.1

[Intel-gfx] [PATCH 2/3] drm/i915/vdsc: Enable YCbCr420 for VDSC

[Kandpal, Suraj]

From: Suraj Kandpal 

Implementation of VDSC for YCbCr420.

Signed-off-by: Suraj Kandpal 
---
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |   4 +-
 3 files changed, 180 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c 
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..6e86c0971d24 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -17,6 +17,15 @@
 /* from BPP 6 to 36 in steps of 0.5 */
 #define RC_RANGE_QP444_12BPC_MAX_NUM_BPP   61
 
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP17
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP   23
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP   29
+
 /*
  * These qp tables are as per the C model
  * and it has the rows pointing to bpps which increment
@@ -283,26 +292,182 @@ static const u8 
rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
  11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5, 
5, 4 }
 };
 
-#define PARAM_TABLE(_minmax, _bpc, _row, _col)  do { \
-   if (bpc == (_bpc)) \
-   return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+static const u8 
rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
+   { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 }
+};
+
+static const u8 
rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
+   { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
+   { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+   { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
+   { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
+   { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
+   { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
+   { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 }
+};
+
+static const u8 
rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_MAX_NUM_BPP] = 
{
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
+   { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 5, 4, 4, 4, 3, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1, 1 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1 },
+   { 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+   { 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 7, 6, 6, 5, 4, 4, 3, 3, 2, 1 },
+   { 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 7, 7, 6, 5, 4, 4, 3, 3, 2, 1 },
+   { 13, 12, 12, 11, 11, 11, 11, 11, 11, 10, 9, 9, 8, 7, 7, 6, 5, 5, 4, 3, 
3,
+ 2, 2 },
+   { 17, 16, 16, 15, 14, 14, 13, 12, 12, 11, 10, 10, 10, 9, 8, 8, 7, 6, 6, 
5,
+ 5, 4, 4 }
+};
+
+static const u8 

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Check if DSC supports the given output_format

[Kandpal, Suraj]

From: Ankit Nautiyal 

Go with DSC only if the given output_format is supported.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c9be61d2348e..f2f77856df83 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1464,6 +1464,32 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
 }
 
+static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
+enum intel_output_format output_format)
+{
+   u8 sink_dsc_format;
+
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   sink_dsc_format = DP_DSC_RGB;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   sink_dsc_format = DP_DSC_YCbCr444;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   if (min(intel_dp_source_dsc_version_minor(intel_dp),
+   intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
+   return false;
+   sink_dsc_format = DP_DSC_YCbCr420_Native;
+   break;
+   default:
+   return false;
+   }
+
+   return intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] 
&
+  sink_dsc_format;
+}
+
 static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
   struct intel_crtc_state *pipe_config,
   struct drm_connector_state *conn_state,
@@ -1482,6 +1508,9 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
+   if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
+   return -EINVAL;
+
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
 
if (intel_dp->force_dsc_bpc) {
-- 
2.25.1

[Intel-gfx] [PATCH 0/3] Enable YCbCr420 for VDSC

[Kandpal, Suraj]

This patch series aims to enable the YCbCr420 format
for DSC. Changes are mostly compute params related for
hdmi,dp and dsi along with the addition of new rc_tables
for native_420 and corresponding changes to macros used to
fetch them.

Ankit Nautiyal (1):
  drm/i915/dp: Check if DSC supports the given output_format

Suraj Kandpal (2):
  drm/i915/vdsc: Enable YCbCr420 for VDSC
  drm/i915/display: Fill in native_420 field

 drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  32 ++-
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |  20 +-
 5 files changed, 224 insertions(+), 21 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] [PATCH v5 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification

[Dmitry Osipenko]

On 9/20/22 17:13, Sumit Semwal wrote:
> Hi Dmitry,
> 
> Thanks very much for the series.
> 
> On Wed, 14 Sept 2022 at 00:59, Dmitry Osipenko
>  wrote:
>>
>> Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking
>> specification by asserting that the reservation lock is held.
> Thanks for the patch; just a minor nit - I think you mean dma_buf_vmap
> / vunmap() here, and not _unlocked?

Yes, the _unlocked should be dropped here. Thank you for the review!

-- 
Best regards,
Dmitry

Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper

[Jani Nikula]

On Tue, 20 Sep 2022, Lucas De Marchi  wrote:
> On Tue, Sep 20, 2022 at 02:04:33PM -0300, Gustavo Sousa wrote:
>>Hi, Jani.
>>
>>On Tue, Sep 20, 2022 at 10:19:53AM +0300, Jani Nikula wrote:
>>> On Mon, 19 Sep 2022, Gustavo Sousa  wrote:
>>> > Make the code more readable, which will be more apparent as new
>>> > platforms with different hotplug inversion needs are added.
>>> >
>>> > Signed-off-by: Gustavo Sousa 
>>> > ---
>>> >  drivers/gpu/drm/i915/i915_irq.c | 25 -
>>> >  1 file changed, 16 insertions(+), 9 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>>> > b/drivers/gpu/drm/i915/i915_irq.c
>>> > index de06f293e173..c53d21ae197f 100644
>>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct 
>>> > drm_i915_private *dev_priv)
>>> >   spin_unlock_irq(_priv->irq_lock);
>>> >  }
>>> >
>>> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
>>> > +{
>>> > + u32 invert_bits;
>>> > +
>>> > + if (HAS_PCH_DG1(dev_priv))
>>> > + invert_bits = INVERT_DDIA_HPD |
>>> > +   INVERT_DDIB_HPD |
>>> > +   INVERT_DDIC_HPD |
>>> > +   INVERT_DDID_HPD;
>>>
>>> Nitpick, the indentation will be off compared to automated indentation.
>>
>>What do you mean by automated indentation?
>>
>>>
>>> > + else
>>> > + return;
>>> > +
>>> > + intel_uncore_rmw(_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
>>> > +}
>>> > +
>>> >  static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
>>> >  enum hpd_pin pin)
>>> >  {
>>> > @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct 
>>> > drm_i915_private *i915,
>>> >
>>> >  static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
>>> >  {
>>> > - u32 val;
>>> > -
>>> > - val = intel_uncore_read(_priv->uncore, SOUTH_CHICKEN1);
>>> > - val |= (INVERT_DDIA_HPD |
>>> > - INVERT_DDIB_HPD |
>>> > - INVERT_DDIC_HPD |
>>> > - INVERT_DDID_HPD);
>>> > - intel_uncore_write(_priv->uncore, SOUTH_CHICKEN1, val);
>>> > -
>>> > + setup_hotplug_inversion(dev_priv);
>>>
>>> Since you're already in a platform specific function here, seems a bit
>>> odd to call a new generic function that needs to have another if ladder
>>> platform check. What are we gaining here? The end result is
>>> de-duplicating just one line of intel_uncore_rmw(). I'm not convinced.
>>
>>It is true that the proposed refactor repeats a platform check, but the 
>>proposed
>>refactor has its benefits. As more platforms with hotplug inversion needs are
>>added (e.g. MTL), we will have a common place for the logic of hotplug
>>inversion. That arguably makes the code more readable and makes future 
>>refactors
>>easier when we need split a function that has become too complex due to 
>>platform
>>checks.
>>
>>To make that last point clearer, I am quoting Lucas' (copied here as well)
>>comment (which was what convinced me) from a discussion regarding the 
>>advantage
>>of using such a helper:
>>
>>that is what helpers are for, so you don't have to open code it in every
>>platform-fork of the function that needs it. See how the various
>>"Sequences to initialize display" are done in the driver... When we are
>>extending it to a future platform, if the change is small enough we just
>>add e few if/else in the same function. But it doesn't take too long for
>>those functions to become unreadable if there are several branches the
>>code path may take.  So then we "fork" the function for a new platform,
>>but reuse the helpers doing the individual steps.
>
> the missing information here is that there are changes in the pipeline
> for platforms that have different bits to be inverted, or none at
> all, with a different register to program. Adding the if/else in this
> function seems unrelated churn.
>
> Another possibility would be to just let the caller handle the if/else
> decision, passing the bits (and possibly register) to invert. The noise
> in xxx_hpd_irq_setup() function may be avoid by
>
> #define INVERT_DII_HPD(INVERT_DDIA_HPD | INVERT_DDIB_HPD | 
> INVERT_DDIC_HPD | INVERT_DDID_HPD)
> #define XXX_INVERT_DII_HPD(...)
>
> Third possibility since the function is already very small is to just go
> ahead and use another _setup() for the next platforms.

IMO if you already have platform specific functions, it can get
confusing if you call generic helpers that again spread out to platform
specific functions, possibly with different conditions than the first
one. We've had a bunch of those where you eventually realize there's
conditions in the helper that never happen.

I'd probably just add small *platform specific* hpd invert
functions. dg1_hpd_invert() and mtl_hpd_invert() etc.

Compare with *_hpd_detection_setup(), and wonder what that would look
like if it were a generic helper. 

Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions

[Tvrtko Ursulin]

On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common functionalities into a separate file where possible.


Looks like a good start to me. A couple comments/questions below.


Signed-off-by: Niranjana Vishwanathapura 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 507 ++---
  .../drm/i915/gem/i915_gem_execbuffer_common.c | 530 ++
  .../drm/i915/gem/i915_gem_execbuffer_common.h |  47 ++
  4 files changed, 612 insertions(+), 473 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bf939ef18ea..bf952f478555 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+   gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 33d989a20227..363b2a788cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -9,8 +9,6 @@
  #include 
  #include 
  
-#include 

-
  #include "display/intel_frontbuffer.h"
  
  #include "gem/i915_gem_ioctls.h"

@@ -28,6 +26,7 @@
  #include "i915_file_private.h"
  #include "i915_gem_clflush.h"
  #include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
  #include "i915_gem_evict.h"
  #include "i915_gem_ioctls.h"
  #include "i915_trace.h"
@@ -235,13 +234,6 @@ enum {
   * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
   */
  
-struct eb_fence {

-   struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
-   struct dma_fence *dma_fence;
-   u64 value;
-   struct dma_fence_chain *chain_fence;
-};
-
  struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2446,164 +2438,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX]   = VECS0
  };
  
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel_context *ce)

-{
-   struct intel_ring *ring = ce->ring;
-   struct intel_timeline *tl = ce->timeline;
-   struct i915_request *rq;
-
-   /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
-   if (intel_ring_update_space(ring) >= PAGE_SIZE)
-   return NULL;
-
-   /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
-   list_for_each_entry(rq, >requests, link) {
-   if (rq->ring != ring)
-   continue;
-
-   if (__intel_ring_space(rq->postfix,
-  ring->emit, ring->size) > ring->size / 2)
-   break;
-   }
-   if (>link == >requests)
-   return NULL; /* weird, we will check again later for real */
-
-   return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context 
*ce,
-  bool throttle)
-{
-   struct intel_timeline *tl;
-   struct i915_request *rq = NULL;
-
-   /*
-* Take a local wakeref for preparing to dispatch the execbuf as
-* we expect to access the hardware fairly frequently in the
-* process, and require the engine to be kept awake between accesses.
-* Upon dispatch, we acquire another prolonged wakeref that we hold
-* until the timeline is idle, which in turn releases the wakeref
-* taken on the engine, and the parent device.
-*/
-   tl = intel_context_timeline_lock(ce);
-   if (IS_ERR(tl))
-   return PTR_ERR(tl);
-
-   intel_context_enter(ce);
-   if (throttle)
-   rq = eb_throttle(eb, ce);
-   intel_context_timeline_unlock(tl);
-
-   if (rq) {
-   bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
-   long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
-   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
-  

Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper

[Jani Nikula]

On Tue, 20 Sep 2022, Gustavo Sousa  wrote:
> On Tue, Sep 20, 2022 at 12:01:36AM -0700, Lucas De Marchi wrote:
>> On Mon, Sep 19, 2022 at 11:56:59AM -0300, Gustavo Sousa wrote:
>> > Make the code more readable, which will be more apparent as new
>> > platforms with different hotplug inversion needs are added.
>> > 
>> > Signed-off-by: Gustavo Sousa 
>> > ---
>> > drivers/gpu/drm/i915/i915_irq.c | 25 -
>> > 1 file changed, 16 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index de06f293e173..c53d21ae197f 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct 
>> > drm_i915_private *dev_priv)
>> >spin_unlock_irq(_priv->irq_lock);
>> > }
>> > 
>> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
>> 
>> new users of drm_i915_private should use "i915" as variable name rather
>> than dev_priv.
>
> Thanks. I will update this.
>
> Is there any documentation where we can find information like this?

WIP:

https://gitlab.freedesktop.org/jani/i915-check/-/blob/main/i915-style-guide.rst

BR,
Jani.

>
>> 
>> other than that,  Reviewed-by: Lucas De Marchi 
>> 
>> 
>> Lucas De Marchi
>> 
>> > +{
>> > +  u32 invert_bits;
>> > +
>> > +  if (HAS_PCH_DG1(dev_priv))
>> > +  invert_bits = INVERT_DDIA_HPD |
>> > +INVERT_DDIB_HPD |
>> > +INVERT_DDIC_HPD |
>> > +INVERT_DDID_HPD;
>> > +  else
>> > +  return;
>> > +
>> > +  intel_uncore_rmw(_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
>> > +}
>> > +
>> > static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
>> >   enum hpd_pin pin)
>> > {
>> > @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct 
>> > drm_i915_private *i915,
>> > 
>> > static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
>> > {
>> > -  u32 val;
>> > -
>> > -  val = intel_uncore_read(_priv->uncore, SOUTH_CHICKEN1);
>> > -  val |= (INVERT_DDIA_HPD |
>> > -  INVERT_DDIB_HPD |
>> > -  INVERT_DDIC_HPD |
>> > -  INVERT_DDID_HPD);
>> > -  intel_uncore_write(_priv->uncore, SOUTH_CHICKEN1, val);
>> > -
>> > +  setup_hotplug_inversion(dev_priv);
>> >icp_hpd_irq_setup(dev_priv);
>> > }
>> > 
>> > -- 
>> > 2.37.3
>> > 

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/guc: Define CTB based TLB invalidation routines

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/guc: Define CTB based TLB 
invalidation routines
URL   : https://patchwork.freedesktop.org/series/108818/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12163 -> Patchwork_108818v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_108818v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_108818v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/index.html

Participating hosts (42 -> 44)
--

  Additional (3): fi-icl-u2 fi-tgl-dsi fi-tgl-u2 
  Missing(1): fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_108818v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- bat-dg1-5:  [PASS][1] -> [DMESG-WARN][2] +6 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/bat-dg1-5/igt@i915_selftest@live@gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/bat-dg1-5/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@migrate:
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-rkl-guc/igt@i915_selftest@l...@migrate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-rkl-guc/igt@i915_selftest@l...@migrate.html

  
 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}:   NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html

  
Known issues


  Here are the changes found in Patchwork_108818v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-tgl-u2:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-tgl-u2:  NOTRUN -> [SKIP][9] ([fdo#109284] / [fdo#111827]) +7 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-u2/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-tgl-u2:  NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([i915#4103])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/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][13] ([i915#6008])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([i915#3555])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
- fi-tgl-u2:  NOTRUN -> [SKIP][17] ([i915#3555])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108818v1/fi-tgl-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dgfx: Release mmap on rpm suspend

[Matthew Auld]

On 21/09/2022 06:29, Gupta, Anshuman wrote:




-Original Message-
From: Matthew Auld 
Sent: Tuesday, September 20, 2022 7:30 PM
To: Gupta, Anshuman 
Cc: intel-gfx@lists.freedesktop.org; ch...@chris-wilson.co.uk; Auld, Matthew
; Vivi, Rodrigo 
Subject: Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dgfx: Release mmap on rpm
suspend

On Tue, 13 Sept 2022 at 16:27, Anshuman Gupta 
wrote:


Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access to
memory mappings will raise a userfault.

Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0 state if it was
in D3 in order to access the mmap memory mappings.

v2:
- Squashes the patches. [Matt Auld]
- Add adequate locking for lmem_userfault_list addition. [Matt Auld]
- Reused obj->userfault_count to avoid double addition. [Matt Auld]
- Added i915_gem_object_lock to check
   i915_gem_object_is_lmem. [Matt Auld]

v3:
- Use i915_ttm_cpu_maps_iomem. [Matt Auld]
- Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld]
- Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld]
- Delete the mmaped obj from lmem_userfault_list in obj
   destruction path. [Matt Auld]
- Get a wakeref for object destruction patch. [Matt Auld]
- Use intel_wakeref_auto to delay runtime PM. [Matt Auld]

v4:
- Avoid using mmo offset to get the vma_node. [Matt Auld]
- Added comment to use the lmem_userfault_lock. [Matt Auld]
- Get lmem_userfault_lock in i915_gem_object_release_mmap_offset.
   [Matt Auld]
- Fixed kernel test robot generated warning.

v5:
- Addressed the cosmetics comments. [Andi]
- Changed i915_gem_runtime_pm_object_release_mmap_offset() name to
   i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic.

PCIe Specs 5.3.1.4.1

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Cc: Matthew Auld 
Cc: Rodrigo Vivi 
Signed-off-by: Anshuman Gupta 
Reviewed-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 21 +++
  drivers/gpu/drm/i915/gem/i915_gem_mman.h  |  1 +
  drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  3 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 36 +--
  drivers/gpu/drm/i915/gt/intel_gt.c|  2 ++
  drivers/gpu/drm/i915/gt/intel_gt_types.h  | 14 
  drivers/gpu/drm/i915/i915_gem.c   |  4 +++
  8 files changed, 79 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b55befda3387..73d9eda1d6b7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -550,6 +550,20 @@ void i915_gem_object_release_mmap_gtt(struct

drm_i915_gem_object *obj)

 intel_runtime_pm_put(>runtime_pm, wakeref);  }

+void i915_gem_object_runtime_pm_release_mmap_offset(struct
+drm_i915_gem_object *obj) {
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   struct ttm_device *bdev = bo->bdev;
+
+   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;
+   }
+}
+
  void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object
*obj)  {
 struct i915_mmap_offset *mmo, *mn; @@ -573,6 +587,13 @@ 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;
+   }


Sorry for the late reply, I was out last week. This looks like it's missing 
holding
the runtime pm AFAICT. We are holding the runtime pm for object destruction,
but this is also called when a move is triggered (very common). If so, this can
race against the runtime pm also touching the list concurrently. We are chasing
some crazy looking NULL deref bugs, so wondering if this is somehow related...

Yes it is called from  i915_ttm_move_notify(),  I missed it thinking of 
__i915_gem_object_pages_fini
Would be sufficient to protect against runtime PM.
Having said that, it ok to remove the wakeref from i915_ttm_delete_mem_notify 
and having only
in one place in i915_gem_object_release_mmap_offset ?
If that is the case then is it safer to use the i915_gem_object_is_lmem() or we 
should use
i915_ttm_cpu_maps_iomem() here ?


Yeah, maybe we should just throw this into i915_ttm_unmap_virtual(). 
Something like:


 static void i915_ttm_unmap_virtual(struct drm_i915_gem_object *obj)
 {
+   struct ttm_buffer_object *bo = 

Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()

[Tvrtko Ursulin]

On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
  drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 ++
  2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
  #include "pxp/intel_pxp.h"
  
  #include "i915_drv.h"

+#include "i915_gem_context.h"


I can't spot that you are adding any code which would need this? 
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.



  #include "i915_gem_create.h"
  #include "i915_trace.h"
  #include "i915_user_extensions.h"
  
-static u32 object_max_page_size(struct intel_memory_region **placements,

-   unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements:  list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
  {
-   u32 max_page_size = 0;
+   u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
  
  	for (i = 0; i < n_placements; i++) {

@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct intel_memory_region 
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
  
-	GEM_BUG_ON(!max_page_size);

return max_page_size;
  }
  
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private *i915, u64 size,
  
  	i915_gem_flush_free_objects(i915);
  
-	size = round_up(size, object_max_page_size(placements, n_placements));

+   size = round_up(size, i915_gem_object_max_page_size(placements,
+   n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);


Because of the changes above this path is now unreachable. I suppose it 
was meant to tell the user "you have supplied no placements"? But then 
GEM_BUG_ON (which you remove) used to be wrong.


Regards,

Tvrtko

  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h

index 7317d4102955..8c97bddad921 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
  }
  
  void i915_gem_init__objects(struct drm_i915_private *i915);

+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
  
  void i915_objects_module_exit(void);

  int i915_objects_module_init(void);

Re: [Intel-gfx] [RFC v4 02/14] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()

[Tvrtko Ursulin]

On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.

Signed-off-by: Niranjana Vishwanathapura 
---
  drivers/gpu/drm/i915/i915_sw_fence.c | 25 ++---
  drivers/gpu/drm/i915/i915_sw_fence.h |  7 ++-
  2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..0ce8f4efc1ed 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -569,12 +569,11 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
return ret;
  }
  
-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)
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp)
  {
struct dma_resv_iter cursor;
struct dma_fence *f;
@@ -583,7 +582,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
  
-	dma_resv_iter_begin(, resv, dma_resv_usage_rw(write));

+   dma_resv_iter_begin(, resv, usage);
dma_resv_for_each_fence_unlocked(, f) {
pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
@@ -598,6 +597,18 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
return ret;
  }
  
+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)
+{
+   return __i915_sw_fence_await_reservation(fence, resv,
+dma_resv_usage_rw(write),
+timeout, gfp);
+}


Drive by observation - it looked dodgy that you create a wrapper here 
which ignores one function parameter.


On a more detailed look it seems no callers actually use exclude and 
it's even unused inside this function since 1b5bdf071e62 ("drm/i915: use 
the new iterator in i915_sw_fence_await_reservation v3").


So a cleanup patch before this one?

Regards,

Tvrtko



+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/lib_sw_fence.c"
  #include "selftests/i915_sw_fence.c"
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h 
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 619fc5a22f0c..3cf4b6e16f35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -10,13 +10,13 @@
  #define _I915_SW_FENCE_H_
  
  #include 

+#include 
  #include 
  #include 
  #include  /* for NOTIFY_DONE */
  #include 
  
  struct completion;

-struct dma_resv;
  struct i915_sw_fence;
  
  enum i915_sw_fence_notify {

@@ -89,6 +89,11 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
  unsigned long timeout,
  gfp_t gfp);
  
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,

+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp);
  int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
const struct dma_fence_ops *exclude,

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/guc: Define CTB based TLB invalidation routines

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/guc: Define CTB based TLB 
invalidation routines
URL   : https://patchwork.freedesktop.org/series/108818/
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 series starting with [1/4] drm/i915/guc: Define CTB based TLB invalidation routines

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/guc: Define CTB based TLB 
invalidation routines
URL   : https://patchwork.freedesktop.org/series/108818/
State : warning

== Summary ==

Error: dim checkpatch failed
16cae73d9bcf drm/i915/guc: Define CTB based TLB invalidation routines
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
v8: split from "drm/i915/xehpsdv: Define GuC Based TLB invalidation routines"

-:162: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#162: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc.c:929:
+   drm_err(_to_gt(guc)->i915->drm,
+"tlb invalidation response timed out for seqno %u\n", 
seqno);

-:326: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'guc' - possible 
side-effects?
#326: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:480:
+#define INTEL_GUC_SUPPORTS_TLB_INVALIDATION(guc) \
+   ((intel_guc_ct_enabled(&(guc)->ct)) && \
+(intel_guc_submission_is_used(guc)) && \
+(GRAPHICS_VER(guc_to_gt((guc))->i915) >= 12))

total: 0 errors, 1 warnings, 2 checks, 407 lines checked
c0c9221f611f drm/i915/xehpsdv: Define GuC Based full TLB invalidation routine
-:12: WARNING:BAD_SIGN_OFF: Non-standard signature: 'Singed-off-by:' - perhaps 
'Signed-off-by:'?
#12: 
Singed-off-by: Fei Yang 

total: 0 errors, 1 warnings, 0 checks, 41 lines checked
51b831d8101d drm/i915: Add support for GuC tlb invalidation
f984547c7ae1 drm/i915/guc: enable GuC GGTT invalidation from the start

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/vm_bind: Add VM_BIND functionality (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/vm_bind: Add VM_BIND functionality (rev3)
URL   : https://patchwork.freedesktop.org/series/105879/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12163 -> Patchwork_105879v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105879v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105879v3, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/index.html

Participating hosts (42 -> 40)
--

  Additional (1): fi-tgl-u2 
  Missing(3): fi-hsw-4770 fi-rkl-11600 fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_105879v3:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-ilk-650: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-ilk-650/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-ilk-650/igt@i915_module_l...@load.html
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-blb-e6850/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-blb-e6850/igt@i915_module_l...@load.html
- fi-pnv-d510:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-pnv-d510/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-pnv-d510/igt@i915_module_l...@load.html
- fi-snb-2520m:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-snb-2520m/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-snb-2520m/igt@i915_module_l...@load.html
- fi-hsw-g3258:   [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-hsw-g3258/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-hsw-g3258/igt@i915_module_l...@load.html
- fi-ivb-3770:[PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-ivb-3770/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-ivb-3770/igt@i915_module_l...@load.html
- fi-snb-2600:[PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-snb-2600/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-snb-2600/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@gem_migrate:
- bat-dg1-5:  [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/bat-dg1-5/igt@i915_selftest@live@gem_migrate.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/bat-dg1-5/igt@i915_selftest@live@gem_migrate.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@gem_migrate:
- {bat-dg2-8}:[PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/bat-dg2-8/igt@i915_selftest@live@gem_migrate.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/bat-dg2-8/igt@i915_selftest@live@gem_migrate.html
- {bat-dg2-9}:[PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/bat-dg2-9/igt@i915_selftest@live@gem_migrate.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/bat-dg2-9/igt@i915_selftest@live@gem_migrate.html

  
Known issues


  Here are the changes found in Patchwork_105879v3 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-skl-6700k2:  [PASS][21] -> [FAIL][22] ([i915#5032])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-skl-6700k2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-u2:  NOTRUN -> [SKIP][23] ([i915#2190])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v3/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@i915_module_load@load:
- fi-elk-e7500:   [PASS][24] -> [INCOMPLETE][25] ([i915#6836])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12163/fi-elk-e7500/igt@i915_module_l...@load.html
   

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/vm_bind: Add VM_BIND functionality (rev3)
URL   : https://patchwork.freedesktop.org/series/105879/
State : warning

== Summary ==

Error: dim checkpatch failed
1faa6bedf8da drm/i915/vm_bind: Expose vm lookup function
2474615410c3 drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
585b299126d4 drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
671058542882 drm/i915/vm_bind: Implement bind and unbind of object
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#45: 
new file mode 100644

-:565: WARNING:LONG_LINE: line length of 118 exceeds 100 columns
#565: FILE: include/uapi/drm/i915_drm.h:539:
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)

-:566: WARNING:LONG_LINE: line length of 122 exceeds 100 columns
#566: FILE: include/uapi/drm/i915_drm.h:540:
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_unbind)

total: 0 errors, 3 warnings, 0 checks, 665 lines checked
97e2068b921a drm/i915/vm_bind: Support for VM private BOs
b45f5fd59970 drm/i915/vm_bind: Handle persistent vmas
52581ec4212a drm/i915/vm_bind: Add out fence support
a9d8b10d97c9 drm/i915/vm_bind: Abstract out common execbuf functions
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:712: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#712: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 1247 lines checked
f2a78068e648 drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#32: 
new file mode 100644

-:653: WARNING:LONG_LINE: line length of 126 exceeds 100 columns
#653: FILE: include/uapi/drm/i915_drm.h:542:
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)

total: 0 errors, 2 warnings, 0 checks, 679 lines checked
f60faf478ccc drm/i915/vm_bind: Update i915_vma_verify_bind_complete()
5795b486d78c drm/i915/vm_bind: Handle persistent vmas in execbuf3
93f405eeeab3 drm/i915/vm_bind: userptr dma-resv changes
52ee0357651e drm/i915/vm_bind: Skip vma_lookup for persistent vmas
80e8d1ec7e16 drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode

Re: [Intel-gfx] [PATCH] drm/i915: Do not cleanup obj with NULL bo->resource

[Das, Nirmoy]

Hi Matt

On 9/20/2022 7:06 PM, Nirmoy Das wrote:

For delayed BO release i915_ttm_delete_mem_notify()
gets called twice, once with proper bo->resource and
another time with NULL. We shouldn't do anything for
the 2nd time as we already cleanedup the obj once.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850



Please add the below Fixes before merging, I missed that.

Fixes: ad74457a6b5a96 ("drm/i915/dgfx: Release mmap on rpm suspend")

Thanks,
Nirmoy


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 0544b0a4a43a..e3fc38dd5db0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -511,7 +511,7 @@ 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 (likely(obj)) {

+   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);