Re: [Intel-gfx] [PATCH v4 9/9] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Liu, Yi L]

> From: Tian, Kevin 
> Sent: Thursday, April 27, 2023 2:54 PM
> 
> > From: Liu, Yi L 
> > Sent: Wednesday, April 26, 2023 10:54 PM
> >
> > +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> > +   struct iommufd_ctx *iommufd_ctx)
> > +{
> > +   struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(&vdev-
> > >vdev);
> > +   struct iommu_group *iommu_group;
> > +
> > +   if (!iommufd_ctx)
> > +   return false;
> > +
> > +   if (iommufd == iommufd_ctx)
> > +   return true;
> > +
> > +   iommu_group = iommu_group_get(vdev->vdev.dev);
> > +   if (!iommu_group)
> > +   return false;
> > +
> > +   /*
> > +* Try to check if any device within iommu_group is bound with
> > +* the input iommufd_ctx.
> > +*/
> > +   return vfio_devset_iommufd_has_group(vdev->vdev.dev_set,
> > +iommufd_ctx, iommu_group);
> 
> iommu_group is not put.

Oops. Yes.

Re: [Intel-gfx] [PATCH v4 1/9] vfio: Determine noiommu in vfio_device registration

[Liu, Yi L]

> From: Tian, Kevin 
> Sent: Thursday, April 27, 2023 2:36 PM
> 
> > From: Liu, Yi L 
> > Sent: Wednesday, April 26, 2023 10:54 PM
> >
> > -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> > +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> >  {
> > -   return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > -  vdev->group->type == VFIO_NO_IOMMU;
> > +   device->noiommu = IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > + device->group->type == VFIO_NO_IOMMU;
> > +   return 0;
> 
> Just void. this can't fail.

Hmmm. Yes, before below commit, it cannot fail. Maybe this can be
converted to int later.

https://lore.kernel.org/kvm/20230426150321.454465-22-yi.l@intel.com/T/#u

Regards,
Yi Liu

Re: [Intel-gfx] [PATCH v4 6/9] iommufd: Reserved -1 in the iommufd xarray

[Liu, Yi L]

> From: Tian, Kevin 
> Sent: Thursday, April 27, 2023 2:42 PM
> 
> > From: Liu, Yi L 
> > Sent: Wednesday, April 26, 2023 10:54 PM
> >
> > VFIO needs two reserved values. 0 is already reserved by initializing
> > xarray with XA_FLAGS_ALLOC1. This reserves -1 by limiting the xa alloc
> > range.
> >
> > Signed-off-by: Yi Liu 
> > ---
> >  drivers/iommu/iommufd/main.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/iommufd/main.c
> > b/drivers/iommu/iommufd/main.c
> > index 3fbe636c3d8a..51b27c96c52f 100644
> > --- a/drivers/iommu/iommufd/main.c
> > +++ b/drivers/iommu/iommufd/main.c
> > @@ -28,6 +28,9 @@ struct iommufd_object_ops {
> >  static const struct iommufd_object_ops iommufd_object_ops[];
> >  static struct miscdevice vfio_misc_dev;
> >
> > +/* -1 is reserved */
> > +#define iommufd_xa_limit_32b XA_LIMIT(0, (-2U))
> > +
> >  struct iommufd_object *_iommufd_object_alloc(struct iommufd_ctx *ictx,
> >  size_t size,
> >  enum iommufd_object_type type)
> > @@ -50,7 +53,7 @@ struct iommufd_object *_iommufd_object_alloc(struct
> > iommufd_ctx *ictx,
> >  * before calling iommufd_object_finalize().
> >  */
> > rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY,
> > - xa_limit_32b, GFP_KERNEL_ACCOUNT);
> > + iommufd_xa_limit_32b, GFP_KERNEL_ACCOUNT);
> 
> Just direct use XA_LIMIT() here.

Ok.

> btw do we need a contract so vfio can learn 0 and -1 are reserved or
> fine to have a fixed assumption in later patches?

I doubt how to do it. ☹ @Jason? What about your opinion?

Regards,
Yi Liu

Re: [Intel-gfx] [PATCH v4 7/9] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device

[Liu, Yi L]

> From: Tian, Kevin 
> Sent: Thursday, April 27, 2023 2:46 PM
> 
> > From: Yi Liu
> > Sent: Wednesday, April 26, 2023 10:54 PM
> > +
> > +/*
> > + * Return devid for devices that have been bound with iommufd,
> > + * returns 0 if not bound yet.
> > + */
> > +u32 vfio_iommufd_physical_devid(struct vfio_device *vdev)
> > +{
> > +   if (WARN_ON(!vdev->iommufd_device && !vdev->iommufd_access))
> > +   return 0;
> 
> is WARN_ON too restrictive?

This originated from a comment from Eric[1]. At that time, this helper is
void type, hence there is no message when there is no devid. Now, this returns
0 if the device is not bound. Maybe checking it in the caller and warn on
there?

[1] https://lore.kernel.org/kvm/702c2883-1d51-b609-1e99-337295e6e...@redhat.com/

Regards,
Yi Liu

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Hugepage manager and test for MTL (rev2)

[Andrzej Hajda]

On 27.04.2023 00:29, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915: Hugepage manager and test for MTL (rev2)
*URL:*	https://patchwork.freedesktop.org/series/116995/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v2/index.html 




  CI Bug Log - changes from CI_DRM_13065 -> Patchwork_116995v2


Summary

*FAILURE*

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

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



Participating hosts (41 -> 39)

Missing (2): fi-kbl-soraka fi-snb-2520m


Possible new issues

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



  IGT changes


Possible regressions

  * igt@gem_exec_suspend@basic-s3@smem:
  o bat-rpls-1: NOTRUN -> ABORT





Known bug [1].
Other issues also seems not related.


[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/7978

Regards
Andrzej





Known issues

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



  IGT changes


Issues hit

  *

igt@i915_selftest@live@reset:

  o bat-rpls-2: NOTRUN -> ABORT


 (i915#7913 )
  *

igt@i915_selftest@live@slpc:

  o bat-rpls-1: NOTRUN -> FAIL


 (i915#6997 )


Possible fixes

  *

igt@i915_selftest@live@gt_heartbeat:

  o fi-apl-guc: FAIL


 -> PASS 

  *

igt@i915_selftest@live@mman:

  o bat-rpls-2: TIMEOUT


 (i915#7392 ) -> PASS 

  *

igt@i915_selftest@live@reset:

  o bat-rpls-1: ABORT


 (i915#8384 ) -> PASS 

  *

igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:

  o bat-dg2-8: FAIL


 (i915#7932 ) -> PASS 



Warnings

  * igt@i915_suspend@basic-s3-without-i915:
  o fi-tgl-1115g4: INCOMPLETE


 (i915#8102 ) -> INCOMPLETE 

 (i915#7443  / i915#8102 
)

{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_13065 -> Patchwork_116995v2

CI-20190529: 20190529
CI_DRM_13065: d7ded126c43e062a8ed119e55a797e4c616e1967 @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7272: b2786c0c504bb4fa9f2dc6082fe9332223198b24 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116995v2: d7ded126c43e062a8ed119e55a797e4c616e1967 @ 
git://anongit.freedesktop.org/gfx-ci/linux



  Linux commits

4ec1dd2a0fbf drm/i915: Use correct huge page manager for MTL
f3c4bc9f7fc9 drm/i915: Migrate platform-dependent mock hugepage 
selftests to live

Re: [Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA

[Manna, Animesh]

> -Original Message-
> From: Intel-gfx  On Behalf Of Mika
> Kahola
> Sent: Thursday, April 20, 2023 6:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates
> use MPLLA
> 
> Use MPLLA for DP2.0 rates 20G and 20G, when ssc is enabled.

Need to fix a typo here. It will be 10G and 20G.

Regards,
Animesh
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index f7720acaf58c..4231ba98f075 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2340,8 +2340,11 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>   val |=
> XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK);
> 
>   /* TODO: HDMI FRL */
> - /* TODO: DP2.0 10G and 20G rates enable MPLLA*/
> - val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLB : 0;
> + /* DP2.0 10G and 20G rates enable MPLLA*/
> + if (crtc_state->port_clock == 100 || crtc_state->port_clock ==
> 200)
> + val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLA : 0;
> + else
> + val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLB : 0;
> 
>   intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
>XELPDP_LANE1_PHY_CLOCK_SELECT |
> XELPDP_FORWARD_CLOCK_UNGATE |
> --
> 2.34.1

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq

[Andi Shyti]

Hi Vinay,

On Tue, Apr 25, 2023 at 05:39:41PM -0700, Vinay Belgaumkar wrote:
> SLPC enables use of efficient freq at init by default. It is
> possible for GuC to request frequencies that are higher than
> the 'software' max if user has set it lower than the efficient
> level.
> 
> Scenarios/tests that require strict fixing of freq below the efficient
> level will need to disable it through this interface.
> 
> v2: Keep just one interface to toggle sysfs. With this, user will
> be completely responsible for toggling efficient frequency if need
> be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)
> 
> v3: Remove unused label, review comments (Ashutosh)
> 
> v4: Toggle efficient freq usage in SLPC selftest and checkpatch fixes
> 
> v5: Review comments (Andi) and add a separate patch for selftest updates
> 
> Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient 
> frequency")
> Signed-off-by: Vinay Belgaumkar 
> Reviewed-by: Rodrigo Vivi 
> Reviewed-by: Ashutosh Dixit 

Reviewed-by: Andi Shyti  

Andi

> ---
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 35 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 38 +--
>  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |  1 +
>  .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |  1 +
>  4 files changed, 64 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 28f27091cd3b..ee2b44f896a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject 
> *kobj,
>   return sysfs_emit(buff, "%u\n", preq);
>  }
>  
> +static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
> +  struct kobj_attribute *attr,
> +  char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
> + struct intel_guc_slpc *slpc = >->uc.guc.slpc;
> +
> + return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
> +}
> +
> +static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
> +   struct kobj_attribute *attr,
> +   const char *buff, size_t count)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
> + struct intel_guc_slpc *slpc = >->uc.guc.slpc;
> + int err;
> + u32 val;
> +
> + err = kstrtou32(buff, 0, &val);
> + if (err)
> + return err;
> +
> + err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
> + return err ?: count;
> +}
> +
>  struct intel_gt_bool_throttle_attr {
>   struct attribute attr;
>   ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
> @@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale 
> =
>  INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
>  INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
>  
> +INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
> +
>  static const struct attribute *media_perf_power_attrs[] = {
>   &attr_media_freq_factor.attr,
>   &attr_media_freq_factor_scale.attr,
> @@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct 
> kobject *kobj)
>   if (ret)
>   gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)", 
> ERR_PTR(ret));
>  
> + if (intel_uc_uses_guc_slpc(>->uc)) {
> + ret = sysfs_create_file(kobj, &attr_slpc_ignore_eff_freq.attr);
> + if (ret)
> + gt_warn(gt, "failed to create ignore_eff_freq sysfs 
> (%pe)", ERR_PTR(ret));
> + }
> +
>   if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
>   ret = sysfs_create_files(kobj, throttle_reason_attrs);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index 026d73855f36..56dbba1ef668 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
>  
>   slpc->max_freq_softlimit = 0;
>   slpc->min_freq_softlimit = 0;
> + slpc->ignore_eff_freq = false;
>   slpc->min_is_rpmax = false;
>  
>   slpc->boost_freq = 0;
> @@ -457,6 +458,29 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc 
> *slpc, u32 *val)
>   return ret;
>  }
>  
> +int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
> +{
> + struct drm_i915_private *i915 = slpc_to_i915(slpc);
> + intel_wakeref_t wakeref;
> + int ret;
> +
> + mutex_lock(&slpc->lock);
> + wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> +
> + ret = slpc_set_param(slpc,
> +  SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> +  val);
> +   

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/selftest: Update the SLPC selftest

[Andi Shyti]

Hi Vinay,

On Tue, Apr 25, 2023 at 05:39:42PM -0700, Vinay Belgaumkar wrote:
> Use the new efficient frequency toggling interface. Also
> create a helper function to restore the frequencies after
> the test is done.
> 
> v2: Restore max freq first and then min.
> 
> Signed-off-by: Vinay Belgaumkar 

Reviewed-by: Andi Shyti  

Andi

Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout

[Kahola, Mika]

> -Original Message-
> From: Murthy, Arun R 
> Sent: Thursday, April 27, 2023 6:31 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K 
> Subject: RE: [PATCH 02/13] drm/i915/mtl: C20 HW readout
> 
> > -Original Message-
> > From: Kahola, Mika 
> > Sent: Thursday, April 20, 2023 6:11 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Kahola, Mika ; Murthy, Arun R
> > ; Nautiyal, Ankit K
> > 
> > Subject: [PATCH 02/13] drm/i915/mtl: C20 HW readout
> >
> > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > The PLL settings are based on table, not for algorithmic alternative.
> > For DP 1.4 only MPLLB is in use.
> >
> > Once register settings are done, we read back C20 HW state.
> >
> > BSpec: 64568
> >
> > Signed-off-by: Mika Kahola 
> > Signed-off-by: Arun R Murthy 
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 623 +-
> >  drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +-
> >  drivers/gpu/drm/i915/display/intel_ddi.c  |   9 +-
> >  .../drm/i915/display/intel_display_types.h|   1 +
> >  drivers/gpu/drm/i915/display/intel_hdmi.c |   6 +-
> >  drivers/gpu/drm/i915/display/intel_hdmi.h |   1 +
> >  6 files changed, 628 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index dd96bf5e179e..61428c5145e5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -11,6 +11,7 @@
> >  #include "intel_de.h"
> >  #include "intel_display_types.h"
> >  #include "intel_dp.h"
> > +#include "intel_hdmi.h"
> >  #include "intel_panel.h"
> >  #include "intel_psr.h"
> >  #include "intel_tc.h"
> > @@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct
> > drm_i915_private *i915, enum port port,
> > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > 1);  }
> >
> > +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum
> > +port
> > port,
> > +  int lane, u16 addr)
> > +{
> > +   u16 val;
> > +
> > +   assert_dc_off(i915);
> > +
> > +   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >>
> > 8, 0);
> > +   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr &
> > 0xff,
> > +1);
> > +
> > +   val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > +   val <<= 8;
> > +   val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > +
> > +   return val;
> > +}
> > +
> >  static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> > int lane, u16 addr, u8 clear, u8 set, bool
> > committed)  { @@ -659,6 +677,199 @@ static const struct
> > intel_c10pll_state
> > * const mtl_c10_edp_tables[] = {
> > NULL,
> >  };
> >
> > +/* C20 basic DP 1.4 tables */
> > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > +   .link_bit_rate = 162000,
> > +   .clock = 162000,
> > +   .tx = { 0xbe88, /* tx cfg0 */
> > +   0x5800, /* tx cfg1 */
> > +   0x, /* tx cfg2 */
> > +   },
> > +   .cmn = {0x0500, /* cmn cfg0*/
> > +   0x0005, /* cmn cfg1 */
> > +   0x, /* cmn cfg2 */
> > +   0x, /* cmn cfg3 */
> > +   },
> > +   .mpllb = { 0x50a8,  /* mpllb cfg0 */
> > +   0x2120, /* mpllb cfg1 */
> > +   0xcd9a, /* mpllb cfg2 */
> > +   0xbfc1, /* mpllb cfg3 */
> > +   0x5ab8, /* mpllb cfg4 */
> > +   0x4c34, /* mpllb cfg5 */
> > +   0x2000, /* mpllb cfg6 */
> > +   0x0001, /* mpllb cfg7 */
> > +   0x6000, /* mpllb cfg8 */
> > +   0x, /* mpllb cfg9 */
> > +   0x, /* mpllb cfg10 */
> > +   },
> > +};
> > +
> > +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > +   .link_bit_rate = 27,
> > +   .clock = 27,
> > +   .tx = { 0xbe88, /* tx cfg0 */
> > +   0x4800, /* tx cfg1 */
> > +   0x, /* tx cfg2 */
> > +   },
> > +   .cmn = {0x0500, /* cmn cfg0*/
> > +   0x0005, /* cmn cfg1 */
> > +   0x, /* cmn cfg2 */
> > +   0x, /* cmn cfg3 */
> > +   },
> > +   .mpllb = { 0x308c,  /* mpllb cfg0 */
> > +   0x2110, /* mpllb cfg1 */
> > +   0xcc9c, /* mpllb cfg2 */
> > +   0xbfc1, /* mpllb cfg3 */
> > +   0x489a, /* mpllb cfg4 */
> > +   0x3f81, /* mpllb cfg5 */
> > +   0x2000, /* mpllb cfg6 */
> > +   0x0001, /* mpllb cfg7 */
> > +   0x5000, /* mpllb cfg8 */
> > +   0x, /* mpllb cfg9 */
> > +   0x, /* mpllb cfg10 */
> > +   },
> > +};
> > +
> > +static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> > +   .link_bit_rate

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

[Joonas Lahtinen]

Hi Dave & Daniel,

Just one Cc stable SKL+ pipe source size fix for #8357: CML-U: external
5120x2160 monitor can't play video.

Best Regards, Joonas

***

drm-intel-next-fixes-2023-04-27:

One cc stable for pipe source size check on SKL+

The following changes since commit 2c69679626d5daa680d71c77ad58af0088db537f:

  drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams 
(2023-04-19 17:25:29 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2023-04-27

for you to fetch changes up to d944eafed618a8507270b324ad9d5405bb7f0b3e:

  drm/i915: Check pipe source size when using skl+ scalers (2023-04-24 14:48:42 
+0300)


One cc stable for pipe source size check on SKL+


Ville Syrjälä (1):
  drm/i915: Check pipe source size when using skl+ scalers

 drivers/gpu/drm/i915/display/skl_scaler.c | 17 +
 1 file changed, 17 insertions(+)

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

[Hogander, Jouni]

On Thu, 2023-03-09 at 14:34 +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2023 at 12:09:55PM +0100, Maarten Lankhorst wrote:
> > 
> > On 2023-03-09 12:04, Hogander, Jouni wrote:
> > > On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote:
> > > > On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst
> > > > wrote:
> > > > > Hey,
> > > > > 
> > > > > On 2023-03-06 16:23, Souza, Jose wrote:
> > > > > > 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.
> > > > > FBC and PSR work completely as expected. I don't remove
> > > > > frontbuffer
> > > > > tracking; I only remove the GEM parts.
> > > > > 
> > > > > Explicit invalidation using pageflip or CPU rendering +
> > > > > DirtyFB
> > > > > continue
> > > > > to work, as I validated on my laptop with FBC.
> > > > Neither of which are relevant to the removal of the gem hooks.
> > > > 
> > > > Like I already said ~10 times in the last meeting, we need a
> > > > proper
> > > > testcase. Here's a rough idea what it should do:
> > > > 
> > > > prepare a batch with
> > > > 1. spinner
> > > > 2. something that clobbers the fb
> > > > 
> > > > Then
> > > > 1. grab reference crc
> > > > 2. execbuffer
> > > > 3. dirtyfb
> > > > 4. wait long enough for fbc to recompress
> > > > 5. terminate spinner
> > > > 6. gem_sync
> > > > 7. grab crc and compare with reference
> > > > 
> > > > No idea what the current status of PSR+CRC is, so not sure
> > > > whether we can actually test PSR or not.
> > > > 
> > > CRC calculation doesn't work with PSR currently. PSR is disabled
> > > if CRC
> > > capture is requested.
> > > 
> > > Are we supposed to support frontbuffer rendering using GPU?
> > 
> > No other driver does that.
> 
> Every driver does that when you run X w/o a compositor. Assuming
> there is an actual GPU in there.
> 
> > It's fine if DirtyFB hangs instead until the 
> > job it waits on completes.
> 
> No one tried to make it just wait for the fence(s) w/o doing
> a full blown atomic commit. It might work, but might also
> still suck too much. I guess depends on how overloaded the GPU
> is.
> 
> What we could do is do a frontbuffer invalidate on dirtyfb
> invocation, and then once the fence(s) signal we do a frontbuffer
> flush. That would most closely match the gem hook behaviour, except
> the invalidate comes in a bit later. The alternative would be to
> skip the invalidate, which should still guarantee correctness in
> the end, just with possibly jankier interactivity.
> 

I have implemented this approach here:

https://patchwork.freedesktop.org/series/116620/

Review/comments are welcome.

BR,

Jouni Högander

Re: [Intel-gfx] [PATCH v4 6/9] iommufd: Reserved -1 in the iommufd xarray

[Jason Gunthorpe]

On Thu, Apr 27, 2023 at 07:09:38AM +, Liu, Yi L wrote:
> > > @@ -50,7 +53,7 @@ struct iommufd_object *_iommufd_object_alloc(struct
> > > iommufd_ctx *ictx,
> > >* before calling iommufd_object_finalize().
> > >*/
> > >   rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY,
> > > -   xa_limit_32b, GFP_KERNEL_ACCOUNT);
> > > +   iommufd_xa_limit_32b, GFP_KERNEL_ACCOUNT);
> > 
> > Just direct use XA_LIMIT() here.
> 
> Ok.
> 
> > btw do we need a contract so vfio can learn 0 and -1 are reserved or
> > fine to have a fixed assumption in later patches?
> 
> I doubt how to do it. ☹ @Jason? What about your opinion?

It is probably fine to use xa_limit_31b and just say that -ve values
are reserved in a comment near the define for 0

Jason

[Intel-gfx] [RFC 0/4] Expose RPS thresholds in sysfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

>From patch 4:

User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.

Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.

Note this patch supports non GuC based platforms only.

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

Issue 8389 suggests 10-15% performance gains are possible with tweaked
thresholds.

One question is are we able to find a "one size fits all" values.

However regardless of that, given we already expose frequency controls in sysfs
with the same reasoning of allowing system owners explicit control if so wanted,
I think exposing the thresholds can be equally justified.

Tvrtko Ursulin (4):
  drm/i915: Move setting of rps thresholds to init
  drm/i915: Record default rps threshold values
  drm/i915: Add helpers for managing rps thresholds
  drm/i915: Expose RPS thresholds in sysfs

 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 104 
 drivers/gpu/drm/i915/gt/intel_gt_types.h|   3 +
 drivers/gpu/drm/i915/gt/intel_rps.c |  65 +---
 drivers/gpu/drm/i915/gt/intel_rps.h |   4 +
 4 files changed, 165 insertions(+), 11 deletions(-)

-- 
2.37.2

[Intel-gfx] [RFC 1/4] drm/i915: Move setting of rps thresholds to init

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")
thresholds are invariant so lets move their setting to init time.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 80968e49e2c3..05ce71ec5add 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -670,7 +670,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 {
struct intel_gt *gt = rps_to_gt(rps);
struct intel_uncore *uncore = gt->uncore;
-   u32 threshold_up = 0, threshold_down = 0; /* in % */
u32 ei_up = 0, ei_down = 0;
 
lockdep_assert_held(&rps->power.mutex);
@@ -678,9 +677,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
if (new_power == rps->power.mode)
return;
 
-   threshold_up = 95;
-   threshold_down = 85;
-
/* Note the units here are not exactly 1us, but 1280ns. */
switch (new_power) {
case LOW_POWER:
@@ -707,17 +703,22 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 
GT_TRACE(gt,
 "changing power mode [%d], up %d%% @ %dus, down %d%% @ %dus\n",
-new_power, threshold_up, ei_up, threshold_down, ei_down);
+new_power,
+rps->power.up_threshold, ei_up,
+rps->power.down_threshold, ei_down);
 
set(uncore, GEN6_RP_UP_EI,
intel_gt_ns_to_pm_interval(gt, ei_up * 1000));
set(uncore, GEN6_RP_UP_THRESHOLD,
-   intel_gt_ns_to_pm_interval(gt, ei_up * threshold_up * 10));
+   intel_gt_ns_to_pm_interval(gt,
+  ei_up * rps->power.up_threshold * 10));
 
