Re: [PATCH] drm/i915: Do not print 'pxp init failed with 0' when it succeed

[Souza, Jose]

On Thu, 2024-03-21 at 14:38 +0200, Jani Nikula wrote:
> On Wed, 20 Mar 2024, José Roberto de Souza  wrote:
> > It is misleading, if the intention was to also print something
> > in case it succeed it should have a different string.
> > 
> > Cc: Alan Previn 
> > Signed-off-by: José Roberto de Souza 
> 
> Fixes: 698e19da2914 ("drm/i915: Skip pxp init if gt is wedged")
> Cc:  # v6.8+
> Reviewed-by: Jani Nikula 

thank you, pushed.

> 
> > ---
> >  drivers/gpu/drm/i915/i915_driver.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 9ee902d5b72c4..4b9233c07a22c 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -800,7 +800,7 @@ int i915_driver_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> > goto out_cleanup_modeset2;
> >  
> > ret = intel_pxp_init(i915);
> > -   if (ret != -ENODEV)
> > +   if (ret && ret != -ENODEV)
> > drm_dbg(>drm, "pxp init failed with %d\n", ret);
> >  
> > ret = intel_display_driver_probe(i915);
> 

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> driver.
> 

Fixes: 44e694958b95 ("drm/xe/display: Implement display support")

> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index e941e2e4fd14..860574d04f88 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -2295,6 +2295,9 @@ static u8 skl_get_plane_caps(struct drm_i915_private 
> *i915,
>   if (HAS_4TILE(i915))
>   caps |= INTEL_PLANE_CAP_TILING_4;
>  
> + if (!IS_ENABLED(I915) && !HAS_FLAT_CCS(i915))
> + return caps;
> +
>   if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
>   caps |= INTEL_PLANE_CAP_CCS_RC;
>   if (DISPLAY_VER(i915) >= 12)

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Thu, 2024-02-29 at 16:44 +, Souza, Jose wrote:
> On Wed, 2024-02-28 at 06:04 -0800, José Roberto de Souza wrote:
> > On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> > > AuxCCS framebuffers don't work on Xe driver hence disable them
> > > from plane capabilities until they are fixed. FlatCCS framebuffers
> > > work and they are left enabled. CCS is left untouched for i915
> > > driver.
> > > 
> > 
> > Reviewed-by: José Roberto de Souza 
> 
> This needs a Fixes tag so it gets backported to Linux 6.8.

Tested on Xe KMD and fixed the issue at least on ADL-P, you can also add:

Tested-by: José Roberto de Souza 

thank you

> 
> > 
> > > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> > > Signed-off-by: Juha-Pekka Heikkila 
> > > ---
> > >  drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > index e941e2e4fd14..860574d04f88 100644
> > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > @@ -2295,6 +2295,9 @@ static u8 skl_get_plane_caps(struct 
> > > drm_i915_private *i915,
> > >   if (HAS_4TILE(i915))
> > >   caps |= INTEL_PLANE_CAP_TILING_4;
> > >  
> > > + if (!IS_ENABLED(I915) && !HAS_FLAT_CCS(i915))
> > > + return caps;
> > > +
> > >   if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> > >   caps |= INTEL_PLANE_CAP_CCS_RC;
> > >   if (DISPLAY_VER(i915) >= 12)
> > 
> 

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Wed, 2024-02-28 at 06:04 -0800, José Roberto de Souza wrote:
> On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> > AuxCCS framebuffers don't work on Xe driver hence disable them
> > from plane capabilities until they are fixed. FlatCCS framebuffers
> > work and they are left enabled. CCS is left untouched for i915
> > driver.
> > 
> 
> Reviewed-by: José Roberto de Souza 

This needs a Fixes tag so it gets backported to Linux 6.8.

> 
> > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> > Signed-off-by: Juha-Pekka Heikkila 
> > ---
> >  drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index e941e2e4fd14..860574d04f88 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -2295,6 +2295,9 @@ static u8 skl_get_plane_caps(struct drm_i915_private 
> > *i915,
> > if (HAS_4TILE(i915))
> > caps |= INTEL_PLANE_CAP_TILING_4;
> >  
> > +   if (!IS_ENABLED(I915) && !HAS_FLAT_CCS(i915))
> > +   return caps;
> > +
> > if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> > caps |= INTEL_PLANE_CAP_CCS_RC;
> > if (DISPLAY_VER(i915) >= 12)
> 

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> driver.
> 

Reviewed-by: José Roberto de Souza 

> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index e941e2e4fd14..860574d04f88 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -2295,6 +2295,9 @@ static u8 skl_get_plane_caps(struct drm_i915_private 
> *i915,
>   if (HAS_4TILE(i915))
>   caps |= INTEL_PLANE_CAP_TILING_4;
>  
> + if (!IS_ENABLED(I915) && !HAS_FLAT_CCS(i915))
> + return caps;
> +
>   if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
>   caps |= INTEL_PLANE_CAP_CCS_RC;
>   if (DISPLAY_VER(i915) >= 12)

Re: [PATCH] drm/i915: Add some boring kerneldoc

[Souza, Jose]

On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Tvrtko Ursulin 
> Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
> Reported-by: Stephen Rothwell 
> Cc: Jose Souza 
> ---
>  include/uapi/drm/i915_drm.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bd87386a8243..2ee338860b7e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3572,9 +3572,13 @@ struct drm_i915_query_memory_regions {
>   * struct drm_i915_query_guc_submission_version - query GuC submission 
> interface version
>   */
>  struct drm_i915_query_guc_submission_version {
> + /** @branch: Firmware branch version. */
>   __u32 branch;
> + /** @major: Firmware major version. */
>   __u32 major;
> + /** @minor: Firmware minor version. */
>   __u32 minor;
> + /** @patch: Firmware patch version. */
>   __u32 patch;
>  };
>  

Re: [PATCH v2] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza, Jose wrote:
> > > > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin 
> > > > > > 
> > > > > > Add a new query to the GuC submission interface version.
> > > > > > 
> > > > > > Mesa intends to use this information to check for old firmware 
> > > > > > versions
> > > > > > with a known bug where using the render and compute command 
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware 
> > > > > > scheduling.
> > > > > > 
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > > 
> > > > > > Compile tested only.
> > > > > > 
> > > > > > v2:
> > > > > >* Added branch version.
> > > > > 
> > > > > Reviewed-by: José Roberto de Souza 
> > > > > Tested-by: José Roberto de Souza 
> > > > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> > > > 
> > > > Thanks, but please we also need to close down on the branch number
> > > > situation. I.e. be sure what is the failure mode in shipping Mesa with
> > > > the change as it stands in the MR linked. What platforms could start
> > > > failing and when, depending on GuC FW release eventualities.
> > > 
> > > yes, I have asked John Harrison for a documentation link about the 
> > > firmware versioning.
> > 
> > Got the documentation link, MR updated.
> > Will ask for reviews in Mesa side.
> 
> Is it then understood and accepted that should GuC ever update the 
> branch number on any given platform, that platform, for all deployed 
> Mesa's in the field, will automatically revert to no async queues and so 
> cause a silent performance regression?

yes, understood and accepted.
The Mesa MR is now reviewed, thank you Sagar.

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > > 
> > > > 
> > > > Regards,
> > > > 
> > > > Tvrtko
> > > > 
> > > > > > Signed-off-by: Tvrtko Ursulin 
> > > > > > Cc: Kenneth Graunke 
> > > > > > Cc: Jose Souza 
> > > > > > Cc: Sagar Ghuge 
> > > > > > Cc: Paulo Zanoni 
> > > > > > Cc: John Harrison 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Tvrtko Ursulin 
> > > > > > Cc: Vivaik Balasubrawmanian 
> > > > > > Cc: Joonas Lahtinen 
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/i915_query.c | 33 
> > > > > > +++
> > > > > >include/uapi/drm/i915_drm.h   | 12 +++
> > > > > >2 files changed, 45 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_query.c 
> > > > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > > > index 00871ef99792..d4dba1240b40 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct 
> > > > > > drm_i915_private *i915,
> > > > > > return hwconfig->size;
> > > > > >}
> > > > > >
> > > > > > +static int
> > > > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > > > +struct drm_i915_query_item *query)
> > > > > > +{
> > > > > > +   struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > > > +   
> > > > > > u64_to_user_ptr(query->data_ptr);
> > > > > > +   struct drm_i915_query_guc_submission_version ver;
> > > > > > +   struct intel_guc *guc = _gt(i915)->uc.guc;
> > > > > > +   const size_t size = sizeof(ver);
> > > > > > +   int r

Re: [PATCH v2] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > On 08/02/2024 14:30, Souza, Jose wrote:
> > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > Add a new query to the GuC submission interface version.
> > > > 
> > > > Mesa intends to use this information to check for old firmware versions
> > > > with a known bug where using the render and compute command streamers
> > > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > > > 
> > > > Based on patches from Vivaik and Joonas.
> > > > 
> > > > Compile tested only.
> > > > 
> > > > v2:
> > > >   * Added branch version.
> > > 
> > > Reviewed-by: José Roberto de Souza 
> > > Tested-by: José Roberto de Souza 
> > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> > 
> > Thanks, but please we also need to close down on the branch number 
> > situation. I.e. be sure what is the failure mode in shipping Mesa with 
> > the change as it stands in the MR linked. What platforms could start 
> > failing and when, depending on GuC FW release eventualities.
> 
> yes, I have asked John Harrison for a documentation link about the firmware 
> versioning.

Got the documentation link, MR updated.
Will ask for reviews in Mesa side.

> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > > > Cc: Kenneth Graunke 
> > > > Cc: Jose Souza 
> > > > Cc: Sagar Ghuge 
> > > > Cc: Paulo Zanoni 
> > > > Cc: John Harrison 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Jani Nikula 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Vivaik Balasubrawmanian 
> > > > Cc: Joonas Lahtinen 
> > > > ---
> > > >   drivers/gpu/drm/i915/i915_query.c | 33 +++
> > > >   include/uapi/drm/i915_drm.h   | 12 +++
> > > >   2 files changed, 45 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_query.c 
> > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > index 00871ef99792..d4dba1240b40 100644
> > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct 
> > > > drm_i915_private *i915,
> > > > return hwconfig->size;
> > > >   }
> > > >   
> > > > +static int
> > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > +struct drm_i915_query_item *query)
> > > > +{
> > > > +   struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > +   
> > > > u64_to_user_ptr(query->data_ptr);
> > > > +   struct drm_i915_query_guc_submission_version ver;
> > > > +   struct intel_guc *guc = _gt(i915)->uc.guc;
> > > > +   const size_t size = sizeof(ver);
> > > > +   int ret;
> > > > +
> > > > +   if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > > +   return -ENODEV;
> > > > +
> > > > +   ret = copy_query_item(, size, size, query);
> > > > +   if (ret != 0)
> > > > +   return ret;
> > > > +
> > > > +   if (ver.branch || ver.major || ver.minor || ver.patch)
> > > > +   return -EINVAL;
> > > > +
> > > > +   ver.branch = 0;
> > > > +   ver.major = guc->submission_version.major;
> > > > +   ver.minor = guc->submission_version.minor;
> > > > +   ver.patch = guc->submission_version.patch;
> > > > +
> > > > +   if (copy_to_user(query_ptr, , size))
> > > > +   return -EFAULT;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > >   static int (* const i915_query_funcs[])(struct drm_i915_private 
> > > > *dev_priv,
> > > > struct drm_i915_query_item 
> > > > *query_item) = {
> > > > query_topology_info,
> > > > @@ -559,6 +591,7 @@ static int (

Re: [PATCH v2] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> On 08/02/2024 14:30, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Add a new query to the GuC submission interface version.
> > > 
> > > Mesa intends to use this information to check for old firmware versions
> > > with a known bug where using the render and compute command streamers
> > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > > 
> > > Based on patches from Vivaik and Joonas.
> > > 
> > > Compile tested only.
> > > 
> > > v2:
> > >   * Added branch version.
> > 
> > Reviewed-by: José Roberto de Souza 
> > Tested-by: José Roberto de Souza 
> > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> 
> Thanks, but please we also need to close down on the branch number 
> situation. I.e. be sure what is the failure mode in shipping Mesa with 
> the change as it stands in the MR linked. What platforms could start 
> failing and when, depending on GuC FW release eventualities.

yes, I have asked John Harrison for a documentation link about the firmware 
versioning.

> 
> Regards,
> 
> Tvrtko
> 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Kenneth Graunke 
> > > Cc: Jose Souza 
> > > Cc: Sagar Ghuge 
> > > Cc: Paulo Zanoni 
> > > Cc: John Harrison 
> > > Cc: Rodrigo Vivi 
> > > Cc: Jani Nikula 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Vivaik Balasubrawmanian 
> > > Cc: Joonas Lahtinen 
> > > ---
> > >   drivers/gpu/drm/i915/i915_query.c | 33 +++
> > >   include/uapi/drm/i915_drm.h   | 12 +++
> > >   2 files changed, 45 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_query.c 
> > > b/drivers/gpu/drm/i915/i915_query.c
> > > index 00871ef99792..d4dba1240b40 100644
> > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct 
> > > drm_i915_private *i915,
> > >   return hwconfig->size;
> > >   }
> > >   
> > > +static int
> > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > +  struct drm_i915_query_item *query)
> > > +{
> > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > + u64_to_user_ptr(query->data_ptr);
> > > + struct drm_i915_query_guc_submission_version ver;
> > > + struct intel_guc *guc = _gt(i915)->uc.guc;
> > > + const size_t size = sizeof(ver);
> > > + int ret;
> > > +
> > > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > + return -ENODEV;
> > > +
> > > + ret = copy_query_item(, size, size, query);
> > > + if (ret != 0)
> > > + return ret;
> > > +
> > > + if (ver.branch || ver.major || ver.minor || ver.patch)
> > > + return -EINVAL;
> > > +
> > > + ver.branch = 0;
> > > + ver.major = guc->submission_version.major;
> > > + ver.minor = guc->submission_version.minor;
> > > + ver.patch = guc->submission_version.patch;
> > > +
> > > + if (copy_to_user(query_ptr, , size))
> > > + return -EFAULT;
> > > +
> > > + return 0;
> > > +}
> > > +
> > >   static int (* const i915_query_funcs[])(struct drm_i915_private 
> > > *dev_priv,
> > >   struct drm_i915_query_item 
> > > *query_item) = {
> > >   query_topology_info,
> > > @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct 
> > > drm_i915_private *dev_priv,
> > >   query_memregion_info,
> > >   query_hwconfig_blob,
> > >   query_geometry_subslices,
> > > + query_guc_submission_version,
> > >   };
> > >   
> > >   int i915_query_ioctl(struct drm_device *dev, void *data, struct 
> > > drm_file *file)
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index 550c496ce76d..84fb7f7ea834 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
> > >* 

Re: [PATCH v2] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Add a new query to the GuC submission interface version.
> 
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
> simultaneously can cause GPU hangs due issues in firmware scheduling.
> 
> Based on patches from Vivaik and Joonas.
> 
> Compile tested only.
> 
> v2:
>  * Added branch version.

Reviewed-by: José Roberto de Souza 
Tested-by: José Roberto de Souza 
UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233

> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Kenneth Graunke 
> Cc: Jose Souza 
> Cc: Sagar Ghuge 
> Cc: Paulo Zanoni 
> Cc: John Harrison 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: Tvrtko Ursulin 
> Cc: Vivaik Balasubrawmanian 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_query.c | 33 +++
>  include/uapi/drm/i915_drm.h   | 12 +++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> b/drivers/gpu/drm/i915/i915_query.c
> index 00871ef99792..d4dba1240b40 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct drm_i915_private 
> *i915,
>   return hwconfig->size;
>  }
>  
> +static int
> +query_guc_submission_version(struct drm_i915_private *i915,
> +  struct drm_i915_query_item *query)
> +{
> + struct drm_i915_query_guc_submission_version __user *query_ptr =
> + u64_to_user_ptr(query->data_ptr);
> + struct drm_i915_query_guc_submission_version ver;
> + struct intel_guc *guc = _gt(i915)->uc.guc;
> + const size_t size = sizeof(ver);
> + int ret;
> +
> + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> + return -ENODEV;
> +
> + ret = copy_query_item(, size, size, query);
> + if (ret != 0)
> + return ret;
> +
> + if (ver.branch || ver.major || ver.minor || ver.patch)
> + return -EINVAL;
> +
> + ver.branch = 0;
> + ver.major = guc->submission_version.major;
> + ver.minor = guc->submission_version.minor;
> + ver.patch = guc->submission_version.patch;
> +
> + if (copy_to_user(query_ptr, , size))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
>  static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>   struct drm_i915_query_item *query_item) 
> = {
>   query_topology_info,
> @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct 
> drm_i915_private *dev_priv,
>   query_memregion_info,
>   query_hwconfig_blob,
>   query_geometry_subslices,
> + query_guc_submission_version,
>  };
>  
>  int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *file)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 550c496ce76d..84fb7f7ea834 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
>*  - %DRM_I915_QUERY_MEMORY_REGIONS (see struct 
> drm_i915_query_memory_regions)
>*  - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob uAPI`)
>*  - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct 
> drm_i915_query_topology_info)
> +  *  - %DRM_I915_QUERY_GUC_SUBMISSION_VERSION (see struct 
> drm_i915_query_guc_submission_version)
>*/
>   __u64 query_id;
>  #define DRM_I915_QUERY_TOPOLOGY_INFO 1
> @@ -3046,6 +3047,7 @@ struct drm_i915_query_item {
>  #define DRM_I915_QUERY_MEMORY_REGIONS4
>  #define DRM_I915_QUERY_HWCONFIG_BLOB 5
>  #define DRM_I915_QUERY_GEOMETRY_SUBSLICES6
> +#define DRM_I915_QUERY_GUC_SUBMISSION_VERSION7
>  /* Must be kept compact -- no holes and well documented */
>  
>   /**
> @@ -3591,6 +3593,16 @@ struct drm_i915_query_memory_regions {
>   struct drm_i915_memory_region_info regions[];
>  };
>  
> +/**
> +* struct drm_i915_query_guc_submission_version - query GuC submission 
> interface version
> +*/
> +struct drm_i915_query_guc_submission_version {
> + __u32 branch;
> + __u32 major;
> + __u32 minor;
> + __u32 patch;
> +};
> +
>  /**
>   * DOC: GuC HWCONFIG blob uAPI
>   *

Re: [RFC] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
> On 2/7/2024 11:43, Souza, Jose wrote:
> > On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> > > On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > > > On 07/02/2024 18:12, John Harrison wrote:
> > > > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin 
> > > > > > 
> > > > > > Add a new query to the GuC submission interface version.
> > > > > > 
> > > > > > Mesa intends to use this information to check for old firmware 
> > > > > > versions
> > > > > > with a known bug where using the render and compute command 
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware 
> > > > > > scheduling.
> > > > > > 
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > > 
> > > > > > There is a little bit of an open around the width required for
> > > > > > versions.
> > > > > > While the GuC FW iface tells they are u8, i915 GuC code uses u32:
> > > > > > 
> > > > > >    #define CSS_SW_VERSION_UC_MAJOR   (0xFF << 16)
> > > > > >    #define CSS_SW_VERSION_UC_MINOR   (0xFF << 8)
> > > > > >    #define CSS_SW_VERSION_UC_PATCH   (0xFF << 0)
> > > > > > ...
> > > > > >    struct intel_uc_fw_ver {
> > > > > >    u32 major;
> > > > > >    u32 minor;
> > > > > >    u32 patch;
> > > > > >    u32 build;
> > > > > >    };
> > > > > This is copied from generic code which supports firmwares other than
> > > > > GuC. Only GuC promises to use 8-bit version components. Other
> > > > > firmwares very definitely do not. There is no open.
> > > > Ack.
> > > > 
> > > > > > So we could make the query u8, and refactor the struct 
> > > > > > intel_uc_fw_ver
> > > > > > to use u8, or not. To avoid any doubts on why are we assigning u32 
> > > > > > to
> > > > > > u8 I simply opted to use u64. Which avoids the need to add any 
> > > > > > padding
> > > > > > too.
> > > > > I don't follow how potential 8 vs 32 confusion means jump to 64?!
> > > > Suggestion was to use u8 in the uapi in order to align with GuC FW ABI
> > > > (or however it's called), in which case there would be:
> > > > 
> > > >     ver.major = guc->submission_version.major;
> > > > 
> > > > which would be:
> > > > 
> > > >     (u8) = (u32)
> > > > 
> > > > And I was anticipating someone not liking that either. Using too wide
> > > > u64 simply avoids the need to add a padding element to the uapi struct.
> > > > 
> > > > If you are positive we need to include a branch number, even though it
> > > > does not seem to be implemented in the code even(*) then I can make
> > > > uapi 4x u32 and achieve the same.
> > > It's not implemented in the code because we've never had to, and it is
> > > yet another train wreck waiting to happen. There are a bunch of issues
> > > at different levels that need to be resolved. But that is all in the
> > > kernel and/or firmware and so can be added by a later kernel update when
> > > necessary. However, if the UMDs are not already taking it into account
> > > or its not even in the UAPI, then we can't back fill in the kernel
> > > later, we are just broken.
> > This sounds to me like a firmware version for internal testing or for 
> > pre-production HW, would any branched firmware be released to customers?
> See comments below. Branching is about back porting critical fixes to 
> older releases. I.e. supporting LTS releases. There is absolutely 
> nothing internal only or testing related about branching.
> 
> Just because we haven't had to do so yet doesn't mean we won't need to 
> do so tomorrow.
> 
> John.
> 
> > 
> > > > (*)
> > > > static void uc_unpack_css_version(struct intel_uc_fw_ver *ver, u32
> > > > css_value)
> > > > {
> > > >  /* Get version numbers from the CSS header */
> > > >  ver->major = FIELD_GET(CSS_SW_VERSION_UC_

Re: [RFC] drm/i915: Add GuC submission interface version query

[Souza, Jose]

On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > On 07/02/2024 18:12, John Harrison wrote:
> > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > Add a new query to the GuC submission interface version.
> > > > 
> > > > Mesa intends to use this information to check for old firmware versions
> > > > with a known bug where using the render and compute command streamers
> > > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > > > 
> > > > Based on patches from Vivaik and Joonas.
> > > > 
> > > > There is a little bit of an open around the width required for 
> > > > versions.
> > > > While the GuC FW iface tells they are u8, i915 GuC code uses u32:
> > > > 
> > > >   #define CSS_SW_VERSION_UC_MAJOR   (0xFF << 16)
> > > >   #define CSS_SW_VERSION_UC_MINOR   (0xFF << 8)
> > > >   #define CSS_SW_VERSION_UC_PATCH   (0xFF << 0)
> > > > ...
> > > >   struct intel_uc_fw_ver {
> > > >   u32 major;
> > > >   u32 minor;
> > > >   u32 patch;
> > > >   u32 build;
> > > >   };
> > > This is copied from generic code which supports firmwares other than 
> > > GuC. Only GuC promises to use 8-bit version components. Other 
> > > firmwares very definitely do not. There is no open.
> > 
> > Ack.
> > 
> > > > 
> > > > So we could make the query u8, and refactor the struct intel_uc_fw_ver
> > > > to use u8, or not. To avoid any doubts on why are we assigning u32 to
> > > > u8 I simply opted to use u64. Which avoids the need to add any padding
> > > > too.
> > > I don't follow how potential 8 vs 32 confusion means jump to 64?!
> > 
> > Suggestion was to use u8 in the uapi in order to align with GuC FW ABI 
> > (or however it's called), in which case there would be:
> > 
> >    ver.major = guc->submission_version.major;
> > 
> > which would be:
> > 
> >    (u8) = (u32)
> > 
> > And I was anticipating someone not liking that either. Using too wide 
> > u64 simply avoids the need to add a padding element to the uapi struct.
> > 
> > If you are positive we need to include a branch number, even though it 
> > does not seem to be implemented in the code even(*) then I can make 
> > uapi 4x u32 and achieve the same.
> It's not implemented in the code because we've never had to, and it is 
> yet another train wreck waiting to happen. There are a bunch of issues 
> at different levels that need to be resolved. But that is all in the 
> kernel and/or firmware and so can be added by a later kernel update when 
> necessary. However, if the UMDs are not already taking it into account 
> or its not even in the UAPI, then we can't back fill in the kernel 
> later, we are just broken.

This sounds to me like a firmware version for internal testing or for 
pre-production HW, would any branched firmware be released to customers?

> 
> > 
> > (*)
> > static void uc_unpack_css_version(struct intel_uc_fw_ver *ver, u32 
> > css_value)
> > {
> > /* Get version numbers from the CSS header */
> > ver->major = FIELD_GET(CSS_SW_VERSION_UC_MAJOR, css_value);
> > ver->minor = FIELD_GET(CSS_SW_VERSION_UC_MINOR, css_value);
> > ver->patch = FIELD_GET(CSS_SW_VERSION_UC_PATCH, css_value);
> > }
> > 
> > No branch field in the CSS header?
> I think there is, it's just not officially implemented yet.
> 
> > 
> > And Why is UMD supposed to reject a non-zero branch? Like how would 
> > 1.1.3.0 be fine and 1.1.3.1 be bad? I don't get it. But anyway, I can 
> > respin if you definitely confirm.
> Because that is backwards. The branch number goes at the front.
> 
> So, for example (using made up numbers, I don't recall offhand what 
> versions we have where) say we currently have 0.1.3.0 in tip and 0.1.1.0 
> in the last LTS. We then need to ship a critical security fix and back 
> port it to the LTS. Tip becomes 0.1.3.1 but the LTS can't become 0.1.1.1 
> because that version already exists in the history of tip and does not 
> contain the fix. So the LTS gets branched to 1.1.0.0. We then have both 
> branches potentially moving forwards with completely independent versioning.
> 
> Exactly the same as 5.8.x, 5.9,y, 6.0.z, etc in the Linux kernel 
> versioning. You cannot make any assumptions about what might be in 
> 1.4.5.6 compared to 0.1.2.3. 1.4.5.6 could actually 0.1.0.3 with a stack 
> of security fixes but none of the features, workarounds or bug fixes 
> that are in 0.1.2.3.
> 
> Hence, if the branch number changes then all bets are off. You have to 
> start over and reject anything you do not explicitly know about.
> 
> This is why we were saying that exposing version numbers to UMDs breaks 
> down horribly as soon as we have to start branching. There is no clean 
> or simple way to do this.
> 
> John.
> 
> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > > 
> > > > Compile tested only.
> > > > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > > > Cc: Kenneth Graunke 
> 

Re: [RFC PATCH] drm/i915: Add GETPARAM for GuC submission version

[Souza, Jose]

On Wed, 2024-02-07 at 13:36 +0200, Joonas Lahtinen wrote:
> Quoting Tvrtko Ursulin (2024-02-07 10:44:01)
> > 
> > On 06/02/2024 20:51, Souza, Jose wrote:
> > > On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
> > > > On 2/6/2024 08:33, Tvrtko Ursulin wrote:
> > > > > On 01/02/2024 18:25, Souza, Jose wrote:
> > > > > > On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> > > > > > > On 24/01/2024 08:19, Joonas Lahtinen wrote:
> > > > > > > > Add reporting of the GuC submissio/VF interface version via 
> > > > > > > > GETPARAM
> > > > > > > > properties. Mesa intends to use this information to check for 
> > > > > > > > old
> > > > > > > > firmware versions with known bugs before enabling features like 
> > > > > > > > async
> > > > > > > > compute.
> > > > > > > 
> > > > > > > There was
> > > > > > > https://patchwork.freedesktop.org/patch/560704/?series=124592=1
> > > > > > > which does everything in one go so would be my preference.
> > > > > > 
> > > > > > IMO Joonas version brings less burden to be maintained(no new 
> > > > > > struct).
> > > > > > But both versions works, please just get into some agreement so we
> > > > > > can move this forward.
> > > > > 
> > > > > So I would really prefer the query. Simplified version would do like
> > > > > the compile tested only:
> > > > Vivaik's patch is definitely preferred. It is much cleaner to make one
> > > > single call than having to make four separate calls. It is also
> > > > extensible to other firmwares if required. The only blockage against it
> > > > was whether it was a good thing to report at all. If that blockage is no
> > > > longer valid then we should just merge the patch that has already been
> > > > discussed, polished, fixed, etc. rather than starting the whole process
> > > > from scratch.
> > > 
> > > Agreed.
> > > 
> > > Vivaik can you please rebase and send it again?
> > 
> > Note there was review feedback not addressed so do that too please. 
> > AFAIR incorrect usage of copy item, pad/rsvd/mbz checking and questions 
> > about padding in general. Last is why I proposed a simplified version 
> > which is not future extensible and avoids the need for padding.
> 
> Yeah, I don't think there is point an adding an extensible interface as
> we're not going to add further FW version queries. This only the
> submission interface version we're going to expose:
> 
>  * Note that the spec for the CSS header defines this version number
>  * as 'vf_version' as it was originally intended for virtualisation.
>  * However, it is applicable to native submission as well.
> 
> If somebody wants to work on the simplified version like Tvrtko
> suggested below, I have no objection. We can also remove the reference
> to the VF version even if that's used by the header definition.
> 
> But if there are just suggestions but no actual patches floated, then we
> should be merging the GETPARAM version with the "VF" word removed.
> 
> We've already discussed on the topic for some months so doing the
> minimal changes to fulfill Mesa requirements should be considered a
> priority to avoid further delays.

This is

Reviewed-by: José Roberto de Souza 
Tested-by: José Roberto de Souza 

Here the user-space usage: 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233

> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > 
> > > 
> > > > 
> > > > And note that it is four calls not three. The code below is missing the
> > > > branch version number.
> 
> Not even kernel uses the 'build' version anywhere. I don't see how there
> could be 'build' version for the VF interface version? It's not supposed
> to version a concrete firmware build but the API contract implemented by
> the build where patch version should already be incremented for each
> fix.
> 
> So adding the build does not seem appropriate as there is no plan to
> extend this API any further.
> 
> Regards, Joonas 
> 
> > > > 
> > > > John.
> > > > 
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > > i

Re: [RFC PATCH] drm/i915: Add GETPARAM for GuC submission version

[Souza, Jose]

On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
> On 2/6/2024 08:33, Tvrtko Ursulin wrote:
> > On 01/02/2024 18:25, Souza, Jose wrote:
> > > On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> > > > On 24/01/2024 08:19, Joonas Lahtinen wrote:
> > > > > Add reporting of the GuC submissio/VF interface version via GETPARAM
> > > > > properties. Mesa intends to use this information to check for old
> > > > > firmware versions with known bugs before enabling features like async
> > > > > compute.
> > > > 
> > > > There was
> > > > https://patchwork.freedesktop.org/patch/560704/?series=124592=1
> > > > which does everything in one go so would be my preference.
> > > 
> > > IMO Joonas version brings less burden to be maintained(no new struct).
> > > But both versions works, please just get into some agreement so we 
> > > can move this forward.
> > 
> > So I would really prefer the query. Simplified version would do like 
> > the compile tested only:
> Vivaik's patch is definitely preferred. It is much cleaner to make one 
> single call than having to make four separate calls. It is also 
> extensible to other firmwares if required. The only blockage against it 
> was whether it was a good thing to report at all. If that blockage is no 
> longer valid then we should just merge the patch that has already been 
> discussed, polished, fixed, etc. rather than starting the whole process 
> from scratch.

Agreed.

Vivaik can you please rebase and send it again?


> 
> And note that it is four calls not three. The code below is missing the 
> branch version number.
> 
> John.
> 
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_query.c 
> > b/drivers/gpu/drm/i915/i915_query.c
> > index 00871ef99792..999687f6a3d4 100644
> > --- a/drivers/gpu/drm/i915/i915_query.c
> > +++ b/drivers/gpu/drm/i915/i915_query.c
> > @@ -551,6 +551,37 @@ static int query_hwconfig_blob(struct 
> > drm_i915_private *i915,
> >     return hwconfig->size;
> >  }
> > 
> > +static int
> > +query_guc_submission_version(struct drm_i915_private *i915,
> > +    struct drm_i915_query_item *query)
> > +{
> > +   struct drm_i915_query_guc_submission_version __user *query_ptr =
> > + u64_to_user_ptr(query->data_ptr);
> > +   struct drm_i915_query_guc_submission_version ver;
> > +   struct intel_guc *guc = _gt(i915)->uc.guc;
> > +   const size_t size = sizeof(ver);
> > +   int ret;
> > +
> > +   if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > +   return -ENODEV;
> > +
> > +   ret = copy_query_item(, size, size, query);
> > +   if (ret != 0)
> > +   return ret;
> > +
> > +   if (ver.major || ver.minor || ver.patch)
> > +   return -EINVAL;
> > +
> > +   ver.major = guc->submission_version.major;
> > +   ver.minor = guc->submission_version.minor;
> > +   ver.patch = guc->submission_version.patch;
> > +
> > +   if (copy_to_user(query_ptr, , size))
> > +   return -EFAULT;
> > +
> > +   return 0;
> > +}
> > +
> >  static int (* const i915_query_funcs[])(struct drm_i915_private 
> > *dev_priv,
> >     struct drm_i915_query_item 
> > *query_item) = {
> >     query_topology_info,
> > @@ -559,6 +590,7 @@ static int (* const i915_query_funcs[])(struct 
> > drm_i915_private *dev_priv,
> >     query_memregion_info,
> >     query_hwconfig_blob,
> >     query_geometry_subslices,
> > +   query_guc_submission_version,
> >  };
> > 
> >  int i915_query_ioctl(struct drm_device *dev, void *data, struct 
> > drm_file *file)
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 550c496ce76d..d80d9b5e1eda 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
> >  *  - %DRM_I915_QUERY_MEMORY_REGIONS (see struct 
> > drm_i915_query_memory_regions)
> >  *  - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob 
> > uAPI`)
> >  *  - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct 
> > drm_i915_query_topology_info)
> > +    *  - %DRM_I915_QUERY_GUC_SUBMISSION_VERSION (see struct 
> > drm_i915_query_guc_submission_version)
> >  */
> >     __u64

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Thu, 2024-01-25 at 08:07 -0800, José Roberto de Souza wrote:
> On Thu, 2024-01-25 at 17:56 +0200, Juha-Pekka Heikkila wrote:
> > On 25.1.2024 17.28, Souza, Jose wrote:
> > > On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> > > > AuxCCS framebuffers don't work on Xe driver hence disable them
> > > > from plane capabilities until they are fixed. FlatCCS framebuffers
> > > > work and they are left enabled. CCS is left untouched for i915
> > > > deriver.
> > > > 
> > > > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> > > > Signed-off-by: Juha-Pekka Heikkila 
> > > > ---
> > > >   drivers/gpu/drm/i915/display/skl_universal_plane.c | 8 
> > > >   1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > > > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > > index 511dc1544854..1521d829525a 100644
> > > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > > @@ -2290,6 +2290,14 @@ static u8 skl_get_plane_caps(struct 
> > > > drm_i915_private *i915,
> > > > if (HAS_4TILE(i915))
> > > > caps |= INTEL_PLANE_CAP_TILING_4;
> > > >   
> > > > +   /*
> > > > +* FIXME: Below if(IS_ENABLED(CONFIG_I915)..) is because Xe 
> > > > driver
> > > > +* can't use AuxCCS framebuffers. Once they are fixed this need 
> > > > to be
> > > > +* removed.
> > > > +*/
> > > > +   if (!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915))
> > > > +   return caps;
> > > > +
> > > 
> > > functional but looks odd.
> > > would rather add a check inside of gen12_plane_has_mc_ccs() or 'if 
> > > ((!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915)) && 
> > > gen12_plane_has_mc_ccs(i915,
> > > plane_id))'
> > 
> > Hi Jose,
> > 
> > not sure I understood your idea. Here need to be disabled all versions 
> > of aux ccs for Xe, not just mc ccs.
> 
> ah misplace this this...please ignore.
> 
> this is fine for something that will be fixed soon.
> 
> Reviewed-by: José Roberto de Souza 

ping!
something is holding from being merged?

> 
> 
> 
> > 
> > > 
> > > > if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> > > > caps |= INTEL_PLANE_CAP_CCS_RC;
> > > > if (DISPLAY_VER(i915) >= 12)
> > > 
> > 
> 

Re: [RFC PATCH] drm/i915: Add GETPARAM for GuC submission version

[Souza, Jose]

On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> On 24/01/2024 08:19, Joonas Lahtinen wrote:
> > Add reporting of the GuC submissio/VF interface version via GETPARAM
> > properties. Mesa intends to use this information to check for old
> > firmware versions with known bugs before enabling features like async
> > compute.
> 
> There was 
> https://patchwork.freedesktop.org/patch/560704/?series=124592=1 
> which does everything in one go so would be my preference.

IMO Joonas version brings less burden to be maintained(no new struct).
But both versions works, please just get into some agreement so we can move 
this forward.

> 
> During the time of that patch there was discussion whether firmware 
> version or submission version was better. I vaguely remember someone 
> raised an issue with the latter. Adding John in case he remembers.
> 
> > Signed-off-by: Joonas Lahtinen 
> > Cc: Kenneth Graunke 
> > Cc: Jose Souza 
> > Cc: Sagar Ghuge 
> > Cc: Paulo Zanoni 
> > Cc: John Harrison 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/i915_getparam.c | 12 
> >   include/uapi/drm/i915_drm.h  | 13 +
> >   2 files changed, 25 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
> > b/drivers/gpu/drm/i915/i915_getparam.c
> > index 5c3fec63cb4c1..f176372debc54 100644
> > --- a/drivers/gpu/drm/i915/i915_getparam.c
> > +++ b/drivers/gpu/drm/i915/i915_getparam.c
> > @@ -113,6 +113,18 @@ int i915_getparam_ioctl(struct drm_device *dev, void 
> > *data,
> > if (value < 0)
> > return value;
> > break;
> > +   case I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR:
> > +   case I915_PARAM_GUC_SUBMISSION_VERSION_MINOR:
> > +   case I915_PARAM_GUC_SUBMISSION_VERSION_PATCH:
> > +   if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > +   return -ENODEV;
> > +   if (param->param == I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR)
> > +   value = to_gt(i915)->uc.guc.submission_version.major;
> > +   else if (param->param == 
> > I915_PARAM_GUC_SUBMISSION_VERSION_MINOR)
> > +   value = to_gt(i915)->uc.guc.submission_version.minor;
> > +   else
> > +   value = to_gt(i915)->uc.guc.submission_version.patch;
> > +   break;
> > case I915_PARAM_MMAP_GTT_VERSION:
> > /* Though we've started our numbering from 1, and so class all
> >  * earlier versions as 0, in effect their value is undefined as
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index fd4f9574d177a..7d5a47f182542 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -806,6 +806,19 @@ typedef struct drm_i915_irq_wait {
> >*/
> >   #define I915_PARAM_PXP_STATUS  58
> >   
> > +/*
> > + * Query for the GuC submission/VF interface version number
> 
> What is this VF you speak of? :/
> 
> Regards,
> 
> Tvrtko
> 
> > + *
> > + * -ENODEV is returned if GuC submission is not used
> > + *
> > + * On success, returns the respective GuC submission/VF interface major,
> > + * minor or patch version as per the requested parameter.
> > + *
> > + */
> > +#define I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR 59
> > +#define I915_PARAM_GUC_SUBMISSION_VERSION_MINOR 60
> > +#define I915_PARAM_GUC_SUBMISSION_VERSION_PATCH 61
> > +
> >   /* Must be kept compact -- no holes and well documented */
> >   
> >   /**

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Thu, 2024-01-25 at 17:56 +0200, Juha-Pekka Heikkila wrote:
> On 25.1.2024 17.28, Souza, Jose wrote:
> > On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> > > AuxCCS framebuffers don't work on Xe driver hence disable them
> > > from plane capabilities until they are fixed. FlatCCS framebuffers
> > > work and they are left enabled. CCS is left untouched for i915
> > > deriver.
> > > 
> > > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> > > Signed-off-by: Juha-Pekka Heikkila 
> > > ---
> > >   drivers/gpu/drm/i915/display/skl_universal_plane.c | 8 
> > >   1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > index 511dc1544854..1521d829525a 100644
> > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > @@ -2290,6 +2290,14 @@ static u8 skl_get_plane_caps(struct 
> > > drm_i915_private *i915,
> > >   if (HAS_4TILE(i915))
> > >   caps |= INTEL_PLANE_CAP_TILING_4;
> > >   
> > > + /*
> > > +  * FIXME: Below if(IS_ENABLED(CONFIG_I915)..) is because Xe driver
> > > +  * can't use AuxCCS framebuffers. Once they are fixed this need to be
> > > +  * removed.
> > > +  */
> > > + if (!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915))
> > > + return caps;
> > > +
> > 
> > functional but looks odd.
> > would rather add a check inside of gen12_plane_has_mc_ccs() or 'if 
> > ((!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915)) && 
> > gen12_plane_has_mc_ccs(i915,
> > plane_id))'
> 
> Hi Jose,
> 
> not sure I understood your idea. Here need to be disabled all versions 
> of aux ccs for Xe, not just mc ccs.

ah misplace this this...please ignore.

this is fine for something that will be fixed soon.

Reviewed-by: José Roberto de Souza 



> 
> > 
> > >   if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> > >   caps |= INTEL_PLANE_CAP_CCS_RC;
> > >   if (DISPLAY_VER(i915) >= 12)
> > 
> 

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

[Souza, Jose]

On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> deriver.
> 
> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/display/skl_universal_plane.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 511dc1544854..1521d829525a 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -2290,6 +2290,14 @@ static u8 skl_get_plane_caps(struct drm_i915_private 
> *i915,
>   if (HAS_4TILE(i915))
>   caps |= INTEL_PLANE_CAP_TILING_4;
>  
> + /*
> +  * FIXME: Below if(IS_ENABLED(CONFIG_I915)..) is because Xe driver
> +  * can't use AuxCCS framebuffers. Once they are fixed this need to be
> +  * removed.
> +  */
> + if (!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915))
> + return caps;
> +

functional but looks odd.
would rather add a check inside of gen12_plane_has_mc_ccs() or 'if 
((!IS_ENABLED(CONFIG_I915) && !HAS_FLAT_CCS(i915)) && 
gen12_plane_has_mc_ccs(i915,
plane_id))'

>   if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
>   caps |= INTEL_PLANE_CAP_CCS_RC;
>   if (DISPLAY_VER(i915) >= 12)

Re: [RFC PATCH] drm/i915: Add GETPARAM for GuC submission version

[Souza, Jose]