set(uncore, GEN6_RP_DOWN_EI,
intel_gt_ns_to_pm_interval(gt, ei_down * 1000));
set(uncore, GEN6_RP_DOWN_THRESHOLD,
-   intel_gt_ns_to_pm_interval(gt, ei_down * threshold_down * 10));
+   intel_gt_ns_to_pm_interval(gt,
+  ei_down *
+  rps->power.down_threshold * 10));
 
set(uncore, GEN6_RP_CONTROL,
(GRAPHICS_VER(gt->i915) > 9 ? 0 : GEN6_RP_MEDIA_TURBO) |
@@ -729,8 +730,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 
 skip_hw_write:
rps->power.mode = new_power;
-   rps->power.up_threshold = threshold_up;
-   rps->power.down_threshold = threshold_down;
 }
 
 static void gen6_rps_set_thresholds(struct intel_rps *rps, u8 val)
@@ -1556,10 +1555,12 @@ void intel_rps_enable(struct intel_rps *rps)
return;
 
GT_TRACE(rps_to_gt(rps),
-"min:%x, max:%x, freq:[%d, %d]\n",
+"min:%x, max:%x, freq:[%d, %d], thresholds:[%u, %u]\n",
 rps->min_freq, rps->max_freq,
 intel_gpu_freq(rps, rps->min_freq),
-intel_gpu_freq(rps, rps->max_freq));
+intel_gpu_freq(rps, rps->max_freq),
+rps->power.threshold_up,
+rps->power.threshold_down);
 
GEM_BUG_ON(rps->max_freq < rps->min_freq);
GEM_BUG_ON(rps->idle_freq > rps->max_freq);
@@ -2012,6 +2013,10 @@ void intel_rps_init(struct intel_rps *rps)
}
}
 
+   /* Set default thresholds in % */
+   rps->power.up_threshold = 95;
+   rps->power.down_threshold = 85;
+
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
rps->idle_freq = rps->min_freq;
-- 
2.37.2

[Intel-gfx] [RFC 2/4] drm/i915: Record default rps threshold values

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Record the default values as preparation for exposing the sysfs controls.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
 drivers/gpu/drm/i915/gt/intel_rps.c  | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f08c2556aa25..1b22d7a50665 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -83,6 +83,9 @@ enum intel_submission_method {
 struct gt_defaults {
u32 min_freq;
u32 max_freq;
+
+   u8 rps_up_threshold;
+   u8 rps_down_threshold;
 };
 
 enum intel_gt_type {
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 05ce71ec5add..343a50188c5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2015,7 +2015,9 @@ void intel_rps_init(struct intel_rps *rps)
 
/* Set default thresholds in % */
rps->power.up_threshold = 95;
+   rps_to_gt(rps)->defaults.rps_up_threshold = rps->power.up_threshold;
rps->power.down_threshold = 85;
+   rps_to_gt(rps)->defaults.rps_down_threshold = rps->power.down_threshold;
 
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
-- 
2.37.2

[Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.

Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.

Note this patch supports non GuC based platforms only.

Signed-off-by: Tvrtko Ursulin 
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 104 
 1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..df1f9ef08475 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -671,6 +671,76 @@ static const struct attribute *media_perf_power_attrs[] = {
NULL
 };
 
+static ssize_t
+rps_up_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+
+   return sysfs_emit(buf, "%u\n", intel_rps_get_up_threshold(rps));
+}
+
+static ssize_t
+rps_up_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+   int ret;
+   u8 val;
+
+   ret = kstrtou8(buf, 10, &val);
+   if (ret)
+   return ret;
+
+   ret = intel_rps_set_up_threshold(rps, val);
+
+   return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_up_threshold_pct =
+__ATTR(rps_up_threshold_pct, 0664,
+   rps_up_threshold_pct_show, rps_up_threshold_pct_store);
+
+static ssize_t
+rps_down_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+   char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+
+   return sysfs_emit(buf, "%u\n", intel_rps_get_down_threshold(rps));
+}
+
+static ssize_t
+rps_down_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+   int ret;
+   u8 val;
+
+   ret = kstrtou8(buf, 10, &val);
+   if (ret)
+   return ret;
+
+   ret = intel_rps_set_down_threshold(rps, val);
+
+   return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_down_threshold_pct =
+__ATTR(rps_down_threshold_pct, 0664,
+   rps_down_threshold_pct_show, rps_down_threshold_pct_store);
+
+static const struct attribute * const gen6_gt_rps_attrs[] = {
+   &rps_up_threshold_pct.attr,
+   &rps_down_threshold_pct.attr,
+   NULL
+};
+
 static ssize_t
 default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr, 
char *buf)
 {
@@ -693,9 +763,37 @@ default_max_freq_mhz_show(struct kobject *kobj, struct 
kobj_attribute *attr, cha
 static struct kobj_attribute default_max_freq_mhz =
 __ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
 
+static ssize_t
+default_rps_up_threshold_pct_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+   struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+   return sysfs_emit(buf, "%u\n", gt->defaults.rps_up_threshold);
+}
+
+static struct kobj_attribute default_rps_up_threshold_pct =
+__ATTR(rps_up_threshold_pct, 0444, default_rps_up_threshold_pct_show, NULL);
+
+static ssize_t
+default_rps_down_threshold_pct_show(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   char *buf)
+{
+   struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+   return sysfs_emit(buf, "%u\n", gt->defaults.rps_down_threshold);
+}
+
+static struct kobj_attribute default_rps_down_threshold_pct =
+__ATTR(rps_down_threshold_pct, 0444, default_rps_down_threshold_pct_show, 
NULL);
+
 static const struct attribute * const rps_defaults_attrs[] = {
&default_min_freq_mhz.attr,
&default_max_freq_mhz.attr,
+   &default_rps_up_threshold_pct.attr,
+   &default_rps_down_threshold_pct.attr,
NULL
 };
 
@@ -723,6 +821,12 @@ static int intel_sysfs_rps_init(struct intel_gt *gt, 
struct kobject *kobj)
if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915))
ret = sysfs_create_file(kobj, vlv_attr);
 
+   if (is_object_gt(kobj) && !intel_uc_uses_guc_slpc(>->uc)) {
+   ret = sysfs_create_files(kobj, gen6_gt_rps_attrs);
+   if (ret)
+   return ret;
+   }
+
retu

[Intel-gfx] [RFC 3/4] drm/i915: Add helpers for managing rps thresholds

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In preparation for exposing via sysfs add helpers for managing rps
thresholds.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 36 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  4 
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 343a50188c5e..c02b7104d11e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2573,6 +2573,42 @@ int intel_rps_set_min_frequency(struct intel_rps *rps, 
u32 val)
return set_min_freq(rps, val);
 }
 
+u8 intel_rps_get_up_threshold(struct intel_rps *rps)
+{
+   return rps->power.up_threshold;
+}
+
+static int rps_set_threshold(struct intel_rps *rps, u8 *threshold, u8 val)
+{
+   int ret;
+
+   if (val > 100)
+   return -EINVAL;
+
+   ret = mutex_lock_interruptible(&rps->lock);
+   if (ret)
+   return ret;
+   *threshold = val;
+   mutex_unlock(&rps->lock);
+
+   return 0;
+}
+
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold)
+{
+   return rps_set_threshold(rps, &rps->power.up_threshold, threshold);
+}
+
+u8 intel_rps_get_down_threshold(struct intel_rps *rps)
+{
+   return rps->power.down_threshold;
+}
+
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold)
+{
+   return rps_set_threshold(rps, &rps->power.down_threshold, threshold);
+}
+
 static void intel_rps_set_manual(struct intel_rps *rps, bool enable)
 {
struct intel_uncore *uncore = rps_to_uncore(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index a3fa987aa91f..92fb01f5a452 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -37,6 +37,10 @@ void intel_rps_mark_interactive(struct intel_rps *rps, bool 
interactive);
 
 int intel_gpu_freq(struct intel_rps *rps, int val);
 int intel_freq_opcode(struct intel_rps *rps, int val);
+u8 intel_rps_get_up_threshold(struct intel_rps *rps);
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold);
+u8 intel_rps_get_down_threshold(struct intel_rps *rps);
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold);
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
 u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
-- 
2.37.2

[Intel-gfx] [PATCH 0/6] Introduce sink_format and other fixes

[Ankit Nautiyal]

This patch series is part of a previous series:
https://patchwork.freedesktop.org/series/109470/

This adds new member sink_format to store the final format that the
sink will be using, which might be different than the output format,
and thus might need color/format conversion performed by the PCON.

Last patch just refactors some lines in mode_valid code for DP.

Ankit Nautiyal (6):
  drm/i915/display: Add new member to configure PCON color conversion
  drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state
sink_format
  drm/i915/dp: Configure PCON for conversion of output_format to
YCbCr444
  drm/i915/display: Use sink_format instead of ycbcr420_output flag
  drm/i915/dp: Add helper to get sink_format
  drm/i915/dp: Rearrange check for illegal mode and comments in
mode_valid

 drivers/gpu/drm/i915/display/icl_dsi.c|   1 +
 drivers/gpu/drm/i915/display/intel_crt.c  |   1 +
 .../drm/i915/display/intel_crtc_state_dump.c  |   5 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   5 +
 .../drm/i915/display/intel_display_types.h|  12 +-
 drivers/gpu/drm/i915/display/intel_dp.c   | 263 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   1 +
 drivers/gpu/drm/i915/display/intel_dvo.c  |   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |  71 +++--
 drivers/gpu/drm/i915/display/intel_hdmi.h |   5 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.c |   1 +
 drivers/gpu/drm/i915/display/intel_tv.c   |   1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c|   1 +
 14 files changed, 250 insertions(+), 119 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH 1/6] drm/i915/display: Add new member to configure PCON color conversion

[Ankit Nautiyal]

The decision to use DFP output format conversion capabilities should be
during compute_config phase.

This patch adds new member to crtc_state to represent the final
output_format to the sink. In case of a DFP this can be different than
the output_format, as per the format conversion done via the PCON.

This will help to store only the format conversion capabilities of the
DP device in intel_dp->dfp, and use crtc_state to compute and store the
configuration for color/format conversion for a given mode.

v2: modified the new member to crtc_state to represent the final
output_format that eaches the sink, after possible conversion by
PCON kind of devices. (Ville)

v3: Addressed comments from Ville:
-Added comments to clarify difference between sink_format and
output_format.
-Corrected the order of setting sink_format and output_format.
-Added readout for sink_format in get_pipe_config hooks.

v4: Set sink_format for intel_sdvo too. (Ville)

v5: Rebased.

v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville)

v7: Fix the condition to set sink_format for HDMI.
Set hdmi output_format simply as sink_format. (Ville)

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Ville Syrjälä  (v3)
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  1 +
 drivers/gpu/drm/i915/display/intel_crt.c  |  1 +
 .../drm/i915/display/intel_crtc_state_dump.c  |  5 +--
 drivers/gpu/drm/i915/display/intel_display.c  |  5 +++
 .../drm/i915/display/intel_display_types.h| 11 ++-
 drivers/gpu/drm/i915/display/intel_dp.c   | 33 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  1 +
 drivers/gpu/drm/i915/display/intel_dvo.c  |  1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c | 27 ++-
 drivers/gpu/drm/i915/display/intel_lvds.c |  1 +
 drivers/gpu/drm/i915/display/intel_sdvo.c |  1 +
 drivers/gpu/drm/i915/display/intel_tv.c   |  1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c|  1 +
 13 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ad78148e0788..2520a4314e0d 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1591,6 +1591,7 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
&pipe_config->hw.adjusted_mode;
int ret;
 
+   pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
 
ret = intel_panel_compute_config(intel_connector, adjusted_mode);
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 13519f78cf9f..f0f4897b3c3c 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -395,6 +395,7 @@ static int intel_crt_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
 
+   pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
 
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 0cdcaa49656f..27d7bab46427 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -217,10 +217,11 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
 
snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
drm_dbg_kms(&i915->drm,
-   "active: %s, output_types: %s (0x%x), output format: %s\n",
+   "active: %s, output_types: %s (0x%x), output format: %s, 
sink format: %s\n",
str_yes_no(pipe_config->hw.active),
buf, pipe_config->output_types,
-   intel_output_format_name(pipe_config->output_format));
+   intel_output_format_name(pipe_config->output_format),
+   intel_output_format_name(pipe_config->sink_format));
 
drm_dbg_kms(&i915->drm,
"cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..2860c40b73c4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2887,6 +2887,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
return false;
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   pipe_config->sink_format = pipe_config->output_format;
pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
pipe_config->shared_dpll = NULL;
 
@@ -3310,6 +3311,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
break;
}
 
+   pipe_config->sink_format = pipe_config-

[Intel-gfx] [PATCH 4/6] drm/i915/display: Use sink_format instead of ycbcr420_output flag

[Ankit Nautiyal]

Start passing the sink_format, to all functions that take a bool
ycbcr420_output as parameter. This will make the functions generic,
and will serve as a slight step towards 4:2:2 support later.

v2: Rebased.

v3: Correct the checks in places concerned with pipe output. (Ville)
Other minor styling and refactoring fixes, as suggested by Ville.

Suggested-by: Ville Syrjälä 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c   | 32 -
 drivers/gpu/drm/i915/display/intel_hdmi.c | 44 ++-
 drivers/gpu/drm/i915/display/intel_hdmi.h |  5 +--
 3 files changed, 45 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5468a362ef9f..e04989b67cdf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -997,7 +997,8 @@ static int intel_dp_max_tmds_clock(struct intel_dp 
*intel_dp)
 
 static enum drm_mode_status
 intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
- int clock, int bpc, bool ycbcr420_output,
+ int clock, int bpc,
+ enum intel_output_format sink_format,
  bool respect_downstream_limits)
 {
int tmds_clock, min_tmds_clock, max_tmds_clock;
@@ -1005,7 +1006,7 @@ intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
if (!respect_downstream_limits)
return MODE_OK;
 
-   tmds_clock = intel_hdmi_tmds_clock(clock, bpc, ycbcr420_output);
+   tmds_clock = intel_hdmi_tmds_clock(clock, bpc, sink_format);
 
min_tmds_clock = intel_dp->dfp.min_tmds_clock;
max_tmds_clock = intel_dp_max_tmds_clock(intel_dp);
@@ -1028,6 +1029,7 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
const struct drm_display_info *info = &connector->base.display_info;
enum drm_mode_status status;
bool ycbcr_420_only;
+   enum intel_output_format sink_format;
 
/* If PCON supports FRL MODE, check FRL bandwidth constraints */
if (intel_dp->dfp.pcon_max_frl_bw) {
@@ -1054,18 +1056,23 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
 
ycbcr_420_only = drm_mode_is_420_only(info, mode);
 
+   if (ycbcr_420_only)
+   sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+   else
+   sink_format = INTEL_OUTPUT_FORMAT_RGB;
+
/* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
-  8, ycbcr_420_only, true);
+  8, sink_format, true);
 
if (status != MODE_OK) {
-   if (ycbcr_420_only ||
+   if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
!connector->base.ycbcr_420_allowed ||
!drm_mode_is_420_also(info, mode))
return status;
-
+   sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
-  8, true, true);
+  8, sink_format, true);
if (status != MODE_OK)
return status;
}
@@ -1301,19 +1308,10 @@ static bool intel_dp_supports_dsc(struct intel_dp 
*intel_dp,
drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd);
 }
 
-static bool intel_dp_is_ycbcr420(struct intel_dp *intel_dp,
-const struct intel_crtc_state *crtc_state)
-{
-   return crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
-   (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
-intel_dp->dfp.ycbcr_444_to_420);
-}
-
 static int intel_dp_hdmi_compute_bpc(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state,
 int bpc, bool respect_downstream_limits)
 {
-   bool ycbcr420_output = intel_dp_is_ycbcr420(intel_dp, crtc_state);
int clock = crtc_state->hw.adjusted_mode.crtc_clock;
 
/*
@@ -1333,8 +1331,8 @@ static int intel_dp_hdmi_compute_bpc(struct intel_dp 
*intel_dp,
 
for (; bpc >= 8; bpc -= 2) {
if (intel_hdmi_bpc_possible(crtc_state, bpc,
-   intel_dp->has_hdmi_sink, 
ycbcr420_output) &&
-   intel_dp_tmds_clock_valid(intel_dp, clock, bpc, 
ycbcr420_output,
+   intel_dp->has_hdmi_sink) &&
+   intel_dp_tmds_clock_valid(intel_dp, clock, bpc, 
crtc_state->sink_format,
  respect_downstream_limits) == 
MODE_OK)
return bpc;
}
diff --git a/drivers/gpu/drm/i915/display/intel

[Intel-gfx] [PATCH 3/6] drm/i915/dp: Configure PCON for conversion of output_format to YCbCr444

[Ankit Nautiyal]

Handle the case with DP to HDMI PCON, where sink_format is set to YCbCr444.
In that case PCON is required to be configured to convert from given
output_format to YCbCR444.

v2: Drop drm_WARN for invalid case, let MISSING_CASE catch it. (Ville)

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

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c3dd165c7a44..5468a362ef9f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2910,6 +2910,17 @@ void intel_dp_configure_protocol_converter(struct 
intel_dp *intel_dp,
MISSING_CASE(crtc_state->output_format);
break;
}
+   } else if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+   switch (crtc_state->output_format) {
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   break;
+   case INTEL_OUTPUT_FORMAT_RGB:
+   rgb_to_ycbcr = true;
+   break;
+   default:
+   MISSING_CASE(crtc_state->output_format);
+   break;
+   }
}
 
tmp = ycbcr444_to_420 ? DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
-- 
2.25.1

[Intel-gfx] [PATCH 2/6] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format

[Ankit Nautiyal]

The decision to use DFP output format conversion capabilities should be
during compute_config phase.

This patch uses the members of intel_dp->dfp to only store the
format conversion capabilities of the DP device and uses the crtc_state
sink_format member, to program the protocol-converter for
colorspace/format conversion.

v2: Use sink_format to determine the color conversion config for the
pcon (Ville).

v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).

v4: Add helper to check if DP supports YCBCR420.

v5: Simplify logic for computing output_format, based on the given
sink_format. (Ville).
Added scaler constraint for YCbCr420 output.

v6: Split the patch for Scaler constraint for Ycbcr420.

v7: Simplify the policy for selecting output_format:
Always try for RGB first, followed by YCBCR444, and finally by YCBCR420.

v8: Removed redundant comments, minor refactoring. (Ville)

v9: Added member for ycbcr420 passthrough cap, fixed minor issues. (Ville)

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 171 --
 2 files changed, 119 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 806e6c7f1413..e7a61bce7d83 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1761,6 +1761,7 @@ struct intel_dp {
int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+   bool ycbcr420_passthrough;
bool rgb_to_ycbcr;
} dfp;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index be2327015b45..c3dd165c7a44 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -841,27 +841,88 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
return 0;
 }
 
+static bool source_can_output(struct intel_dp *intel_dp,
+ enum intel_output_format format)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   switch (format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   return true;
+
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   /*
+* No YCbCr output support on gmch platforms.
+* Also, ILK doesn't seem capable of DP YCbCr output.
+* The displayed image is severly corrupted. SNB+ is fine.
+*/
+   return !HAS_GMCH(i915) && !IS_IRONLAKE(i915);
+
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   /* Platform < Gen 11 cannot output YCbCr420 format */
+   return DISPLAY_VER(i915) >= 11;
+
+   default:
+   MISSING_CASE(format);
+   return false;
+   }
+}
+
+static bool
+dfp_can_convert_from_rgb(struct intel_dp *intel_dp,
+enum intel_output_format sink_format)
+{
+   if (!drm_dp_is_branch(intel_dp->dpcd))
+   return false;
+
+   if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
+   return intel_dp->dfp.rgb_to_ycbcr;
+
+   if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   return intel_dp->dfp.rgb_to_ycbcr &&
+   intel_dp->dfp.ycbcr_444_to_420;
+
+   return false;
+}
+
+static bool
+dfp_can_convert_from_ycbcr444(struct intel_dp *intel_dp,
+ enum intel_output_format sink_format)
+{
+   if (!drm_dp_is_branch(intel_dp->dpcd))
+   return false;
+
+   if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   return intel_dp->dfp.ycbcr_444_to_420;
+
+   return false;
+}
+
 static enum intel_output_format
 intel_dp_output_format(struct intel_connector *connector,
   enum intel_output_format sink_format)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   enum intel_output_format output_format;
 
if (intel_dp->force_dsc_output_format)
return intel_dp->force_dsc_output_format;
 
-   if (!connector->base.ycbcr_420_allowed ||
-   sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
-   return INTEL_OUTPUT_FORMAT_RGB;
+   if (sink_format == INTEL_OUTPUT_FORMAT_RGB ||
+   dfp_can_convert_from_rgb(intel_dp, sink_format))
+   output_format = INTEL_OUTPUT_FORMAT_RGB;
 
-   if (intel_dp->dfp.rgb_to_ycbcr &&
-   intel_dp->dfp.ycbcr_444_to_420)
-   return INTEL_OUTPUT_FORMAT_RGB;
+   else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+dfp_can_convert_from_ycbcr444(intel_dp, sink_format))
+   output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
 
-   if (intel_dp->dfp.ycbcr_444_to_420)
- 

[Intel-gfx] [PATCH 6/6] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid

[Ankit Nautiyal]

Check for MODE_H_ILLEGAL before calculating max rates, lanes etc.
Move comments about compressed bpp U6.4 format closer to where it is used.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index e07c5f3438b3..127533130e63 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1131,6 +1131,9 @@ intel_dp_mode_valid(struct drm_connector *_connector,
if (target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
 
+   if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
+   return MODE_H_ILLEGAL;
+
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
 
@@ -1138,13 +1141,6 @@ intel_dp_mode_valid(struct drm_connector *_connector,
mode_rate = intel_dp_link_required(target_clock,
   
intel_dp_mode_min_output_bpp(connector, mode));
 
-   if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
-   return MODE_H_ILLEGAL;
-
-   /*
-* Output bpp is stored in 6.4 format so right shift by 4 to get the
-* integer value since we support only integer values of bpp.
-*/
if (HAS_DSC(dev_priv) &&
drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
/*
@@ -1153,6 +1149,10 @@ intel_dp_mode_valid(struct drm_connector *_connector,
 */
int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
 
+   /*
+* Output bpp is stored in 6.4 format so right shift by 4 to 
get the
+* integer value since we support only integer values of bpp.
+*/
if (intel_dp_is_edp(intel_dp)) {
dsc_max_output_bpp =
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) 
>> 4;
-- 
2.25.1

[Intel-gfx] [PATCH 5/6] drm/i915/dp: Add helper to get sink_format

[Ankit Nautiyal]

Common function to get the sink format for a given mode for DP.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 30 -
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index e04989b67cdf..e07c5f3438b3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -946,17 +946,25 @@ static int intel_dp_output_bpp(enum intel_output_format 
output_format, int bpp)
return bpp;
 }
 
+static enum intel_output_format
+intel_dp_sink_format(struct intel_connector *connector,
+const struct drm_display_mode *mode)
+{
+   const struct drm_display_info *info = &connector->base.display_info;
+
+   if (drm_mode_is_420_only(info, mode))
+   return INTEL_OUTPUT_FORMAT_YCBCR420;
+
+   return INTEL_OUTPUT_FORMAT_RGB;
+}
+
 static int
 intel_dp_mode_min_output_bpp(struct intel_connector *connector,
 const struct drm_display_mode *mode)
 {
-   const struct drm_display_info *info = &connector->base.display_info;
enum intel_output_format output_format, sink_format;
 
-   if (drm_mode_is_420_only(info, mode))
-   sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
-   else
-   sink_format = INTEL_OUTPUT_FORMAT_RGB;
+   sink_format = intel_dp_sink_format(connector, mode);
 
output_format = intel_dp_output_format(connector, sink_format);
 
@@ -1028,7 +1036,6 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
struct intel_dp *intel_dp = intel_attached_dp(connector);
const struct drm_display_info *info = &connector->base.display_info;
enum drm_mode_status status;
-   bool ycbcr_420_only;
enum intel_output_format sink_format;
 
/* If PCON supports FRL MODE, check FRL bandwidth constraints */
@@ -1054,12 +1061,7 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
 
-   ycbcr_420_only = drm_mode_is_420_only(info, mode);
-
-   if (ycbcr_420_only)
-   sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
-   else
-   sink_format = INTEL_OUTPUT_FORMAT_RGB;
+   sink_format = intel_dp_sink_format(connector, mode);
 
/* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
@@ -2175,10 +2177,8 @@ intel_dp_compute_output_format(struct intel_encoder 
*encoder,
drm_dbg_kms(&i915->drm,
"YCbCr 4:2:0 mode but YCbCr 4:2:0 output not 
possible. Falling back to RGB.\n");
crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
-   } else if (ycbcr_420_only) {
-   crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
} else {
-   crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
+   crtc_state->sink_format = intel_dp_sink_format(connector, 
adjusted_mode);
}
 
crtc_state->output_format = intel_dp_output_format(connector, 
crtc_state->sink_format);
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdeman

[Vinod Govindapillai]

pmdemand support patches for MTL

SAGV configuration support for MTL

v2: added one missing patch in the previous version

v3: chekcpatch warning fixes
update index handling for the icl/tgl QGV point handling
program pmdemand code simplified

v4: update to debufs and pipe values pmdemand regiters
removed the macro usage in update_pmdemand_values

Mika Kahola (1):
  drm/i915/mtl: Add support for PM DEMAND

Vinod Govindapillai (7):
  drm/i915: fix the derating percentage for MTL
  drm/i915: update the QGV point frequency calculations
  drm/i915: store the peak bw per QGV point
  drm/i915: extract intel_bw_check_qgv_points()
  drm/i915: modify max_bw to return index to intel_bw_info
  drm/i915/mtl: find best QGV point and configure sagv
  drm/i915/display: provision to suppress drm_warn in
intel_get_crtc_new_encoder

 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/display/intel_bw.c   | 350 +-
 drivers/gpu/drm/i915/display/intel_bw.h   |   6 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  17 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   3 +-
 .../gpu/drm/i915/display/intel_display_core.h |   8 +
 .../drm/i915/display/intel_display_driver.c   |   7 +
 .../drm/i915/display/intel_display_power.c|   8 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   8 +-
 .../gpu/drm/i915/display/intel_pch_display.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
 drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
 drivers/gpu/drm/i915/display/intel_snps_phy.c |   2 +-
 drivers/gpu/drm/i915/i915_irq.c   |  21 +-
 drivers/gpu/drm/i915/i915_reg.h   |  36 +-
 16 files changed, 819 insertions(+), 133 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h

-- 
2.34.1

[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL

[Vinod Govindapillai]

Follow the values from bspec for the percentage overhead for
efficiency in MTL BW calculations.

Bspec: 64631

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 597d5816ad1b..ab405c48ca3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -379,7 +379,7 @@ static const struct intel_sa_info mtl_sa_info = {
.deburst = 32,
.deprogbwlimit = 38, /* GB/s */
.displayrtids = 256,
-   .derating = 20,
+   .derating = 10,
 };
 
 static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
intel_sa_info *sa)
-- 
2.34.1

[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

[Vinod Govindapillai]

>From MTL onwwards, pcode locks the QGV point based on peak BW of
the intended QGV point passed by the driver. So the peak BW
calculation must match the value expected by the pcode. Update
the calculations as per the Bspec.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index ab405c48ca3a..25ae4e5834d3 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private 
*dev_priv,
val2 = intel_uncore_read(&dev_priv->uncore,
 MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
-   sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
+   sp->dclk = (16667 * dclk + 500) / 1000;
sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
 
-- 
2.34.1

[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point

[Vinod Govindapillai]

In MTL onwards, pcode locks the GV point based on the peak BW
of a QGV point. So store the peak BW of all the QGV points.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c   | 7 +--
 drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 25ae4e5834d3..f5b6cd7f83b8 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -534,10 +534,13 @@ static int tgl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
 
bi->deratedbw[j] = min(maxdebw,
   bw * (100 - sa->derating) / 100);
+   bi->peakbw[j] = sp->dclk * num_channels *
+   qi.channel_width / 8;
 
drm_dbg_kms(&dev_priv->drm,
-   "BW%d / QGV %d: num_planes=%d 
deratedbw=%u\n",
-   i, j, bi->num_planes, bi->deratedbw[j]);
+   "BW%d / QGV %d: num_planes=%d deratedbw=%u 
peakbw: %u\n",
+   i, j, bi->num_planes, bi->deratedbw[j],
+   bi->peakbw[j]);
}
 
for (j = 0; j < qi.num_psf_points; j++) {
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index e36f88a39b86..9f66d734edf6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -314,6 +314,8 @@ struct intel_display {
unsigned int deratedbw[I915_NUM_QGV_POINTS];
/* for each PSF GV point */
unsigned int psf_bw[I915_NUM_PSF_GV_POINTS];
+   /* Peak BW for each QGV point */
+   unsigned int peakbw[I915_NUM_QGV_POINTS];
u8 num_qgv_points;
u8 num_psf_gv_points;
u8 num_planes;
-- 
2.34.1

[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info

[Vinod Govindapillai]

MTL uses the peak BW of a QGV point to lock the required QGV
point instead of the QGV index. Instead of passing the deratedbw
of the selected bw_info, return the index to the selected
bw_info so that either deratedbw or peakbw can be used based on
the platform.

v2: use idx to store index returned by max_bw_index functions

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a3b8512ebe8a..a7f501131bb6 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -592,8 +592,8 @@ static void dg2_get_bw_info(struct drm_i915_private *i915)
i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
 }
 
-static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
-  int num_planes, int qgv_point)
+static unsigned int icl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
 {
int i;
 
@@ -614,14 +614,14 @@ static unsigned int icl_max_bw(struct drm_i915_private 
*dev_priv,
return UINT_MAX;
 
if (num_planes >= bi->num_planes)
-   return bi->deratedbw[qgv_point];
+   return i;
}
 
return 0;
 }
 
-static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
-  int num_planes, int qgv_point)
+static unsigned int tgl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
 {
int i;
 
@@ -642,10 +642,10 @@ static unsigned int tgl_max_bw(struct drm_i915_private 
*dev_priv,
return UINT_MAX;
 
if (num_planes <= bi->num_planes)
-   return bi->deratedbw[qgv_point];
+   return i;
}
 
-   return dev_priv->display.bw.max[0].deratedbw[qgv_point];
+   return 0;
 }
 
 static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
@@ -822,12 +822,19 @@ static int icl_find_qgv_points(struct drm_i915_private 
*i915,
return ret;
 
for (i = 0; i < num_qgv_points; i++) {
+   unsigned int idx;
unsigned int max_data_rate;
 
if (DISPLAY_VER(i915) > 11)
-   max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+   idx = tgl_max_bw_index(i915, num_active_planes, i);
else
-   max_data_rate = icl_max_bw(i915, num_active_planes, i);
+   idx = icl_max_bw_index(i915, num_active_planes, i);
+
+   if (idx > ARRAY_SIZE(i915->display.bw.max))
+   continue;
+
+   max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
/*
 * We need to know which qgv point gives us
 * maximum bandwidth in order to disable SAGV
-- 
2.34.1

[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()

[Vinod Govindapillai]

Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
to facilitate future platform variations in handling SAGV
configurations.

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 235 +---
 1 file changed, 130 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index f5b6cd7f83b8..a3b8512ebe8a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,128 @@ intel_atomic_get_bw_state(struct intel_atomic_state 
*state)
return to_intel_bw_state(bw_state);
 }
 
+static int icl_find_qgv_points(struct drm_i915_private *i915,
+  unsigned int data_rate,
+  unsigned int num_active_planes,
+  const struct intel_bw_state *old_bw_state,
+  struct intel_bw_state *new_bw_state)
+{
+   unsigned int max_bw_point = 0;
+   unsigned int max_bw = 0;
+   unsigned int num_psf_gv_points = 
i915->display.bw.max[0].num_psf_gv_points;
+   unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+   u16 psf_points = 0;
+   u16 qgv_points = 0;
+   int i;
+   int ret;
+
+   ret = intel_atomic_lock_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < num_qgv_points; i++) {
+   unsigned int max_data_rate;
+
+   if (DISPLAY_VER(i915) > 11)
+   max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+   else
+   max_data_rate = icl_max_bw(i915, num_active_planes, i);
+   /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+   if (max_data_rate > max_bw) {
+   max_bw_point = i;
+   max_bw = max_data_rate;
+   }
+   if (max_data_rate >= data_rate)
+   qgv_points |= BIT(i);
+
+   drm_dbg_kms(&i915->drm, "QGV point %d: max bw %d required %d\n",
+   i, max_data_rate, data_rate);
+   }
+
+   for (i = 0; i < num_psf_gv_points; i++) {
+   unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+   if (max_data_rate >= data_rate)
+   psf_points |= BIT(i);
+
+   drm_dbg_kms(&i915->drm, "PSF GV point %d: max bw %d"
+   " required %d\n",
+   i, max_data_rate, data_rate);
+   }
+
+   /*
+* BSpec states that we always should have at least one allowed point
+* left, so if we couldn't - simply reject the configuration for obvious
+* reasons.
+*/
+   if (qgv_points == 0) {
+   drm_dbg_kms(&i915->drm, "No QGV points provide sufficient 
memory"
+   " bandwidth %d for display configuration(%d active 
planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   if (num_psf_gv_points > 0 && psf_points == 0) {
+   drm_dbg_kms(&i915->drm, "No PSF GV points provide sufficient 
memory"
+   " bandwidth %d for display configuration(%d active 
planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   /*
+* Leave only single point with highest bandwidth, if
+* we can't enable SAGV due to the increased memory latency it may
+* cause.
+*/
+   if (!intel_can_enable_sagv(i915, new_bw_state)) {
+   qgv_points = BIT(max_bw_point);
+   drm_dbg_kms(&i915->drm, "No SAGV, using single QGV point %d\n",
+   max_bw_point);
+   }
+
+   /*
+* We store the ones which need to be masked as that is what PCode
+* actually accepts as a parameter.
+*/
+   new_bw_state->qgv_points_mask =
+   ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
+   icl_qgv_points_mask(i915);
+
+   /*
+* If the actual mask had changed we need to make sure that
+* the commits are serialized(in case this is a nomodeset, nonblocking)
+*/
+   if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+   ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int intel_bw_check_qgv_points(

[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

[Vinod Govindapillai]

From: Mika Kahola 

Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).

Wa_14016740474 is added which applies to Xe_LPD+ display

v2: checkpatch warning fixes, simplify program pmdemand part

v3: update to dbufs and pipes values to pmdemand register(stan)
Removed the macro usage in update_pmdemand_values()

Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood 
Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Gustavo Sousa 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Gustavo Sousa 
Signed-off-by: Mika Kahola 
Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   7 +
 .../gpu/drm/i915/display/intel_display_core.h |   6 +
 .../drm/i915/display/intel_display_driver.c   |   7 +
 .../drm/i915/display/intel_display_power.c|   8 +
 drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
 drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
 drivers/gpu/drm/i915/i915_irq.c   |  21 +-
 drivers/gpu/drm/i915/i915_reg.h   |  36 +-
 9 files changed, 562 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..eb899fa86e51 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,7 +281,8 @@ i915-y += \
display/i9xx_wm.o \
display/skl_scaler.o \
display/skl_universal_plane.o \
-   display/skl_watermark.o
+   display/skl_watermark.o \
+   display/intel_pmdemand.o
 i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..f98e235fadc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -99,6 +99,7 @@
 #include "intel_pcode.h"
 #include "intel_pipe_crc.h"
 #include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
 #include "intel_pps.h"
 #include "intel_psr.h"
 #include "intel_sdvo.h"
@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
return ret;
}
 
+   ret = intel_pmdemand_atomic_check(state);
+   if (ret)
+   goto fail;
+
ret = intel_atomic_check_crtcs(state);
if (ret)
goto fail;
@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
}
 
intel_sagv_pre_plane_update(state);
+   intel_pmdemand_pre_plane_update(state);
 
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_verify_planes(state);
 
intel_sagv_post_plane_update(state);
+   intel_pmdemand_post_plane_update(state);
 
drm_atomic_helper_commit_hw_done(&state->base);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 9f66d734edf6..9471a052aa57 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,12 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
 
+   struct {
+   wait_queue_head_t waitqueue;
+   struct mutex lock;
+   struct intel_global_obj obj;
+   } pmdemand;
+
struct {
/*
 * dkl.phy_lock protects against concurrent access of the
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..79853d8c3240 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -47,6 +47,7 @@
 #include "intel_opregion.h"
 #include "intel_overlay.h"
 #include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
 #include "intel_pps.h"
 #include "intel_quirks.h"
 #include "intel_vga.h"
@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct 
drm_i915_private *i915)
if (ret < 0)
goto cleanup_vga;
 
+   intel_pmdemand_init(i915);
+
intel_power_domains_init_hw(i915, false);
 
if (!HAS_DISPLAY(i915))
@@ -240,6 +243,10 @@ int intel_display_driver_probe_noirq(struct 
drm_i915_pr

[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder

[Vinod Govindapillai]

While configuring pmdemand parameters, there could be
intel_get_crtc_new_encoder call where encoders could be 0. To avoid
invoking drm_warn in such cases, use a parameter to indicate drm_warn
should be suppressed.

v2: checkpatch warning fixes

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 10 ++
 drivers/gpu/drm/i915/display/intel_display.h |  3 ++-
 drivers/gpu/drm/i915/display/intel_dpll.c|  8 
 drivers/gpu/drm/i915/display/intel_pch_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_pmdemand.c|  2 +-
 drivers/gpu/drm/i915/display/intel_snps_phy.c|  2 +-
 7 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..e91fdd5a26c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1879,7 +1879,7 @@ void intel_c10pll_state_verify(struct intel_atomic_state 
*state,
!intel_crtc_needs_fastset(new_crtc_state))
return;
 
-   encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
+   encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
phy = intel_port_to_phy(i915, encoder->port);
 
if (!intel_is_c10phy(i915, phy))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f98e235fadc6..4cadda4acce4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct drm_i915_private 
*dev_priv)
  */
 struct intel_encoder *
 intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
-  const struct intel_crtc_state *crtc_state)
+  const struct intel_crtc_state *crtc_state,
+  bool warn)
 {
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
@@ -782,9 +783,10 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state 
*state,
num_encoders++;
}
 
-   drm_WARN(state->base.dev, num_encoders != 1,
-"%d encoders for pipe %c\n",
-num_encoders, pipe_name(master_crtc->pipe));
+   if (warn)
+   drm_WARN(state->base.dev, num_encoders != 1,
+"%d encoders for pipe %c\n",
+num_encoders, pipe_name(master_crtc->pipe));
 
return encoder;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..4620ed991ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct intel_plane_state 
*plane_state);
 
 struct intel_encoder *
 intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
-  const struct intel_crtc_state *crtc_state);
+  const struct intel_crtc_state *crtc_state,
+  bool warn);
 void intel_plane_disable_noatomic(struct intel_crtc *crtc,
  struct intel_plane *plane);
 void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index a9fbef0fa817..9d30f273130e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct intel_atomic_state 
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
 
if (DISPLAY_VER(dev_priv) < 11 &&
@@ -969,7 +969,7 @@ static int hsw_crtc_get_shared_dpll(struct 
intel_atomic_state *state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
 
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
@@ -984,7 +984,7 @@ static int dg2_crtc_compute_clock(struct intel_atomic_state 
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;

[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv

[Vinod Govindapillai]

>From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 87 -
 drivers/gpu/drm/i915/display/intel_bw.h |  6 ++
 2 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a7f501131bb6..70fa469c3c20 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,85 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
 }
 
+static int mtl_find_qgv_points(struct drm_i915_private *i915,
+  unsigned int data_rate,
+  unsigned int num_active_planes,
+  const struct intel_bw_state *old_bw_state,
+  struct intel_bw_state *new_bw_state)
+{
+   unsigned int best_rate = UINT_MAX;
+   unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+   unsigned int qgv_peak_bw  = 0;
+   int i;
+   int ret;
+
+   ret = intel_atomic_lock_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+
+   /*
+* If SAGV cannot be enabled, disable the pcode SAGV by passing all 1's
+* for qgv peak bw in PM Demand request. So assign UINT_MAX if SAGV is
+* not enabled. PM Demand code will clamp the value for the register
+*/
+   if (!intel_can_enable_sagv(i915, new_bw_state)) {
+   new_bw_state->qgv_point_peakbw = UINT_MAX;
+   drm_dbg_kms(&i915->drm, "No SAGV, use UINT_MAX as peak bw.");
+   goto out;
+   }
+
+   /*
+* Find the best QGV point by comparing the data_rate with max data rate
+* offered per plane group
+*/
+   for (i = 0; i < num_qgv_points; i++) {
+   unsigned int bw_index =
+   tgl_max_bw_index(i915, num_active_planes, i);
+   unsigned int max_data_rate;
+
+   if (bw_index > ARRAY_SIZE(i915->display.bw.max))
+   continue;
+
+   max_data_rate = i915->display.bw.max[bw_index].deratedbw[i];
+
+   if (max_data_rate < data_rate)
+   continue;
+
+   if (max_data_rate - data_rate < best_rate) {
+   best_rate = max_data_rate - data_rate;
+   qgv_peak_bw = i915->display.bw.max[bw_index].peakbw[i];
+   }
+
+   drm_dbg_kms(&i915->drm, "QGV point %d: max bw %d required %d 
qgv_peak_bw: %d\n",
+   i, max_data_rate, data_rate, qgv_peak_bw);
+   }
+
+   drm_dbg_kms(&i915->drm, "Matching peaks QGV bw: %d for required data 
rate: %d\n",
+   qgv_peak_bw, data_rate);
+
+   /*
+* The display configuration cannot be supported if no QGV point
+* satisfying the require data rate is found
+*/
+   if (qgv_peak_bw == 0) {
+   drm_dbg_kms(&i915->drm, "No QGV points for bw %d for display 
configuration(%d active planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   /* MTL PM DEMAND expects QGV BW parameter in multiples of 100 mbps */
+   new_bw_state->qgv_point_peakbw = qgv_peak_bw / 100;
+
+out:
+   if (new_bw_state->qgv_point_peakbw != old_bw_state->qgv_point_peakbw)  {
+   ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 static int icl_find_qgv_points(struct drm_i915_private *i915,
   unsigned int data_rate,
   unsigned int num_active_planes,
@@ -927,8 +1006,12 @@ static int intel_bw_check_qgv_points(struct 
drm_i915_private *i915,
 
data_rate = DIV_ROUND_UP(data_rate, 1000);
 
-   return icl_find_qgv_points(i915, data_rate, num_active_planes,
-  old_bw_state, new_bw_state);
+   if (DISPLAY_VER(i915) >= 14)
+   return mtl_find_qgv_points(i915, data_rate, num_active_planes,
+  old_bw_state, new_bw_state);
+   else
+   return icl_find_qgv_points(i915, data_rate, num_active_planes,
+  old_bw_state, new_bw_state);
 }
 
 static bool intel_bw_state_changed(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..fc32f1eace85 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -34,6 +34,12 @@ struct intel_bw_state {
/

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

[Tvrtko Ursulin]

On 26/04/2023 16:41, Yang, Fei wrote:

 > On 26/04/2023 07:24, fei.y...@intel.com wrote:
 >> From: Fei Yang 
 >>
 >> The first three patches in this series are taken from
 >> https://patchwork.freedesktop.org/series/116868/
 >> These patches are included here because the last patch
 >> has dependency on the pat_index refactor.
 >>
 >> This series is focusing on uAPI changes,
 >> 1. end support for set caching ioctl [PATCH 4/5]
 >> 2. add set_pat extension for gem_create [PATCH 5/5]
 >>
 >> v2: drop one patch that was merged separately
 >>      341ad0e8e254 drm/i915/mtl: Add PTE encode function
 >
 > Are the re-sends for stabilizing the series, or focusing on merge?

v2 was sent just to drop one of patches that has already been merged.

 > If the latter then opens are:
 >
 > 1) Link to Mesa MR reviewed and ready to merge.
 >
 > 2) IGT reviewed.
 >
 > 3) I raised an open that get/set_caching should not "lie" but return an
 > error if set pat extension has been used. I don't see a good reason not
 > to do that.

I don't think it's "lying" to the userspace. the comparison is only valid
for objects created by KMD because only such object uses the pat_index
from the cachelevel_to_pat table.


Lets double check my understanding is correct. Userspace sequence of 
operations:


1)
obj = gem_create()+set_pat(PAT_UC)

2a)
get_caching(obj)

What gets reported?

2b)
set_caching(obj, I915_CACHE_LLC)

What is the return code?

If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please 
state a good reason why both shouldn't return an error.




 > + Joonas on this one.
 >
 > 4) Refactoring as done is not very pretty and I proposed an idea for a
 > nicer approach. Feasible or not, open for discussion.

Still digesting your proposal. but not sure how would you define things
like PAT_UC as that is platform dependent, not a constant.


"PAT_UC" in my outline was purely a driver specific value, similarly as 
I915_CACHE_... are. With the whole point that driver can ask if 
something is uncached, WT or whatever. Using the platform specific 
mapping table which converts platform specific obj->pat_index to driver 
representation of caching modes (PAT_UC etc).


Quite possible I missed some detail, but if I haven't then it could be 
a neat and lightweight solution.


Regards,

Tvrtko

[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL

[Vinod Govindapillai]

Follow the values from bspec for the percentage overhead for
efficiency in MTL BW calculations.

Bspec: 64631

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 597d5816ad1b..ab405c48ca3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -379,7 +379,7 @@ static const struct intel_sa_info mtl_sa_info = {
.deburst = 32,
.deprogbwlimit = 38, /* GB/s */
.displayrtids = 256,
-   .derating = 20,
+   .derating = 10,
 };
 
 static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
intel_sa_info *sa)
-- 
2.34.1

[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdemand

[Vinod Govindapillai]

pmdemand support patches for MTL

SAGV configuration support for MTL

v2: added one missing patch in the previous version

v3: chekcpatch warning fixes
update index handling for the icl/tgl QGV point handling
program pmdemand code simplified

v4: update to debufs and pipe values pmdemand regiters
removed the macro usage in update_pmdemand_values

Mika Kahola (1):
  drm/i915/mtl: Add support for PM DEMAND

Vinod Govindapillai (7):
  drm/i915: fix the derating percentage for MTL
  drm/i915: update the QGV point frequency calculations
  drm/i915: store the peak bw per QGV point
  drm/i915: extract intel_bw_check_qgv_points()
  drm/i915: modify max_bw to return index to intel_bw_info
  drm/i915/mtl: find best QGV point and configure sagv
  drm/i915/display: provision to suppress drm_warn in
intel_get_crtc_new_encoder

 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/display/intel_bw.c   | 350 +-
 drivers/gpu/drm/i915/display/intel_bw.h   |   6 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  17 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   3 +-
 .../gpu/drm/i915/display/intel_display_core.h |   8 +
 .../drm/i915/display/intel_display_driver.c   |   7 +
 .../drm/i915/display/intel_display_power.c|   8 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   8 +-
 .../gpu/drm/i915/display/intel_pch_display.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
 drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
 drivers/gpu/drm/i915/display/intel_snps_phy.c |   2 +-
 drivers/gpu/drm/i915/i915_irq.c   |  21 +-
 drivers/gpu/drm/i915/i915_reg.h   |  36 +-
 16 files changed, 819 insertions(+), 133 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h

-- 
2.34.1

[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

[Vinod Govindapillai]

>From MTL onwwards, pcode locks the QGV point based on peak BW of
the intended QGV point passed by the driver. So the peak BW
calculation must match the value expected by the pcode. Update
the calculations as per the Bspec.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index ab405c48ca3a..25ae4e5834d3 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private 
*dev_priv,
val2 = intel_uncore_read(&dev_priv->uncore,
 MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
-   sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
+   sp->dclk = (16667 * dclk + 500) / 1000;
sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
 
-- 
2.34.1

[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point

[Vinod Govindapillai]

In MTL onwards, pcode locks the GV point based on the peak BW
of a QGV point. So store the peak BW of all the QGV points.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c   | 7 +--
 drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 25ae4e5834d3..f5b6cd7f83b8 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -534,10 +534,13 @@ static int tgl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
 
bi->deratedbw[j] = min(maxdebw,
   bw * (100 - sa->derating) / 100);
+   bi->peakbw[j] = sp->dclk * num_channels *
+   qi.channel_width / 8;
 
drm_dbg_kms(&dev_priv->drm,
-   "BW%d / QGV %d: num_planes=%d 
deratedbw=%u\n",
-   i, j, bi->num_planes, bi->deratedbw[j]);
+   "BW%d / QGV %d: num_planes=%d deratedbw=%u 
peakbw: %u\n",
+   i, j, bi->num_planes, bi->deratedbw[j],
+   bi->peakbw[j]);
}
 
for (j = 0; j < qi.num_psf_points; j++) {
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index e36f88a39b86..9f66d734edf6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -314,6 +314,8 @@ struct intel_display {
unsigned int deratedbw[I915_NUM_QGV_POINTS];
/* for each PSF GV point */
unsigned int psf_bw[I915_NUM_PSF_GV_POINTS];
+   /* Peak BW for each QGV point */
+   unsigned int peakbw[I915_NUM_QGV_POINTS];
u8 num_qgv_points;
u8 num_psf_gv_points;
u8 num_planes;
-- 
2.34.1

[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()

[Vinod Govindapillai]

Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
to facilitate future platform variations in handling SAGV
configurations.

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 235 +---
 1 file changed, 130 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index f5b6cd7f83b8..a3b8512ebe8a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,128 @@ intel_atomic_get_bw_state(struct intel_atomic_state 
*state)
return to_intel_bw_state(bw_state);
 }
 
+static int icl_find_qgv_points(struct drm_i915_private *i915,
+  unsigned int data_rate,
+  unsigned int num_active_planes,
+  const struct intel_bw_state *old_bw_state,
+  struct intel_bw_state *new_bw_state)
+{
+   unsigned int max_bw_point = 0;
+   unsigned int max_bw = 0;
+   unsigned int num_psf_gv_points = 
i915->display.bw.max[0].num_psf_gv_points;
+   unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+   u16 psf_points = 0;
+   u16 qgv_points = 0;
+   int i;
+   int ret;
+
+   ret = intel_atomic_lock_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < num_qgv_points; i++) {
+   unsigned int max_data_rate;
+
+   if (DISPLAY_VER(i915) > 11)
+   max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+   else
+   max_data_rate = icl_max_bw(i915, num_active_planes, i);
+   /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+   if (max_data_rate > max_bw) {
+   max_bw_point = i;
+   max_bw = max_data_rate;
+   }
+   if (max_data_rate >= data_rate)
+   qgv_points |= BIT(i);
+
+   drm_dbg_kms(&i915->drm, "QGV point %d: max bw %d required %d\n",
+   i, max_data_rate, data_rate);
+   }
+
+   for (i = 0; i < num_psf_gv_points; i++) {
+   unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+   if (max_data_rate >= data_rate)
+   psf_points |= BIT(i);
+
+   drm_dbg_kms(&i915->drm, "PSF GV point %d: max bw %d"
+   " required %d\n",
+   i, max_data_rate, data_rate);
+   }
+
+   /*
+* BSpec states that we always should have at least one allowed point
+* left, so if we couldn't - simply reject the configuration for obvious
+* reasons.
+*/
+   if (qgv_points == 0) {
+   drm_dbg_kms(&i915->drm, "No QGV points provide sufficient 
memory"
+   " bandwidth %d for display configuration(%d active 
planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   if (num_psf_gv_points > 0 && psf_points == 0) {
+   drm_dbg_kms(&i915->drm, "No PSF GV points provide sufficient 
memory"
+   " bandwidth %d for display configuration(%d active 
planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   /*
+* Leave only single point with highest bandwidth, if
+* we can't enable SAGV due to the increased memory latency it may
+* cause.
+*/
+   if (!intel_can_enable_sagv(i915, new_bw_state)) {
+   qgv_points = BIT(max_bw_point);
+   drm_dbg_kms(&i915->drm, "No SAGV, using single QGV point %d\n",
+   max_bw_point);
+   }
+
+   /*
+* We store the ones which need to be masked as that is what PCode
+* actually accepts as a parameter.
+*/
+   new_bw_state->qgv_points_mask =
+   ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
+   icl_qgv_points_mask(i915);
+
+   /*
+* If the actual mask had changed we need to make sure that
+* the commits are serialized(in case this is a nomodeset, nonblocking)
+*/
+   if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+   ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int intel_bw_check_qgv_points(

[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info

[Vinod Govindapillai]

MTL uses the peak BW of a QGV point to lock the required QGV
point instead of the QGV index. Instead of passing the deratedbw
of the selected bw_info, return the index to the selected
bw_info so that either deratedbw or peakbw can be used based on
the platform.

v2: use idx to store index returned by max_bw_index functions

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a3b8512ebe8a..a7f501131bb6 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -592,8 +592,8 @@ static void dg2_get_bw_info(struct drm_i915_private *i915)
i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
 }
 
-static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
-  int num_planes, int qgv_point)
+static unsigned int icl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
 {
int i;
 
@@ -614,14 +614,14 @@ static unsigned int icl_max_bw(struct drm_i915_private 
*dev_priv,
return UINT_MAX;
 
if (num_planes >= bi->num_planes)
-   return bi->deratedbw[qgv_point];
+   return i;
}
 
return 0;
 }
 
-static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
-  int num_planes, int qgv_point)
+static unsigned int tgl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
 {
int i;
 
@@ -642,10 +642,10 @@ static unsigned int tgl_max_bw(struct drm_i915_private 
*dev_priv,
return UINT_MAX;
 
if (num_planes <= bi->num_planes)
-   return bi->deratedbw[qgv_point];
+   return i;
}
 
-   return dev_priv->display.bw.max[0].deratedbw[qgv_point];
+   return 0;
 }
 
 static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
@@ -822,12 +822,19 @@ static int icl_find_qgv_points(struct drm_i915_private 
*i915,
return ret;
 
for (i = 0; i < num_qgv_points; i++) {
+   unsigned int idx;
unsigned int max_data_rate;
 
if (DISPLAY_VER(i915) > 11)
-   max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+   idx = tgl_max_bw_index(i915, num_active_planes, i);
else
-   max_data_rate = icl_max_bw(i915, num_active_planes, i);
+   idx = icl_max_bw_index(i915, num_active_planes, i);
+
+   if (idx > ARRAY_SIZE(i915->display.bw.max))
+   continue;
+
+   max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
/*
 * We need to know which qgv point gives us
 * maximum bandwidth in order to disable SAGV
-- 
2.34.1

[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv

[Vinod Govindapillai]

>From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.

Bspec: 64636

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 87 -
 drivers/gpu/drm/i915/display/intel_bw.h |  6 ++
 2 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a7f501131bb6..70fa469c3c20 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,85 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
 }
 
+static int mtl_find_qgv_points(struct drm_i915_private *i915,
+  unsigned int data_rate,
+  unsigned int num_active_planes,
+  const struct intel_bw_state *old_bw_state,
+  struct intel_bw_state *new_bw_state)
+{
+   unsigned int best_rate = UINT_MAX;
+   unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+   unsigned int qgv_peak_bw  = 0;
+   int i;
+   int ret;
+
+   ret = intel_atomic_lock_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+
+   /*
+* If SAGV cannot be enabled, disable the pcode SAGV by passing all 1's
+* for qgv peak bw in PM Demand request. So assign UINT_MAX if SAGV is
+* not enabled. PM Demand code will clamp the value for the register
+*/
+   if (!intel_can_enable_sagv(i915, new_bw_state)) {
+   new_bw_state->qgv_point_peakbw = UINT_MAX;
+   drm_dbg_kms(&i915->drm, "No SAGV, use UINT_MAX as peak bw.");
+   goto out;
+   }
+
+   /*
+* Find the best QGV point by comparing the data_rate with max data rate
+* offered per plane group
+*/
+   for (i = 0; i < num_qgv_points; i++) {
+   unsigned int bw_index =
+   tgl_max_bw_index(i915, num_active_planes, i);
+   unsigned int max_data_rate;
+
+   if (bw_index > ARRAY_SIZE(i915->display.bw.max))
+   continue;
+
+   max_data_rate = i915->display.bw.max[bw_index].deratedbw[i];
+
+   if (max_data_rate < data_rate)
+   continue;
+
+   if (max_data_rate - data_rate < best_rate) {
+   best_rate = max_data_rate - data_rate;
+   qgv_peak_bw = i915->display.bw.max[bw_index].peakbw[i];
+   }
+
+   drm_dbg_kms(&i915->drm, "QGV point %d: max bw %d required %d 
qgv_peak_bw: %d\n",
+   i, max_data_rate, data_rate, qgv_peak_bw);
+   }
+
+   drm_dbg_kms(&i915->drm, "Matching peaks QGV bw: %d for required data 
rate: %d\n",
+   qgv_peak_bw, data_rate);
+
+   /*
+* The display configuration cannot be supported if no QGV point
+* satisfying the require data rate is found
+*/
+   if (qgv_peak_bw == 0) {
+   drm_dbg_kms(&i915->drm, "No QGV points for bw %d for display 
configuration(%d active planes).\n",
+   data_rate, num_active_planes);
+   return -EINVAL;
+   }
+
+   /* MTL PM DEMAND expects QGV BW parameter in multiples of 100 mbps */
+   new_bw_state->qgv_point_peakbw = qgv_peak_bw / 100;
+
+out:
+   if (new_bw_state->qgv_point_peakbw != old_bw_state->qgv_point_peakbw)  {
+   ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 static int icl_find_qgv_points(struct drm_i915_private *i915,
   unsigned int data_rate,
   unsigned int num_active_planes,
@@ -927,8 +1006,12 @@ static int intel_bw_check_qgv_points(struct 
drm_i915_private *i915,
 
data_rate = DIV_ROUND_UP(data_rate, 1000);
 
-   return icl_find_qgv_points(i915, data_rate, num_active_planes,
-  old_bw_state, new_bw_state);
+   if (DISPLAY_VER(i915) >= 14)
+   return mtl_find_qgv_points(i915, data_rate, num_active_planes,
+  old_bw_state, new_bw_state);
+   else
+   return icl_find_qgv_points(i915, data_rate, num_active_planes,
+  old_bw_state, new_bw_state);
 }
 
 static bool intel_bw_state_changed(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..fc32f1eace85 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -34,6 +34,12 @@ struct intel_bw_state {
/

[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

[Vinod Govindapillai]

From: Mika Kahola 

Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).

Wa_14016740474 is added which applies to Xe_LPD+ display

v2: checkpatch warning fixes, simplify program pmdemand part

v3: update to dbufs and pipes values to pmdemand register(stan)
Removed the macro usage in update_pmdemand_values()

Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood 
Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Gustavo Sousa 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Gustavo Sousa 
Signed-off-by: Mika Kahola 
Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   7 +
 .../gpu/drm/i915/display/intel_display_core.h |   6 +
 .../drm/i915/display/intel_display_driver.c   |   7 +
 .../drm/i915/display/intel_display_power.c|   8 +
 drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
 drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
 drivers/gpu/drm/i915/i915_irq.c   |  21 +-
 drivers/gpu/drm/i915/i915_reg.h   |  36 +-
 9 files changed, 562 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..eb899fa86e51 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,7 +281,8 @@ i915-y += \
display/i9xx_wm.o \
display/skl_scaler.o \
display/skl_universal_plane.o \
-   display/skl_watermark.o
+   display/skl_watermark.o \
+   display/intel_pmdemand.o
 i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..f98e235fadc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -99,6 +99,7 @@
 #include "intel_pcode.h"
 #include "intel_pipe_crc.h"
 #include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
 #include "intel_pps.h"
 #include "intel_psr.h"
 #include "intel_sdvo.h"
@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
return ret;
}
 
+   ret = intel_pmdemand_atomic_check(state);
+   if (ret)
+   goto fail;
+
ret = intel_atomic_check_crtcs(state);
if (ret)
goto fail;
@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
}
 
intel_sagv_pre_plane_update(state);
+   intel_pmdemand_pre_plane_update(state);
 
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_verify_planes(state);
 
intel_sagv_post_plane_update(state);
+   intel_pmdemand_post_plane_update(state);
 
drm_atomic_helper_commit_hw_done(&state->base);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 9f66d734edf6..9471a052aa57 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,12 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
 
+   struct {
+   wait_queue_head_t waitqueue;
+   struct mutex lock;
+   struct intel_global_obj obj;
+   } pmdemand;
+
struct {
/*
 * dkl.phy_lock protects against concurrent access of the
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..79853d8c3240 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -47,6 +47,7 @@
 #include "intel_opregion.h"
 #include "intel_overlay.h"
 #include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
 #include "intel_pps.h"
 #include "intel_quirks.h"
 #include "intel_vga.h"
@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct 
drm_i915_private *i915)
if (ret < 0)
goto cleanup_vga;
 
+   intel_pmdemand_init(i915);
+
intel_power_domains_init_hw(i915, false);
 
if (!HAS_DISPLAY(i915))
@@ -240,6 +243,10 @@ int intel_display_driver_probe_noirq(struct 
drm_i915_pr

[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder

[Vinod Govindapillai]

While configuring pmdemand parameters, there could be
intel_get_crtc_new_encoder call where encoders could be 0. To avoid
invoking drm_warn in such cases, use a parameter to indicate drm_warn
should be suppressed.

v2: checkpatch warning fixes

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 10 ++
 drivers/gpu/drm/i915/display/intel_display.h |  3 ++-
 drivers/gpu/drm/i915/display/intel_dpll.c|  8 
 drivers/gpu/drm/i915/display/intel_pch_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_pmdemand.c|  2 +-
 drivers/gpu/drm/i915/display/intel_snps_phy.c|  2 +-
 7 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..e91fdd5a26c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1879,7 +1879,7 @@ void intel_c10pll_state_verify(struct intel_atomic_state 
*state,
!intel_crtc_needs_fastset(new_crtc_state))
return;
 
-   encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
+   encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
phy = intel_port_to_phy(i915, encoder->port);
 
if (!intel_is_c10phy(i915, phy))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f98e235fadc6..4cadda4acce4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct drm_i915_private 
*dev_priv)
  */
 struct intel_encoder *
 intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
-  const struct intel_crtc_state *crtc_state)
+  const struct intel_crtc_state *crtc_state,
+  bool warn)
 {
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
@@ -782,9 +783,10 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state 
*state,
num_encoders++;
}
 
-   drm_WARN(state->base.dev, num_encoders != 1,
-"%d encoders for pipe %c\n",
-num_encoders, pipe_name(master_crtc->pipe));
+   if (warn)
+   drm_WARN(state->base.dev, num_encoders != 1,
+"%d encoders for pipe %c\n",
+num_encoders, pipe_name(master_crtc->pipe));
 
return encoder;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..4620ed991ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct intel_plane_state 
*plane_state);
 
 struct intel_encoder *
 intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
-  const struct intel_crtc_state *crtc_state);
+  const struct intel_crtc_state *crtc_state,
+  bool warn);
 void intel_plane_disable_noatomic(struct intel_crtc *crtc,
  struct intel_plane *plane);
 void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index a9fbef0fa817..9d30f273130e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct intel_atomic_state 
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
 
if (DISPLAY_VER(dev_priv) < 11 &&
@@ -969,7 +969,7 @@ static int hsw_crtc_get_shared_dpll(struct 
intel_atomic_state *state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
 
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
@@ -984,7 +984,7 @@ static int dg2_crtc_compute_clock(struct intel_atomic_state 
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
-   intel_get_crtc_new_encoder(state, crtc_state);
+   intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;

Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

[Ville Syrjälä]

On Thu, Apr 27, 2023 at 06:00:10PM +0300, Vinod Govindapillai wrote:
> >From MTL onwwards, pcode locks the QGV point based on peak BW of
> the intended QGV point passed by the driver. So the peak BW
> calculation must match the value expected by the pcode. Update
> the calculations as per the Bspec.
> 
> Bspec: 64636
> 
> Signed-off-by: Vinod Govindapillai 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index ab405c48ca3a..25ae4e5834d3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct 
> drm_i915_private *dev_priv,
>   val2 = intel_uncore_read(&dev_priv->uncore,
>MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
>   dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
> - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
> + sp->dclk = (16667 * dclk + 500) / 1000;

Don't hand roll rounding.

>   sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
>   sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
>  
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 13/13] drm/i915/mtl: Enable TC ports

[Clint Taylor]

On 4/20/23 05:40, Mika Kahola wrote:

Finally, we can enable TC ports for Meteorlake.

Signed-off-by: Mika Kahola 
---
  drivers/gpu/drm/i915/display/intel_display.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e70bdf0e06f3..dc777c3b1b1a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7587,9 +7587,12 @@ void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
return;
  
  	if (IS_METEORLAKE(dev_priv)) {

-   /* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+   intel_ddi_init(dev_priv, PORT_TC1);
+   intel_ddi_init(dev_priv, PORT_TC2);
+   intel_ddi_init(dev_priv, PORT_TC3);
+   intel_ddi_init(dev_priv, PORT_TC4);


Reviewed-by: Clint Taylor 

-Clint


} else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);

Re: [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

[Dmitry Baryshkov]

On 26/04/2023 19:29, Doug Anderson wrote:

Hi,

On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub  wrote:


Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.

Main change in v10 is handling the kernel test bot warnings.

Patches 1-4 focus on moving the common HDCP helpers to common DRM.
This introduces a slight change in the original intel flow
as it splits the unique driver protocol from the generic implementation.

Patches 5-7 split the HDCP flow on the i915 driver to make use of the common 
DRM helpers.

Patches 8-10 implement HDCP on MSM driver.

Thanks,
-Mark Yacoub

Sean Paul (10):
   drm/hdcp: Add drm_hdcp_atomic_check()
   drm/hdcp: Avoid changing crtc state in hdcp atomic check
   drm/hdcp: Update property value on content type and user changes
   drm/hdcp: Expand HDCP helper library for enable/disable/check
   drm/i915/hdcp: Consolidate HDCP setup/state cache
   drm/i915/hdcp: Retain hdcp_capable return codes
   drm/i915/hdcp: Use HDCP helpers for i915
   dt-bindings: msm/dp: Add bindings for HDCP registers
   arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
   drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

  .../bindings/display/msm/dp-controller.yaml   |7 +-
  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |8 +
  drivers/gpu/drm/display/drm_hdcp_helper.c | 1224 +
  drivers/gpu/drm/i915/display/intel_atomic.c   |8 +-
  drivers/gpu/drm/i915/display/intel_ddi.c  |   32 +-
  .../drm/i915/display/intel_display_debugfs.c  |   12 +-
  .../drm/i915/display/intel_display_types.h|   51 +-
  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  352 ++---
  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   16 +-
  drivers/gpu/drm/i915/display/intel_hdcp.c | 1060 +++---
  drivers/gpu/drm/i915/display/intel_hdcp.h |   48 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c |  267 ++--
  drivers/gpu/drm/msm/Kconfig   |1 +
  drivers/gpu/drm/msm/Makefile  |1 +
  drivers/gpu/drm/msm/dp/dp_catalog.c   |  156 +++
  drivers/gpu/drm/msm/dp/dp_catalog.h   |   18 +
  drivers/gpu/drm/msm/dp/dp_debug.c |   46 +-
  drivers/gpu/drm/msm/dp/dp_debug.h |   11 +-
  drivers/gpu/drm/msm/dp/dp_display.c   |   39 +-
  drivers/gpu/drm/msm/dp/dp_display.h   |5 +
  drivers/gpu/drm/msm/dp/dp_drm.c   |   39 +-
  drivers/gpu/drm/msm/dp/dp_drm.h   |7 +
  drivers/gpu/drm/msm/dp/dp_hdcp.c  |  389 ++
  drivers/gpu/drm/msm/dp/dp_hdcp.h  |   33 +
  drivers/gpu/drm/msm/dp/dp_parser.c|   14 +
  drivers/gpu/drm/msm/dp/dp_parser.h|4 +
  drivers/gpu/drm/msm/dp/dp_reg.h   |   30 +-
  drivers/gpu/drm/msm/msm_atomic.c  |   19 +
  include/drm/display/drm_hdcp.h|  296 
  include/drm/display/drm_hdcp_helper.h |   23 +
  30 files changed, 2867 insertions(+), 1349 deletions(-)


Mark asked me if I had any advice for getting this patch series
landed. I haven't been following the patch series super closely, but
as I understand it:

1. The first several patches (the generic ones) seem fairly well
reviewed and haven't changed in any significant ways in a while. The
ideal place to land these would be drm-misc, I think.

2. The i915 patches also seem OK to land. The ideal place would be the
Intel DRM tree, I think.

3. The msm patches are not fully baked yet. Not only is there a kernel
bot complaint on patch #10, but Mark also said that comments from v6
haven't yet fully been addressed and he's talked with Dmitry on IRC
about this and has a plan to move forward.


The question becomes: can/should we land the generic and maybe the
i915 patches now while the msm patches are reworked. Do folks have an
opinion here? If we're OK landing some of the patches, I guess we have
a few options:

a) Just land the generic patches to drm-misc and put the i915 ones on
the backburner until drm-misc has made it to somewhere that the
drm-intel tree is based on. If we want to go this route and nobody
objects, I don't mind being the person who does the gruntwork of
actually landing them on drm-misc-next, though I certainly wouldn't
rush to make sure that nobody is unhappy with this idea.

b) Land the generic patches in some type of immutable branch so they
can be pulled into drm-misc and the Intel DRM tree. Someone more
senior to me would need to help with this, but if we really want to go
this way I can poke folks on IRC.

c) Land the generic and Intel patches in the Intel tree. The msm
patches would not be able to land until these trickled up the chain,
but the msm patches aren't fully ready yet anyway so maybe this is OK.

d) Land the generic and Intel patches in the drm-misc tree. If folks
are OK with this I can be the person to pull the trigger, but I'd want
to be very sure that Intel DRM fo

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

> On 26/04/2023 16:41, Yang, Fei wrote:
>>> On 26/04/2023 07:24, fei.y...@intel.com wrote:
 From: Fei Yang 

 The first three patches in this series are taken from
 https://patchwork.freedesktop.org/series/116868/
 These patches are included here because the last patch
 has dependency on the pat_index refactor.

 This series is focusing on uAPI changes,
 1. end support for set caching ioctl [PATCH 4/5]
 2. add set_pat extension for gem_create [PATCH 5/5]

 v2: drop one patch that was merged separately
  341ad0e8e254 drm/i915/mtl: Add PTE encode function
>>>
>>> Are the re-sends for stabilizing the series, or focusing on merge?
>>
>> v2 was sent just to drop one of patches that has already been merged.
>>
>>> If the latter then opens are:
>>>
>>> 1) Link to Mesa MR reviewed and ready to merge.
>>>
>>> 2) IGT reviewed.
>>>
>>> 3) I raised an open that get/set_caching should not "lie" but return an
>>> error if set pat extension has been used. I don't see a good reason not
>>> to do that.
>>
>> I don't think it's "lying" to the userspace. the comparison is only valid
>> for objects created by KMD because only such object uses the pat_index
>> from the cachelevel_to_pat table.
>
> Lets double check my understanding is correct. Userspace sequence of
> operations:
> 1)
> obj = gem_create()+set_pat(PAT_UC)
>
> 2a)
> get_caching(obj)
> What gets reported?

I see your point here. nice catch.
That should be handled by,
if (obj->cachel_level == I915_CACHE_INVAL) /* indicated pat-index is set by 
userspace */
  return -EOPNOTSUPP;
Will update the patch.

>
> 2b)
> set_caching(obj, I915_CACHE_LLC)
> What is the return code?

This will either return -EOPNOTSUPP, or ignored because set_pat extension was 
called.

>
> If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please
> state a good reason why both shouldn't return an error.
>
>>
>>> + Joonas on this one.
>>>
>>> 4) Refactoring as done is not very pretty and I proposed an idea for a
>>> nicer approach. Feasible or not, open for discussion.
>>
>> Still digesting your proposal. but not sure how would you define things
>> like PAT_UC as that is platform dependent, not a constant.
>
> "PAT_UC" in my outline was purely a driver specific value, similarly as
> I915_CACHE_... are.

Okay. Then you were suggesting to add a translation table for 
pat_index-to-(PAT-UC/WB/WT)?
It's going to be a N:1 mapping.

> With the whole point that driver can ask if
> something is uncached, WT or whatever. Using the platform specific
> mapping table which converts platform specific obj->pat_index to driver
> representation of caching modes (PAT_UC etc).

Are you suggesting completely remove i915_cache_level and use (PAT-UC/WB/WT) 
instead?
Let's say a KMD object wants to be set as WB, how you get the exact pat_index 
to use?
Note that there are multiple PAT indices having caching mod WB, but they are 
different,
e.g. do you want just WB or WB with 1-way-coherency or WB with 2-way coherency?

Also, in case a checking of pat_index is needed, do we say WB with 
1-way-coherency is
equal to WB or not?

BTW, isn't PAT-UC/WB/WT the same kind of abstraction as enum i915_cache_level, 
I'm not
sure how that would simplify anything.

> Quite possible I missed some detail, but if I haven't then it could be
> a neat and lightweight solution.
>
> Regards,
>
> Tvrtko

Re: [Intel-gfx] [PATCH 10/13] drm/i915/mtl: Power up TCSS

[Matt Atwood]

On Thu, Apr 20, 2023 at 03:40:47PM +0300, Mika Kahola wrote:
> Add register writes to enable powering up Type-C subsystem i.e. TCSS.
> For MeteorLake we need to request TCSS to power up and check the TCSS
> power state after 500 us.
> 
> In addition, for PICA we need to set/clear the Type-C PHY ownnership
> bit when Type-C device is connected/disconnected.
> 
Reviewed-by: Matt Atwood 
> Signed-off-by: Mika Kahola 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c |  19 ++
>  drivers/gpu/drm/i915/display/intel_cx0_phy.h |   4 +
>  drivers/gpu/drm/i915/display/intel_ddi.c |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c |   2 +-
>  drivers/gpu/drm/i915/display/intel_tc.c  | 199 ++-
>  5 files changed, 216 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dc005e61..97d80adb921f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2884,6 +2884,25 @@ void intel_mtl_pll_disable(struct intel_encoder 
> *encoder)
>   intel_cx0pll_disable(encoder);
>  }
>  
> +enum icl_port_dpll_id
> +intel_mtl_port_pll_type(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + /*
> +  * TODO: Determine the PLL type from the SW state, once MTL PLL
> +  * handling is done via the standard shared DPLL framework.
> +  */
> + u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
> + u32 clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
> +
> + if (clock == XELPDP_DDI_CLOCK_SELECT_MAXPCLK ||
> + clock == XELPDP_DDI_CLOCK_SELECT_DIV18CLK)
> + return ICL_PORT_DPLL_MG_PHY;
> + else
> + return ICL_PORT_DPLL_DEFAULT;
> +}
> +
>  void intel_c10pll_state_verify(struct intel_atomic_state *state,
>  struct intel_crtc_state *new_crtc_state)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> index c1b8f7980f69..f99809af257d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> @@ -16,12 +16,16 @@
>  struct drm_i915_private;
>  struct intel_encoder;
>  struct intel_crtc_state;
> +enum icl_port_dpll_id;
>  enum phy;
>  
>  bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy);
>  void intel_mtl_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state);
>  void intel_mtl_pll_disable(struct intel_encoder *encoder);
> +enum icl_port_dpll_id
> +intel_mtl_port_pll_type(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state);
>  void intel_c10pll_readout_hw_state(struct intel_encoder *encoder, struct 
> intel_c10pll_state *pll_state);
>  int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct 
> intel_encoder *encoder);
>  void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8f0f858cde31..55f36d9d509c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4784,6 +4784,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   if (DISPLAY_VER(dev_priv) >= 14) {
>   encoder->enable_clock = intel_mtl_pll_enable;
>   encoder->disable_clock = intel_mtl_pll_disable;
> + encoder->port_pll_type = intel_mtl_port_pll_type;
>   encoder->get_config = mtl_ddi_get_config;
>   } else if (IS_DG2(dev_priv)) {
>   encoder->enable_clock = intel_mpllb_enable;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1c264c17b6e4..e70bdf0e06f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1757,7 +1757,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv, 
> enum phy phy)
>   if (IS_DG2(dev_priv))
>   /* DG2's "TC1" output uses a SNPS PHY */
>   return false;
> - else if (IS_ALDERLAKE_P(dev_priv))
> + else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
>   return phy >= PHY_F && phy <= PHY_I;
>   else if (IS_TIGERLAKE(dev_priv))
>   return phy >= PHY_D && phy <= PHY_I;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 3b60995e9dfb..951b12ac51dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -5,6 +5,7 @@
>  
>  #include "i915_drv.h"
>  #include "i915_reg.h"
> +#i

Re: [Intel-gfx] [PATCH 11/13] drm/i915/mtl: TypeC HPD live status query

[Matt Atwood]

On Thu, Apr 20, 2023 at 03:40:48PM +0300, Mika Kahola wrote:
> From: Imre Deak 
> 
> The HPD live status for MTL has to be read from different set of
> registers. MTL deserves a new function for this purpose
> and cannot reuse the existing  HPD live status detection
> 
Reviewed-by: Matt Atwood 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Imre Deak 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 30 -
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 951b12ac51dc..b192265a3d78 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -886,6 +886,34 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
>   * XELPDP TC PHY handlers
>   * --
>   */
> +static u32 xelpdp_tc_phy_hpd_live_status(struct intel_tc_port *tc)
> +{
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + struct intel_digital_port *dig_port = tc->dig_port;
> + enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
> + u32 pica_isr_bits = i915->display.hotplug.hpd[hpd_pin];
> + u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
> + intel_wakeref_t wakeref;
> + u32 pica_isr;
> + u32 pch_isr;
> + u32 mask = 0;
> +
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref) {
> + pica_isr = intel_de_read(i915, PICAINTERRUPT_ISR);
> + pch_isr = intel_de_read(i915, SDEISR);
> + }
> +
> + if (pica_isr & (pica_isr_bits & XELPDP_DP_ALT_HOTPLUG_MASK))
> + mask |= BIT(TC_PORT_DP_ALT);
> + if (pica_isr & (pica_isr_bits & XELPDP_TBT_HOTPLUG_MASK))
> + mask |= BIT(TC_PORT_TBT_ALT);
> +
> + if (tc->legacy_port && (pch_isr & pch_isr_bit))
> + mask |= BIT(TC_PORT_LEGACY);
> +
> + return mask;
> +}
> +
>  static bool
>  xelpdp_tc_phy_tcss_power_is_enabled(struct intel_tc_port *tc)
>  {
> @@ -1039,7 +1067,7 @@ static void xelpdp_tc_phy_disconnect(struct 
> intel_tc_port *tc)
>  
>  static const struct intel_tc_phy_ops xelpdp_tc_phy_ops = {
>   .cold_off_domain = tgl_tc_phy_cold_off_domain,
> - .hpd_live_status = adlp_tc_phy_hpd_live_status,
> + .hpd_live_status = xelpdp_tc_phy_hpd_live_status,
>   .is_ready = adlp_tc_phy_is_ready,
>   .is_owned = xelpdp_tc_phy_is_owned,
>   .get_hw_state = xelpdp_tc_phy_get_hw_state,
> -- 
> 2.34.1
> 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Expose RPS thresholds in sysfs

[Patchwork]

== Series Details ==

Series: Expose RPS thresholds in sysfs
URL   : https://patchwork.freedesktop.org/series/117054/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  drivers/gpu/drm/i915/gt/intel_rps.o
In file included from ./include/linux/interrupt.h:6,
 from ./include/drm/drm_util.h:35,
 from ./drivers/gpu/drm/i915/display/intel_display.h:28,
 from drivers/gpu/drm/i915/gt/intel_rps.c:10:
drivers/gpu/drm/i915/gt/intel_rps.c: In function ‘intel_rps_enable’:
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no 
member named ‘threshold_up’
 1562 |rps->power.threshold_up,
  |  ^
./include/linux/kernel.h:337:40: note: in definition of macro 
‘__trace_printk_check_format’
  337 |   trace_printk_check_format(fmt, ##args);  \
  |^~~~
./include/linux/kernel.h:374:3: note: in expansion of macro ‘do_trace_printk’
  374 |   do_trace_printk(fmt, ##__VA_ARGS__); \
  |   ^~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro 
‘trace_printk’
  119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
  |^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
   18 |  GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev),  \
  |  ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro 
‘GT_TRACE’
 1557 |  GT_TRACE(rps_to_gt(rps),
  |  ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1563:14: error: ‘struct ’ has no 
member named ‘threshold_down’
 1563 |rps->power.threshold_down);
  |  ^
./include/linux/kernel.h:337:40: note: in definition of macro 
‘__trace_printk_check_format’
  337 |   trace_printk_check_format(fmt, ##args);  \
  |^~~~
./include/linux/kernel.h:374:3: note: in expansion of macro ‘do_trace_printk’
  374 |   do_trace_printk(fmt, ##__VA_ARGS__); \
  |   ^~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro 
‘trace_printk’
  119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
  |^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
   18 |  GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev),  \
  |  ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro 
‘GT_TRACE’
 1557 |  GT_TRACE(rps_to_gt(rps),
  |  ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no 
member named ‘threshold_up’
 1562 |rps->power.threshold_up,
  |  ^
./include/linux/kernel.h:388:50: note: in definition of macro ‘do_trace_printk’
  388 |   __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
  |  ^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro 
‘trace_printk’
  119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
  |^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
   18 |  GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev),  \
  |  ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro 
‘GT_TRACE’
 1557 |  GT_TRACE(rps_to_gt(rps),
  |  ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1563:14: error: ‘struct ’ has no 
member named ‘threshold_down’
 1563 |rps->power.threshold_down);
  |  ^
./include/linux/kernel.h:388:50: note: in definition of macro ‘do_trace_printk’
  388 |   __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
  |  ^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro 
‘trace_printk’
  119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
  |^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
   18 |  GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev),  \
  |  ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro 
‘GT_TRACE’
 1557 |  GT_TRACE(rps_to_gt(rps),
  |  ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no 
member named ‘threshold_up’
 1562 |rps->power.threshold_up,
  |  ^
./include/linux/kernel.h:390:36: note: in definition of macro ‘do_trace_printk’
  390 |   __trace_printk(_THIS_IP_, fmt, ##args);   \
  |^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro 
‘trace_printk’
  119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
  |^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
   18 |  GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev),  \
  |  ^~~

Re: [Intel-gfx] [PATCH 12/13] drm/i915/mtl: Pin assignment for TypeC

[Matt Atwood]

On Thu, Apr 20, 2023 at 03:40:49PM +0300, Mika Kahola wrote:
> From: Anusha Srivatsa 
> 
> Unlike previous platforms that used PORT_TX_DFLEXDPSP
> for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
> from which the max_lanes has to be calculated.
> 
> Bspec: 50235, 65380
> 
Reviewed-by: Matt Atwood 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Jose Roberto de Souza 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 28 +
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index b192265a3d78..4fca711a58bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -16,6 +16,10 @@
>  #include "intel_mg_phy_regs.h"
>  #include "intel_tc.h"
>  
> +#define DP_PIN_ASSIGNMENT_C  0x3
> +#define DP_PIN_ASSIGNMENT_D  0x4
> +#define DP_PIN_ASSIGNMENT_E  0x5
> +
>  enum tc_port_mode {
>   TC_PORT_DISCONNECTED,
>   TC_PORT_TBT_ALT,
> @@ -281,6 +285,27 @@ u32 intel_tc_port_get_pin_assignment_mask(struct 
> intel_digital_port *dig_port)
>  DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
>  }
>  
> +static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port 
> *dig_port)
> +{
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + intel_wakeref_t wakeref;
> + u32 pin_mask;
> +
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> + pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
> +
> + switch (pin_mask) {
> + default:
> + MISSING_CASE(pin_mask);
> + fallthrough;
> + case DP_PIN_ASSIGNMENT_D:
> + return 2;
> + case DP_PIN_ASSIGNMENT_C:
> + case DP_PIN_ASSIGNMENT_E:
> + return 4;
> + }
> +}
> +
>  int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> @@ -294,6 +319,9 @@ int intel_tc_port_fia_max_lane_count(struct 
> intel_digital_port *dig_port)
>  
>   assert_tc_cold_blocked(tc);
>  
> + if (DISPLAY_VER(i915) >= 14)
> + return mtl_tc_port_get_pin_assignment_mask(dig_port);
> +
>   lane_mask = 0;
>   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
>   lane_mask = intel_tc_port_get_lane_mask(dig_port);
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests

[Kamil Konieczny]

Hi Ashutosh,

On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote:
> On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote:
> >
> > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c
> > new file mode 100644
> > index ..17adacbc
> > --- /dev/null
> > +++ b/tests/i915/i915_pm_freq_api.c
> > @@ -0,0 +1,153 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2023 Intel Corporation
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "drmtest.h"
> 
> The series is merged but before merging I removed all the #include's above,
> they are not needed.

Please do not do this, at least send it to trybot and look at
GitLab.Pipeline status. There are platforms where compilation 
failed due to missing fcntl.h, see
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/137

It is fixed now with
https://patchwork.freedesktop.org/series/117047/

Regards,
Kamil

> 
> > +#include "i915/gem.h"
> > +#include "igt_sysfs.h"
> > +#include "igt.h"
> 
> Thanks.
> --
> Ashutosh

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests

[Dixit, Ashutosh]

On Thu, 27 Apr 2023 09:24:58 -0700, Kamil Konieczny wrote:
>
> Hi Ashutosh,
>
> On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote:
> > On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote:
> > >
> > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c
> > > new file mode 100644
> > > index ..17adacbc
> > > --- /dev/null
> > > +++ b/tests/i915/i915_pm_freq_api.c
> > > @@ -0,0 +1,153 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2023 Intel Corporation
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include "drmtest.h"
> >
> > The series is merged but before merging I removed all the #include's above,
> > they are not needed.
>
> Please do not do this, at least send it to trybot and look at
> GitLab.Pipeline status. There are platforms where compilation
> failed due to missing fcntl.h, see
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/137
>
> It is fixed now with
> https://patchwork.freedesktop.org/series/117047/

Hi Kamil, agreed, sorry about that. Lesson learnt. Thanks for fixing it quickly.

Ashutosh

Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout

[Sripada, Radhakrishna]

> -Original Message-
> From: Kahola, Mika 
> Sent: Wednesday, April 26, 2023 4:43 AM
> To: Sripada, Radhakrishna 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> 
> > -Original Message-
> > From: Sripada, Radhakrishna 
> > Sent: Monday, April 24, 2023 11:56 PM
> > To: Kahola, Mika 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Apr 20, 2023 at 03:40:39PM +0300, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > Signed-off-by: Mika Kahola 
> > > Signed-off-by: Arun R Murthy 
> > > Signed-off-by: Ankit Nautiyal 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 623 +-
> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +-
> > >  drivers/gpu/drm/i915/display/intel_ddi.c  |   9 +-
> > >  .../drm/i915/display/intel_display_types.h|   1 +
> > >  drivers/gpu/drm/i915/display/intel_hdmi.c |   6 +-
> > >  drivers/gpu/drm/i915/display/intel_hdmi.h |   1 +
> > >  6 files changed, 628 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index dd96bf5e179e..61428c5145e5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > >  #include "intel_de.h"
> > >  #include "intel_display_types.h"
> > >  #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > >  #include "intel_panel.h"
> > >  #include "intel_psr.h"
> > >  #include "intel_tc.h"
> > > @@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct
> > drm_i915_private *i915, enum port port,
> > >   intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1);  }
> > >
> > > +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port
> > port,
> > > +int lane, u16 addr)
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff,
> > > +1);
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > + return val;
> > > +}
> > > +
> > >  static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port 
> > > port,
> > >   int lane, u16 addr, u8 clear, u8 set, bool 
> > > committed)  {
> > @@
> > > -659,6 +677,199 @@ static const struct intel_c10pll_state * const
> > mtl_c10_edp_tables[] = {
> > >   NULL,
> > >  };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > + .link_bit_rate = 162000,
> > > + .clock = 162000,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x5800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x50a8,  /* mpllb cfg0 */
> > > + 0x2120, /* mpllb cfg1 */
> > > + 0xcd9a, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x5ab8, /* mpllb cfg4 */
> > > + 0x4c34, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > + 0x0001, /* mpllb cfg7 */
> > > + 0x6000, /* mpllb cfg8 */
> > > + 0x, /* mpllb cfg9 */
> > > + 0x, /* mpllb cfg10 */
> > > + },
> > > +};
> > > +
> > > +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > > + .link_bit_rate = 27,
> > > + .clock = 27,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x4800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x308c,  /* mpllb cfg0 */
> > > + 0x2110, /* mpllb cfg1 */
> > > + 0xcc9c, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x489a, /* mpllb cfg4 */
> > This should be 0x4b9a ^ for mpllb cfg4 according to the consolidated table.
> Yes. Perhaps this has changed since the time of writing.
> 
> >
> > > + 0x3f81, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > +

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() 
(rev2)
URL   : https://patchwork.freedesktop.org/series/116947/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116947v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 36)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@slpc:
- bat-rplp-1: [PASS][1] -> [FAIL][2] ([i915#7913])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rplp-1/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rplp-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][3] ([i915#7828])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][4] ([i915#1845])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][5] ([i915#6687]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][7] ([i915#7916]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-6}:   [ABORT][9] ([i915#7920]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][11] -> [ABORT][12] ([i915#8397])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

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

  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
  [i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
  [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397


Build changes
-

  * Linux: CI_DRM_13071 -> Patchwork_116947v2

  CI-20190529: 20190529
  CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116947v2: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b5d23433d39e drm/i915/dsi: Use unconditional msleep() instead of 
intel_dsi_msleep()

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix error capture for virtual engines

[Teres Alexis, Alan Previn]

On Fri, 2023-04-14 at 17:27 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> GuC based register dumps in error capture logs were basically broken
> for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
>   [IGT] gem_exec_balancer: starting subtest hang
>   [drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
>   [drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D
>   [drm] GPU HANG: ecode 12:4:, in gem_exec_balanc [6388]
>   [IGT] gem_exec_balancer: exiting, ret=0
> 
> The test causes a hang on both engines of a virtual engine context.
> The engine instance zero hang gets a valid error capture but the
> non-instance-zero hang does not.
> 
> Fix that by scanning through the list of pending register captures
> when a hang notification for a virtual engine is received. That way,
> the hang can be assigned to the correct physical engine prior to
> starting the error capture process. So later on, when the error capture
> handler tries to find the engine register list, it looks for one on
> the correct engine.
> 
> Also, sneak in a missing blank line before a comment in the node
> search code.
> 
> Signed-off-by: John Harrison 

LGTM - thanks for fixing this! :D
Reviewed-by: Alan Previn 

A side conversation - potentially requring an unrelated future patch,...
i notice that the array "error->reset_engine_count[]" (which is being
used for error state reporting and as some verification in selftests) seem
to have a size indicating of engine-instance-count but the reading/wrting
of members of this array keep using the engine->uabi_class as index...
meaning its being used to track engine class reset counts? Maybe this is
an issue or i am misundertanding that. Either way, that issue is unrelated
to the intent of this patch - i just wanted to get that highlighted for
future action if needed. I can take that onus if its in fact an issue.

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

[Teres Alexis, Alan Previn]

On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
> On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
alan:snip

> 
> > - Jordan still wants the extension query
> Yes, I do, but so far it doesn't appear that any kernel devs think
> it's a reasonable request.
> 
> As I read through your emails about this pxp situation, it seems like
> a separate issue. When I encountered the 8s delay, it was on MTL, and
> apparently some firmware issue meant it was never going to work. So, I
> thought this was a case of it either being supported, or never being
> supported.
alan: this might be because of an older patch version in internal tree
- which I'm trying hard to fix to follow latest upstream - but keep getting
delays and conflicts - but thats unrelated to this upstream POV


> Now I'm seeing from your emails that in some cases it might be
> supported, but just not ready yet. In that case a status which is
> directly tied to pxp seems valuable. (But, yuck, how did we get into
> this situation? :)
alan: thanks for the go ahead on this PXP's uniquely different-issue
(and i must agree, 'yukcy' situation).

How did we get here? we are trying to debug this - its interesting to see
the same kernel with the same configs much faster on ADL vs MTL but
the MTL case is suffering because the mei-heci-parent driver is getting
loaded much later (which IS common to ADL) - this delayed parent driver
is causing the delay on the gsc-proxy component MTL. From parent load
to gsc-proxy bin+init is relatively fast (~few hundred milisecs). But I
believe it seems to only be happenning on select OS stacks (our ChromeOS
fork is definitely seeing this).


> Can you tell that pxp is in progress, but not ready yet, as a separate
> state from 'it will never work on this platform'? If so, maybe the
> status could return something like:
> 
> 0: It's never going to work
> 1: It's ready to use
> 2: It's starting and should work soon
> 
> I could see an argument for treating that as a case where we could
> still advertise protected content support, but if we try to use it we
> might be in for a nasty delay.
> 
alan: IIRC Lionel seemed okay with any permutation that would allow it to not
get blocked. Daniele did ask for something similiar to what u mentioned above
but he said that is non-blocking. But since both you AND Daniele have mentioned
the same thing, i shall re-rev this and send that change out today.
I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick 
with that.
but 1 = ready to use and 2 = starting and should work sounds good. so '0' will 
never
be returned - we just look for a positive value (from user space). I will also
make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan:snip

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce sink_format and other fixes

[Patchwork]

== Series Details ==

Series: Introduce sink_format and other fixes
URL   : https://patchwork.freedesktop.org/series/117056/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/b

[Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce sink_format and other fixes

[Patchwork]

== Series Details ==

Series: Introduce sink_format and other fixes
URL   : https://patchwork.freedesktop.org/series/117056/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_117056v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_117056v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_117056v1, 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_117056v1/index.html

Participating hosts (38 -> 36)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- bat-adlm-1: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-adlm-1/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8:  [PASS][3] -> [FAIL][4] ([i915#7932])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][5] ([i915#7916]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-6}:   [ABORT][7] ([i915#7920]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][9] -> [ABORT][10] ([i915#8397])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

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

  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
  [i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397


Build changes
-

  * Linux: CI_DRM_13071 -> Patchwork_117056v1

  CI-20190529: 20190529
  CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_117056v1: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

29ccc1a911bb drm/i915/dp: Rearrange check for illegal mode and comments in 
mode_valid
902e2b51e8ab drm/i915/dp: Add helper to get sink_format
51801e2939b5 drm/i915/display: Use sink_format instead of ycbcr420_output flag
2525d109de1b drm/i915/dp: Configure PCON for conversion of output_format to 
YCbCr444
4a2e03229361 drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state 
sink_format
a782b8fdbafa drm/i915/display: Add new member to configure PCON color conversion

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mtl: add support for pmdemand (rev4)

[Patchwork]

== Series Details ==

Series: mtl: add support for pmdemand (rev4)
URL   : https://patchwork.freedesktop.org/series/116949/
State : warning

== Summary ==

Error: dim checkpatch failed
874300201d54 drm/i915: fix the derating percentage for MTL
0351498e12a8 drm/i915: update the QGV point frequency calculations
a19eee5cbb59 drm/i915: store the peak bw per QGV point
7165b8529aef drm/i915: extract intel_bw_check_qgv_points()
08a7346302d0 drm/i915: modify max_bw to return index to intel_bw_info
0f2930d76473 drm/i915/mtl: find best QGV point and configure sagv
5bd2838f8dfc drm/i915/mtl: Add support for PM DEMAND
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:97: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#97: FILE: drivers/gpu/drm/i915/display/intel_display_core.h:350:
+   struct mutex lock;

-:170: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#170: 
new file mode 100644

-:281: CHECK:LINE_SPACING: Please don't use multiple blank lines
#281: FILE: drivers/gpu/drm/i915/display/intel_pmdemand.c:107:
+
+

-:734: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#734: FILE: drivers/gpu/drm/i915/i915_reg.h:4519:
+#define  XELPDP_PMDEMAND_QCLK_GV_BW(x) 
REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_BW_MASK, x)

-:736: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#736: FILE: drivers/gpu/drm/i915/i915_reg.h:4521:
+#define  XELPDP_PMDEMAND_VOLTAGE_INDEX(x)  
REG_FIELD_PREP(XELPDP_PMDEMAND_VOLTAGE_INDEX_MASK, x)

-:738: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#738: FILE: drivers/gpu/drm/i915/i915_reg.h:4523:
+#define  XELPDP_PMDEMAND_QCLK_GV_INDEX(x)  
REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_INDEX_MASK, x)

-:740: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#740: FILE: drivers/gpu/drm/i915/i915_reg.h:4525:
+#define  XELPDP_PMDEMAND_PIPES(x)  
REG_FIELD_PREP(XELPDP_PMDEMAND_PIPES_MASK, x)

-:742: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#742: FILE: drivers/gpu/drm/i915/i915_reg.h:4527:
+#define  XELPDP_PMDEMAND_DBUFS(x)  
REG_FIELD_PREP(XELPDP_PMDEMAND_DBUFS_MASK, x)

-:748: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#748: FILE: drivers/gpu/drm/i915/i915_reg.h:4533:
+#define  XELPDP_PMDEMAND_CDCLK_FREQ(x) 
REG_FIELD_PREP(XELPDP_PMDEMAND_CDCLK_FREQ_MASK, x)

-:750: WARNING:LONG_LINE: line length of 107 exceeds 100 columns
#750: FILE: drivers/gpu/drm/i915/i915_reg.h:4535:
+#define  XELPDP_PMDEMAND_DDICLK_FREQ(x)
REG_FIELD_PREP(XELPDP_PMDEMAND_DDICLK_FREQ_MASK, x)

-:752: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#752: FILE: drivers/gpu/drm/i915/i915_reg.h:4537:
+#define  XELPDP_PMDEMAND_SCALERS(x)
REG_FIELD_PREP(XELPDP_PMDEMAND_SCALERS_MASK, x)

total: 0 errors, 9 warnings, 2 checks, 680 lines checked
0f22628358d0 drm/i915/display: provision to suppress drm_warn in 
intel_get_crtc_new_encoder

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for mtl: add support for pmdemand (rev4)

[Patchwork]

== Series Details ==

Series: mtl: add support for pmdemand (rev4)
URL   : https://patchwork.freedesktop.org/series/116949/
State : warning

== Summary ==

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

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

[Teres Alexis, Alan Previn]

(fixed email addresses again - why is my Evolution client deteorating??)

On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:
> On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
> > On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
> alan:snip
> > Can you tell that pxp is in progress, but not ready yet, as a separate
> > state from 'it will never work on this platform'? If so, maybe the
> > status could return something like:
> > 
> > 0: It's never going to work
> > 1: It's ready to use
> > 2: It's starting and should work soon
> > 
> > I could see an argument for treating that as a case where we could
> > still advertise protected content support, but if we try to use it we
> > might be in for a nasty delay.
> > 
> alan: IIRC Lionel seemed okay with any permutation that would allow it to not
> get blocked. Daniele did ask for something similiar to what u mentioned above
> but he said that is non-blocking. But since both you AND Daniele have 
> mentioned
> the same thing, i shall re-rev this and send that change out today.
> I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick 
> with that.
> but 1 = ready to use and 2 = starting and should work sounds good. so '0' 
> will never
> be returned - we just look for a positive value (from user space). I will also
> make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan: I also realize with these final touch-ups, we can go back to the original
pxp-context-creation timeout of 250 milisecs like it was on ADL since the user
space component will have this new param to check on (so even farther down from
1 sec on the last couple of revs).

Jordan, Lional - i am thinking of creating the PR on MESA side to take advantage
of GET_PARAM on both get-caps AND runtime creation (latter will be useful to 
ensure
no unnecesssary delay experienced by Mesa stuck in kernel call - which 
practically
never happenned in ADL AFAIK):

1. MESA PXP get caps: 
- use GET_PARAM (any positive number shall mean its supported).
2. MESA app-triggered PXP context creation (i.e. if caps was supported):
- use GET_PARAM to wait until positive number switches from "2" to "1".
- now call context creation. So at this point if it fails, we know its
  an actual failure.

you guys okay with above? (i'll re-rev this kernel series first and wait on your
ack or feedback before i create/ test/ submit a PR for Mesa side).

[Intel-gfx] ✓ Fi.CI.BAT: success for mtl: add support for pmdemand (rev4)

[Patchwork]

== Series Details ==

Series: mtl: add support for pmdemand (rev4)
URL   : https://patchwork.freedesktop.org/series/116949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116949v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 36)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8:  [PASS][1] -> [FAIL][2] ([i915#7932]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][3] ([i915#7916]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-6}:   [ABORT][5] ([i915#7920]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: [FAIL][7] ([i915#6997]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][9] -> [ABORT][10] ([i915#8397])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

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

  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
  [i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397


Build changes
-

  * Linux: CI_DRM_13071 -> Patchwork_116949v4

  CI-20190529: 20190529
  CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116949v4: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

72ff61a5f452 drm/i915/display: provision to suppress drm_warn in 
intel_get_crtc_new_encoder
c5df808bc840 drm/i915/mtl: Add support for PM DEMAND
ca6f9668a8ee drm/i915/mtl: find best QGV point and configure sagv
b5d9b3816438 drm/i915: modify max_bw to return index to intel_bw_info
80e5807febdc drm/i915: extract intel_bw_check_qgv_points()
1f73baa912be drm/i915: store the peak bw per QGV point
9866a15853f6 drm/i915: update the QGV point frequency calculations
1cff5f944d75 drm/i915: fix the derating percentage for MTL

== Logs ==

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

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

[Lionel Landwerlin]

On 27/04/2023 21:19, Teres Alexis, Alan Previn wrote:

(fixed email addresses again - why is my Evolution client deteorating??)

On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:

On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:

On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:

alan:snip

Can you tell that pxp is in progress, but not ready yet, as a separate
state from 'it will never work on this platform'? If so, maybe the
status could return something like:

0: It's never going to work
1: It's ready to use
2: It's starting and should work soon

I could see an argument for treating that as a case where we could
still advertise protected content support, but if we try to use it we
might be in for a nasty delay.


alan: IIRC Lionel seemed okay with any permutation that would allow it to not
get blocked. Daniele did ask for something similiar to what u mentioned above
but he said that is non-blocking. But since both you AND Daniele have mentioned
the same thing, i shall re-rev this and send that change out today.
I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick 
with that.
but 1 = ready to use and 2 = starting and should work sounds good. so '0' will 
never
be returned - we just look for a positive value (from user space). I will also
make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan: I also realize with these final touch-ups, we can go back to the original
pxp-context-creation timeout of 250 milisecs like it was on ADL since the user
space component will have this new param to check on (so even farther down from
1 sec on the last couple of revs).

Jordan, Lional - i am thinking of creating the PR on MESA side to take advantage
of GET_PARAM on both get-caps AND runtime creation (latter will be useful to 
ensure
no unnecesssary delay experienced by Mesa stuck in kernel call - which 
practically
never happenned in ADL AFAIK):

1. MESA PXP get caps:
- use GET_PARAM (any positive number shall mean its supported).
2. MESA app-triggered PXP context creation (i.e. if caps was supported):
- use GET_PARAM to wait until positive number switches from "2" to "1".
- now call context creation. So at this point if it fails, we know its
  an actual failure.

you guys okay with above? (i'll re-rev this kernel series first and wait on your
ack or feedback before i create/ test/ submit a PR for Mesa side).



Sounds good.

Thanks,


-Lionel

Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices

[Alex Williamson]

On Thu, 27 Apr 2023 06:59:17 +
"Liu, Yi L"  wrote:

> > From: Tian, Kevin 
> > Sent: Thursday, April 27, 2023 2:39 PM
> >   
> > > From: Liu, Yi L 
> > > Sent: Wednesday, April 26, 2023 10:54 PM
> > > @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> > > unsigned long iova,
> > >  {
> > >   struct vfio_device *vdev = data;
> > >
> > > - if (vdev->ops->dma_unmap)
> > > + /* noiommu devices cannot do map/unmap */
> > > + if (vdev->noiommu && vdev->ops->dma_unmap)
> > >   vdev->ops->dma_unmap(vdev, iova, length);  
> > 
> > Is it necessary? All mdev devices implementing @dma_unmap won't
> > set noiommu flag.  
> 
> Hmmm. Yes, and all the devices set noiommu is not implementing @dma_unmap
> as far as I see. Maybe this noiommu check can be removed.

Not to mention that the polarity of the noiommu test is backwards here!
This also seems to be the only performance path where noiommu is tested
and therefore I believe the only actual justification of the previous
patch.
 
> > Instead in the future if we allow noiommu userspace to pin pages
> > we'd need similar logic too.  
> 
> I'm not quite sure about it so far. For mdev devices, the device driver
> may use vfio_pin_pages/vfio_dma_rw () to pin page. Hence such drivers
> need to listen to dma_unmap() event. But for noiommu users, does the
> device driver also participate in the page pin? At least for vfio-pci driver,
> it does not, or maybe it will in the future when enabling noiommu
> userspace to pin pages. It looks to me such userspace should order
> the DMA before calling ioctl to unpin page instead of letting device
> driver listen to unmap.

Whoa, noiommu is inherently unsafe an only meant to expose the vfio
device interface for userspace drivers that are going to do unsafe
things regardless.  Enabling noiommu to work with mdev, pin pages, or
anything else should not be on our agenda.  Userspaces relying on niommu
get the minimum viable interface and must impose a minuscule
incremental maintenance burden.  The only reason we're spending so much
effort on it here is to make iommufd noiommu support equivalent to
group/container noiommu support.  We should stop at that.  Thanks,

Alex

Re: [Intel-gfx] [PATCH v4 1/9] vfio: Determine noiommu in vfio_device registration

[Alex Williamson]

On Thu, 27 Apr 2023 07:05:37 +
"Liu, Yi L"  wrote:

> > From: Tian, Kevin 
> > Sent: Thursday, April 27, 2023 2:36 PM
> >   
> > > From: Liu, Yi L 
> > > Sent: Wednesday, April 26, 2023 10:54 PM
> > >
> > > -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> > > +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> > >  {
> > > - return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > > -vdev->group->type == VFIO_NO_IOMMU;
> > > + device->noiommu = IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > > +   device->group->type == VFIO_NO_IOMMU;
> > > + return 0;  
> > 
> > Just void. this can't fail.  
> 
> Hmmm. Yes, before below commit, it cannot fail. Maybe this can be
> converted to int later.
> 
> https://lore.kernel.org/kvm/20230426150321.454465-22-yi.l@intel.com/T/#u

AFAICT with the comments on the next patch, this change is not at all
justified within this series and should be dropped.  Thanks,

Alex

Re: [Intel-gfx] [PATCH v4 5/9] vfio: Mark cdev usage in vfio_device

[Alex Williamson]

On Wed, 26 Apr 2023 07:54:15 -0700
Yi Liu  wrote:

> Use it to differentiate whether to report group_id or dev_id in revised
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. Though it is not set at this
> moment introducing it now allows us to get hot reset ready for cdev.
> 
> Signed-off-by: Yi Liu 
> ---
>  include/linux/vfio.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 4ee613924435..298f4ef16be7 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -63,6 +63,7 @@ struct vfio_device {
>   bool iommufd_attached;
>  #endif
>   bool noiommu;
> + bool cdev_opened;
>  };
>  
>  /**
> @@ -140,6 +141,12 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device 
> *vdev, u32 *pt_id);
>   ((int (*)(struct vfio_device *vdev, u32 *pt_id)) NULL)
>  #endif
>  
> +static inline bool vfio_device_cdev_opened(struct vfio_device *device)
> +{
> + lockdep_assert_held(&device->dev_set->lock);
> + return device->cdev_opened;
> +}

The lockdep test doesn't make much sense here, the method of opening
the device can't change from an ioctl called on the device, which is
the only path using this.  If there needs to be a placeholder for
future code, it should probably statically return false here and we can
save adding the structure field and locking checks based on the
semantics of how the field is actually used later.  Thanks,

Alex

Re: [Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end

[Umesh Nerlige Ramappa]

On Wed, Apr 26, 2023 at 05:51:24PM -0700, Dixit, Ashutosh wrote:

On Wed, 26 Apr 2023 17:11:27 -0700, Umesh Nerlige Ramappa wrote:




Hi Umesh,


On Mon, Apr 24, 2023 at 10:41:41AM -0700, Dixit, Ashutosh wrote:
> On Tue, 04 Apr 2023 17:14:32 -0700, Umesh Nerlige Ramappa wrote:
>
>> GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
>> in the context image. This value is saved/restored on context switches.
>> KMD accumulates these values into a 64 bit counter taking care of any
>> overflows as needed. This count provides the basis for client specific
>> busyness in the fdinfo interface.
>>
>> KMD accumulation happens just before the context is unpinned and when
>> context switches out. This works for execlist back-end since execlist
>> scheduling has visibility into context switches. With GuC mode, KMD does
>> not have visibility into context switches and this counter is
>> accumulated only when context is unpinned. Context is unpinned once the
>> context scheduling is successfully disabled. Disabling context
>> scheduling is an asynchronous operation.
>
> This means guc_context_unpin() is called asynchronously, correct? From
> guc_context_sched_disable()?

correct
>
>> Also if a context is servicing frequent requests, scheduling may never be
>> disabled on it.
>>
>> For GuC mode, since updates to the context runtime may be delayed, add
>> hooks to update the context runtime in a worker thread as well as when
>> a user queries for it.
>>
>> Limitation:
>> - If a context is never switched out or runs for a long period of time,
>>   the runtime value of CTX_TIMESTAMP may never be updated, so the
>>   counter value may be unreliable. This patch does not support such
>>   cases. Such support must be available from the GuC FW and it is WIP.
>>
>> This patch is an extract from previous work authored by John/Umesh here -
>> https://patchwork.freedesktop.org/patch/496441/?series=105085&rev=4
>>
>> Signed-off-by: Umesh Nerlige Ramappa 
>> Co-developed-by: John Harrison 
>> Signed-off-by: John Harrison 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_context.c   | 12 +--
>>  drivers/gpu/drm/i915/gt/intel_context.h   |  2 +-
>>  drivers/gpu/drm/i915/gt/intel_context_types.h |  5 +++
>>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++
>>  4 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
>> index 2aa63ec521b8..e01f222e9e42 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
>> @@ -578,16 +578,24 @@ void intel_context_bind_parent_child(struct 
intel_context *parent,
>>child->parallel.parent = parent;
>>  }
>>
>> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
>> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
>>  {
>>u64 total, active;
>>
>> +  if (ce->ops->update_stats)
>> +  ce->ops->update_stats(ce);
>> +
>>total = ce->stats.runtime.total;
>>if (ce->ops->flags & COPS_RUNTIME_CYCLES)
>>total *= ce->engine->gt->clock_period_ns;
>>
>>active = READ_ONCE(ce->stats.active);
>> -  if (active)
>> +  /*
>> +   * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
>> +   * already provides the total active time of the context,
>
> Where is this done in the GuC case? I looked but couldn't find it (at least
> in this version of the patch, it is there in the old version).

In this case, the backend is not providing the total active time, I guess I
should drop this logic provided ce->stats.active is 0 for GuC mode.


Yes, I think best to skip the active part in this patch since this is a
temporary/inaccurate solution.



>
>> +   * so skip this calculation when this flag is set.
>> +   */
>> +  if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
>>active = intel_context_clock() - active;
>>
>>return total + active;
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
>> index 0a8d553da3f4..720809523e2d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
>> @@ -368,7 +368,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
>>clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
>>  }
>>
>> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
>> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
>>  u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
>>
>>  static inline u64 intel_context_clock(void)
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> index e36670f2e626..58b0294d359d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> @@ -38,6 +38,9 @@ struct intel_conte

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hugepage manager and test for MTL (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Hugepage manager and test for MTL (rev3)
URL   : https://patchwork.freedesktop.org/series/116995/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116995v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [FAIL][3] ([i915#7913] / [i915#8383])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +16 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#7828])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8:  [PASS][6] -> [FAIL][7] ([i915#7932])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][8] ([i915#1845])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][9] ([i915#6687]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][11] ([i915#7916]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-6}:   [ABORT][13] ([i915#7920]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][15] -> [ABORT][16] ([i915#8397])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  [INCOMPLETE][17] ([i915#7443] / [i915#8102]) -> 
[INCOMPLETE][18] ([i915#8102])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7443]: https://git

Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

[Alex Williamson]

On Wed, 26 Apr 2023 07:54:18 -0700
Yi Liu  wrote:

> This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound
> iommufd of the cdev device to check the ownership of the other affected
> devices and set a flag to tell user if the cdev device is resettable
> with a zero-length fd array.
> 
> For each of the affected devices, if it is bound to the iommufd of the
> cdev device, _INFO reports a valid dev_id > 0; if it is not opened by
> the calling user, but it is in the iommu_group of a device that is bound
> to the iommufd of the cdev device, reports dev_id == 0; If the device is
> un-owned device, configured within a different iommufd, or opened outside
> of the vfio device cdev API, the _INFO ioctl shall report dev_id==-1 for
> such affected devices. dev_id >=0 doesn't block hot-reset, while
> dev_id == -1 will block hot-reset.
> 
> This adds flag VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID to tell the user
> dev_id is returned and adds flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE to
> tell user if the cdev device is resettable or not.
> 
> Suggested-by: Jason Gunthorpe 
> Suggested-by: Alex Williamson 
> Signed-off-by: Yi Liu 
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 101 ---
>  include/uapi/linux/vfio.h|  39 +++-
>  2 files changed, 132 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c 
> b/drivers/vfio/pci/vfio_pci_core.c
> index 39e7823088e7..43858d471447 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -766,6 +766,51 @@ static int vfio_pci_get_irq_count(struct 
> vfio_pci_core_device *vdev, int irq_typ
>   return 0;
>  }
>  
> +static struct vfio_device *
> +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> +struct pci_dev *pdev)
> +{
> + struct vfio_device *cur;
> +
> + lockdep_assert_held(&dev_set->lock);
> +
> + list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> + if (cur->dev == &pdev->dev)
> + return cur;
> + return NULL;
> +}

Couldn't this just as easily take a struct device arg and live in
vfio/vfio_main.?

> +
> +/*
> + * Check if a given iommu_group has been bound to an iommufd within a
> + * devset.  Returns true if there is device in the devset which is in
> + * the input iommu_group and meanwhile bound to the input iommufd.
> + * Otherwise, returns false.
> + */
> +static bool
> +vfio_devset_iommufd_has_group(struct vfio_device_set *dev_set,
> +   struct iommufd_ctx *iommufd,
> +   struct iommu_group *iommu_group)
> +{
> + struct vfio_device *cur;
> + struct iommu_group *grp;
> + bool found = false;
> +
> + lockdep_assert_held(&dev_set->lock);
> +
> + list_for_each_entry(cur, &dev_set->device_list, dev_set_list) {
> + grp = iommu_group_get(cur->dev);
> + if (!grp)
> + continue;
> + iommu_group_put(grp);
> + if (iommu_group == grp &&
> + iommufd == vfio_iommufd_physical_ictx(cur)) {
> + found = true;
> + break;
> + }
> + }
> + return found;
> +}

And should this live in vfio/iommufd.c?  I'd change the variables to
vdev and group for consistency elsewhere (yeah, I see cur from removed
code below).  We also don't need the found variable, we can simply
return true from within the loop and false outside of the loop.  The
group variable could also be scoped within the loop.

> +
>  static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
>  {
>   (*(int *)data)++;
> @@ -776,13 +821,20 @@ struct vfio_pci_fill_info {
>   int max;
>   int cur;
>   struct vfio_pci_dependent_device *devices;
> + struct vfio_device *vdev;
> + bool devid;
> + bool resettable;

See other current threads on list about using bitfields.

>  };
>  
>  static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
>  {
>   struct vfio_pci_fill_info *fill = data;
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(fill->vdev);
> + struct vfio_device_set *dev_set = fill->vdev->dev_set;

Curious that we didn't added iommufd and dev_set fields to
vfio_pci_fill_info instead.  Both vars can be scoped within the devid
branch below.

>   struct iommu_group *iommu_group;
>  
> + lockdep_assert_held(&dev_set->lock);
> +
>   if (fill->cur == fill->max)
>   return -EAGAIN; /* Something changed, try again */
>  
> @@ -790,7 +842,34 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, void 
> *data)
>   if (!iommu_group)
>   return -EPERM; /* Cannot reset non-isolated devices */
>  
> - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + if (fill->devid) {
> + struct vfio_device *vdev;
> +
> + /*
> +  * Report devid for the affected devices:
> 

Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

[Alex Williamson]

On Thu, 27 Apr 2023 14:04:05 -0600
Alex Williamson  wrote:

> On Wed, 26 Apr 2023 07:54:18 -0700
> Yi Liu  wrote:
> 
> > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound
> > iommufd of the cdev device to check the ownership of the other affected
> > devices and set a flag to tell user if the cdev device is resettable
> > with a zero-length fd array.
> > 
> > For each of the affected devices, if it is bound to the iommufd of the
> > cdev device, _INFO reports a valid dev_id > 0; if it is not opened by
> > the calling user, but it is in the iommu_group of a device that is bound
> > to the iommufd of the cdev device, reports dev_id == 0; If the device is
> > un-owned device, configured within a different iommufd, or opened outside
> > of the vfio device cdev API, the _INFO ioctl shall report dev_id==-1 for
> > such affected devices. dev_id >=0 doesn't block hot-reset, while
> > dev_id == -1 will block hot-reset.
> > 
> > This adds flag VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID to tell the user
> > dev_id is returned and adds flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE to
> > tell user if the cdev device is resettable or not.
> > 
> > Suggested-by: Jason Gunthorpe 
> > Suggested-by: Alex Williamson 
> > Signed-off-by: Yi Liu 
> > ---
> >  drivers/vfio/pci/vfio_pci_core.c | 101 ---
> >  include/uapi/linux/vfio.h|  39 +++-
> >  2 files changed, 132 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c 
> > b/drivers/vfio/pci/vfio_pci_core.c
> > index 39e7823088e7..43858d471447 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -766,6 +766,51 @@ static int vfio_pci_get_irq_count(struct 
> > vfio_pci_core_device *vdev, int irq_typ
> > return 0;
> >  }
> >  
> > +static struct vfio_device *
> > +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> > +  struct pci_dev *pdev)
> > +{
> > +   struct vfio_device *cur;
> > +
> > +   lockdep_assert_held(&dev_set->lock);
> > +
> > +   list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > +   if (cur->dev == &pdev->dev)
> > +   return cur;
> > +   return NULL;
> > +}  
> 
> Couldn't this just as easily take a struct device arg and live in
> vfio/vfio_main.?
> 
> > +
> > +/*
> > + * Check if a given iommu_group has been bound to an iommufd within a
> > + * devset.  Returns true if there is device in the devset which is in
> > + * the input iommu_group and meanwhile bound to the input iommufd.
> > + * Otherwise, returns false.
> > + */
> > +static bool
> > +vfio_devset_iommufd_has_group(struct vfio_device_set *dev_set,
> > + struct iommufd_ctx *iommufd,
> > + struct iommu_group *iommu_group)
> > +{
> > +   struct vfio_device *cur;
> > +   struct iommu_group *grp;
> > +   bool found = false;
> > +
> > +   lockdep_assert_held(&dev_set->lock);
> > +
> > +   list_for_each_entry(cur, &dev_set->device_list, dev_set_list) {
> > +   grp = iommu_group_get(cur->dev);
> > +   if (!grp)
> > +   continue;
> > +   iommu_group_put(grp);
> > +   if (iommu_group == grp &&
> > +   iommufd == vfio_iommufd_physical_ictx(cur)) {
> > +   found = true;
> > +   break;
> > +   }
> > +   }
> > +   return found;
> > +}  
> 
> And should this live in vfio/iommufd.c?  I'd change the variables to
> vdev and group for consistency elsewhere (yeah, I see cur from removed
> code below).  We also don't need the found variable, we can simply
> return true from within the loop and false outside of the loop.  The
> group variable could also be scoped within the loop.
> 
> > +
> >  static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> >  {
> > (*(int *)data)++;
> > @@ -776,13 +821,20 @@ struct vfio_pci_fill_info {
> > int max;
> > int cur;
> > struct vfio_pci_dependent_device *devices;
> > +   struct vfio_device *vdev;
> > +   bool devid;
> > +   bool resettable;  
> 
> See other current threads on list about using bitfields.
> 
> >  };
> >  
> >  static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> >  {
> > struct vfio_pci_fill_info *fill = data;
> > +   struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(fill->vdev);
> > +   struct vfio_device_set *dev_set = fill->vdev->dev_set;  
> 
> Curious that we didn't added iommufd and dev_set fields to
> vfio_pci_fill_info instead.  Both vars can be scoped within the devid
> branch below.
> 
> > struct iommu_group *iommu_group;
> >  
> > +   lockdep_assert_held(&dev_set->lock);
> > +
> > if (fill->cur == fill->max)
> > return -EAGAIN; /* Something changed, try again */
> >  
> > @@ -790,7 +842,34 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, 
> > void *data)
> > if (!iommu_group)
> > return -EPERM; /* Cannot reset non-iso

Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

[Gustavo Sousa]

Quoting Vinod Govindapillai (2023-04-27 12:00:15)
>From: Mika Kahola 
>
>Display14 introduces a new way to instruct the PUnit with
>power and bandwidth requirements of DE. Add the functionality
>to program the registers and handle waits using interrupts.
>The current wait time for timeouts is programmed for 10 msecs to
>factor in the worst case scenarios. Changes made to use REG_BIT
>for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
>Wa_14016740474 is added which applies to Xe_LPD+ display
>
>v2: checkpatch warning fixes, simplify program pmdemand part
>
>v3: update to dbufs and pipes values to pmdemand register(stan)
>Removed the macro usage in update_pmdemand_values()
>
>Bspec: 66451, 64636, 64602, 64603
>Cc: Matt Atwood 
>Cc: Matt Roper 
>Cc: Lucas De Marchi 
>Cc: Gustavo Sousa 
>Signed-off-by: José Roberto de Souza 
>Signed-off-by: Radhakrishna Sripada 
>Signed-off-by: Gustavo Sousa 
>Signed-off-by: Mika Kahola 
>Signed-off-by: Vinod Govindapillai 
>---
> drivers/gpu/drm/i915/Makefile |   3 +-
> drivers/gpu/drm/i915/display/intel_display.c  |   7 +
> .../gpu/drm/i915/display/intel_display_core.h |   6 +
> .../drm/i915/display/intel_display_driver.c   |   7 +
> .../drm/i915/display/intel_display_power.c|   8 +
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
> drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
> drivers/gpu/drm/i915/i915_irq.c   |  21 +-
> drivers/gpu/drm/i915/i915_reg.h   |  36 +-
> 9 files changed, 562 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
>
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 9af76e376ca9..eb899fa86e51 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -281,7 +281,8 @@ i915-y += \
>display/i9xx_wm.o \
>display/skl_scaler.o \
>display/skl_universal_plane.o \
>-  display/skl_watermark.o
>+  display/skl_watermark.o \
>+  display/intel_pmdemand.o
> i915-$(CONFIG_ACPI) += \
>display/intel_acpi.o \
>display/intel_opregion.o
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>b/drivers/gpu/drm/i915/display/intel_display.c
>index bf391a6cd8d6..f98e235fadc6 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -99,6 +99,7 @@
> #include "intel_pcode.h"
> #include "intel_pipe_crc.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> #include "intel_sdvo.h"
>@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
>return ret;
>}
> 
>+  ret = intel_pmdemand_atomic_check(state);
>+  if (ret)
>+  goto fail;
>+
>ret = intel_atomic_check_crtcs(state);
>if (ret)
>goto fail;
>@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct 
>intel_atomic_state *state)
>}
> 
>intel_sagv_pre_plane_update(state);
>+  intel_pmdemand_pre_plane_update(state);
> 
>/* Complete the events for pipes that have now been disabled */
>for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
>@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct 
>intel_atomic_state *state)
>intel_verify_planes(state);
> 
>intel_sagv_post_plane_update(state);
>+  intel_pmdemand_post_plane_update(state);
> 
>drm_atomic_helper_commit_hw_done(&state->base);
> 
>diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
>b/drivers/gpu/drm/i915/display/intel_display_core.h
>index 9f66d734edf6..9471a052aa57 100644
>--- a/drivers/gpu/drm/i915/display/intel_display_core.h
>+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
>@@ -345,6 +345,12 @@ struct intel_display {
>struct intel_global_obj obj;
>} dbuf;
> 
>+  struct {
>+  wait_queue_head_t waitqueue;
>+  struct mutex lock;
>+  struct intel_global_obj obj;
>+  } pmdemand;
>+
>struct {
>/*
> * dkl.phy_lock protects against concurrent access of the
>diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
>b/drivers/gpu/drm/i915/display/intel_display_driver.c
>index 60ce10fc7205..79853d8c3240 100644
>--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
>+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
>@@ -47,6 +47,7 @@
> #include "intel_opregion.h"
> #include "intel_overlay.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_quirks.h"
> #include "intel_vga.h"
>@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct 
>drm_i915_private *i915)
>if (ret < 0)
>goto cleanup_vga;
> 
>+  intel_pmdemand_init(i915);
>+
>intel_power_domains_init_hw(i915, fals

Re: [Intel-gfx] [PATCH v4 9/9] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Alex Williamson]

On Wed, 26 Apr 2023 07:54:19 -0700
Yi Liu  wrote:

> This is the way user to invoke hot-reset for the devices opened by cdev
> interface. User should check the flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE
> in the output of VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl before doing
> hot-reset for cdev devices.
> 
> Suggested-by: Jason Gunthorpe 
> Signed-off-by: Jason Gunthorpe 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 66 +++-
>  include/uapi/linux/vfio.h| 22 +++
>  2 files changed, 79 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c 
> b/drivers/vfio/pci/vfio_pci_core.c
> index 43858d471447..f70e3b948b16 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -180,7 +180,8 @@ static void vfio_pci_probe_mmaps(struct 
> vfio_pci_core_device *vdev)
>  struct vfio_pci_group_info;
>  static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
>  static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> -   struct vfio_pci_group_info *groups);
> +   struct vfio_pci_group_info *groups,
> +   struct iommufd_ctx *iommufd_ctx);
>  
>  /*
>   * INTx masking requires the ability to disable INTx signaling via 
> PCI_COMMAND
> @@ -1364,8 +1365,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct 
> vfio_pci_core_device *vdev,
>   if (ret)
>   return ret;
>  
> - /* Somewhere between 1 and count is OK */
> - if (!array_count || array_count > count)
> + if (array_count > count)
>   return -EINVAL;

Doesn't this need a || vfio_device_cdev_opened(vdev) test as well?
It's invalid to pass fds for a cdev device.  Presumably it would fail
later collecting group fds as well, but might as well enforce the
semantics early.

>  
>   group_fds = kcalloc(array_count, sizeof(*group_fds), GFP_KERNEL);
> @@ -1414,7 +1414,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct 
> vfio_pci_core_device *vdev,
>   info.count = array_count;
>   info.files = files;
>  
> - ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, &info);
> + ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, &info, NULL);
>  
>  hot_reset_release:
>   for (file_idx--; file_idx >= 0; file_idx--)
> @@ -1429,6 +1429,7 @@ static int vfio_pci_ioctl_pci_hot_reset(struct 
> vfio_pci_core_device *vdev,
>  {
>   unsigned long minsz = offsetofend(struct vfio_pci_hot_reset, count);
>   struct vfio_pci_hot_reset hdr;
> + struct iommufd_ctx *iommufd;
>   bool slot = false;
>  
>   if (copy_from_user(&hdr, arg, minsz))
> @@ -1443,7 +1444,12 @@ static int vfio_pci_ioctl_pci_hot_reset(struct 
> vfio_pci_core_device *vdev,
>   else if (pci_probe_reset_bus(vdev->pdev->bus))
>   return -ENODEV;
>  
> - return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count, slot, arg);
> + if (hdr.count)
> + return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count, 
> slot, arg);
> +
> + iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> +
> + return vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, NULL, iommufd);

Why did we need to store iommufd in a variable?

>  }
>  
>  static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,
> @@ -2415,6 +2421,9 @@ static bool vfio_dev_in_groups(struct 
> vfio_pci_core_device *vdev,
>  {
>   unsigned int i;
>  
> + if (!groups)
> + return false;
> +
>   for (i = 0; i < groups->count; i++)
>   if (vfio_file_has_dev(groups->files[i], &vdev->vdev))
>   return true;
> @@ -2488,13 +2497,38 @@ static int vfio_pci_dev_set_pm_runtime_get(struct 
> vfio_device_set *dev_set)
>   return ret;
>  }
>  
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> + struct iommu_group *iommu_group;
> +
> + if (!iommufd_ctx)
> + return false;
> +
> + if (iommufd == iommufd_ctx)
> + return true;
> +
> + iommu_group = iommu_group_get(vdev->vdev.dev);
> + if (!iommu_group)
> + return false;
> +
> + /*
> +  * Try to check if any device within iommu_group is bound with
> +  * the input iommufd_ctx.
> +  */
> + return vfio_devset_iommufd_has_group(vdev->vdev.dev_set,
> +  iommufd_ctx, iommu_group);
> +}

This last test makes this not do what the function name suggests it
does.  If it were true, the device is not in the iommufd_ctx, it simply
cannot be within another iommu ctx.

> +
>  /*
>   * We need to get memory_lock for each device, but devices can share 
> mmap_lock,
>   * therefore we need to

[Intel-gfx] [PATCH 2/2] drm/i915/fdinfo: Enable fdinfo for GuC backends

[Umesh Nerlige Ramappa]

Enable fdinfo for GuC based platforms with the exception that long
running contexts will not provide reliable busyness data unless they
switch out at some reasonable point in time.

Link: https://gitlab.freedesktop.org/drm/intel/issues/8303
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_drm_client.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index e8fa172ebe5e..d18d0a3ed905 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -147,11 +147,7 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct 
file *f)
   PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
seq_printf(m, "drm-client-id:\t%u\n", client->id);
 
-   /*
-* Temporarily skip showing client engine information with GuC 
submission till
-* fetching engine busyness is implemented in the GuC submission backend
-*/
-   if (GRAPHICS_VER(i915) < 8 || 
intel_uc_uses_guc_submission(&i915->gt0.uc))
+   if (GRAPHICS_VER(i915) < 8)
return;
 
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
-- 
2.36.1

[Intel-gfx] [PATCH 0/2] fdinfo: Enable some support for GuC based client busyness

[Umesh Nerlige Ramappa]

Export context runtime into the fdinfo framework to enable per client
busyness for GuC back-end.

v2: Fix zeroed busyness values
v3: Include review comments from Ashutosh

Signed-off-by: Umesh Nerlige Ramappa 

Umesh Nerlige Ramappa (2):
  i915/pmu: Add support for total context runtime for GuC back-end
  drm/i915/fdinfo: Enable fdinfo for GuC backends

 drivers/gpu/drm/i915/gt/intel_context.c   |  5 ++-
 drivers/gpu/drm/i915/gt/intel_context.h   |  2 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  2 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 +++
 drivers/gpu/drm/i915/i915_drm_client.c|  6 +---
 5 files changed, 39 insertions(+), 7 deletions(-)

-- 
2.36.1

[Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end

[Umesh Nerlige Ramappa]

GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
in the context image. This value is saved/restored on context switches.
KMD accumulates these values into a 64 bit counter taking care of any
overflows as needed. This count provides the basis for client specific
busyness in the fdinfo interface.

KMD accumulation happens just before the context is unpinned and when
context switches out. This works for execlist back-end since execlist
scheduling has visibility into context switches. With GuC mode, KMD does
not have visibility into context switches and this counter is
accumulated only when context is unpinned. Context is unpinned once the
context scheduling is successfully disabled. Disabling context
scheduling is an asynchronous operation. Also if a context is servicing
frequent requests, scheduling may never be disabled on it.

For GuC mode, since updates to the context runtime may be delayed, add
hooks to update the context runtime in a worker thread as well as when
a user queries for it.

Limitation:
- If a context is never switched out or runs for a long period of time,
  the runtime value of CTX_TIMESTAMP may never be updated, so the
  counter value may be unreliable. This patch does not support such
  cases. Such support must be available from the GuC FW and it is WIP.

This patch is an extract from previous work authored by John/Umesh here -
https://patchwork.freedesktop.org/patch/496441/?series=105085&rev=4

v2: (Ashutosh)
- Drop COPS_RUNTIME_ACTIVE_TOTAL
- s/guc_context_update_clks/__guc_context_update_stats
- Pin context before accessing in guc_timestamp_ping
- In guc_context_unpin, use spinlock to serialize access to runtime stats

Signed-off-by: Umesh Nerlige Ramappa 
Co-developed-by: John Harrison 
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_context.c   |  5 ++-
 drivers/gpu/drm/i915/gt/intel_context.h   |  2 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  2 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 +++
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b8..a53b26178f0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -578,10 +578,13 @@ void intel_context_bind_parent_child(struct intel_context 
*parent,
child->parallel.parent = parent;
 }
 
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
 {
u64 total, active;
 
+   if (ce->ops->update_stats)
+   ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index 48f888c3da08..43ed92f8dc83 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -375,7 +375,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
 }
 
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
 u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
 
 static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e36670f2e626..aceaac28a33e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -58,6 +58,8 @@ struct intel_context_ops {
 
void (*sched_disable)(struct intel_context *ce);
 
+   void (*update_stats)(struct intel_context *ce);
+
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index ee3e8352637f..c869ddc73e69 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1402,13 +1402,34 @@ static void __update_guc_busyness_stats(struct 
intel_guc *guc)
spin_unlock_irqrestore(&guc->timestamp.lock, flags);
 }
 
+static void __guc_context_update_stats(struct intel_context *ce)
+{
+   struct intel_guc *guc = ce_to_guc(ce);
+   unsigned long flags;
+
+   spin_lock_irqsave(&guc->timestamp.lock, flags);
+   lrc_update_runtime(ce);
+   spin_unlock_irqrestore(&guc->timestamp.lock, flags);
+}
+
+static void guc_context_update_stats(struct intel_context *ce)
+{
+   if (!intel_context_pin_if_active(ce))
+   return;
+
+   __guc_context_update_stats(ce);
+   intel_context_unpin(ce);
+}
+
 static void guc_timestamp_ping(struct work_struct *wrk)
 {
struct intel_guc *gu

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() 
(rev2)
URL   : https://patchwork.freedesktop.org/series/116947/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116947v2_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
- shard-apl:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl1/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl3/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2846])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb:  [PASS][8] -> [FAIL][9] ([i915#8295])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-snb5/igt@gem_pp...@blt-vs-render-ctxn.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +25 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

  * igt@kms_cdclk@mode-transition:
- shard-glk:  NOTRUN -> [SKIP][11] ([fdo#109271]) +6 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk6/igt@kms_cd...@mode-transition.html

  * igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl:  NOTRUN -> [TIMEOUT][12] ([i915#7173])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@kms_content_protection@ato...@pipe-a-dp-1.html

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271]) +5 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-snb1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-...@pipe-b-hdmi-a-1.html

  * igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk6/igt@kms_psr2...@overlay-plane-move-continuous-sf.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][17] ([i915#7461] / [i915#8234]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-dg1-17/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}:   [FAIL][19] ([i915#6268]) 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for 
efficient freq (rev3)
URL   : https://patchwork.freedesktop.org/series/116957/
State : warning

== Summary ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for 
efficient freq (rev3)
URL   : https://patchwork.freedesktop.org/series/116957/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116957v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [FAIL][3] ([i915#7913] / [i915#8383])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][4] -> [ABORT][5] ([i915#8384])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271]) +16 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8:  [PASS][7] -> [FAIL][8] ([i915#7932]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][9] ([i915#7916]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@slpc:
- bat-adln-1: [FAIL][11] ([i915#6997]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-adln-1/igt@i915_selftest@l...@slpc.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][13] -> [ABORT][14] ([i915#8397])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#8383]: https://gitlab.freedesktop.org/drm/intel/issues/8383
  [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
  [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397


Build changes
-

  * Linux: CI_DRM_13071 -> Patchwork_116957v3

  CI-20190529: 20190529
  CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116957v3: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4794ebe681d1 drm/i915/selftest: Update the SLPC selftest
3e9db6645c0c drm/i915/guc/slpc: Provide sysfs for efficient freq

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fdinfo: Enable some support for GuC based client busyness (rev2)

[Patchwork]

== Series Details ==

Series: fdinfo: Enable some support for GuC based client busyness (rev2)
URL   : https://patchwork.freedesktop.org/series/116120/
State : warning

== Summary ==

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

[Intel-gfx] [PATCH v9 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

[Alan Previn]

Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.

Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.

We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
 - a buffer for the HECI packet that contains PXP FW commands
 - a batch-buffer that contains the engine instruction for
   sending the HECI packet to the GSC firmware.

Thus, add the allocation and freeing of these buffers in gsccs
init and fini.

The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.

The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   3 +-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |   3 +
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|   4 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 5 files changed, 254 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 3f60cbc011c1..0db216a031af 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -50,7 +50,8 @@ struct intel_gsc_mtl_header {
 * we distinguish the flags using OUTFLAG or INFLAG
 */
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
 
u32 status;
 } __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
 /* PXP-Cmd-Op definitions */
 #define PXP43_CMDID_START_HUC_AUTH 0x003A
 
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
 /* PXP-Input-Packet: HUC-Authentication */
 struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
 #include "gem/i915_gem_internal.h"
 
 #include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_types.h"
 
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+  void *msg_in, size_t msg_in_size,
+  void *msg_out, size_t msg_out_size_max,
+  size_t *msg_out_len,
+  u64 *gsc_msg_handle_retry)
+{
+   struct intel_gt *gt = pxp->ctrl_gt;
+   struct drm_i915_private *i915 = gt->i915;
+   struct gsccs_session_resources *exec_res =  &pxp->gsccs_res;
+   struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+   struct intel_gsc_heci_non_priv_pkt pkt;
+   size_t max_msg_size;
+   u32 reply_size;
+   int ret;
+
+   if (!exec_res->ce)
+   return -ENODEV;
+
+   max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+   if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+   return -ENOSPC;
+
+   if (!exec_res->pkt_vma || !exec_res->bb_vma)
+   return -ENOENT;
+
+   GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+   mutex_lock(&pxp->tee_mutex);
+
+   memset(header, 0, sizeof(*header));
+   intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+   /* check if this is a host-session-handle cleanup call (empty packet) */
+   if (!msg_in && !msg_out)
+   header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+   /* copy caller provided gsc

[Intel-gfx] [PATCH v9 0/8] drm/i915/pxp: Add MTL PXP Support

[Alan Previn]

This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created when protected contexts are created.

In this series, the front end behaviors and interfaces (uapi) remain
the same. We add backend support for MTL but with MTL we directly use
the GSC-CS engine on the MTL GPU device to send messages to the PXP
(a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format
of the message is slightly different with a 2-layer packetization
that is explained in detail in Patch #3. Also, the second layer
which is the actual PXP firmware packet is now rev'd to version 4.3
for MTL that is defined in Patch #5.

Take note that Patch #4 adds the buffer allocation and gsccs-send-
message without actually being called by the arb-creation code
which gets added in Patch #5. Additionally, a seperate series being
reviewed is introducing a change for session teardown (in pxp front-
end layer that will need backend support by both legacy and gsccs).
If we squash all of these together (buffer-alloc, send-message,
arb-creation and, in future, session-termination), the single patch
will be rather large. That said, we are keeping Patch #4 and #5
separate for now, but at merge time, we can squash them together
if maintainer requires it.

Changes from prior revs:
   v1 : - fixed when building with CONFIG_PXP disabled.
- more alignment with gsc_mtl_header structure from the HDCP
   v2 : - (all following changes as per reviews from Daniele)
- squashed Patch #1 from v1 into the next one.
- replaced unnecessary "uses_gsccs" boolean in the pxp
  with "HAS_ENGINE(pxp->ctrl_gt, GSC0)".
- moved the stashing of gsccs resources from a dynamically
  allocated opaque handle to an explicit sub-struct in
  'struct intel_pxp'.
- moved the buffer object allocations from Patch #1 of this
  series to Patch #5 (but keep the context allocation in
  Patch #1).
- used the kernel default ppgtt for the gsccs context.
- optimized the buffer allocation and deallocation code
  and drop the need to stash the drm_i915_gem_object.
- use a macro with the right mmio reg base (depending
  on root-tile vs media-tile) along with common relative
  offset to access all KCR registers thus minimizing
  changes to the KCR register access codes.
- fixed bugs in the heci packet request submission code
  in Patch #3 (of this series)
- add comments in the mtl-gsc-heci-header regarding the
  host-session-handle.
- re-use tee-mutex instead of introducing a gsccs specific
  cmd mutex.
- minor cosmetic improvements in Patch #5.
- before creating arb session, ensure intel_pxp_start
  first ensures the GSC FW is up and running.
- use 2 second timeout for the pending-bit scenario when
  sending command to GSC-FW as per specs.
- simplify intel_pxp_get_irq_gt with addition comments
- redo Patch #7 to minimize the changes without introducing
  a common  abstraction helper for suspend/resume/init/fini
  codes that have to change the kcr power state.
   v3 : - rebase onto latest drm-tip with the updated firmware
  session invalidation flow
- on Patch#1: move 'mutex_init(&pxp->tee_mutex)' to a common
  init place in intel_pxp_init since its needed everywhere
  (Daniele)
- on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);"
  (Daniele)
- on Patch#2: move the introduction of host_session_handle to
  Patch#4 where it starts getting used.
- on Patch#4: move host-session-handle initialization to the
  allocate-resources during gsccs-init (away from Patch#5)
  and add the required call to PXP-firmware to cleanup the
  host-session-handle in destroy-resources during gsccs-fini
- on Patch#5: add dispatching of arb session termination
  firmware cmd during session teardown (as per latest
  upstream flows)
   v4 : - Added proper initialization and cleanup of host-session-handle
  that the gsc firmware expects.
- Fix the stream-session-key invalidation instruction for MTL.
   v5 : - In Patch #4, move the tee_mutex locking to after we check for
  valid vma allocations.
- In Patch #5, wait for intel_huc_is_authenticated instead of
  intel_uc_fw_is_running(gsc-fw) before starting ARB session.
- In Patch #5, increase the necessary timeouts at the top-level
  (PXP arb session creation / termination) to accomodate SLA of
  GSC firmware when busy with pending-bit responses.
- In Patch #5, remove redundant host_session_handle i

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

[Alan Previn]

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.

However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context
and is documented in the GEM UAPI headers.

While making this change, create a helper that is common to both
GET_PARAM caller and intel_pxp_start since the latter does
similiar checks.

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/i915_getparam.c |  7 +++
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 include/uapi/drm/i915_drm.h  | 19 ++
 4 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..6f11d7eaa91a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
 #include "gem/i915_gem_mman.h"
 #include "gt/intel_engine_user.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "i915_cmd_parser.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
@@ -102,6 +104,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+   case I915_PARAM_PXP_STATUS:
+   value = intel_pxp_get_readiness_status(i915->pxp);
+   if (value < 0)
+   return value;
+   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/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index b600d68de2a4..f143eadbc253 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -358,23 +358,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
 }
 
 /*
- * the arb session is restarted from the irq work when we receive the
- * termination completion interrupt
+ * this helper is used by both intel_pxp_start and by
+ * the GET_PARAM IOCTL that user space calls. Thus, the
+ * return values here should match the UAPI spec.
  */
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
 {
-   int ret = 0;
-
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
 
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
-   return -ENXIO;
+   return 2;
} else {
if (wait_for(pxp_component_bound(pxp), 250))
-   return -ENXIO;
+   return 2;
}
+   return 1;
+}
+
+/*
+ * the arb session is restarted from the irq work when we receive the
+ * termination completion interrupt
+ */
+int intel_pxp_start(struct intel_pxp *pxp)
+{
+   int ret = 0;
+
+   ret = intel_pxp_get_readiness_status(pxp);
+   if (ret < 0)
+   return ret;
+   else if (ret > 1)
+   return -EIO; /* per UAPI spec, user may retry later */
 
mutex_lock(&pxp->arb_mutex);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..17e6dbc86b38 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -26,6 +26,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
 void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b15dd9cc2ffb..f4efbb2db0c5 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,25 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
 
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV = PXP support is not available on the GPU device or in the
+ *   kernel due to missing component drivers or kerne

[Intel-gfx] [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Alan Previn]

Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.

NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
 1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
 2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
 3- PXP: This series.

NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.

NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
   common helpers come in:
 - On MTL, when an i915 subsystem needs to send a command request
   to the security firmware, it will send that via the GSC-
   engine-command-streamer.
 - However those commands, (lets call them "gsc_specific_fw_api"
   calls), are not understood by the GSC command streamer hw.
 - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
   passes it along to the GSC firmware.
 - The GSC FW on the other hand needs additional metadata to know
   which usage service is being called (PXP, HDCP, proxy, etc) along
   with session specific info. Thus an extra header called GSC-CS
   HECI Memory Header, (C) in below diagram is prepended before
   the FW specific API, (D).
 - Thus, the structural layout of the request submitted would
   need to look like the diagram below (for non-priv PXP).
 - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
   PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
   will populate blob (C) while additional helpers, different for
   PPGGTT (this patch) vs GGTT (HDCP series) will populate
   blobs (A) and (B) below.
  ___
 (A)  |  MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
  | |   |
  |_|   |
  | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,|   |
  ||   pkt-addr-out, pkt-size-out)  |
  || MI_BATCH_BUFFER_END|   |   |
  |||   |   |
  | |   |
  |_|   |
|
-
|
   \|/
  __V___
  |   _|
  |(C)|   ||
  |   | struct intel_gsc_mtl_header { ||
  |   |   validity marker ||
  |   |   heci_clent_id   ||
  |   |   ... ||
  |   |  }||
  |   |___||
  |(D)|   ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   | ...   ||
  |   | For an example, see   ||
  |   | 'struct pxp43_create_arb_in' at   ||
  |   | intel_pxp_cmd_interface_43.h  ||
  |   |   ||
  |   | } ||
  |   |  Struture depends on command type ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   |___||
  ||

That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).

Signed-off-by: Alan Previn 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  23 
 2 files changed, 125 insertions(+

[Intel-gfx] [PATCH v9 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

[Alan Previn]

For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.

Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.

Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 20 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  2 -
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  8 +++
 6 files changed, 117 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..523fc9dda428 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -342,6 +342,7 @@ i915-y += \
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+   pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
 #include "i915_drv.h"
 
 #include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
 
-   ret = intel_pxp_tee_component_init(pxp);
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   ret = intel_pxp_gsccs_init(pxp);
+   else
+   ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
 
@@ -165,9 +169,12 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
/*
 * For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
 * on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
 */
-   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+   intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw) &&
+   intel_uc_fw_is_loadable(&i915->media_gt->uc.huc.fw))
return i915->media_gt;
 
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
 
+   /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+   mutex_init(&i915->pxp->tee_mutex);
 
/*
 * If full PXP feature is not available but HuC is loaded by GSC on 
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
 
i915->pxp->arb_is_valid = false;
 
-   intel_pxp_tee_component_fini(i915->pxp);
+   if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+   intel_pxp_gsccs_fini(i915->pxp);
+   else
+   intel_pxp_tee_component_fini(i915->pxp);
 
destroy_vcs_context(i915->pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+   struct gsccs_session_resources *exec_res = &pxp->gsccs_res;
+
+   if (exec_res->ce)
+   intel_context_put(exec_res->ce);
+
+   memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+   st

[Intel-gfx] [PATCH v9 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation

[Alan Previn]

Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:

1. Updating 'pick-gt' to get the media tile for
   KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
   (init, status-checking, etc.).

While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  6 
 5 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..7727eadb0672 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -101,7 +101,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
-   if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
+   if ((instance == OTHER_GSC_INSTANCE || instance == 
OTHER_KCR_INSTANCE) &&
+   HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
 #include "intel_pxp.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
 }
 
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+   u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES) 
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+   intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
 
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, true);
 }
 
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, false);
 }
 
 static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(&pxp->termination);
complete_all(&pxp->termination);
 
+   if (pxp->ctrl_gt->type == GT_MEDIA)
+   pxp->kcr_base = MTL_KCR_BASE;
+   else
+   pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_enable(pxp->ctrl_gt);
+   kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_disable(pxp->ctrl_gt);
-
+   kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
 }
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(bas

[Intel-gfx] [PATCH v9 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component

[Alan Previn]

On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.

Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c|  3 ++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
+#include "intel_pxp.h"
 #include "intel_pxp_cmd_interface_42.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
 
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
 {
+   intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+   with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_fini_hw(pxp);
 }
 
 int intel_pxp_gsccs_init(struct intel_pxp *pxp)
 {
-   return gsccs_allocate_execution_resource(pxp);
+   int ret;
+   intel_wakeref_t wakeref;
+
+   ret = gsccs_allocate_execution_resource(pxp);
+   if (!ret) {
+   with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_init_hw(pxp);
+   }
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
 * The PXP component gets automatically unbound when we go into S3 and
 * re-bound after we come out, so in that scenario we can defer the
 * hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
 */
-   if (!pxp->pxp_component)
+   if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
 
intel_pxp_init_hw(pxp);
-- 
2.39.0

[Intel-gfx] [PATCH v9 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS

[Alan Previn]

Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.

Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_pci.c  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c |  6 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  2 +-
 5 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5fcc9cfed671..f59122e33465 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1152,6 +1152,7 @@ static const struct intel_device_info mtl_info = {
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
+   .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f143eadbc253..bb2e15329f34 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
 }
 
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   return 250;
+}
+
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 17e6dbc86b38..17254c3f1267 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp 
*pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
 int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
 
 #include "intel_pxp.h"
 #include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_types.h"
 
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
 {
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+   int timeout_ms;
 
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp, 
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
 
+   timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(&pxp->termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
 
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp, 
u32 id, bool in_pla
  KCR_SIP(pxp->kcr_base),

[Intel-gfx] [PATCH v9 5/8] drm/i915/pxp: Add ARB session creation and cleanup

[Alan Previn]

Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.

While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT:
   Since the first merge of PXP support on ADL, i915 returns -ENXIO
   if a dependency such as firmware or component driver was yet to
   be loaded or returns -EIO if the creation attempt failed when
   requested by the PXP firmware (specific firmware error responses
   are reported in dmesg).

Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.

For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.

Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  10 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |   1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  27 +++-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  21 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|  12 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  11 +-
 include/uapi/drm/i915_drm.h   |  15 ++
 8 files changed, 220 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 236673c02f9a..013dfe284a28 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -13,6 +13,7 @@
 #define GSC_FW_STATUS_REG  _MMIO(0x116C40)
 #define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
 #define   GSC_FW_CURRENT_STATE_RESET   0
+#define   GSC_FW_PROXY_STATE_NORMAL5
 #define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
 
 static bool gsc_is_in_reset(struct intel_uncore *uncore)
@@ -31,6 +32,15 @@ bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
return fw_status & GSC_FW_INIT_COMPLETE_BIT;
 }
 
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_PROXY_STATE_NORMAL;
+}
+
 static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
 {
u32 offset = i915_ggtt_offset(gsc->local);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index f4c1106bb2a9..fff8928218df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -13,5 +13,6 @@ struct intel_uncore;
 
 int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..b600d68de2a4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
 
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 250;
+
+   if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
 
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
 
 static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   el

[Intel-gfx] ✓ Fi.CI.BAT: success for fdinfo: Enable some support for GuC based client busyness (rev2)

[Patchwork]

== Series Details ==

Series: fdinfo: Enable some support for GuC based client busyness (rev2)
URL   : https://patchwork.freedesktop.org/series/116120/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116120v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  NOTRUN -> [FAIL][3] ([i915#7916])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [FAIL][4] ([i915#7913] / [i915#8383])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@migrate:
- bat-atsm-1: [PASS][5] -> [FAIL][6] ([i915#6268] / [i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-atsm-1/igt@i915_selftest@l...@migrate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rplp-1: [PASS][7] -> [FAIL][8] ([i915#7913])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rplp-1/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rplp-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271]) +16 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][10] ([i915#7828])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#1845])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][12] ([i915#6687]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][14] ([i915#7916]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-6}:   [ABORT][16] ([i915#7920]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: [FAIL][18] ([i915#6997]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][20] -> [ABORT][21] ([i915#8397])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=10

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: Add MTL PXP Support (rev9)
URL   : https://patchwork.freedesktop.org/series/112647/
State : warning

== Summary ==

Error: dim checkpatch failed
e93c6f73e145 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:99: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#99: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 173 lines checked
c4038c750253 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#109: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 153 lines checked
89dc3a6ba479 drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
35ffeec3fe80 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
-:109: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#109: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:43:
+   GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));

total: 0 errors, 1 warnings, 0 checks, 326 lines checked
8f8dbe8a8d33 drm/i915/pxp: Add ARB session creation and cleanup
7ba97b08f8de drm/i915/uapi/pxp: Add a GET_PARAM for PXP
-:24: WARNING:TYPO_SPELLING: 'similiar' may be misspelled - perhaps 'similar'?
#24: 
similiar checks.


total: 0 errors, 1 warnings, 0 checks, 96 lines checked
0a11a1c36145 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
0d4594ea1808 drm/i915/pxp: Enable PXP with MTL-GSC-CS

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: Add MTL PXP Support (rev9)
URL   : https://patchwork.freedesktop.org/series/112647/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Teres Alexis, Alan Previn]

On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> Add helper functions into a new file for heci-packet-submission.
> The helpers will handle generating the MTL GSC-CS Memory-Header
> and submission of the Heci-Cmd-Packet instructions to the engine.
> 
> 
alan: I accidentally forgot to carry Daniele's RB forward from rev8.
Repasting as this patch did not change:

Reviewed-by: Daniele Ceraolo Spurio 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: Add MTL PXP Support (rev9)
URL   : https://patchwork.freedesktop.org/series/112647/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071 -> Patchwork_112647v9


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 36)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#8384])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8:  [PASS][3] -> [FAIL][4] ([i915#7932])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [FAIL][5] ([i915#7916]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  
 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g:   [ABORT][7] -> [ABORT][8] ([i915#8397])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html

  
  [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
  [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397


Build changes
-

  * Linux: CI_DRM_13071 -> Patchwork_112647v9

  CI-20190529: 20190529
  CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112647v9: b9458e7075652669ec0e04abe039a5ed001701fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

e8198913fb52 drm/i915/pxp: Enable PXP with MTL-GSC-CS
011a5305fc2e drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
2376e499100c drm/i915/uapi/pxp: Add a GET_PARAM for PXP
1ec1cc5c4289 drm/i915/pxp: Add ARB session creation and cleanup
7dbb00a61263 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
3419de8797ba drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
0bfe806a36ed drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
e72c1f99d86c drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for mtl: add support for pmdemand (rev4)

[Patchwork]

== Series Details ==

Series: mtl: add support for pmdemand (rev4)
URL   : https://patchwork.freedesktop.org/series/116949/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116949v4_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk8/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-glk7/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html

  
 Suppressed 

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

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}:   [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html

  * igt@i915_selftest@live@workarounds:
- {shard-dg1}:[PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@i915_selftest@l...@workarounds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-dg1-13/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-glk3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@gem_huc_c...@huc-copy.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +25 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

  * igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl:  NOTRUN -> [TIMEOUT][13] ([i915#7173])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@kms_content_protection@ato...@pipe-a-dp-1.html

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][14] ([fdo#109271]) +21 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-snb1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-...@pipe-b-hdmi-a-1.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][17] ([i915#7461] / [i915#8234]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-dg1-12/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_eio@hibernate:
- shard-apl:  [ABORT][19] -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tr

[Intel-gfx] [CI] PR for HuC v8.4.5 for MTL

[Daniele Ceraolo Spurio]

The following changes since commit fab149657d8d029c06179dd006b59b2f3594f916:

  Group all Conexant V4L devices together (2023-04-27 09:15:55 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_8.4.5

for you to fetch changes up to 2cae62ee3cc08ad2d6271a5664f18462294d62be:

  i915: add HuC v8.4.5 for MTL (2023-04-27 17:39:43 -0700)


Daniele Ceraolo Spurio (1):
  i915: add HuC v8.4.5 for MTL

 WHENCE   |   3 +++
 i915/mtl_huc_gsc.bin | Bin 0 -> 626688 bytes
 2 files changed, 3 insertions(+)
 create mode 100755 i915/mtl_huc_gsc.bin

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hugepage manager and test for MTL (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Hugepage manager and test for MTL (rev3)
URL   : https://patchwork.freedesktop.org/series/116995/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116995v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@gem_huc_c...@huc-copy.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +25 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

  * igt@kms_cdclk@mode-transition:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271]) +6 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-glk8/igt@kms_cd...@mode-transition.html

  * igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl:  NOTRUN -> [TIMEOUT][8] ([i915#7173])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@kms_content_protection@ato...@pipe-a-dp-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2346])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271]) +37 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-snb6/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-vga-1.html

  * igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-glk8/igt@kms_psr2...@overlay-plane-move-continuous-sf.html

  
 Possible fixes 

  * igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14] +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][15] ([i915#7461] / [i915#8234]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-dg1-12/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}:   [FAIL][17] ([i915#6268]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_eio@hibernate:
- shard-apl:  [ABORT][19] -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_...@hibernate.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@gem_...@hibernate.html

  * igt@gem_eio@res

[Intel-gfx] [PATCH 1/8] DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy

[Daniele Ceraolo Spurio]

This is a squash of the GSC proxy series, which is being reviewed
separately [1]. It's being included here because some of the patches in
this series depend on it. This is not a functional dependencies, the
patches just touch the same code and the proxy patches are planned to be
merged first, so it is easier to base the new patches on top of it.

[1] https://patchwork.freedesktop.org/series/115806/
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  66 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
 drivers/misc/mei/Kconfig  |   2 +-
 drivers/misc/mei/Makefile |   1 +
 drivers/misc/mei/gsc_proxy/Kconfig|  14 +
 drivers/misc/mei/gsc_proxy/Makefile   |   7 +
 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
 include/drm/i915_component.h  |   3 +-
 include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
 15 files changed, 830 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
 create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
 create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
 create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
 create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..f2ac803e35b4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -194,6 +194,7 @@ i915-y += \
 # general-purpose microcontroller (GuC) support
 i915-y += \
  gt/uc/intel_gsc_fw.o \
+ gt/uc/intel_gsc_proxy.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_gsc_uc_heci_cmd_submit.o\
  gt/uc/intel_guc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..95e59ed6651d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -16,6 +16,7 @@
 #include "intel_uncore.h"
 #include "intel_rps.h"
 #include "pxp/intel_pxp_irq.h"
+#include "uc/intel_gsc_proxy.h"
 
 static void guc_irq_handler(struct intel_guc *guc, u16 iir)
 {
@@ -82,6 +83,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
instance,
if (instance == OTHER_GSC_INSTANCE)
return intel_gsc_irq_handler(gt, iir);
 
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return intel_gsc_proxy_irq_handler(>->uc.gsc, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
  instance, iir);
 }
@@ -101,6 +105,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return media_gt;
if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
return media_gt;
fallthrough;
@@ -257,6 +263,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
u32 irqs = GT_RENDER_USER_INTERRUPT;
u32 guc_mask = intel_uc_wants_guc(>->uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
+   u32 heci_mask = 0;
u32 dmask;
u32 smask;
 
@@ -268,10 +275,16 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
dmask = irqs << 16 | irqs;
smask = irqs << 16;
 
-   if (HAS_ENGINE(gt, GSC0))
+   if (HAS_ENGINE(gt, GSC0)) {
+   /*
+* the heci2 interrupt is enabled via the same register as the
+* GSC interrupt, but it has its own mask register.
+*/
gsc_mask = irqs;
-   else if (HAS_HECI_GSC(gt->i915))
+   heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
+   } else if (HAS_HECI_GSC(gt->i915)) {
gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+   }
 
BUILD_BUG_ON(irqs & 0x);
 
@@ -281,7 +294,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (CCS_MASK(gt))
intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, smask);
if (gsc_mask)
-   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask);
+   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask | heci_mask);
 
/* Unmask irqs on RCS, BCS, VCS and VECS engines. */
intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask);
@@ -309,6 +322,9 @@ void

[Intel-gfx] [PATCH 2/8] drm/i915/uc: perma-pin firmwares

[Daniele Ceraolo Spurio]

Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Given that we use dummy vmas for the pinning, we do need to explicitly
re-pin on resume because the automated helper won't cover us.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  3 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  7 -
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  8 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 36 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  5 +++-
 8 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..ab71ed11de79 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1322,6 +1322,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(&ggtt->vm, ggtt->error_capture.start,
   ggtt->error_capture.size);
 
+   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+   intel_uc_resume_mappings(>->uc);
+
ggtt->invalidate(ggtt);
 
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 64bff01026e8..af542e3cb3e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -80,7 +80,12 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
 {
struct intel_gt *gt = gsc_uc_to_gt(gsc);
 
-   intel_uc_fw_init_early(&gsc->fw, INTEL_UC_FW_TYPE_GSC);
+   /*
+* GSC FW needs to be copied to a dedicated memory allocations for
+* loading (see gsc->local), so we don't need to GGTT map the FW image
+* itself into GGTT.
+*/
+   intel_uc_fw_init_early(&gsc->fw, INTEL_UC_FW_TYPE_GSC, false);
INIT_WORK(&gsc->work, gsc_work);
 
/* we can arrive here from i915_driver_early_probe for primary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c9f20385f6a0..2eb891b270ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -164,7 +164,7 @@ void intel_guc_init_early(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
 
-   intel_uc_fw_init_early(&guc->fw, INTEL_UC_FW_TYPE_GUC);
+   intel_uc_fw_init_early(&guc->fw, INTEL_UC_FW_TYPE_GUC, true);
intel_guc_ct_init_early(&guc->ct);
intel_guc_log_init_early(&guc->log);
intel_guc_submission_init_early(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index aefdaa62da99..9721761373fb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -276,7 +276,7 @@ void intel_huc_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
struct intel_gt *gt = huc_to_gt(huc);
 
-   intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
+   intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC, true);
 
/*
 * we always init the fence as already completed, even if HuC is not
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 996168312340..b6adfda3761e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -697,6 +697,12 @@ void intel_uc_suspend(struct intel_uc *uc)
}
 }
 
+static void __uc_resume_mappings(struct intel_uc *uc)
+{
+   intel_uc_fw_resume_mapping(&uc->guc.fw);
+   intel_uc_fw_resume_mapping(&uc->huc.fw);
+}
+
 static int __uc_resume(struct intel_uc *uc, bool enable_communication)
 {
struct intel_guc *guc = &uc->guc;
@@ -764,4 +770,6 @@ static const struct intel_uc_ops uc_ops_on = {
 
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
+
+   .resume_mappings = __uc_resume_mappings,
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 5d0f1bcc381e..c2783e6e752b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -24,6 +24,7 @@ struct intel_uc_ops {
void (*fini)(struct intel_uc *uc);
int (*init_hw)(struct intel_uc *uc);
void (*fini_hw)(struct intel_uc *uc);
+   void (*resume_mappings)(struct intel_uc *uc);
 };
 
 struct intel_uc {
@@ -113,6 +114,7 @@ intel_uc_ops_function(init, init, int, 0);
 intel_uc_ops_function(fini, fini, void, );
 intel_uc_ops_functio

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Parse the GSC-enabled HuC binary

[Daniele Ceraolo Spurio]

The new binaries that support the 2-step authentication have contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
manifest of the GSC binary. The manifest consist of a partition header
followed by entries, one of which contains the offset we're looking for.
Since we're now parsing the entries, we can extract the HuC version
that way instead of using hardcoded offsets.

Note that the meu structure will be re-used for parsing the GSC binary,
so they've been added in their own header.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc.c|  11 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 116 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   5 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  71 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   2 +
 7 files changed, 253 insertions(+), 47 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
new file mode 100644
index ..df9c482a8052
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_MEU_H_
+#define _INTEL_GSC_MEU_H_
+
+#include 
+
+/* Code partition structures */
+struct intel_gsc_cpt_directory_header_v2 {
+   u32 header_marker;
+#define INTEL_GSC_CPT_HEADER_MARKER 0x44504324
+
+   u32 num_of_entries;
+   u8 header_version;
+   u8 entry_version;
+   u8 header_length; /* in bytes */
+   u8 flags;
+   u32 partition_name;
+   u32 crc32;
+} __packed;
+
+struct intel_gsc_cpt_directory_entry {
+   u8 name[12];
+
+   /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+   u32 offset;
+#define INTEL_GSC_CPT_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPT_ENTRY_HUFFMAN_COMP BIT(25)
+
+   /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+   u32 length;
+
+   u8 reserved[4];
+} __packed;
+
+struct intel_gsc_meu_version {
+   u16 major;
+   u16 minor;
+   u16 hotfix;
+   u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+   u32 header_type; /* 0x4 for manifest type */
+   u32 header_length; /* in dwords */
+   u32 header_version;
+   u32 flags;
+   u32 vendor;
+   u32 date;
+   u32 size; /* In dwords, size of entire manifest (header + extensions) */
+   u32 header_id;
+   u32 internal_data;
+   struct intel_gsc_meu_version fw_version;
+   u32 security_version;
+   struct intel_gsc_meu_version meu_kit_version;
+   u32 meu_manifest_version;
+   u8 general_data[4];
+   u8 reserved3[56];
+   u32 modulus_size; /* in dwords */
+   u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 9721761373fb..062ff914b274 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
 #include 
 
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
 #include "intel_guc_reg.h"
 #include "intel_huc.h"
+#include "intel_huc_print.h"
 #include "i915_drv.h"
 
 #include 
 #include 
 
-#define huc_printk(_huc, _level, _fmt, ...) \
-   gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...)   huc_printk((_huc), err, _fmt, 
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...)  huc_printk((_huc), warn, _fmt, 
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt, 
##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...)  huc_printk((_huc), info, _fmt, 
##__VA_ARGS__)
-#define huc_dbg(_huc, _fmt, ...)   huc_printk((_huc), dbg, _fmt, 
##__VA_ARGS__)
-#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt, 
##__VA_ARGS__)
-
 /**
  * DOC: HuC
  *
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 534b0aa43316..f1c973e1c676 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -5,11 +5,127 @@
 
 #include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
+#include "intel_gsc_meu_headers.h"
 #include "intel_huc.h"
 #include "intel_huc_fw.h"
+#include "int