On Wed, 2024-01-24 at 10:19 +0200, Joonas Lahtinen wrote:
> Add reporting of the GuC submissio/VF interface version via GETPARAM
> properties. Mesa intends to use this information to check for old
> firmware versions with known bugs before enabling features like async
> compute.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Joonas Lahtinen 
> Cc: Kenneth Graunke 
> Cc: Jose Souza 
> Cc: Sagar Ghuge 
> Cc: Paulo Zanoni 
> Cc: John Harrison 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_getparam.c | 12 
>  include/uapi/drm/i915_drm.h  | 13 +
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
> b/drivers/gpu/drm/i915/i915_getparam.c
> index 5c3fec63cb4c1..f176372debc54 100644
> --- a/drivers/gpu/drm/i915/i915_getparam.c
> +++ b/drivers/gpu/drm/i915/i915_getparam.c
> @@ -113,6 +113,18 @@ int i915_getparam_ioctl(struct drm_device *dev, void 
> *data,
>   if (value < 0)
>   return value;
>   break;
> + case I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR:
> + case I915_PARAM_GUC_SUBMISSION_VERSION_MINOR:
> + case I915_PARAM_GUC_SUBMISSION_VERSION_PATCH:
> + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> + return -ENODEV;
> + if (param->param == I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR)
> + value = to_gt(i915)->uc.guc.submission_version.major;
> + else if (param->param == 
> I915_PARAM_GUC_SUBMISSION_VERSION_MINOR)
> + value = to_gt(i915)->uc.guc.submission_version.minor;
> + else
> + value = to_gt(i915)->uc.guc.submission_version.patch;
> + break;
>   case I915_PARAM_MMAP_GTT_VERSION:
>   /* Though we've started our numbering from 1, and so class all
>* earlier versions as 0, in effect their value is undefined as
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index fd4f9574d177a..7d5a47f182542 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -806,6 +806,19 @@ typedef struct drm_i915_irq_wait {
>   */
>  #define I915_PARAM_PXP_STATUS 58
>  
> +/*
> + * Query for the GuC submission/VF interface version number
> + *
> + * -ENODEV is returned if GuC submission is not used
> + *
> + * On success, returns the respective GuC submission/VF interface major,
> + * minor or patch version as per the requested parameter.
> + *
> + */
> +#define I915_PARAM_GUC_SUBMISSION_VERSION_MAJOR 59
> +#define I915_PARAM_GUC_SUBMISSION_VERSION_MINOR 60
> +#define I915_PARAM_GUC_SUBMISSION_VERSION_PATCH 61
> +
>  /* Must be kept compact -- no holes and well documented */
>  
>  /**

Re: [PATCH] drm/xe/display: Disable aux ccs framebuffers

[Souza, Jose]

On Mon, 2024-01-08 at 17:18 -0500, Rodrigo Vivi wrote:
> On Tue, Jan 02, 2024 at 09:44:48PM +0200, Jani Nikula wrote:
> > On Tue, 02 Jan 2024, Juha-Pekka Heikkila  
> > wrote:
> > > Aux ccs framebuffers don't work on Xe driver hence disable them
> > > from plane capabilities until they are fixed. Flat ccs framebuffers
> > > work and they are left enabled. Here is separated plane capabilities
> > > check on i915 so it can behave differencly depending on the driver.
> > 
> > Cc: Rodrigo and xe maintainers
> > 
> > We need to figure out the proper workflow, the mailing lists to use, the
> > subject prefix to use, the acks to require, etc, for changes touching
> > both xe and i915.
> > 
> > I'd very much prefer changes to i915 display to be merged via
> > drm-intel-next as always. For one thing, it'll take a while to sync
> > stuff back from drm-xe-next to drm-intel-next, and most display
> > development still happens on drm-intel-next.
> 
> I fully agree with you.
> 
> > 
> > But this patch can't be applied to drm-intel-next, because xe doesn't
> > even exist on drm-intel-next yet...
> 
> should we do a backmerge of drm-next already, or too early for that?

Can we split it into 2 patches and merge it?
This is necessary to fix Wayland compositors on ADL and newer.

> 
> > 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> > > Signed-off-by: Juha-Pekka Heikkila 
> > > ---
> > >  drivers/gpu/drm/i915/Makefile |  1 +
> > >  .../gpu/drm/i915/display/intel_plane_caps.c   | 68 +++
> > >  .../gpu/drm/i915/display/intel_plane_caps.h   | 14 
> > >  .../drm/i915/display/skl_universal_plane.c| 61 +
> > >  drivers/gpu/drm/xe/display/xe_plane_initial.c | 23 +++
> > >  5 files changed, 107 insertions(+), 60 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_plane_caps.c
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_plane_caps.h
> > > 
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index e777686190ca..c5e3c2dd0a01 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -302,6 +302,7 @@ i915-y += \
> > >   display/intel_overlay.o \
> > >   display/intel_pch_display.o \
> > >   display/intel_pch_refclk.o \
> > > + display/intel_plane_caps.o \
> > >   display/intel_plane_initial.o \
> > >   display/intel_pmdemand.o \
> > >   display/intel_psr.o \
> > > diff --git a/drivers/gpu/drm/i915/display/intel_plane_caps.c 
> > > b/drivers/gpu/drm/i915/display/intel_plane_caps.c
> > > new file mode 100644
> > > index ..6206ae11f296
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/display/intel_plane_caps.c
> > > @@ -0,0 +1,68 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2024 Intel Corporation
> > > + */
> > > +
> > > +#include "i915_drv.h"
> > > +#include "intel_fb.h"
> > > +#include "intel_plane_caps.h"
> > > +
> > > +static bool skl_plane_has_rc_ccs(struct drm_i915_private *i915,
> > > +  enum pipe pipe, enum plane_id plane_id)
> > > +{
> > > + /* Wa_22011186057 */
> > > + if (IS_ALDERLAKE_P(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> > > + return false;
> > > +
> > > + if (DISPLAY_VER(i915) >= 11)
> > > + return true;
> > > +
> > > + if (IS_GEMINILAKE(i915))
> > > + return pipe != PIPE_C;
> > > +
> > > + return pipe != PIPE_C &&
> > > + (plane_id == PLANE_PRIMARY ||
> > > +  plane_id == PLANE_SPRITE0);
> > > +}
> > > +
> > > +static bool gen12_plane_has_mc_ccs(struct drm_i915_private *i915,
> > > +enum plane_id plane_id)
> > > +{
> > > + if (DISPLAY_VER(i915) < 12)
> > > + return false;
> > > +
> > > + /* Wa_14010477008 */
> > > + if (IS_DG1(i915) || IS_ROCKETLAKE(i915) ||
> > > + (IS_TIGERLAKE(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_D0)))
> > > + return false;
> > > +
> > > + /* Wa_22011186057 */
> > > + if (IS_ALDERLAKE_P(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> > > + return false;
> > > +
> > > + return plane_id < PLANE_SPRITE4;
> > > +}
> > > +
> > > +u8 skl_get_plane_caps(struct drm_i915_private *i915,
> > > +   enum pipe pipe, enum plane_id plane_id)
> > > +{
> > > + u8 caps = INTEL_PLANE_CAP_TILING_X;
> > > +
> > > + if (DISPLAY_VER(i915) < 13 || IS_ALDERLAKE_P(i915))
> > > + caps |= INTEL_PLANE_CAP_TILING_Y;
> > > + if (DISPLAY_VER(i915) < 12)
> > > + caps |= INTEL_PLANE_CAP_TILING_Yf;
> > > + if (HAS_4TILE(i915))
> > > + caps |= INTEL_PLANE_CAP_TILING_4;
> > > +
> > > + if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> > > + caps |= INTEL_PLANE_CAP_CCS_RC;
> > > + if (DISPLAY_VER(i915) >= 12)
> > > + caps |= INTEL_PLANE_CAP_CCS_RC_CC;
> > > + }
> > > +
> > > + if (gen12_plane_has_mc_ccs(i915, plane_id))
> > > + caps |= 

Re: [PATCH] drm/xe/display: Disable aux ccs framebuffers

[Souza, Jose]

On Tue, 2024-01-02 at 20:24 +0200, Juha-Pekka Heikkila wrote:
> Aux ccs framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. Flat ccs framebuffers
> work and they are left enabled. Here is separated plane capabilities
> check on i915 so it can behave differencly depending on the driver.
> 

Reviewed-by: José Roberto de Souza 

> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933
> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/Makefile |  1 +
>  .../gpu/drm/i915/display/intel_plane_caps.c   | 68 +++
>  .../gpu/drm/i915/display/intel_plane_caps.h   | 14 
>  .../drm/i915/display/skl_universal_plane.c| 61 +
>  drivers/gpu/drm/xe/display/xe_plane_initial.c | 23 +++
>  5 files changed, 107 insertions(+), 60 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_plane_caps.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_plane_caps.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index e777686190ca..c5e3c2dd0a01 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -302,6 +302,7 @@ i915-y += \
>   display/intel_overlay.o \
>   display/intel_pch_display.o \
>   display/intel_pch_refclk.o \
> + display/intel_plane_caps.o \
>   display/intel_plane_initial.o \
>   display/intel_pmdemand.o \
>   display/intel_psr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_caps.c 
> b/drivers/gpu/drm/i915/display/intel_plane_caps.c
> new file mode 100644
> index ..6206ae11f296
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_plane_caps.c
> @@ -0,0 +1,68 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_fb.h"
> +#include "intel_plane_caps.h"
> +
> +static bool skl_plane_has_rc_ccs(struct drm_i915_private *i915,
> +  enum pipe pipe, enum plane_id plane_id)
> +{
> + /* Wa_22011186057 */
> + if (IS_ALDERLAKE_P(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> + return false;
> +
> + if (DISPLAY_VER(i915) >= 11)
> + return true;
> +
> + if (IS_GEMINILAKE(i915))
> + return pipe != PIPE_C;
> +
> + return pipe != PIPE_C &&
> + (plane_id == PLANE_PRIMARY ||
> +  plane_id == PLANE_SPRITE0);
> +}
> +
> +static bool gen12_plane_has_mc_ccs(struct drm_i915_private *i915,
> +enum plane_id plane_id)
> +{
> + if (DISPLAY_VER(i915) < 12)
> + return false;
> +
> + /* Wa_14010477008 */
> + if (IS_DG1(i915) || IS_ROCKETLAKE(i915) ||
> + (IS_TIGERLAKE(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_D0)))
> + return false;
> +
> + /* Wa_22011186057 */
> + if (IS_ALDERLAKE_P(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> + return false;
> +
> + return plane_id < PLANE_SPRITE4;
> +}
> +
> +u8 skl_get_plane_caps(struct drm_i915_private *i915,
> +   enum pipe pipe, enum plane_id plane_id)
> +{
> + u8 caps = INTEL_PLANE_CAP_TILING_X;
> +
> + if (DISPLAY_VER(i915) < 13 || IS_ALDERLAKE_P(i915))
> + caps |= INTEL_PLANE_CAP_TILING_Y;
> + if (DISPLAY_VER(i915) < 12)
> + caps |= INTEL_PLANE_CAP_TILING_Yf;
> + if (HAS_4TILE(i915))
> + caps |= INTEL_PLANE_CAP_TILING_4;
> +
> + if (skl_plane_has_rc_ccs(i915, pipe, plane_id)) {
> + caps |= INTEL_PLANE_CAP_CCS_RC;
> + if (DISPLAY_VER(i915) >= 12)
> + caps |= INTEL_PLANE_CAP_CCS_RC_CC;
> + }
> +
> + if (gen12_plane_has_mc_ccs(i915, plane_id))
> + caps |= INTEL_PLANE_CAP_CCS_MC;
> +
> + return caps;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_caps.h 
> b/drivers/gpu/drm/i915/display/intel_plane_caps.h
> new file mode 100644
> index ..60a941c76f23
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_plane_caps.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#ifndef __INTEL_PLANE_CAPS_H__
> +#define __INTEL_PLANE_CAPS_H__
> +
> +#include "intel_display_types.h"
> +
> +u8 skl_get_plane_caps(struct drm_i915_private *i915,
> +   enum pipe pipe, enum plane_id plane_id);
> +
> +#endif /* __INTEL_PLANE_CAPS_H__ */
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 511dc1544854..f2fd3833c61d 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -17,6 +17,7 @@
>  #include "intel_fb.h"
>  #include "intel_fbc.h"
>  #include "intel_frontbuffer.h"
> +#include "intel_plane_caps.h"
>  #include "intel_psr.h"
>  #include 

Re: [PATCH] drm/i915: Disable DSB in Xe KMD

[Souza, Jose]

On Wed, 2024-01-03 at 17:37 +0200, Jani Nikula wrote:
> On Wed, 03 Jan 2024, José Roberto de Souza  wrote:
> > Often getting DBS overflows when starting Xorg or Wayland compositor
> > when running Xe KMD.
> > Issue was reported but nothing was done, so disabling DSB as whole
> > until properly fixed.
> 
> Please just incorporate this into the HAS_DSB() check, and don't litter
> the source with ifdefs.

Like this is enough?

+/* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
+#ifdef I915
 #define HAS_DSB(i915)  (DISPLAY_INFO(i915)->has_dsb)
+#else
+#define HAS_DSB(i915)  (false)
+#endif


> 
> Thanks,
> Jani.
> 
> > 
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072
> > Cc: Animesh Manna 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dsb.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > index 482c28b5c2de5..bc11c447afe03 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -321,6 +321,7 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> > intel_dsb_buffer_flush_map(>dsb_buf);
> >  }
> >  
> > +#ifdef I915
> >  static int intel_dsb_dewake_scanline(const struct intel_crtc_state 
> > *crtc_state)
> >  {
> > struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > @@ -339,6 +340,7 @@ static int intel_dsb_dewake_scanline(const struct 
> > intel_crtc_state *crtc_state)
> >  
> > return max(0, vblank_start - intel_usecs_to_scanlines(adjusted_mode, 
> > latency));
> >  }
> > +#endif
> >  
> >  static void _intel_dsb_commit(struct intel_dsb *dsb, u32 ctrl,
> >   int dewake_scanline)
> > @@ -444,6 +446,8 @@ void intel_dsb_wait(struct intel_dsb *dsb)
> >  struct intel_dsb *intel_dsb_prepare(const struct intel_crtc_state 
> > *crtc_state,
> > unsigned int max_cmds)
> >  {
> > +   /* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
> > +#ifdef I915
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > intel_wakeref_t wakeref;
> > @@ -484,6 +488,7 @@ struct intel_dsb *intel_dsb_prepare(const struct 
> > intel_crtc_state *crtc_state,
> >   "[CRTC:%d:%s] DSB %d queue setup failed, will fallback to 
> > MMIO for display HW programming\n",
> >   crtc->base.base.id, crtc->base.name, DSB1);
> >  
> > +#endif
> > return NULL;
> >  }
> 

Re: [Intel-gfx] [PATCH] drm/xe/uapi: Fix various struct padding for 64b alignment

[Souza, Jose]

On Fri, 2023-11-17 at 15:48 -0500, Rodrigo Vivi wrote:
> Let's respect Documentation/process/botching-up-ioctls.rst
> and add the proper padding for a 64b alignment with all as
> well as all the required checks and settings for the pads
> and the reserved entries.
> 
> v2: Fix remaining wholes and double check with pahole (Jose)
> Ensure with pahole that both 32b and 64b have exact same
> layout (Thomas)
> Do not set query's pad and reserved bits to zero since it
> is redundant and already done by kzalloc (Matt)


Reviewed-by: José Roberto de Souza 

But this has changes that were done in 
https://patchwork.freedesktop.org/series/126535/ so it will not apply on top of 
current drm-xe-next.

> 
> Cc: Thomas Hellström 
> Cc: Francois Dugast 
> Cc: José Roberto de Souza 
> Cc: Matt Roper 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/xe/xe_query.c |  1 +
>  drivers/gpu/drm/xe/xe_vm.c|  8 
>  include/uapi/drm/xe_drm.h | 19 +++
>  3 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> index 838f03795841..c5f2b3d67166 100644
> --- a/drivers/gpu/drm/xe/xe_query.c
> +++ b/drivers/gpu/drm/xe/xe_query.c
> @@ -377,6 +377,7 @@ static int query_gt_list(struct xe_device *xe, struct 
> drm_xe_device_query *query
>   return -ENOMEM;
>  
>   gt_list->num_gt = xe->info.gt_count;
> +
>   for_each_gt(gt, xe, id) {
>   if (xe_gt_is_media_type(gt))
>   gt_list->gt_list[id].type = DRM_XE_QUERY_GT_TYPE_MEDIA;
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index f8559ebad9bc..2f22f1feaf1c 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -2850,6 +2850,10 @@ static int vm_bind_ioctl_check_args(struct xe_device 
> *xe,
>   int err;
>   int i;
>  
> + if (XE_IOCTL_DBG(xe, args->pad || args->pad2) ||
> + XE_IOCTL_DBG(xe, args->reserved[0] || args->reserved[1]))
> + return -EINVAL;
> +
>   if (XE_IOCTL_DBG(xe, args->extensions) ||
>   XE_IOCTL_DBG(xe, !args->num_binds) ||
>   XE_IOCTL_DBG(xe, args->num_binds > MAX_BINDS))
> @@ -2966,6 +2970,10 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *file)
>   if (err)
>   return err;
>  
> + if (XE_IOCTL_DBG(xe, args->pad || args->pad2) ||
> + XE_IOCTL_DBG(xe, args->reserved[0] || args->reserved[1]))
> + return -EINVAL;
> +
>   if (args->exec_queue_id) {
>   q = xe_exec_queue_lookup(xef, args->exec_queue_id);
>   if (XE_IOCTL_DBG(xe, !q)) {
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 8610ac461619..c07cd4b61baa 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -211,8 +211,6 @@ struct drm_xe_mem_region {
>* a unique pair.
>*/
>   __u16 instance;
> - /** @pad: MBZ */
> - __u32 pad;
>   /**
>* @min_page_size: Min page-size in bytes for this region.
>*
> @@ -384,6 +382,8 @@ struct drm_xe_gt {
>   __u16 tile_id;
>   /** @gt_id: Unique ID of this GT within the PCI Device */
>   __u16 gt_id;
> + /** @pad: MBZ */
> + __u16 pad[3];
>   /** @clock_freq: A clock frequency for timestamp */
>   __u32 clock_freq;
>   /**
> @@ -723,6 +723,9 @@ struct drm_xe_vm_bind_op {
>*/
>   __u32 prefetch_mem_region_instance;
>  
> + /** @pad: MBZ */
> + __u32 pad2;
> +
>   /** @reserved: Reserved */
>   __u64 reserved[2];
>  };
> @@ -741,12 +744,12 @@ struct drm_xe_vm_bind {
>*/
>   __u32 exec_queue_id;
>  
> - /** @num_binds: number of binds in this IOCTL */
> - __u32 num_binds;
> -
>   /** @pad: MBZ */
>   __u32 pad;
>  
> + /** @num_binds: number of binds in this IOCTL */
> + __u32 num_binds;
> +
>   union {
>   /** @bind: used if num_binds == 1 */
>   struct drm_xe_vm_bind_op bind;
> @@ -758,12 +761,12 @@ struct drm_xe_vm_bind {
>   __u64 vector_of_binds;
>   };
>  
> + /** @pad: MBZ */
> + __u32 pad2;
> +
>   /** @num_syncs: amount of syncs to wait on */
>   __u32 num_syncs;
>  
> - /** @pad2: MBZ */
> - __u32 pad2;
> -
>   /** @syncs: pointer to struct drm_xe_sync array */
>   __u64 syncs;
>  

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Swap ggtt_vma during legacy cursor update

[Souza, Jose]

On Wed, 2023-06-21 at 13:48 +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 4962247911d41..6f34098ea314d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -688,9 +688,8 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>   if (ret)
>   goto out_free;
>  
> - ret = intel_plane_pin_fb(new_plane_state);
> - if (ret)
> - goto out_free;
> + /* magic trick! */
> + swap(new_plane_state->ggtt_vma, old_plane_state->ggtt_vma);
>  
>   intel_frontbuffer_flush(to_intel_frontbuffer(new_plane_state->hw.fb),
>   ORIGIN_CURSOR_UPDATE);

Getting a opps with this. This is missing the unbind 
block(https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/282#note_1947355):

[  219.866996] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
[CONNECTOR:276:DP-4]
[  219.867005] xe :03:00.0: [drm:intel_dp_detect [xe]] [CONNECTOR:276:DP-4]
[  219.867053] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
[CONNECTOR:276:DP-4] disconnected
[  219.867073] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
[CONNECTOR:284:HDMI-A-3]
[  219.867082] xe :03:00.0: [drm:intel_hdmi_detect [xe]] 
[CONNECTOR:284:HDMI-A-3]
[  219.867127] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
[CONNECTOR:284:HDMI-A-3] disconnected
[  222.635935] BUG: kernel NULL pointer dereference, address: 
[  222.642930] #PF: supervisor read access in kernel mode
[  222.648081] #PF: error_code(0x) - not-present page
[  222.653229] PGD 0 P4D 0
[  222.655778] Oops:  [#1] PREEMPT SMP NOPTI
[  222.660147] CPU: 0 PID: 3049 Comm: InputThread Not tainted 6.3.0+zeh-xe+ 
#1023
[  222.667378] Hardware name: Intel Corporation Alder Lake Client 
Platform/AlderLake-S ADP-S DDR4 UDIMM CRB, BIOS ADLSFWI1.R00.3385.A00.2209161457
09/16/2022
[  222.681196] RIP: 0010:__xe_unpin_fb_vma+0x4/0x190 [xe]
[  222.686404] Code: 00 00 e9 65 ff ff ff e8 ea 56 9e e1 66 2e 0f 1f 84 00 00 
00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 41 54 55 53
<48> 8b 07 48 89 fb 48 8b 6b 08 48 8b 50 08 48 8b ba e8 22 00 00 48
[  222.705163] RSP: 0018:c9000350fb50 EFLAGS: 00010206
[  222.710398] RAX:  RBX: 88821f3a4c00 RCX: 0040
[  222.717544] RDX:  RSI: 8253a99b RDI: 
[  222.724691] RBP: 888142dda800 R08: 0001 R09: 0001
[  222.731833] R10: 0007 R11: 0003 R12: 88811b5fa000
[  222.738979] R13:  R14: 0100 R15: 88821f3a4c00
[  222.746125] FS:  7fd3e4a4f640() GS:88849e60() 
knlGS:
[  222.754221] CS:  0010 DS:  ES:  CR0: 80050033
[  222.759979] CR2:  CR3: 00011c36 CR4: 00770ef0
[  222.767125] PKRU: 5554
[  222.769847] Call Trace:
[  222.772311]  
[  222.774426]  intel_plane_unpin_fb+0x10/0x30 [xe]
[  222.779105]  intel_legacy_cursor_update+0x2fc/0x3d0 [xe]
[  222.784481]  drm_mode_cursor_universal+0x126/0x240
[  222.789286]  drm_mode_cursor_common+0xfc/0x230
[  222.793746]  ? __pfx_drm_mode_cursor_ioctl+0x10/0x10
[  222.798723]  drm_mode_cursor_ioctl+0x46/0x70
[  222.803010]  drm_ioctl_kernel+0xc0/0x170
[  222.806947]  drm_ioctl+0x212/0x470
[  222.810366]  ? __pfx_drm_mode_cursor_ioctl+0x10/0x10
[  222.815341]  __x64_sys_ioctl+0x8a/0xb0
[  222.819104]  do_syscall_64+0x38/0x90
[  222.822700]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
[  222.827769] RIP: 0033:0x7fd3f831aaff
[  222.831364] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 
00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05
<41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
[  222.850121] RSP: 002b:7fd3e4a4d1e0 EFLAGS: 0246 ORIG_RAX: 
0010
[  222.857701] RAX: ffda RBX: 7fd3e4a4d270 RCX: 7fd3f831aaff
[  222.864847] RDX: 7fd3e4a4d270 RSI: c01c64a3 RDI: 000e
[  222.871991] RBP: c01c64a3 R08: 0710 R09: 0001
[  222.879137] R10: 0004 R11: 0246 R12: 5639c66aef90
[  222.886283] R13: 000e R14: 0150 R15: 0150
[  222.893430]  
[  222.895635] Modules linked in: snd_hda_codec_hdmi xe drm_ttm_helper 
gpu_sched drm_suballoc_helper i2c_algo_bit drm_buddy ttm drm_display_helper
drm_kms_helper syscopyarea sysfillrect sysimgblt mei_hdcp mei_pxp pmt_telemetry 
pmt_class snd_hda_codec_realtek x86_pkg_temp_thermal
snd_hda_codec_generic ledtrig_audio coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel kvm_intel snd_hda_intel 

Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Souza, Jose]

On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > Because of the additional firmware, component-driver and
> > > > initialization depedencies required on MTL platform before a
> > > > PXP context can be created, UMD calling for PXP creation as a
> > > > way to get-caps can take a long time. An actual real world
> > > > customer stack has seen this happen in the 4-to-8 second range
> > > > after the kernel starts (which sees MESA's init appear in the
> > > > middle of this range as the compositor comes up). To avoid
> > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > > 
> > > alan:snip.
> > > Progress update on the UMD side - I'm working on patch for PR here: 
> > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > but taking time to verify certain code paths
> > 
> > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > soon"), then it is basically certain that in a production environment,
> > then it will eventually return 1 meaning it's ready, right?
> alan: yes - but not 100%. non-platform-state-machine could still
> cause unexpected failures for example, [1] if hw was fused in a way
> that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> doesnt allow PXP. However at the moment, there is no way for us
> to know for sure without actually creating a protected context.
> Of course having hw-fusing + bios-config that supports PXP have
> always 100% succeeded for me.

In my opinion it is problematic mark that we support protected context but then 
it fails to create protected context.

It should check the I915_PARAM_PXP_STATUS in 
i915_gem_supports_protected_context() return earlier if know that protected 
context is not supported.
Then create a protected context so we know that all other calls will succeed.

> 
> > 
> > If this is correct, then I think that the change in
> > i915_gem_supports_protected_context() is good, and probably we can
> > skip the change in iris_create_hw_context().
> > 
> > Basically, we're timing out for multiple seconds either way. And, I'm
> > hoping that the kernel will eventually get the PXP init done and
> > create the context.
> > 
> > I think there's 2 cases of interest here.
> > 
> > First, and most likely, the application running doesn't care about
> > protected content. In this case we can quickly advertise the support,
> > but there will be no consequence because the application won't use the
> > feature.
> alan: yes - that was one of the goals of this UAPI.
> > 
> > Second, the application does care about protected content. In this
> > case we can quickly advertise the support, but if the feature is used
> > too quickly, then the context create might take a long time.
> alan: no, that isnt the case now, we started at 8-secs, then 2-secs,
> and finally settled on the same timeout as ADL since this new UAPI
> will be something that can be polled on to be sure we have readiness
> to make the create-context-call. That's why i wanted to add the
> polling wait in the actual create call - but not the get caps call
> which can be quick (as you said above).
> 
> > 
> > If I915_PARAM_PXP_STATUS returning 2 has a reasonable chance in a
> > production environment of eventually finding out that pxp can't work,
> > then perhaps more disussion is needed. I guess the worst case scenario
> > is no worse than today though. (Except it is still somewhat better,
> > because the common case would not involve protected content being
> > used by the application.)
> alan: hmmm... i guess it depends on the meaning of resonable: if 50%
> of the CI platforms being run have incorrect bios config / hw fusing
> does it mean this UAPI is only 50% useful? My opinion is the alternative:
> in the case of platform that has correctly configured BIOS + fusing,
> is the chance of 2 eventually leading to a failure high? The answer is no.
> Hypothetically i have actually never seen this happen (note: this UAPI
> is new but i know from past debug of customer issues). There are some very
> corner-cases but those get into the weeds of pxp runtime state machine..
> I am sure we don't wanna discuss that rabbit hole right now.
> > 
> > Another option besides from the timeout loop in
> > iris_create_hw_context() might be to check I915_PARAM_PXP_STATUS after
> > the context create fails to tweak the debug message.
> alan: Yeah, that is an option - I'm thinking we can add a DBG that reads
> either"PXP context failure expected due not ready" vs
> "Unexpected PXP context failure" 
> 
> > 
> > -Jordan
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Initialize dkl_phy spin lock from display code path (rev4)

[Souza, Jose]

On Fri, 2023-04-21 at 02:02 +, Patchwork wrote:
Patch Details
Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev4)
URL:https://patchwork.freedesktop.org/series/116325/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/index.html
CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116325v4_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_116325v4_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_116325v4_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (7 -> 7)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_ppgtt@blt-vs-render-ctxn:
 *   shard-snb: 
PASS
 -> 
DMESG-FAIL

Not related.
SNB don't even have DKL phy.

Patch pushed, thanks for all the comments and reviews.

Suppressed

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

  *   igt@kms_flip@2x-flip-vs-fences-interruptible:
 *   {shard-dg1}: NOTRUN -> 
SKIP

Known issues

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

IGT changes
Issues hit

  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-glk: 
PASS
 -> 
FAIL
 (i915#2842)
  *   igt@kms_color@ctm-0-25@pipe-b-vga-1:

 *   shard-snb: NOTRUN -> 
SKIP
 (fdo#109271) +6 similar 
issues

Possible fixes

  *   igt@gem_barrier_race@remote-request@rcs0:

 *   {shard-rkl}: 
ABORT
 (i915#8211) -> 
PASS
  *   igt@gem_exec_endless@dispatch@rcs0:

 *   {shard-tglu}: 
TIMEOUT
 (i915#3778) -> 
PASS
  *   igt@gem_exec_fair@basic-deadline:

 *   shard-apl: 
FAIL
 (i915#2846) -> 
PASS
  *   igt@gem_exec_fair@basic-none@vcs0:

 *   {shard-rkl}: 
FAIL
 (i915#2842) -> 
PASS
 +2 similar issues
  *   igt@i915_pm_rpm@dpms-lpsp:

 *   {shard-rkl}: 
SKIP
 (i915#1397) -> 
PASS
 +1 similar issue
  *   igt@i915_pm_rpm@modeset-non-lpsp:

 *   {shard-dg1}: 
SKIP
 (i915#1397) -> 
PASS
  *   igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:

 *   shard-apl: 
FAIL
 (i915#2346) -> 

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Thu, 2023-04-20 at 09:35 -0700, Lucas De Marchi wrote:
> On Thu, Apr 20, 2023 at 08:36:37AM -0700, Jose Souza wrote:
> > On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> > > On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > > > On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > > > > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > > > > On Tue, 18 Apr 2023, Lucas De Marchi  
> > > > > > wrote:
> > > > > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > > > > Start to move the initialization of display locks from
> > > > > > > > > i915_driver_early_probe(), this way it is also executed when 
> > > > > > > > > running
> > > > > > > > > Xe kmd.
> > > > > > > > > 
> > > > > > > > > This will fix a warning in Xe kmd:
> > > > > > > > > 
> > > > > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY 
> > > > > > > > > A] failed to retrieve link info, disabling eDP
> > > > > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
> > > > > > > > > source OUI
> > > > > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > > > > [  202.175347] irq event stamp: 754060
> > > > > > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > > > > > [  202.180294] The code is fine but needs lockdep annotation, 
> > > > > > > > > or maybe
> > > > > > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > > > > > [] do_idle+0x99/0x230
> > > > > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: G 
> > > > > > > > >W  6.3.0-rc4+zeh-xe+ #909
> > > > > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake 
> > > > > > > > > Client Platform/RaptorLake-P LP5 RVP, BIOS 
> > > > > > > > > RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > > > > [  202.255737] Call Trace:
> > > > > > > > > [  202.258179]  
> > > > > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > > > > [  202.306202]  ? 
> > > > > > > > > intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
> > > > > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > > > > [  202.317543]  
> > > > > > > > > __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
> > > > > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > &

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > > Start to move the initialization of display locks from
> > > > > > > i915_driver_early_probe(), this way it is also executed when 
> > > > > > > running
> > > > > > > Xe kmd.
> > > > > > > 
> > > > > > > This will fix a warning in Xe kmd:
> > > > > > > 
> > > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
> > > > > > > failed to retrieve link info, disabling eDP
> > > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
> > > > > > > source OUI
> > > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > > [  202.175347] irq event stamp: 754060
> > > > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > > > [  202.180294] The code is fine but needs lockdep annotation, or 
> > > > > > > maybe
> > > > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > > > [] do_idle+0x99/0x230
> > > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: G
> > > > > > > W  6.3.0-rc4+zeh-xe+ #909
> > > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake 
> > > > > > > Client Platform/RaptorLake-P LP5 RVP, BIOS 
> > > > > > > RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > > [  202.255737] Call Trace:
> > > > > > > [  202.258179]  
> > > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > > [  202.306202]  ? 
> > > > > > > intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
> > > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 
> > > > > > > [xe]
> > > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > > > [  202.363809]  ? __pfx

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > Start to move the initialization of display locks from
> > > > > i915_driver_early_probe(), this way it is also executed when running
> > > > > Xe kmd.
> > > > > 
> > > > > This will fix a warning in Xe kmd:
> > > > > 
> > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
> > > > > failed to retrieve link info, disabling eDP
> > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source 
> > > > > OUI
> > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > [  202.175347] irq event stamp: 754060
> > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > [  202.180294] The code is fine but needs lockdep annotation, or maybe
> > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > [] do_idle+0x99/0x230
> > > > > [  202.192734] you didn't initialize this object before use?
> > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > [  202.206882] turning off the locking correctness validator.
> > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW
> > > > >   6.3.0-rc4+zeh-xe+ #909
> > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
> > > > > Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 
> > > > > 11/15/2022
> > > > > [  202.255737] Call Trace:
> > > > > [  202.258179]  
> > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > [  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 
> > > > > [xe]
> > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
> > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > > > > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > > > > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e 
> > > > > fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 
> > > > > 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 
> > > > > 89 01 48
> > > > > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 
> > > > > 0139
> > > > > [  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 
> > > > > 7fd11291ea3d
> > > > > [  202.461106] RDX:  RSI: 5616a617fe60 RDI: 
> > > > > 000e
> > > > > [  202.468182] RBP: 0004 R08:  R09: 
> > > > > 0002
> > > > > [  202.475250] R10: 000e R11: 0246 R12: 
> > > > > 5616a617fe60
> > > > > [  202.482319] R13: 5616a617f340 R14:  R15: 
> 

Re: [Intel-gfx] [Intel-xe] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Tue, 2023-04-11 at 14:20 -0700, Lucas De Marchi wrote:
> On Tue, Apr 11, 2023 at 08:07:12PM +, Jose Souza wrote:
> > On Tue, 2023-04-11 at 12:59 -0700, Lucas De Marchi wrote:
> > > On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote:
> > > > On Tue, Apr 11, 2023 at 12:14:36PM +0300, Jani Nikula wrote:
> > > > > On Tue, 11 Apr 2023, Ville Syrjälä  
> > > > > wrote:
> > > > > > On Tue, Apr 11, 2023 at 11:51:33AM +0300, Jani Nikula wrote:
> > > > > > > On Tue, 11 Apr 2023, Ville Syrjälä 
> > > > > > >  wrote:
> > > > > > > > On Mon, Apr 10, 2023 at 11:32:14AM -0700, José Roberto de Souza 
> > > > > > > > wrote:
> > > > > > > > > Start to move the initialization of some lock from
> > > > > > > > > i915_driver_early_probe().
> > > > > > > > > No dkl function is called prior to intel_setup_outputs(), so 
> > > > > > > > > this is
> > > > > > > > > a good place to initialize it.
> > > > > > > > 
> > > > > > > > I disagree. We don't want to sprinke these all over the place.
> > > > > > > 
> > > > > > > I'm thinking if only foo.c uses a lock, foo.c should initialize 
> > > > > > > it, not
> > > > > > > someone else.
> > > > > > 
> > > > > > Perhaps. But I think there should be some consistent place in the 
> > > > > > higher
> > > > > > level code where all such things get called instead of dropping 
> > > > > > each one
> > > > > > individually into some random spot in the overlall display init 
> > > > > > flow.
> > > > > 
> > > > > Agreed.
> > > > 
> > > > Ops, I just saw this now, right after I cc'ed you in the other thread.
> > > > 
> > > > So, probably good to hold this and do the entire refactor together of 
> > > > all
> > > > those locks initialization so we find this common consistent place 
> > > > apparently...
> > > 
> > > "internal" sw initialization of display-related stuff. It doesn't belong 
> > > in
> > > i915_driver_early_probe(), it makes harder to follow the sequence if we 
> > > sprinkle
> > > them around, like here in intel_setup_outputs.
> > > 
> > > But I don't see why this couldn't be done in a higher level "sw
> > > initialization of display-related stuff".  Should we add an equivalent
> > > of i915_driver_early_probe(), e.g.  intel_display_early_probe()[1],  and
> > > move the display-related things from i915_driver_early_probe()?
> > > 
> > > In that case, from xe we would call this function rather than
> > > initializing these fields in xe_display_create()
> > 
> > Sent another version, added intel_display_locks_init() that is called in 
> > the beginning of intel_modeset_init_noirq().
> > https://patchwork.freedesktop.org/series/116326/
> 
> modeset? why? That is after we are already probing the hw

That called during probe, called from i915_driver_probe().

> and what does that have to do with modeset?

The name is misleading but intel_modeset_init_noirq() is the first generic 
display initialization function called.
There is other display functions called before it but they are very 
specific(intel_dram_detect(), intel_bw_init_hw() and
intel_device_info_runtime_init()).

> 
> Lucas De Marchi
> 
> > 
> > If this is accepted we can then move the other display locks from 
> > i915_driver_early_probe().
> > 
> > > 
> > > Lucas De Marchi
> > > 
> > > [1] I don't like the name, but it follows what is already there
> > > 
> > > > 
> > > > > 
> > > > > --
> > > > > Jani Nikula, Intel Open Source Graphics Center
> > 

Re: [Intel-gfx] [Intel-xe] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Tue, 2023-04-11 at 12:59 -0700, Lucas De Marchi wrote:
> On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote:
> > On Tue, Apr 11, 2023 at 12:14:36PM +0300, Jani Nikula wrote:
> > > On Tue, 11 Apr 2023, Ville Syrjälä  wrote:
> > > > On Tue, Apr 11, 2023 at 11:51:33AM +0300, Jani Nikula wrote:
> > > > > On Tue, 11 Apr 2023, Ville Syrjälä  
> > > > > wrote:
> > > > > > On Mon, Apr 10, 2023 at 11:32:14AM -0700, José Roberto de Souza 
> > > > > > wrote:
> > > > > > > Start to move the initialization of some lock from
> > > > > > > i915_driver_early_probe().
> > > > > > > No dkl function is called prior to intel_setup_outputs(), so this 
> > > > > > > is
> > > > > > > a good place to initialize it.
> > > > > > 
> > > > > > I disagree. We don't want to sprinke these all over the place.
> > > > > 
> > > > > I'm thinking if only foo.c uses a lock, foo.c should initialize it, 
> > > > > not
> > > > > someone else.
> > > > 
> > > > Perhaps. But I think there should be some consistent place in the higher
> > > > level code where all such things get called instead of dropping each one
> > > > individually into some random spot in the overlall display init flow.
> > > 
> > > Agreed.
> > 
> > Ops, I just saw this now, right after I cc'ed you in the other thread.
> > 
> > So, probably good to hold this and do the entire refactor together of all
> > those locks initialization so we find this common consistent place 
> > apparently...
> 
> "internal" sw initialization of display-related stuff. It doesn't belong in
> i915_driver_early_probe(), it makes harder to follow the sequence if we 
> sprinkle
> them around, like here in intel_setup_outputs.
> 
> But I don't see why this couldn't be done in a higher level "sw
> initialization of display-related stuff".  Should we add an equivalent
> of i915_driver_early_probe(), e.g.  intel_display_early_probe()[1],  and
> move the display-related things from i915_driver_early_probe()?
> 
> In that case, from xe we would call this function rather than
> initializing these fields in xe_display_create()

Sent another version, added intel_display_locks_init() that is called in the 
beginning of intel_modeset_init_noirq().
https://patchwork.freedesktop.org/series/116326/

If this is accepted we can then move the other display locks from 
i915_driver_early_probe().

> 
> Lucas De Marchi
> 
> [1] I don't like the name, but it follows what is already there
> 
> > 
> > > 
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [Intel-xe] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Tue, 2023-04-11 at 11:33 +0300, Jani Nikula wrote:
> On Tue, 11 Apr 2023, Jani Nikula  wrote:
> > On Mon, 10 Apr 2023, José Roberto de Souza  wrote:
> > > Start to move the initialization of some lock from
> > > i915_driver_early_probe().
> > 
> > Please send this as standalone patch to i915. It won't get merged to
> > i915 as part of series only parts of which apply to i915.
> 
> Not to mention drm-xe-next is *not* the path to upstream i915
> changes. Each i915 merged there is a potential problem in upstreaming
> xe.

Already sent it https://patchwork.freedesktop.org/series/116272/

> 
> BR,
> Jani.
> 
> 

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 3/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

[Souza, Jose]

On Mon, 2023-04-10 at 11:37 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:30AM -0700, José Roberto de Souza wrote:
> > This spin lock will not be used in older display versions, so no need
> > to initialize it.
> 
> Should we add some warn_on(disp_ver < 12) on the dkl phy functions?

If called in platforms with display version older than 12 we will get warnings 
about spink lock functions being called in a non initialized spinlock_t
anyways.

> 
> Anyway:
> 
> Reviewed-by: Rodrigo Vivi 
> 
> 
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dkl_phy.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.c 
> > b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
> > index 5bce7b5b27bc7..1c5d410b74e5d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dkl_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
> > @@ -108,5 +108,6 @@ intel_dkl_phy_posting_read(struct drm_i915_private 
> > *i915, struct intel_dkl_phy_r
> >  void
> >  intel_dkl_phy_init(struct drm_i915_private *i915)
> >  {
> > -   spin_lock_init(>display.dkl.phy_lock);
> > +   if (DISPLAY_VER(i915) >= 12)
> > +   spin_lock_init(>display.dkl.phy_lock);
> >  }
> > -- 
> > 2.40.0
> > 

Re: [Intel-gfx] [PATCH v2 rebased 2/6] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Mon, 2023-04-10 at 11:33 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:29AM -0700, José Roberto de Souza wrote:
> > Start to move the initialization of some lock from
> > i915_driver_early_probe().
> > This will also fix a warning in Xe kmd:
> > 
> > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to 
> > retrieve link info, disabling eDP
> > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source OUI
> > [  202.175346] INFO: trying to register non-static key.
> > [  202.175347] irq event stamp: 754060
> > [  202.175359] hardirqs last  enabled at (754059): [] 
> > tick_nohz_idle_enter+0x59/0x80
> > [  202.180294] The code is fine but needs lockdep annotation, or maybe
> > [  202.183774] hardirqs last disabled at (754060): [] 
> > do_idle+0x99/0x230
> > [  202.192734] you didn't initialize this object before use?
> > [  202.198951] softirqs last  enabled at (753948): [] 
> > irq_exit_rcu+0xbe/0x130
> > [  202.206882] turning off the locking correctness validator.
> > [  202.212236] softirqs last disabled at (753943): [] 
> > irq_exit_rcu+0xbe/0x130
> > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW  
> > 6.3.0-rc4+zeh-xe+ #909
> > [  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
> > Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 
> > 11/15/2022
> > [  202.255737] Call Trace:
> > [  202.258179]  
> > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > [  202.263922]  register_lock_class+0x756/0x7d0
> > [  202.268165]  ? find_held_lock+0x2b/0x80
> > [  202.271975]  __lock_acquire+0x72/0x28b0
> > [  202.275786]  ? debug_object_free+0xb4/0x160
> > [  202.279946]  lock_acquire+0xd1/0x2d0
> > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > [  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
> > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
> > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > [  202.356260]  pci_device_probe+0x9d/0x150
> > [  202.360164]  really_probe+0x19a/0x400
> > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > [  202.368226]  __driver_probe_device+0x73/0x170
> > [  202.372558]  driver_probe_device+0x1a/0x90
> > [  202.376632]  __driver_attach+0xcd/0x1c0
> > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > [  202.384253]  bus_add_driver+0x110/0x210
> > [  202.388063]  driver_register+0x50/0x100
> > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > [  202.396431]  do_one_initcall+0x55/0x260
> > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > [  202.407786]  do_init_module+0x45/0x1e0
> > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > [  202.415838]  do_syscall_64+0x37/0x90
> > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 
> > 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 
> > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48
> > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 
> > 0139
> > [  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 
> > 7fd11291ea3d
> > [  202.461106] RDX:  RSI: 5616a617fe60 RDI: 
> > 000e
> > [  202.468182] RBP: 0004 R08:  R09: 
> > 0002
> > [  202.475250] R10: 000e R11: 0246 R12: 
> > 5616a617fe60
> > [  202.482319] R13: 5616a617f340 R14:  R15: 
> > 5616a6180650
> > [  202.489396]  
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 3 +++
> >  drivers/gpu/drm/i915/display/intel_dkl_phy.c | 6 ++
> >  drivers/gpu/drm/i915/display/intel_dkl_phy.h | 2 ++
> >  drivers/gpu/drm/i915/i915_driver.c   | 1 -
> >  4 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 2d59330ff5abd..92e1b535b2798 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -85,6 +85,7 @@
> >  #include 

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 1/6] drm/i915: Nuke unused dsparb_lock

[Souza, Jose]

On Thu, 2023-04-06 at 16:38 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:28AM -0700, José Roberto de Souza wrote:
> > dsparb_lock it not used anymore, nuke it.
> 
> Well, this doesn't exist in our drm-tip baseline, so it would be good
> if this patch is a fixup! to whatever patch is adding this back here.
> 
> Take a look to the Jani series I just pushed:
> 
> https://lists.freedesktop.org/archives/intel-xe/2023-April/002000.html
> 
> I believe you should make this series on something more like that.
> so on a next step I run a rebase --autosquash and we get cleaner patches.
> 
> Also, I believe this series here might conflict with that, so I'm
> afraid you will have to rebase it anyway. Sorry about that...

Will skip this patch then, it will probably be gone in next rebase.

Can you please take a look at the other 5 patches before I send a new version?

> 
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_core.h | 3 ---
> >  drivers/gpu/drm/i915/i915_driver.c| 1 -
> >  2 files changed, 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
> > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > index cc058eb303ee8..d2346d43d1162 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > @@ -266,9 +266,6 @@ struct intel_wm {
> >  */
> > struct mutex wm_mutex;
> >  
> > -   /* protects DSPARB registers on pre-g4x/vlv/chv */
> > -   spinlock_t dsparb_lock;
> > -
> > bool ipc_enabled;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 066d79c2069c4..ea2cc56d18a6e 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -214,7 +214,6 @@ static int i915_driver_early_probe(struct 
> > drm_i915_private *dev_priv)
> > spin_lock_init(_priv->irq_lock);
> > spin_lock_init(_priv->gpu_error.lock);
> > spin_lock_init(_priv->display.fb_tracking.lock);
> > -   spin_lock_init(_priv->display.wm.dsparb_lock);
> > mutex_init(_priv->display.backlight.lock);
> >  
> > mutex_init(_priv->sb_lock);
> > -- 
> > 2.40.0
> > 

Re: [Intel-gfx] [Intel-xe] [PATCH 1/5] drm/i915: Split display locks init from i915_driver_early_probe()

[Souza, Jose]

On Mon, 2023-04-03 at 13:03 -0400, Rodrigo Vivi wrote:
> On Mon, Apr 03, 2023 at 09:46:11AM -0700, José Roberto de Souza wrote:
> > No behavior changes here, just adding a function to make clear
> > what locks initialized here are display related or not.
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_driver.c | 23 +++
> >  1 file changed, 15 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 066d79c2069c4..224cb4cb43335 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -188,6 +188,20 @@ static void sanitize_gpu(struct drm_i915_private *i915)
> > }
> >  }
> >  
> > +static void
> > +i915_driver_display_early_probe(struct drm_i915_private *dev_priv)
> > +{
> > +   spin_lock_init(_priv->display.fb_tracking.lock);
> > +   spin_lock_init(_priv->display.wm.dsparb_lock);
> > +   mutex_init(_priv->display.backlight.lock);
> > +
> > +   mutex_init(_priv->display.audio.mutex);
> > +   mutex_init(_priv->display.wm.wm_mutex);
> > +   mutex_init(_priv->display.pps.mutex);
> > +   mutex_init(_priv->display.hdcp.comp_mutex);
> > +   spin_lock_init(_priv->display.dkl.phy_lock);
> > +}
> > +
> 
> hmmm... I like that, however Jani had indicated in another series [1]
> that he would prefer the wm mutex inside the wm code for instance...
> 
> So, should we move all of these to their own components instead of this
> move?
> 
> [1] https://patchwork.freedesktop.org/series/115675/
> 
> I checked and for a few components it is simple to move them to their
> own init functions. However for a few we would need to create new init
> functions and call them here.
> 
> Jani, more thoughts?

Forgot to CC you two in the new version: 
https://patchwork.freedesktop.org/series/116039/

display.wm.dsparb_lock is not used anywhere.
Moved display.dkl.phy_lock, will leave the rest to someone to take over.


> 
> >  /**
> >   * i915_driver_early_probe - setup state not requiring device access
> >   * @dev_priv: device private
> > @@ -213,18 +227,11 @@ static int i915_driver_early_probe(struct 
> > drm_i915_private *dev_priv)
> >  
> > spin_lock_init(_priv->irq_lock);
> > spin_lock_init(_priv->gpu_error.lock);
> > -   spin_lock_init(_priv->display.fb_tracking.lock);
> > -   spin_lock_init(_priv->display.wm.dsparb_lock);
> > -   mutex_init(_priv->display.backlight.lock);
> >  
> > mutex_init(_priv->sb_lock);
> > cpu_latency_qos_add_request(_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > -   mutex_init(_priv->display.audio.mutex);
> > -   mutex_init(_priv->display.wm.wm_mutex);
> > -   mutex_init(_priv->display.pps.mutex);
> > -   mutex_init(_priv->display.hdcp.comp_mutex);
> > -   spin_lock_init(_priv->display.dkl.phy_lock);
> > +   i915_driver_display_early_probe(dev_priv);
> >  
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(_priv->runtime_pm);
> > -- 
> > 2.40.0
> > 

Re: [Intel-gfx] [PATCH 03/14] drm/i915/tc: Fix the ICL PHY ownership check in TC-cold state

[Souza, Jose]

On Thu, 2023-03-16 at 15:17 +0200, Imre Deak wrote:
> The commit renaming icl_tc_phy_is_in_safe_mode() to
> icl_tc_phy_take_ownership() didn't flip the function's return value
> accordingly, fix this up.
> 
> This didn't cause an actual problem besides state check errors, since
> the function is only used during HW readout.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Fixes: f53979d68a77 ("drm/i915/display/tc: Rename safe_mode functions 
> ownership")
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 0b6fe96ab4759..fd826b9657e93 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -418,9 +418,9 @@ static bool icl_tc_phy_is_owned(struct intel_digital_port 
> *dig_port)
>   val = intel_de_read(i915, PORT_TX_DFLEXDPCSSS(dig_port->tc_phy_fia));
>   if (val == 0x) {
>   drm_dbg_kms(>drm,
> - "Port %s: PHY in TCCOLD, assume safe mode\n",
> + "Port %s: PHY in TCCOLD, assume not owned\n",
>   dig_port->tc_port_name);
> - return true;
> + return false;
>   }
>  
>   return val & DP_PHY_MODE_STATUS_NOT_SAFE(dig_port->tc_phy_fia_idx);

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

[Souza, Jose]

On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> As a fallback if we decide not to merge the frontbuffer tracking, allow
> i915 to keep its own implementation, and do the right thing in Xe.
> 
> The frontbuffer tracking for Xe is still done per-fb, while i915 can
> keep doing the weird intel_frontbuffer + i915_active thing without
> blocking Xe.

Please also disable PSR and FBC with this or at least add a way for users to 
disable those features.
Without frontbuffer tracker those two features will break in some cases.

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  .../gpu/drm/i915/display/intel_display_types.h  | 12 
>  drivers/gpu/drm/i915/display/intel_drrs.c   |  1 +
>  drivers/gpu/drm/i915/display/intel_fb.c |  8 +---
>  drivers/gpu/drm/i915/display/intel_fbdev.c  |  2 +-
>  .../gpu/drm/i915/display/intel_frontbuffer.c| 17 +
>  .../gpu/drm/i915/display/intel_frontbuffer.h| 12 ++--
>  drivers/gpu/drm/i915/display/intel_psr.c|  1 +
>  .../gpu/drm/i915/display/skl_universal_plane.c  |  2 ++
>  8 files changed, 45 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index f2918bb07107..a4a57aa24422 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -133,7 +133,11 @@ struct intel_fb_view {
>  
>  struct intel_framebuffer {
>   struct drm_framebuffer base;
> +#ifdef I915
>   struct intel_frontbuffer *frontbuffer;
> +#else
> + atomic_t bits;
> +#endif
>  
>   /* Params to remap the FB pages and program the plane registers in each 
> view. */
>   struct intel_fb_view normal_view;
> @@ -2074,10 +2078,18 @@ static inline u32 intel_plane_ggtt_offset(const 
> struct intel_plane_state *plane_
>  #endif
>  }
>  
> +#ifdef I915
>  static inline struct intel_frontbuffer *
>  to_intel_frontbuffer(struct drm_framebuffer *fb)
>  {
>   return fb ? to_intel_framebuffer(fb)->frontbuffer : NULL;
>  }
> +#else
> +static inline struct intel_framebuffer *
> +to_intel_frontbuffer(struct drm_framebuffer *fb)
> +{
> + return fb ? to_intel_framebuffer(fb) : NULL;
> +}
> +#endif
>  
>  #endif /*  __INTEL_DISPLAY_TYPES_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 5b9e3814..3503d112387d 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -9,6 +9,7 @@
>  #include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_drrs.h"
> +#include "intel_frontbuffer.h"
>  #include "intel_panel.h"
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 8c357a4098f6..e67c71f9b29d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1846,6 +1846,8 @@ static void intel_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>  #ifdef I915
>   if (intel_fb_uses_dpt(fb))
>   intel_dpt_destroy(intel_fb->dpt_vm);
> +
> + intel_frontbuffer_put(intel_fb->frontbuffer);
>  #else
>   if (intel_fb_obj(fb)->flags & XE_BO_CREATE_PINNED_BIT) {
>   struct xe_bo *bo = intel_fb_obj(fb);
> @@ -1857,8 +1859,6 @@ static void intel_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>   }
>  #endif
>  
> - intel_frontbuffer_put(intel_fb->frontbuffer);
> -
>   kfree(intel_fb);
>  }
>  
> @@ -1966,9 +1966,9 @@ int intel_framebuffer_init(struct intel_framebuffer 
> *intel_fb,
>   obj->flags |= XE_BO_SCANOUT_BIT;
>   }
>   ttm_bo_unreserve(>ttm);
> -#endif
>  
>   atomic_set(_fb->bits, 0);
> +#endif
>  
>   if (!drm_any_plane_has_format(_priv->drm,
> mode_cmd->pixel_format,
> @@ -2085,7 +2085,9 @@ int intel_framebuffer_init(struct intel_framebuffer 
> *intel_fb,
>   return 0;
>  
>  err:
> +#ifdef I915
>   intel_frontbuffer_put(intel_fb->frontbuffer);
> +#endif
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 75d8029185f0..2682b26b511f 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -82,7 +82,7 @@ struct intel_fbdev {
>  
>  static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
>  {
> - return ifbdev->fb->frontbuffer;
> + return to_intel_frontbuffer(>fb->base);
>  }
>  
>  static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
> b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 17a7aa8b28c2..64fe73d2ac4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> 

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add another EHL pci id

[Souza, Jose]

On Mon, 2023-02-06 at 08:59 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Add another EHL pci id
> URL: https://patchwork.freedesktop.org/series/113691/
> State: success

Pushed, thanks for the patch.

> Details: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113691v1/index.html
> 
> CI Bug Log - changes from CI_DRM_12697_full -> 
> Patchwork_113691v1_fullSummarySUCCESS
> No regressions found.
> External URL: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113691v1/index.html
> Participating hosts (9 -> 11)Additional (2): shard-rkl0 shard-tglu-9 
> Known issuesHere are the changes found in Patchwork_113691v1_full that come 
> from known issues:
> IGT changesIssues hit * igt@gen9_exec_parse@allowed-single:shard-glk: PASS -> 
> ABORT (i915#5566)
>  * 
> igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:shard-glk:
>  PASS -> FAIL (i915#2346)
>  * 
> igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:shard-glk:
>  PASS -> FAIL (i915#79)
> Possible fixes * igt@drm_fdinfo@idle@rcs0:{shard-rkl}: FAIL (i915#7742) -> 
> PASS
>  * igt@gem_exec_fair@basic-none-rrul@rcs0:{shard-rkl}: FAIL (i915#2842) -> 
> PASS
>  * igt@gem_exec_fair@basic-pace-share@rcs0:shard-glk: FAIL (i915#2842) -> PASS
>  * igt@gem_exec_reloc@basic-cpu-read-noreloc:{shard-rkl}: SKIP (i915#3281) -> 
> PASS +5 similar issues
>  * igt@gem_exec_schedule@semaphore-power:{shard-rkl}: SKIP (i915#7276) -> PASS
>  * igt@gem_mmap_gtt@coherency:{shard-rkl}: SKIP (fdo#111656) -> PASS
>  * igt@gem_partial_pwrite_pread@writes-after-reads:{shard-rkl}: SKIP 
> (i915#3282) -> PASS +9 similar issues
>  * igt@gen9_exec_parse@bb-start-param:{shard-rkl}: SKIP (i915#2527) -> PASS 
> +4 similar issues
>  * igt@i915_pm_rpm@modeset-lpsp:{shard-rkl}: SKIP (i915#1397) -> PASS
>  * igt@i915_pm_sseu@full-enable:{shard-rkl}: SKIP (i915#4387) -> PASS
>  * igt@kms_big_fb@x-tiled-32bpp-rotate-0:{shard-rkl}: SKIP (i915#1845 / 
> i915#4098) -> PASS +26 similar issues
>  * igt@kms_dp_aux_dev:{shard-rkl}: SKIP (i915#1257) -> PASS
>  * igt@kms_fbcon_fbt@fbc:{shard-rkl}: SKIP (i915#4098) -> PASS
>  * igt@kms_fbcon_fbt@psr-suspend:{shard-rkl}: SKIP (fdo#110189 / i915#3955) 
> -> PASS
>  * 
> igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-hdmi-a1-hdmi-a2:shard-glk:
>  FAIL (i915#2122) -> PASS
>  * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:shard-glk: FAIL (i915#79) -> 
> PASS
>  * 
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:{shard-rkl}:
>  SKIP (i915#1849 / i915#4098) -> PASS +20 similar issues
>  * igt@kms_psr@cursor_blt:{shard-rkl}: SKIP (i915#1072) -> PASS +2 similar 
> issues
>  * igt@perf@gen8-unprivileged-single-ctx-counters:{shard-rkl}: SKIP 
> (i915#2436) -> PASS
>  * igt@perf@mi-rpc:{shard-rkl}: SKIP (i915#2434) -> PASS
> {name}: This element is suppressed. This means it is ignored when computing
>  the status of the difference (SUCCESS, WARNING, or FAILURE).
> Build changes * Linux: CI_DRM_12697 -> Patchwork_113691v1
> CI-20190529: 20190529
>  CI_DRM_12697: 36bc05063652a1bb1a8c00c19c39281dc7ecf015 @ 
> git://anongit.freedesktop.org/gfx-ci/linux
>  IGT_7149: 1c7ea154b625e1fb826f1519b816b4256dd10b62 @ 
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>  Patchwork_113691v1: 36bc05063652a1bb1a8c00c19c39281dc7ecf015 @ 
> git://anongit.freedesktop.org/gfx-ci/linux

Re: [Intel-gfx] [PATCH] drm/i915: Add another EHL pci id

[Souza, Jose]

On Mon, 2023-02-06 at 15:37 +1100, Jonathan Gray wrote:
> described as "32 Execution Unit (EU) Super SKU" in:
> Intel Atom x6000E Series, and Intel Pentium and Celeron N and
> J Series Processors for IoT Applications
> Datasheet, Volume 1
> Document Number: 636112-1.6
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Jonathan Gray 
> ---
>  include/drm/i915_pciids.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 4a4c190f7698..92205054e542 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -588,6 +588,7 @@
>   INTEL_VGA_DEVICE(0x4551, info), \
>   INTEL_VGA_DEVICE(0x4555, info), \
>   INTEL_VGA_DEVICE(0x4557, info), \
> + INTEL_VGA_DEVICE(0x4570, info), \
>   INTEL_VGA_DEVICE(0x4571, info)
>  
>  /* JSL */

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Souza, Jose]

On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> SEL_FETCH_CTL registers are armed immediately when plane is disabled.
> SEL_FETCH_* instances of plane configuration are used when doing
> selective update and normal plane register instances for full updates.
> Currently all SEL_FETCH_* registers are written as a part of noarm
> plane configuration. If noarm and arm plane configuration are not
> happening within same vblank we may end up having plane as a part of
> selective update before it's PLANE_SURF register is written.
> 
> Fix this by splitting plane selective fetch configuration into arm and
> noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
> version.

Does this helps to revert the set of SFF and CFF at the same time?

> 
> v2:
>  - drop color_plane parameter from arm part
>  - dev_priv -> i915 in arm part
> 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Vinod Govindapillai 
> Cc: Stanislav Lisovskiy 
> Cc: Luca Coelho 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  | 28 +--
>  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
>  .../drm/i915/display/skl_universal_plane.c|  4 ++-
>  4 files changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index d190fa0d393b..ae9f0b6c92db 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -532,7 +532,8 @@ static void i9xx_cursor_update_arm(struct intel_plane 
> *plane,
>   skl_write_cursor_wm(plane, crtc_state);
>  
>   if (plane_state)
> - intel_psr2_program_plane_sel_fetch(plane, crtc_state, 
> plane_state, 0);
> + intel_psr2_program_plane_sel_fetch_arm(plane, crtc_state,
> +plane_state);
>   else
>   intel_psr2_disable_plane_sel_fetch(plane, crtc_state);

Missing rename intel_psr2_disable_plane_sel_fetch() to 
intel_psr2_disable_plane_sel_fetch_arm().

With this LGTM.
Reviewed-by: José Roberto de Souza 


>  
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7a72e15e6836..a3f4451eb66d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1559,7 +1559,25 @@ void intel_psr2_disable_plane_sel_fetch(struct 
> intel_plane *plane,
>   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
>  }
>  
> -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
> + const struct intel_crtc_state 
> *crtc_state,
> + const struct intel_plane_state 
> *plane_state)
> +{
> + struct drm_i915_private *i915 = to_i915(plane->base.dev);
> + enum pipe pipe = plane->pipe;
> +
> + if (!crtc_state->enable_psr2_sel_fetch)
> + return;
> +
> + if (plane->id == PLANE_CURSOR)
> + intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> +   plane_state->ctl);
> + else
> + intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> +   PLANE_SEL_FETCH_CTL_ENABLE);
> +}
> +
> +void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
>   const struct intel_crtc_state 
> *crtc_state,
>   const struct intel_plane_state 
> *plane_state,
>   int color_plane)
> @@ -1573,11 +1591,8 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
>   if (!crtc_state->enable_psr2_sel_fetch)
>   return;
>  
> - if (plane->id == PLANE_CURSOR) {
> - intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
> plane->id),
> -   plane_state->ctl);
> + if (plane->id == PLANE_CURSOR)
>   return;
> - }
>  
>   clip = _state->psr2_sel_fetch_area;
>  
> @@ -1605,9 +1620,6 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
>   val = (drm_rect_height(clip) - 1) << 16;
>   val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
>   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
> -
> - intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> -   PLANE_SEL_FETCH_CTL_ENABLE);
>  }
>  
>  void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
> *crtc_state)
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h 
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index 2ac3a465..c87ae2e6ee6c 100644
> --- 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Add continuous full frame bit together with single

[Souza, Jose]

On Tue, 2022-11-29 at 09:51 +0200, Jouni Högander wrote:
> Currently we are observing occasionally display flickering or complete
> freeze. This is narrowed down to be caused by single full frame update
> (SFF).
> 
> SFF bit after it's written gets cleared by HW in subsequent vblank
> i.e. when the update is sent to the panel. SFF bit is required to be
> written together with partial frame update (PFU) bit. After the SFF
> bit gets cleared by the HW psr2 man trk ctl register still contains
> PFU bit. If there is subsequent update for any reason we will end up
> having selective update/fetch configuration where start line is 0 and
> end line is 0.
> 

How did you get this information(start and end line 0)?

>  Also selective fetch configuration for the planes is
> not properly performed. This seems to be causing problems with some
> panels.
> 
> Using CFF without SFF doesn't work either because it may happen that
> psr2 man track ctl register is overwritten by next update before
> vblank triggers sending the update. This is causing problems to
> psr_invalidate/flush. Using CFF and SFF together solves the problems
> as SFF is cleared only by HW in subsequent vblank.

This looks dangerous, have you checked with HW engineers if setting both could 
cause any issue?
At the SFF write you could get what is the current vblank counter and properly 
handle future PSR2_MAN_TRK_CTL writes.

> 
> Fix the flickering/freeze issue by adding continuous full frame with
> single full frame update and switch to partial frame update only when
> selective update area is properly calculated and configured.
> 
> This is also workaround for HSD 14014971508

Please use versions in your patches, you had 2 patches in the previous approach 
with the same subject but no versioning and no information about what
changed between versions.

> 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Reported-by: Lee Shawn C 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 5b678916e6db..88388201684e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1510,7 +1510,8 @@ static void psr_force_hw_tracking_exit(struct intel_dp 
> *intel_dp)
>  PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
>  man_trk_ctl_enable_bit_get(dev_priv) |
>  man_trk_ctl_partial_frame_bit_get(dev_priv) |
> -man_trk_ctl_single_full_frame_bit_get(dev_priv));
> +man_trk_ctl_single_full_frame_bit_get(dev_priv) |
> +man_trk_ctl_continuos_full_frame(dev_priv));
>  
>   /*
>* Display WA #0884: skl+
> @@ -1624,11 +1625,8 @@ static void psr2_man_trk_ctl_calc(struct 
> intel_crtc_state *crtc_state,
>   val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
>  
>   if (full_update) {
> - /*
> -  * Not applying Wa_14014971508:adlp as we do not support the
> -  * feature that requires this workaround.
> -  */
>   val |= man_trk_ctl_single_full_frame_bit_get(dev_priv);
> + val |= man_trk_ctl_continuos_full_frame(dev_priv);
>   goto exit;
>   }
>  
> @@ -2307,12 +2305,15 @@ static void _psr_flush_handle(struct intel_dp 
> *intel_dp)
>   /* can we turn CFF off? */
>   if (intel_dp->psr.busy_frontbuffer_bits == 0) {
>   u32 val = man_trk_ctl_enable_bit_get(dev_priv) |
> -   
> man_trk_ctl_partial_frame_bit_get(dev_priv) |
> -   
> man_trk_ctl_single_full_frame_bit_get(dev_priv);
> + 
> man_trk_ctl_partial_frame_bit_get(dev_priv) |
> + 
> man_trk_ctl_single_full_frame_bit_get(dev_priv) |
> + 
> man_trk_ctl_continuos_full_frame(dev_priv);

style.

>  
>   /*
> -  * turn continuous full frame off and do a 
> single
> -  * full frame
> +  * turn continuous full frame off and do a 
> single full frame. Still
> +  * keep cff bit enabled as we don't have proper 
> SU configuration in
> +  * case update is sent for any reason after sff 
> bit gets cleared by
> +  * the HW on next vblank.


turn off and keep bit enabled?! makes no sense this comment.

>*/
>   intel_de_write(dev_priv, 
> PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
>

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gsc: Only initialize GSC in tile 0 (rev2)

[Souza, Jose]

On Mon, 2022-11-21 at 14:31 +, Patchwork wrote:
Patch Details
Series: drm/i915/gsc: Only initialize GSC in tile 0 (rev2)
URL:https://patchwork.freedesktop.org/series/110304/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110304v2/index.html
CI Bug Log - changes from CI_DRM_12407_full -> Patchwork_110304v2_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_110304v2_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110304v2_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 -> 9)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
 *   shard-skl: NOTRUN -> 
INCOMPLETE

Not related regression.

Patch pushed to drm-intel-gt-next, thanks.

Known issues

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

CI changes
Possible fixes

  *   boot:

 *   shard-glk: 
(PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 (i915#4392) -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Souza, Jose]

On Wed, 2022-11-02 at 19:45 +0200, Jouni Högander wrote:
> Selective update area is now aligned with DSC slice height when
> DSC is enabled. Remove inappropriate warning about missing DSC
> alignment.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> Signed-off-by: Jouni Högander 
> Signed-off-by: Anshuman Gupta 
> Reviewed-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 57575b5c6d48..a75b37851504 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1684,9 +1684,6 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
> struct intel_crtc_state *c
>   pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
>   if (pipe_clip->y2 % y_alignment)
>   pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1) * 
> y_alignment;
> -
> - if (IS_ALDERLAKE_P(dev_priv) && crtc_state->dsc.compression_enable)
> - drm_warn(_priv->drm, "Missing PSR2 sel fetch alignment with 
> DSC\n");
>  }
>  
>  /*

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Ensure panel granularity aligns with DSC slice height

[Souza, Jose]

On Wed, 2022-11-02 at 19:45 +0200, Jouni Högander wrote:
> Do not enable psr2 if panel ganularity is not aligned with DSC slice
> height when DSC is enabled
> 

Reviewed-by: José Roberto de Souza 

> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index e11b0592055f..57575b5c6d48 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -779,6 +779,7 @@ static bool psr2_granularity_check(struct intel_dp 
> *intel_dp,
>  struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + const struct drm_dsc_config *vdsc_cfg = _state->dsc.config;
>   const int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   const int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
>   u16 y_granularity = 0;
> @@ -809,6 +810,10 @@ static bool psr2_granularity_check(struct intel_dp 
> *intel_dp,
>   if (y_granularity == 0 || crtc_vdisplay % y_granularity)
>   return false;
>  
> + if (crtc_state->dsc.compression_enable &&
> + vdsc_cfg->slice_height % y_granularity)
> + return false;
> +
>   crtc_state->su_y_granularity = y_granularity;
>   return true;
>  }

Re: [Intel-gfx] [PATCH] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Souza, Jose]

On Tue, 2022-11-01 at 20:55 +, Hogander, Jouni wrote:
> On Tue, 2022-11-01 at 20:00 +0000, Souza, Jose wrote:
> > On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> > > Selective update area is now aligned with DSC slice height when
> > > DSC is enabled. Remove inappropriate warning about missing DSC
> > > alignment.
> > > 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > 
> > > Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> > > Signed-off-by: Jouni Högander 
> > > Signed-off-by: Anshuman Gupta 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 904a1049eff3..64e9e134fdca 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1678,9 +1678,6 @@ static void
> > > intel_psr2_sel_fetch_pipe_alignment(const struct intel_crtc_state
> > > *c
> > > pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
> > > if (pipe_clip->y2 % y_alignment)
> > > pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1)
> > > * y_alignment;
> > > -
> > > -   if (IS_ALDERLAKE_P(dev_priv) && crtc_state-
> > > > dsc.compression_enable)
> > > -   drm_warn(_priv->drm, "Missing PSR2 sel fetch
> > > alignment with DSC\n");
> > 
> > It is necessary check if DSC alignment and PSR2 alignment matches, if
> > not PSR2 can't be enabled.
> 
> This check is there at the begin of
> intel_psr2_sel_fetch_pipe_alignment:
> 
> /* ADLP aligns the SU region to vdsc slice height in case dsc is
> enabled */
> if (crtc_state->dsc.compression_enable &&
>   (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14))
>   y_alignment = vdsc_cfg->slice_height;

This is still wrong.
There is no guarantee that required PSR2 alignment matches 
vdsc_cfg->slice_height.

> 
> For some reason when this got merged warning was still left there. Now
> just removing the warning as well.
> 
> > 
> > >  }
> > >  
> > >  /*
> > 
> 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Souza, Jose]

On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> Selective update area is now aligned with DSC slice height when
> DSC is enabled. Remove inappropriate warning about missing DSC
> alignment.
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> Signed-off-by: Jouni Högander 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 904a1049eff3..64e9e134fdca 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1678,9 +1678,6 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
> struct intel_crtc_state *c
>   pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
>   if (pipe_clip->y2 % y_alignment)
>   pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1) * 
> y_alignment;
> -
> - if (IS_ALDERLAKE_P(dev_priv) && crtc_state->dsc.compression_enable)
> - drm_warn(_priv->drm, "Missing PSR2 sel fetch alignment with 
> DSC\n");

It is necessary check if DSC alignment and PSR2 alignment matches, if not PSR2 
can't be enabled.

>  }
>  
>  /*

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Souza, Jose]

On Tue, 2022-11-01 at 13:53 +0200, Jouni Högander wrote:
> MTL shares PSR2_MAN_TRK_CTL bits with ADL. Currently some bit
> getter functions are incorrect for MTL. This patch fixes those.
> 
> Bspec: 49274

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Radhakrishna Sripada 
> 
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 904a1049eff3..4bfb8313738e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1470,7 +1470,8 @@ void intel_psr_resume(struct intel_dp *intel_dp)
>  
>  static u32 man_trk_ctl_enable_bit_get(struct drm_i915_private *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ? 0 : PSR2_MAN_TRK_CTL_ENABLE;
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ? 0 :
> + PSR2_MAN_TRK_CTL_ENABLE;
>  }
>  
>  static u32 man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private 
> *dev_priv)
> @@ -1482,14 +1483,14 @@ static u32 
> man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private *dev_pr
>  
>  static u32 man_trk_ctl_partial_frame_bit_get(struct drm_i915_private 
> *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ?
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
>  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
>  PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
>  }
>  
>  static u32 man_trk_ctl_continuos_full_frame(struct drm_i915_private 
> *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ?
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
>  ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME :
>  PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
>  }

Re: [Intel-gfx] [PATCH] drm/i915/psr: Send update also on invalidate

[Souza, Jose]

On Mon, 2022-10-24 at 08:46 +0300, Jouni Högander wrote:
> Currently we are observing mouse cursor stuttering when using
> xrandr --scaling=1.2x1.2. X scaling/transformation seems to be
> doing fronbuffer rendering. When moving mouse cursor X seems to
> perform several invalidates and only one DirtyFB. I.e. it seems
> to be assuming updates are sent to panel while drawing is done.
> 
> Earlier we were disabling PSR in frontbuffer invalidate call back
> (when drawing in X started). PSR was re-enabled in frontbuffer
> flush callback (dirtyfb ioctl). This was working fine with X
> scaling/transformation. Now we are just enabling continuous full
> frame (cff) in PSR invalidate callback. Enabling cff doesn't
> trigger any updates. It just configures PSR to send full frame
> when updates are sent. I.e. there are no updates on screen before
> PSR flush callback is made. X seems to be doing several updates
> in frontbuffer before doing dirtyfb ioctl.
> 
> Fix this by sending single update on every invalidate callback.

Fair enough.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Ville Syrjälä 
> Cc: Mika Kahola 
> 
> Fixes: 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to 
> handle frontbuffer invalidations")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6679
> Signed-off-by: Jouni Högander 
> Reported-by: Brian J. Tarricone 
> Tested-by: Brian J. Tarricone 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 904a1049eff3..564d4fd94048 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2209,8 +2209,11 @@ static void _psr_invalidate_handle(struct intel_dp 
> *intel_dp)
>   if (intel_dp->psr.psr2_sel_fetch_enabled) {
>   u32 val;
>  
> - if (intel_dp->psr.psr2_sel_fetch_cff_enabled)
> + if (intel_dp->psr.psr2_sel_fetch_cff_enabled) {
> + /* Send one update otherwise lag is observed in screen 
> */
> + intel_de_write(dev_priv, 
> CURSURFLIVE(intel_dp->psr.pipe), 0);
>   return;
> + }
>  
>   val = man_trk_ctl_enable_bit_get(dev_priv) |
> man_trk_ctl_partial_frame_bit_get(dev_priv) |

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Extend Wa_1607297627 to Alderlake-P

[Souza, Jose]

On Mon, 2022-10-17 at 20:05 +, Patchwork wrote:
Patch Details
Series: drm/i915: Extend Wa_1607297627 to Alderlake-P
URL:https://patchwork.freedesktop.org/series/109772/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/index.html
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109772v1_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_109772v1_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_109772v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (12 -> 12)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@i915_module_load@reload-with-fault-injection:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
  *   igt@i915_suspend@debugfs-reader:

 *   shard-apl: NOTRUN -> 
INCOMPLETE

Failures are not related, patch was pushed.

Thanks for the review Lucas and Tvrtko.

Warnings

  *   igt@gem_eio@in-flight-suspend:
 *   shard-apl: 
INCOMPLETE
 (i915#7112) -> 
INCOMPLETE

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-apl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 -> 
(PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [PATCH] i915: Extend Wa_1607297627 to Alderlake-P

[Souza, Jose]

On Mon, 2022-10-17 at 09:51 +0100, Tvrtko Ursulin wrote:
> On 14/10/2022 23:08, Lucas De Marchi wrote:
> > On Thu, Oct 13, 2022 at 06:23:07PM +, Jose Souza wrote:
> > > missed the "drm/" in the subject 
> > 
> > with that,  Reviewed-by: Lucas De Marchi 
> 
> And where is the commit text? :p
> 
> Impact warrants fixes and/or cc stable 5.17+ for ADL-P force probe 
> removal or not?

Will add the fixes to adl-p force probe patch in the v2.

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > Lucas De Marchi
> > 
> > > 
> > > On Thu, 2022-10-13 at 11:14 -0700, José Roberto de Souza wrote:
> > > > BSpec: 54369
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > index b8eb20a155f0d..e1d5df3a5756e 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > @@ -2300,11 +2300,11 @@ rcs_engine_wa_init(struct intel_engine_cs 
> > > > *engine, struct i915_wa_list *wal)
> > > >  }
> > > > 
> > > >  if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
> > > > -    IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
> > > > +    IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || 
> > > > IS_ALDERLAKE_P(i915)) {
> > > >  /*
> > > >   * Wa_1607030317:tgl
> > > >   * Wa_1607186500:tgl
> > > > - * Wa_1607297627:tgl,rkl,dg1[a0]
> > > > + * Wa_1607297627:tgl,rkl,dg1[a0],adlp
> > > >   *
> > > >   * On TGL and RKL there are multiple entries for this WA in the
> > > >   * BSpec; some indicate this is an A0-only WA, others indicate
> > > 

Re: [Intel-gfx] [PATCH] i915: Extend Wa_1607297627 to Alderlake-P

[Souza, Jose]

missed the "drm/" in the subject 

On Thu, 2022-10-13 at 11:14 -0700, José Roberto de Souza wrote:
> BSpec: 54369
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index b8eb20a155f0d..e1d5df3a5756e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2300,11 +2300,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>   }
>  
>   if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
> - IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
> + IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) {
>   /*
>* Wa_1607030317:tgl
>* Wa_1607186500:tgl
> -  * Wa_1607297627:tgl,rkl,dg1[a0]
> +  * Wa_1607297627:tgl,rkl,dg1[a0],adlp
>*
>* On TGL and RKL there are multiple entries for this WA in the
>* BSpec; some indicate this is an A0-only WA, others indicate

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)

[Souza, Jose]

On Mon, 2022-10-03 at 09:30 +, Patchwork wrote:
Patch Details
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL:https://patchwork.freedesktop.org/series/108811/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108811v4/index.html
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_108811v4_full
Summary

SUCCESS

No regressions found.

Pushed to drm-intel-next, thanks for the patch.


Participating hosts (9 -> 9)

No changes in participating hosts

Known issues

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

CI changes
Possible fixes

  *   boot:
 *   shard-apl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 (i915#4386) -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

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

[Souza, Jose]

On Mon, 2022-10-03 at 10:20 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
> 
> /*
>  * gen12+ has registers relative to transcoder and one per transcoder
>  * using the same bit definition: handle it as TRANSCODER_EDP to force
>  * 0 shift in bit definition
>  */
> 
> At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> incorrectly if DISPLAY_VER >= 12.
> 
> Fix this by adding separate register field defines for >=12 and add bit
> getter functions to keep code readability.
> 
> v4:
>  - Remove EDP from TGL definitions (José)
>  - Use REG_BIT and REG_GENMASK (José)
> v3:
>  - Add separate register field defines (José)
>  - Add bit getter functions (José)
> v2:
>  - Improve commit message (José)

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Fixes: 8241cfbe67f4 ("drm/i915/tgl: Access the right register when handling 
> PSR interruptions")
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 78 ++--
>  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
>  2 files changed, 59 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..d4cce627d7a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_PSR_ERROR :
> + EDP_PSR_ERROR(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_PSR_POST_EXIT :
> + EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_PSR_PRE_ENTRY :
> + EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_PSR_MASK :
> + EDP_PSR_MASK(intel_dp->psr.transcoder);
> +}
> +
>  static void psr_irq_control(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>   u32 mask, val;
>  
> - /*
> -  * gen12+ has registers relative to transcoder and one per transcoder
> -  * using the same bit definition: handle it as TRANSCODER_EDP to force
> -  * 0 shift in bit definition
> -  */
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - mask = EDP_PSR_ERROR(trans_shift);
> + mask = psr_irq_psr_error_bit_get(intel_dp);
>   if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> - mask |= EDP_PSR_POST_EXIT(trans_shift) |
> - EDP_PSR_PRE_ENTRY(trans_shift);
> + mask |= psr_irq_post_exit_bit_get(intel_dp) |
> + psr_irq_pre_entry_bit_get(intel_dp);
>  
> - /* Warning: it is masking/setting reserved bits too */
>   val = intel_de_read(dev_priv, imr_reg);
> - val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> + val &= ~psr_irq_mask_get(intel_dp);
>   val |= ~mask;
>   intel_de_write(dev_priv, imr_reg, val);
>  }
> @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> u32 psr_iir)
>   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   ktime_t time_ns =  ktime_get();
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>  
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - if (psr_iir & EDP_PSR_PRE_ENTRY(trans_shift)) {
> + if (psr_iir & psr_irq_pre_entry_bit_get(intel_dp)) {
>   intel_dp->psr.last_entry_attempt = 

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

[Souza, Jose]

On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote:
> On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> > bits in PSR_IMR/IIR registers:
> > 
> > /*
> >  * gen12+ has registers relative to transcoder and one per transcoder
> >  * using the same bit definition: handle it as TRANSCODER_EDP to force
> >  * 0 shift in bit definition
> >  */
> > 
> > At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> > This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> > incorrectly if DISPLAY_VER >= 12.
> > 
> > Fix this by adding separate register field defines for >=12 and add bit
> > getter functions to keep code readability.
> > 
> > v3:
> >  - Add separate register field defines (José)
> >  - Add bit getter functions (José)
> > v2:
> >  - Improve commit message (José)

Also missing the Fixes tag, so this gets backported to stable kernels.

> > 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
> >  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
> >  2 files changed, 62 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9def8d9fade6..d7b08a7da9e9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> > *intel_dp)
> > }
> >  }
> >  
> > +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> > +   EDP_PSR_ERROR(intel_dp->psr.transcoder);
> 
> Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP 
> or any transcoder in TGL+ it is one register per transcoder.
> 
> > +}
> > +
> > +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> > +   EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> > +   EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> > +   EDP_PSR_MASK(intel_dp->psr.transcoder);
> > +}
> > +
> >  static void psr_irq_control(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> > u32 mask, val;
> >  
> > -   /*
> > -* gen12+ has registers relative to transcoder and one per transcoder
> > -* using the same bit definition: handle it as TRANSCODER_EDP to force
> > -* 0 shift in bit definition
> > -*/
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   mask = EDP_PSR_ERROR(trans_shift);
> > +   mask = psr_irq_psr_error_bit_get(intel_dp);
> > if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> > -   mask |= EDP_PSR_POST_EXIT(trans_shift) |
> > -   EDP_PSR_PRE_ENTRY(trans_shift);
> > +   mask |= psr_irq_post_exit_bit_get(intel_dp) |
> > +   psr_irq_pre_entry_bit_get(intel_dp);
> >  
> > -   /* Warning: it is masking/setting reserved bits too */
> > val = intel_de_read(dev_priv, imr_reg);
> > -   val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> > +   val &= ~psr_irq_mask_get(intel_dp);
> > val |= ~mask;
> > intel_de_write(dev_priv, imr_reg, val);
> >  }
> > @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> > u32 psr_iir)
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > ktime_t time_ns =  ktime_get();
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> >  
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   if 

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

[Souza, Jose]

On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
> 
> /*
>  * gen12+ has registers relative to transcoder and one per transcoder
>  * using the same bit definition: handle it as TRANSCODER_EDP to force
>  * 0 shift in bit definition
>  */
> 
> At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> incorrectly if DISPLAY_VER >= 12.
> 
> Fix this by adding separate register field defines for >=12 and add bit
> getter functions to keep code readability.
> 
> v3:
>  - Add separate register field defines (José)
>  - Add bit getter functions (José)
> v2:
>  - Improve commit message (José)
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
>  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
>  2 files changed, 62 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..d7b08a7da9e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> + EDP_PSR_ERROR(intel_dp->psr.transcoder);

Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP or 
any transcoder in TGL+ it is one register per transcoder.

> +}
> +
> +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> + EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> + EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> + EDP_PSR_MASK(intel_dp->psr.transcoder);
> +}
> +
>  static void psr_irq_control(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>   u32 mask, val;
>  
> - /*
> -  * gen12+ has registers relative to transcoder and one per transcoder
> -  * using the same bit definition: handle it as TRANSCODER_EDP to force
> -  * 0 shift in bit definition
> -  */
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - mask = EDP_PSR_ERROR(trans_shift);
> + mask = psr_irq_psr_error_bit_get(intel_dp);
>   if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> - mask |= EDP_PSR_POST_EXIT(trans_shift) |
> - EDP_PSR_PRE_ENTRY(trans_shift);
> + mask |= psr_irq_post_exit_bit_get(intel_dp) |
> + psr_irq_pre_entry_bit_get(intel_dp);
>  
> - /* Warning: it is masking/setting reserved bits too */
>   val = intel_de_read(dev_priv, imr_reg);
> - val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> + val &= ~psr_irq_mask_get(intel_dp);
>   val |= ~mask;
>   intel_de_write(dev_priv, imr_reg, val);
>  }
> @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> u32 psr_iir)
>   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   ktime_t time_ns =  ktime_get();
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>  
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - if (psr_iir & EDP_PSR_PRE_ENTRY(trans_shift)) {
> + if (psr_iir & psr_irq_pre_entry_bit_get(intel_dp)) {
>   intel_dp->psr.last_entry_attempt = time_ns;
>   drm_dbg_kms(_priv->drm,
>   "[transcoder %s] PSR entry attempt in 2 vblanks\n",
> 

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

[Souza, Jose]

On Fri, 2022-09-23 at 12:45 +, Hogander, Jouni wrote:
> On Fri, 2022-09-23 at 12:37 +0000, Souza, Jose wrote:
> > On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > > > Current PSR code is supposed to use TRANSCODER_EDP to force 0
> > > > > shift
> > > > > for
> > > > > bits in PSR_IMR/IIR registers:
> > > > > 
> > > > > /*
> > > > >  * gen12+ has registers relative to transcoder and one per
> > > > > transcoder
> > > > >  * using the same bit definition: handle it as TRANSCODER_EDP
> > > > > to
> > > > > force
> > > > >  * 0 shift in bit definition
> > > > >  */
> > > > > 
> > > > > At the time of writing the code assumption "TRANSCODER_EDP ==
> > > > > 0"
> > > > > was made.
> > > > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > > > shifted
> > > > > incorrectly if DISPLAY_VER >= 12.
> > > > 
> > > > From where are you getting that TRANSCODER_EDP == 0?
> > > 
> > > It's not. That is my point. If you look at this commit:
> > > 
> > > https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> > > 
> > > adding this comment:
> > > 
> > > +   /*
> > > +    * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > > +    * using the same bit definition: handle it as
> > > TRANSCODER_EDP
> > > to force
> > > +    * 0 shift in bit definition
> > > +    */
> > > 
> > > and the code added by this commit is doing
> > > 
> > > ...
> > > +   trans_shift = 0;
> > > mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > > 
> > > +   mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > > 
> > > and if we look at EDP_PSR_ERROR definition:
> > > 
> > > ...
> > > #define   _EDP_PSR_TRANS_SHIFT(trans)   ((trans) ==
> > > TRANSCODER_EDP ? \
> > >  0 : ((trans) -
> > > TRANSCODER_A + 1) * 8)
> > > ...
> > > #define   EDP_PSR_ERROR(trans)  (0x4 <<
> > > _EDP_PSR_TRANS_SHIFT(trans))
> > > ...
> > > 
> > > EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> > > TRANSCODER_EDP as mentioned in the added comment:
> > > EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> > > 
> > > My patch is doing what is in the comment. There are other way to
> > > fix
> > > this, but to my opinion original idea using TRANSCODER_EDP in
> > > commit 
> > > 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> > > code pretty clean.
> > > 
> > > > 
> > > > enum pipe {
> > > > INVALID_PIPE = -1,
> > > > 
> > > > PIPE_A = 0,
> > > > PIPE_B,
> > > > PIPE_C,
> > > > PIPE_D,
> > > > _PIPE_EDP,
> > > > 
> > > > I915_MAX_PIPES = _PIPE_EDP
> > > > };
> > > > 
> > > > #define pipe_name(p) ((p) + 'A')
> > > > 
> > > > enum transcoder {
> > > > INVALID_TRANSCODER = -1,
> > > > /*
> > > >  * The following transcoders have a 1:1 transcoder ->
> > > > pipe
> > > > mapping,
> > > >  * keep their values fixed: the code assumes that
> > > > TRANSCODER_A=0, the
> > > >  * rest have consecutive values and match the enum values
> > > > of
> > > > the pipes
> > > >  * they map to.EDP_PSR_TRANS_
> > > >  */
> > > > TRANSCODER_A = PIPE_A,
> > > > TRANSCODER_B = PIPE_B,
> > > > TRANSCODER_C = PIPE_C,
> > > > TRANSCODER_D = PIPE_D,
> > > > 
> > > > /*
> > > >  * The following transcoders can map to any pipe, their
> > > > enum
> > > > value
> > > >  * doesn't need to stay fixed.
> > > >  */
&

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

[Souza, Jose]

On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> On Thu, 2022-09-22 at 13:08 +0000, Souza, Jose wrote:
> > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift
> > > for
> > > bits in PSR_IMR/IIR registers:
> > > 
> > > /*
> > >  * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > >  * using the same bit definition: handle it as TRANSCODER_EDP to
> > > force
> > >  * 0 shift in bit definition
> > >  */
> > > 
> > > At the time of writing the code assumption "TRANSCODER_EDP == 0"
> > > was made.
> > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > shifted
> > > incorrectly if DISPLAY_VER >= 12.
> > 
> > From where are you getting that TRANSCODER_EDP == 0?
> 
> It's not. That is my point. If you look at this commit:
> 
> https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> 
> adding this comment:
> 
> +   /*
> +* gen12+ has registers relative to transcoder and one per
> transcoder
> +* using the same bit definition: handle it as TRANSCODER_EDP
> to force
> +* 0 shift in bit definition
> +*/
> 
> and the code added by this commit is doing
> 
> ...
> +   trans_shift = 0;
> mask = EDP_PSR_ERROR(trans_shift);
> ...
> 
> +   mask = EDP_PSR_ERROR(trans_shift);
> ...
> 
> and if we look at EDP_PSR_ERROR definition:
> 
> ...
> #define   _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> TRANSCODER_EDP ? \
>0 : ((trans) -
> TRANSCODER_A + 1) * 8)
> ...
> #define   EDP_PSR_ERROR(trans)(0x4 <<
> _EDP_PSR_TRANS_SHIFT(trans))
> ...
> 
> EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> TRANSCODER_EDP as mentioned in the added comment:
> EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> 
> My patch is doing what is in the comment. There are other way to fix
> this, but to my opinion original idea using TRANSCODER_EDP in commit 
> 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> code pretty clean.
> 
> > 
> > enum pipe {
> > INVALID_PIPE = -1,
> > 
> > PIPE_A = 0,
> > PIPE_B,
> > PIPE_C,
> > PIPE_D,
> > _PIPE_EDP,
> > 
> > I915_MAX_PIPES = _PIPE_EDP
> > };
> > 
> > #define pipe_name(p) ((p) + 'A')
> > 
> > enum transcoder {
> > INVALID_TRANSCODER = -1,
> > /*
> >  * The following transcoders have a 1:1 transcoder -> pipe
> > mapping,
> >  * keep their values fixed: the code assumes that
> > TRANSCODER_A=0, the
> >  * rest have consecutive values and match the enum values of
> > the pipes
> >  * they map to.EDP_PSR_TRANS_
> >  */
> > TRANSCODER_A = PIPE_A,
> > TRANSCODER_B = PIPE_B,
> > TRANSCODER_C = PIPE_C,
> > TRANSCODER_D = PIPE_D,
> > 
> > /*
> >  * The following transcoders can map to any pipe, their enum
> > value
> >  * doesn't need to stay fixed.
> >  */
> > TRANSCODER_EDP,
> > 
> > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> > 
> > > 
> > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > thought
> > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this way
> > > keeps
> > > code clean and readable.
> > 
> > trans_shift = 0 is fine, we needed this because display12+ splited
> > from a single register with all transcoder to one register per
> > transcoder.
> > 
> 
> No, it's not. See the definition of  _EDP_PSR_TRANS_SHIFT and
> EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would prevent
> misunderstanding here.

Okay now I understood.
In my opinion the proper fix would be add TGL_X macros to be used in diplay12+ 
paths and drop the EDP transcoder concept that do not exist in TGL+.

Also please include a fixes tag pointing to 
8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf so this gets backported.

> 
> > > 
> > > v2: Improve commit message (José)
> > > 
> > > Cc: Mika Kahola 
> > > Cc: José Roberto de Souza 
> > > 
> > > Signed-off-by: Jouni Högander 
> > > ---
> > > 

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

[Souza, Jose]

On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
> 
> /*
>  * gen12+ has registers relative to transcoder and one per transcoder
>  * using the same bit definition: handle it as TRANSCODER_EDP to force
>  * 0 shift in bit definition
>  */
> 
> At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> incorrectly if DISPLAY_VER >= 12.

From where are you getting that TRANSCODER_EDP == 0?


enum pipe {
INVALID_PIPE = -1,

PIPE_A = 0,
PIPE_B,
PIPE_C,
PIPE_D,
_PIPE_EDP,

I915_MAX_PIPES = _PIPE_EDP
};

#define pipe_name(p) ((p) + 'A')

enum transcoder {
INVALID_TRANSCODER = -1,
/*
 * The following transcoders have a 1:1 transcoder -> pipe mapping,
 * keep their values fixed: the code assumes that TRANSCODER_A=0, the
 * rest have consecutive values and match the enum values of the pipes
 * they map to.
 */
TRANSCODER_A = PIPE_A,
TRANSCODER_B = PIPE_B,
TRANSCODER_C = PIPE_C,
TRANSCODER_D = PIPE_D,

/*
 * The following transcoders can map to any pipe, their enum value
 * doesn't need to stay fixed.
 */
TRANSCODER_EDP,

https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87

> 
> Fix this by using TRANSCODER_EDP definition instead of 0. Even thought
> TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this way keeps
> code clean and readable.

trans_shift = 0 is fine, we needed this because display12+ splited from a 
single register with all transcoder to one register per transcoder.

> 
> v2: Improve commit message (José)
> 
> Cc: Mika Kahola 
> Cc: José Roberto de Souza 
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..9ecf1a9a1120 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -129,7 +129,7 @@ static void psr_irq_control(struct intel_dp *intel_dp)
>* 0 shift in bit definition
>*/
>   if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + trans_shift = TRANSCODER_EDP;
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
>   } else {
>   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);

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

Re: [Intel-gfx] [PATCH] drm/i915/psr: Do not re-activate PSR if there was a PSR aux error

[Souza, Jose]

On Fri, 2022-09-16 at 14:08 +0300, Jouni Högander wrote:
> If there is a PSR aux error sink is marked as not reliable
> and PSR is permantently disabled.
> 
> Current code is activating PSR again even there was PSR aux error.
> Fix this by skipping intel_psr_activate when PSR aux error is
> detected.
> 
> Cc: Mika Kahola 
> Cc: José Roberto de Souza 
> 
> Reported-by: Charlton Lin 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..42390203ad19 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2153,8 +2153,10 @@ static void intel_psr_work(struct work_struct *work)
>   if (!intel_dp->psr.enabled)
>   goto unlock;
>  
> - if (READ_ONCE(intel_dp->psr.irq_aux_error))
> + if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
>   intel_psr_handle_irq(intel_dp);
> + goto unlock;
> + }

Already handled.
__psr_wait_for_idle_locked
if (!intel_dp->psr.enabled)
return false;

>  
>   /*
>* We have to make sure PSR is ready for re-enable

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Disable PSR before disable pipe

[Souza, Jose]

On Fri, 2022-07-15 at 11:39 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Jul 15, 2022 at 08:33:43AM +0300, Hogander, Jouni wrote:
> > On Thu, 2022-07-14 at 08:07 -0700, José Roberto de Souza wrote:
> > > The issue here was on for_each_intel_encoder_mask_with_psr() over the
> > > new_crtc_state encoder mask, so if the CRTC was being disabled mask
> > > would be zero and it would not have any chance to disable PSR.
> > > 
> > > So here doing for_each_intel_encoder_mask_with_psr() over the
> > > old_crtc_state encoder mask and then using the new_crtc_state to
> > > check if PSR needs to be disabled.
> 
> Are we sure that using old_crtc_state mask is safe here?
> Because currently we would be basically mixing a usage of 
> encoder from old_crtc_state mask with new_crtc_state.
> 
> If you mention a specific scenario, when this happens(i.e crtc
> is being disabled and new mask is 0) should we add a specific check 
> instructing us to use old_crtc_state mask only?
> 

This scenario were new_crtc_state is being disabled(ie encoder_mask = 0) is 
handled by intel_crtc_needs_modeset() check.
This same check will handle more complicated cases like pipe A(with PSR) now 
will drive a different port...

> Because currently you might be touching some other scenarios as
> well, that is what I'm concerned about.
> 
> 
> Stan
> 
> > > 
> > > Cc: Jouni Högander 
> > > Cc: Stanislav Lisovskiy 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 14 --
> > >  1 file changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index e6a870641cd25..98c3c8015a5c4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1863,7 +1863,9 @@ void intel_psr_pre_plane_update(struct
> > > intel_atomic_state *state,
> > >   struct intel_crtc *crtc)
> > >  {
> > >   struct drm_i915_private *i915 = to_i915(state->base.dev);
> > > - const struct intel_crtc_state *crtc_state =
> > > + const struct intel_crtc_state *old_crtc_state =
> > > + intel_atomic_get_old_crtc_state(state, crtc);
> > > + const struct intel_crtc_state *new_crtc_state =
> > >   intel_atomic_get_new_crtc_state(state, crtc);
> > >   struct intel_encoder *encoder;
> > > 
> > > @@ -1871,7 +1873,7 @@ void intel_psr_pre_plane_update(struct
> > > intel_atomic_state *state,
> > >   return;
> > > 
> > >   for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > > -  crtc_state-
> > > > uapi.encoder_mask) {
> > > +  old_crtc_state-
> > > > uapi.encoder_mask) {
> > 
> > I would add comment here explaining why using encoder mask from
> > old_crtc_state, but using new_crtc_state inside the loop. It's up to
> > you:
> > 
> > Reviewed-by: Jouni Högander 
> > 
> > >   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > >   struct intel_psr *psr = _dp->psr;
> > >   bool needs_to_disable = false;
> > > @@ -1884,10 +1886,10 @@ void intel_psr_pre_plane_update(struct
> > > intel_atomic_state *state,
> > >* - All planes will go inactive
> > >* - Changing between PSR versions
> > >*/
> > > - needs_to_disable |=
> > > intel_crtc_needs_modeset(crtc_state);
> > > - needs_to_disable |= !crtc_state->has_psr;
> > > - needs_to_disable |= !crtc_state->active_planes;
> > > - needs_to_disable |= crtc_state->has_psr2 != psr-
> > > > psr2_enabled;
> > > + needs_to_disable |=
> > > intel_crtc_needs_modeset(new_crtc_state);
> > > + needs_to_disable |= !new_crtc_state->has_psr;
> > > + needs_to_disable |= !new_crtc_state->active_planes;
> > > + needs_to_disable |= new_crtc_state->has_psr2 != psr-
> > > > psr2_enabled;
> > > 
> > >   if (psr->enabled && needs_to_disable)
> > >   intel_psr_disable_locked(intel_dp);
> > 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Ensure PSR gets disabled if no encoders in new state

[Souza, Jose]

On Thu, 2022-07-14 at 07:22 +, Hogander, Jouni wrote:
> On Wed, 2022-07-13 at 21:04 +0000, Souza, Jose wrote:
> > On Wed, 2022-07-13 at 20:58 +0000, Souza, Jose wrote:
> > > On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> > > > Currently PSR is left enabled when all planes are disabled if
> > > > there
> > > > is no attached encoder in new state. This seems to be causing
> > > > FIFO
> > > > underruns.
> > > 
> > > What is the case were there is no attached encoder and
> > > active_planes > 0?
> > 
> > Can you point to some test?
> 
> You just need to run kms_busy@basic and this triggers when dynamic
> subtest modeset is run.

Thanks, were able to reproduce the issue.

> 
> > I believe that a pipe to be enabled needs to have a enconder/port
> > attached, otherwise it will be disabled.
> 
> To my understanding pipe actually gets eventually disabled in this
> testcase as well. Before pipe is disabled we have state where planes
> are all disabled, but PSR is kept enabled. This was triggering FIFO
> underrun.

Yep that was happening but this is not the proper solution.
for_each_oldnew_intel_crtc_in_state() will iterate over all CRTCs in the 
drm_i915_private, not only the CRTC passed as parameter.

As this was already merged I have sent the fix: 
https://patchwork.freedesktop.org/series/106357/

> 
> > 
> > > > Fix this by checking if encoder exists in new crtc state and
> > > > disable
> > > > PSR if it doesn't.
> > > > 
> > > > v2: Unify disable logic with existing
> > > > 
> > > > Cc: Mika Kahola 
> > > > Reported-by: Stanislav Lisovskiy 
> > > > Signed-off-by: Jouni Högander 
> > > > Signed-off-by: Stanislav Lisovskiy  > > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_psr.c | 53 ++--
> > > > 
> > > >  1 file changed, 31 insertions(+), 22 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index e6a870641cd2..90599dd1cb1b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -1863,36 +1863,45 @@ void intel_psr_pre_plane_update(struct
> > > > intel_atomic_state *state,
> > > >  struct intel_crtc *crtc)
> > > >  {
> > > >  struct drm_i915_private *i915 = to_i915(state->base.dev);
> > > > -const struct intel_crtc_state *crtc_state =
> > > > -intel_atomic_get_new_crtc_state(state, crtc);
> > > > -struct intel_encoder *encoder;
> > > > +struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > > > +int i;
> > > > 
> > > >  if (!HAS_PSR(i915))
> > > >  return;
> > > > 
> > > > -for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > > > - crtc_state->uapi.encoder_mask) {
> > > > -struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > -struct intel_psr *psr = _dp->psr;
> > > > -bool needs_to_disable = false;
> > > > +for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> > > > +new_crtc_state, i) {
> > > > +struct intel_encoder *encoder;
> > > > +u32 old_new_encoder_mask = old_crtc_state->uapi.encoder_mask |
> > > > +new_crtc_state->uapi.encoder_mask;
> > > > 
> > > > -mutex_lock(>lock);
> > > > +for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > > > + old_new_encoder_mask) {
> > > > +struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > +struct intel_psr *psr = _dp->psr;
> > > > +bool needs_to_disable = false;
> > > > 
> > > > -/*
> > > > - * Reasons to disable:
> > > > - * - PSR disabled in new state
> > > > - * - All planes will go inactive
> > > > - * - Changing between PSR versions
> > > > - */
> > > > -needs_to_disable |= intel_crtc_needs_modeset(crtc_state);
> > > > -needs_to_disable |= !crtc_state->has_psr;
> > > > -needs_to_disable |= !crtc_state->active_planes;
> > > > -needs_to_disable |= crtc_state->has_psr2 != psr->psr2_enabled;
> > > > +mutex_lock(>lock);
> > > > 
> > > > -if (psr->enabled && needs_to_disable)
> > > > -intel_psr_disable_locked(intel_dp);
> > > > +/*
> > > > + * Reasons to disable:
> > > > + * - PSR disabled in new state
> > > > + * - All planes will go inactive
> > > > + * - Changing between PSR versions
> > > > + * - Encoder isn't present in new mask
> > > > + */
> > > > +needs_to_disable |= intel_crtc_needs_modeset(new_crtc_state);
> > > > +needs_to_disable |= !new_crtc_state->has_psr;
> > > > +needs_to_disable |= !new_crtc_state->active_planes;
> > > > +needs_to_disable |= new_crtc_state->has_psr2 != psr-
> > > > > psr2_enabled;
> > > > +needs_to_disable |= !(new_crtc_state->uapi.encoder_mask &
> > > > +  drm_encoder_mask(&(encoder)->base));
> > > > 
> > > > -mutex_unlock(>lock);
> > > > +if (psr->enabled && needs_to_disable)
> > > > +intel_psr_disable_locked(intel_dp);
> > > > +
> > > > +mutex_unlock(>lock);
> > > > +}
> > > >  }
> > > >  }
> > > > 
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Ensure PSR gets disabled if no encoders in new state

[Souza, Jose]

On Wed, 2022-07-13 at 20:58 +, Souza, Jose wrote:
> On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> > Currently PSR is left enabled when all planes are disabled if there
> > is no attached encoder in new state. This seems to be causing FIFO
> > underruns.
> 
> What is the case were there is no attached encoder and active_planes > 0?

Can you point to some test?
I believe that a pipe to be enabled needs to have a enconder/port attached, 
otherwise it will be disabled. 

> 
> > 
> > Fix this by checking if encoder exists in new crtc state and disable
> > PSR if it doesn't.
> > 
> > v2: Unify disable logic with existing
> > 
> > Cc: Mika Kahola 
> > Reported-by: Stanislav Lisovskiy 
> > Signed-off-by: Jouni Högander 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 53 ++--
> >  1 file changed, 31 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index e6a870641cd2..90599dd1cb1b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1863,36 +1863,45 @@ void intel_psr_pre_plane_update(struct 
> > intel_atomic_state *state,
> > struct intel_crtc *crtc)
> >  {
> > struct drm_i915_private *i915 = to_i915(state->base.dev);
> > -   const struct intel_crtc_state *crtc_state =
> > -   intel_atomic_get_new_crtc_state(state, crtc);
> > -   struct intel_encoder *encoder;
> > +   struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > +   int i;
> >  
> > if (!HAS_PSR(i915))
> > return;
> >  
> > -   for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > -crtc_state->uapi.encoder_mask) {
> > -   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > -   struct intel_psr *psr = _dp->psr;
> > -   bool needs_to_disable = false;
> > +   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> > +   new_crtc_state, i) {
> > +   struct intel_encoder *encoder;
> > +   u32 old_new_encoder_mask = old_crtc_state->uapi.encoder_mask |
> > +   new_crtc_state->uapi.encoder_mask;
> >  
> > -   mutex_lock(>lock);
> > +   for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > +old_new_encoder_mask) {
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +   struct intel_psr *psr = _dp->psr;
> > +   bool needs_to_disable = false;
> >  
> > -   /*
> > -* Reasons to disable:
> > -* - PSR disabled in new state
> > -* - All planes will go inactive
> > -* - Changing between PSR versions
> > -*/
> > -   needs_to_disable |= intel_crtc_needs_modeset(crtc_state);
> > -   needs_to_disable |= !crtc_state->has_psr;
> > -   needs_to_disable |= !crtc_state->active_planes;
> > -   needs_to_disable |= crtc_state->has_psr2 != psr->psr2_enabled;
> > +   mutex_lock(>lock);
> >  
> > -   if (psr->enabled && needs_to_disable)
> > -   intel_psr_disable_locked(intel_dp);
> > +   /*
> > +* Reasons to disable:
> > +* - PSR disabled in new state
> > +* - All planes will go inactive
> > +* - Changing between PSR versions
> > +* - Encoder isn't present in new mask
> > +*/
> > +   needs_to_disable |= 
> > intel_crtc_needs_modeset(new_crtc_state);
> > +   needs_to_disable |= !new_crtc_state->has_psr;
> > +   needs_to_disable |= !new_crtc_state->active_planes;
> > +   needs_to_disable |= new_crtc_state->has_psr2 != 
> > psr->psr2_enabled;
> > +   needs_to_disable |= !(new_crtc_state->uapi.encoder_mask 
> > &
> > + 
> > drm_encoder_mask(&(encoder)->base));
> >  
> > -   mutex_unlock(>lock);
> > +   if (psr->enabled && needs_to_disable)
> > +   intel_psr_disable_locked(intel_dp);
> > +
> > +   mutex_unlock(>lock);
> > +   }
> > }
> >  }
> >  
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Ensure PSR gets disabled if no encoders in new state

[Souza, Jose]

On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> Currently PSR is left enabled when all planes are disabled if there
> is no attached encoder in new state. This seems to be causing FIFO
> underruns.

What is the case were there is no attached encoder and active_planes > 0?

> 
> Fix this by checking if encoder exists in new crtc state and disable
> PSR if it doesn't.
> 
> v2: Unify disable logic with existing
> 
> Cc: Mika Kahola 
> Reported-by: Stanislav Lisovskiy 
> Signed-off-by: Jouni Högander 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 53 ++--
>  1 file changed, 31 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index e6a870641cd2..90599dd1cb1b 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1863,36 +1863,45 @@ void intel_psr_pre_plane_update(struct 
> intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
> - const struct intel_crtc_state *crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> - struct intel_encoder *encoder;
> + struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> + int i;
>  
>   if (!HAS_PSR(i915))
>   return;
>  
> - for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> -  crtc_state->uapi.encoder_mask) {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - struct intel_psr *psr = _dp->psr;
> - bool needs_to_disable = false;
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + struct intel_encoder *encoder;
> + u32 old_new_encoder_mask = old_crtc_state->uapi.encoder_mask |
> + new_crtc_state->uapi.encoder_mask;
>  
> - mutex_lock(>lock);
> + for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> +  old_new_encoder_mask) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_psr *psr = _dp->psr;
> + bool needs_to_disable = false;
>  
> - /*
> -  * Reasons to disable:
> -  * - PSR disabled in new state
> -  * - All planes will go inactive
> -  * - Changing between PSR versions
> -  */
> - needs_to_disable |= intel_crtc_needs_modeset(crtc_state);
> - needs_to_disable |= !crtc_state->has_psr;
> - needs_to_disable |= !crtc_state->active_planes;
> - needs_to_disable |= crtc_state->has_psr2 != psr->psr2_enabled;
> + mutex_lock(>lock);
>  
> - if (psr->enabled && needs_to_disable)
> - intel_psr_disable_locked(intel_dp);
> + /*
> +  * Reasons to disable:
> +  * - PSR disabled in new state
> +  * - All planes will go inactive
> +  * - Changing between PSR versions
> +  * - Encoder isn't present in new mask
> +  */
> + needs_to_disable |= 
> intel_crtc_needs_modeset(new_crtc_state);
> + needs_to_disable |= !new_crtc_state->has_psr;
> + needs_to_disable |= !new_crtc_state->active_planes;
> + needs_to_disable |= new_crtc_state->has_psr2 != 
> psr->psr2_enabled;
> + needs_to_disable |= !(new_crtc_state->uapi.encoder_mask 
> &
> +   
> drm_encoder_mask(&(encoder)->base));
>  
> - mutex_unlock(>lock);
> + if (psr->enabled && needs_to_disable)
> + intel_psr_disable_locked(intel_dp);
> +
> + mutex_unlock(>lock);
> + }
>   }
>  }
>  

Re: [Intel-gfx] [PATCH RESEND] drm: i915: fix a possible refcount leak in intel_dp_add_mst_connector()

[Souza, Jose]

Hi Hangyu

Don't know why but our CI still did not caught this patch.
Maybe it is because intel-gfx@lists.freedesktop.org needs to be in the "to" 
list, try that in future patches.

Anyways I have resend it and it is properly behaving now.
https://patchwork.freedesktop.org/series/105601/

After CI results I will push this for you.

On Fri, 2022-06-24 at 10:28 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take
> care of proper free. So it is necessary to drop the refcount of port
> before intel_connector_free.
> 
> Fixes: 091a4f91942a ("drm/i915: Handle drm-layer errors in 
> intel_dp_add_mst_connector")
> Signed-off-by: Hangyu Hua 
> Reviewed-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 061b277e5ce7..14d2a64193b2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -839,6 +839,7 @@ static struct drm_connector 
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>   ret = drm_connector_init(dev, connector, _dp_mst_connector_funcs,
>DRM_MODE_CONNECTOR_DisplayPort);
>   if (ret) {
> + drm_dp_mst_put_port_malloc(port);
>   intel_connector_free(intel_connector);
>   return NULL;
>   }

Re: [Intel-gfx] [PATCH] drm/i915: Fix error code in icl_compute_combo_phy_dpll()

[Souza, Jose]

On Fri, 2022-06-24 at 09:39 +0300, Dan Carpenter wrote:
> This function is supposed to return zero or negative error codes but it
> accidentally returns true on failure.

Reviewed-by: José Roberto de Souza 

> 
> Fixes: 92a020747d6c ("drm/i915: Split shared dpll .get_dplls() into compute 
> and get phases")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 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 ddae7e42ac46..118598c9a809 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -3184,7 +3184,7 @@ static int icl_compute_combo_phy_dpll(struct 
> intel_atomic_state *state,
>   struct icl_port_dpll *port_dpll =
>   _state->icl_port_dplls[ICL_PORT_DPLL_DEFAULT];
>   struct skl_wrpll_params pll_params = {};
> - bool ret;
> + int ret;
>  
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) ||
>   intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))

Re: [Intel-gfx] [PATCH] drm/i915: Call i915_gem_suspend() only after display is turned off

[Souza, Jose]

On Wed, 2022-06-22 at 15:19 -0700, Matt Roper wrote:
> On Tue, Jun 21, 2022 at 10:03:04AM -0700, Souza, Jose wrote:
> > On Fri, 2022-06-17 at 12:28 -0700, Matt Roper wrote:
> > > On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> > > > Gem buffers could still be in use by display after i915_gem_suspend()
> > > > is executed so there is chances that i915_gem_flush_free_objects()
> > > > will be being executed at the same time that
> > > > intel_runtime_pm_driver_release() is executed printing warnings about
> > > > wakerefs will being held.
> > > 
> > > By the same logic do we need to adjust i915_driver_remove() too?
> > 
> > Nope, all display buffers are freed in i915_driver_unregister() call chain:
> > 
> > 
> > i915_driver_remove()
> > i915_driver_unregister()
> > intel_display_driver_unregister()
> > drm_atomic_helper_shutdown()
> > i915_gem_suspend()
> > i915_gem_drain_freed_objects()
> > 
> > 
> > Only FBC compressed framebuffer is freed after that but that will not cause 
> > any warnings as it is allocated from stolen memory.
> 
> Okay sounds good; thanks for checking.
> 
> I'm still having a bit of trouble understanding your description of the
> issue in the commit message though:
> 
> "...so there is chances that i915_gem_flush_free_objects() will
> be being executed at the same time that
> intel_runtime_pm_driver_release()..."
> 
> I'm not super familiar with the driver teardown paths, or the memory
> management cleanup details.  Intuitively it makes sense that we should
> clean up memory management (GEM) only after we've torn down display so
> that all objects that were used by framebuffers are out of circulation.
> But from a cursory view, it looks like i915_gem_suspend() is mostly
> concerned with quiescing the GT and cleaning up PPGTT (which doesn't
> impact display since all of its buffers are in the GGTT).
> 
> Is the problem arising from i915->mm.free_work still doing asynchronous
> work to actually release the unused objects at the same time we're
> tearing down runtime PM later?  If so does swapping the order of the
> gem_suspend and display disable here actually prevent that from
> happening or does it just make the race less likely by helping some
> objects free up earlier?

So when the last reference of a gem object is removed it is added to the 
mm.free_list list and mm.free_work is queued to actually free the object.
i915_gem_drain_freed_objects() flushes the mm.free_work.

If any other gem object has its last reference removed after 
i915_gem_suspend()/i915_gem_drain_freed_objects() the warning in
intel_runtime_pm_driver_release() can happen as the mm.free_work could be 
running at the same time.

But when pci_driver.remove() is called, probably all file descriptors attached 
to this device have been closed and the functions called after
i915_gem_suspend() will not free any gem object, so I don't believe we will 
have any more warnings.

> 
> 
> Matt
> 
> > 
> > > 
> > > 
> > > Matt
> > > 
> > > > 
> > > > So here only calling i915_gem_suspend() and by consequence
> > > > i915_gem_drain_freed_objects() only after display is down making
> > > > sure all buffers are freed.
> > > > 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_driver.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index d26dcca7e654a..4227675dd1cfe 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -1067,8 +1067,6 @@ void i915_driver_shutdown(struct drm_i915_private 
> > > > *i915)
> > > > intel_runtime_pm_disable(>runtime_pm);
> > > > intel_power_domains_disable(i915);
> > > >  
> > > > -   i915_gem_suspend(i915);
> > > > -
> > > > if (HAS_DISPLAY(i915)) {
> > > > drm_kms_helper_poll_disable(>drm);
> > > >  
> > > > @@ -1085,6 +1083,8 @@ void i915_driver_shutdown(struct drm_i915_private 
> > > > *i915)
> > > >  
> > > > intel_dmc_ucode_suspend(i915);
> > > >  
> > > > +   i915_gem_suspend(i915);
> > > > +
> > > > /*
> > > >  * The only requirement is to reboot with display DC states 
> > > > disabled,
> > > >  * for now leaving all display power wells in the INIT power 
> > > > domain
> > > > -- 
> > > > 2.36.1
> > > > 
> > > 
> > 
> 

Re: [Intel-gfx] [PATCH] drm: i915: fix a possible refcount leak in intel_dp_add_mst_connector()

[Souza, Jose]

On Thu, 2022-06-23 at 13:44 +, Souza, Jose wrote:
> On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> > If drm_connector_init fails, intel_connector_free will be called to take 
> > care of proper free. So it is necessary to drop the refcount of port 
> > before intel_connector_free.
> 
> Reviewed-by: José Roberto de Souza 

Don't know why but our CI did not caught your patch.
Can you please resend it with my Reviewed-by to intel-gfx@lists.freedesktop.org 
?

> 
> > 
> > Fixes: 091a4f91942a ("drm/i915: Handle drm-layer errors in 
> > intel_dp_add_mst_connector")
> > Signed-off-by: Hangyu Hua 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index e30e698aa684..f7d46ea3afb9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -841,6 +841,7 @@ static struct drm_connector 
> > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > ret = drm_connector_init(dev, connector, _dp_mst_connector_funcs,
> >  DRM_MODE_CONNECTOR_DisplayPort);
> > if (ret) {
> > +   drm_dp_mst_put_port_malloc(port);
> > intel_connector_free(intel_connector);
> > return NULL;
> > }
> 

Re: [Intel-gfx] [PATCH] drm: i915: fix a possible refcount leak in intel_dp_add_mst_connector()

[Souza, Jose]

On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take 
> care of proper free. So it is necessary to drop the refcount of port 
> before intel_connector_free.

Reviewed-by: José Roberto de Souza 

> 
> Fixes: 091a4f91942a ("drm/i915: Handle drm-layer errors in 
> intel_dp_add_mst_connector")
> Signed-off-by: Hangyu Hua 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index e30e698aa684..f7d46ea3afb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -841,6 +841,7 @@ static struct drm_connector 
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>   ret = drm_connector_init(dev, connector, _dp_mst_connector_funcs,
>DRM_MODE_CONNECTOR_DisplayPort);
>   if (ret) {
> + drm_dp_mst_put_port_malloc(port);
>   intel_connector_free(intel_connector);
>   return NULL;
>   }

Re: [Intel-gfx] [PATCH] drm/i915: Call i915_gem_suspend() only after display is turned off

[Souza, Jose]

On Fri, 2022-06-17 at 12:28 -0700, Matt Roper wrote:
> On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> > Gem buffers could still be in use by display after i915_gem_suspend()
> > is executed so there is chances that i915_gem_flush_free_objects()
> > will be being executed at the same time that
> > intel_runtime_pm_driver_release() is executed printing warnings about
> > wakerefs will being held.
> 
> By the same logic do we need to adjust i915_driver_remove() too?

Nope, all display buffers are freed in i915_driver_unregister() call chain:


i915_driver_remove()
i915_driver_unregister()
intel_display_driver_unregister()
drm_atomic_helper_shutdown()
i915_gem_suspend()
i915_gem_drain_freed_objects()


Only FBC compressed framebuffer is freed after that but that will not cause any 
warnings as it is allocated from stolen memory.

> 
> 
> Matt
> 
> > 
> > So here only calling i915_gem_suspend() and by consequence
> > i915_gem_drain_freed_objects() only after display is down making
> > sure all buffers are freed.
> > 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_driver.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index d26dcca7e654a..4227675dd1cfe 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1067,8 +1067,6 @@ void i915_driver_shutdown(struct drm_i915_private 
> > *i915)
> > intel_runtime_pm_disable(>runtime_pm);
> > intel_power_domains_disable(i915);
> >  
> > -   i915_gem_suspend(i915);
> > -
> > if (HAS_DISPLAY(i915)) {
> > drm_kms_helper_poll_disable(>drm);
> >  
> > @@ -1085,6 +1083,8 @@ void i915_driver_shutdown(struct drm_i915_private 
> > *i915)
> >  
> > intel_dmc_ucode_suspend(i915);
> >  
> > +   i915_gem_suspend(i915);
> > +
> > /*
> >  * The only requirement is to reboot with display DC states disabled,
> >  * for now leaving all display power wells in the INIT power domain
> > -- 
> > 2.36.1
> > 
> 

Re: [Intel-gfx] [PATCH] drm/i915/pvc: Add recommended MMIO setting

[Souza, Jose]

On Mon, 2022-06-13 at 09:53 -0700, Matt Roper wrote:
> As with past platforms, the bspec's performance tuning guide provides
> recommended MMIO settings.  Although not technically "workarounds" we
> apply these through the workaround framework to ensure that they're
> re-applied at the proper times (e.g., on engine resets) and that any
> conflicts with real workarounds are flagged.

Reviewed-by: José Roberto de Souza 

> 
> Bspec: 72161
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 226557018037..07ef111947b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -981,6 +981,11 @@
>  #define XEHP_L3SCQREG7   _MMIO(0xb188)
>  #define   BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
>  
> +#define XEHPC_L3SCRUB_MMIO(0xb18c)
> +#define   SCRUB_CL_DWNGRADE_SHARED   REG_BIT(12)
> +#define   SCRUB_RATE_PER_BANK_MASK   REG_GENMASK(2, 0)
> +#define   SCRUB_RATE_4B_PER_CLK  
> REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
> +
>  #define L3SQCREG1_CCS0   _MMIO(0xb200)
>  #define   FLUSHALLNONCOH REG_BIT(5)
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 1e982ac931dc..c4af51144216 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2679,6 +2679,15 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>  {
>   struct drm_i915_private *i915 = engine->i915;
>  
> + if (IS_PONTEVECCHIO(i915)) {
> + /*
> +  * The following is not actually a "workaround" but rather
> +  * a recommended tuning setting documented in the bspec's
> +  * performance guide section.
> +  */
> + wa_write(wal, XEHPC_L3SCRUB, SCRUB_CL_DWNGRADE_SHARED | 
> SCRUB_RATE_4B_PER_CLK);
> + }
> +
>   if (IS_XEHPSDV(i915)) {
>   /* Wa_1409954639 */
>   wa_masked_en(wal,

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix handling of enable_psr parameter

[Souza, Jose]

On Thu, 2022-06-09 at 17:01 +, Patchwork wrote:
Patch Details
Series: drm/i915/display: Fix handling of enable_psr parameter
URL:https://patchwork.freedesktop.org/series/104907/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/index.html
CI Bug Log - changes from CI_DRM_11740_full -> Patchwork_104907v1_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_104907v1_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104907v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (13 -> 13)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_capture@pi@vecs0:

 *   shard-skl: NOTRUN -> 
INCOMPLETE
  *   igt@perf_pmu@busy-accuracy-98@vcs1:

 *   shard-kbl: 
PASS
 -> 
INCOMPLETE

Those failures are not related.

Patch pushed, thanks for the review Jouni.

Known issues

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

CI changes
Possible fixes

  *   boot:
 *   shard-glk: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 (i915#4392) -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add function to check if headless sku

[Souza, Jose]

On Tue, 2022-06-07 at 13:05 +, Hogander, Jouni wrote:
> On Tue, 2022-06-07 at 10:36 +0300, Jani Nikula wrote:
> > On Mon, 06 Jun 2022, "Souza, Jose"  wrote:
> > > On Mon, 2022-06-06 at 11:16 +0300, Jani Nikula wrote:
> > > > On Mon, 06 Jun 2022, "Hogander, Jouni" 
> > > > wrote:
> > > > > On Fri, 2022-06-03 at 16:32 +, Souza, Jose wrote:
> > > > > > On Fri, 2022-06-03 at 13:14 +, Hogander, Jouni wrote:
> > > > > > > On Fri, 2022-06-03 at 15:43 +0300, Jani Nikula wrote:
> > > > > > > > On Fri, 03 Jun 2022, Jouni Högander <
> > > > > > > > jouni.hogan...@intel.com>
> > > > > > > > wrote:
> > > > > > > > > Export headless sku bit (bit 13) from opregion->header-
> > > > > > > > > > pcon as
> > > > > > > > > an
> > > > > > > > > interface to check if our device is headless
> > > > > > > > > configuration.
> > > > > > > > > 
> > > > > > > > > Bspec: 53441
> > > > > > > > > Signed-off-by: Jouni Högander  > > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/i915/display/intel_opregion.c | 12
> > > > > > > > > 
> > > > > > > > >  drivers/gpu/drm/i915/display/intel_opregion.h |  7
> > > > > > > > > +++
> > > > > > > > >  2 files changed, 19 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git
> > > > > > > > > a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > > > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > > > index f31e8c3f8ce0..eab3f2e6b786 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > > > @@ -53,6 +53,8 @@
> > > > > > > > >  #define MBOX_ASLE_EXTBIT(4)/* Mailbox #5 */
> > > > > > > > >  #define MBOX_BACKLIGHTBIT(5)/* Mailbox #2
> > > > > > > > > (valid from v3.x) */
> > > > > > > > > 
> > > > > > > > > +#define PCON_HEADLESS_SKUBIT(13)
> > > > > > > > 
> > > > > > > > Here we go again.
> > > > > > > > 
> > > > > > > > What does headless mean here? The spec does not say. Does
> > > > > > > > it have
> > > > > > > > display hardware? Apparently yes, since otherwise we
> > > > > > > > wouldn't be
> > > > > > > > here.
> > > > > > > 
> > > > > > > This is for hybrid setup with several display hw and the
> > > > > > > panel wont
> > > > > > > be
> > > > > > > connected into device driven by i915 driver.
> > > > > > > 
> > > > > > > > We have INTEL_DISPLAY_ENABLED() which should do the right
> > > > > > > > thing
> > > > > > > > when
> > > > > > > > you
> > > > > > > > do have display hardware and have done output setup etc.
> > > > > > > > but want
> > > > > > > > to
> > > > > > > > force them disconnected, i.e. you take the hardware over
> > > > > > > > properly,
> > > > > > > > but
> > > > > > > > put it to sleep for power savings.
> > > > > > > > 
> > > > > > > > Maybe we should bolt this opregion check in that macro?
> > > > > > > > 
> > > > > > > > Maybe we need to use INTEL_DISPLAY_ENABLED() also to
> > > > > > > > prevent
> > > > > > > > polling.
> > > > > > > 
> > > > > > > Thank you for pointing this out. HAS_DISPLAY I already
> > > > > > > notice and
> > > > > > > it's
> > > > > > > not suitable for what we want here. I think b

Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add function to check if headless sku

[Souza, Jose]

On Mon, 2022-06-06 at 11:16 +0300, Jani Nikula wrote:
> On Mon, 06 Jun 2022, "Hogander, Jouni"  wrote:
> > On Fri, 2022-06-03 at 16:32 +, Souza, Jose wrote:
> > > On Fri, 2022-06-03 at 13:14 +, Hogander, Jouni wrote:
> > > > On Fri, 2022-06-03 at 15:43 +0300, Jani Nikula wrote:
> > > > > On Fri, 03 Jun 2022, Jouni Högander 
> > > > > wrote:
> > > > > > Export headless sku bit (bit 13) from opregion->header->pcon as
> > > > > > an
> > > > > > interface to check if our device is headless configuration.
> > > > > > 
> > > > > > Bspec: 53441
> > > > > > Signed-off-by: Jouni Högander 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_opregion.c | 12
> > > > > > 
> > > > > >  drivers/gpu/drm/i915/display/intel_opregion.h |  7 +++
> > > > > >  2 files changed, 19 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > index f31e8c3f8ce0..eab3f2e6b786 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > @@ -53,6 +53,8 @@
> > > > > >  #define MBOX_ASLE_EXTBIT(4)/* Mailbox #5 */
> > > > > >  #define MBOX_BACKLIGHTBIT(5)/* Mailbox #2
> > > > > > (valid from v3.x) */
> > > > > > 
> > > > > > +#define PCON_HEADLESS_SKUBIT(13)
> > > > > 
> > > > > Here we go again.
> > > > > 
> > > > > What does headless mean here? The spec does not say. Does it have
> > > > > display hardware? Apparently yes, since otherwise we wouldn't be
> > > > > here.
> > > > 
> > > > This is for hybrid setup with several display hw and the panel wont
> > > > be
> > > > connected into device driven by i915 driver.
> > > > 
> > > > > We have INTEL_DISPLAY_ENABLED() which should do the right thing
> > > > > when
> > > > > you
> > > > > do have display hardware and have done output setup etc. but want
> > > > > to
> > > > > force them disconnected, i.e. you take the hardware over
> > > > > properly,
> > > > > but
> > > > > put it to sleep for power savings.
> > > > > 
> > > > > Maybe we should bolt this opregion check in that macro?
> > > > > 
> > > > > Maybe we need to use INTEL_DISPLAY_ENABLED() also to prevent
> > > > > polling.
> > > > 
> > > > Thank you for pointing this out. HAS_DISPLAY I already notice and
> > > > it's
> > > > not suitable for what we want here. I think bolting this check into
> > > > INTEL_DISPLAY_ENABLED as you suggested is enough. That will prevent
> > > > waking up the hw into D0 state for polling.
> > > 
> > > A headless sku should not have any DDI ports enabled, much easier
> > > check for that.
> > 
> > Could you please clarify this a bit? What exactly you are thinking
> > should be checked? Aren't DDI port also disabled when non-headless
> > setup is in runtime suspend?
> 
> I also think "headless" and "DDI ports enabled" need clarification. They
> are overloaded terms.

In a properly setup headless sku, VBT should have all ports marked as disabled.

intel_ddi_init() {
...

if (!init_dp && !init_hdmi) {
drm_dbg_kms(_priv->drm,
"VBT says port %c is not DVI/HDMI/DP compatible, 
respect it\n",
port_name(port));
return;
}


All DDI should return earlier in the above.
So you can use the number of enabled connectors to know if it is a headless sku 
or not.

So you can skip the pooling in case there is no connectors.

> 
> Seems to me the use case here could be the same as
> INTEL_DISPLAY_ENABLED(), and that could benefit from polling disable.
> 
> BR,
> Jani.
> 
> 
> >  
> > > 
> > > > > I certainly would not want to add another mode that's separate
> > > > > from
> > > > > HAS_DISPLAY() and INTEL_DISPLAY_ENABLED().
> > > > 
> > > > No need for this. I think we can

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/fbc: Do not apply WA 22014263786 to DG2 (rev2)

[Souza, Jose]

Hi Lakshmi

Can you please help with this failures?
Current code is only doing a small change that would only affect DG2.

On Fri, 2022-06-03 at 20:09 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/fbc: Do not apply WA 22014263786 to DG2 (rev2)
URL:https://patchwork.freedesktop.org/series/104678/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104678v2/index.html
CI Bug Log - changes from CI_DRM_11726 -> Patchwork_104678v2
Summary

FAILURE

Serious unknown changes coming with Patchwork_104678v2 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104678v2, 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_104678v2/index.html

Participating hosts (43 -> 44)

Additional (2): bat-adln-1 fi-kbl-x1275
Missing (1): fi-rkl-11600

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_addfb_basic@unused-pitches:
 *   fi-kbl-soraka: 
PASS
 -> 
INCOMPLETE

Suppressed

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

  *   igt@i915_selftest@live@hangcheck:

 *   {fi-ehl-2}: 
PASS
 -> 
INCOMPLETE
  *   igt@kms_frontbuffer_tracking@basic:

 *   {bat-adln-1}: NOTRUN -> 
SKIP
 +19 similar issues

Known issues

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

IGT changes
Issues hit

  *   igt@gem_huc_copy@huc-copy:

 *   fi-kbl-x1275: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#2190)
  *   igt@gem_lmem_swapping@verify-random:

 *   fi-kbl-x1275: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#4613) +3 similar 
issues
  *   igt@i915_selftest@live@hangcheck:

 *   bat-dg1-5: 
PASS
 -> 
DMESG-FAIL
 (i915#4494 / 
i915#4957)

 *   bat-dg1-6: 
PASS
 -> 
DMESG-FAIL
 (i915#4494 / 
i915#4957)

  *   igt@i915_selftest@live@requests:

 *   fi-blb-e6850: 
PASS
 -> 
DMESG-FAIL
 (i915#4528)
  *   igt@i915_selftest@live@reset:

 *   bat-adlp-4: 
PASS
 -> 
DMESG-FAIL
 (i915#4983)
  *   igt@kms_chamelium@dp-hpd-fast:

 *   fi-kbl-x1275: NOTRUN -> 
SKIP
 (fdo#109271 / 
fdo#111827) +8 similar 
issues
  *   igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:

 *   fi-kbl-x1275: NOTRUN -> 
SKIP
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add function to check if headless sku

[Souza, Jose]

On Fri, 2022-06-03 at 13:14 +, Hogander, Jouni wrote:
> On Fri, 2022-06-03 at 15:43 +0300, Jani Nikula wrote:
> > On Fri, 03 Jun 2022, Jouni Högander  wrote:
> > > Export headless sku bit (bit 13) from opregion->header->pcon as an
> > > interface to check if our device is headless configuration.
> > > 
> > > Bspec: 53441
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_opregion.c | 12 
> > >  drivers/gpu/drm/i915/display/intel_opregion.h |  7 +++
> > >  2 files changed, 19 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > index f31e8c3f8ce0..eab3f2e6b786 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > @@ -53,6 +53,8 @@
> > >  #define MBOX_ASLE_EXTBIT(4)  /* Mailbox #5 */
> > >  #define MBOX_BACKLIGHT   BIT(5)  /* Mailbox #2
> > > (valid from v3.x) */
> > >  
> > > +#define PCON_HEADLESS_SKUBIT(13)
> > 
> > Here we go again.
> > 
> > What does headless mean here? The spec does not say. Does it have
> > display hardware? Apparently yes, since otherwise we wouldn't be
> > here.
> 
> This is for hybrid setup with several display hw and the panel wont be
> connected into device driven by i915 driver.
> 
> > We have INTEL_DISPLAY_ENABLED() which should do the right thing when
> > you
> > do have display hardware and have done output setup etc. but want to
> > force them disconnected, i.e. you take the hardware over properly,
> > but
> > put it to sleep for power savings.
> > 
> > Maybe we should bolt this opregion check in that macro?
> > 
> > Maybe we need to use INTEL_DISPLAY_ENABLED() also to prevent polling.
> 
> Thank you for pointing this out. HAS_DISPLAY I already notice and it's
> not suitable for what we want here. I think bolting this check into
> INTEL_DISPLAY_ENABLED as you suggested is enough. That will prevent
> waking up the hw into D0 state for polling.

A headless sku should not have any DDI ports enabled, much easier check for 
that.

> 
> > 
> > I certainly would not want to add another mode that's separate from
> > HAS_DISPLAY() and INTEL_DISPLAY_ENABLED().
> 
> No need for this. I think we can go with INTEL_DISPLAY_ENABLED.
> > 
> > > +
> > >  struct opregion_header {
> > >   u8 signature[16];
> > >   u32 size;
> > > @@ -1135,6 +1137,16 @@ struct edid *intel_opregion_get_edid(struct
> > > intel_connector *intel_connector)
> > >   return new_edid;
> > >  }
> > >  
> > > +bool intel_opregion_headless_sku(struct drm_i915_private *i915)
> > > +{
> > > + struct intel_opregion *opregion = >opregion;
> > > +
> > > + if (!opregion->header)
> > > + return false;
> > > +
> > > + return opregion->header->pcon & PCON_HEADLESS_SKU;
> > 
> > We should probably start checking for opregion version for this stuff
> > too.
> > 
> 
> Yes, I will do this change.
> 
> > 
> > BR,
> > Jani.
> > 
> > > +}
> > > +
> > >  void intel_opregion_register(struct drm_i915_private *i915)
> > >  {
> > >   struct intel_opregion *opregion = >opregion;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
> > > b/drivers/gpu/drm/i915/display/intel_opregion.h
> > > index 82cc0ba34af7..5ad96e1d8278 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_opregion.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
> > > @@ -76,6 +76,8 @@ int intel_opregion_notify_adapter(struct
> > > drm_i915_private *dev_priv,
> > >  int intel_opregion_get_panel_type(struct drm_i915_private
> > > *dev_priv);
> > >  struct edid *intel_opregion_get_edid(struct intel_connector
> > > *connector);
> > >  
> > > +bool intel_opregion_headless_sku(struct drm_i915_private *i915);
> > > +
> > >  #else /* CONFIG_ACPI*/
> > >  
> > >  static inline int intel_opregion_setup(struct drm_i915_private
> > > *dev_priv)
> > > @@ -127,6 +129,11 @@ intel_opregion_get_edid(struct intel_connector
> > > *connector)
> > >   return NULL;
> > >  }
> > >  
> > > +bool intel_opregion_headless_sku(struct drm_i915_private *i915)
> > > +{
> > > + return false;
> > > +}
> > > +
> > >  #endif /* CONFIG_ACPI */
> > >  
> > >  #endif
> 

Re: [Intel-gfx] [PATCH] drm/i915/pvc: GuC depriv applies to PVC

[Souza, Jose]

On Thu, 2022-06-02 at 16:30 -0700, Matt Roper wrote:
> We missed this setting in the initial device info patch's definition of
> XE_HPC_FEATURES.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 047a6e326031..a5a1a7647320 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1089,6 +1089,7 @@ static const struct intel_device_info ats_m_info = {
>   XE_HP_FEATURES, \
>   .dma_mask_size = 52, \
>   .has_3d_pipeline = 0, \
> + .has_guc_deprivilege = 1, \
>   .has_l3_ccs_read = 1, \
>   .has_one_eu_per_fuse_bit = 1
>  

Re: [Intel-gfx] [PATCH] drm/i915: Add extra registers to GPU error dump

[Souza, Jose]

On Wed, 2022-06-01 at 14:06 -0700, Matt Roper wrote:
> From: Stuart Summers 
> 
> Our internal teams have identified a few additional engine registers
> that are worth inspecting in error state dumps during development &
> debug.  Let's capture and print them as part of our error dump.
> 
> For simplicity we'll just dump these registers on gen11 and beyond.
> Most of these registers have existed since earlier platforms (e.g., gen6
> or gen7) but were initially introduced only for a subset of the
> platforms' engines; gen11 seems to be where they became available on all
> engines.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Stuart Summers 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_regs.h |  5 +
>  drivers/gpu/drm/i915/i915_gpu_error.c   | 19 +++
>  drivers/gpu/drm/i915/i915_gpu_error.h   |  7 +++
>  3 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> index 44de10cf7837..889f0df3940b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> @@ -8,6 +8,7 @@
>  
>  #include "i915_reg_defs.h"
>  
> +#define RING_EXCC(base)  _MMIO((base) + 0x28)
>  #define RING_TAIL(base)  _MMIO((base) + 0x30)
>  #define   TAIL_ADDR  0x0018
>  #define RING_HEAD(base)  _MMIO((base) + 0x34)
> @@ -133,6 +134,8 @@
>   (REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, (dst) << 1) | \
>REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, (src) << 1))
>  
> +#define RING_CSCMDOP(base)   _MMIO((base) + 0x20c)
> +
>  /*
>   * CMD_CCTL read/write fields take a MOCS value and _not_ a table index.
>   * The lsb of each can be considered a separate enabling bit for encryption.
> @@ -149,6 +152,7 @@
>REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
>  
>  #define RING_PREDICATE_RESULT(base)  _MMIO((base) + 0x3b8) /* gen12+ 
> */
> +
>  #define MI_PREDICATE_RESULT_2(base)  _MMIO((base) + 0x3bc)
>  #define   LOWER_SLICE_ENABLED(1 << 0)
>  #define   LOWER_SLICE_DISABLED   (0 << 0)
> @@ -172,6 +176,7 @@
>  #defineCTX_CTRL_ENGINE_CTX_SAVE_INHIBIT  REG_BIT(2)
>  #defineCTX_CTRL_INHIBIT_SYN_CTX_SWITCH   REG_BIT(3)
>  #defineGEN12_CTX_CTRL_OAR_CONTEXT_ENABLE REG_BIT(8)
> +#define RING_CTX_SR_CTL(base)_MMIO((base) + 0x244)
>  #define RING_SEMA_WAIT_POLL(base)_MMIO((base) + 0x24c)
>  #define GEN8_RING_PDP_UDW(base, n)   _MMIO((base) + 0x270 + (n) * 8 
> + 4)
>  #define GEN8_RING_PDP_LDW(base, n)   _MMIO((base) + 0x270 + (n) * 8)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 0512c66fa4f3..bff8a111424a 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -581,6 +581,15 @@ static void error_print_engine(struct 
> drm_i915_error_state_buf *m,
>   err_printf(m, "  RC PSMI: 0x%08x\n", ee->rc_psmi);
>   err_printf(m, "  FAULT_REG: 0x%08x\n", ee->fault_reg);
>   }
> + if (GRAPHICS_VER(m->i915) >= 11) {
> + err_printf(m, "  NOPID: 0x%08x\n", ee->nopid);
> + err_printf(m, "  EXCC: 0x%08x\n", ee->excc);
> + err_printf(m, "  CMD_CCTL: 0x%08x\n", ee->cmd_cctl);
> + err_printf(m, "  CSCMDOP: 0x%08x\n", ee->cscmdop);
> + err_printf(m, "  CTX_SR_CTL: 0x%08x\n", ee->ctx_sr_ctl);
> + err_printf(m, "  DMA_FADDR_HI: 0x%08x\n", ee->dma_faddr_hi);
> + err_printf(m, "  DMA_FADDR_LO: 0x%08x\n", ee->dma_faddr_lo);
> + }
>   if (HAS_PPGTT(m->i915)) {
>   err_printf(m, "  GFX_MODE: 0x%08x\n", ee->vm_info.gfx_mode);
>  
> @@ -1224,6 +1233,16 @@ static void engine_record_registers(struct 
> intel_engine_coredump *ee)
>   ee->ipehr = ENGINE_READ(engine, IPEHR);
>   }
>  
> + if (GRAPHICS_VER(i915) >= 11) {
> + ee->cmd_cctl = ENGINE_READ(engine, RING_CMD_CCTL);
> + ee->cscmdop = ENGINE_READ(engine, RING_CSCMDOP);
> + ee->ctx_sr_ctl = ENGINE_READ(engine, RING_CTX_SR_CTL);
> + ee->dma_faddr_hi = ENGINE_READ(engine, RING_DMA_FADD_UDW);
> + ee->dma_faddr_lo = ENGINE_READ(engine, RING_DMA_FADD);
> + ee->nopid = ENGINE_READ(engine, RING_NOPID);
> + ee->excc = ENGINE_READ(engine, RING_EXCC);
> + }
> +
>   intel_engine_get_instdone(engine, >instdone);
>  
>   ee->instpm = ENGINE_READ(engine, RING_INSTPM);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index a611abacd9c2..55a143b92d10 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ 

Re: [Intel-gfx] [RFC PATCH] drm/i915: Debugfs statistics interface for psr

[Souza, Jose]

On Thu, 2022-05-19 at 12:17 +, Hogander, Jouni wrote:
> On Wed, 2022-05-18 at 20:00 +0000, Souza, Jose wrote:
> > On Wed, 2022-05-18 at 10:45 +0300, Jouni Högander wrote:
> > > Currently there is no mean to get understanding how psr is
> > > utilized.
> > > E.g. How much psr is actually enabled or how often driver falls
> > > back
> > > to full update.
> > 
> > But with this information what can you do?
> 
> If you are doing pnp analysis for use cases with PSR2 capable panel.
> Having such information telling you how PSR is utilized is valuable to
> make your statement if there is room for optimization.
> 
> or
> 
> you are doing power measurement follow-up and facing regression in
> certain use case. You can check possible changes in PSR utilization
> and make your statement if it's involved or not. E.g. recent changes to
> fall back to full update if area calculation fails or the one where
> using continuous full update instead of psr disable would have been
> visible in these statistics.

The goal is to get rid of all full frame update cases, knowing that it have 10% 
of full updates do not adds anything.

About PNP this information is not helpful, most of the power saved with PSR is 
when display is idle and it goes to DC5/DC6 states that can be measured
in i915_dmc_info and by pkg10 residency from the SOC.

Other thing is this only covers Tigerlake and Alderlake-P, I guess it would 
only print the number of vblanks for older platforms.

> 
> Addition to these I have been thinking extending this to gather
> statistics or history over used update area as well. Considering recent
> bugs we have fixed in psr code: As a first step you need to start
> instrumenting psr code and ask reporter to take trace with your
> instrumentation. Instead we could have some statistic or even last SU
> areas when CRC error is triggered and make these available in logs or
> via some debugfs interface.
> 
> I'm pretty sure we will revisit psr code in the future and introduce
> new bugs and new workarounds among new features. I'm trying to figure
> out something to ease up analyzing their impact and maybe even
> rootcausing bugs.

If you have something that proved to be useful in a few bugs I would consider 
this.
But merge a bunch of code to returns information that will not be useful is not 
good and would bring more maintenance burden in future.
If you check the psr debugfs we already have some of it that was not much 
useful.

> 
> > 
> > I don't see much value on it.
> > We have now some cases that leads to full update, that needs to be
> > properly fixed so it can always do partial updates.
> 
> There are still these cases, but also frontbuffer invalidate/flush
> callbacks are there. e.g. currently there is no way to say how often we
> are doing full update. Before the "continuous full update" we didn't
> know how much psr is actually disabled due to invalidate/flush.
> 
> > Did not checked the implementation details.
> > 
> > > This patch addresses this by adding new debugfs interface
> > > i915_edp_psr_stats. Statistics gathering is started by writing
> > > 1/y/Y and
> > > stopped by writing 0/n/N into this new interface.
> > > 
> > > Following fields are provided for reading by this new interface:
> > > 
> > > "PSR disabled vblank count"
> > > 
> > > Over how many vblank periods  PSR was disabled after statistics
> > > gathering got started. I.e. How many normal updates were sent to
> > > panel.
> > > 
> > > "Total vblank count"
> > > 
> > > Total vblank count after statistics gathering got started.
> > > 
> > > "Selective update count"
> > > 
> > > How many selective updates (PSR2) were done after statistics
> > > gathering
> > > got started.
> > > 
> > > "Full update count"
> > > 
> > > How many times driver decided to fall back to full update when
> > > trying to
> > > perform selective update.
> > > 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > Cc: Uma Shankar 
> > > Cc: Nischal Varide 
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  .../drm/i915/display/intel_display_debugfs.c  | 100 
> > >  .../drm/i915/display/intel_display_types.h|  16 ++
> > >  drivers/gpu/drm/i915/display/intel_psr.c  | 144
> > > ++
> > >  drivers/gpu/drm/i915/display/intel_psr.h  |   2 +
> > >  4 files changed, 236 insertions(+), 26 deletions(-)
> > > 
>

Re: [Intel-gfx] [RFC PATCH] drm/i915: Debugfs statistics interface for psr

[Souza, Jose]

On Wed, 2022-05-18 at 10:45 +0300, Jouni Högander wrote:
> Currently there is no mean to get understanding how psr is utilized.
> E.g. How much psr is actually enabled or how often driver falls back
> to full update.

But with this information what can you do?

I don't see much value on it.
We have now some cases that leads to full update, that needs to be properly 
fixed so it can always do partial updates.

Did not checked the implementation details.

> 
> This patch addresses this by adding new debugfs interface
> i915_edp_psr_stats. Statistics gathering is started by writing 1/y/Y and
> stopped by writing 0/n/N into this new interface.
> 
> Following fields are provided for reading by this new interface:
> 
> "PSR disabled vblank count"
> 
> Over how many vblank periods  PSR was disabled after statistics
> gathering got started. I.e. How many normal updates were sent to panel.
> 
> "Total vblank count"
> 
> Total vblank count after statistics gathering got started.
> 
> "Selective update count"
> 
> How many selective updates (PSR2) were done after statistics gathering
> got started.
> 
> "Full update count"
> 
> How many times driver decided to fall back to full update when trying to
> perform selective update.
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Uma Shankar 
> Cc: Nischal Varide 
> Signed-off-by: Jouni Högander 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 100 
>  .../drm/i915/display/intel_display_types.h|  16 ++
>  drivers/gpu/drm/i915/display/intel_psr.c  | 144 ++
>  drivers/gpu/drm/i915/display/intel_psr.h  |   2 +
>  4 files changed, 236 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 452d773fd4e3..c29f151062e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -9,6 +9,7 @@
>  #include 
>  
>  #include "i915_debugfs.h"
> +#include "intel_crtc.h"
>  #include "intel_de.h"
>  #include "intel_display_debugfs.h"
>  #include "intel_display_power.h"
> @@ -1868,6 +1869,95 @@ i915_fifo_underrun_reset_write(struct file *filp,
>   return cnt;
>  }
>  
> +static int intel_psr_stats(struct seq_file *m, struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = (m->private);
> + struct intel_psr *psr = _dp->psr;
> + struct drm_crtc *crtc = _crtc_for_pipe(dev_priv, psr->pipe)->base;
> + u64 total_vblank_count = psr->stats.total_vblank_count,
> + non_psr_vblank_count = psr->stats.non_psr_vblank_count;
> + ktime_t vblanktime;
> +
> + if (!psr->active)
> + non_psr_vblank_count += drm_crtc_vblank_count_and_time(crtc, 
> ) -
> + psr->stats.psr_disable_vblank;
> +
> + seq_printf(m, "PSR disabled vblank count : %llu\n", 
> non_psr_vblank_count);
> +
> + if (psr->stats.enable)
> + total_vblank_count += drm_crtc_vblank_count_and_time(crtc, 
> ) -
> + psr->stats.start_vblank;
> +
> + seq_printf(m, "Total vblank count : %llu\n", total_vblank_count);
> + seq_printf(m, "Selective update count : %llu\n", 
> psr->stats.selective_update_count);
> + seq_printf(m, "Full update count : %llu\n", 
> psr->stats.full_update_count);
> +
> + return 0;
> +}
> +
> +static int i915_edp_psr_stats_show(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = (m->private);
> + struct intel_dp *intel_dp = NULL;
> + struct intel_encoder *encoder;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + /* Find the first EDP which supports PSR */
> + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> + intel_dp = enc_to_intel_dp(encoder);
> + break;
> + }
> +
> + if (!intel_dp)
> + return -ENODEV;
> +
> + return intel_psr_stats(m, intel_dp);
> +}
> +
> +static ssize_t
> +i915_edp_psr_stats_write(struct file *filp, const char __user *ubuf,
> +  size_t cnt, loff_t *ppos)
> +{
> + struct seq_file *m = filp->private_data;
> + struct drm_i915_private *dev_priv = m->private;
> + struct intel_dp *intel_dp = NULL;
> + struct intel_encoder *encoder;
> + int ret;
> + bool enable_stats;
> +
> + ret = kstrtobool_from_user(ubuf, cnt, _stats);
> + if (ret)
> + return ret;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + /* Find the first EDP which supports PSR */
> + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> + intel_dp = enc_to_intel_dp(encoder);
> + break;
> + }
> +
> + if (!intel_dp)
> + return -ENODEV;
> +
> + if (enable_stats)
> + intel_psr_stats_enable_stats(intel_dp);
> + else
> + intel_psr_stats_disable_stats(intel_dp);
> +
> + return cnt;

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Fri, 2022-05-13 at 17:28 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails.  For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
> 
> One of such for example is big fb with offset. We don't have usable
> offset in psr2_sel_fetch_update. Currently it's open what is the
> proper way to fix this corner case. Use full update for now.
> 
> v2: Commit message modified
> v3: Print out debug info once when area calculation fails
> v4: Use drm_info_once
> v5: pipeA -> "pipe %c", pipe_name(crtc-pipe)
> 

Reviewed-by: José Roberto de Souza 

> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..fecdaaeac39e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1685,6 +1685,7 @@ static bool psr2_sel_fetch_pipe_state_supported(const 
> struct intel_crtc_state *c
>  int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct intel_crtc_state *crtc_state = 
> intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX, .y2 = 
> -1 };
>   struct intel_plane_state *new_plane_state, *old_plane_state;
> @@ -1770,6 +1771,19 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   clip_area_update(_clip, _area);
>   }
>  
> + /*
> +  * TODO: For now we are just using full update in case
> +  * selective fetch area calculation fails. To optimize this we
> +  * should identify cases where this happens and fix the area
> +  * calculation for those.
> +  */
> + if (pipe_clip.y1 == -1) {
> + drm_info_once(_priv->drm,
> +   "Selective fetch area calculation failed in pipe 
> %c\n",
> +   pipe_name(crtc->pipe));
> + full_update = true;
> + }
> +
>   if (full_update)
>   goto skip_sel_fetch_set_loop;
>  

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Ensure damage clip area is within pipe area

[Souza, Jose]

On Fri, 2022-05-13 at 15:30 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
> 
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
> 
> v2: Set x1 and x2 in damaged_area initialization
> v3: Move drm_rect_intersect into clip_area_update
> v4: draw_area -> pipe_src

Reviewed-by: José Roberto de Souza 

> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 1f031ebc1456..18058252037d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1618,8 +1618,12 @@ static void psr2_man_trk_ctl_calc(struct 
> intel_crtc_state *crtc_state,
>  }
>  
>  static void clip_area_update(struct drm_rect *overlap_damage_area,
> -  struct drm_rect *damage_area)
> +  struct drm_rect *damage_area,
> +  struct drm_rect *pipe_src)
>  {
> + if (!drm_rect_intersect(damage_area, pipe_src))
> + return;
> +
>   if (overlap_damage_area->y1 == -1) {
>   overlap_damage_area->y1 = damage_area->y1;
>   overlap_damage_area->y2 = damage_area->y2;
> @@ -1709,7 +1713,8 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>*/
>   for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
>new_plane_state, i) {
> - struct drm_rect src, damaged_area = { .y1 = -1 };
> + struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1,
> +   .x2 = INT_MAX };
>   struct drm_atomic_helper_damage_iter iter;
>   struct drm_rect clip;
>  
> @@ -1736,20 +1741,23 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   if (old_plane_state->uapi.visible) {
>   damaged_area.y1 = old_plane_state->uapi.dst.y1;
>   damaged_area.y2 = old_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   }
>  
>   if (new_plane_state->uapi.visible) {
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   }
>   continue;
>   } else if (new_plane_state->uapi.alpha != 
> old_plane_state->uapi.alpha) {
>   /* If alpha changed mark the whole plane area as 
> damaged */
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   continue;
>   }
>  
> @@ -1760,7 +1768,8 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  _plane_state->uapi);
>   drm_atomic_for_each_plane_damage(, ) {
>   if (drm_rect_intersect(, ))
> - clip_area_update(_area, );
> + clip_area_update(_area, ,
> +  _state->pipe_src);
>   }
>  
>   if (damaged_area.y1 == -1)
> @@ -1768,7 +1777,7 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  
>   damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
>   damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area, 
> _state->pipe_src);
>   }
>  
>   /*

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Fri, 2022-05-13 at 15:30 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails.  For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
> 
> One of such for example is big fb with offset. We don't have usable
> offset in psr2_sel_fetch_update. Currently it's open what is the
> proper way to fix this corner case. Use full update for now.
> 
> v2: Commit message modified
> v3: Print out debug info once when area calculation fails
> v4: Use drm_info_once
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..1f031ebc1456 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1685,6 +1685,7 @@ static bool psr2_sel_fetch_pipe_state_supported(const 
> struct intel_crtc_state *c
>  int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct intel_crtc_state *crtc_state = 
> intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX, .y2 = 
> -1 };
>   struct intel_plane_state *new_plane_state, *old_plane_state;
> @@ -1770,6 +1771,17 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   clip_area_update(_clip, _area);
>   }
>  
> + /*
> +  * TODO: For now we are just using full update in case
> +  * selective fetch area calculation fails. To optimize this we
> +  * should identify cases where this happens and fix the area
> +  * calculation for those.
> +  */
> + if (pipe_clip.y1 == -1) {
> + drm_info_once(_priv->drm, "Selective fetch area calculation 
> failed in pipeA");

Please do not hardcode to pipe A, get the pipe from state and print it.

> + full_update = true;
> + }
> +
>   if (full_update)
>   goto skip_sel_fetch_set_loop;
>  

Re: [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db from device info

[Souza, Jose]

On Wed, 2022-05-11 at 08:39 +0100, Tvrtko Ursulin wrote:
> On 10/05/2022 08:41, Jani Nikula wrote:
> > On Tue, 10 May 2022, Joonas Lahtinen  
> > wrote:
> > > Quoting Souza, Jose (2022-05-09 17:19:28)
> > > > On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen wrote:
> > > > > Quoting José Roberto de Souza (2022-05-07 16:28:50)
> > > > > > No need to have this parameter in intel_device_info struct
> > > > > > as this feature is supported by Broadwell, Haswell all platforms 
> > > > > > with
> > > > > > display version 9 or newer.
> > > > > 
> > > > > This is opposite of the direction we want to move to.
> > > > > 
> > > > > We want to embrace the has_xyz flags, instead of the macro trickery.
> > > > 
> > > > This ever growing flag definition is causing problems when defining new 
> > > > platforms.
> > > 
> > > The ever growing macros that change between kernel versions are much
> > > more painful than easily printable list per SKU.
> > > 
> > > Just to make it clear, a strict NACK from me for merging any patches
> > > into this direction.
> > 
> > I was hoping to start a discussion to reach consensus on this with my
> > mail [1], adding all maintainers in Cc, but merging started before the
> > discussion really even started.
> > 
> > Obviously no further patches on this are to be merged, and the question
> > now is really what to do with the ones that were. Revert?
> 
>  From the process standpoint strictly yes, but in practice I think there 
> is no rush.
> 
> The ones which got merged I definitely do not like are:
> 
> Rc6 - because it creates an inconsistency where rc6p remains a device 
> info flag.
> 
> DDI - because it is not 100% trivial and used from i915_irq.c. But a) I 
> am not sure it is truly on an irq path, and b) it is display code so not 
> my call anyway. (Affects the DP MST one as well by inheritance.)
> 
> The others are at best lukewarm to me - primarily because I am not 
> convinced there is a benefit to it all. One day the need might come to 
> move them back if some platforms drops support or something, which would 
> be more churn. And it is handy to see a consolidated description of a 
> platform in dmesg when looking at bugs. So just not sure it's an 
> improvement.

If platform feature list print is a must, we could print those features 
converted to platform and IP checks in intel_device_info_print_runtime().

> 
> Give there is much more conversions proposed I guess it may make sense 
> to revert until overall consensus is achieved, since it may be odd to 
> have a handful if we decide to stop there.
> 
> Regards,
> 
> Tvrtko

Re: [Intel-gfx] [PATCH v3 1/3] drm/print: Add drm_debug_once* macros

[Souza, Jose]

On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Add drm_debug_once* macros to allow printing out one time debug
> messages which can be still controlled via drm.debug parameter.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  include/drm/drm_print.h | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 22fabdeed297..e339f47eeb6d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -476,6 +476,35 @@ void drm_dev_dbg(const struct device *dev, enum 
> drm_debug_category category,
>  #define drm_dbg_drmres(drm, fmt, ...)
> \
>   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, 
> ##__VA_ARGS__)
>  
> +#define drm_dev_dbg_once(dev, cat, fmt, ...) \
> +({   \
> + static bool __print_once __read_mostly; \
> + if (!__print_once) {\
> + __print_once = true;\
> + drm_dev_dbg(dev, cat, fmt, ##__VA_ARGS__);  \
> + }   \
> +})
> +
> +#define drm_dbg_once_core(drm, fmt, ...) 
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once(drm, fmt, ...)  
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_kms(drm, fmt, ...)  
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_prime(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_atomic(drm, fmt, ...)   
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_vbl(drm, fmt, ...)  
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_state(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_lease(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_dp(drm, fmt, ...)   
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, 
> ##__VA_ARGS__)
> +#define drm_dbg_once_drmres(drm, fmt, ...)   
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, 
> ##__VA_ARGS__)
>  
>  /*
>   * printk based logging

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Ensure damage clip area is within pipe area

[Souza, Jose]

On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
> 
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
> 
> v2: Set x1 and x2 in damaged_area initialization
> v3: Move drm_rect_intersect into clip_area_update
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 3561c218cfb1..f4b4c1c83d2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1618,8 +1618,12 @@ static void psr2_man_trk_ctl_calc(struct 
> intel_crtc_state *crtc_state,
>  }
>  
>  static void clip_area_update(struct drm_rect *overlap_damage_area,
> -  struct drm_rect *damage_area)
> +  struct drm_rect *damage_area,
> +  struct drm_rect *draw_area)

s/draw_area/pipe_src?

>  {
> + if (!drm_rect_intersect(damage_area, draw_area))
> + return;
> +
>   if (overlap_damage_area->y1 == -1) {
>   overlap_damage_area->y1 = damage_area->y1;
>   overlap_damage_area->y2 = damage_area->y2;
> @@ -1709,7 +1713,8 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>*/
>   for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
>new_plane_state, i) {
> - struct drm_rect src, damaged_area = { .y1 = -1 };
> + struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1,
> +   .x2 = INT_MAX };
>   struct drm_atomic_helper_damage_iter iter;
>   struct drm_rect clip;
>  
> @@ -1736,20 +1741,23 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   if (old_plane_state->uapi.visible) {
>   damaged_area.y1 = old_plane_state->uapi.dst.y1;
>   damaged_area.y2 = old_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   }
>  
>   if (new_plane_state->uapi.visible) {
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   }
>   continue;
>   } else if (new_plane_state->uapi.alpha != 
> old_plane_state->uapi.alpha) {
>   /* If alpha changed mark the whole plane area as 
> damaged */
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + clip_area_update(_clip, _area,
> +  _state->pipe_src);
>   continue;
>   }
>  
> @@ -1760,7 +1768,8 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  _plane_state->uapi);
>   drm_atomic_for_each_plane_damage(, ) {
>   if (drm_rect_intersect(, ))
> - clip_area_update(_area, );
> + clip_area_update(_area, ,
> +  _state->pipe_src);
>   }
>  
>   if (damaged_area.y1 == -1)
> @@ -1768,7 +1777,8 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  
>   damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
>   damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> - clip_area_update(_clip, _area);
> +
> + clip_area_update(_clip, _area, 
> _state->pipe_src);

white space ^

with those nits:
Reviewed-by: José Roberto de Souza 

>   }
>  
>   /*

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails.  For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
> 
> One of such for example is big fb with offset. We don't have usable
> offset in psr2_sel_fetch_update. Currently it's open what is the
> proper way to fix this corner case. Use full update for now.
> 
> v2: Commit message modified
> v3: Print out debug info once when area calculation fails
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..3561c218cfb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1685,6 +1685,7 @@ static bool psr2_sel_fetch_pipe_state_supported(const 
> struct intel_crtc_state *c
>  int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct intel_crtc_state *crtc_state = 
> intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX, .y2 = 
> -1 };
>   struct intel_plane_state *new_plane_state, *old_plane_state;
> @@ -1770,6 +1771,17 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   clip_area_update(_clip, _area);
>   }
>  
> + /*
> +  * TODO: For now we are just using full update in case
> +  * selective fetch area calculation fails. To optimize this we
> +  * should identify cases where this happens and fix the area
> +  * calculation for those.
> +  */
> + if (pipe_clip.y1 == -1) {
> + drm_dbg_once_kms(_priv->drm, "No selective fetch area, 
> using full update");

The debug message is misleading, a better message would be: Selective fetch 
area calculation failed in pipeA.

with that:
Reviewed-by: José Roberto de Souza 

> + full_update = true;
> + }
> +
>   if (full_update)
>   goto skip_sel_fetch_set_loop;
>  

Re: [Intel-gfx] [PATCH 01/16] drm/i915: Drop has_llc from device info

[Souza, Jose]

On Mon, 2022-05-09 at 15:52 +0100, Matthew Auld wrote:
> On Mon, 9 May 2022 at 15:05, Souza, Jose  wrote:
> > 
> > On Mon, 2022-05-09 at 12:09 +0100, Matthew Auld wrote:
> > > On Sat, 7 May 2022 at 14:29, José Roberto de Souza  
> > > wrote:
> > > > 
> > > > This feature is supported in graphics version 6 and newer in all
> > > > integrated GPUs not including VLC and CHV, so we can drop this flag
> > > > for a not so complicated macro check.
> > > 
> > > s/VLC/VLV/ ?
> > 
> > yep, thanks.
> > 
> > > 
> > > There are also some gen9/10 platforms that only have snooping.
> > 
> > That is not reflected into current platform definition.
> 
> See glk_info/bxt_info.

Oh okay, missed that.
In this case the macro gets too big and is better to keep the flag into device 
info.

> 
> > Can you point out the spec pages?
> > 
> > > 
> > > > 
> > > > For this flag we were lucky as XE_HP_FEATURES was setting it to true
> > > > while DGFX_FEATURES was setting it to false and xehpsdv and DG2 were
> > > > using those macros in this givin order if it was the other way around,
> > > > some code paths would follow the HAS_LLC path while LLC is not
> > > > available in hardware and was not initialized in software.
> > > > 
> > > > As a side effect of the of removal this flag, it will not be printed
> > > > in dmesg during driver load anymore and developers will have to rely
> > > > on to check the macro and compare with platform being used and IP
> > > > versions of it.
> > > > 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/gt/intel_llc.c  | 2 +-
> > > >  drivers/gpu/drm/i915/i915_drv.h  | 5 -
> > > >  drivers/gpu/drm/i915/i915_pci.c  | 4 
> > > >  drivers/gpu/drm/i915/intel_device_info.h | 1 -
> > > >  4 files changed, 5 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_llc.c
> > > > index 40e2e28ee6c75..ffcff51ee6e47 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_llc.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_llc.c
> > > > @@ -52,7 +52,7 @@ static bool get_ia_constants(struct intel_llc *llc,
> > > > struct drm_i915_private *i915 = llc_to_gt(llc)->i915;
> > > > struct intel_rps *rps = _to_gt(llc)->rps;
> > > > 
> > > > -   if (!HAS_LLC(i915) || IS_DGFX(i915))
> > > > +   if (!HAS_LLC(i915))
> > > > return false;
> > > > 
> > > > if (rps->max_freq <= rps->min_freq)
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 6dfaf7fce9156..fd5269845e9ad 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1236,7 +1236,10 @@ IS_SUBPLATFORM(const struct drm_i915_private 
> > > > *i915,
> > > >   */
> > > >  #define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7)
> > > > 
> > > > -#define HAS_LLC(dev_priv)  (INTEL_INFO(dev_priv)->has_llc)
> > > > +#define HAS_LLC(dev_priv)  (!IS_DGFX(dev_priv) && 
> > > > (GRAPHICS_VER(dev_priv) >= 8 || \
> > > > +   
> > > > IS_HASWELL(dev_priv) || \
> > > > +   
> > > > IS_IVYBRIDGE(dev_priv) || \
> > > > +   
> > > > IS_SANDYBRIDGE(dev_priv)))
> > > >  #define HAS_4TILE(dev_priv)(INTEL_INFO(dev_priv)->has_4tile)
> > > >  #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop)
> > > >  #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb)
> > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > > b/drivers/gpu/drm/i915/i915_pci.c
> > > > index 799573a5e5a6f..30a32a5d0e3c9 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > @@ -404,7 +404,6 @@ static const struct intel_device_info ilk_m_info = {
> > > > .display.fbc_mask = BIT(INTEL_FBC_A), \
> >

Re: [Intel-gfx] [PATCH CI 5/7] drm/i915: Drop has_ddi from device info

[Souza, Jose]

On Mon, 2022-05-09 at 15:27 +0100, Tvrtko Ursulin wrote:
> On 09/05/2022 15:01, Souza, Jose wrote:
> > On Mon, 2022-05-09 at 14:32 +0100, Tvrtko Ursulin wrote:
> > > On 05/05/2022 20:35, José Roberto de Souza wrote:
> > > > No need to have this parameter in intel_device_info struct
> > > > as all platforms with display version 9 or newer, haswell or broadwell
> > > > supports it.
> > > > 
> > > > As a side effect of the of removal this flag, it will not be printed
> > > > in dmesg during driver load anymore and developers will have to rely
> > > > on to check the macro and compare with platform being used and IP
> > > > versions of it.
> > > > 
> > > > Reviewed-by: Matt Roper 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >drivers/gpu/drm/i915/i915_drv.h  | 4 +++-
> > > >drivers/gpu/drm/i915/i915_pci.c  | 3 ---
> > > >drivers/gpu/drm/i915/intel_device_info.h | 1 -
> > > >3 files changed, 3 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 5538564bc1d25..600d8cee272da 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1298,7 +1298,9 @@ IS_SUBPLATFORM(const struct drm_i915_private 
> > > > *i915,
> > > >#define HAS_DP20(dev_priv)   (IS_DG2(dev_priv))
> > > >
> > > >#define HAS_CDCLK_CRAWL(dev_priv) 
> > > > (INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
> > > > -#define HAS_DDI(dev_priv)   
> > > > (INTEL_INFO(dev_priv)->display.has_ddi)
> > > > +#define HAS_DDI(dev_priv)   (DISPLAY_VER(dev_priv) >= 9 || 
> > > > \
> > > > + IS_BROADWELL(dev_priv) || \
> > > > + IS_HASWELL(dev_priv))
> > > 
> > > This one is a bit borderline, not sure it passes Jani's criteria of
> > > simplicity, which I thought was a good one. And from the OCD angle it
> > > kind of sucks to expand the conditionals to all call sites (when it's
> > > even called from i915_irq.c, justifiably or not I don't know).
> > 
> > This might increase code size but I don't believe it will case any 
> > performance impact even for interruption handling.
> 
> Probably won't, but its IMO ugly and at some point a death of thousand 
> cuts come to play ie. maybe you can't measure an effect of a single 
> change, but over time pointless wastage of cycles accumulates. Not 
> saying that I looked whether it applies to this concrete example, just a 
> general principle - if the condition is not straightforward I would 
> recommend looking at the number and context of callers.
> 
> > > What is the high level motivation for this work?
> > 
> > Add new platforms definitions are becoming huge burden, there is too many 
> > features to check if a new platform supports each one of it, what is leading
> > to platform definition errors.
> 
> How does this change help with that? That work is always required, no? 
> With flags it is at least mostly centralized in one file and with this 
> series some parts become spread around so you have to not even know what 
> feature supports what, but also where in code to look for places which 
> need to be adjusted. (Example engine reset and further issues when/if 
> other macros start getting out i915_drv.h.)

There is already several features that don't have a device info flag.
What helps is this case is define the HAS_XXX() using IP version.

> 
> > Also usually when a feature is dropped a HSD will be filed, so the person 
> > taking care of that can just adjust the macro upper platform or IP bound and
> > disable it for good.
> 
> Or can equally adjust the has flags assignments at a single file.

What happens it that a feature is disabled for a single platform and on the 
next one the information that from IP X and newer this feature is gone is
lost in the source code.

> 
> To be clear I don't have a strong preference either way (in principle) 
> at the moment, but think more consensus and discussion is needed here 
> before changing it all.

Okay

> 
> Regards,
> 
> Tvrtko
> 
> > > Also, why is this in drm-intel-gt-next? :)
> > 
> > To reduce conflicts, moving just one of this patches around already causes 
> > conflicts.
> > 
> > > 
>

Re: [Intel-gfx] [PATCH CI 5/7] drm/i915: Drop has_ddi from device info

[Souza, Jose]

On Mon, 2022-05-09 at 17:05 +0300, Jani Nikula wrote:
> On Mon, 09 May 2022, Tvrtko Ursulin  wrote:
> > On 05/05/2022 20:35, José Roberto de Souza wrote:
> > > No need to have this parameter in intel_device_info struct
> > > as all platforms with display version 9 or newer, haswell or broadwell
> > > supports it.
> > > 
> > > As a side effect of the of removal this flag, it will not be printed
> > > in dmesg during driver load anymore and developers will have to rely
> > > on to check the macro and compare with platform being used and IP
> > > versions of it.
> > > 
> > > Reviewed-by: Matt Roper 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.h  | 4 +++-
> > >   drivers/gpu/drm/i915/i915_pci.c  | 3 ---
> > >   drivers/gpu/drm/i915/intel_device_info.h | 1 -
> > >   3 files changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 5538564bc1d25..600d8cee272da 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1298,7 +1298,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > >   #define HAS_DP20(dev_priv)  (IS_DG2(dev_priv))
> > >   
> > >   #define HAS_CDCLK_CRAWL(dev_priv)
> > > (INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
> > > -#define HAS_DDI(dev_priv) 
> > > (INTEL_INFO(dev_priv)->display.has_ddi)
> > > +#define HAS_DDI(dev_priv) (DISPLAY_VER(dev_priv) >= 9 || 
> > > \
> > > +   IS_BROADWELL(dev_priv) || \
> > > +   IS_HASWELL(dev_priv))
> > 
> > This one is a bit borderline, not sure it passes Jani's criteria of 
> > simplicity, which I thought was a good one. And from the OCD angle it 
> > kind of sucks to expand the conditionals to all call sites (when it's 
> > even called from i915_irq.c, justifiably or not I don't know).
> > 
> > What is the high level motivation for this work?
> 
> Yeah, just don't merge when there's open discussion. Get the acks.

Sorry, I thought that for this ones we were good to go.

> 
> > Also, why is this in drm-intel-gt-next? :)
> 
> Without the smiley, actually.
> 
> *ALL* refactoring like this *MUST* go through drm-intel-next.

My understating was that if it was touching GT it should go to 
drm-intel-gt-next.

> 
> This is now a source for conflicts for at least 4-6 weeks until we can
> merge drm-intel-gt-next -> drm-next -> drm-intel-next.
> 
> 
> BR,
> Jani.
> 
> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > 
> > >   #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
> > > (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> > >   #define HAS_PSR(dev_priv)
> > > (INTEL_INFO(dev_priv)->display.has_psr)
> > >   #define HAS_PSR_HW_TRACKING(dev_priv) \
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 2dc0284629d30..a0693d9ff9cee 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -535,7 +535,6 @@ static const struct intel_device_info vlv_info = {
> > >   .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | 
> > > BIT(VECS0), \
> > >   .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | 
> > > BIT(TRANSCODER_B) | \
> > >   BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > > - .display.has_ddi = 1, \
> > >   .display.has_fpga_dbg = 1, \
> > >   .display.has_dp_mst = 1, \
> > >   .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > > @@ -683,7 +682,6 @@ static const struct intel_device_info skl_gt4_info = {
> > >   BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> > >   BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> > >   .has_64bit_reloc = 1, \
> > > - .display.has_ddi = 1, \
> > >   .display.has_fpga_dbg = 1, \
> > >   .display.fbc_mask = BIT(INTEL_FBC_A), \
> > >   .display.has_hdcp = 1, \
> > > @@ -932,7 +930,6 @@ static const struct intel_device_info adl_s_info = {
> > >   .dbuf.size = 4096,  
> > > \
> > >   .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
> > > \
> > >   BIT(DBUF_S4),   
> > > \
> > > - .display.has_ddi = 1,   
> > > \
> > >   .display.has_dmc = 1,   
> > > \
> > >   .display.has_dp_mst = 1,
> > > \
> > >   .display.has_dsb = 1,   
> > > \
> > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > > b/drivers/gpu/drm/i915/intel_device_info.h
> > > index bef65e3f02c55..bc71ce48763ad 100644
> > > --- 

Re: [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db from device info

[Souza, Jose]

On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen wrote:
> Quoting José Roberto de Souza (2022-05-07 16:28:50)
> > No need to have this parameter in intel_device_info struct
> > as this feature is supported by Broadwell, Haswell all platforms with
> > display version 9 or newer.
> 
> This is opposite of the direction we want to move to.
> 
> We want to embrace the has_xyz flags, instead of the macro trickery.

This ever growing flag definition is causing problems when defining new 
platforms.

There is too many features to check if a new platform supports each one of it, 
what is leading to platform definition errors.

Also usually when a feature is dropped a HSD will be filed, so the person 
taking care of that can just adjust the macro upper platform or IP bound and
disable it for good. 

> 
> > As a side effect of the of removal this flag, it will not be printed
> > in dmesg during driver load anymore and developers will have to rely
> > on to check the macro and compare with platform being used and IP
> > versions of it.
> 
> This is not a very good rationale. If the platform has something, but it
> becomes disabled in runtime, then we should add an another print after
> the runtime sanitization has been done.

In my opinion this flags should only change in runtime if the feature is fused 
off like is done for has_dsc and has_dmc.

> 
> Regards, Joonas
> 
> > 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 4 +++-
> >  drivers/gpu/drm/i915/i915_pci.c  | 3 ---
> >  drivers/gpu/drm/i915/intel_device_info.h | 1 -
> >  3 files changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4b1025dbaab2a..4a1edf48d37b9 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1306,7 +1306,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >   IS_BROADWELL(dev_priv) || \
> >   IS_HASWELL(dev_priv))
> >  #define HAS_DP_MST(dev_priv)(HAS_DDI(dev_priv))
> > -#define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
> > (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> > +#define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (DISPLAY_VER(dev_priv) >= 9 || \
> > + IS_BROADWELL(dev_priv) || \
> > + IS_HASWELL(dev_priv))
> >  #define HAS_PSR(dev_priv)   (DISPLAY_VER(dev_priv) >= 9)
> >  #define HAS_PSR2_SEL_FETCH(dev_priv)(DISPLAY_VER(dev_priv) >= 12)
> >  #define HAS_TRANSCODER(dev_priv, trans) 
> > ((INTEL_INFO(dev_priv)->display.cpu_transcoder_mask & BIT(trans)) != 0)
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 5a42acb162a15..6a5b70b3ea2d7 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -523,7 +523,6 @@ static const struct intel_device_info vlv_info = {
> > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | 
> > BIT(VECS0), \
> > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | 
> > BIT(TRANSCODER_B) | \
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > -   .display.has_fpga_dbg = 1, \
> > HSW_PIPE_OFFSETS
> >  
> >  #define HSW_PLATFORM \
> > @@ -657,7 +656,6 @@ static const struct intel_device_info skl_gt4_info = {
> > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | 
> > BIT(TRANSCODER_B) | \
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> > BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> > -   .display.has_fpga_dbg = 1, \
> > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > .display.has_hdcp = 1, \
> > .display.has_dmc = 1, \
> > @@ -894,7 +892,6 @@ static const struct intel_device_info adl_s_info = {
> > .display.has_dmc = 1,   
> > \
> > .display.has_dsc = 1,   
> > \
> > .display.fbc_mask = BIT(INTEL_FBC_A),   
> > \
> > -   .display.has_fpga_dbg = 1,  
> > \
> > .display.has_hdcp = 1,  
> > \
> > .display.has_hotplug = 1,   
> > \
> > .display.ver = 13,  
> > \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index 7581ef4a68f94..e61a334b611ac 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -157,7 +157,6 @@ enum intel_ppgtt_type {
> > func(has_cdclk_crawl); \
> > func(has_dmc); \
> > func(has_dsc); \
> > -   

Re: [Intel-gfx] [PATCH 01/16] drm/i915: Drop has_llc from device info

[Souza, Jose]

On Mon, 2022-05-09 at 12:09 +0100, Matthew Auld wrote:
> On Sat, 7 May 2022 at 14:29, José Roberto de Souza  
> wrote:
> > 
> > This feature is supported in graphics version 6 and newer in all
> > integrated GPUs not including VLC and CHV, so we can drop this flag
> > for a not so complicated macro check.
> 
> s/VLC/VLV/ ?

yep, thanks.

> 
> There are also some gen9/10 platforms that only have snooping.

That is not reflected into current platform definition.
Can you point out the spec pages?

> 
> > 
> > For this flag we were lucky as XE_HP_FEATURES was setting it to true
> > while DGFX_FEATURES was setting it to false and xehpsdv and DG2 were
> > using those macros in this givin order if it was the other way around,
> > some code paths would follow the HAS_LLC path while LLC is not
> > available in hardware and was not initialized in software.
> > 
> > As a side effect of the of removal this flag, it will not be printed
> > in dmesg during driver load anymore and developers will have to rely
> > on to check the macro and compare with platform being used and IP
> > versions of it.
> > 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_llc.c  | 2 +-
> >  drivers/gpu/drm/i915/i915_drv.h  | 5 -
> >  drivers/gpu/drm/i915/i915_pci.c  | 4 
> >  drivers/gpu/drm/i915/intel_device_info.h | 1 -
> >  4 files changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c 
> > b/drivers/gpu/drm/i915/gt/intel_llc.c
> > index 40e2e28ee6c75..ffcff51ee6e47 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_llc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_llc.c
> > @@ -52,7 +52,7 @@ static bool get_ia_constants(struct intel_llc *llc,
> > struct drm_i915_private *i915 = llc_to_gt(llc)->i915;
> > struct intel_rps *rps = _to_gt(llc)->rps;
> > 
> > -   if (!HAS_LLC(i915) || IS_DGFX(i915))
> > +   if (!HAS_LLC(i915))
> > return false;
> > 
> > if (rps->max_freq <= rps->min_freq)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 6dfaf7fce9156..fd5269845e9ad 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1236,7 +1236,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >   */
> >  #define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7)
> > 
> > -#define HAS_LLC(dev_priv)  (INTEL_INFO(dev_priv)->has_llc)
> > +#define HAS_LLC(dev_priv)  (!IS_DGFX(dev_priv) && 
> > (GRAPHICS_VER(dev_priv) >= 8 || \
> > +   
> > IS_HASWELL(dev_priv) || \
> > +   
> > IS_IVYBRIDGE(dev_priv) || \
> > +   
> > IS_SANDYBRIDGE(dev_priv)))
> >  #define HAS_4TILE(dev_priv)(INTEL_INFO(dev_priv)->has_4tile)
> >  #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop)
> >  #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb)
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 799573a5e5a6f..30a32a5d0e3c9 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -404,7 +404,6 @@ static const struct intel_device_info ilk_m_info = {
> > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0), \
> > .has_coherent_ggtt = true, \
> > -   .has_llc = 1, \
> > .has_rc6p = 1, \
> > .has_rps = true, \
> > .dma_mask_size = 40, \
> > @@ -454,7 +453,6 @@ static const struct intel_device_info snb_m_gt2_info = {
> > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0), \
> > .has_coherent_ggtt = true, \
> > -   .has_llc = 1, \
> > .has_rc6p = 1, \
> > .has_rps = true, \
> > .dma_mask_size = 40, \
> > @@ -878,7 +876,6 @@ static const struct intel_device_info rkl_info = {
> > 
> >  #define DGFX_FEATURES \
> > .memory_regions = REGION_SMEM | REGION_LMEM | REGION_STOLEN_LMEM, \
> > -   .has_llc = 0, \
> > .has_pxp = 0, \
> > .has_snoop = 1, \
> > .is_dgfx = 1, \
> > @@ -985,7 +982,6 @@ static const struct intel_device_info adl_p_info = {
> > .has_64bit_reloc = 1, \
> > .has_flat_ccs = 1, \
> > .has_global_mocs = 1, \
> > -   .has_llc = 1, \
> > .has_logical_ring_contexts = 1, \
> > .has_mslices = 1, \
> > .has_rps = 1, \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index a2e53b8683285..e8d53c7a1bd83 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -149,7 +149,6 @@ enum intel_ppgtt_type {
> > func(has_heci_gscfi); \
> > 

Re: [Intel-gfx] [PATCH CI 5/7] drm/i915: Drop has_ddi from device info

[Souza, Jose]

On Mon, 2022-05-09 at 14:32 +0100, Tvrtko Ursulin wrote:
> On 05/05/2022 20:35, José Roberto de Souza wrote:
> > No need to have this parameter in intel_device_info struct
> > as all platforms with display version 9 or newer, haswell or broadwell
> > supports it.
> > 
> > As a side effect of the of removal this flag, it will not be printed
> > in dmesg during driver load anymore and developers will have to rely
> > on to check the macro and compare with platform being used and IP
> > versions of it.
> > 
> > Reviewed-by: Matt Roper 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h  | 4 +++-
> >   drivers/gpu/drm/i915/i915_pci.c  | 3 ---
> >   drivers/gpu/drm/i915/intel_device_info.h | 1 -
> >   3 files changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5538564bc1d25..600d8cee272da 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1298,7 +1298,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >   #define HAS_DP20(dev_priv)(IS_DG2(dev_priv))
> >   
> >   #define HAS_CDCLK_CRAWL(dev_priv)  
> > (INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
> > -#define HAS_DDI(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ddi)
> > +#define HAS_DDI(dev_priv)   (DISPLAY_VER(dev_priv) >= 9 || \
> > + IS_BROADWELL(dev_priv) || \
> > + IS_HASWELL(dev_priv))
> 
> This one is a bit borderline, not sure it passes Jani's criteria of 
> simplicity, which I thought was a good one. And from the OCD angle it 
> kind of sucks to expand the conditionals to all call sites (when it's 
> even called from i915_irq.c, justifiably or not I don't know).

This might increase code size but I don't believe it will case any performance 
impact even for interruption handling.

> 
> What is the high level motivation for this work?

Add new platforms definitions are becoming huge burden, there is too many 
features to check if a new platform supports each one of it, what is leading
to platform definition errors.

Also usually when a feature is dropped a HSD will be filed, so the person 
taking care of that can just adjust the macro upper platform or IP bound and
disable it for good.

> 
> Also, why is this in drm-intel-gt-next? :)

To reduce conflicts, moving just one of this patches around already causes 
conflicts.

> 
> Regards,
> 
> Tvrtko
> 
> 
> >   #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
> > (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> >   #define HAS_PSR(dev_priv)  (INTEL_INFO(dev_priv)->display.has_psr)
> >   #define HAS_PSR_HW_TRACKING(dev_priv) \
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 2dc0284629d30..a0693d9ff9cee 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -535,7 +535,6 @@ static const struct intel_device_info vlv_info = {
> > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | BIT(VECS0), 
> > \
> > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > -   .display.has_ddi = 1, \
> > .display.has_fpga_dbg = 1, \
> > .display.has_dp_mst = 1, \
> > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > @@ -683,7 +682,6 @@ static const struct intel_device_info skl_gt4_info = {
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> > BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> > .has_64bit_reloc = 1, \
> > -   .display.has_ddi = 1, \
> > .display.has_fpga_dbg = 1, \
> > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > .display.has_hdcp = 1, \
> > @@ -932,7 +930,6 @@ static const struct intel_device_info adl_s_info = {
> > .dbuf.size = 4096,  
> > \
> > .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
> > \
> > BIT(DBUF_S4),   
> > \
> > -   .display.has_ddi = 1,   
> > \
> > .display.has_dmc = 1,   
> > \
> > .display.has_dp_mst = 1,
> > \
> > .display.has_dsb = 1,   
> > \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index bef65e3f02c55..bc71ce48763ad 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -167,7 +167,6 @@ enum intel_ppgtt_type {
> > func(cursor_needs_physical); \
> > func(has_cdclk_crawl); \
> > func(has_dmc); \
> > -   func(has_ddi); \
> > func(has_dp_mst); \
> > func(has_dsb); \
> >  

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Ensure damage clip area is within pipe area

[Souza, Jose]

On Mon, 2022-05-09 at 10:24 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
> 
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
> 
> v2: Set x1 and x2 in damaged_area initialization
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Tested-by: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 8c099d24de86..ecd062a0fea4 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1708,7 +1708,9 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>*/
>   for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
>new_plane_state, i) {
> - struct drm_rect src, damaged_area = { .y1 = -1 };
> + /* Set damaged_area x1 and x2 for drm_rect_intersect usage */
> + struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1,
> +   .x2 = INT_MAX };

In my opinion this comment is not necessary.

>   struct drm_atomic_helper_damage_iter iter;
>   struct drm_rect clip;
>  
> @@ -1735,20 +1737,23 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   if (old_plane_state->uapi.visible) {
>   damaged_area.y1 = old_plane_state->uapi.dst.y1;
>   damaged_area.y2 = old_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, 
> _area);

What about the suggestion to move the drm_rect_intersect() to 
clip_area_update()?

>   }
>  
>   if (new_plane_state->uapi.visible) {
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, 
> _area);
>   }
>   continue;
>   } else if (new_plane_state->uapi.alpha != 
> old_plane_state->uapi.alpha) {
>   /* If alpha changed mark the whole plane area as 
> damaged */
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, _area);
>   continue;
>   }
>  
> @@ -1767,7 +1772,9 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  
>   damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
>   damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> - clip_area_update(_clip, _area);
> +
> + if (drm_rect_intersect(_area, _state->pipe_src))
> + clip_area_update(_clip, _area);
>   }
>  
>   if (pipe_clip.y1 == -1)

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Mon, 2022-05-09 at 10:24 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails.  For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
> 
> One of such for example is big fb with offset. We don't have usable
> offset in psr2_sel_fetch_update. Currently it's open what is the
> proper way to fix this corner case. Use full update for now.
> 
> v2: Commit message modified
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Tested-by: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..8c099d24de86 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1770,6 +1770,9 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   clip_area_update(_clip, _area);
>   }
>  
> + if (pipe_clip.y1 == -1)
> + full_update = true;

Left the debug_once and the TODO out, for a regular reader this looks like a 
normal code path... what is not the case.

> +
>   if (full_update)
>   goto skip_sel_fetch_set_loop;
>  

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Fri, 2022-05-06 at 18:28 +, Hogander, Jouni wrote:
> On Fri, 2022-05-06 at 15:29 +0000, Souza, Jose wrote:
> > On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> > > Currently we have some corner cases where area calculation
> > > fails.  For
> > > these sel fetch are calculation ends up having update area as y1 =
> > > 0,
> > > y2 = 4. Instead of these values safer option is full update.
> > 
> > Aren't you able to reproduce this scenarios with IGT? So why not
> > probably fix the calculations?
> 
> There were some discussion with Ville Syrjälä that the proper fix for
> this would be to move psr update area calculation into where other
> calculations for planes are done. Currently we don't have e.g. proper
> offset information available here. I have this in my tasklist, but been
> busy with other tracks.

Okay so please add some of that to the commit description.

> 
> I'm also concerned generally on the first loop possibly ending up with
> y1=-1,y2=-1 values due to other reasons as well. So using that
> full_update prevents this posibility completely.
> 
> If I forget how I originally found this problem with bigfb I think this
> backup using full update if something goes wrong is generally a good
> idea. Currently it's just using y1=0,y2=4.
> 
> > 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > Tested-by: Mark Pearson 
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 06db407e2749..8c099d24de86 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1770,6 +1770,9 @@ int intel_psr2_sel_fetch_update(struct
> > > intel_atomic_state *state,
> > >  clip_area_update(_clip, _area);
> > >  }
> > > 

Add a TODO and a "drm_DEBUG_ONCE()"(check drm_WARN_ONCE) here so we get a 
warning about this at least once and this is not forgot.

> > > +if (pipe_clip.y1 == -1)
> > > +full_update = true;
> > > +
> > >  if (full_update)
> > >  goto skip_sel_fetch_set_loop;
> > > 
> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ensure damage clip area is within pipe area

[Souza, Jose]

On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
> 
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Tested-by: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 8c099d24de86..5229ba89a079 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1724,6 +1724,10 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   break;
>   }
>  
> + /* Set x1 and x2 for drm_rect_intersect usage */
> + damaged_area.x1 = 0;
> + damaged_area.x2 = INT_MAX;

Move the above to the variable definition and initialization.

> +
>   /*
>* If visibility or plane moved, mark the whole plane area as
>* damaged as it needs to be complete redraw in the new and old
> @@ -1735,20 +1739,23 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   if (old_plane_state->uapi.visible) {
>   damaged_area.y1 = old_plane_state->uapi.dst.y1;
>   damaged_area.y2 = old_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, 
> _area);
>   }
>  
>   if (new_plane_state->uapi.visible) {
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, 
> _area);
>   }
>   continue;
>   } else if (new_plane_state->uapi.alpha != 
> old_plane_state->uapi.alpha) {
>   /* If alpha changed mark the whole plane area as 
> damaged */
>   damaged_area.y1 = new_plane_state->uapi.dst.y1;
>   damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(_clip, _area);
> + if (drm_rect_intersect(_area, 
> _state->pipe_src))
> + clip_area_update(_clip, _area);
>   continue;
>   }
>  
> @@ -1767,7 +1774,9 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>  
>   damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
>   damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> - clip_area_update(_clip, _area);
> +
> + if (drm_rect_intersect(_area, _state->pipe_src))
> + clip_area_update(_clip, _area);

As it is repeating move the drm_rect_intersect() call to clip_area_update(), 
adding a crtc_state parameter or pipe_src, your call.

Also please include a Fixes tag to some commit that makes sense so this patch 
is backported to older kernels with selective fetch enabled.

>   }
>  
>   if (pipe_clip.y1 == -1)

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Use full update In case of area calculation fails

[Souza, Jose]

On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails.  For
> these sel fetch are calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.

Aren't you able to reproduce this scenarios with IGT? So why not probably fix 
the calculations?

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Tested-by: Mark Pearson 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..8c099d24de86 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1770,6 +1770,9 @@ int intel_psr2_sel_fetch_update(struct 
> intel_atomic_state *state,
>   clip_area_update(_clip, _area);
>   }
>  
> + if (pipe_clip.y1 == -1)
> + full_update = true;
> +
>   if (full_update)
>   goto skip_sel_fetch_set_loop;
>  

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Drop IPC from display 13 and newer

[Souza, Jose]

On Thu, 2022-05-05 at 00:33 +0300, Ville Syrjälä wrote:
> On Wed, May 04, 2022 at 12:07:45PM -0700, José Roberto de Souza wrote:
> > This feature is supported from display 9 to display 12 and was
> > incorrectly being applied to DG2 and Alderlake-P.
> 
> They just renamed the register to ARB_HP_CTL.

Missed that, will fix it.

Thanks

> 
> > 
> > While at is also taking the oportunity to drop it from
> > intel_device_info struct as a display check is more simple
> > and less prone to be left enabled in future platforms.
> > 
> > BSpec: 50039
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 3 ++-
> >  drivers/gpu/drm/i915/i915_pci.c  | 3 ---
> >  drivers/gpu/drm/i915/intel_device_info.h | 1 -
> >  3 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2dddc27a1b0ed..695b35cd6b5e4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1344,7 +1344,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >   */
> >  #define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
> >  
> > -#define HAS_IPC(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ipc)
> > +#define HAS_IPC(dev_priv)   (DISPLAY_VER(dev_priv) >= 9 && \
> > + DISPLAY_VER(dev_priv) <= 12)
> >  
> >  #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
> >  #define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 498708b33924f..c4f9c805cffd1 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -646,7 +646,6 @@ static const struct intel_device_info chv_info = {
> > .display.has_dmc = 1, \
> > .has_gt_uc = 1, \
> > .display.has_hdcp = 1, \
> > -   .display.has_ipc = 1, \
> > .display.has_psr = 1, \
> > .display.has_psr_hw_tracking = 1, \
> > .dbuf.size = 896 - 4, /* 4 blocks for bypass path allocation */ \
> > @@ -712,7 +711,6 @@ static const struct intel_device_info skl_gt4_info = {
> > .has_reset_engine = 1, \
> > .has_snoop = true, \
> > .has_coherent_ggtt = false, \
> > -   .display.has_ipc = 1, \
> > HSW_PIPE_OFFSETS, \
> > IVB_CURSOR_OFFSETS, \
> > IVB_COLORS, \
> > @@ -955,7 +953,6 @@ static const struct intel_device_info adl_s_info = {
> > .display.has_fpga_dbg = 1,  
> > \
> > .display.has_hdcp = 1,  
> > \
> > .display.has_hotplug = 1,   
> > \
> > -   .display.has_ipc = 1,   
> > \
> > .display.has_psr = 1,   
> > \
> > .display.ver = 13,  
> > \
> > .display.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | 
> > BIT(PIPE_D), \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index e7d2cf7d65c85..c9660b4282d9e 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -180,7 +180,6 @@ enum intel_ppgtt_type {
> > func(has_hdcp); \
> > func(has_hotplug); \
> > func(has_hti); \
> > -   func(has_ipc); \
> > func(has_modular_fia); \
> > func(has_overlay); \
> > func(has_psr); \
> > -- 
> > 2.36.0
>