Re: [PATCH] drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c

[Vivi, Rodrigo]

On Thu, 2024-03-14 at 14:48 +0200, Joonas Lahtinen wrote:
> Quoting Rodrigo Vivi (2024-03-08 16:58:04)
> > On Fri, Mar 08, 2024 at 04:46:43PM +0200, Joonas Lahtinen wrote:
> > > Add standalone includes for BUG_ON and BUILD_BUG_ON to avoid
> > > build failure
> > > after linux-next include refactoring.
> > 
> > any lore link so we can use with a 'Closes:' tag?
> > and perhaps a reported-by?
> 
> The build failure seems to have happened in intel-gfx-ci.01.org but
> the
> failing build results are not uploaded so it's only visible in the
> background.
> 
> From the CI page[1] we can see next-20240304 is the last successful
> build[2].
> Failure seems to have started next-20240305 after which the results
> are
> not uploaded due to the failure.
> 
> For future, I asked if we could improve the CI dashboard by alos
> showing the
> failing builds in the CI view. 
> 
> However, for now we don't have a reference, I guess.
> 
> [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
> [2] https://intel-gfx-ci.01.org/tree/linux-next/next-
> 20240304/filelist.html
> 
> > 
> > > 
> > > Signed-off-by: Joonas Lahtinen 
> > > Cc: Chris Wilson 
> > > Cc: Jani Nikula 
> > > Cc: Rodrigo Vivi 
> > > Cc: Tvrtko Ursulin 
> > > ---
> > >  drivers/gpu/drm/i915/i915_memcpy.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
> > > b/drivers/gpu/drm/i915/i915_memcpy.c
> > > index ba82277254b7..cc41974cee74 100644
> > > --- a/drivers/gpu/drm/i915/i915_memcpy.c
> > > +++ b/drivers/gpu/drm/i915/i915_memcpy.c
> > > @@ -25,6 +25,8 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > 
> > git grep BUILD_BUG_ON drivers/gpu/drm/i915/
> > output
> > 
> > vs
> > 
> > git grep build_bug.h drivers/gpu/drm/i915/
> > output
> > 
> > tells me that we likely need this in many more files...
> > 
> > but not opposed to move with this faster and come back later with
> > other fixes if this unblocks people:
> 
> Yeah, I made the same observation.
> 
> Are you fine to merge this with the R-b even without the reference?

sorry for having missed this.

yes, the rv-b can be used even without the reference, let's just get
this in and fix the build issue.

> 
> Regards, Joonas
> 
> > 
> > Reviewed-by: Rodrigo Vivi 
> > 
> > >  #include 
> > >  
> > >  #include "i915_memcpy.h"
> > > -- 
> > > 2.43.2
> > > 

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

[Vivi, Rodrigo]

On Fri, 2023-11-03 at 09:47 +, Tvrtko Ursulin wrote:
> 
> On 03/11/2023 08:58, Coelho, Luciano wrote:
> > On Fri, 2023-11-03 at 03:31 +, Vivi, Rodrigo wrote:
> > > > > 
> > > > > Any other suggestions?
> > > > 
> > > > I think it will boil down to the reason uncore lock is held
> > > > over
> > > > the
> > > > respective sections ie. the comment in
> > > > i915_get_crtc_scanoutpos.
> > > > 
> > > > If it is timing sensitive to the extent irq off was needed it
> > > > may
> > > > apply
> > > > to Xe as well. Likewise the need to use mmio helpers which rely
> > > > on
> > > > the
> > > > uncore lock already held. Question of whether there is
> > > > conceptual
> > > > commonality, will probably drive the best name, or the best
> > > > approach
> > > > in
> > > > general.
> > > 
> > > yeap, this is how I'm seeing this. If i915-display needs this
> > > global
> > > lock around mmio operations, then we wound need to add it to the
> > > xe_mmio as well and then solve the name, etc.
> > > 
> > > However, I don't believe that other users of the mmio would need
> > > this lock. So I believe the right thing to do is to create a
> > > i915-
> > > display only spin_lock, around the intel_de_mmio calls and here.
> > > 
> > > With this we entirely kill the dependency on someone-else's lock
> > > and have something that is entirely inside display code so it
> > > doesn't need to be ported to one or another driver core
> > > components.
> > 
> > Right, I agree too.
> > 
> > My patch was just trying to address the quick hack made for Xe, not
> > the
> > actual implementation in Xe's side.  But it makes sense to
> > implement
> > this new lock internally in the display so there are no
> > dependencies or
> > wrappers needed.
> > 
> > I'll respin.
> 
> You could also make sure it needs to be a lock and not just say a 
> preempt off or irq section?

indeed a good question. maybe we don't need the lock at all there...

> 
> Regards,
> 
> Tvrtko

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

[Vivi, Rodrigo]

> > 
> > Any other suggestions?
> 
> I think it will boil down to the reason uncore lock is held over the 
> respective sections ie. the comment in i915_get_crtc_scanoutpos.
> 
> If it is timing sensitive to the extent irq off was needed it may
> apply 
> to Xe as well. Likewise the need to use mmio helpers which rely on
> the 
> uncore lock already held. Question of whether there is conceptual 
> commonality, will probably drive the best name, or the best approach
> in 
> general.

yeap, this is how I'm seeing this. If i915-display needs this global
lock around mmio operations, then we wound need to add it to the
xe_mmio as well and then solve the name, etc.

However, I don't believe that other users of the mmio would need
this lock. So I believe the right thing to do is to create a i915-
display only spin_lock, around the intel_de_mmio calls and here.

With this we entirely kill the dependency on someone-else's lock
and have something that is entirely inside display code so it
doesn't need to be ported to one or another driver core components.

> 
> Regards,
> 
> Tvrtko

Re: [Intel-gfx] [PATCH] gpu: drm: i915: fix documentation style

[Vivi, Rodrigo]

On Mon, 2023-08-21 at 14:00 -0700, Ceraolo Spurio, Daniele wrote:
> 
> 
> On 8/21/2023 9:22 AM, Jani Nikula wrote:
> > On Mon, 21 Aug 2023, "Ricardo B. Marliere" 
> > wrote:
> > > This patch fixes the following sphinx warnings in the htmldocs
> > > make target:
> > > 
> > > Documentation/gpu/i915:546:
> > > ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:29: ERROR: Unexpected
> > > indentation.
> > > Documentation/gpu/i915:546:
> > > ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:30: WARNING: Block quote
> > > ends without a blank line; unexpected unindent.
> > > Documentation/gpu/i915:546:
> > > ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:35: WARNING: Bullet list
> > > ends without a blank line; unexpected unindent.
> > > 
> > > Signed-off-by: Ricardo B. Marliere 
> > Already fixed by commit 175b036472f6 ("drm/i915: fix Sphinx
> > indentation
> > warning") in drm-next.
> 
> Should we send this commit through the -fixes path, so it gets
> included 
> in 6.5?

175b036472f6 cherry-picked to drm-intel-fixes. Should be in this
week's pull request towards 6.5

> 
> Daniele
> 
> > BR,
> > Jani.
> > 
> > > ---
> > >   drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > > index ddd146265beb..fa70defcb5b2 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > > @@ -26,6 +26,7 @@
> > >    * The kernel driver is only responsible for loading the HuC
> > > firmware and
> > >    * triggering its security authentication. This is done
> > > differently depending
> > >    * on the platform:
> > > + *
> > >    * - older platforms (from Gen9 to most Gen12s): the load is
> > > performed via DMA
> > >    *   and the authentication via GuC
> > >    * - DG2: load and authentication are both performed via GSC.
> > > @@ -33,6 +34,7 @@
> > >    *   not-DG2 older platforms), while the authentication is done
> > > in 2-steps,
> > >    *   a first auth for clear-media workloads via GuC and a
> > > second one for all
> > >    *   workloads via GSC.
> > > + *
> > >    * On platforms where the GuC does the authentication, to
> > > correctly do so the
> > >    * HuC binary must be loaded before the GuC one.
> > >    * Loading the HuC is optional; however, not using the HuC
> > > might negatively
> 

Re: [Intel-gfx] [PATCH] drm/i915/mtl: do not enable render power-gating on MTL

[Vivi, Rodrigo]

On Wed, 2023-05-17 at 17:12 +0200, Das, Nirmoy wrote:
> 
> On 5/17/2023 3:59 PM, Andrzej Hajda wrote:
> > Multiple CI tests fails with forcewake ack timeouts
> > if render power gating is enabled.
> > BSpec 52698 clearly states it should be 0 for MTL.
> > 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983
> > Signed-off-by: Andrzej Hajda 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> > b/drivers/gpu/drm/i915/gt/intel_rc6.c
> > index 908a3d0f2343f4..ebb2373dd73640 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> > @@ -117,8 +117,9 @@ static void gen11_rc6_enable(struct intel_rc6
> > *rc6)
> > GEN6_RC_CTL_RC6_ENABLE |
> > GEN6_RC_CTL_EI_MODE(1);
> >   
> > -   /* Wa_16011777198 - Render powergating must remain disabled
> > */
> > -   if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0)
> > ||
> > +   /* Wa_16011777198 and BSpec 52698 - Render powergating must
> > be off */
> 
> Nice catch!

Indeed! What a mess in the workaround database.
It is telling us that no_impact on MTL SKUs while we clearly needs
that. I tried to reopen that and get that fixed in the hsds.


>  instead of bspec you could add Wa_1401266.

not actually.
16011777198 is the right lineage number for 1401266.
Besides, 1401266 is for DG2 anyway.

Let's keep the way Adrzej put with the BSPec reference besides the
lineage.

> 
> 
> > +   if (IS_METEORLAKE(gt->i915) ||
> > +   IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0)
> > ||
> >     IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))
> > pg_enable =
> > GEN9_MEDIA_PG_ENABLE |
> > 
> > ---
> > base-commit: 01d3dd92d1b71421f6ee85e1bea829e0a917d979
> > change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e
> 
> ^ unwanted artifacts ?   Otherwise this looks good to me.
> 
> Reviewed-by: Nirmoy Das 

with the artifacts removed:
Reviewed-by: Rodrigo Vivi 


> 
> > 
> > Best regards,

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gt: Move LSC_CHICKEN_BIT* workarounds to correct function

[Vivi, Rodrigo]

On Thu, 2023-01-19 at 19:24 -0300, Gustavo Sousa wrote:
> On Thu, Jan 19, 2023 at 04:57:09PM -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 18, 2023 at 12:52:49PM -0300, Gustavo Sousa wrote:
> > > That register doesn't belong to a specific engine, so the proper
> > > placement for workarounds programming it should be
> > > general_render_compute_wa_init().
> > > 
> > > Signed-off-by: Gustavo Sousa 
> > 
> > Reviewed-by: Rodrigo Vivi 
> 
> Thanks for the review, Rodrigo!
> 
> Last time I talked with the team, Lucas suspected there could be a
> reason why
> the workarounds were in their current places. I'll include him and
> Matt Roper
> here, since they had assigned themselves to check this.
> 
> I think we should wait for their input before applying this patch.

ops, I have just pushed them...

> 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 65 ---
> > > --
> > >  1 file changed, 36 insertions(+), 29 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index ef6065ce8267..918a271447e2 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -2341,10 +2341,6 @@ rcs_engine_wa_init(struct intel_engine_cs
> > > *engine, struct i915_wa_list *wal)
> > > /* Wa_1509727124 */
> > > wa_mcr_masked_en(wal, GEN10_SAMPLER_MODE,
> > > 
> > > SC_DISABLE_POWER_OPTIMIZATION_EBB);
> > > -
> > > -   /* Wa_22013037850 */
> > > -   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
> > > -
> > >    DISABLE_128B_EVICTION_COMMAND_UDW);
> > > }
> > >  
> > > if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0,
> > > STEP_FOREVER) ||
> > > @@ -2373,21 +2369,6 @@ rcs_engine_wa_init(struct intel_engine_cs
> > > *engine, struct i915_wa_list *wal)
> > > 
> > > GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIX);
> > > }
> > >  
> > > -   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) ||
> > > -   IS_DG2_G11(i915)) {
> > > -   /*
> > > -    * Wa_22012826095:dg2
> > > -    * Wa_22013059131:dg2
> > > -    */
> > > -   wa_mcr_write_clr_set(wal, LSC_CHICKEN_BIT_0_UDW,
> > > -    MAXREQS_PER_BANK,
> > > -   
> > > REG_FIELD_PREP(MAXREQS_PER_BANK, 2));
> > > -
> > > -   /* Wa_22013059131:dg2 */
> > > -   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
> > > -
> > >    FORCE_1_SUB_MESSAGE_PER_FRAGMENT);
> > > -   }
> > > -
> > > /* Wa_1308578152:dg2_g10 when first gslice is fused off
> > > */
> > > if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) &&
> > >     needs_wa_1308578152(engine)) {
> > > @@ -2412,16 +2393,6 @@ rcs_engine_wa_init(struct intel_engine_cs
> > > *engine, struct i915_wa_list *wal)
> > >  */
> > > wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN,
> > >  MDQ_ARBITRATION_MODE |
> > > UGM_BACKUP_MODE);
> > > -
> > > -   /*
> > > -    * Wa_14010918519:dg2_g10
> > > -    *
> > > -    * LSC_CHICKEN_BIT_0 always reads back as 0 is
> > > this stepping,
> > > -    * so ignoring verification.
> > > -    */
> > > -   wa_mcr_add(wal, LSC_CHICKEN_BIT_0_UDW, 0,
> > > -  FORCE_SLM_FENCE_SCOPE_TO_TILE |
> > > FORCE_UGM_FENCE_SCOPE_TO_TILE,
> > > -  0, false);
> > > }
> > >  
> > > if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)) {
> > > @@ -3006,6 +2977,15 @@ general_render_compute_wa_init(struct
> > > intel_engine_cs *engine, struct i915_wa_li
> > >  
> > > add_render_compute_tuning_settings(i915, wal);
> > >  
> > > +   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > > +   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0) ||
> > > +   IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0,
> > > STEP_FOREVER) ||
> > > +   IS_DG2_G11(i915) || IS_DG2_G12(i915)) {
> > > +   /* Wa_22013037850 */
> > > +   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
> > > +   DISABLE_128B_EVICTION_COMMAND_UDW
> > > );
> > > +   }
> > > +
> > > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > >     IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0) ||
> > >     IS_PONTEVECCHIO(i915) ||
> > > @@ -3027,6 +3007,33 @@ general_render_compute_wa_init(struct
> > > intel_engine_cs *engine, struct i915_wa_li
> > > wa_masked_en(wal, VFG_PREEMPTION_CHICKEN,
> > > POLYGON_TRIFAN_LINELOOP_DISABLE);
> > > }
> > >  
> > > +   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) 

Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Add initial gt workarounds

[Vivi, Rodrigo]

On Fri, 2023-01-06 at 19:33 +, Sripada, Radhakrishna wrote:
Pushed with the nit's fixed. Thanks for the patch and review.

Next time please modify, resend and wait the BAT. We had
seen cases in the past where the modification ended in a bad code
that broken compilation and everyone else.

Small modifications while merging are only acceptable in the commit
messages.

Thanks,
Rodrigo.


- Radhakrishna(RK) Sripada

-Original Message-
From: Intel-gfx 
mailto:intel-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Rodrigo
Vivi
Sent: Friday, January 6, 2023 5:04 AM
To: Atwood, Matthew S 
mailto:matthew.s.atw...@intel.com>>
Cc: intel-gfx@lists.freedesktop.org; De 
Marchi, Lucas
mailto:lucas.demar...@intel.com>>
Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Add initial gt workarounds

On Thu, Jan 05, 2023 at 03:44:08PM -0800, Matt Atwood wrote:
From: Matt Roper mailto:matthew.d.ro...@intel.com>>

This patch introduces initial gt workarounds for the MTL platform.

v2: drop redundant/stale comments specifying wa platforms affected
(Lucas).
v3: drop additional redundant stale comments (MattR)

Bspec: 66622

Signed-off-by: Matt Roper 
mailto:matthew.d.ro...@intel.com>>
Signed-off-by: Matt Atwood 
mailto:matthew.s.atw...@intel.com>>
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   6 +-
 .../drm/i915/gt/intel_execlists_submission.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  11 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 115 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   9 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_device_info.c  |   6 +
 9 files changed, 128 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..e3f30bdf7e61 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1494,10 +1494,12 @@ static int __intel_engine_stop_cs(struct
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode,
_MASKED_BIT_ENABLE(STOP_RING));

/*
-* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : Prior to doing a reset, ensure CS is

 ^ you could've had also removed the extra space

 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))

this is getting hard to read, but yeap, this is the only way...

intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine-
mmio_base),

_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 2daffa7c7dfd..18ffe55282e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2989,10 +2989,12 @@ static void execlists_reset_prepare(struct
intel_engine_cs *engine)
intel_engine_stop_cs(engine);

/*
-* Wa_22011802037:gen11/gen12: In addition to stopping the cs, we
need
+* Wa_22011802037: In addition to stopping the cs, we need
 * to wait for any pending mi force wakeups
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_engine_wait_for_pending_mi_fw(engine);

engine->execlists.reset_ccid = active_ccid(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 41a237509dcf..4127830c33ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
gt->steering_table[OADDRM] =
xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
-intel_uncore_read(gt->uncore,
XEHP_FUSE4));
+   /* Wa_14016747170 */
+   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore,
+
MTL_GT_ACTIVITY_FACTOR));
+   else
+  

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmc: Use unversioned firmware paths

[Vivi, Rodrigo]

On Wed, 2022-12-28 at 19:00 -0300, Gustavo Sousa wrote:
> On Fri, Dec 23, 2022 at 10:36:05AM -0500, Rodrigo Vivi wrote:
> > On Fri, Dec 23, 2022 at 08:51:59AM -0300, Gustavo Sousa wrote:
> > > On Thu, Dec 22, 2022 at 04:52:21PM -0800, Lucas De Marchi wrote:
> > > > On Thu, Dec 22, 2022 at 07:12:08PM -0300, Gustavo Sousa wrote:
> > > > > On Wed, Dec 21, 2022 at 04:23:45PM -0800, Lucas De Marchi
> > > > > wrote:
> > > > > > On Wed, Dec 21, 2022 at 12:26:26PM +0200, Jani Nikula
> > > > > > wrote:
> > > > > > > On Tue, 20 Dec 2022, Gustavo Sousa
> > > > > > >  wrote:
> > > > > > > > As we do not require specific versions anymore, change
> > > > > > > > the convention
> > > > > > > > for blob filenames to stop using version numbers. This
> > > > > > > > simplifies code
> > > > > > > > maintenance, since we do not need to keep updating blob
> > > > > > > > paths for new
> > > > > > > > DMC releases, and also makes DMC loading compatible
> > > > > > > > with systems that do
> > > > > > > > not have the latest firmware release.
> > > > > > > > 
> > > > > > > > References:
> > > > > > > > https://lore.kernel.org/r/y3081s7c5ksut...@intel.com
> > > > > > > > Signed-off-by: Gustavo Sousa 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/display/intel_dmc.c | 98
> > > > > > > > 
> > > > > > > >  1 file changed, 82 insertions(+), 16 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > > > > > index 4124b3d37110..b11f0f451dd7 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > > > > > @@ -42,51 +42,70 @@
> > > > > > > >  #define DMC_VERSION_MAJOR(version) ((version) >>
> > > > > > > > 16)
> > > > > > > >  #define DMC_VERSION_MINOR(version) ((version) &
> > > > > > > > 0x)
> > > > > > > > 
> > > > > > > > -#define DMC_PATH(platform, major, minor) \
> > > > > > > > -   "i915/"  \
> > > > > > > > -   __stringify(platform) "_dmc_ver" \
> > > > > > > > -   __stringify(major) "_"   \
> > > > > > > > +#define DMC_PATH(platform) \
> > > > > > > > +   "i915/" __stringify(platform) "_dmc.bin"
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * New DMC additions should not use this. This is used
> > > > > > > > solely to remain
> > > > > > > > + * compatible with systems that have not yet updated
> > > > > > > > DMC blobs to use
> > > > > > > > + * unversioned file names.
> > > > > > > > + */
> > > > > > > > +#define DMC_LEGACY_PATH(platform, major, minor) \
> > > > > > > > +   "i915/" \
> > > > > > > > +   __stringify(platform) "_dmc_ver"\
> > > > > > > > +   __stringify(major) "_"  \
> > > > > > > > __stringify(minor) ".bin"
> > > > > > > > 
> > > > > > > >  #define DISPLAY_VER13_DMC_MAX_FW_SIZE  0x2
> > > > > > > > 
> > > > > > > >  #define
> > > > > > > > DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
> > > > > > > > 
> > > > > > > > -#define DG2_DMC_PATH   DMC_PATH(dg2,
> > > > > > > > 2, 08)
> > > > > > > > +#define DG2_DMC_PATH   DMC_PATH(dg2)
> > > > > > > > +#define
> > > > > > > > DG2_DMC_LEGACY_PATHDMC_LEGACY_PATH(dg2, 2,
> > > > > > > > 08)
> > > > > > > >  MODULE_FIRMWARE(DG2_DMC_PATH);
> > > > > > 
> > > > > > We have an issue here.  Previously `modinfo --
> > > > > > field=firmware i915`
> > > > > > would report i915/dg2_dmc_ver2_08.bin. Now it's going to
> > > > > > report
> > > > > > i915/dg2_dmc.bin
> > > > > > 
> > > > > > that modinfo call is what distros use to bundle the
> > > > > > firmware blobs in
> > > > > > the initrd. It may also be used for creating package
> > > > > > dependendies.
> > > > > > 
> > > > > > If we do this, unless they have updated their linux-
> > > > > > firmware
> > > > > > packages, the initrd will be left without the firmware.
> > > > > > Just checked
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linu
> > > > > > x-firmware.git main
> > > > > > and we still don't have the unversioned firmware there.
> > > > > 
> > > > > Interesting. Thanks for the explanation!
> > > > > 
> > > > > I think one way of approaching the issue would be to
> > > > > synchronize the process:
> > > > > 
> > > > > 1. Work toward getting approval for the patch (i.e. r-b);
> > > > > 2. With the approval, send a PR to linux-firmware with the
> > > > > necessary changes;
> > > > > 3. After the linux-firmware PR is merged, the patch could be
> > > > > integraged.
> > > > > 
> > > > > I think that would still apply if going with your proposal on
> > > > > your next comment.
> > > > > 
> > > > > > 
> > > > > > > > 
> > > > > > > > -#define ADLP_DMC_PATH  DMC_PATH(adlp,
> > > > > > > > 2, 16)
> > > > > > > > +#define ADLP_DMC_PATH  

Re: [Intel-gfx] [PATCH v2] drm/i915/hwconfig: Remove comment block

[Vivi, Rodrigo]

On Tue, 2022-12-13 at 13:50 +0800, Jiapeng Chong wrote:
> No functional modification involved.
> 
> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning:
> expecting prototype for intel_guc_hwconfig_init(). Prototype was for
> guc_hwconfig_init() instead.

Thank you for the patch and for addressing the comment.
But now the commit message is not explaining what's really going on.

Could you please improve the message saying that the function has
changed to static and we don't need doc comment in the static
functions, etc?!

Also, while doing this, please find a better commit message.
This is way to generic. Something like
drm/i915: Remove unnecessary doc from static hwconfig_init
sounds better and easier to understand from a log --oneline.

Oh, and it also looks this patch deserves a "Fixes:" tag,
pointing to the patch that created the mess. Either the original
patch if it already introduced like this, or to the patch that
transformed this function in static. git blame to find the culprit out.

With the commit msg fixed as above I will add my rv-b while merging it.

> 
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3414
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
> Changes in v2:
>   -Remove the comment block.
> 
>  drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> index 4781fccc2687..5559d39881ee 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> @@ -102,12 +102,6 @@ static bool has_table(struct drm_i915_private
> *i915)
> return false;
>  }
>  
> -/**
> - * intel_guc_hwconfig_init - Initialize the HWConfig
> - *
> - * Retrieve the HWConfig table from the GuC and save it locally.
> - * It can then be queried on demand by other users later on.
> - */
>  static int guc_hwconfig_init(struct intel_gt *gt)
>  {
> struct intel_hwconfig *hwconfig = >info.hwconfig;

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reset twice

[Vivi, Rodrigo]

On Tue, 2022-12-13 at 00:08 +0100, Andi Shyti wrote:
> Hi Rodrigo,
> 
> On Mon, Dec 12, 2022 at 11:55:10AM -0500, Rodrigo Vivi wrote:
> > On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> > > From: Chris Wilson 
> > > 
> > > After applying an engine reset, on some platforms like
> > > Jasperlake, we
> > > occasionally detect that the engine state is not cleared until
> > > shortly
> > > after the resume. As we try to resume the engine with volatile
> > > internal
> > > state, the first request fails with a spurious CS event (it looks
> > > like
> > > it reports a lite-restore to the hung context, instead of the
> > > expected
> > > idle->active context switch).
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > There's a typo in the signature email I'm afraid...
> 
> oh yes, I forgot the 'C' :)

you forgot?
who signed it off?

> 
> > Other than that, have we checked the possibility of using the
> > driver-initiated-flr bit
> > instead of this second loop? That should be the right way to
> > guarantee everything is
> > cleared on gen11+...
> 
> maybe I am misinterpreting it, but is FLR the same as resetting
> hardware domains individually?

No, it is bigger than that... almost the PCI FLR with some exceptions:

https://lists.freedesktop.org/archives/intel-gfx/2022-December/313956.html

> How am I supposed to use driver_initiated_flr() in this context?

Some drivers are not even using this gt reset anymore and going
directly with the driver-initiated FLR in case that guc reset failed.

I believe we can still keep the gt reset in our case as we currently
have, but instead of keep retrying it until it succeeds we probably
should go to the next level and do the driver initiated FLR when the GT
reset failed.

> 
> Thanks,
> Andi
> 
> > > Cc: sta...@vger.kernel.org
> > > Cc: Mika Kuoppala 
> > > Signed-off-by: Andi Shyti 
> > > ---
> > >  drivers/gpu/drm/i915/gt/intel_reset.c | 34
> > > ++-
> > >  1 file changed, 28 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > index ffde89c5835a4..88dfc0c5316ff 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > @@ -268,6 +268,7 @@ static int ilk_do_reset(struct intel_gt *gt,
> > > intel_engine_mask_t engine_mask,
> > >  static int gen6_hw_domain_reset(struct intel_gt *gt, u32
> > > hw_domain_mask)
> > >  {
> > > struct intel_uncore *uncore = gt->uncore;
> > > +   int loops = 2;
> > > int err;
> > >  
> > > /*
> > > @@ -275,18 +276,39 @@ static int gen6_hw_domain_reset(struct
> > > intel_gt *gt, u32 hw_domain_mask)
> > >  * for fifo space for the write or forcewake the chip for
> > >  * the read
> > >  */
> > > -   intel_uncore_write_fw(uncore, GEN6_GDRST,
> > > hw_domain_mask);
> > > +   do {
> > > +   intel_uncore_write_fw(uncore, GEN6_GDRST,
> > > hw_domain_mask);
> > >  
> > > -   /* Wait for the device to ack the reset requests */
> > > -   err = __intel_wait_for_register_fw(uncore,
> > > -  GEN6_GDRST,
> > > hw_domain_mask, 0,
> > > -  500, 0,
> > > -  NULL);
> > > +   /*
> > > +    * Wait for the device to ack the reset requests.
> > > +    *
> > > +    * On some platforms, e.g. Jasperlake, we see see
> > > that the
> > > +    * engine register state is not cleared until
> > > shortly after
> > > +    * GDRST reports completion, causing a failure as
> > > we try
> > > +    * to immediately resume while the internal state
> > > is still
> > > +    * in flux. If we immediately repeat the reset,
> > > the second
> > > +    * reset appears to serialise with the first, and
> > > since
> > > +    * it is a no-op, the registers should retain
> > > their reset
> > > +    * value. However, there is still a concern that
> > > upon
> > > +    * leaving the second reset, the internal engine
> > > state
> > > +    * is still in flux and not ready for resuming.
> > > +    */
> > > +   err = __intel_wait_for_register_fw(uncore,
> > > GEN6_GDRST,
> > > + 
> > > hw_domain_mask, 0,
> > > +  2000, 0,
> > > +  NULL);
> > > +   } while (err == 0 && --loops);
> > > if (err)
> > > GT_TRACE(gt,
> > >  "Wait for 0x%08x engines reset
> > > failed\n",
> > >  hw_domain_mask);
> > >  
> > > +   /*
> > > +    * As we have observed that the engine state is still
> > > volatile
> > > +    * after GDRST is 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Vivi, Rodrigo]

On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:
> On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
> > Simplify the code.
> 
> Personally, I absolutely hate fetch_and_zero().
> 
> I understand the point, but there are two main traps:
> 
> First, the name implies atomicity, which there is none at all.
> 
> Second, the name implies it's part of a kernel core header, which it
> isn't, and this just amplifies the first point.
> 
> It's surprising and misleading, and those are not things I like about
> interfaces in the kernel.
> 
> I would not like to see this proliferate. If fetch_and_zero() was
> atomic
> *and* part of a core kernel header, it would be a different matter.
> But
> I don't think that's going to happen, exactly because it won't be
> atomic
> and the name implies it is.

+1 here.

Please let's go the other way around and try to kill macros like this.

we either kill or we ensure this gets accepted in the core kernel
libraries.

> 
> 
> BR,
> Jani.
> 
> 
> > 
> > Signed-off-by: Andrzej Hajda 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 907ab7526cb478..2972d7533da44e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -304,10 +304,8 @@ static void i915_digport_work_func(struct
> > work_struct *work)
> > u32 old_bits = 0;
> >  
> > spin_lock_irq(_priv->irq_lock);
> > -   long_port_mask = dev_priv->display.hotplug.long_port_mask;
> > -   dev_priv->display.hotplug.long_port_mask = 0;
> > -   short_port_mask = dev_priv-
> > >display.hotplug.short_port_mask;
> > -   dev_priv->display.hotplug.short_port_mask = 0;
> > +   long_port_mask = fetch_and_zero(_priv-
> > >display.hotplug.long_port_mask);
> > +   short_port_mask = fetch_and_zero(_priv-
> > >display.hotplug.short_port_mask);
> > spin_unlock_irq(_priv->irq_lock);
> >  
> > for_each_intel_encoder(_priv->drm, encoder) {
> > @@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct
> > work_struct *work)
> >  
> > spin_lock_irq(_priv->irq_lock);
> >  
> > -   hpd_event_bits = dev_priv->display.hotplug.event_bits;
> > -   dev_priv->display.hotplug.event_bits = 0;
> > -   hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
> > -   dev_priv->display.hotplug.retry_bits = 0;
> > +   hpd_event_bits = fetch_and_zero(_priv-
> > >display.hotplug.event_bits);
> > +   hpd_retry_bits = fetch_and_zero(_priv-
> > >display.hotplug.retry_bits);
> >  
> > /* Enable polling for connectors which had HPD IRQ storms
> > */
> > intel_hpd_irq_storm_switch_to_polling(dev_priv);
> 

Re: [Intel-gfx] [PATCH v7 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Vivi, Rodrigo]

On Fri, 2022-12-02 at 19:21 +, Teres Alexis, Alan Previn wrote:
> 
> 
> On Fri, 2022-12-02 at 11:22 -0500, Vivi, Rodrigo wrote:
> > On Thu, Dec 01, 2022 at 05:14:07PM -0800, Alan Previn wrote:
> > > Starting with MTL, there will be two GT-tiles, a render and media
> > > tile. PXP as a service for supporting workloads with protected
> > > contexts and protected buffers can be subscribed by process
> > > workloads on any tile. However, depending on the platform,
> > > only one of the tiles is used for control events pertaining to
> > > PXP
> > > 
> Alan: [snip]
> 
> > > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct
> > > drm_device *dev)
> > >  {
> > > struct drm_i915_private *i915 = to_i915(dev);
> > >  
> > > +   intel_pxp_suspend_prepare(i915->pxp);
> > > +
> > > /*
> > >  * NB intel_display_suspend() may issue new requests
> > > after we've
> > >  * ostensibly marked the GPU as ready-to-sleep here. We
> > > need to
> > > @@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct
> > > drm_device *dev, bool hibernation)
> > >  
> > > disable_rpm_wakeref_asserts(rpm);
> > >  
> > > +   intel_pxp_suspend(dev_priv->pxp);
> > 
> > is this really needed here in the suspend_late?
> > why not in suspend()?
> > 
> > In general what is needed in suspend_late is resumed from the
> > resume_early,
> > what doesn't look the case here. So something looks off.
> > 
> 
> Actually this patch is NOT changing the code flow of when these pxp
> pm functions are getting called from an i915-level
> perspective - i am merely moving it from inside gt level to top level
> up:
> 
> Original --> i915_drm_suspend_late calls i915_gem_suspend_late calls
> intel_gt_suspend_late calls intel_pxp_suspend
> Patch --> i915_drm_suspend_late calls intel_pxp_suspend (before
> calling i915_gem_suspend_late)
> 
> Putting that aside, i think the original code was designed to have
> the suspend-prepare do nearly everything except
> disable the KCR registers which is postponed in order to handle a
> failed system-suspend-prepare (after pxp's suspend-
> prepare). A failed system-suspend-prepare (after pxp's suspend-
> prepare) would be recoverable with no-op from pxp's
> perspective as the UMD would be forced to recreate the pxp context
> that recreates arb session again and because the KCR
> registers hadnt been disabled, nothing more is required. I'm not 100%
> sure so I'll ping Daniele jump in to correct me. 
> 
> That said, the better way, for code readibility, would be completely
> skip having an intel_pxp_suspend and just disable
> the KCR in intel_pxp_suspend_prepare and instead add an i915 callback
> for resume_complete (which is the symmetrical
> opposite of suspend_prepare and surprisingly non-existend in i915
> codebase) in order to re-start kcr registers there for
> the case of a failed-system-suspend-prepare or completion of resume.
> I have a separate series that is attempting to fix
> some of this lack of symmetry
> here: https://patchwork.freedesktop.org/patch/513279/?series=111409
> ev=1 but i hadn't
> removed the intel_pxp_suspend because i am not sure if the i915-
> resume-complete callback would still be called if i915
> itself was the reason for the failed suspend-prepare AND the pxp-
> suspend-prepare had occured. So i need to craft out a
> way to test that.
> 
> Do you want to continue pursuing the final fixups for pxp's suspend-
> resume flows in this patch? Again, i am NOT changing
> this flow - just moving it from inside-gt to outside gem-gt where for
> suspend we move it outside-and-before and for
> resume we move it outside-and-after.

Oh! okay, let's move without changing this flow in this patch and work
in a follow up.

> 
> > > 
> > > 
> 
> Alan: [snip]
> 
> > > +
> > > i915_gem_suspend_late(dev_priv);
> > >  
> > > for_each_gt(gt, dev_priv, i)
> > > +int intel_pxp_init(struct drm_i915_private *i915)
> > > +{
> > > +   struct intel_pxp *newpxp;
> > > +
> > > +   newpxp = kzalloc(sizeof(*newpxp), GFP_KERNEL);
> > > +   if (!newpxp)
> > > +   return -ENOMEM;
> > > +
> > > +   i915->pxp = newpxp;
> > 
> > i915->pxp is already an intel_pxp *, why can't we simply
> > do 
> > i915->pxp = kzalloc(sizeof(...
> >   if (!i915->pxp)
> >   return -ENOMEM;
> > ?
> > 
> 

Re: [Intel-gfx] [PATCH v3 0/2] mei: add timeout to send

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 18:43 +0100, Greg Kroah-Hartman wrote:
> On Wed, Nov 30, 2022 at 09:20:28AM -0500, Rodrigo Vivi wrote:
> > On Wed, Nov 16, 2022 at 02:47:33PM +0200, Alexander Usyskin wrote:
> > > When driver wakes up the firmware from the low power state,
> > > it is sending a memory ready message.
> > > The send is done via synchronous/blocking function to ensure
> > > that firmware is in ready state. However, in case of firmware
> > > undergoing reset send might be block forever.
> > > To address this issue a timeout is added to blocking
> > > write command on the internal bus.
> > > 
> > > Introduce the __mei_cl_send_timeout function to use instead of
> > > __mei_cl_send in cases where timeout is required.
> > > The mei_cl_write has only two callers and there is no need to
> > > split
> > > it into two functions.
> > > 
> > > V2: address review comments:
> > >  - split __mei_cl_send and __mei_cl_send_timeout
> > >  - add units to timeout KDoc
> > >  - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
> > > 
> > > V3: - split the state fix into separate patch
> > >     - document define unit
> > >     - expand timeout KDoc
> > 
> > These 2 patches looks good to me now.
> > 
> > Greg, whenever you review it, please let me know if it is
> > okay to me to push these through the drm-fixes, or if you
> > prefer these to the mei branches.
> 
> These have been in my tree for over a week now, sorry.  No one told
> me
> not to take them...
> 
> {sigh}

no worries at all. The important thing is that the users will get the
fix.
We can keep them in our topic/core-for-CI while our branches are out-
of-sync.

Thanks a lot,
Rodrigo.

> 
> greg k-h

Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 09:32 -0800, Matt Roper wrote:
> On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > tile. PXP as a service for supporting workloads with protected
> 
> Drive-by comment:  we've been a bit inconsistent about terminology in
> the past, but my understanding is that we're trying to standardize on
> "GT" for the unit that MTL has two of, and keeping the term "tile"
> for
> the PVC-style unit that is a combination of (GT+lmem).

I agree that this gets really confusing... but it will be hard to
standardize this I'm afraid. Specially when we do the PVC-style-tile a
intel_gt struct and we apparently are doing the same on MTL, no?!

So, unless the topology gets organized in the code with a standard
name, it is hard to demand everyone to use the same one.

Besides that whenever we were discussing the pvc's one we all had
agreed that the term "tile" was bad, hence we focused on keep the
intel_gt ready for that.

Whenever I hear tile I think of the display buffer organization...
and there are other "tiles" examples iirc.

> 
> 
> Matt
> 
> > contexts and protected buffers can be subscribed by process
> > workloads on any tile. However, depending on the platform,
> > only one of the tiles is used for control events pertaining to PXP
> > operation (such as creating the arbitration session and session
> > tear-down).
> > 
> > PXP as a global feature is accessible via batch buffer instructions
> > on any engine/tile and the coherency across tiles is handled
> > implicitly
> > by the HW. In fact, for the foreseeable future, we are expecting
> > this
> > single-control-tile for the PXP subsystem.
> > 
> > In MTL, it's the standalone media tile (not the root tile) because
> > it contains the VDBOX and KCR engine (among the assets PXP relies
> > on
> > for those events).
> > 
> > Looking at the current code design, each tile is represented by the
> > intel_gt structure while the intel_pxp structure currently hangs
> > off the
> > intel_gt structure.
> > 
> > Keeping the intel_pxp structure within the intel_gt structure makes
> > some
> > internal functionalities more straight forward but adds code
> > complexity to
> > code readibility and maintainibility to many external-to-pxp
> > subsystems
> > which may need to pick the correct intel_gt structure. An example
> > of this
> > would be the intel_pxp_is_active or intel_pxp_is_enabled
> > functionality
> > which should be viewed as a global level inquiry, not a per-gt
> > inquiry.
> > 
> > That said, this series promotes the intel_pxp structure into the
> > drm_i915_private structure making it a top-level subsystem and the
> > PXP
> > subsystem will select the control gt internally and keep a pointer
> > to
> > it for internal reference.
> > 
> > Changes from prior revs:
> >    v5: - Switch from series to single patch (Rodrigo).
> >    - change function name from pxp_get_kcr_owner_gt to
> >  pxp_get_ctrl_gt.
> >    - Fix CI BAT failure by removing redundant call to
> > intel_pxp_fini
> >  from driver-remove.
> >    - NOTE: remaining open still persists on using ptr-to-ptr
> >  and back-ptr.
> >    v4: - Instead of maintaining intel_pxp as an intel_gt structure
> > member
> >  and creating a number of convoluted helpers that takes in
> > i915 as
> >  input and redirects to the correct intel_gt or takes any
> > intel_gt
> >  and internally replaces with the correct intel_gt, promote
> > it to
> >  be a top-level i915 structure.
> >    v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
> >  supported/ active_on_gt" (Daniele)
> >    - Upgrade _gt_supports_pxp to replace what was
> > intel_gtpxp_is
> >  supported as the new intel_pxp_is_supported_on_gt to check
> > for
> >  PXP feature support vs the tee support for huc
> > authentication.
> >  Fix pxp-debugfs-registration to use only the former to
> > decide
> >  support. (Daniele)
> >    - Couple minor optimizations.
> >    v2: - Avoid introduction of new device info or gt variables and
> > use
> >  existing checks / macros to differentiate the correct GT-
> > >PXP
> >  control ownership (Daniele Ceraolo Spurio)
> >    - Don't reuse the updated global-checkers for per-GT callers
> > (such
> >  as other files within PXP) to avoid unnecessary GT-
> > reparsing,
> >  expose a replacement helper like the prior ones.
> > (Daniele).
> >    v1: - Add one more patch to the series for the intel_pxp
> > suspend/resume
> >  for similar refactoring
> > 
> > Signed-off-by: Alan Previn 
> > ---
> >  .../drm/i915/display/skl_universal_plane.c    |  2 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_create.c    |  2 +-
> >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |  2 +-
> >  drivers/gpu/drm/i915/gt/intel_gt.c 

Re: [Intel-gfx] [PATCH v3] drm/i915/dmc: Update DG2 DMC version to v2.08

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 10:42 -0300, Gustavo Sousa wrote:
> On Thu, Nov 24, 2022 at 01:27:40PM -0300, Gustavo Sousa wrote:
> > Just a quick note: firmware PR hasn't been applied yet. Waiting...
> 
> Firmware PR merged into linux-firmware!

Thanks for the patch and the heads up.

Patch is now pushed to drm-intel-next and already cherry-picked to
drm-intel-next-fixes.

> 
> --
> Gustavo Sousa

Re: [Intel-gfx] [PATCH] drm/i915: Remove CONFIG_PM dependency from RC6.

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 11:47 +, Tvrtko Ursulin wrote:
> 
> On 30/11/2022 02:29, Rodrigo Vivi wrote:
> > RC6 is a sleep state that doesn't depend on the cpu sleep,
> > or any of the APM or ACPI or anything related to the
> > CONFIG_PM.
> > 
> > A long time ago we have removed the module parameter
> > that allows the RC6 disablement. We want that feature enabled
> > everywhere. However, for some reason this CONFIG_PM was long
> > forgotten behind.
> > 
> > If we end up needing knobs to disable RC6 we should create
> > individual ones, rather than relying on this master one.
> 
> Digging in history shows 5ab3633d6907 ("drm/i915: make rc6 in sysfs 
> functions conditional") and then it appears the issue could still be 
> present, since we still use power_group_name which is NULL when
> !CONFIG_PM.

oh, indeed!
So, we should probably go with Paul's proposal:
https://lists.freedesktop.org/archives/intel-gfx/2022-November/311569.html
> 
> $ ls -l /sys/class/drm/card0/power/
> total 0
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 async
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 autosuspend_delay_ms
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 control
> -r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_enable
> -r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_residency_ms
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_kids
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_time
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_enabled
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_status
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_suspended_time
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_usage
> 
> Other than rc6 entries I guess come from somewhere else but I haven't
> looked from where exactly.


Ouch! Everything else here comes from the pci's pm_runtime.
Probably our bad decision was to add rc6 to it.
But we do need to stick to that.


> 
> Regards,
> 
> Tvrtko
> 
> > Cc: Paul Cercueil 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 --
> >   1 file changed, 6 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 cf71305ad586..77327ede18ad 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > @@ -164,7 +164,6 @@ sysfs_gt_attribute_r_func(struct kobject *kobj,
> > struct attribute *attr,
> > 
> > NULL); \
> > INTEL_GT_ATTR_RO(_name)
> >   
> > -#ifdef CONFIG_PM
> >   static u32 get_residency(struct intel_gt *gt, enum
> > intel_rc6_res_type id)
> >   {
> > intel_wakeref_t wakeref;
> > @@ -329,11 +328,6 @@ static void intel_sysfs_rc6_init(struct
> > intel_gt *gt, struct kobject *kobj)
> >  gt->info.id, ERR_PTR(ret));
> > }
> >   }
> > -#else
> > -static void intel_sysfs_rc6_init(struct intel_gt *gt, struct
> > kobject *kobj)
> > -{
> > -}
> > -#endif /* CONFIG_PM */
> >   
> >   static u32 __act_freq_mhz_show(struct intel_gt *gt)
> >   {

Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Sat, 2022-11-19 at 09:02 +0530, Nilawar, Badal wrote:
> 
> 
> On 19-11-2022 00:07, Vivi, Rodrigo wrote:
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >   - Fix review comments (Vinay)
> > >   - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >   - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> As he is original author I will prefer not to change it. You can
> remove 
> his rv-b while merging.

Thanks and pushed.

> 
> Regards,
> Badal
> > 
> > > Reviewed-by: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18
> > > ++
> > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  4 
> > >   2 files changed, 22 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index b0a4a2dbe3ee..e971b153fda9 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -15,6 +15,22 @@
> > >   #include "intel_rc6.h"
> > >   #include "intel_ring.h"
> > >   #include "shmem_utils.h"
> > > +#include "intel_gt_regs.h"
> > > +
> > > +static void intel_gsc_idle_msg_enable(struct intel_engine_cs
> > > *engine)
> > > +{
> > > +   struct drm_i915_private *i915 = engine->i915;
> > > +
> > > +   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  RC_PSMI_CTRL_GSCCS,
> > > +
> > > _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
> > > +   /* hysteresis 0xA=5us as recommended in spec*/
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  PWRCTX_MAXCNT_GSCCS,
> > > +  0xA);
> > > +   }
> > > +}
> > >   
> > >   static void dbg_poison_ce(struct intel_context *ce)
> > >   {
> > > @@ -275,6 +291,8 @@ void intel_engine_init__pm(struct
> > > intel_engine_cs
> > > *engine)
> > >   
> > >  intel_wakeref_init(>wakeref, rpm, _ops);
> > >  intel_engine_init_heartbeat(engine);
> > > +
> > > +   intel_gsc_idle_msg_enable(engine);
> > >   }
> > >   
> > >   /**
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index c3cd92691795..80a979e6f6be 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -917,6 +917,10 @@
> > >   #define  MSG_IDLE_FW_MASK  REG_GENMASK(13, 9)
> > >   #define  MSG_IDLE_FW_SHIFT 9
> > >   
> > > +#defineRC_PSMI_CTRL_GSCCS  _MMIO(0x11a050)
> > > +#define  IDLE_MSG_DISABLE  REG_BIT(0)
> > > +#definePWRCTX_MAXCNT_GSCCS _MMIO(0x11a054)
> > > +
> > >   #define FORCEWAKE_MEDIA_GEN9   _MMIO(0xa270)
> > >   #define FORCEWAKE_RENDER_GEN9  _MMIO(0xa278)
> > >   
> > 

Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Fri, 2022-11-18 at 13:37 -0800, Dixit, Ashutosh wrote:
> On Fri, 18 Nov 2022 10:37:37 -0800, Vivi, Rodrigo wrote:
> > 
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >  - Fix review comments (Vinay)
> > >  - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >  - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> 
> Not sure if that is the case here,

yeap, this is too small patch for that to happen.

>  but when multiple people contribute to a
> patch, the original author can review changes by others and add his
> Reviewed-by, no? Or are we saying it is redundant for the author to
> add his
> R-b?
> 
> Similarly, are S-o-b and R-b by the same person ok? I add changes to
> someone's patch so add my S-o-b but also review other's changes so
> add my
> R-b? Sometimes finding a 3rd person to add a R-b is hard. But two
> poeple
> can contribute to a patch and review each other's changes so add both
> their
> S-o-b's and R-b's or no?

Definitely a case by case thing. If that happens it is good to have it
clearly written in the commit message to know who did what, who
reviewed what.

Although I'd say that I'd still prefer the co-authored-by and having a
third one doing the full review.

> 
> :)
> 
> Ashutosh
> 

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT

[Vivi, Rodrigo]

On Mon, 2022-11-21 at 11:39 +, Tvrtko Ursulin wrote:
> 
> On 17/11/2022 22:34, Teres Alexis, Alan Previn wrote:
> > On Thu, 2022-11-17 at 11:02 -0500, Vivi, Rodrigo wrote:
> > > On Wed, Nov 16, 2022 at 04:30:13PM -0800, Alan Previn wrote:
> > > > In preparation for future MTL-PXP feature support, PXP control
> > > > context should only valid on the correct gt tile. Depending on
> > > > the
> > > > device-info this depends on which tile owns the VEBOX and KCR.
> > > > PXP is still a global feature though (despite its control-
> > > > context
> > > > located in the owning GT structure). Additionally, we find
> > > > that the HAS_PXP macro is only used within the pxp module,
> > > > 
> > > > That said, lets drop that HAS_PXP macro altogether and replace
> > > > it
> > > > with a more fitting named intel_gtpxp_is_supported and helpers
> > > > so that PXP init/fini can use to verify if the referenced gt
> > > > supports
> > > > PXP or teelink.
> > > 
> > > Yep, I understand you as I'm not fan of these macros, specially
> > > single usage. But we need to consider that we have multiple
> > > dependencies
> > > there and other cases like this in the driver... Well, but I'm
> > > not
> > > opposing, but probably better to first get rid of the macro,
> > > then change the behavior of the function on the next patch.
> > > 
> > > > 
> > > > Add TODO for Meteorlake that will come in future series.
> > > 
> > > This refactor patch should be standalone, without poputing it
> > > with
> > > the changes that didn't came yet to this point.
> > > 
> > Sure i can follow this rule, but it would then raise the question
> > of "nothign is really changing anywhere for MTL, why
> > are we doing this" thats why i wanted to add that placeholder. I
> > see "TODO"s are a common thing in the driver for larger
> > features that cant all be enabled at once. Respectfully and humbly,
> > is there some documented rule? Can you show it to
> > me?
> 
> Separating refactoring from functional changes is one of the most
> basic 
> principles we follow (and not just us) and there should never be 
> pushback on the former due lack of functional changes.
> 
> On the basic level following this guideline makes it trivial to
> review 
> the refactoring patch, and in the vast majority of cases much easier
> to 
> review the functional change patch as well.
> 
> And easy to review means happy reviewers, faster turnaround time
> (easier 
> to carry a rebase), happier authors, easier reverts when things go
> bad 
> (only small functional patch needs to be reverted), sometimes even 
> easier backporting if code diverged a lot.
> 
> Oh, and it even has potential to decrease internal technical debt.
> Often 
> you can push refactoring upstream and keep a smaller delta behind the
> closed doors, when that is required.
> 
> > > > Signed-off-by: Alan Previn 
> > > > ---
> > > >   drivers/gpu/drm/i915/i915_drv.h  |  4 
> > > >   drivers/gpu/drm/i915/pxp/intel_pxp.c | 22
> > > > ++--
> > > >   drivers/gpu/drm/i915/pxp/intel_pxp.h |  3 +++
> > > >   drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c |  2 +-
> > > >   4 files changed, 20 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 7e3820d2c404..0616e5f0bd31 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -933,10 +933,6 @@ IS_SUBPLATFORM(const struct
> > > > drm_i915_private *i915,
> > > >   
> > > >   #define
> > > > HAS_GLOBAL_MOCS_REGISTERS(dev_priv)   (INTEL_INFO(dev_priv)-
> > > > >has_global_mocs)
> > > >   
> > > > -#define HAS_PXP(dev_priv)  ((IS_ENABLED(CONFIG_DRM_I915_PXP)
> > > > && \
> > > > -   INTEL_INFO(dev_priv)->has_pxp) && \
> > > > -   VDBOX_MASK(to_gt(dev_priv)))
> > > > -
> > > >   #define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)-
> > > > >display.has_gmch)
> > > >   
> > > >   #define HAS_GMD_ID(i915)  (INTEL_INFO(i915)->has_gmd_id)
> > > > diff --git a/drivers/gp

Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> From: Vinay Belgaumkar 
> 
> By defaut idle messaging is disabled for GSC CS so to unblock RC6
> entry on media tile idle messaging need to be enabled.
> 
> v2:
>  - Fix review comments (Vinay)
>  - Set GSC idle hysteresis as per spec (Badal)
> v3:
>  - Fix review comments (Rodrigo)
> 
> Bspec: 71496
> 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Vinay Belgaumkar 
> Signed-off-by: Badal Nilawar 
> Reviewed-by: Vinay Belgaumkar 

He is the author of the patch, no?!
or you can remove this or change the author to be you and keep his
reviewed-by...

or I can just remove his rv-b while merging.. just let me know..

> Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  4 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index b0a4a2dbe3ee..e971b153fda9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -15,6 +15,22 @@
>  #include "intel_rc6.h"
>  #include "intel_ring.h"
>  #include "shmem_utils.h"
> +#include "intel_gt_regs.h"
> +
> +static void intel_gsc_idle_msg_enable(struct intel_engine_cs
> *engine)
> +{
> +   struct drm_i915_private *i915 = engine->i915;
> +
> +   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> +   intel_uncore_write(engine->gt->uncore,
> +  RC_PSMI_CTRL_GSCCS,
> + 
> _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
> +   /* hysteresis 0xA=5us as recommended in spec*/
> +   intel_uncore_write(engine->gt->uncore,
> +  PWRCTX_MAXCNT_GSCCS,
> +  0xA);
> +   }
> +}
>  
>  static void dbg_poison_ce(struct intel_context *ce)
>  {
> @@ -275,6 +291,8 @@ void intel_engine_init__pm(struct intel_engine_cs
> *engine)
>  
> intel_wakeref_init(>wakeref, rpm, _ops);
> intel_engine_init_heartbeat(engine);
> +
> +   intel_gsc_idle_msg_enable(engine);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index c3cd92691795..80a979e6f6be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -917,6 +917,10 @@
>  #define  MSG_IDLE_FW_MASK  REG_GENMASK(13, 9)
>  #define  MSG_IDLE_FW_SHIFT 9
>  
> +#defineRC_PSMI_CTRL_GSCCS  _MMIO(0x11a050)
> +#define  IDLE_MSG_DISABLE  REG_BIT(0)
> +#definePWRCTX_MAXCNT_GSCCS _MMIO(0x11a054)
> +
>  #define FORCEWAKE_MEDIA_GEN9   _MMIO(0xa270)
>  #define FORCEWAKE_RENDER_GEN9  _MMIO(0xa278)
>  

Re: [Intel-gfx] [PULL] gvt-next

[Vivi, Rodrigo]

On Thu, 2022-11-17 at 11:02 +0800, Zhenyu Wang wrote:
> On 2022.11.15 10:36:59 -0500, Rodrigo Vivi wrote:
> > On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote:
> > > Hi,
> > > 
> > > Here's current accumulated changes in gvt-next. Sorry that I
> > > delayed
> > > to refresh them on time for upstream...It contains mostly kernel
> > > doc,
> > > typo fixes and small code cleanups, as details below.
> > > 
> > > btw, one gvt change for next
> > > https://patchwork.freedesktop.org/patch/58/
> > > is still pending, I need a backmerge from linus tree e.g with
> > > recent vfio/mdev
> > > consolidate change with gvt and Jason's fix for destroy device,
> > > to apply Zhi's
> > > change cleanly. Pls help on that.
> > > 
> > > Thanks!
> > > ---
> > > The following changes since commit
> > > a6ebd538364b1e9e6048faaafbc0188172ed50c3:
> > > 
> > >   drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-11
> > > 
> > > for you to fetch changes up to
> > > 50468ca2e2e1ce882f060a8c263f678affe112db:
> > > 
> > >   drm/i915/gvt: Remove the unused function get_pt_type() (2022-
> > > 11-08 15:34:06 +0800)
> > > 
> > > 
> > > gvt-next-2022-11-11
> > > 
> > > - kernel doc fixes
> > > - remove vgpu->released sanity check
> > > - small clean up
> > > 
> > > 
> > > Colin Ian King (1):
> > >   drm/i915/reg: Fix spelling mistake "Unsupport" ->
> > > "Unsupported"
> > 
> > dim: d7e4e9579f01 ("drm/i915/reg: Fix spelling mistake "Unsupport"
> > -> "Unsupported""): committer Signed-off-by missing.
> > 
> > could you please fix this before we can merge this pr?
> > 
> 
> That should still be .mailmap issue for Colin's email...
> But could we improve our dim script to grep mailmap in that case? So
> if s-o-b mail is valid
> in mailmap, we should still allow it, right?

Based on what I could verify the commiter signature is really not
there. It looks like you later forced a rebase and while
rebasing you forgot to re-sign everything.

We need to fix this in your tree to avoid propagating that to other
trees later:

From tig view:
Commit: Zhenyu Wang 
CommitDate: Tue Nov 8 15:04:53 2022 +0800

drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

There is a spelling mistake in a gvt_vgpu_err error message. Fix
it.

Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with
gvt_vgpu_err")
Signed-off-by: Colin Ian King 
Signed-off-by: Zhi Wang 
Link:
http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.k...@gmail.com
Reviewed-by: Zhi Wang 

no signature from you.

> 
> > > 
> > > Jiapeng Chong (4):
> > >   drm/i915/gvt: Fix kernel-doc
> > >   drm/i915/gvt: Fix kernel-doc
> > >   drm/i915/gvt: Fix kernel-doc
> > >   drm/i915/gvt: Remove the unused function get_pt_type()
> > > 
> > > Julia Lawall (1):
> > >   drm/i915/gvt: fix typo in comment
> > > 
> > > Mauro Carvalho Chehab (1):
> > >   drm/i915: gvt: fix kernel-doc trivial warnings
> > > 
> > > Paulo Miguel Almeida (1):
> > >   i915/gvt: remove hardcoded value on crc32_start calculation
> > > 
> > > Zhi Wang (1):
> > >   drm/i915/gvt: remove the vgpu->released and its sanity
> > > check
> > > 
> > > wangjianli (1):
> > >   drm/i915: fix repeated words in comments
> > > 
> > >  drivers/gpu/drm/i915/gvt/aperture_gm.c  | 4 ++--
> > >  drivers/gpu/drm/i915/gvt/cfg_space.c    | 2 +-
> > >  drivers/gpu/drm/i915/gvt/dmabuf.h   | 2 +-
> > >  drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> > >  drivers/gpu/drm/i915/gvt/gtt.c  | 9 ++---
> > >  drivers/gpu/drm/i915/gvt/gvt.h  | 2 --
> > >  drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> > >  drivers/gpu/drm/i915/gvt/kvmgt.c    | 4 
> > >  drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> > >  drivers/gpu/drm/i915/gvt/page_track.c   | 2 +-
> > >  drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> > >  11 files changed, 14 insertions(+), 25 deletions(-)
> > 
> > 

Re: [Intel-gfx] [PULL] drm-intel-next

[Vivi, Rodrigo]

On Sat, 2022-10-29 at 02:41 +0300, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 02:22:33PM -0400, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Here goes the first chunk of drm-intel-next targeting 6.2
> > 
> > The highlight goes to Ville with many display related clean-up
> > and improvement, some other MTL enabling work and many other
> > fixes and small clean-ups.
> > 
> > drm-intel-next-2022-10-28:
> ...
> > - ELD precompute and readout (Ville)
> 
> A slight clarification seems to be in order. The ELD
> precompute+readout is in fact not in yet. This was just a pile
> of cleanups and minor fixes. The real ELD stuff will come later,
> once we figure out how we actually want to do it.

Sorry for the confusion. I have just used the subject of your series
as summary: 
[Intel-gfx] [PATCH 00/22] drm/i915: ELD precompute and readout

Should I change that to ELD precompute and readout

> 

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper

[Vivi, Rodrigo]

On Wed, 2022-09-28 at 12:31 +, Tangudu, Tilak wrote:
> +
> 
> > -Original Message-
> > From: Tangudu, Tilak
> > Sent: Wednesday, September 28, 2022 5:46 PM
> > To: Tangudu, Tilak ; Vivi, Rodrigo
> > ; Nikula, Jani 
> > Cc: Wilson, Chris P ; Gupta, saurabhg
> > ; intel-gfx@lists.freedesktop.org
> > Subject: RE: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed
> > helper
> > 
> >  @Nikula, Jani,
> > 
> > As you know we have reused i915_gem_backup_suspend,
> > i915_gem_suspend_late and i915_gem_resume in
> > runtime_pm_suspend/resume callbacks ,they use runtime pm helpers
> > (intel_runtime_pm_get/put).
> > These need to be avoided in callbacks as they lead to deadlock.
> > 
> > This can be done in two ways
> > 1) push runtime pm helpers usage at higher level functions,
> > Which requires code refactoring
> > (https://patchwork.freedesktop.org/series/105427/#rev2    is
> > partially
> > implemented following this)
> > 2) Add is_intel_rpm_allowed helper and avoid the runtime helpers
> > (https://patchwork.freedesktop.org/series/105427/#rev3 is
> > completely
> > implemented following this)
> > 
> > Hope I gave you the context,
> > 
> > As per your review comment in rev2,  the below is implemented in
> > rev3
> > 
> > """"""""""""""""""""""""
> > v2: Return -2 if runtime pm is not allowed in runtime_pm_get and
> > skip
> > wakeref release in runtime_pm_put if wakeref value is -2. - Jani N
> > Signed-off-by: Tilak Tangudu 
> > """""""""""""""""""""""""
> > 
> > Rodrigo and myself want to trigger a discussion, if 2) is a proper
> > approach or
> > go with 1) which requires lot of code refactoring.
> > Or Is there any way we follow 1) with less code refactoring.?
> > Or Do you think there is any other proper approach ?
> > 
> > (Please note rev3 is not clean, d3cold off support need to be
> > restricted to
> > Headless clients for now , we see some Display related warnings in
> > headed
> > case ).

I believe this warnings shows that the solution 2 has some flaws or
corner cases that we don't fully understand.

I honestly believe we need to go with option 1, moving the runtime_pm_
{get,put} to higher levels.

One way or another, we should not go partial here, but with full
implementation so we can see if we are really covered.

Jani, thoughts?

> > 
> > Thanks
> > Tilak
> > 
> > 
> > > -Original Message-
> > > From: Intel-gfx  On
> > > Behalf Of
> > > Tangudu, Tilak
> > > Sent: Thursday, August 4, 2022 11:03 AM
> > > To: Vivi, Rodrigo 
> > > Cc: Nikula, Jani ; Wilson, Chris P
> > > ; Gupta, saurabhg
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added
> > > is_intel_rpm_allowed helper
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: Vivi, Rodrigo 
> > > > Sent: Thursday, August 4, 2022 2:01 AM
> > > > To: Tangudu, Tilak 
> > > > Cc: Ewins, Jon ; Belgaumkar, Vinay
> > > > ; Roper, Matthew D
> > > > ; Wilson, Chris P
> > > > ; Nikula, Jani
> > > > ;
> > > > Gupta, saurabhg ; Gupta, Anshuman
> > > > ; Nilawar, Badal
> > > > ; Deak, Imre ;
> > > > Iddamsetty, Aravind ;
> > > > intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed
> > > > helper
> > > > 
> > > > On Thu, Jul 21, 2022 at 03:29:48PM +0530,
> > > > tilak.tang...@intel.com
> > wrote:
> > > > > From: Tilak Tangudu 
> > > > > 
> > > > > Added is_intel_rpm_allowed function to query the runtime_pm
> > > > > status
> > > > > and disllow during suspending and resuming.
> > > > 
> > > > > 
> > > > > v2: Return -2 if runtime pm is not allowed in runtime_pm_get
> > > > > and
> > > > > skip wakeref release in runtime_pm_put if wakeref value is -
> > > > > 2. -
> > > > > Jani N
> > > > 
> > > > Should we have some defines instead of the -#s?
> > > Ok will address this.
> > > > 
>

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

[Vivi, Rodrigo]

Rafael, could you please add your thoughts here?

On Thu, 2022-09-22 at 12:40 +, Gupta, Anshuman wrote:
> 
> 
> > -Original Message-
> > From: Gupta, Anshuman
> > Sent: Thursday, September 22, 2022 4:40 PM
> > To: Vivi, Rodrigo ; Tvrtko Ursulin
> > 
> > Cc: Nikula, Jani ; intel-
> > g...@lists.freedesktop.org; Daniel
> > J Blueman ; Wysocki, Rafael J
> > ; sta...@vger.kernel.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not
> > actively
> > managing a known PCI device.
> > 
> > 
> > 
> > On 9/22/2022 3:13 PM, Rodrigo Vivi wrote:
> > > On Thu, Sep 22, 2022 at 08:56:00AM +0100, Tvrtko Ursulin wrote:
> > > > 
> > > > On 21/09/2022 18:39, Rodrigo Vivi wrote:
> > > > > The force_probe protection actively avoids the probe of i915
> > > > > to
> > > > > manage a device that is currently under development. It is a
> > > > > nice
> > > > > protection for future users when getting a new platform but
> > > > > using
> > > > > some older kernel.
> > > > > 
> > > > > However, when we avoid the probe we don't take back the
> > > > > registration
> > > > > of the device. We cannot give up the registration anyway
> > > > > since we
> > > > > can have multiple devices present. For instance an integrated
> > > > > and a
> > > > > discrete one.
> > > > > 
> > > > > When this scenario occurs, the user will not be able to
> > > > > change any
> > > > > of the runtime pm configuration of the unmanaged device. So,
> > > > > it will
> > > > > be blocked in D0 state wasting power. This is specially bad
> > > > > in the
> > > > > case where we have a discrete platform attached, but the user
> > > > > is
> > > > > able to fully use the integrated one for everything else.
> > > > > 
> > > > > So, let's put the protected and unmanaged device in D3. So we
> > > > > can
> > > > > save some power.
> > > > > 
> > > > > Reported-by: Daniel J Blueman 
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: Daniel J Blueman 
> > > > > Cc: Tvrtko Ursulin 
> > > > > Cc: Anshuman Gupta 
> > > > > Signed-off-by: Rodrigo Vivi 
> > > > > ---
> > > > >    drivers/gpu/drm/i915/i915_pci.c | 8 
> > > > >    1 file changed, 8 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > > > b/drivers/gpu/drm/i915/i915_pci.c index
> > > > > 77e7df21f539..fc3e7c69af2a
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > > @@ -25,6 +25,7 @@
> > > > >    #include 
> > > > >    #include 
> > > > >    #include 
> > > > > +#include 
> > > > >    #include "gt/intel_gt_regs.h"
> > > > >    #include "gt/intel_sa_media.h"
> > > > > @@ -1304,6 +1305,7 @@ static int i915_pci_probe(struct
> > > > > pci_dev *pdev,
> > const struct pci_device_id *ent)
> > > > >    {
> > > > > struct intel_device_info *intel_info =
> > > > > (struct intel_device_info *) ent-
> > > > > >driver_data;
> > > > > +   struct device *kdev = >dev;
> > > > > int err;
> > > > > if (intel_info->require_force_probe && @@ -1314,6
> > > > > +1316,12 @@
> > > > > static int i915_pci_probe(struct pci_dev *pdev, const struct
> > > > > pci_device_id
> > *ent)
> > > > >  "module parameter or
> > CONFIG_DRM_I915_FORCE_PROBE=%04x configuration option,\n"
> > > > >  "or (recommended) check for kernel
> > > > > updates.\n",
> > > > >  pdev->device, pdev->device, pdev-
> > > > > >device);
> > > > > +
> > > > > +   /* Let's not waste power if we are not
> > > > > managing the device */
> > > > > +   pm_runtime_use_autosuspend(kdev);
> 

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

[Vivi, Rodrigo]

On Sun, 2022-09-11 at 19:22 +0200, Jason A. Donenfeld wrote:
> Hi Rodrigo,
> 
> On Thu, Sep 08, 2022 at 09:59:54AM -0400, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > A few fixes, but most targeting stable.
> > 
> > [...]
> > 
> > Ville Syrjälä (2):
> >   drm/i915: Implement WaEdpLinkRateDataReload
> 
> Don't you need to revert d5929835080a60f9119d024fa42f315913942f76 in
> order for "drm/i915: Implement WaEdpLinkRateDataReload" to actually
> be
> useful/interesting? Otherwise, what's the point?

Unfortunately there was no clear indication on the revert patch for
the tool to pick, and I hadn't followed that front myself closely.

Should 
483e3d87a37e ("Revert "drm/i915/display: Re-add check for low voltage
sku for max dp source rate"")
have a Fixes tag?

Or should dim consider all reverts as Fixes?

Anyway, I will cherry pick this to our fixes branch for propagation
this week.

Thanks for the heads up,
Rodrigo.

> 
> Regards,
> Jason

Re: [Intel-gfx] [PATCH 6/8] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Vivi, Rodrigo]

On Fri, 2022-09-09 at 08:38 -0700, Dixit, Ashutosh wrote:
On Fri, 09 Sep 2022 03:13:05 -0700, Rodrigo Vivi wrote:

On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote:
From: Tilak Tangudu mailto:tilak.tang...@intel.com>>
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 24009786f88b..9492f8f43b25 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1802,6 +1802,7 @@
 #define   POWER_LIMIT_4_MASK   REG_BIT(8)
 #define   POWER_LIMIT_1_MASK   REG_BIT(10)
 #define   POWER_LIMIT_2_MASK   REG_BIT(11)
+#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)


I'm kind of confused here because I saw the other bits in the patch 5.

Sorry Rodrigo, patch 5 is a bug-fix patch which should probably be merged
to -fixes independent of this series, I have posted it independently too:

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

yeap, better to merge this one first.

I hope 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108277v2/shard-apl4/igt@i915_pm_...@engine-order.html
is not related to this patch. should we trigger a retest?


I was debating including patch 5 as part of this series but then it was
touching the same code so I ended up including it. Sorry for the confusion.

no worries. it makes sense now.
Thanks for the patience


but, anyway, thanks for improving the commit msg.

Reviewed-by: Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>>

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2

[Vivi, Rodrigo]

On Fri, 2022-09-09 at 08:17 -0700, Ceraolo Spurio, Daniele wrote:
> 
> 
> On 9/9/2022 3:24 AM, Joonas Lahtinen wrote:
> > Dave, do you have a preference how to deal with the mishap here,
> > shall I do a
> > force-push to drm-intel-gt-next to correctly record the Acked-by or
> > revert and
> > re-push? Or just leave it as is?

Dave and Daniel, this question is still pertinent.

> > 
> > Quoting Greg Kroah-Hartman (2022-09-01 18:09:09)
> > > On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote:
> > > > Add GSC support for XeHP SDV and DG2 platforms.
> > > > 
> > > > The series includes changes for the mei driver:
> > > > - add ability to use polling instead of interrupts
> > > > - add ability to use extended timeouts
> > > > - setup extended operational memory for GSC
> > > > 
> > > > The series includes changes for the i915 driver:
> > > > - allocate extended operational memory for GSC
> > > > - GSC on XeHP SDV offsets and definitions
> > > > 
> > > > This patch set should be merged via gfx tree as
> > > > the auxiliary device belongs there.
> > > > Greg, your ACK is required for the drives/misc/mei code base,
> > > > please review the patches.
> > > With the exception that you all don't know what year it is:
> > > 
> > > Acked-by: Greg Kroah-Hartman 
> > Daniele, why were the patches applied without this A-b?
> 
> Apologies, I usually rely on dim to pick up all the correct r-bs and 
> acks from the ML and to warn me if something is missing, and I didn't
> realize that it hadn't automagically picked up the ack.

I understand the feeling. Recently I merged a patch from Vinay relying
on patchwork to get the reviewed-by and I forgot to double check.

dim picks up the "Link:", but I don't believe it picks any ack or rv-b
from the mailing list. Patchwork does if you use pwclient or something
like that.

Anyway, lesson to both of us to always double-check, regardless the
tool used.

> 
> > 
> > I'm just preparing the drm-intel-gt-next pull request and now it
> > appears
> > like we're pushing a lot of commits outside of drm without any
> > Acks.
> > 
> > Please reach out to the maintainers *before* pushing code for other
> > subsystems. Unless you get an explicit ack to do so, do not push
> > such
> > code.
> 
> I'm assuming you mean the i915 maintainers here, given that there is
> an 
> ack from Greg in this email? Rodrigo was in the loop of us needing to
> merge this via drm, so I thought I was good on that side. I'll make
> sure 
> to have an explicit ack on the ML next time (which is coming
> relatively 
> soon, because there are some more mei patches in the DG2 HuC series).

That's my fault indeed. I was following the movement, but I failed
to step up right after I saw Greg's ack.
Although I also noticed some re-send and reviews in progress even
after the ack, I should had been more active there.

Sorry,
Rodrigo.

> 
> > 
> > Quoting from the committer guidelines[1] the first rule is:
> > "Only push patches changing drivers/gpu/drm/i915."
> > 
> > In those cases, please ping a maintainer and don't rush things.
> 
> Will do. And apologies again for the mistake.
> 
> Daniele
> 
> > Regards, Joonas
> > 
> > [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-
> > drm-intel.html#high-level-guidelines
> > 
> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Let's avoid even early init if SLPC is used.

[Vivi, Rodrigo]

On Fri, 2022-09-02 at 07:16 -0700, Dixit, Ashutosh wrote:
> On Fri, 02 Sep 2022 02:51:26 -0700, Rodrigo Vivi wrote:
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index 6fadde4ee7bf..c29652281f2e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -1960,6 +1960,9 @@ void gen5_rps_irq_handler(struct intel_rps
> > *rps)
> > 
> >  void intel_rps_init_early(struct intel_rps *rps)
> >  {
> > +   if (rps_uses_slpc(rps))
> > +   return;
> > +
> 
> Hi Rodrigo, Let me double check with you, this works correctly at
> this
> place, correct? Looks like things to make this work should get
> initialized
> in intel_uc_init_early() which is called just before
> intel_rps_init_early()
> so looks ok (can't tell for sure with all those uc macros :/):

yeap, I hate those uc macros as well!

In theory it should work well since

@ static void __intel_gt_init_early(struct intel_gt *gt)
  intel_uc_init_early(>uc);   
  intel_rps_init_early(>rps); 
}

And it works well when slpc is enabled...
But our CI showed this is a disaster when SLPC is not used.

I will have to fix that.


> Reviewed-by: Ashutosh Dixit 
> 
> > mutex_init(>lock);
> > mutex_init(>power.mutex);
> > 
> > --
> > 2.37.2
> > 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move some of the request decisions out of rps_boost function.

[Vivi, Rodrigo]

On Fri, 2022-09-02 at 11:07 +0200, Das, Nirmoy wrote:
> Hi Rodrigo,
> 
> On 9/1/2022 9:32 PM, Rodrigo Vivi wrote:
> > Ideally all the decisions should be made before calling the boost
> > function.
> > And rps functions only receiving the rps struct. At least lets move
> > most
> > of the decisions to the request component, but still leave the test
> > and set of the fence flag boost inside the rps because that might
> > be time
> > sensitive.
> > 
> > Cc: Ashutosh Dixit 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >   drivers/gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
> >   drivers/gpu/drm/i915/gem/i915_gem_wait.c  | 3 ++-
> >   drivers/gpu/drm/i915/gt/intel_rps.c   | 3 ---
> >   drivers/gpu/drm/i915/gt/intel_rps.h   | 1 +
> >   drivers/gpu/drm/i915/i915_request.h   | 5 +++--
> >   5 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index dd876dbbaa39..6967c47c7ba0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -918,7 +918,7 @@ static int do_rps_boost(struct wait_queue_entry
> > *_wait,
> >  * is reasonable to assume that it will complete before the
> > next
> >  * vblank without our intervention, so leave RPS alone.
> >  */
> > -   if (!i915_request_started(rq))
> > +   if (!i915_request_started(rq) &&
> > i915_request_needs_boost(rq))
> > intel_rps_boost(rq);
> > i915_request_put(rq);
> >   
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > index e6e01c2a74a6..2f2ca5e27248 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > @@ -58,7 +58,8 @@ i915_gem_object_boost(struct dma_resv *resv,
> > unsigned int flags)
> >     dma_resv_usage_rw(flags &
> > I915_WAIT_ALL));
> > dma_resv_for_each_fence_unlocked(, fence)
> > if (dma_fence_is_i915(fence) &&
> > -   !i915_request_started(to_request(fence)))
> > +   !i915_request_started(to_request(fence)) &&
> > +   i915_request_needs_boost(to_request(fence)))
> > intel_rps_boost(to_request(fence));
> > dma_resv_iter_end();
> >   }
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index 579ae9ac089c..2c8d9eeb7e7e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -1006,9 +1006,6 @@ void intel_rps_boost(struct i915_request *rq)
> >   {
> > struct intel_guc_slpc *slpc;
> >   
> > -   if (i915_request_signaled(rq) ||
> > i915_request_has_waitboost(rq))
> > -   return;
> > -
> > /* Serializes with i915_request_retire() */
> > if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, 
> > >fence.flags)) {
> > struct intel_rps *rps = _ONCE(rq->engine)->gt-
> > >rps;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h
> > b/drivers/gpu/drm/i915/gt/intel_rps.h
> > index 4509dfdc52e0..9a053f1b04e8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.h
> > @@ -23,6 +23,7 @@ void intel_rps_disable(struct intel_rps *rps);
> >   
> >   void intel_rps_park(struct intel_rps *rps);
> >   void intel_rps_unpark(struct intel_rps *rps);
> > +bool intel_rps_request_needs_boost(struct i915_request *rq);
> >   void intel_rps_boost(struct i915_request *rq);
> >   void intel_rps_dec_waiters(struct intel_rps *rps);
> >   u32 intel_rps_get_boost_frequency(struct intel_rps *rps);
> > diff --git a/drivers/gpu/drm/i915/i915_request.h
> > b/drivers/gpu/drm/i915/i915_request.h
> > index 47041ec68df8..4f5049ef1ab9 100644
> > --- a/drivers/gpu/drm/i915/i915_request.h
> > +++ b/drivers/gpu/drm/i915/i915_request.h
> > @@ -625,9 +625,10 @@ static inline void
> > i915_request_mark_complete(struct i915_request *rq)
> >    (u32 *)>fence.seqno);
> >   }
> >   
> > -static inline bool i915_request_has_waitboost(const struct
> > i915_request *rq)
> > +static inline bool i915_request_needs_boost(const struct
> > i915_request *rq)
> >   {
> > -   return test_bit(I915_FENCE_FLAG_BOOST, >fence.flags);
> > +   return i915_request_signaled(rq)
> > +   && test_bit(I915_FENCE_FLAG_BOOST, 
> > >fence.flags);
> 
> This could be i915_request_has_waitboost() or else AFAICS 
> intel_rps_boost() is the only user of i915_request_has_waitboost()
> 
> and that could be removed.
> 
> Otherwise the series is: Acked-by: Nirmoy Das 

Thank you. I will actually hold this patch for now, because there's not
much value alone and the next one is pending broader validation.

I had resent the series with the only 2 simple patches that I want for
now: 

Re: [Intel-gfx] [PATCH] drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC

[Vivi, Rodrigo]

On Tue, 2022-08-30 at 17:45 -0700, Dixit, Ashutosh wrote:
> On Tue, 30 Aug 2022 12:16:20 -0700, Rodrigo Vivi wrote:
> > 
> 
> Hi Rodrigo,
> 
> > @@ -65,13 +63,8 @@ static bool get_ia_constants(struct intel_llc
> > *llc,
> > /* convert DDR frequency from units of 266.6MHz to
> > bandwidth */
> > consts->min_ring_freq = mult_frac(consts->min_ring_freq, 8,
> > 3);
> > 
> > -   consts->min_gpu_freq = rps->min_freq;
> > -   consts->max_gpu_freq = rps->max_freq;
> > -   if (GRAPHICS_VER(i915) >= 9) {
> > -   /* Convert GT frequency to 50 HZ units */
> > -   consts->min_gpu_freq /= GEN9_FREQ_SCALER;
> > -   consts->max_gpu_freq /= GEN9_FREQ_SCALER;
> > -   }
> > +   consts->min_gpu_freq = intel_rps_get_min_raw_freq(rps);
> > +   consts->max_gpu_freq = intel_rps_get_max_raw_freq(rps);
> > 
> > return true;
> >  }
> > @@ -130,6 +123,12 @@ static void gen6_update_ring_freq(struct
> > intel_llc *llc)
> > if (!get_ia_constants(llc, ))
> > return;
> > 
> > +   /*
> > +    * Although this is unlikely on any platform during
> > initialization,
> > +    * let's ensure we don't get accidentally into infinite
> > loop
> > +    */
> > +   if (consts.max_gpu_freq <= consts.min_gpu_freq)
> > +   return;
> 
> As I said this is not correct and is not needed. If
> 'consts.max_gpu_freq ==
> consts.min_gpu_freq' we would *want* to program PCODE. If
> 'consts.max_gpu_freq < consts.min_gpu_freq' the loop will
> automatically
> skip (and also it is not an infinite loop).

yeap, but if we change this condition in the loop we will
miss one entry in the case they are equal.
Since we are doing this generically for 15 years of hardware
I didn't want to take the risk of having some out there
where the min = max and the 1 entry in the table is needed.

> 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index de794f5f8594..26af974292c7 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -2156,6 +2156,24 @@ u32 intel_rps_get_max_frequency(struct
> > intel_rps *rps)
> > return intel_gpu_freq(rps, rps-
> > >max_freq_softlimit);
> >  }
> > 
> > +u32 intel_rps_get_max_raw_freq(struct intel_rps *rps)
> 
> What does "raw" mean? Or are we introducing a new concept here then
> we need
> to explain the new concept? I was previously told there is a concept
> of "hw
> units" of freq and intel_gpu_freq will convert from "hw units" to
> MHz.

yeap, it is the hw units, some folks also calling FID of the freqs.
I couldn't find a better name.

> 
> Also, Is the return value in units of 50 MHz in all cases (we know it
> is
> for SLPC and Gen 9+)? In that case we should name such a function to
> something like intel_rps_get_max_freq_in_50mhz_units?

yeap, that would work... at least until in some future platform our hw
folks need to find another base...

> 
> > +{
> > +   struct intel_guc_slpc *slpc = rps_to_slpc(rps);
> > +   u32 freq;
> > +
> > +   if (rps_uses_slpc(rps)) {
> > +   return DIV_ROUND_CLOSEST(slpc->rp0_freq,
> > +    GT_FREQUENCY_MULTIPLIER);
> > +   } else {
> > +   freq = rps->max_freq;
> > +   if (GRAPHICS_VER(rps_to_i915(rps)) >= 9) {
> > +   /* Convert GT frequency to 50 HZ units */
> 
> 50 MHz and not 50 Hz. Also the comment should be moved to above
> rps_uses_slpc() line if returned freq is always in units of 50 MHz.

yeap, this comment was already there and probably wrong...

> 
> > +   freq /= GEN9_FREQ_SCALER;
> > +   }
> > +   return freq;
> > +   }
> > +}
> 
> Also is this function equivalent to this:
> 
> u32 intel_rps_get_max_freq_in_50mhz_units(struct intel_rps *rps)
> {
> struct intel_guc_slpc *slpc = rps_to_slpc(rps);
> u32 freq;
> 
> /* freq in MHz */
> freq = rps_uses_slpc(rps) ? slpc->rp0_freq :
> intel_gpu_freq(rps->max_freq);

do you really want to convert forth and back? Can we minimize the math?

> 
> return DIV_ROUND_CLOSEST(freq, GT_FREQUENCY_MULTIPLIER);
> }
> 
> Sorry I don't have a lot of history in how these frequencies are
> scaled
> specially for old platforms like CHV/VLV/Gen6+. But afaiu
> intel_gpu_freq()
> will convert the freq to MHz for all platforms.

yeap, old platforms also concern me... another reason to avoid doing
something new and only using the conversion that was already there.

> 
> And then does get_ia_constants() accept freq in 50 MHz units for all
> platforms?

Please notice that there's absolutely no change for the non-slpc
platforms.

> 
> If we are not sure about this, we can go with your version which is
> closer
> to the original version in get_ia_constants() and so "safer" I guess.

so you mean this version? ;)

> 
> Thanks.
> --
> Ashutosh

Re: [Intel-gfx] [PATCH] drm/i915/slpc: Set rps' min and max frequencies even with SLPC.

[Vivi, Rodrigo]

On Thu, 2022-08-25 at 16:59 -0700, Dixit, Ashutosh wrote:
On Thu, 25 Aug 2022 15:23:15 -0700, Rodrigo Vivi wrote:

We need to inform PCODE of a desired ring frequencies so PCODE update
the memory frequencies to us. rps->min_freq and rps->max_freq are the
frequencies used in that request. However they were unset when SLPC was
enabled and PCODE never updated the memory freq.

Let's at least for now get these freq set up so we can inform PCODE.

Hi Rodrigo,

Great find. Though may I propose a more direct patch below for fixing this:

+
diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c 
b/drivers/gpu/drm/i915/gt/intel_llc.c
index 14fe65812e42..a1791b6c7e04 100644
--- a/drivers/gpu/drm/i915/gt/intel_llc.c
+++ b/drivers/gpu/drm/i915/gt/intel_llc.c
@@ -49,6 +49,7 @@ static unsigned int cpu_max_MHz(void)
 static bool get_ia_constants(struct intel_llc *llc,
 struct ia_constants *consts)
 {
+   struct intel_guc_slpc *slpc = _to_gt(llc)->uc.guc.slpc;
struct drm_i915_private *i915 = llc_to_gt(llc)->i915;
struct intel_rps *rps = _to_gt(llc)->rps;

@@ -65,8 +66,14 @@ static bool get_ia_constants(struct intel_llc *llc,
/* convert DDR frequency from units of 266.6MHz to bandwidth */
consts->min_ring_freq = mult_frac(consts->min_ring_freq, 8, 3);

-   consts->min_gpu_freq = rps->min_freq;
-   consts->max_gpu_freq = rps->max_freq;
+   if (intel_uc_uses_guc_slpc(_to_gt(llc)->uc)) {
+   consts->min_gpu_freq = slpc->min_freq;
+   consts->max_gpu_freq = slpc->rp0_freq;
+   } else {
+   consts->min_gpu_freq = rps->min_freq;
+   consts->max_gpu_freq = rps->max_freq;
+   }
+
if (GRAPHICS_VER(i915) >= 9) {
/* Convert GT frequency to 50 HZ units */
consts->min_gpu_freq /= GEN9_FREQ_SCALER;
+

I have only compile tested the patch but it looks like everything is set up
so the patch above should work. The call stack for slpc initialization is
the following (I am writing here due to the rather opaque uc macros):

intel_gt_resume
-> intel_gt_init_hw
-> intel_uc_init_hw/__uc_init_hw
-> intel_guc_slpc_enable
-> slpc_get_rp_values

As we can see intel_llc_enable() is called after intel_gt_init_hw() in
intel_gt_resume() so SLPC params should be set up.

Yeap, I took that path worried about timing, but you are right this should
be there already and it would be cleaner.


What you have is fine too, I can R-b that if you prefer that.

Your is better and cleaner. Let me try that first here and then I will resend 
it.

Thank you!


Thanks.
--
Ashutosh

Cc: Ashutosh Dixit mailto:ashutosh.di...@intel.com>>
Tested-by: Sushma Venkatesh Reddy 
mailto:sushma.venkatesh.re...@intel.com>>
Signed-off-by: Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>>
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 8c289a032103..58a82978d5df 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1128,6 +1128,20 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps, 
struct intel_rps_freq_caps *c
}
 }

+static void rps_basic_init_for_slpc(struct intel_rps *rps)
+{
+   struct intel_rps_freq_caps caps;
+
+   /*
+* Even with SLPC we need to initialize at least a basic min and max
+* frequency so we can inform pcode a desired IA ring frequency in
+* gen6_update_ring_freq
+*/
+   gen6_rps_get_freq_caps(rps, );
+   rps->min_freq = caps.min_freq;
+   rps->max_freq = caps.rp0_freq;
+}
+
 static void gen6_rps_init(struct intel_rps *rps)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
@@ -1970,8 +1984,10 @@ void intel_rps_init(struct intel_rps *rps)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);

-   if (rps_uses_slpc(rps))
+   if (rps_uses_slpc(rps)) {
+   rps_basic_init_for_slpc(rps);
return;
+   }

if (IS_CHERRYVIEW(i915))
chv_rps_init(rps);
--
2.37.1

Re: [Intel-gfx] [PATCH i-g-t] i915/guc: Disable i915_pm_rps when SLPC is enabled

[Vivi, Rodrigo]

On Thu, 2022-08-18 at 13:42 -0700, Vinay Belgaumkar wrote:
> These tests were specifically designed for host Turbo. Skip
> them when SLPC is enabled as they fail frequently. We will look
> to keep adding to SLPC test coverage with these scenarios.
> 
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/4016
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/5468
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/5831
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Vinay Belgaumkar 

Ideally we should add other api tests and cases to validate the
expected slpc flow.
But this could be done in a follow-up work since right now it is
important to merge
the fix for the performance regression without the ignore_efficient
freq.

So,
Reviewed-by: Rodrigo Vivi 

> ---
>  lib/igt_pm.c | 15 +++
>  lib/igt_pm.h |  1 +
>  tests/i915/i915_pm_rps.c | 29 -
>  3 files changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 6ebbad33..79bd6e2a 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -1202,3 +1202,18 @@ void
> igt_pm_print_pci_card_runtime_status(void)
> igt_pm_print_pci_dev_runtime_status(__pci_dev_pwrattr
> [i].pci_dev);
> }
>  }
> +
> +bool i915_is_slpc_enabled(int fd)
> +{
> +   int debugfs_fd = igt_debugfs_dir(fd);
> +   char buf[4096];
> +   int len;
> +
> +   igt_require(debugfs_fd != -1);
> +
> +   len = igt_debugfs_simple_read(debugfs_fd,
> "gt/uc/guc_slpc_info", buf, sizeof(buf));
> +   if (len < 0)
> +   return false;
> +   else
> +   return strstr(buf, "SLPC state: running");
> +}
> diff --git a/lib/igt_pm.h b/lib/igt_pm.h
> index f28b6ebf..cbbde12b 100644
> --- a/lib/igt_pm.h
> +++ b/lib/igt_pm.h
> @@ -79,5 +79,6 @@ void igt_pm_enable_pci_card_runtime_pm(struct
> pci_device *root,
>  void igt_pm_setup_pci_card_runtime_pm(struct pci_device *pci_dev);
>  void igt_pm_restore_pci_card_runtime_pm(void);
>  void igt_pm_print_pci_card_runtime_status(void);
> +bool i915_is_slpc_enabled(int fd);
>  
>  #endif /* IGT_PM_H */
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index d06ade27..cce07009 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -914,35 +914,54 @@ igt_main
> igt_install_exit_handler(pm_rps_exit_handler);
> }
>  
> -   igt_subtest("basic-api")
> +   igt_subtest("basic-api") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> min_max_config(basic_check, false);
> +   }
>  
> /* Verify the constraints, check if we can reach idle */
> -   igt_subtest("min-max-config-idle")
> +   igt_subtest("min-max-config-idle") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> min_max_config(idle_check, true);
> +   }
>  
> /* Verify the constraints with high load, check if we can
> reach max */
> igt_subtest("min-max-config-loaded") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> load_helper_run(HIGH);
> min_max_config(loaded_check, false);
> load_helper_stop();
> }
>  
> /* Checks if we achieve boost using gem_wait */
> -   igt_subtest("waitboost")
> +   igt_subtest("waitboost") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> waitboost(drm_fd, false);
> +   }
>  
> igt_describe("Check if the order of fences does not affect
> waitboosting");
> -   igt_subtest("fence-order")
> +   igt_subtest("fence-order") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> fence_order(drm_fd);
> +   }
>  
> igt_describe("Check if context reuse does not affect
> waitboosting");
> -   igt_subtest("engine-order")
> +   igt_subtest("engine-order") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> engine_order(drm_fd);
> +   }
>  
> /* Test boost frequency after GPU reset */
> igt_subtest("reset") {
> igt_hang_t hang = igt_allow_hang(drm_fd, 0, 0);
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> waitboost(drm_fd, 

Re: [Intel-gfx] [PULL] gvt-fixes

[Vivi, Rodrigo]

On Thu, 2022-08-18 at 17:27 +0300, Jani Nikula wrote:
On Thu, 18 Aug 2022, Jani Nikula 
mailto:jani.nik...@intel.com>> wrote:
On Wed, 17 Aug 2022, "Colin King (gmail)" 
mailto:colin.i.k...@gmail.com>> wrote:
On 17/08/2022 21:07, Vivi, Rodrigo wrote:
On Tue, 2022-08-16 at 12:43 +0800, Zhenyu Wang wrote:
On 2022.08.16 12:05:08 +0800, Zhenyu Wang wrote:
On 2022.08.15 19:32:45 -0400, Rodrigo Vivi wrote:
On Mon, Aug 15, 2022 at 10:38:55AM +0800, Zhenyu Wang wrote:
oh, surprise! I just found Colin's email is actually defined in
.mailmap,
so all his commits in kernel are changed for @intel.com address as in
mailmap...

Colin, would you mind to get the Sign-off-by in the patches the same
as your authorship so the tools don't get confused?
(starting with modifying in tree this already merged patch)

Since my patches are generally trivial janitorial fixed done in my spare
time I'm going to get the .mailmap changed to use my gmail email address
rather than my Intel one (since I don't do kernel work in my current role).

This should clean up the confusion. Apologies.

Everyone hold your horses.

I think our tooling should handle the mailmap stuff. The commit *is*
fine, it's just that the when we check it, we let mailmap alter it. We
should check the commit without mailmap modifications.

In this case, it's actually not about Colin's Signed-off-by or mailmap
at all! Like the error message from dim says, "committer Signed-off-by
missing". Committer, not author!

$ git show -s tags/gvt-fixes-2022-08-15^ --pretty=fuller
commit d6632370536d0b80be3bfc90dd67e1f693335a75
Author: Colin Ian King mailto:colin.k...@intel.com>>
AuthorDate: Tue Mar 15 20:24:49 2022 +
Commit: Zhenyu Wang 
mailto:zhen...@linux.intel.com>>
CommitDate: Mon Aug 15 10:51:15 2022 +0800

drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

There is a spelling mistake in a gvt_vgpu_err error message. Fix it.

Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Colin Ian King 
mailto:colin.i.k...@gmail.com>>
Signed-off-by: Zhi Wang mailto:zhi.a.w...@intel.com>>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.k...@gmail.com
Reviewed-by: Zhi Wang mailto:zhi.a.w...@intel.com>>

Committed by Zhenyu, Signed-off-by Zhi. Maybe caused by rebase by Zhenyu
after being committed by Zhi?

Probably easier if you could rebase it again signing it then?

I could bypass dim here, but this will likely affect someone else later in the 
upstream chain as well..


BR,
Jani.

Re: [Intel-gfx] [PULL] gvt-fixes

[Vivi, Rodrigo]

On Tue, 2022-08-16 at 12:43 +0800, Zhenyu Wang wrote:
> On 2022.08.16 12:05:08 +0800, Zhenyu Wang wrote:
> > On 2022.08.15 19:32:45 -0400, Rodrigo Vivi wrote:
> > > On Mon, Aug 15, 2022 at 10:38:55AM +0800, Zhenyu Wang wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > Here's one gvt-fixes pull for 6.0-rc. Major one is Cometlake
> > > > regression
> > > > fix for mmio table rework, and others are left kernel doc fixes
> > > > not pushed yet.
> > > > 
> > > > Thanks
> > > > --
> > > > The following changes since commit
> > > > a7a47a5dfa9a9692a41764ee9ab4054f12924a42:
> > > > 
> > > >   drm/i915/reset: Add additional steps for Wa_22011802037 for
> > > > execlist backend (2022-07-25 15:57:54 +0100)
> > > > 
> > > > are available in the Git repository at:
> > > > 
> > > >   https://github.com/intel/gvt-linux.git tags/gvt-fixes-2022-
> > > > 08-15
> > > > 
> > > > for you to fetch changes up to
> > > > 394f0560a76298842defd1d95bd64b203a5fdcc4:
> > > > 
> > > >   drm/i915/gvt: Fix Comet Lake (2022-08-15 10:54:03 +0800)
> > > > 
> > > > ---
> > > > -
> > > > gvt-fixes-2022-08-15
> > > > 
> > > > - CometLake regression fix in mmio table rework (Alex)
> > > > - misc kernel doc and typo fixes
> > > > 
> > > > ---
> > > > -
> > > > Alex Williamson (1):
> > > >   drm/i915/gvt: Fix Comet Lake
> > > > 
> > > > Colin Ian King (1):
> > > >   drm/i915/reg: Fix spelling mistake "Unsupport" ->
> > > > "Unsupported"
> > > 
> > > dim: d6632370536d ("drm/i915/reg: Fix spelling mistake
> > > "Unsupport" -> "Unsupported""): committer Signed-off-by missing.
> > > 
> > > is it possible to fix this in your tree?
> > 
> > Sorry about that. Let me re-generate.
> 
> oh, surprise! I just found Colin's email is actually defined in
> .mailmap,
> so all his commits in kernel are changed for @intel.com address as in
> mailmap...

Colin, would you mind to get the Sign-off-by in the patches the same
as your authorship so the tools don't get confused?
(starting with modifying in tree this already merged patch)

Thanks,
Rodrigo.

> 
> So maybe I can't change that?
> 
> 

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

[Vivi, Rodrigo]

On Tue, 2022-08-09 at 01:09 +0200, Andi Shyti wrote:
> Hi Rodrigo,
> 
> On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote:
> > On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote:
> > > Hi Mauro,
> > > 
> > > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab
> > > wrote:
> > > > WRITE_ONCE() should happen at the original var, not on a local
> > > > copy of it.
> > > > 
> > > > Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > 
> > > Reviewed-by: Andi Shyti 
> > 
> > Thanks and pushed...
> 
> Thanks!
> 
> > > 
> > > Are you going to send it to the stable mailing list?
> > 
> > I added cc stable while pushing and the cherry-pick to drm-intel-
> > next-fixes
> > has the right sha, so I'd assume this would be automagically now.
> > But yeap, it would be good if Mauro can follow up whenever this
> > gets
> > to Linus tree and Greg's script start to pop up the heads-up
> > messages.
> 
> That's what I meant... does Mauro now need to send the e-mail
> again for the stable?
> 
> I thought there was some suspicion towards e-mails pushed without
> being first sent to both stable and upstream mailing lists
> because they can get lost or forgotten... maybe I'm wrong.

It doesn't help to send now to stable ml because it can only be merged
there after it reaches the Linus' master tree.
Right now with the right fixes and cc:stable it should be automatically
and he shouldn't worry.
But in case he notices that the first patch got in but the second
didn't then it is when we send the patch directly to the stable ml.


> 
> Andi
> 
> > Thanks,
> > Rodrigo.
> > 
> > > 
> > > Andi

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper

[Vivi, Rodrigo]

On Thu, 2022-08-04 at 05:32 +, Tangudu, Tilak wrote:
> 
> 
> > -Original Message-
> > From: Vivi, Rodrigo 
> > Sent: Thursday, August 4, 2022 2:01 AM
> > To: Tangudu, Tilak 
> > Cc: Ewins, Jon ; Belgaumkar, Vinay
> > ; Roper, Matthew D
> > ; Wilson, Chris P
> > ;
> > Nikula, Jani ; Gupta, saurabhg
> > ; Gupta, Anshuman
> > ; Nilawar, Badal
> > ;
> > Deak, Imre ; Iddamsetty, Aravind
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed
> > helper
> > 
> > On Thu, Jul 21, 2022 at 03:29:48PM +0530,
> > tilak.tang...@intel.com wrote:
> > > From: Tilak Tangudu 
> > > 
> > > Added is_intel_rpm_allowed function to query the runtime_pm
> > > status and
> > > disllow during suspending and resuming.
> > 
> > > 
> > > v2: Return -2 if runtime pm is not allowed in runtime_pm_get and
> > > skip
> > > wakeref release in runtime_pm_put if wakeref value is -2. - Jani
> > > N
> > 
> > Should we have some defines instead of the -#s?
> Ok will address this.
> > 
> > > Signed-off-by: Tilak Tangudu 
> > > ---
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 23
> > ++-
> > > drivers/gpu/drm/i915/intel_runtime_pm.h |  1 +
> > >  2 files changed, 23 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 6ed5786bcd29..704beeeb560b 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -113,7 +113,7 @@ static void
> > untrack_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm,
> > > unsigned long flags, n;
> > > bool found = false;
> > > 
> > > -   if (unlikely(stack == -1))
> > > +   if (unlikely(stack == -1) || unlikely(stack == -2))
> > > return;
> > > 
> > > spin_lock_irqsave(>debug.lock, flags); @@ -320,6
> > > +320,21
> > @@
> > > untrack_all_intel_runtime_pm_wakerefs(struct intel_runtime_pm
> > > *rpm)  }
> > > 
> > >  #endif
> > > +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm)
> > > {
> > > +   return rpm->kdev->power.runtime_status; }
> > > +
> > > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm)
> > 
> > why not static?
>  We need is_intel_rpm_allowed for rc6 helpers , the helpers use
> pm_runtime_get_sync,
> To avoid lock issue we need to use it here too.
> 
> See this patch " drm/i915: Guard rc6 helpers with
> is_intel_rpm_allowed" 
> 
> > 
> > > +{
> > > +   int rpm_status;
> > > +
> > > +   rpm_status = intel_runtime_pm_status(rpm);
> > > +   if (rpm_status == RPM_RESUMING
> > 
> > I don't have a good feeling about this. If we are resuming we
> > shouldn't grab
> > extra references... This seems a workaround for the lock mess.
> > 
> > > > > rpm_status == RPM_SUSPENDING)
> > 
> > and when we are suspending and we call this function is because we
> > need to
> > wake up, no?!
> 
> As we have re-used i915_gem_backup_suspend, i915_gem_suspend_late
>  and i915_gem_resume , These functions use runtime helpers, which in-
> turn call
>  runtime suspend/resume callbacks and leads to deadlock.
>  So, these helpers need to be avoided.  we have added
> is_intel_rpm_allowed
>  and disallowed rpm callbacks with above condition during suspending
> and resuming
>  to avoid deadlock.

Why does these functions in suspend resume path are using the runtime
callbacks?
Can't we have a refactor on that area that allows the paths that we
need in a place where we are sure that device is not going to d3?
then we can have a clear infra?

> > 
> > > +   return false;
> > > +   else
> > > +   return true;
> > > +}
> > > 
> > >  static void
> > >  intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool
> > > wakelock)
> > > @@ -354,6 +369,9 @@ static intel_wakeref_t
> > __intel_runtime_pm_get(struct intel_runtime_pm *rpm,
> > >  runtime_pm);
> > > int ret;
> > > 
> > > +   if (!is_intel_rpm_allowed(rpm))
> > > +   return -2;
> > > +
> >

Re: [Intel-gfx] [PULL] drm-intel-gt-next

[Vivi, Rodrigo]

On Wed, 2022-07-13 at 17:31 -0400, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
> 
> On behalf of Tvrtko, who is recovering from Covid,
> here goes the latest drm-intel-gt-next pull request
> targeting 5.20.

Hi Folks,

any particular issue with this pull request?

We just realized it is not yet part of the drm-next.


Thanks,
Rodrigo.

> 
> Thanks,
> Rodrigo.
> 
> Driver uAPI changes:
> - All related to the Small BAR support: (and all by Matt Auld)
>  * add probed_cpu_visible_size
>  * expose the avail memory region tracking
>  * apply ALLOC_GPU only by default
>  * add NEEDS_CPU_ACCESS hint
>  * tweak error capture on recoverable contexts
> 
> Driver highlights:
> - Add Small BAR support (Matt)
> - Add MeteorLake support (RK)
> - Add support for LMEM PCIe resizable BAR (Akeem)
> 
> Driver important fixes:
> - ttm related fixes (Matt Auld)
> - Fix a performance regression related to waitboost (Chris)
> - Fix GT resets (Chris)
> 
> Driver others:
> - Adding GuC SLPC selftest (Vinay)
> - Fix ADL-N GuC load (Daniele)
> - Add platform workaround (Gustavo, Matt Roper)
> - DG2 and ATS-M device ID updates (Matt Roper)
> - Add VM_BIND doc rfc with uAPI documentation (Niranjana)
> - Fix user-after-free in vma destruction (Thomas)
> - Async flush of GuC log regions (Alan)
> - Fixes in selftests (Chris, Dan, Andrzej)
> - Convert to drm_dbg (Umesh)
> - Disable OA sseu config param for newer hardware (Umesh)
> - Multi-cast register steering changes (Matt Roper)
> - Add lmem_bar_size modparam (Priyanka)
> 
> Thanks,
> Rodrigo.
> 
> The following changes since commit
> a06968563775181690125091f470a8655742dcbf:
> 
>   drm/i915: Fix a lockdep warning at error capture (2022-06-29
> 14:52:50 +0530)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-
> 2022-07-13
> 
> for you to fetch changes up to
> 17cd10a44a8962860ff4ba351b2a290e752dbbde:
> 
>   drm/i915: Add lmem_bar_size modparam (2022-07-13 17:47:51 +0100)
> 
> 
> Driver uAPI changes:
> - All related to the Small BAR support: (and all by Matt Auld)
>  * add probed_cpu_visible_size
>  * expose the avail memory region tracking
>  * apply ALLOC_GPU only by default
>  * add NEEDS_CPU_ACCESS hint
>  * tweak error capture on recoverable contexts
> 
> Driver highlights:
> - Add Small BAR support (Matt)
> - Add MeteorLake support (RK)
> - Add support for LMEM PCIe resizable BAR (Akeem)
> 
> Driver important fixes:
> - ttm related fixes (Matt Auld)
> - Fix a performance regression related to waitboost (Chris)
> - Fix GT resets (Chris)
> 
> Driver others:
> - Adding GuC SLPC selftest (Vinay)
> - Fix ADL-N GuC load (Daniele)
> - Add platform workaround (Gustavo, Matt Roper)
> - DG2 and ATS-M device ID updates (Matt Roper)
> - Add VM_BIND doc rfc with uAPI documentation (Niranjana)
> - Fix user-after-free in vma destruction (Thomas)
> - Async flush of GuC log regions (Alan)
> - Fixes in selftests (Chris, Dan, Andrzej)
> - Convert to drm_dbg (Umesh)
> - Disable OA sseu config param for newer hardware (Umesh)
> - Multi-cast register steering changes (Matt Roper)
> - Add lmem_bar_size modparam (Priyanka)
> 
> 
> Akeem G Abodunrin (1):
>   drm/i915: Add support for LMEM PCIe resizable bar
> 
> Alan Previn (1):
>   drm/i915/guc: Asynchronous flush of GuC log regions
> 
> Andrzej Hajda (1):
>   drm/i915/selftests: fix subtraction overflow bug
> 
> Chris Wilson (6):
>   drm/i915/selftests: Grab the runtime pm in shrink_thp
>   drm/i915/gt: Serialize GRDOM access between multiple engine
> resets
>   drm/i915/gt: Serialize TLB invalidates with GT resets
>   drm/i915/gem: Look for waitboosting across the whole object
> prior to individual waits
>   drm/i915: Bump GT idling delay to 2 jiffies
>   drm/i915/gt: Only kick the signal worker if there's been an
> update
> 
> Dan Carpenter (1):
>   drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
> 
> Daniele Ceraolo Spurio (1):
>   drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
> 
> Gustavo Sousa (1):
>   drm/i915/pvc: Implement w/a 16016694945
> 
> Matt Roper (4):
>   drm/i915: DG2 and ATS-M device ID updates
>   drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
>   drm/i915/dg2: Add Wa_15010599737
>   drm/i915: Correct ss -> steering calculation for pre-Xe_HP
> platforms
> 
> Matthew Auld (15):
>   drm/doc: add rfc section for small BAR uapi
>   drm/i915/uapi: add probed_cpu_visible_size
>   drm/i915/uapi: expose the avail tracking
>   drm/i915: remove intel_memory_region avail
>   drm/i915/uapi: apply ALLOC_GPU_ONLY by default
>   drm/i915/uapi: add NEEDS_CPU_ACCESS hint
>   drm/i915/error: skip non-mappable pages
>   drm/i915/uapi: tweak error capture on recoverable contexts
>   drm/i915/selftests: skip the mman tests for 

Re: [Intel-gfx] [PATCH] drm/i915: Fix 32-bit build

[Vivi, Rodrigo]

On Sun, 2022-07-17 at 09:20 -0700, Guenter Roeck wrote:
> Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
> introduces
> an additional parameter to i915_rsgt_from_mm_node(). The parameter is
> used
> to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
> divisor. So far segment_pages was a constant and handled without
> divide
> operation. Since it is no longer constant, a divide operation is now
> necessary. This results in build errors on 32-bit builds.
> 
> x86_64-linux-ld: drivers/gpu/drm/i915/i915_scatterlist.o:
> in function `i915_rsgt_from_mm_node':
> i915_scatterlist.c:(.text+0x196): undefined reference to `__udivdi3'
> 
> Fix the problem by using DIV_ROUND_UP_ULL() instead of
> DIV_ROUND_UP().
> 
> Fixes: aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
> Cc: Matthew Auld 
> Cc: Nirmoy Das 
> Cc: Rodrigo Vivi 
> Signed-off-by: Guenter Roeck 
> ---
> I took a stab at the problem. Please ignore the noise if it has
> already
> been fixed with a different patch.

Thanks for your patch.

This was actually fixed already in our -next branches, but missed
on the fixes:

https://patchwork.freedesktop.org/patch/493637/?series=106260=1

Thanks,
Rodrigo.


> 
>  drivers/gpu/drm/i915/i915_scatterlist.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
> b/drivers/gpu/drm/i915/i915_scatterlist.c
> index f63b50b71e10..b81d5658c222 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.c
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.c
> @@ -96,7 +96,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const
> struct drm_mm_node *node,
>  
> i915_refct_sgt_init(rsgt, node->size << PAGE_SHIFT);
> st = >table;
> -   if (sg_alloc_table(st, DIV_ROUND_UP(node->size,
> segment_pages),
> +   if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size,
> segment_pages),
>    GFP_KERNEL)) {
> i915_refct_sgt_put(rsgt);
> return ERR_PTR(-ENOMEM);

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Load DMC on DG2

[Vivi, Rodrigo]

On Thu, 2022-05-05 at 09:58 -0700, Anusha Srivatsa wrote:
> Add Support for DC states on Dg2.
> 
> v2: Add dc9 as the max supported DC states and disable DC5.
> v3: set max_dc to 0. (Imre)
> 
> Cc: Imre Deak 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Rodrigo Vivi (v1)
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c |  4 +++-
>  drivers/gpu/drm/i915/display/intel_dmc.c   | 10 +-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 1d9bd5808849..15b15f434fcf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -907,7 +907,9 @@ static u32 get_allowed_dc_mask(const struct
> drm_i915_private *dev_priv,
> if (!HAS_DISPLAY(dev_priv))
> return 0;
>  
> -   if (IS_DG1(dev_priv))
> +   if (IS_DG2(dev_priv))
> +   max_dc = 0;

Please add a /* FIXME: */
explaining the DC5 bugs that are under investigation or something like
that... and that DC9 doesn't depend on DMC, but we are loading it
in order to unblock the runtime_pm.

> +   else if (IS_DG1(dev_priv))
> max_dc = 3;
> else if (DISPLAY_VER(dev_priv) >= 12)
> max_dc = 4;
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 257cf662f9f4..2f01aca4d981 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -52,6 +52,10 @@
>  
>  #define DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
>  
> +#define DG2_DMC_PATH   DMC_PATH(dg2, 2, 06)
> +#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 06)
> +MODULE_FIRMWARE(DG2_DMC_PATH);
> +
>  #define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 16)
>  #define ADLP_DMC_VERSION_REQUIRED  DMC_VERSION(2, 16)
>  MODULE_FIRMWARE(ADLP_DMC_PATH);
> @@ -688,7 +692,11 @@ void intel_dmc_ucode_init(struct
> drm_i915_private *dev_priv)
>  */
> intel_dmc_runtime_pm_get(dev_priv);
>  
> -   if (IS_ALDERLAKE_P(dev_priv)) {
> +   if (IS_DG2(dev_priv)) {
> +   dmc->fw_path = DG2_DMC_PATH;
> +   dmc->required_version = DG2_DMC_VERSION_REQUIRED;
> +   dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> +   } else if (IS_ALDERLAKE_P(dev_priv)) {
> dmc->fw_path = ADLP_DMC_PATH;
> dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
> dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;

Re: [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's

[Vivi, Rodrigo]

On Tue, 2022-04-19 at 22:54 -0700, Dixit, Ashutosh wrote:
> On Fri, 15 Apr 2022 03:21:26 -0700, Rodrigo Vivi wrote:
> > On Thu, Apr 14, 2022 at 03:31:07PM -0700, Dixit, Ashutosh wrote:
> > > On Thu, 14 Apr 2022 06:28:57 -0700, Jani Nikula wrote:
> > > > 
> > > > On Wed, 13 Apr 2022, Ashutosh Dixit 
> > > > wrote:
> > > > > Each gt contains an independent instance of pcode. Extend
> > > > > pcode functions
> > > > > to interface with pcode on different gt's. Previous (GT0)
> > > > > pcode read/write
> > > > > interfaces are preserved.
> > > > 
> > > > The big problem here is that this hard couples display code to
> > > > gt code,
> > > > while we're trying hard to go the opposite direction. It
> > > > doesn't matter
> > > > that the existing interfaces are preserved as wrappers when it
> > > > relies on
> > > > an intel_gt being available (via i915->gt0).
> > 
> > I don't believe there is a big problem in here...
> > 
> > please note the intel_pcode.h is keeping the abstraction for
> > display
> > 
> > #define snb_pcode_write_timeout(i915, mbox, val, fast_timeout_us,
> > slow_timeout_ms) \
> >     intel_gt_pcode_write_timeout(&(i915)->gt0, mbox, val,
> > fast_timeout_us, slow_timeout_ms)
> > 
> > #define snb_pcode_write(i915, mbox, val) \
> >     snb_pcode_write_timeout(i915, mbox, val, 500, 0)
> > 
> > display only uses these macros that Ashutosh didn't touch.
> > 
> > > > 
> > > > Note how 'git grep intel_gt -- drivers/gpu/drm/i915/display/'
> > > > matches
> > > > only 1 line.
> > 
> > As well with the patches applied:
> > 
> > $ git log --oneline -1
> > 1f58f1195478 (HEAD -> drm-tip) drm/i915/gt: Expose per-gt RPS
> > defaults in sysfs
> > 
> > $ git grep intel_gt -- drivers/gpu/drm/i915/display/
> > drivers/gpu/drm/i915/display/intel_display.c:  
> > intel_gt_set_wedged(to_gt(dev_priv));
> > 
> > > 
> > > Hi Jani, would you have suggestions about how to do this (handle
> > > pcode on
> > > multiple gt's)? The thinking was this patch would be a
> > > straightforward way
> > > to avoid code duplication. Also:
> > 
> > Maybe it is just a matter of renaming the macros used by display
> > in intel_pcode.h to reflect that it should be used by display only?
> 
> In v2 I have added a patch ([PATCH 4/9] drm/i915/gt: Convert callers
> to
> user per-gt pcode functions) which correctly calls per-gt pcode
> functions
> where this is required. With this patch only display functions (and
> one
> other caller) are left calling the "global scope"
> snb_pcode_read/write*
> functions. So the legacy snb_pcode_read/write* are now basically
> being used
> only by display. Let's see if Jani is ok with this. Thanks.

Jani is not happy with this abstraction because it still creates some
dependency and also no with the name intel_gt_pcode_ in the
functions...

He has some valid points.

I believe the right way to do this is to keep intel_pcode totally clean
from intel_gt and only receive intel_uncore as the argument. Then, if
needed we create display/intel_display_pcode and/or gt/intel_gt_pcode
with the needed abstractions... but better with none I'd say.

Re: [Intel-gfx] [PATCH] drm/i915: Reserving some Multi-thread forcewake bits.

[Vivi, Rodrigo]

On Thu, 2022-04-14 at 14:14 -0700, Matt Roper wrote:
> On Wed, Apr 13, 2022 at 05:39:27PM -0400, Rodrigo Vivi wrote:
> > Bit 0: Currently bit used by i915. Ideally only i915 touches it
> >    in a Linux stack.
> > 
> > Bits 1 and 2: A while ago we were using Bit 1 for i915 and bit 2
> >   for the user space, until commit 7130630323c5
> > ("drm/i915:
> >   Use fallback forcewake if primary ack missing")
> > changed it
> >   to bit 1.
> 
> That commit didn't change the bits, just the notation used to
> describe
> them.  0x1 == BIT(0) and 0x2 == BIT(1) so no functional change.

I could swear I had seen (1 << 1) and (1 << 2)... defining the value
instead of the bit on this file confused me... Glad that that patch
actually fixed this.

> 
> In general userspace shouldn't ever be using forcewake and the very
> few
> exceptions to that rule aren't using the definitions in our kernel
> register header anyway so I don't see much value in trying to reserve
> bits in our kernel header.  I believe the only userspace users of
> forcewake are/were:
> 
>  * The old Intel-specific DDX driver (which has now been replaced by
> the
>    vendor-agnostic xf86-video-modesetting) used to grab forcewake via
>    the command streamer while waiting for scanline on hsw-gen9
> 
>     b[3] = MI_LOAD_REGISTER_IMM | 1;
>     b[4] = 0xa188; /* FORCEWAKE_MT */
>     b[5] = 2 << 16 | 2;
> 
>    So the usage of bit 1 (i.e., 0x2) is hardcoded into the DDX; you'd
>    need to update the DDX itself if you're worried about clashes with
>    pcode on those old platforms.

I don't believe that's the case... so we should be good.

> 
>    Honestly I don't know if the above register update even lands...at
>    least for modern platforms bspec page 45546 doesn't list 0xa188 as
> a
>    register that userspace has permission to update via the command
>    streamer (it would probably be a security concern if it was!), so
>    this old DDX strategy of using an LRI instruction to update the
>    register shouldn't be something we even need to consider going
>    forward.
> 
>  * debug tools like intel_reg that run as root can manipulate
> registers
>    directly, including the forcewake register.  But the bits that get
>    used are up to whoever is running the tool; the definitions in
> i915
>    code don't matter.
> 
>  * There's an "i915_forcewake_user" debugfs entry that holds
> forcewake
>    while userspace holds an open file descriptor on it.  But usage of
>    that debugfs still utilizes the FORCEWAKE_KERNEL bit rather than
> the
>    "userspace" bit.
> 
> Since FORCEWAKE_USER is completely unused by i915, I'd suggest just
> dropping the definition so that people don't even get the bad idea
> that
> manipulating forcewake from userspace is okay.  Just leave
> FORCEWAKE_KERNEL and FORCEWAKE_KERNEL_FALLBACK as the only ones
> defined
> since from our point of view those are the only ones that matter.

I'd like to use this place to keep documented what bits we are
reserving for what cases. So in the future when PCODE or yet another
comment comes and ask who is using what we show this list and they
know what to use or not.

For instance PSMI in older platforms were using bit 12, not it changed
to bit 0...
But I also found out if they change back to bit 12 we might conflict
with a PCODE w/a 

It's unfortunate that this wasn't documented in BSpec and windows
driver and linux are already totally different in the bits usages,
but we need to at least answer what bits in a linux stack we know
to be used by what...

Even if we need to add

DG2_FORCEWAKE_PCODE BIT(12)
PVC_FORCEWAKE_PCODE BIT(1)

etc...


> 
> 
> Matt
> 
> >   Now we have a situation where PCODE is also using
> > this bit-1
> >   in one case, while it should actually be using the
> > Bit-3.
> >   So, let's redirect users back to bit-2 and mark this
> > 1 as
> >   reserved.
> > 
> > Bit 3: Let's reserve for PCODE.
> > 
> > Bit 4: Let's reserve for PSMI.
> > 
> > Cc: Tilak Tangudu 
> > Cc: Mika Kuoppala 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 0a5c2648aaf0..15ceaaace4d9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1399,8 +1399,11 @@
> >  #define FORCEWAKE_MT_ACK   _MMIO(0x130040)
> >  #define FORCEWAKE_ACK_HSW  _MMIO(0x130044)
> >  #define FORCEWAKE_ACK_GT_GEN9  _MMIO(0x130044)
> > -#define   FORCEWAKE_KERNEL BIT(0)
> > -#define   FORCEWAKE_USER   BIT(1)
> > +#define   FORCEWAKE_KERNEL BIT(0) /* For i915
> > use only */
> > +#define   FORCEWAKE_RSVD   BIT(1)
> > 

Re: [Intel-gfx] [PATCH 0/4] drm/i915/dg2: Add support for render/media decompression

[Vivi, Rodrigo]

On Mon, 2022-04-11 at 15:38 +0300, Imre Deak wrote:
> Hi Rodrigo, Jani,
> 
> On Mon, Apr 04, 2022 at 04:38:42PM +0300, Imre Deak wrote:
> > This is a rebased version of patches 15-17 of [1], adding DG2
> > display
> > engine support for decompressing render and media compressed
> > framebuffers.
> > 
> > The dependency patches from [1] should be merged already to drm-
> > tip.
> > 
> > It addresses the review comments on the modifier layout description
> > from
> > Nanley, updates the commit logs vs. flat CCS and Tile4 and splits
> > out
> > the changes adding the modifiers to drm_fourcc.h to separate
> > patches.
> > 
> > [1] https://patchwork.freedesktop.org/series/95686/
> > 
> > Cc: Anshuman Gupta 
> > Cc: Ramalingam C 
> > Cc: Radhakrishna Sripada 
> > Cc: Matt Roper 
> > Cc: Mika Kahola 
> > Cc: Juha-Pekka Heikkilä 
> > Cc: Nanley Chery 
> 
> I'd like to push this patchset to drm-intel-next, but it depends on
> https://patchwork.freedesktop.org/patch/475167/?series=100419=1
> 
> which is only in drm-intel-gt-next. According to Joonas, this should
> be
> resolved by backmerging drm-intel-gt-next to drm-intel-next, could
> you
> help with this?

+Tvrtko.

Jani is taking care of the drm-intel-next this round.
Based on our previous experiences with this kind of conflicts I agree
with Joonas. I also believe it is a good idea to backmerge the -gt-next
when needed.

But whenever we do this wee need to be careful when sending the
drm-intel-next pull request. We should ideally get the -gt-next pull
request merged to drm-next before doing the drm-intel-next PR, so 
we guarantee it was approved already and we also don't duplicate the
commits in the PR.

That sad, the PRs will need to be in sync and the window of -gt-next
should close a bit earlier on begin of -rc5 in case of an existent
backmerge in drm-intel-next... and avoid -rc6 PRs.

> 
> > Anshuman Gupta (1):
> >   drm/i915/dg2: Add support for DG2 clear color compression
> > 
> > Matt Roper (2):
> >   drm/fourcc: Introduce format modifiers for DG2 render and media
> >     compression
> >   drm/i915/dg2: Add support for DG2 render and media compression
> > 
> > Mika Kahola (1):
> >   drm/fourcc: Introduce format modifier for DG2 clear color
> > 
> >  drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
> >  drivers/gpu/drm/i915/display/intel_fb.c   | 53
> > +++
> >  .../drm/i915/display/skl_universal_plane.c    | 49 +--
> > --
> >  include/uapi/drm/drm_fourcc.h | 36 +
> >  4 files changed, 122 insertions(+), 20 deletions(-)
> > 
> > -- 
> > 2.30.2
> > 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for iommu/vt-d: Add RPLS to quirk list to skip TE disabling (rev3)

[Vivi, Rodrigo]

Thank you all.

I had reviewed this patch already in the iommu list.
Now pushed.

Thanks,
Rodrigo.

On Thu, 2022-03-03 at 00:38 +0800, Vudum, Lakshminarayana wrote:
> Filed this issue and reported.
> https://gitlab.freedesktop.org/drm/intel/-/issues/5239
>  
> Lakshmi.
>  
> From: Surendrakumar Upadhyay, TejaskumarX
> 
> Sent: Wednesday, March 2, 2022 5:20 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo ; Meena, Mahesh
> ; Vudum, Lakshminarayana
> 
> Subject: RE: ✗ Fi.CI.IGT: failure for iommu/vt-d: Add RPLS to quirk
> list to skip TE disabling (rev3)
>  
> Regression is not related to the patch. Please mark it pass and
> requesting to merge.
>  
> Thanks,
> Tejas
>  
> From: Patchwork 
> Sent: 02 March 2022 17:56
> To: Surendrakumar Upadhyay, TejaskumarX
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.IGT: failure for iommu/vt-d: Add RPLS to quirk list
> to skip TE disabling (rev3)
>  
> Patch Details
> Series: iommu/vt-d: Add RPLS to quirk list to skip TE disabling
> (rev3) URL: https://patchwork.freedesktop.org/series/100165/ State:
> failure Details: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_22458/index.html CI Bug Log - changes from
> CI_DRM_11308_full -> Patchwork_22458_fullSummaryFAILURE
> Serious unknown changes coming with Patchwork_22458_full absolutely
> need to be
> verified manually.
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_22458_full, please notify your bug team to
> allow them
> to document this new failure mode, which will reduce false positives
> in CI.
> Participating hosts (13 -> 13)No changes in participating hosts
> Possible new issuesHere are the unknown changes that may have been
> introduced in Patchwork_22458_full:
> IGT changesPossible regressions * igt@kms_cursor_legacy@long-
> nonblocking-modeset-vs-cursor-atomic:
> - shard-tglb: PASS -> INCOMPLETE
> SuppressedThe following results come from untrusted machines, tests,
> or statuses.
> They do not affect the overall result.
>  * {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-
> factor-0-5}:
> - {shard-rkl}: NOTRUN -> SKIP +1 similar issue
>  * {igt@kms_plane_scaling@scaler-with-rotation-unity-scaling@pipe-d-
> hdmi-a-3-scaler-with-rotation}:
> - {shard-dg1}: NOTRUN -> SKIP +3 similar issues
> New testsNew tests have been introduced between CI_DRM_11308_full and
> Patchwork_22458_full:
> New IGT tests (1) * igt@kms_plane_scaling@planes-unity-scaling-
> downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
> - Statuses : 1 pass(s)
> - Exec time: [1.28] s
> Known issuesHere are the changes found in Patchwork_22458_full that
> come from known issues:
> CI changesIssues hit * boot:
> - shard-skl: (PASS,PASS, PASS, PASS, PASS, PASS, PASS, PASS,
> PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS,
> PASS, PASS, PASS, PASS) -> (PASS,PASS, PASS, PASS, PASS, PASS, PASS,
> PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, FAIL, PASS,
> PASS, PASS, PASS, PASS, PASS, PASS) ([i915#5032])
> IGT changesIssues hit * igt@gem_ctx_isolation@preservation-s3@vcs0:
> - shard-kbl: PASS -> DMESG-WARN ([i915#180]) +4 similar issues
>  * igt@gem_exec_balancer@parallel-bb-first:
> - shard-tglb: NOTRUN -> DMESG-WARN ([i915#5076])
>  * igt@gem_exec_fair@basic-deadline:
> - shard-skl: NOTRUN -> FAIL ([i915#2846])
>  * igt@gem_exec_fair@basic-none-share@rcs0:
> - shard-iclb: PASS -> FAIL ([i915#2842])
> - shard-glk: PASS -> FAIL ([i915#2842])
>  * igt@gem_exec_fair@basic-pace-solo@rcs0:
> - shard-kbl: PASS -> FAIL ([i915#2842])
>  * igt@gem_exec_whisper@basic-contexts-forked-all:
> - shard-glk: PASS -> DMESG-WARN ([i915#118])
>  * igt@gem_exec_whisper@basic-queues-forked-all:
> - shard-iclb: PASS -> INCOMPLETE ([i915#1895])
>  * igt@gem_lmem_swapping@heavy-verify-random:
> - shard-skl: NOTRUN -> SKIP ([fdo#109271] / [i915#4613]) +1
> similar issue
>  * igt@gem_lmem_swapping@smem-oom:
> - shard-apl: NOTRUN -> SKIP ([fdo#109271] / [i915#4613])
>  * igt@gem_pread@exhaustion:
> - shard-skl: NOTRUN -> WARN ([i915#2658])
>  * igt@gem_pxp@create-regular-context-1:
> - shard-iclb: NOTRUN -> SKIP ([i915#4270]) +1 similar issue
>  * igt@gem_pxp@create-regular-context-2:
> - shard-tglb: NOTRUN -> SKIP ([i915#4270])
>  * igt@gem_render_copy@y-tiled-mc-ccs-to-y-tiled-ccs:
> - shard-iclb: NOTRUN -> SKIP ([i915#768])
>  * igt@gem_userptr_blits@create-destroy-unsync:
> - shard-iclb: NOTRUN -> SKIP ([i915#3297])
>  * igt@gem_userptr_blits@dmabuf-sync:
> - shard-skl: NOTRUN -> SKIP 

Re: [Intel-gfx] [PULL] drm-intel-gt-next

[Vivi, Rodrigo]

On Tue, 2022-02-22 at 11:44 -0800, Lucas De Marchi wrote:
> On Mon, Feb 21, 2022 at 11:21:35AM +0200, Jani Nikula wrote:
> > On Mon, 21 Feb 2022, Dave Airlie  wrote:
> > > On Thu, 17 Feb 2022 at 20:26, Joonas Lahtinen
> > >  wrote:
> > > > 
> > > > Hi Dave & Daniel,
> > > > 
> > > > Here is the first drm-intel-gt-next feature PR towards v5.18.
> > > 
> > > Am I missing some previous drm-intel pull?
> > > 
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:
> > > In function ‘rcs_engine_wa_init’:
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:2051:40:
> > > error: ‘XEHP_DIS_BBL_SYSPIPE’ undeclared (first use in this
> > > function)
> > >  2051 |   wa_masked_en(wal, GEN9_ROW_CHICKEN4,
> > > XEHP_DIS_BBL_SYSPIPE);
> > >   |   
> > > ^~~~
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:2051:40:
> > > note: each undeclared identifier is reported only once for each
> > > function it appears in
> > 
> > There's apparently a silent conflict between changes in drm-intel-
> > next
> > and drm-intel-gt-next. There's a fixup patch in drm-rerere:
> > fixups/drm-intel-gt-next.patch.

With ack from Dave on #dri-devel, I've applied this pull request to
drm-intel-next.

Then I used this big fixup on the merge resolution.

Now I'm going to prepare a drm-intel-next pull request towards drm-
next.

Then for the next rounds we check if we are doing cross merges,
or the other way around and get drm-intel-next into drm-intel-gt-next

Thanks,
Rodrigo.


> yeah, with all header refactors landing in drm-intel-next there were
> quite a few conflict lately. Just taking fixups/drm-intel-gt-
> next.patch
> doesn't fix it though as we'd need to follow the merge order drm-tip
> is
> doing, i.e. first get a pull request for drm-intel-next in, and then
> drm-intel-gt-next. Or the octopus merge
> 
> For this merge only I believe the fixup is:
> 
> git show 064030837c5b:fixups/drm-intel-gt-next.patch | patch
> -p1
> 
> with 064030837c5b being the commit in drm-rerere. Cc'ing Matt Roper
> 
> Lucas De Marchi
> 
> > 
> > We opted to sync the branches via drm-next pulls and backmerges,
> > but I'm
> > afraid that means you'd have to use the fixups when merging. I
> > guess we
> > failed to communicate that. The alternative would've been cross-
> > merges
> > within drm-intel.
> > 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > Dave.
> > > > 
> > > > For DG2 adds subplatform G12, missing workarounds and fixes GuC
> > > > loading on ARM64. C0/D0 stepping info added for RPL-S.
> > > > 
> > > > For uAPI enables support for simple parallel submission with
> > > > execlists which was previously enabled only for GuC.
> > > > 
> > > > Further fixes for PMU metrics when GuC is enabled, better error
> > > > reporting for GuC loading failures. Fix for PXP unbind splat.
> > > > Updates to GuC version 69.0.3 with improvements to GT reset
> > > > scenarios.
> > > > 
> > > > The rest is mostly refactoring of the memory management code,
> > > > as highlights introduction of async unbinding/migration and
> > > > removal of short-term pinning in execbuf.
> > > > 
> > > > Then a few selftest and coding style fixes.
> > > > 
> > > > Regards, Joonas
> > > > 
> > > > ***
> > > > 
> > > > drm-intel-gt-next-2022-02-17:
> > > > 
> > > > UAPI Changes:
> > > > 
> > > > - Weak parallel submission support for execlists
> > > > 
> > > >   Minimal implementation of the parallel submission support for
> > > >   execlists backend that was previously only implemented for
> > > > GuC.
> > > >   Support one sibling non-virtual engine.
> > > > 
> > > > Core Changes:
> > > > 
> > > > - Two backmerges of drm/drm-next for header file
> > > > renames/changes and
> > > >   i915_regs reorganization
> > > > 
> > > > Driver Changes:
> > > > 
> > > > - Add new DG2 subplatform: DG2-G12 (Matt R)
> > > > - Add new DG2 workarounds (Matt R, Ram, Bruce)
> > > > - Handle pre-programmed WOPCM registers for DG2+ (Daniele)
> > > > - Update guc shim control programming on XeHP SDV+ (Daniele)
> > > > - Add RPL-S C0/D0 stepping information (Anusha)
> > > > - Improve GuC ADS initialization to work on ARM64 on dGFX
> > > > (Lucas)
> > > > 
> > > > - Fix KMD and GuC race on accessing PMU busyness (Umesh)
> > > > - Use PM timestamp instead of RING TIMESTAMP for reference in
> > > > PMU with GuC (Umesh)
> > > > - Report error on invalid reset notification from GuC (John)
> > > > - Avoid WARN splat by holding RPM wakelock during PXP unbind
> > > > (Juston)
> > > > - Fixes to parallel submission implementation (Matt B.)
> > > > - Improve GuC loading status check/error reports (John)
> > > > - Tweak TTM LRU priority hint selection (Matt A.)
> > > > - Align the plane_vma to min_page_size of stolen mem (Ram)
> > > > 
> > > > - Introduce vma resources and implement async unbinding
> > > > (Thomas)
> > > > - Use struct 

Re: [Intel-gfx] [PATCH] drm/i915: delete shadow "ret" variable

[Vivi, Rodrigo]

On Fri, 2022-01-28 at 09:36 +0300, Dan Carpenter wrote:
> On Fri, Jan 28, 2022 at 07:20:02AM +0100, Thomas Hellström wrote:
> > On Thu, 2022-01-27 at 17:26 -0500, Rodrigo Vivi wrote:
> > > On Thu, Jan 27, 2022 at 11:51:15AM +0300, Dan Carpenter wrote:
> > > > This "ret" declaration shadows an existing "ret" variable at
> > > > the
> > > > top of
> > > > the function.  Delete it.
> > > > 
> > > > Signed-off-by: Dan Carpenter 
> > > 
> > > Reviewed-by: Rodrigo Vivi 
> > > 
> > > and pushing right now
> > 
> > Should probably have had a Fixes: tag on this one. I'm not 100%

Well, I had added while pushing yesterday... but...

> > sure
> > whether the faulty patch is already upstream. In that case we might
> > need to manually include it in a -fixes pull.
> > 
> 
> It's not really a bug.  It's just a Sparse warning which is disabled
> by default (-Wshadow).  The patch is in linux-next.

Yeap, but it is good to add Fixes so if anyone is backporting the other
patch it is clear that this patch is a good addition on top.

> 
> Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async
> unbinding")

hmm... you are right... this one was the one...

I had added

Fixes: f6c466b84cfa ("drm/i915: Add support for moving fence waiting")

pointing to the original patch that introduced this int ret 
instead of the one that created the duplication...

so my Fixes addition can actually break some backport out there...
But luckily I believe that these 2 patches will be backported together
anyway...

Sorry about the confusion,
Rodrigo.


> 
> regards,
> dan carpenter
> 

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/pxp: Hold RPM wakelock during PXP unbind

[Vivi, Rodrigo]

On Mon, 2022-01-17 at 13:21 +0200, Jani Nikula wrote:
> On Thu, 13 Jan 2022, Rodrigo Vivi  wrote:
> > On Thu, Jan 06, 2022 at 12:02:36PM -0800, Juston Li wrote:
> > > Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock
> > > during
> > > PXP suspend") but to fix the same warning for unbind during
> > > shutdown:
> > > 
> > > [ cut here ]
> > > RPM wakelock ref not held during HW access
> > > WARNING: CPU: 0 PID: 4139 at
> > > drivers/gpu/drm/i915/intel_runtime_pm.h:115
> > > gen12_fwtable_write32+0x1b7/0
> > > Modules linked in: 8021q ccm rfcomm cmac algif_hash
> > > algif_skcipher
> > > af_alg uinput snd_hda_codec_hdmi vf industrialio iwl7000_mac80211
> > > cros_ec_sensorhub lzo_rle lzo_compress zram iwlwifi cfg80211
> > > joydev
> > > CPU: 0 PID: 4139 Comm: halt Tainted: G U  W
> > > 5.10.84 #13 344e11e079c4a03940d949e537eab645f6
> > > RIP: 0010:gen12_fwtable_write32+0x1b7/0x200
> > > Code: 48 c7 c7 fc b3 b5 89 31 c0 e8 2c f3 ad ff 0f 0b e9 04 ff ff
> > > ff c6
> > > 05 71 e9 1d 01 01 48 c7 c7 d67
> > > RSP: 0018:a09ec0bb3bb0 EFLAGS: 00010246
> > > RAX: 12dde97bbd260300 RBX: 000320f0 RCX: 89e60ea0
> > > RDX:  RSI: dfff RDI: 89e60e70
> > > RBP: a09ec0bb3bd8 R08:  R09: a09ec0bb3950
> > > R10: dfff R11: 89e91160 R12: 
> > > R13: 28121969 R14: 9515c32f0990 R15: 4000
> > > FS:  790dcf225740() GS:95173780()
> > > knlGS:
> > > CS:  0010 DS:  ES:  CR0: 80050033
> > > CR2: 58b25efae147 CR3: 000133ea6001 CR4: 00770ef0
> > > DR0:  DR1:  DR2: 
> > > DR3:  DR6: 07f0 DR7: 0400
> > > PKRU: 5554
> > > Call Trace:
> > >  intel_pxp_fini_hw+0x2f/0x39
> > >  i915_pxp_tee_component_unbind+0x1c/0x42
> > >  component_unbind+0x32/0x48
> > >  component_unbind_all+0x80/0x9d
> > >  take_down_master+0x24/0x36
> > >  component_master_del+0x56/0x70
> > >  mei_pxp_remove+0x2c/0x68
> > >  mei_cl_device_remove+0x35/0x68
> > >  device_release_driver_internal+0x100/0x1a1
> > >  mei_cl_bus_remove_device+0x21/0x79
> > >  mei_cl_bus_remove_devices+0x3b/0x51
> > >  mei_stop+0x3b/0xae
> > >  mei_me_shutdown+0x23/0x58
> > >  device_shutdown+0x144/0x1d3
> > >  kernel_power_off+0x13/0x4c
> > >  __se_sys_reboot+0x1d4/0x1e9
> > >  do_syscall_64+0x43/0x55
> > >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x790dcf316273
> > > Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
> > > 44 00
> > > 00 89 fa be 69 19 12 28 bf ad8
> > > RSP: 002b:7ffca0df9198 EFLAGS: 0202 ORIG_RAX:
> > > 00a9
> > > RAX: ffda RBX: 4321fedc RCX: 790dcf316273
> > > RDX: 4321fedc RSI: 28121969 RDI: fee1dead
> > > RBP: 7ffca0df9200 R08: 0007 R09: 563ce8cd8970
> > > R10:  R11: 0202 R12: 7ffca0df9308
> > > R13: 0001 R14:  R15: 0003
> > > ---[ end trace 2f501b01b348f114 ]---
> > > ACPI: Preparing to enter system sleep state S5
> > > reboot: Power down
> > > 
> > > Changes since v1:
> > >  - Rebase to latest drm-tip
> > > 
> > > Fixes: 0cfab4cb3c4e ("drm/i915/pxp: Enable PXP power management")
> > > Suggested-by: Lee Shawn C 
> > > Signed-off-by: Juston Li 
> > > Reviewed-by: Daniele Ceraolo Spurio
> > > 
> > 
> > Reviewed-by: Rodrigo Vivi 
> > 
> > and pushing to drm-intel-next right now.
> > 
> > Thanks for the patch.
> 
> As it happens, this had already been pushed to drm-intel-gt-next by
> John:

doh! (facepalm)
sorry for the mistake this should be really in -gt-next
luckly no conflicts so the propagation should be transparent,
but lesson learned...

> 
> commit 57ded5fc98b11d76dae505ca3591b61c9dbbbda7
> Author: Juston Li 
> AuthorDate: Thu Jan 6 12:02:36 2022 -0800
> Commit: John Harrison 
> CommitDate: Fri Jan 7 15:30:23 2022 -0800
> 
>     drm/i915/pxp: Hold RPM wakelock during PXP unbind
> 
> I don't know if the problem is common enough to warrant more checks.
> It
> does help to reply to the list when one pushes patches, and although
> at
> least I almost always do it, we haven't really made it a requirement
> either.
> 
> 
> BR,
> Jani.
> 
> 
> 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > index 195b2323ec00..4b6f5655fab5 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > @@ -107,9 +107,12 @@ static int
> > > i915_pxp_tee_component_bind(struct device *i915_kdev,
> > >  static void i915_pxp_tee_component_unbind(struct device
> > > *i915_kdev,
> > > 

Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next-queued

[Vivi, Rodrigo]

On Fri, 2022-01-07 at 14:43 +, Wang, Zhi A wrote:
> Hi folks:
> 
> Happy holidays! This pull mostly contains the code re-factors patches
> from Guenter Roeck and Rikard. Also a minor change from Zhenyu.
> 
> Zhi
> 
> The following changes since commit
> 3bfa7d40ce736ffbbfe07127061f54b359ee2b12:
> 
>    drm/i915/dg2: Add support for new DG2-G11 revid 0x5 (2021-08-06
> 09:03:10 -0700)
> 
> are available in the Git repository at:
> 
>    https://github.com/intel/gvt-linux tags/gvt-next-2022-01-07
> 
> for you to fetch changes up to
> d7a8585430f2b6df5960bbc305edcec5a55180f3:

I'm not sure what's going on here, but:

dim: no pull request found

did you do anything different on this round for generating and sending
out this pull request email?

> 
>    drm/i915/gvt: Constify vgpu_types (2021-12-16 09:13:02 -0500)
> 
> 
> Guenter Roeck (1):
>    drm/i915/gvt: Use list_entry to access list members
> 
> Rikard Falkeborn (9):
>    drm/i915/gvt: Constify intel_gvt_gtt_gma_ops
>    drm/i915/gvt: Constify intel_gvt_gtt_pte_ops
>    drm/i915/gvt: Constify intel_gvt_irq_ops
>    drm/i915/gvt: Constify intel_gvt_sched_policy_ops
>    drm/i915/gvt: Constify gvt_mmio_block
>    drm/i915/gvt: Constify cmd_interrupt_events
>    drm/i915/gvt: Constify formats
>    drm/i915/gvt: Constify gtt_type_table_entry
>    drm/i915/gvt: Constify vgpu_types
> 
> Zhenyu Wang (1):
>    drm/i915/gvt: Fix cmd parser error for Passmark9
> 
>   drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 +-
>   drivers/gpu/drm/i915/gvt/dmabuf.c   | 18 +++--
>   drivers/gpu/drm/i915/gvt/fb_decoder.c   | 24 ++--
>   drivers/gpu/drm/i915/gvt/gtt.c  | 68
> -
>   drivers/gpu/drm/i915/gvt/gtt.h  |  4 +-
>   drivers/gpu/drm/i915/gvt/gvt.h  |  2 +-
>   drivers/gpu/drm/i915/gvt/handlers.c | 13 ---
>   drivers/gpu/drm/i915/gvt/interrupt.c    | 10 ++---
>   drivers/gpu/drm/i915/gvt/interrupt.h    |  2 +-
>   drivers/gpu/drm/i915/gvt/sched_policy.c |  2 +-
>   drivers/gpu/drm/i915/gvt/scheduler.h    |  2 +-
>   drivers/gpu/drm/i915/gvt/vgpu.c |  4 +-
>   12 files changed, 72 insertions(+), 79 deletions(-)
> 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/gt: Improve "race-to-idle" at low frequencies

[Vivi, Rodrigo]

On Tue, 2021-11-23 at 09:17 +, Tvrtko Ursulin wrote:
> 
> On 22/11/2021 18:44, Rodrigo Vivi wrote:
> > On Wed, Nov 17, 2021 at 02:49:55PM -0800, Vinay Belgaumkar wrote:
> > > From: Chris Wilson 
> > > 
> > > While the power consumption is proportional to the frequency,
> > > there is
> > > also a static draw for active gates. The longer we are able to
> > > powergate
> > > (rc6), the lower the static draw. Thus there is a sweetspot in
> > > the
> > > frequency/power curve where we run at higher frequency in order
> > > to sleep
> > > longer, aka race-to-idle. This is more evident at lower
> > > frequencies, so
> > > let's look to bump the frequency if we think we will benefit by
> > > sleeping
> > > longer at the higher frequency and so conserving power.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Vinay Belgaumkar 
> > > Cc: Tvrtko Ursulin 
> > 
> > Please let's not increase the complexity here, unless we have a
> > very good
> > and documented reason.
> > 
> > Before trying to implement anything smart like this in the driver
> > I'd like
> > to see data, power and performance results in different platforms
> > and with
> > different workloads.
> 
> Who has such test suite and test farm which isn't focused to
> workloads 
> from a single customer? ;(

Okay, maybe we don't need to cover the world here. But without seen any
data at all it is hard to make this call.

> 
> Regards,
> 
> Tvrtko

Re: [Intel-gfx] [PATCH 1/1] drm/i915/rpm: Enable runtime pm autosuspend by default

[Vivi, Rodrigo]

On Thu, 2021-11-11 at 14:42 +0200, Ville Syrjälä wrote:
> On Wed, Nov 10, 2021 at 05:24:22PM -0500, Rodrigo Vivi wrote:
> > On Wed, Nov 10, 2021 at 01:46:46PM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 10, 2021 at 10:59:26AM +0530, Tilak Tangudu wrote:
> > > > Enable runtime pm autosuspend by default for gen12 and
> > > > later versions.
> > > > 
> > > > Signed-off-by: Tilak Tangudu 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > index eaf7688f517d..ef75f24288ef 100644
> > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > @@ -600,6 +600,10 @@ void intel_runtime_pm_enable(struct
> > > > intel_runtime_pm *rpm)
> > > > pm_runtime_use_autosuspend(kdev);
> > > > }
> > > >  
> > > > +   /* XXX: Enable by default only for newer platforms for
> > > > now */
> > > > +   if (GRAPHICS_VER(i915) >= 12)
> > > > +   pm_runtime_allow(kdev);
> > > 
> > > If we change some default then we should just do it across the
> > > board.
> > > There is nothing special about tgl+.
> > 
> > Nothing special with tgl and newer platforms indeed. This is why we
> > have the XXX message here.
> > 
> > The problem in the last attempt was with the gen9 platforms.
> 
> What problem was that?

unfortunately it looks like the logs are not available anymore. :(

Tilak, could you please send this patch without the if?

so we can at
least make sure we spot the differences and see if there's something
quick that we can do about the gen9 or if we should take this path of
gen12, then fix gen9 , then enable eveywhere

> 
> > Apparently some special there, and I didn't want to block the
> > progress while we cannot get to the gen9 bugs.
> > 
> > > 
> > > > +
> > > > /*
> > > >  * The core calls the driver load handler with an RPM
> > > > reference held.
> > > >  * We drop that here and will reacquire it during
> > > > unloading in
> > > > -- 
> > > > 2.25.1
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Revert 'guc_id' from i915_request tracepoint

[Vivi, Rodrigo]

On Wed, 2021-10-27 at 14:15 +0300, Joonas Lahtinen wrote:
+ Jani and Rodrigo in order to pick this to -fixes.

picked up to drm-intel-next-fixes.

thanks,
Rodrigo.


Quoting Patchwork (2021-10-27 13:31:33)
Patch Details

Series:  drm/i915: Revert 'guc_id' from i915_request tracepoint
URL: https://patchwork.freedesktop.org/series/96336/
State:   success
Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21458/index.html

CI Bug Log - changes from CI_DRM_10795 -> Patchwork_21458

Summary

SUCCESS

No regressions found.

Thanks for the review, this is now merged to drm-intel-gt-next.

Regards, Joonas

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

Participating hosts (37 -> 35)

Additional (2): fi-tgl-1115g4 fi-icl-u2
Missing (4): fi-bsw-cyan bat-adlp-4 bat-dg1-6 bat-dg1-5

Known issues

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

IGT changes

Issues hit

  • igt@amdgpu/amd_basic@query-info:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109315)
  • igt@amdgpu/amd_cs_nop@fork-gfx0:

  □ fi-icl-u2: NOTRUN -> SKIP (fdo#109315) +17 similar issues
  • igt@amdgpu/amd_cs_nop@nop-gfx0:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109315 / i915#2575) +16 similar
issues
  • igt@gem_huc_copy@huc-copy:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#2190)

  □ fi-icl-u2: NOTRUN -> SKIP (i915#2190)

  • igt@i915_pm_backlight@basic-brightness:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#1155)
  • igt@i915_selftest@live@execlists:

  □ fi-bsw-n3050: PASS -> INCOMPLETE (i915#2940)
  • igt@kms_chamelium@common-hpd-after-suspend:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#111827) +8 similar issues
  • igt@kms_chamelium@dp-crc-fast:

  □ fi-bsw-nick: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +8 similar issues
  • igt@kms_chamelium@hdmi-hpd-fast:

  □ fi-icl-u2: NOTRUN -> SKIP (fdo#111827) +8 similar issues
  • igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#4103) +1 similar issue
  • igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:

  □ fi-icl-u2: NOTRUN -> SKIP (fdo#109278) +2 similar issues
  • igt@kms_force_connector_basic@force-load-detect:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109285)

  □ fi-icl-u2: NOTRUN -> SKIP (fdo#109285)

  • igt@kms_psr@primary_mmap_gtt:

  □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#1072) +3 similar issues
  • igt@prime_vgem@basic-fence-flip:

  □ fi-bsw-nick: NOTRUN -> SKIP (fdo#109271) +57 similar issues
  • igt@prime_vgem@basic-userptr:

  □ fi-icl-u2: NOTRUN -> SKIP (i915#3301)

  □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#3301)

  • igt@runner@aborted:

  □ fi-bsw-n3050: NOTRUN -> FAIL (fdo#109271 / i915#1436 / i915#3428 / i915
#4312)

Possible fixes

  • igt@gem_exec_suspend@basic-s3:

  □ fi-bsw-nick: INCOMPLETE (i915#2369 / i915#3159) -> PASS
  • igt@kms_frontbuffer_tracking@basic:

  □ fi-cfl-8109u: DMESG-FAIL (i915#295) -> PASS
  • igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:

  □ fi-cfl-8109u: DMESG-WARN (i915#295) -> PASS +10 similar issues

Build changes

  • Linux: CI_DRM_10795 -> Patchwork_21458

CI-20190529: 20190529
CI_DRM_10795: 59f3569eebe53403249227d476e81d09c63c0f0c @ git://
anongit.freedesktop.org/gfx-ci/linux
IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ https://
gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21458: b7ef9de627b6edf88489282bddece7a342263c62 @ git://
anongit.freedesktop.org/gfx-ci/linux

== Linux commits ==

b7ef9de627b6 drm/i915: Revert 'guc_id' from i915_request tracepoint

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: fix broken build

[Vivi, Rodrigo]

On Wed, 2021-10-27 at 10:48 +0100, Matthew Auld wrote:
> On Wed, 27 Oct 2021 at 10:44, Jani Nikula
>  wrote:
> > 
> > On Wed, 27 Oct 2021, Matthew Auld 
> > wrote:
> > > On Wed, 27 Oct 2021 at 09:58, Jani Nikula
> > >  wrote:
> > > > 
> > > > On Wed, 27 Oct 2021, Matthew Auld
> > > >  wrote:
> > > > > On Thu, 21 Oct 2021 at 13:54, Matthew Auld
> > > > >  wrote:
> > > > > > 
> > > > > > wbinvd_on_all_cpus() is only defined on x86 it seems, plus
> > > > > > we need to
> > > > > > include asm/smp.h here.
> > > > > > 
> > > > > > Reported-by: kernel test robot 
> > > > > > Signed-off-by: Matthew Auld 
> > > > > > Cc: Thomas Hellström 
> > > > > 
> > > > > Jani, would it make sense to cherry-pick this to -fixes? The
> > > > > offending
> > > > > commit is in drm-next, and there have been a few reports
> > > > > around this.
> > > > > 
> > > > > Fixes: a035154da45d ("drm/i915/dmabuf: add paranoid flush-on-
> > > > > acquire")
> > > > 
> > > > If the Fixes: tag is in place, our tooling will cherry-pick it
> > > > where it
> > > > belongs. (In this case, drm-intel-next-fixes, not drm-intel-
> > > > fixes.)
> > > 
> > > Yeah, I forgot to add the fixes tag here unfortunately.
> > 
> > Already merged? What's the commit id to be cherry-picked? Rodrigo
> > can do
> > it manually.
> 
> Yeah, it was merged to gt-next:
> 
> 777226dac058 ("drm/i915/dmabuf: fix broken build")

picked up to drm-intel-next-fixes

thanks,
Rodrigo.

> 
> > 
> > Note to self, we should set up some way to check which maintainer
> > is
> > responsible for which branches and when.
> > 
> > BR,
> > Jani.
> > 
> > > 
> > > > 
> > > > Cc: Rodrigo who covers drm-intel-next-fixes atm.
> > > > 
> > > > BR,
> > > > Jani.
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 +++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > > > > index 1adcd8e02d29..a45d0ec2c5b6 100644
> > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > > > > @@ -12,6 +12,13 @@
> > > > > >  #include "i915_gem_object.h"
> > > > > >  #include "i915_scatterlist.h"
> > > > > > 
> > > > > > +#if defined(CONFIG_X86)
> > > > > > +#include 
> > > > > > +#else
> > > > > > +#define wbinvd_on_all_cpus() \
> > > > > > +   pr_warn(DRIVER_NAME ": Missing cache flush in
> > > > > > %s\n", __func__)
> > > > > > +#endif
> > > > > > +
> > > > > >  I915_SELFTEST_DECLARE(static bool
> > > > > > force_different_devices;)
> > > > > > 
> > > > > >  static struct drm_i915_gem_object *dma_buf_to_obj(struct
> > > > > > dma_buf *buf)
> > > > > > --
> > > > > > 2.26.3
> > > > > > 
> > > > 
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
> > 
> > --
> > Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Enable runtime pm autosuspend by default

[Vivi, Rodrigo]

On Mon, 2021-09-13 at 16:27 +0530, Gupta, Anshuman wrote:
> 
> 
> > -Original Message-
> > From: Vivi, Rodrigo 
> > Sent: Friday, September 10, 2021 11:15 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Vivi, Rodrigo ; Daniel Vetter
> > ; David Weinehall
> > ;
> > Tangudu, Tilak ; Deak, Imre
> > ;
> > Gupta, Anshuman 
> > Subject: [PATCH 3/3] drm/i915: Enable runtime pm autosuspend by
> > default
> > 
> > Let's enable runtime pm autosuspend by default everywhere.
> > 
> > But at this time let's not touch the autosuspend_delay time, what
> > caused some
> > regression on our previous attempt.
> > 
> > v2: CI on some gen9 platforms was not clean. But it came
> >     pretty clean on newer generations. For now, let's
> >     pick gen12 and newer. We will return later to extend
> >     that to older platforms.
> > 
> > Cc: Daniel Vetter 
> > Cc: David Weinehall 
> > Cc: Tilak Tangudu 
> > Cc: Imre Deak 
> > Signed-off-by: Rodrigo Vivi 
> > Reviewed-by: Anshuman Gupta  #v1
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index f28b5bab61b4..f91a04c3ef14 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -605,6 +605,10 @@ void intel_runtime_pm_enable(struct
> > intel_runtime_pm *rpm)
> > pm_runtime_use_autosuspend(kdev);
> > }
> > 
> > +   /* XXX: Enable by default only for newer platforms for now
> > */
> > +   if (GRAPHICS_VER(i915) >= 12)
> > +   pm_runtime_allow(kdev);
> Reviewed-by: Anshuman Gupta 
> Looks good to me.
> Br,
> Anshuman Gupta.

Not so fast though :(
We found some bugs on DG2. Tilak will take a look there before we can
push this.

Thanks,
Rodrigo.


> > +
> > /*
> >  * The core calls the driver load handler with an RPM
> > reference held.
> >  * We drop that here and will reacquire it during unloading
> > in
> > --
> > 2.31.1
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Disallow D3Cold.

[Vivi, Rodrigo]

On Mon, 2021-09-13 at 16:22 +0530, Gupta, Anshuman wrote:
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf
> > Of Rodrigo
> > Vivi
> > Sent: Friday, September 10, 2021 11:15 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Vivi, Rodrigo ; Tangudu, Tilak
> > ; Deak, Imre 
> > Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Disallow D3Cold.
> > 
> > During runtime or s2idle suspend and resume cases on discrete
> > cards, if D3Cold
> > is really achieved, we will blow everything up and freeze the
> > machine because
> > we are not yet handling the pci states properly.
> > 
> > On Integrated it simply doesn't matter because D3hot is the maximum
> > that we
> > will get anyway, unless the system is on S3/S4 and our power is
> > cut.
> > 
> > Let's put this hammer for now everywhere. So we can work to enable
> > the auto-
> > suspend by default without blowing up the world.
> > 
> > Then, this should be removed when we finally fix the D3Cold flow.
> > 
> > Cc: Tilak Tangudu 
> > Signed-off-by: Rodrigo Vivi 
> > Acked-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index a40b5d806321..086a9a475ce8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -301,6 +301,7 @@ static void sanitize_gpu(struct
> > drm_i915_private *i915)
> >   */
> >  static int i915_driver_early_probe(struct drm_i915_private
> > *dev_priv)  {
> > +   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> > int ret = 0;
> > 
> > if (i915_inject_probe_failure(dev_priv))
> > @@ -331,6 +332,13 @@ static int i915_driver_early_probe(struct
> > drm_i915_private *dev_priv)
> > if (ret < 0)
> > return ret;
> > 
> > +   /*
> > +    * FIXME: Temporary hammer to avoid freezing the machine on
> > our
> > DGFX
> > +    * This should be totally removed when we handle the pci
> > states
> > properly
> > +    * on runtime PM and on s2idle cases.
> > +    */
> > +   pci_d3cold_disable(pdev);
> This still doesn't protect, if user space enables d3cold via
> sys-fs.
> d3cold_allowed_store() may call pci_d3cold_enable()
> Is it possible to disable it via PCI PM Caps at early probe?
> Otherwise it should done in respective suspend callback to
> make sure
> d3cold is disabled.

Well, I'm not too concerned about the case that user goes and tweak
something that he shouldn't. In especial a temporary hack like this,
and with us actively working to remove that.

However you have a point and Tilak also is trying to convince me that
his version which disables it on the relevant suspend paths and re-
enables it on the resume is safer for s3 and s4.

I'm also not fully convinced there becasue on s3/s4 we lose power
ayways, however I'm not going to be stubborn and listen to both of you
;)

Please let's go with Tilak's version.

I just believe that we need a way with a temporary kernel parameter to
be able to allow d3cold on rpm and s2idle so while we are working to
fix d3cold paths properly.

Thanks,
Rodrigo.

> 
> Thanks,
> Anshuman Gupta.
> > +
> > ret = vlv_suspend_init(dev_priv);
> > if (ret < 0)
> > goto err_workqueues;
> > --
> > 2.31.1
> 

Re: [Intel-gfx] [PATCH 4/5] drm/i915/display: stop returning errors from debugfs registration

[Vivi, Rodrigo]

On Wed, 2021-09-01 at 20:02 +0300, Jani Nikula wrote:
> On Wed, 01 Sep 2021, Rodrigo Vivi  wrote:
> > On Mon, Aug 30, 2021 at 03:53:43PM +0300, Jani Nikula wrote:
> > > Failures to register debugfs should be ignored anyway, so stop
> > > propagating errors altogether for clarity and simplicity. No
> > > functional
> > > changes.
> > 
> > not even a drm_debug if that fails?
> 
> *shrug* the only error we were returning anyway was if debugfs hadn't
> been added at the drm level.

oh, indeed...
Reviewed-by: Rodrigo Vivi 

> 
> BR,
> Jani.
> 
> > 
> > > 
> > > Signed-off-by: Jani Nikula 
> > > ---
> > >  .../drm/i915/display/intel_display_debugfs.c  | 19 +
> > > --
> > >  .../drm/i915/display/intel_display_debugfs.h  |  8 
> > >  2 files changed, 9 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index c1cd5d005e08..845e2dc76f87 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -2443,17 +2443,15 @@ static const struct file_operations
> > > i915_dsc_bpp_fops = {
> > >   *
> > >   * Cleanup will be done by drm_connector_unregister() through a
> > > call to
> > >   * drm_debugfs_connector_remove().
> > > - *
> > > - * Returns 0 on success, negative error codes on error.
> > >   */
> > > -int intel_connector_debugfs_add(struct drm_connector *connector)
> > > +void intel_connector_debugfs_add(struct drm_connector
> > > *connector)
> > >  {
> > > struct dentry *root = connector->debugfs_entry;
> > > struct drm_i915_private *dev_priv = to_i915(connector-
> > > >dev);
> > >  
> > > /* The connector must have been registered beforehands.
> > > */
> > > if (!root)
> > > -   return -ENODEV;
> > > +   return;
> > >  
> > > if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> > > {
> > > debugfs_create_file("i915_panel_timings",
> > > S_IRUGO, root,
> > > @@ -2493,23 +2491,16 @@ int intel_connector_debugfs_add(struct
> > > drm_connector *connector)
> > >     connector->connector_type ==
> > > DRM_MODE_CONNECTOR_HDMIB)
> > > debugfs_create_file("i915_lpsp_capability", 0444,
> > > root,
> > >     connector,
> > > _lpsp_capability_fops);
> > > -
> > > -   return 0;
> > >  }
> > >  
> > >  /**
> > >   * intel_crtc_debugfs_add - add i915 specific crtc debugfs files
> > >   * @crtc: pointer to a drm_crtc
> > >   *
> > > - * Returns 0 on success, negative error codes on error.
> > > - *
> > >   * Failure to add debugfs entries should generally be ignored.
> > >   */
> > > -int intel_crtc_debugfs_add(struct drm_crtc *crtc)
> > > +void intel_crtc_debugfs_add(struct drm_crtc *crtc)
> > >  {
> > > -   if (!crtc->debugfs_entry)
> > > -   return -ENODEV;
> > > -
> > > -   crtc_updates_add(crtc);
> > > -   return 0;
> > > +   if (crtc->debugfs_entry)
> > > +   crtc_updates_add(crtc);
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> > > index 557901f3eb90..c72e35ecba1f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> > > @@ -12,12 +12,12 @@ struct drm_i915_private;
> > >  
> > >  #ifdef CONFIG_DEBUG_FS
> > >  void intel_display_debugfs_register(struct drm_i915_private
> > > *i915);
> > > -int intel_connector_debugfs_add(struct drm_connector
> > > *connector);
> > > -int intel_crtc_debugfs_add(struct drm_crtc *crtc);
> > > +void intel_connector_debugfs_add(struct drm_connector
> > > *connector);
> > > +void intel_crtc_debugfs_add(struct drm_crtc *crtc);
> > >  #else
> > >  static inline void intel_display_debugfs_register(struct
> > > drm_i915_private *i915) {}
> > > -static inline int intel_connector_debugfs_add(struct
> > > drm_connector *connector) { return 0; }
> > > -static inline int intel_crtc_debugfs_add(struct drm_crtc *crtc)
> > > { return 0; }
> > > +static inline void intel_connector_debugfs_add(struct
> > > drm_connector *connector) {}
> > > +static inline void intel_crtc_debugfs_add(struct drm_crtc *crtc)
> > > {}
> > >  #endif
> > >  
> > >  #endif /* __INTEL_DISPLAY_DEBUGFS_H__ */
> > > -- 
> > > 2.20.1
> > > 
> 

Re: [Intel-gfx] [GIT PULL] drm-misc + drm-intel: Add support for out-of-band hotplug notification

[Vivi, Rodrigo]

On Thu, 2021-08-26 at 10:23 +0200, Maxime Ripard wrote:
> On Wed, Aug 25, 2021 at 04:03:43PM +0000, Vivi, Rodrigo wrote:
> > On Tue, 2021-08-24 at 18:48 +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 8/24/21 10:45 AM, Jani Nikula wrote:
> > > > On Fri, 20 Aug 2021, Hans de Goede  wrote:
> > > > > Hello drm-misc and drm-intel maintainers,
> > > > > 
> > > > > My "Add support for out-of-band hotplug notification"
> > > > > patchset:
> > > > > https://patchwork.freedesktop.org/series/93763/
> > > > > 
> > > > > Is ready for merging now, as discussed on IRC I based this
> > > > > series
> > > > > on top drm-tip and when trying to apply the i915 parts on top
> > > > > of drm-misc this fails due to conflict.
> > > > > 
> > > > > So as Jani suggested here is a pull-req for a topic-branch
> > > > > with
> > > > > the
> > > > > entire set, minus the troublesome i915 bits. Once this has
> > > > > been
> > > > > merged
> > > > > into both drm-misc-next and drm-intel-next I can push the 2
> > > > > i915
> > > > > patch do drm-intel-next on top of the merge.
> > > > > 
> > > > > Note there are also 2 drivers/usb/typec patches in here these
> > > > > have Greg KH's Reviewed-by for merging through the drm tree,
> > > > > Since this USB code does not change all that much. I also
> > > > > checked
> > > > > and the drm-misc-next-2021-08-12 base of this tree contains
> > > > > the
> > > > > same last commit to the modified file as usb-next.
> > > > > 
> > > > > Daniel Vetter mentioned on IRC that it might be better for
> > > > > you to
> > > > > simply
> > > > > pick-up the series directly from patchwork, that is fine too
> > > > > in
> > > > > that
> > > > > case don't forget to add:
> > > > > 
> > > > > Reviewed-by: Lyude Paul 
> > > > > 
> > > > > To the entire series (given in a reply to the cover-letter)
> > > > > 
> > > > > And:
> > > > > 
> > > > > Reviewed-by: Greg Kroah-Hartman 
> > > > > 
> > > > > To the usb/typec patches (patch 7/8), this was given in reply
> > > > > to a previous posting of the series and I forgot to add this
> > > > > in the resend.
> > > > 
> > > > Since this is mostly touching drm core, I think it should be
> > > > merged
> > > > to
> > > > drm-misc-next first, and drm-intel-next after. Please let us
> > > > know.
> > > 
> > > I agree this should go to drm-misc-next first.
> > > 
> > > (I was planning on pushing this to drm-misc-next myself,
> > > but then ended up going with the topic branch because of the
> > > conflict in the i915 bits.)
> > 
> > Just to be clear and avoid confusion: This pull request does apply
> > cleanly on drm-misc-next nd drm-intel-next right now.
> > 
> > I'm just waiting for drm-misc-next maintainers to pull this to drm-
> > misc-next so I can pull it to drm-intel-next.
> > 
> > Maxime, is that your round now?
> > or Thomas?
> 
> That's me, I just pushed it to drm-misc-next

Thank you!
I also pushed to drm-intel-next.

> 
> Thanks!
> Maxime

Re: [Intel-gfx] [GIT PULL] drm-misc + drm-intel: Add support for out-of-band hotplug notification

[Vivi, Rodrigo]

On Tue, 2021-08-24 at 18:48 +0200, Hans de Goede wrote:
> Hi,
> 
> On 8/24/21 10:45 AM, Jani Nikula wrote:
> > On Fri, 20 Aug 2021, Hans de Goede  wrote:
> > > Hello drm-misc and drm-intel maintainers,
> > > 
> > > My "Add support for out-of-band hotplug notification" patchset:
> > > https://patchwork.freedesktop.org/series/93763/
> > > 
> > > Is ready for merging now, as discussed on IRC I based this series
> > > on top drm-tip and when trying to apply the i915 parts on top
> > > of drm-misc this fails due to conflict.
> > > 
> > > So as Jani suggested here is a pull-req for a topic-branch with
> > > the
> > > entire set, minus the troublesome i915 bits. Once this has been
> > > merged
> > > into both drm-misc-next and drm-intel-next I can push the 2 i915
> > > patch do drm-intel-next on top of the merge.
> > > 
> > > Note there are also 2 drivers/usb/typec patches in here these
> > > have Greg KH's Reviewed-by for merging through the drm tree,
> > > Since this USB code does not change all that much. I also checked
> > > and the drm-misc-next-2021-08-12 base of this tree contains the
> > > same last commit to the modified file as usb-next.
> > > 
> > > Daniel Vetter mentioned on IRC that it might be better for you to
> > > simply
> > > pick-up the series directly from patchwork, that is fine too in
> > > that
> > > case don't forget to add:
> > > 
> > > Reviewed-by: Lyude Paul 
> > > 
> > > To the entire series (given in a reply to the cover-letter)
> > > 
> > > And:
> > > 
> > > Reviewed-by: Greg Kroah-Hartman 
> > > 
> > > To the usb/typec patches (patch 7/8), this was given in reply
> > > to a previous posting of the series and I forgot to add this
> > > in the resend.
> > 
> > Since this is mostly touching drm core, I think it should be merged
> > to
> > drm-misc-next first, and drm-intel-next after. Please let us know.
> 
> I agree this should go to drm-misc-next first.
> 
> (I was planning on pushing this to drm-misc-next myself,
> but then ended up going with the topic branch because of the
> conflict in the i915 bits.)

Just to be clear and avoid confusion: This pull request does apply
cleanly on drm-misc-next nd drm-intel-next right now.

I'm just waiting for drm-misc-next maintainers to pull this to drm-
misc-next so I can pull it to drm-intel-next.

Maxime, is that your round now?
or Thomas?

Thanks,
Rodrigo.

> 
> Regards,
> 
> Hans
> 
> 
> 
> > > The following changes since commit
> > > c7782443a88926a4f938f0193041616328cf2db2:
> > > 
> > >   drm/bridge: ti-sn65dsi86: Avoid creating multiple connectors
> > > (2021-08-12 09:56:09 -0700)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git
> > > drm-misc-intel-oob-hotplug-v1
> > > 
> > > for you to fetch changes up to
> > > 7f811394878535ed9a6849717de8c2959ae38899:
> > > 
> > >   usb: typec: altmodes/displayport: Notify drm subsys of hotplug
> > > events (2021-08-20 12:35:59 +0200)
> > > 
> > > 
> > > Topic branch for drm-misc / drm-intel for OOB hotplug support for
> > > Type-C connectors
> > > 
> > > 
> > > Hans de Goede (6):
> > >   drm/connector: Give connector sysfs devices there own
> > > device_type
> > >   drm/connector: Add a fwnode pointer to drm_connector and
> > > register with ACPI (v2)
> > >   drm/connector: Add drm_connector_find_by_fwnode() function
> > > (v3)
> > >   drm/connector: Add support for out-of-band hotplug
> > > notification (v3)
> > >   usb: typec: altmodes/displayport: Make dp_altmode_notify()
> > > more generic
> > >   usb: typec: altmodes/displayport: Notify drm subsys of
> > > hotplug events
> > > 
> > >  drivers/gpu/drm/drm_connector.c  | 79
> > > +
> > >  drivers/gpu/drm/drm_crtc_internal.h  |  2 +
> > >  drivers/gpu/drm/drm_sysfs.c  | 87
> > > +++-
> > >  drivers/usb/typec/altmodes/Kconfig   |  1 +
> > >  drivers/usb/typec/altmodes/displayport.c | 58 +-
> > > ---
> > >  include/drm/drm_connector.h  | 25 +
> > >  6 files changed, 217 insertions(+), 35 deletions(-)
> > > 
> > 
> 

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Make workaround upper bounds exclusive

[Vivi, Rodrigo]

On Tue, 2021-08-10 at 15:58 +0300, Jani Nikula wrote:
> On Mon, 19 Jul 2021, "Souza, Jose"  wrote:
> > On Fri, 2021-07-16 at 22:14 -0700, Matt Roper wrote:
> > > Workarounds are documented in the bspec with an exclusive upper
> > > bound
> > > (i.e., a "fixed" stepping that no longer needs the workaround). 
> > > This
> > > makes our driver's use of an inclusive upper bound for stepping
> > > ranges
> > > confusing; the differing notation between code and bspec makes it
> > > very
> > > easy for mistakes to creep in.
> > > 
> > > Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over
> > > to use
> > > an exclusive upper bound like the bspec does.  This also has the
> > > benefit
> > > of helping make sure workarounds are properly handled for new
> > > minor
> > > steppings that show up (e.g., an A1 between the A0 and B0 we
> > > already
> > > knew about) --- if the new intermediate stepping pulls in
> > > hardware fixes
> > > early, there will be an update to the workaround definition which
> > > lets
> > > us know we need to change our code.  If the new stepping does not
> > > pull a
> > > hardware fix earlier, then the new stepping will already be
> > > captured
> > > properly by the "[begin, fix)" range in the code.
> > > 
> > > We'll probably need to be extra vigilant in code review of new
> > > workarounds for the near future to make sure developers notice
> > > the new
> > > semantics of workaround bounds.  But we just migrated a bunch of
> > > our
> > > platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so
> > > people
> > > are already adjusting to the new macros and now is a good time to
> > > make
> > > this change too.
> > > 
> > > Signed-off-by: Matt Roper 
> 
> It's been merged already, but I think this is a good example of a
> patch
> where simple review is just not enough. Needs maintainers in Cc and
> acks
> on top.

I agree. But I like the approach of getting this aligned with all other
internal tools we have to track w/a.
late-acked-by me...

> 
> BR,
> Jani.
> 
> 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cdclk.c    |  2 +-
> > >  .../drm/i915/display/intel_display_power.c    |  8 +++---
> > >  drivers/gpu/drm/i915/display/intel_psr.c  | 18 ++--
> > >  .../drm/i915/display/skl_universal_plane.c    |  8 +++---
> > >  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  2 +-
> > >  drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  2 +-
> > >  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 28 +
> > > --
> > >  drivers/gpu/drm/i915/i915_drv.h   |  4 +--
> > >  drivers/gpu/drm/i915/intel_device_info.c  |  2 +-
> > >  drivers/gpu/drm/i915/intel_pm.c   |  8 +++---
> > >  10 files changed, 41 insertions(+), 41 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 71067a62264d..944fb13b9d98 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2879,7 +2879,7 @@ void intel_init_cdclk_hooks(struct
> > > drm_i915_private *dev_priv)
> > > dev_priv->display.modeset_calc_cdclk =
> > > bxt_modeset_calc_cdclk;
> > > dev_priv->display.calc_voltage_level =
> > > tgl_calc_voltage_level;
> > > /* Wa_22011320316:adl-p[a0] */
> > > -   if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0,
> > > STEP_A0))
> > > +   if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0,
> > > STEP_B0))
> > > dev_priv->cdclk.table =
> > > adlp_a_step_cdclk_table;
> > > else
> > > dev_priv->cdclk.table = adlp_cdclk_table;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index e3aaf9678b07..bec380e58f40 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -5799,10 +5799,10 @@ static void tgl_bw_buddy_init(struct
> > > drm_i915_private *dev_priv)
> > > int config, i;
> > >  
> > > if (IS_ALDERLAKE_S(dev_priv) ||
> > > -   IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > > -   IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > > -   IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > > -   /* Wa_1409767108:tgl,rkl,dg1,adl-s */
> > > +   IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > +   IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > +   IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0))
> > > +   /* Wa_1409767108:tgl,dg1,adl-s */
> > > table = wa_1409767108_buddy_page_masks;
> > > else
> > > table = tgl_buddy_page_masks;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 

Re: [Intel-gfx] [PATCH 25/25] drm/i915: finish removal of CNL

[Vivi, Rodrigo]

On Wed, 2021-07-28 at 17:32 -0700, Lucas De Marchi wrote:
> On Wed, Jul 28, 2021 at 02:59:46PM -0700, Lucas De Marchi wrote:
> > With all the users removed, finish removing the CNL platform
> > definitions.
> > We will leave the PCI IDs around as those are exposed to userspace.
> > Even if mesa doesn't support CNL anymore, let's avoid build
> > breakages
> > due to changing the headers.
> > 
> > Also, due to drm/i915/gt still using IS_CANNONLAKE() let's just
> > redefine
> > it instead of removing.
> 
> +Rodrigo
> 
> Rodrigo, when I was going to merge this patch I noticed it was not
> really possible. IS_CANNONLAKE() is used in drm/i915/gt/ so it can't
> be
> removed if part of the patches are merged in one branch and the other
> part in another.
> 
> I also checked if it would be possible to do this by using a topic
> branch, but that
> gives conflicts when trying to use the merge base. So, I re-submitted
> the series split in 2: one for drm-intel-next and another for
> drm-intel-gt-next. Here instead of removing IS_CANNONLAKE() I only
> redefine it to 0.  I'm keeping your previous r-b below, but please
> let
> me know if all above is fine and your r-b still stands.

oh, I had missed this but I saw that and acked already.
All rv-b are still valid!

> 
> thanks
> Lucas De Marchi
> 
> 
> > 
> > Signed-off-by: Lucas De Marchi 
> > Reviewed-by: Rodrigo Vivi 
> > ---
> > drivers/gpu/drm/i915/i915_drv.h  |  8 ++--
> > drivers/gpu/drm/i915/i915_pci.c  | 23 +
> > --
> > drivers/gpu/drm/i915/i915_perf.c |  1 -
> > drivers/gpu/drm/i915/intel_device_info.c |  2 --
> > drivers/gpu/drm/i915/intel_device_info.h |  2 --
> > 5 files changed, 7 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5d5cf5ad0513..6ac90ccbee0b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1380,7 +1380,7 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> > #define IS_GEMINILAKE(dev_priv) IS_PLATFORM(dev_priv,
> > INTEL_GEMINILAKE)
> > #define IS_COFFEELAKE(dev_priv) IS_PLATFORM(dev_priv,
> > INTEL_COFFEELAKE)
> > #define IS_COMETLAKE(dev_priv)  IS_PLATFORM(dev_priv,
> > INTEL_COMETLAKE)
> > -#define IS_CANNONLAKE(dev_priv)IS_PLATFORM(dev_priv,
> > INTEL_CANNONLAKE)
> > +#define IS_CANNONLAKE(dev_priv)0
> > #define IS_ICELAKE(dev_priv)IS_PLATFORM(dev_priv,
> > INTEL_ICELAKE)
> > #define IS_JSL_EHL(dev_priv)(IS_PLATFORM(dev_priv,
> > INTEL_JASPERLAKE) || \
> > IS_PLATFORM(dev_priv,
> > INTEL_ELKHARTLAKE))
> > @@ -1446,8 +1446,6 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> > #define IS_CML_GT2(dev_priv)(IS_COMETLAKE(dev_priv) && \
> >  INTEL_INFO(dev_priv)->gt == 2)
> > 
> > -#define IS_CNL_WITH_PORT_F(dev_priv) \
> > -   IS_SUBPLATFORM(dev_priv, INTEL_CANNONLAKE,
> > INTEL_SUBPLATFORM_PORTF)
> > #define IS_ICL_WITH_PORT_F(dev_priv) \
> > IS_SUBPLATFORM(dev_priv, INTEL_ICELAKE,
> > INTEL_SUBPLATFORM_PORTF)
> > 
> > @@ -1592,9 +1590,7 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> > 
> > /* WaRsDisableCoarsePowerGating:skl,cnl */
> > #define
> > NEEDS_WaRsDisableCoarsePowerGating(dev_priv)\
> > -   (IS_CANNONLAKE(dev_priv)
> > || \
> > -    IS_SKL_GT3(dev_priv)
> > ||\
> > -    IS_SKL_GT4(dev_priv))
> > +   (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > 
> > #define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4)
> > #define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >=
> > 11 || \
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index ec80cd1cd00c..cb4a46174513 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -787,27 +787,13 @@ static const struct intel_device_info
> > cml_gt2_info = {
> > .gt = 2,
> > };
> > 
> > -#define GEN10_FEATURES \
> > -   GEN9_FEATURES, \
> > -   GEN(10), \
> > -   .dbuf.size = 1024 - 4, /* 4 blocks for bypass path
> > allocation */ \
> > -   .display.has_dsc = 1, \
> > -   .has_coherent_ggtt = false, \
> > -   GLK_COLORS
> > -
> > -static const struct intel_device_info cnl_info = {
> > -   GEN10_FEATURES,
> > -   PLATFORM(INTEL_CANNONLAKE),
> > -   .gt = 2,
> > -};
> > -
> > #define GEN11_DEFAULT_PAGE_SIZES \
> > .page_sizes = I915_GTT_PAGE_SIZE_4K | \
> >   I915_GTT_PAGE_SIZE_64K | \
> >   I915_GTT_PAGE_SIZE_2M
> > 
> > #define GEN11_FEATURES \
> > -   GEN10_FEATURES, \
> > +   GEN9_FEATURES, \
> > GEN11_DEFAULT_PAGE_SIZES, \
> > .abox_mask = BIT(0), \
> > .cpu_transcoder_mask = BIT(TRANSCODER_A) |
> > BIT(TRANSCODER_B) | \
> > @@ -830,10 +816,12 @@ static 

Re: [Intel-gfx] [PATCH CI] drm/i915: Initialize err in remap_io_sg()

[Vivi, Rodrigo]

On Mon, 2021-05-17 at 23:31 +0300, Jani Nikula wrote:
> On Mon, 17 May 2021, "Souza, Jose"  wrote:
> > Rodrigo, Jani: So "i915: fix remap_io_sg to verify the pgprot" was
> > not merged into any drm-intel branch, how should I merge this after
> > get CI green
> > light?
> 
> I think Rodrigo should do a backmerge.

done... pushing right now... sorry for the delay

> 
> BR,
> Jani.
> 
> 
> > 
> > On Mon, 2021-05-17 at 13:21 -0700, José Roberto de Souza wrote:
> > > If the do while loop breaks in 'if (!sg_dma_len(sgl))' in the
> > > first
> > > iteration, err is uninitialized causing a wrong call to
> > > zap_vma_ptes().
> > > 
> > > But that is impossible to happen as a scatterlist must have at
> > > least
> > > one valid segment.
> > > Anyways to avoid more reports from static checkers initializing
> > > ret
> > > here.
> > > 
> > > Fixes: b12d691ea5e0 ("i915: fix remap_io_sg to verify the
> > > pgprot")
> > > Reviewed-by: Christoph Hellwig 
> > > Cc: Christoph Hellwig 
> > > Signed-off-by: James Ausmus 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_mm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_mm.c
> > > b/drivers/gpu/drm/i915/i915_mm.c
> > > index 4c8cd08c672d..25576fa73ff0 100644
> > > --- a/drivers/gpu/drm/i915/i915_mm.c
> > > +++ b/drivers/gpu/drm/i915/i915_mm.c
> > > @@ -47,7 +47,7 @@ int remap_io_sg(struct vm_area_struct *vma,
> > > struct scatterlist *sgl, resource_size_t iobase)
> > >  {
> > > unsigned long pfn, len, remapped = 0;
> > > -   int err;
> > > +   int err = 0;
> > >  
> > > /* We rely on prevalidation of the io-mapping to skip
> > > track_pfn(). */
> > > GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) !=
> > > EXPECTED_FLAGS);
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-gt-next

[Vivi, Rodrigo]

On Wed, 2021-01-20 at 14:21 +0200, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2021-01-18 07:07:39)
> > 
> > Hi,
> > 
> > This is GVT next for 5.12 against drm-intel-gt-next which is mostly
> > for cmd parser enhancement which adds extra check on register load
> > depending on initial context and handles vGPU register state
> > accordingly.
> 
> I think we were bit inconclusive on this last time.
> 
> Even if this does not have any dependency to drm-intel-gt-next I can
> pull this to drm-intel-gt-next. The only caveat is that for any -
> fixes,
> there needs to be a backmerge to drm-intel-next.
> 
> Not sure if this is a problem. Do we want to make it a recurring
> practice
> to backmerge drm-intel-gt-next into drm-intel-next after it lands in
> drm-next?
> 
> So to recap: Do we want to pull to drm-intel-next whenever there are
> no
> dependencies to drm-intel-gt-next, to avoid a backmerge?

It looks better indeed...

but how to proceed when we have dependencies? merge on both sides like
the topic branches?

>  Or do we want
> to always do a backmerge in anticipation of -fixes.
> 
> Regards, Joonas
> 
> > Thanks.
> > --
> > The following changes since commit
> > fe7bcfaeb2b775f257348dc7b935f8e80eef3e7d:
> > 
> >   drm/i915/gt: Refactor heartbeat request construction and
> > submission (2020-12-24 18:07:26 +)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux tags/gvt-gt-next-2021-01-18
> > 
> > for you to fetch changes up to
> > 02dd2b12a685944c4d52c569d05f636372a7b6c7:
> > 
> >   drm/i915/gvt: unify lri cmd handler and mmio handlers (2020-12-25
> > 11:16:32 +0800)
> > 
> > 
> > gvt-gt-next-2021-01-18
> > 
> > - GVT cmd parser enhancement against guest context (Yan)
> > 
> > 
> > Yan Zhao (11):
> >   drm/i915/gvt: parse init context to update cmd accessible reg
> > whitelist
> >   drm/i915/gvt: scan VM ctx pages
> >   drm/i915/gvt: filter cmds "srm" and "lrm" in cmd_handler
> >   drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in
> > cmd_handler
> >   drm/i915/gvt: filter cmd "pipe-ctrl" in cmd_handler
> >   drm/i915/gvt: export find_mmio_info
> >   drm/i915/gvt: make width of mmio_attribute bigger
> >   drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCH
> >   drm/i915/gvt: statically set F_CMD_WRITE_PATCH flag
> >   drm/i915/gvt: update F_CMD_WRITE_PATCH flag when parsing init
> > ctx
> >   drm/i915/gvt: unify lri cmd handler and mmio handlers
> > 
> >  drivers/gpu/drm/i915/gvt/cmd_parser.c | 335
> > +++---
> >  drivers/gpu/drm/i915/gvt/cmd_parser.h |   4 +
> >  drivers/gpu/drm/i915/gvt/gvt.h    |  37 +++-
> >  drivers/gpu/drm/i915/gvt/handlers.c   |  15 +-
> >  drivers/gpu/drm/i915/gvt/mmio.h   |   3 +
> >  drivers/gpu/drm/i915/gvt/reg.h    |   2 +
> >  drivers/gpu/drm/i915/gvt/scheduler.c  |  22 ++-
> >  drivers/gpu/drm/i915/gvt/vgpu.c   |   4 +-
> >  8 files changed, 339 insertions(+), 83 deletions(-)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs

[Vivi, Rodrigo]

On Mon, 2021-01-11 at 13:25 -0800, Lucas De Marchi wrote:
> On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote:
> > On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote:
> > > On Mon, 11 Jan 2021, Jani Nikula 
> > > wrote:
> > > > On Fri, 08 Jan 2021, Matt Roper 
> > > > wrote:
> > > > > On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup
> > > > > wrote:
> > > > > > TGL adds another level of indirection for applying WA based
> > > > > > on stepping
> > > > > > information rather than PCI REVID. So change TGL_REVID enum
> > > > > > into
> > > > > > stepping enum and use PCI REVID as index into revid to
> > > > > > stepping table to
> > > > > > fetch correct display and GT stepping for application of
> > > > > > WAs as
> > > > > > suggested by Matt Roper.
> > > > > 
> > > > > So to clarify the goal is to rename "revid" -> "stepping"
> > > > > because the
> > > > > values like "A1," "C0," etc. are't the actual PCI revision
> > > > > ID, but
> > > > > rather descriptions of the stepping of a given IP block; the
> > > > > enum values
> > > > > we use to represent those are arbitrary and don't matter as
> > > > > long as
> > > > > they're monotonically increasing for comparisons.  The PCI
> > > > > revision ID
> > > > > is just the input we use today to deduce what the IP
> > > > > steppings are, and
> > > > > there's talk that we could determine the IP steppings in a
> > > > > different way
> > > > > at some point in the future.
> > > > > 
> > > > > Furthermore, since the same scheme will be used at least for
> > > > > ADL-S, we
> > > > > should drop the "TGL" prefix since there's no need to name
> > > > > these general
> > > > > enum values in a platform-specific manner.
> > > > > 
> > > > > Reviewed-by: Matt Roper 
> > > > > 
> > > > > We should probably make the same kind of change to KBL (and
> > > > > use the same
> > > > > stepping enum) too since it has the same kind of extra
> > > > > indirection as
> > > > > TGL/ADL-S, but we can do that as a followup patch.
> > > > 
> > > > FWIW I have a wip series changing the whole thing to abstract
> > > > steppings
> > > > enums that are shared between platforms, but it's in a bit of
> > > > limbo
> > > > because the previous revid changes were applied to drm-intel-
> > > > gt-next,
> > > > and it's fallen pretty far out of sync with drm-intel-next. All
> > > > of this
> > > > really belongs to drm-intel-next, but can't do that until the
> > > > branches
> > > > sync up again.
> > > 
> > > Btw this series doesn't apply to drm-intel-next either, for the
> > > same
> > > reason, and the ADL-S platform definition and PCI IDs must *not*
> > > be
> > > applied to drm-intel-gt-next.
> > 
> > So to clarify, it looks like we have a bunch of revid changes to
> > the
> > display code that got merged to the gt-next tree but not to the
> > intel-next tree?  Should we be going back and also merging /
> > cherry-picking those over to intel-next since that's where the
> > display
> > changes are supposed to go, or is it too late to do that cleanly at
> > this
> > point?
> 
> it was my mistake to merge them to drm-intel-gt-next. They should
> have
> been in drm-intel-next.
> 
> > 
> > Going forward, what should the general strategy be for stuff like
> > platform definitions and such?  Merge such enablement patches to
> > both
> 
> last time we talked about this was regarding dg1 AFAIR and the
> consensus
> was to create a topic branch and that topic branch to be merged in
> both
> branches. That would avoid having 2 commits in different branches.

Yeap, I believe this is the way to go.

> 
> Not sure if it would work out nicely for getting test on CI though.

create an empty topic branch using dim.

Pre-merge CI with drm-tip. Only if passing and if everything is realy
ready. Push to the topic branch using dim.

Then it will be part of drm-tip already for any subsequential pre-merge
CI...

Then do the pull requests to bot drm-intel-next and drm-intel-gt-next.

After everything is pulled to both places, then delete the topic
branch.

> Since the changes are spread through the codebase, we could very
> easily
> hit a situation that this topic branch creates conflicts for other
> patches getting merged on either drm-intel-next or drm-intel-gt-next.
> 
> +Joonas, +Rodrigo
> 
> Lucas De Marchi
> 
> > intel-next and gt-next at the same time so that the basic
> > definitions
> > are available to both trees?  It seems like the whole split into
> > two
> > trees really isn't working well and is just leading to more
> > mistakes and
> > bottlenecks.  What benefit are we supposed to be getting from this
> > split?
> > 
> > 
> > Matt
> > 
> > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > > 
> > > > My series also completely hides the arrays into a separate .c
> > > > file,
> > > > because the externs with direct array access are turning into
> > > > nightmare. The ARRAY_SIZE() checks rely on the extern
> > > > declaration and
> > > > the actual array definition to have the 

Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time

[Vivi, Rodrigo]

On Mon, 2021-01-11 at 21:38 +, Huang, Sean Z wrote:
> Hello,
> 
> I see, based on Joonas and Rodrigo's feedback.
> 
> I made the modification as below, I will still keep the macro in this
> .c instead of i915_reg.h, and this change will be reflected in rev20.
> 
> /* KCR register definitions */
>  #define KCR_INIT    _MMIO(0x320f0)
> -#define KCR_INIT_MASK_SHIFT (16)
> +
>  /* Setting KCR Init bit is required after system boot */
> -#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) <<
> KCR_INIT_MASK_SHIFT))
> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << 16))

This is not what I asked actually.

I asked to get the BIT(14) to be defined separated, shift defined as
well... and the | and actuall shift operations to be performed in the
code and not in the defines

> 
> Best regards,
> Sean
> 
> -Original Message-
> From: Joonas Lahtinen 
> Sent: Friday, January 8, 2021 3:31 AM
> To: Huang, Sean Z ; 
> Intel-gfx@lists.freedesktop.org; Vivi, Rodrigo <
> rodrigo.v...@intel.com>
> Subject: Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg
> init during the boot time
> 
> Quoting Vivi, Rodrigo (2021-01-07 17:31:36)
> > On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> > > Set the KCR init during the boot time, which is required by
> > > hardware, to allow us doing further protection operation such as
> > > sending commands to GPU or TEE.
> > > 
> > > Signed-off-by: Huang, Sean Z 
> > > ---
> > >  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > index 9bc3c7e30654..f566a4fda044 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > @@ -6,6 +6,12 @@
> > >  #include "intel_pxp.h"
> > >  #include "intel_pxp_context.h"
> > > 
> > > +/* KCR register definitions */
> > 
> > please define this in i915_reg.h
> 
> Generally the trend on the GT side is to contain in a .c file if
> there are no shared users like these. So they should be at this spot,
> yet the rest of the review comments apply.
> 
> The spurious comments should be dropped and like Rodrigo pointed out,
> we should be using the appropriate macros for a masked writes, not
> baking in the #define.
> 
> Regards, Joonas

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce Intel PXP component - Mesa single session (rev19)

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 23:47 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Introduce Intel PXP component - Mesa single session (rev19)
> URL   : https://patchwork.freedesktop.org/series/84620/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> fbdd4e2e287d drm/i915/pxp: Introduce Intel PXP component
> -:119: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #119: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 194 lines checked
> fdb764188c85 drm/i915/pxp: set KCR reg init during the boot time
> 20c2f538fd26 drm/i915/pxp: Implement funcs to create the TEE channel
> -:8: WARNING:TYPO_SPELLING: 'defualt' may be misspelled - perhaps
> 'default'?
> #8: 
> (defualt) session.
>  ^^^
> 
> -:85: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #85: 
> new file mode 100644
> 
> total: 0 errors, 2 warnings, 0 checks, 253 lines checked
> e77ddc43854a drm/i915/pxp: Create the arbitrary session after boot
> -:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #68: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 330 lines checked
> 60d904942ebb drm/i915/pxp: Func to send hardware session termination
> -:53: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #53: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 222 lines checked
> e06c62d5fd8d drm/i915/pxp: Enable PXP irq worker and callback stub
> -:51: WARNING:LONG_LINE_COMMENT: line length of 113 exceeds 100
> columns
> #51: FILE: drivers/gpu/drm/i915/i915_reg.h:7970:
> +#define GEN11_CRYPTO_INTR_MASK _MMIO(0x1900f0) /* crypto
> mask is in bit31-16 (Engine1 Interrupt Mask) */
> 
> total: 0 errors, 1 warnings, 0 checks, 230 lines checked
> 2b451866410d drm/i915/pxp: Destroy arb session upon teardown
> f74cff978a9a drm/i915/pxp: Enable PXP power management
> -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #78: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 148 lines checked
> f45f6bf27787 drm/i915/pxp: Expose session state for display
> protection flip
> ed1733ee9985 mei: pxp: export pavp client to me client bus
> -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #32: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 277 lines checked
> 5ed5ea72d630 drm/i915/uapi: introduce drm_i915_gem_create_ext
> -:12: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Joonas
> Lahtinen joonas.lahti...@linux.intel.com'
> #12: 
> Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com

Please make sure you address some of the checkpatch complains like this

> 
> -:13: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Matthew Auld 
> matthew.a...@intel.com'
> #13: 
> Cc: Matthew Auld matthew.a...@intel.com

this

> 
> -:46: ERROR:CODE_INDENT: code indent should use tabs where possible
> #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265:
> +    struct drm_i915_private *i915;$

this

> 
> -:46: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265:
> +    struct drm_i915_private *i915;$
> 

this


> -:50: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open
> parenthesis
> #50: FILE: drivers/gpu/drm/i915/i915_gem.c:269:
> +static int __create_setparam(struct drm_i915_gem_object_param *args,
> +   struct
> create_ext *ext_data)
> 

this

> -:95: CHECK:LINE_SPACING: Please don't use multiple blank lines
> #95: FILE: drivers/gpu/drm/i915/i915_gem.c:317:
> +
> +

this

> -:107: WARNING:LONG_LINE: line length of 120 exceeds 100 columns
> #107: FILE: include/uapi/drm/i915_drm.h:395:
> +#define DRM_IOCTL_I915_GEM_CREATE_EXT   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_CREATE, struct drm_i915_gem_create_ext)
> 
> -:155: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #155: FILE: include/uapi/drm/i915_drm.h:1736:
> +#define I915_OBJECT_PARAM  (1ull<<32)

this

>  ^
> 
> total: 3 errors, 2 warnings, 3 checks, 136 lines checked
> ae1f0edf901f drm/i915/pxp: User interface for Protected buffer
> 7ce48b165a12 drm/i915/pxp: Add plane decryption support
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v19 12/13] drm/i915/pxp: User interface for Protected buffer

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> From: Bommu Krishnaiah 
> 
> This api allow user mode to create Protected buffer and context
> creation.
> 
> Signed-off-by: Bommu Krishnaiah 
> Cc: Telukuntla Sreedhar 
> Cc: Kondapally Kalyan 
> Cc: Gupta Anshuman 
> Cc: Huang Sean Z 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 19 +--
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |  5 
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  2 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  5 
>  drivers/gpu/drm/i915/i915_gem.c   | 23 +++--
> --
>  include/uapi/drm/i915_drm.h   | 19 +++
>  6 files changed, 66 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 68f58762d5e3..00d7ca3071e7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -81,6 +81,8 @@
>  #include "i915_trace.h"
>  #include "i915_user_extensions.h"
>  
> +#include "pxp/intel_pxp.h"
> +
>  #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
>  
>  static struct i915_global_gem_context {
> @@ -2022,12 +2024,25 @@ static int ctx_setparam(struct
> drm_i915_file_private *fpriv,
> case I915_CONTEXT_PARAM_RECOVERABLE:
> if (args->size)
> ret = -EINVAL;
> -   else if (args->value)
> -   i915_gem_context_set_recoverable(ctx);
> +   else if (args->value) {
> +   if (!i915_gem_context_is_protected(ctx))
> +   i915_gem_context_set_recoverable(ctx)
> ;
> +   else
> +   ret = -EPERM;
> +   }
> else
> i915_gem_context_clear_recoverable(ctx);
> break;
>  
> +   case I915_CONTEXT_PARAM_PROTECTED_CONTENT:

remember that we also need to require recoverable flag to false. It
cannot be implicit.

> +   if (args->size)
> +   ret = -EINVAL;
> +   else if (args->value)
> +   ret =
> intel_pxp_gem_context_set_protected(ctx->i915,
> +
> >user_flags,
> +
> UCONTEXT_PROTECTED);
> +   break;
> +
> case I915_CONTEXT_PARAM_PRIORITY:
> ret = set_priority(ctx, args);
> break;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index b5c908f3f4f2..173154fdc311 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -70,6 +70,11 @@ static inline void
> i915_gem_context_set_recoverable(struct i915_gem_context *ctx
> set_bit(UCONTEXT_RECOVERABLE, >user_flags);
>  }
>  
> +static inline bool i915_gem_context_is_protected(struct
> i915_gem_context *ctx)
> +{
> +   return test_bit(UCONTEXT_PROTECTED, >user_flags);
> +}
> +
>  static inline void i915_gem_context_clear_recoverable(struct
> i915_gem_context *ctx)
>  {
> clear_bit(UCONTEXT_RECOVERABLE, >user_flags);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 1449f54924e0..0917c9431c65 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -134,7 +134,7 @@ struct i915_gem_context {
>  #define UCONTEXT_BANNABLE  2
>  #define UCONTEXT_RECOVERABLE   3
>  #define UCONTEXT_PERSISTENCE   4
> -
> +#define UCONTEXT_PROTECTED 5
> /**
>  * @flags: small set of booleans
>  */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index e2d9b7e1e152..90ac955463f4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -161,6 +161,11 @@ struct drm_i915_gem_object {
> } mmo;
>  
> I915_SELFTEST_DECLARE(struct list_head st_link);
> +   /**
> +    * @user_flags: small set of booleans set by the user
> +    */
> +   unsigned long user_flags;
> +#define I915_BO_PROTECTED BIT(0)
>  
> unsigned long flags;
>  #define I915_BO_ALLOC_CONTIGUOUS BIT(0)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index c53b13c02e59..611a0b5ab51f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -184,7 +184,8 @@ static int
>  i915_gem_create(struct drm_file *file,
> struct intel_memory_region *mr,
> u64 *size_p,
> -   u32 *handle_p)
> +   u32 

Re: [Intel-gfx] [RFC-v19 09/13] drm/i915/pxp: Expose session state for display protection flip

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the intel_pxp_gem_object_status() to allow i915 display
> querying the current PXP session state. In the design, display
> should not perform protection flip on the protected buffers if
> there is no PXP session alive. And Implement the funciton to set
> the protected flag for gem context.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 21 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h | 18 ++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 23d4cfc1fb1f..a28a459532c2 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -158,3 +158,24 @@ void intel_pxp_irq_handler(struct intel_pxp
> *pxp, u16 iir)
> pxp->current_events |= events;
> schedule_work(>irq_work);
>  }
> +
> +bool intel_pxp_gem_object_status(struct drm_i915_private *i915)
> +{
> +   if (i915->gt.pxp.ctx.inited &&
> +   i915->gt.pxp.ctx.flag_display_hm_surface_keys)
> +   return true;
> +   else
> +   return false;
> +}
> +
> +int intel_pxp_gem_context_set_protected(struct drm_i915_private
> *i915,
> +   unsigned long *user_flags,
> +   u32 protected_bit)
> +{
> +   if (!user_flags || !protected_bit ||
> +   !intel_pxp_arb_session_is_in_play(>gt.pxp))
> +   return -EINVAL;
> +
> +   set_bit(protected_bit, user_flags);

This protected_bit should only be set during context creation and never
modified with set_context.

> +   return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index cdaa6ce6fdca..ff1c1c0e720c 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -29,6 +29,8 @@ enum pxp_protection_modes {
> PROTECTION_MODE_ALL
>  };
>  
> +struct drm_i915_private;
> +
>  #ifdef CONFIG_DRM_I915_PXP
>  void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
>  int i915_pxp_teardown_required_callback(struct intel_pxp *pxp);
> @@ -36,6 +38,10 @@ int
> i915_pxp_global_terminate_complete_callback(struct intel_pxp *pxp);
>  
>  void intel_pxp_init(struct intel_pxp *pxp);
>  void intel_pxp_fini(struct intel_pxp *pxp);
> +bool intel_pxp_gem_object_status(struct drm_i915_private *i915);
> +int intel_pxp_gem_context_set_protected(struct drm_i915_private
> *i915,
> +   unsigned long *user_flag,
> +   u32 protected_bit);
>  #else
>  static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16
> iir)
>  {
> @@ -58,6 +64,18 @@ static inline void intel_pxp_init(struct intel_pxp
> *pxp)
>  static inline void intel_pxp_fini(struct intel_pxp *pxp)
>  {
>  }
> +
> +static inline bool intel_pxp_gem_object_status(struct
> drm_i915_private *i915)
> +{
> +   return false;
> +}
> +
> +static inline int intel_pxp_gem_context_set_protected(struct
> drm_i915_private *i915,
> + unsigned long
> *user_flag,
> + u32
> protected_bit)
> +{
> +   return 0;
> +}
>  #endif
>  
>  #endif /* __INTEL_PXP_H__ */

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v19 08/13] drm/i915/pxp: Enable PXP power management

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> software session state was marked as alive after resume. So to
> handle such case, PXP should terminate all the hardware sessions
> and cleanup all the software states after the power cycle.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile  |  1 +
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c  |  4 ++
>  drivers/gpu/drm/i915/i915_drv.c    |  4 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c    | 65
> ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.h    | 31 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  1 +
>  6 files changed, 106 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 5599b92bea9b..7592fc8cbd89 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -265,6 +265,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp_arb.o \
> pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> +   pxp/intel_pxp_pm.o \
> pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index c94e8ac884eb..ae0387e419a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -20,6 +20,7 @@
>  #include "intel_rc6.h"
>  #include "intel_rps.h"
>  #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_pm.h"
>  
>  static void user_forcewake(struct intel_gt *gt, bool suspend)
>  {
> @@ -266,6 +267,8 @@ int intel_gt_resume(struct intel_gt *gt)
>  
> intel_uc_resume(>uc);
>  
> +   intel_pxp_pm_resume(>pxp);
> +
> user_forcewake(gt, false);
>  
>  out_fw:
> @@ -300,6 +303,7 @@ void intel_gt_suspend_prepare(struct intel_gt
> *gt)
> user_forcewake(gt, true);
> wait_for_suspend(gt);
>  
> +   intel_pxp_pm_prepare_suspend(>pxp);
> intel_uc_suspend(>uc);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 207d50226e64..5923db004d9b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@
>  #include "gt/intel_gt_pm.h"
>  #include "gt/intel_rc6.h"
>  
> +#include "pxp/intel_pxp_pm.h"
> +
>  #include "i915_debugfs.h"
>  #include "i915_drv.h"
>  #include "i915_ioc32.h"
> @@ -1338,6 +1340,8 @@ static int i915_drm_resume_early(struct
> drm_device *dev)
>  
> intel_power_domains_resume(dev_priv);
>  
> +   intel_pxp_pm_resume_early(_priv->gt.pxp);
> +
> enable_rpm_wakeref_asserts(_priv->runtime_pm);
>  
> return ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> new file mode 100644
> index ..ebe89262485c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp_pm.h"
> +
> +void intel_pxp_pm_prepare_suspend(struct intel_pxp *pxp)
> +{
> +   if (!pxp->ctx.inited)
> +   return;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   /* Disable PXP-IOCTLs */
> +   pxp->ctx.global_state_in_suspend = true;
> +
> +   mutex_unlock(>ctx.mutex);
> +}
> +
> +void intel_pxp_pm_resume_early(struct intel_pxp *pxp)
> +{
> +   if (!pxp->ctx.inited)
> +   return;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   if (pxp->ctx.global_state_in_suspend) {
> +   /* reset the attacked flag even there was a pending
> */
> +   pxp->ctx.global_state_attacked = false;
> +
> +   pxp->ctx.flag_display_hm_surface_keys = false;
> +   }
> +
> +   mutex_unlock(>ctx.mutex);
> +}
> +
> +int intel_pxp_pm_resume(struct intel_pxp *pxp)
> +{
> +   int ret = 0;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +
> +   if (!pxp->ctx.inited)
> +   return 0;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   /* Re-enable PXP-IOCTLs */
> +   if (pxp->ctx.global_state_in_suspend) {
> +   ret = intel_pxp_arb_terminate_session(pxp);

I'm confused. I was expecting we terminate the session at suspend and
re-stablish at resume. But I'm missing or forgetting something

> +   if (ret) {
> +   drm_err(>i915->drm, "Failed to terminate
> the arb session\n");
> +   goto end;
> +   }
> +
> +   pxp->ctx.global_state_in_suspend = false;
> +   }
> +
> +end:
> +   

Re: [Intel-gfx] [RFC-v19 05/13] drm/i915/pxp: Func to send hardware session termination

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the functions to allow PXP to send a GPU command, in
> order to terminate the hardware session, so hardware can recycle
> this session slot for the next usage.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile  |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   |  13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c   | 158
> +
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h   |  18 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |   4 +
>  5 files changed, 194 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index af9e87e4c63a..5599b92bea9b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -263,6 +263,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_arb.o \
> +   pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 3868e8c697f9..2f63801748f8 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -17,10 +17,23 @@
>  void intel_pxp_init(struct intel_pxp *pxp)
>  {
> struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +   int i;
>  
> if (INTEL_GEN(gt->i915) < 12)
> return;
>  
> +   /* Find the first VCS engine present */
> +   for (i = 0; i < I915_MAX_VCS; i++) {
> +   if (HAS_ENGINE(gt, _VCS(i))) {
> +   pxp->vcs_engine = gt->engine[_VCS(i)];
> +   break;
> +   }
> +   }
> +   if (!pxp->vcs_engine) {
> +   drm_err(>i915->drm, "Could not find a VCS
> engine\n");
> +   return;
> +   }
> +
> intel_pxp_ctx_init(>ctx);
>  
> intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> new file mode 100644
> index ..d9298cf5e1a7
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "intel_pxp_cmd.h"
> +#include "i915_drv.h"
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +struct i915_vma *intel_pxp_cmd_get_batch(struct intel_pxp *pxp,
> +    struct intel_context *ce,
> +    struct
> intel_gt_buffer_pool_node *pool,
> +    u32 *cmd_buf, int
> cmd_size_in_dw)
> +{
> +   struct i915_vma *batch = ERR_PTR(-EINVAL);
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +   u32 *cmd;
> +
> +   if (!ce || !ce->engine || !cmd_buf)
> +   return ERR_PTR(-EINVAL);
> +
> +   if (cmd_size_in_dw * 4 > PAGE_SIZE) {
> +   drm_err(>i915->drm, "Failed to %s, invalid
> cmd_size_id_dw=[%d]\n",
> +   __func__, cmd_size_in_dw);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC);
> +   if (IS_ERR(cmd)) {
> +   drm_err(>i915->drm, "Failed to
> i915_gem_object_pin_map()\n");
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   memcpy(cmd, cmd_buf, cmd_size_in_dw * 4);
> +
> +   if (drm_debug_enabled(DRM_UT_DRIVER)) {
> +   print_hex_dump(KERN_DEBUG, "cmd binaries:",
> +  DUMP_PREFIX_OFFSET, 4, 4, cmd,
> cmd_size_in_dw * 4, true);
> +   }
> +
> +   i915_gem_object_unpin_map(pool->obj);
> +
> +   batch = i915_vma_instance(pool->obj, ce->vm, NULL);
> +   if (IS_ERR(batch)) {
> +   drm_err(>i915->drm, "Failed to
> i915_vma_instance()\n");
> +   return batch;
> +   }
> +
> +   return batch;
> +}
> +
> +int intel_pxp_cmd_submit(struct intel_pxp *pxp, u32 *cmd, int
> cmd_size_in_dw)
> +{
> +   int err = -EINVAL;
> +   struct i915_vma *batch;
> +   struct i915_request *rq;
> +   struct intel_context *ce = NULL;
> +   bool is_engine_pm_get = false;
> +   bool is_batch_vma_pin = false;
> +   bool is_skip_req_on_err = false;
> +   bool is_engine_get_pool = false;

I remember that I asked myself in some internal version to this to be
converted to gotos and I remember seeing the change. I'm not sure why
this also came back to the very original code.

Then Chris and Joonas also requested changes on older versions of this
patch. Not only limited to this. Please address 

Re: [Intel-gfx] [RFC-v19 00/13] Introduce Intel PXP component - Mesa single session

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> PXP (Protected Xe Path) is an i915 component, available on
> GEN12+ that helps to establish the hardware protected session
> and manage the status of the alive software session, as well
> as its life cycle.
> 
> This patch series is to allow the kernel space to create and
> manage a single hardware session (a.k.a. default session or
> arbitrary session). So user can allocate the protected buffer,
> which is encrypted with the leverage of the arbitrary hardware
> session.
> 
> v2:
>     - modification based on code review feedbacks received
>     - passing pxp instead of i915 as function argument
>     - remove dead code only for multi-session
>     - move the pxp init call from i915_drv.c to intel_gt.c
>     - remove the tautology naming
> 
> v3:
>     - rebase to latest drm-tip
> 
> v4:
>     - Append the split non-mesa patch sereis (commit #14 - #21) into
>   this patch series
> 
> v5:
>     - include "intel_pxp.h" in intel_pxp_sm.h at commit #14 to fix
>   the build problem.
> 
> v6:
>     - Fix the null pointer arb_session access bug in intel_pxp_arb.c
> in
>   "04 [RFC-v5] drm/i915/pxp: Create the arbitrary session after
>   boot"
> 
> v7:
>     - Use list_for_each_entry_safe instead of list_for_each_entry
> 
> v8:
>     - Add MEI vtag support for PXP multi-session usage
> 
> v9:
>     - Fix error handling bug in commit #5 "Func to send hardware
> session
>   termination". In intel_pxp_cmd.c, we should properly assign
>   "err = PTR_ERR(x)" if hitting the error case "IS_ERR(x)", this
> is
>   the only change in v9.
> 
> v10
>     - Remove the multi session commits #14-#21, for now we would like
> to
>   keep the multi session patches as downstream.
>     - Adopt the code review suggestion from Wilson in commit #1
> 
> v11
>     - In commit #05 "drm/i915/pxp: Func to send hardware session
>   termination", we should not assume VCS0 is always on.
>   Instead we use available VCS#, could be VCS0, VCS2, etc.
> 
> v12
>     - Add "#include  in #1 intel_pxp_types.h
> 
> v13
>     - Add "#include  in #1 intel_pxp_types.h (#v12
> didn't
>   actually update the _types.h file...)
> 
> v14
>     - Add "if (INTEL_GEN(gt->i915) < 12) return;" in #1
>   intel_pxp_fini(), just skip for non gen12+ sku
> 
> v15
>     In #04:
>     - Make intel_pxp_arb_reserve_session() as static function to fix
> the
>   sparse warning
>     - Update value of PXP_TEE_ARB_CMD_BIN 
> 
> v16
>     In #04:
>     - Remove the binary from source code via defining the TEE command
>   header
> 
> v17
>     - In #04, directly return intel_pxp_tee_component_fini() if
>   pxp_tee_comp_added is off
> 
> v18
>     - In #09, Add intel_pxp_gem_context_set_protected() to check the
> arb
>   session before setting protected flag for gem context
> 
>     - In #12, Replace i915_gem_context_set_protected() with
>   intel_pxp_gem_context_set_protected() to check whether the
> arbitrary
>   session is alive
> 
> v19
>     - In #01, put intel_pxp_fini() in intel_gt_driver_remove()
> instead of
>   intel_gt_driver_release() since intel_gt_driver_release() is
> the last
>   stage of i915 unbind and we shouldn't call the component_del
> here.
> 
>     - In #04, check if arbitrary session is alive before
>   intel_pxp_arb_create_session()

Please reduce the amount of series revision and start using --in-reply-
to so we can easily see what was addressed from the previous comments
versus what is open.

> 
> 
> Anshuman Gupta (1):
>   drm/i915/pxp: Add plane decryption support
> 
> Bommu Krishnaiah (2):
>   drm/i915/uapi: introduce drm_i915_gem_create_ext
>   drm/i915/pxp: User interface for Protected buffer
> 
> Huang, Sean Z (9):
>   drm/i915/pxp: Introduce Intel PXP component
>   drm/i915/pxp: set KCR reg init during the boot time
>   drm/i915/pxp: Implement funcs to create the TEE channel
>   drm/i915/pxp: Create the arbitrary session after boot
>   drm/i915/pxp: Func to send hardware session termination
>   drm/i915/pxp: Enable PXP irq worker and callback stub
>   drm/i915/pxp: Destroy arb session upon teardown
>   drm/i915/pxp: Enable PXP power management
>   drm/i915/pxp: Expose session state for display protection flip
> 
> Vitaly Lubart (1):
>   mei: pxp: export pavp client to me client bus
> 
>  drivers/gpu/drm/i915/Kconfig  |  22 ++
>  drivers/gpu/drm/i915/Makefile |   9 +
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  21 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  19 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |   5 +
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |   2 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   5 +
>  drivers/gpu/drm/i915/gt/intel_gt.c    |   5 +
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c    |   4 +
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |   4 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   3 +
>  

Re: [Intel-gfx] [RFC-v19 04/13] drm/i915/pxp: Create the arbitrary session after boot

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session. Because the
> hardware requires at least one alive session for protected buffer
> creation.  This arbitrary session needs to be re-created after
> teardown or power event because hardware encryption key won't be
> valid after such cases.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile    |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h |  16 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.c | 131
> +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.h |  16 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  73 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h |   3 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  26 
>  9 files changed, 268 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 5494c30cb54f..af9e87e4c63a 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,6 +262,7 @@ i915-y += i915_perf.o
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> +   pxp/intel_pxp_arb.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index c819f3791ee4..3868e8c697f9 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,7 @@
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
>  #include "intel_pxp_tee.h"
> +#include "intel_pxp_arb.h"
>  
>  /* KCR register definitions */
>  #define KCR_INIT    _MMIO(0x320f0)
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index f47bc6bea34f..8fc91e900b16 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -8,6 +8,22 @@
>  
>  #include "intel_pxp_types.h"
>  
> +enum pxp_session_types {
> +   SESSION_TYPE_TYPE0 = 0,
> +   SESSION_TYPE_TYPE1 = 1,
> +
> +   SESSION_TYPE_MAX
> +};
> +
> +enum pxp_protection_modes {
> +   PROTECTION_MODE_NONE = 0,
> +   PROTECTION_MODE_LM   = 2,
> +   PROTECTION_MODE_HM   = 3,
> +   PROTECTION_MODE_SM   = 6,
> +
> +   PROTECTION_MODE_ALL
> +};
> +
>  #ifdef CONFIG_DRM_I915_PXP
>  void intel_pxp_init(struct intel_pxp *pxp);
>  void intel_pxp_fini(struct intel_pxp *pxp);
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> new file mode 100644
> index ..640d7103c04d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +#include "intel_pxp_types.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR type0 session in play 0-
> 31 */
> +
> +/* Arbitrary session */
> +#define ARB_SESSION_INDEX 0xf
> +#define ARB_SESSION_TYPE SESSION_TYPE_TYPE0

All reg defines should be in i915_reg.h

> +
> +bool intel_pxp_arb_session_is_in_play(struct intel_pxp *pxp)
> +{
> +   u32 regval_sip = 0;
> +   intel_wakeref_t wakeref;
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +
> +   with_intel_runtime_pm(>i915->runtime_pm, wakeref) {
> +   regval_sip = intel_uncore_read(gt->uncore,
> GEN12_KCR_SIP);
> +   }
> +
> +   return regval_sip & BIT(ARB_SESSION_INDEX);
> +}
> +
> +/* wait hw session_in_play reg to match the current sw state */
> +static int wait_arb_hw_sw_state(struct intel_pxp *pxp)
> +{
> +   const int max_retry = 10;
> +   const int ms_delay = 10;
> +   int retry = 0;
> +   int ret;
> +   struct pxp_protected_session *arb = >ctx.arb_session;
> +
> +   ret = -EINVAL;
> +   for (retry = 0; retry < max_retry; retry++) {
> +   if (intel_pxp_arb_session_is_in_play(pxp) ==
> +   arb->is_in_play) {
> +   ret = 0;
> +   break;
> +   }
> +
> +   msleep(ms_delay);
> +   }
> +
> +   return ret;
> +}
> +
> +static void arb_session_entry_init(struct intel_pxp *pxp)
> +{
> +   struct pxp_protected_session *arb = >ctx.arb_session;
> +
> +   arb->type = ARB_SESSION_TYPE;
> +   

Re: [Intel-gfx] [RFC-v19 03/13] drm/i915/pxp: Implement funcs to create the TEE channel

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (defualt) session.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile    |   3 +-
>  drivers/gpu/drm/i915/i915_drv.c  |   1 +
>  drivers/gpu/drm/i915/i915_drv.h  |   6 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |   5 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 137
> +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h |  14 +++
>  include/drm/i915_component.h |   1 +
>  include/drm/i915_pxp_tee_interface.h |  45 
>  8 files changed, 211 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
>  create mode 100644 include/drm/i915_pxp_tee_interface.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index cbf2f0594b4d..5494c30cb54f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,7 +262,8 @@ i915-y += i915_perf.o
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> -   pxp/intel_pxp_context.o
> +   pxp/intel_pxp_context.o \
> +   pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 3e504247f2da..207d50226e64 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -322,6 +322,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(_priv->wm.wm_mutex);
> mutex_init(_priv->pps_mutex);
> mutex_init(_priv->hdcp_comp_mutex);
> +   mutex_init(_priv->pxp_tee_comp_mutex);
>  
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(_priv->runtime_pm);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 5e5bcef20e33..c2f47daef5a5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1209,6 +1209,12 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values.
> */
> struct mutex hdcp_comp_mutex;
>  
> +   struct i915_pxp_comp_master *pxp_tee_master;
> +   bool pxp_tee_comp_added;
> +
> +   /* Mutex to protect the above pxp_tee component related
> values. */
> +   struct mutex pxp_tee_comp_mutex;
> +
> I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>  
> /*
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index f566a4fda044..c819f3791ee4 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -5,6 +5,7 @@
>  #include "i915_drv.h"
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
>  
>  /* KCR register definitions */
>  #define KCR_INIT    _MMIO(0x320f0)
> @@ -23,6 +24,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
>  
> +   intel_pxp_tee_component_init(pxp);
> +
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n");
>  }
>  
> @@ -33,5 +36,7 @@ void intel_pxp_fini(struct intel_pxp *pxp)
> if (INTEL_GEN(gt->i915) < 12)
> return;
>  
> +   intel_pxp_tee_component_fini(pxp);
> +
> intel_pxp_ctx_fini(>ctx);
>  }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..5a1ffcc703e2
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include 
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include  "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
> +
> +static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> +   void *msg_in, u32 msg_in_size,
> +   void *msg_out, u32
> *msg_out_size_ptr,
> +   u32 msg_out_buf_size)
> +{
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +   struct drm_i915_private *i915 = gt->i915;
> +   struct i915_pxp_comp_master *pxp_tee_master = i915-
> >pxp_tee_master;
> +
> +   if (!pxp_tee_master || !msg_in || !msg_out ||
> !msg_out_size_ptr)
> +   return -EINVAL;
> +
> +   lockdep_assert_held(>pxp_tee_comp_mutex);
> +
> +   if 

Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Set the KCR init during the boot time, which is
> required by hardware, to allow us doing further
> protection operation such as sending commands to
> GPU or TEE.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 9bc3c7e30654..f566a4fda044 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,12 @@
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
>  
> +/* KCR register definitions */

please define this in i915_reg.h

> +#define KCR_INIT    _MMIO(0x320f0)
> +#define KCR_INIT_MASK_SHIFT (16) 

mask or shift?

> +/* Setting KCR Init bit is required after system boot */
> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) <<
> KCR_INIT_MASK_SHIFT))

Also, use only bit definitions here and leave the mask and/or shift
only when calling the write function.

> 
> +
>  void intel_pxp_init(struct intel_pxp *pxp)
>  {
> struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> @@ -15,6 +21,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> intel_pxp_ctx_init(>ctx);
>  
> +   intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
> +
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n");
>  }
>  

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v19 01/13] drm/i915/pxp: Introduce Intel PXP component

[Vivi, Rodrigo]

On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps to establish the hardware protected session and manage
> the status of the alive software session, as well as its life cycle.
> 
> This patch series is to allow the kernel space to create and
> manage a single hardware session (a.k.a default session or
> arbitrary session). So Mesa can allocate the protected buffer,
> which is encrypted with the leverage of the arbitrary hardware
> session.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Kconfig | 22 +++
>  drivers/gpu/drm/i915/Makefile    |  5 
>  drivers/gpu/drm/i915/gt/intel_gt.c   |  5 
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 29
> 
>  drivers/gpu/drm/i915/pxp/intel_pxp.h | 25 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.c | 25 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 15 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   | 23 
>  9 files changed, 152 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig
> b/drivers/gpu/drm/i915/Kconfig
> index 1e1cb245fca7..594775c11e19 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,28 @@ config DRM_I915_GVT_KVMGT
>   Choose this option if you want to enable KVMGT support for
>   Intel GVT-g.
>  
> +config DRM_I915_PXP
> +   bool "Enable Intel PXP support for Intel Gen12+ platform"
> +   depends on DRM_I915
> +   select INTEL_MEI
> +   select INTEL_MEI_ME
> +   select INTEL_MEI_TXE
> +   select INTEL_MEI_PXP

I'm afraid you haven't addressed any of the Chris' comments from V4.
I saw you marked as "done", but I'm seeing everything back here.
So I'm not sure what's going on here.


> +   default y
> +   help
> + This option selects INTEL_MEI_ME if it isn't already
> selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP (Protected Xe Path) is an i915 componment, available on
> GEN12+,
> + that helps to establish the hardware protected session and
> manage
> + the status of the alive software session, as well as its
> life cycle.
> +
> + This patch series is to allow the kernel space to create
> and
> + manage a single hardware session (a.k.a default session or
> + arbitrary session). So Mesa can allocate the protected
> buffer,
> + which is encrypted with the leverage of the arbitrary
> hardware
> + session.
> +
>  menu "drm/i915 Debugging"
>  depends on DRM_I915
>  depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 4074d8cb0d6e..cbf2f0594b4d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -259,6 +259,11 @@ i915-y += \
>  
>  i915-y += i915_perf.o
>  
> +# Protected execution platform (PXP) support
> +i915-$(CONFIG_DRM_I915_PXP) += \
> +   pxp/intel_pxp.o \
> +   pxp/intel_pxp_context.o
> +
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
>  i915-$(CONFIG_DRM_I915_SELFTEST) += \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index d8e1ab412634..336ad7deae06 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -18,6 +18,7 @@
>  #include "intel_uncore.h"
>  #include "intel_pm.h"
>  #include "shmem_utils.h"
> +#include "pxp/intel_pxp.h"
>  
>  void intel_gt_init_early(struct intel_gt *gt, struct
> drm_i915_private *i915)
>  {
> @@ -584,6 +585,8 @@ int intel_gt_init(struct intel_gt *gt)
> if (err)
> goto err_gt;
>  
> +   intel_pxp_init(>pxp);
> +
> goto out_fw;
>  err_gt:
> __intel_gt_disable(gt);
> @@ -607,6 +610,8 @@ void intel_gt_driver_remove(struct intel_gt *gt)
>  {
> __intel_gt_disable(gt);
>  
> +   intel_pxp_fini(>pxp);
> +
> intel_uc_driver_remove(>uc);
>  
> intel_engines_release(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index a83d3e18254d..c4760e2722fd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -23,6 +23,7 @@
>  #include "intel_rc6_types.h"
>  #include "intel_rps_types.h"
>  #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_types.h"
>  
>  struct drm_i915_private;
>  struct 

Re: [Intel-gfx] [PULL] drm-intel-fixes v2

[Vivi, Rodrigo]

On Wed, 2020-12-09 at 14:11 +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2020 at 05:47:05AM -0800, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Please ignore the pull request I had sent yesterday and use only
> > this one.
> > 
> > I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protect context
> > lifetime with RCU").
> > 
> > Also, please notice that the commit 6db58901c2aa
> > ("drm/i915/display: return earlier from
> > +intel_modeset_init() without display") was not actually a crucial
> > fix, but it
> > +allowed a clean pick of the use-after-free one.
> > 
> > Here goes drm-intel-fixes-2020-12-03:
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > Thanks,
> > Rodrigo.
> > 
> > The following changes since commit
> > b65054597872ce3aefbc6a666385eabdf9e288da:
> > 
> >   Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-
> > 2020-12-03
> > 
> > for you to fetch changes up to
> > ccc9e67ab26feda7e62749bb54c05d7abe07dca9:
> > 
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised (2020-12-02 17:05:58 -0800)
> > 
> > 
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > 
> > Chris Wilson (5):
> >   drm/i915/gt: Program mocs:63 for cache eviction on gen9
> 
> That also needs
> commit 444fbf5d7058 ("drm/i915/gt: Declare gen9 has 64 mocs
> entries!")
> which seems to have not made it into this pull.

yeap, I'm sorry I have missed that one.
dim doesn't deal very well with fixes for fixes and I end up missing
that.

It is now on dif and will be part of this week's pull request.

Thanks for the heads up,
Rodrigo.

> 
> >   drm/i915/gt: Protect context lifetime with RCU
> >   drm/i915/gt: Split the breadcrumb spinlock between global and
> > contexts
> >   drm/i915/gt: Limit frequency drop to RPe on parking
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised
> > 
> > Jani Nikula (1):
> >   drm/i915/display: return earlier from intel_modeset_init()
> > without display
> > 
> > Venkata Ramana Nayana (1):
> >   drm/i915/gt: Retain default context state across shrinking
> > 
> >  drivers/gpu/drm/i915/display/intel_display.c  |  24 ++--
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 168
> > ++
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h |   6 +-
> >  drivers/gpu/drm/i915/gt/intel_context.c   |  15 +-
> >  drivers/gpu/drm/i915/gt/intel_context_types.h |  23 ++-
> >  drivers/gpu/drm/i915/gt/intel_mocs.c  |  14 +-
> >  drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +
> >  drivers/gpu/drm/i915/gt/shmem_utils.c |   7 +-
> >  drivers/gpu/drm/i915/i915_request.h   |   6 +-
> >  9 files changed, 143 insertions(+), 124 deletions(-)
> > ___
> > dim-tools mailing list
> > dim-to...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dim-tools
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Vivi, Rodrigo]

> On Nov 12, 2020, at 4:32 PM, Dave Airlie  wrote:
> 
> On Fri, 13 Nov 2020 at 09:08, Rodrigo Vivi  wrote:
>> 
>> Hi Dave and Daniel,
>> 
>> This is the same set as last week + couple new fixes targeting stable.
>> 
> 
> But I merged last weeks set and it's in rc3, maybe you can generate
> the pull request relative to origin/master or drm/drm-fixes because
> I'm not sure which bits to edit out here.

oh, of course... bad rebase on my part. Sorry...
Please ignore this one. I'm going to generate another one soon.

> 
> Dave.
> 
>> Thanks,
>> Rodrigo.
>> 
>> drm-intel-fixes-2020-11-12-1:
>> - GVT fixes including vGPU suspend/resume fixes and workaround for APL guest 
>> GPU hang.
>> - Fix set domain's cache coherency (Chris)
>> - Fixes around breadcrumbs (Chris)
>> - Fix encoder lookup during PSR atomic (Imre)
>> - Hold onto an explicit ref to i915_vma_work.pinned (Chris)
>> - Pull phys pread/pwrite implementations to the backend (Chris)
>> - Correctly set SFC capability for video engines
>> The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:
>> 
>>  Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)
>> 
>> are available in the Git repository at:
>> 
>>  git://anongit.freedesktop.org/drm/drm-intel 
>> tags/drm-intel-fixes-2020-11-12-1
>> 
>> for you to fetch changes up to a4264790f4c2f0062d27d8173344c914bc7884e0:
>> 
>>  drm/i915: Correctly set SFC capability for video engines (2020-11-12 
>> 16:41:54 -0500)
>> 
>> 
>> - GVT fixes including vGPU suspend/resume fixes and workaround for APL guest 
>> GPU hang.
>> - Fix set domain's cache coherency (Chris)
>> - Fixes around breadcrumbs (Chris)
>> - Fix encoder lookup during PSR atomic (Imre)
>> - Hold onto an explicit ref to i915_vma_work.pinned (Chris)
>> - Pull phys pread/pwrite implementations to the backend (Chris)
>> - Correctly set SFC capability for video engines
>> 
>> 
>> Chris Wilson (6):
>>  drm/i915/gem: Flush coherency domains on first set-domain-ioctl
>>  drm/i915/gt: Use the local HWSP offset during submission
>>  drm/i915/gt: Expose more parameters for emitting writes into the ring
>>  drm/i915/gt: Flush xcs before tgl breadcrumbs
>>  drm/i915: Hold onto an explicit ref to i915_vma_work.pinned
>>  drm/i915/gem: Pull phys pread/pwrite implementations to the backend
>> 
>> Colin Xu (4):
>>  drm/i915/gvt: Allow zero out HWSP addr on hws_pga_write
>>  drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang
>>  drm/i915/gvt: Only pin/unpin intel_context along with workload
>>  drm/i915/gvt: Fix mmio handler break on BXT/APL.
>> 
>> Imre Deak (1):
>>  drm/i915: Fix encoder lookup during PSR atomic check
>> 
>> Matthew Auld (1):
>>  drm/i915/gem: Allow backends to override pread implementation
>> 
>> Venkata Sandeep Dhanalakota (1):
>>  drm/i915: Correctly set SFC capability for video engines
>> 
>> drivers/gpu/drm/i915/display/intel_psr.c |  2 +-
>> drivers/gpu/drm/i915/gem/i915_gem_domain.c   | 28 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  2 +
>> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 55 
>> 
>> drivers/gpu/drm/i915/gt/intel_engine.h   | 55 
>> +++-
>> drivers/gpu/drm/i915/gt/intel_engine_cs.c|  3 +-
>> drivers/gpu/drm/i915/gt/intel_lrc.c  | 31 +
>> drivers/gpu/drm/i915/gt/intel_timeline.c | 18 
>> drivers/gpu/drm/i915/gt/intel_timeline_types.h   |  2 +
>> drivers/gpu/drm/i915/gvt/handlers.c  | 47 ++--
>> drivers/gpu/drm/i915/gvt/scheduler.c | 15 ---
>> drivers/gpu/drm/i915/i915_gem.c  | 32 +++---
>> drivers/gpu/drm/i915/i915_vma.c  |  6 ++-
>> 13 files changed, 204 insertions(+), 92 deletions(-)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms

[Vivi, Rodrigo]

> On Nov 4, 2020, at 9:17 PM, Anshuman Gupta  wrote:
> 
> On 2020-11-03 at 17:06:42 -0500, Rodrigo Vivi wrote:
>> On Fri, Oct 30, 2020 at 11:46:58AM +0530, Anshuman Gupta wrote:
>>> From: Bob Paauwe 
>>> 
>>> The WA specifies that we need to toggle a SDE chicken bit on and then
>>> off as the final step in preparation for s0ix entry.
>>> 
>>>Bspec: 33450
>>>Bspec: 8402
>>> 
>>> However, something is happening after we toggle the bit that causes
>>> the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq
>>> active being already in s0ix state i.e SLP_S0 counter incremented.
>>> Tweaking the Wa_14010685332 by setting the bit on suspend and clearing
>>> it on resume turns down the dispcnlunit1_cp_xosc_clkreq.
>>> B.Spec has Documented this tweaked sequence of WA as an alternative.
>>> Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for
>>> other platforms which never observed this issue.
>>> 
>>> v2 (MattR):
>>> - Change the comment on the workaround to give PCH names rather than
>>>   platform names.  Although the bspec is setup to list workarounds by
>>>   platform, the hardware team has confirmed that the actual issue being
>>>   worked around here is something that was introduced back in the
>>>   Cannon Lake PCH and carried forward to subsequent PCH's.
>>> - Extend the untweaked version of the workaround to include  PCH_CNP as
>>>   well.  Note that since PCH_CNP is used to represent CMP, this will
>>>   apply on CML and some variants of RKL too.
>>> - Cap the untweaked version of the workaround so that it won't apply to
>>>   "fake" PCH's (i.e., DG1).  The issue we're working around really is
>>>   an issue in the PCH itself, not the South Display, so it shouldn't
>>>   apply when there isn't a real PCH.
>>> 
>>> Cc: Rodrigo Vivi 
>>> Signed-off-by: Bob Paauwe 
>>> Signed-off-by: Anshuman Gupta 
>>> Signed-off-by: Matt Roper 
>>> ---
>>> .../drm/i915/display/intel_display_power.c| 21 +--
>>> drivers/gpu/drm/i915/i915_irq.c   |  6 --
>>> 2 files changed, 23 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
>>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> index 689922480661..d2a6518329d7 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> @@ -5858,17 +5858,34 @@ static void intel_power_domains_verify_state(struct 
>>> drm_i915_private *i915)
>>> 
>>> void intel_display_power_suspend_late(struct drm_i915_private *i915)
>>> {
>>> -   if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915))
>>> +   u32 val;
>>> +
>>> +   if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915)) {
>>> bxt_enable_dc9(i915);
>>> -   else if (IS_HASWELL(i915) || IS_BROADWELL(i915))
>>> +   /* Tweaked Wa_14010685332:icp,jsp,mcc */
>>> +   if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <= 
>>> PCH_MCC) {
>>> +   val = intel_de_read(i915, SOUTH_CHICKEN1);
>>> +   val |= SBCLK_RUN_REFCLK_DIS;
>>> +   intel_de_write(i915, SOUTH_CHICKEN1, val);
>> 
>> could we use intel_de_rmw here?
> May be i had misunderstod it earlier, i thought it was your recommendation
> to use manual read, modify write without using intel_uncore_rmw(),

ouch, I'm really sorry for causing this confusion here.
My recommendation was for debug purposes only on the original w/a
I haven't noticed it had expanded to the alternate/tweaked one.
This shouldn't be needed here.

> Was the actual idea to use intel_de_rmw flavour of API instead of 
> intel_uncore_rmw?

I'm assuming that both south or north registers would still be considered
display engine. Jani can correct me if I'm wrong here.
But I believe _de_ is more appropriated here.

> Also would it require to use at original Wa in gen11_display_irq_reset as 
> well?

any modification there could be done in separated patches as needed.

>  
> Thanks,
> Anshuman Gupta.
>> 
>>> +   }
>>> +   } else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
>>> hsw_enable_pc8(i915);
>>> +   }
>>> }
>>> 
>>> void intel_display_power_resume_early(struct drm_i915_private *i915)
>>> {
>>> +   u32 val;
>>> +
>>> if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915)) {
>>> gen9_sanitize_dc_state(i915);
>>> bxt_disable_dc9(i915);
>>> +   /* Tweaked Wa_14010685332:icp,jsp,mcc */
>>> +   if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <= 
>>> PCH_MCC) {
>>> +   val = intel_de_read(i915, SOUTH_CHICKEN1);
>>> +   val &= ~SBCLK_RUN_REFCLK_DIS;
>>> +   intel_de_write(i915, SOUTH_CHICKEN1, val);
>> 
>> and here?
>> 
>> sorry for not having spotted that sooner.
>> 
>>> +   }
>>> } else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
>>> hsw_disable_pc8(i915);
>>> }
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>>> 

Re: [Intel-gfx] [PULL] gvt-fixes

[Vivi, Rodrigo]

> On Oct 29, 2020, at 10:21 PM, Zhenyu Wang  wrote:
> 
> On 2020.10.28 11:18:45 +0000, Vivi, Rodrigo wrote:
> 
>> 
>> I'm actually pulling it off. I had bypassed dim, considering this was an old
>> issue with our email decoder,
>> but it happens that 
>> 
>> $ git show 401ccfa87856 | grep Fixes
>> Fixes: e6ba76480299 (drm/i915: Remove i915->kernel_context)
>> 
>> And this is what it should have:
>> 
>> $ dim fixes e6ba76480299 | grep Fixes
>> Fixes: e6ba76480299 ("drm/i915: Remove i915->kernel_context")
>> 
>> Sorry for the trouble.
>> Let's fix this in place so we don't propagate bad tag that might break other
>> scripts on the way
>> 
> 
> Hi, Rodrigo, here's re-generated pull. I also picked another fixes for
> MMIO cmd access flag on BXT/APL, which required a backmerge.
> 
> Thanks!
> --
> The following changes since commit 61334ed227a5852100115180f5535b1396ed5227:
> 
>  drm/i915: Reject 90/270 degree rotated initial fbs (2020-10-29 14:20:24 
> -0400)
> 
> are available in the Git repository at:
> 
>  https://github.com/intel/gvt-linux tags/gvt-fixes-2020-10-30
> 
> for you to fetch changes up to 92010a97098c4c9fd777408cc98064d26b32695b:
> 
>  drm/i915/gvt: Fix mmio handler break on BXT/APL. (2020-10-30 11:50:06 +0800)


pulled, thanks!


> 
> 
> gvt-fixes-2020-10-30
> 
> - Fix HWSP reset handling during vGPU suspend/resume (Colin)
> - Apply flush workaround on APL now for possible guest hang (Colin)
> - Fix vGPU context pin/unpin also for host suspend regression with
>  vGPU created (Colin)
> - more BXT/APL mmio cmd access fixes (Colin)
> 
> 
> Colin Xu (4):
>  drm/i915/gvt: Allow zero out HWSP addr on hws_pga_write
>  drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang
>  drm/i915/gvt: Only pin/unpin intel_context along with workload
>  drm/i915/gvt: Fix mmio handler break on BXT/APL.
> 
> Zhenyu Wang (1):
>  Merge tag 'drm-intel-fixes-2020-10-29' into gvt-fixes
> 
> drivers/gpu/drm/i915/gvt/handlers.c  | 47 +---
> drivers/gpu/drm/i915/gvt/scheduler.c | 15 ++--
> 2 files changed, 52 insertions(+), 10 deletions(-)
> 
> 
> -- 
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection

[Vivi, Rodrigo]

> On Oct 27, 2020, at 11:49 PM, Pandey, Hariom  wrote:
> 
> Hi Chris,
>  
> Awaiting your kind response here…

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9208/fi-ehl-1/igt@i915_selftest@live@gt_pm.html
"Did not enter RC6!"

Chris already told that we need to get RC6 working on CI.
If we need BIOS update or machine replacement there we need to work with CI 
team to make that happen.

>  
> Thanks
> Hariom Pandey
>  
> From: Pandey, Hariom 
> Sent: Tuesday, October 20, 2020 9:28 PM
> To: Chris Wilson 
> Cc: Ausmus, James ; Nikula, Jani 
> ; intel-gfx@  intel-gfx@lists.freedesktop.org>; Souza, Jose ; 
> dri-devel@ ; 
> Surendrakumar Upadhyay, TejaskumarX 
> ; K, SrinivasX 
> ; Vivi, Rodrigo ; Meena, 
> Mahesh 
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe 
> protection
>  
> Hi Chris,
>  
> We have run RC6 test cases as recently as 4 days ago on EHL and they have 
> passed. Below are the pass log links & attached email has the DRM/IGT tag 
> where they have passed. We are finding that the “EHL BAT setup” is not upto 
> date in terms of Silicon & BIOS which we are working to upgrade. But just for 
> that, should we block this patch? Just trying to understand as there is no 
> inherent or latent RC6 issue anymore.
>  
>   • igt@i915_pm_rc6_residency@rc6-accuracy --- PASS - Log
>   • igt@i915_pm_rc6_residency@rc6-fence --- PASS – Log
>   • igt@i915_pm_rc6_residency@rc6-idle --- PASS - Log
>   • igt@perf@rc6-disable --- PASS - Log
>   • igt@perf_pmu@rc6 --- PASS - Log
>   • igt@perf_pmu@rc6-runtime-pm --- PASS - Log
>   • igt@perf_pmu@rc6-runtime-pm-long --- PASS – Log
>  
>  
> Thanks
> Hariom Pandey
>  
> > -Original Message-
> > From: Chris Wilson 
> > Sent: Tuesday, October 20, 2020 12:04 AM
> > To: K, SrinivasX ; Vivi, Rodrigo
> > 
> > Cc: Pandey, Hariom ; Ausmus, James
> > ; Nikula, Jani ; intel-gfx@
> > ; Souza, Jose
> > ; dri-devel@  > de...@lists.freedesktop.org>; Surendrakumar Upadhyay, TejaskumarX
> > 
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe
> > protection
> > 
> > Quoting Rodrigo Vivi (2020-10-19 19:29:36)
> > >
> > > I just checked the CI picture and it looks much better indeed.
> > >
> > > Only bad case being the gt_pm, which is also failing on other platforms.
> > 
> > Not nearly in the same manner. CI is indicating that there is no RC6 entry 
> > and
> > no power saving at all; neither in the selftests nor visible from userspace.
> > That is a critical battery eating bug.
> > 
> > If there's a patch to fix it for ehl and jsl, send it to CI for proving.
> > -Chris
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-fixes

[Vivi, Rodrigo]

On Oct 27, 2020, at 1:46 PM, Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>> wrote:

On Tue, Oct 27, 2020 at 11:17:40AM +0800, Zhenyu Wang wrote:

Hi,

Here's first gvt fixes for 5.10 which includes more vGPU
suspend/resume fix in HWSP reset handling, and also fix for host i915
suspend regression when vGPU is created (not need to be active), and
one workaround for APL guest hang issue.

pulled to drm-intel-fixes

I'm actually pulling it off. I had bypassed dim, considering this was an old 
issue with our email decoder,
but it happens that

$ git show 401ccfa87856 | grep Fixes
Fixes: e6ba76480299 (drm/i915: Remove i915->kernel_context)

And this is what it should have:

$ dim fixes e6ba76480299 | grep Fixes
Fixes: e6ba76480299 ("drm/i915: Remove i915->kernel_context")

Sorry for the trouble.
Let's fix this in place so we don't propagate bad tag that might break other 
scripts on the way

Sorry,
Rodrigo.

thanks


Thanks
--
The following changes since commit 16cce04cdb200ba905d1241b425ac48da5a9ace5:

 drm/i915/selftests: Push the fake iommu device from the stack to data 
(2020-09-23 10:15:46 +0300)

are available in the Git repository at:

 https://github.com/intel/gvt-linux tags/gvt-fixes-2020-10-27

for you to fetch changes up to 401ccfa87856656b874c737522ea92721394a348:

 drm/i915/gvt: Only pin/unpin intel_context along with workload (2020-10-19 
16:54:28 +0800)


gvt-fixes-2020-10-27

- Fix HWSP reset handling during vGPU suspend/resume (Colin)
- Apply flush workaround on APL now for possible guest hang (Colin)
- Fix vGPU context pin/unpin also for host suspend regression with
 vGPU created (Colin)


Colin Xu (3):
 drm/i915/gvt: Allow zero out HWSP addr on hws_pga_write
 drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang
 drm/i915/gvt: Only pin/unpin intel_context along with workload

drivers/gpu/drm/i915/gvt/handlers.c  | 35 +--
drivers/gpu/drm/i915/gvt/scheduler.c | 15 ---
2 files changed, 41 insertions(+), 9 deletions(-)


--

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

[Vivi, Rodrigo]

> On Oct 12, 2020, at 2:47 PM, Lyude Paul  wrote:
> 
> Just pushed this, but it's not in drm-tip because it would seem that 
> rebuilding
> drm-tip has failed, and the conflict doesn't appear to be from any of the
> patches I pushed so I'm getting the feeling from the DRM maintainer docs I
> should probably let one of the drm-misc-folks handle the conflict.

conflicts solved. feel free to push now.

For the drm-misc I simply went with the drm-misc-next solution and for the 
drm-intel
I went with the drm-intel-next-queued one.

> 
> On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
>> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul  wrote:
>>> On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
 On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul  wrote:
> So if I understand this correctly, it sounds like that some Pixelbooks
> boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> the
> panel actually having DPCD backlight controls enabled?
 
 It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
 backlight.enabled = false. By changing backlight.level = max,
 backlight.enabled is now set to true. This results in losing backlight
 control on boot (since the enable routine is no longer invoked).
 
>>> Ahhh ok, I'm fine with that - review still stands :)
>> 
>> Pinging intel maintainers, could someone please apply this?
>> 
>> 
>> Sean
>> 
 Sean
 
> If I'm understanding that correctly, then this patch looks good to me:
> 
> Reviewed-by: Lyude Paul 
> 
> On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
>> From: Sean Paul 
>> 
>> In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
>> DPCD control mode"), we fixed the brightness level when DPCD control
>> was
>> not active to max brightness. This is as good as we can guess since
>> most
>> backlights go on full when uncontrolled.
>> 
>> However in doing so we changed the semantics of the initial
>> 'backlight.enabled' value. At least on Pixelbooks, they  were relying
>> on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
>> boot such that enabled would be false. This causes the device to be
>> enabled when the brightness is set. Without this, brightness control
>> doesn't work. So by changing brightness to max, we also flipped
>> enabled
>> to be true on boot.
>> 
>> To fix this, make enabled a function of brightness and backlight
>> control
>> mechanism.
>> 
>> Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
>> DPCD
>> control mode")
>> Cc: Lyude Paul 
>> Cc: Jani Nikula 
>> Cc: Juha-Pekka Heikkila 
>> Cc: "Ville Syrjälä" 
>> Cc: Rodrigo Vivi 
>> Cc: Kevin Chowski >
>> Signed-off-by: Sean Paul 
>> ---
>> .../drm/i915/display/intel_dp_aux_backlight.c | 31 
>> ---
>> 1 file changed, 20 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index acbd7eb66cbe..036f504ac7db 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
>> intel_dp
>> *intel_dp, bool enable)
>>  }
>> }
>> 
>> -/*
>> - * Read the current backlight value from DPCD register(s) based
>> - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
>> - */
>> -static u32 intel_dp_aux_get_backlight(struct intel_connector
>> *connector)
>> +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
>> *connector)
>> {
>>  struct intel_dp *intel_dp = intel_attached_dp(connector);
>>  struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> - u8 read_val[2] = { 0x0 };
>>  u8 mode_reg;
>> - u16 level = 0;
>> 
>>  if (drm_dp_dpcd_readb(_dp->aux,
>>DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
>> @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
>> intel_connector *connector)
>>  drm_dbg_kms(>drm,
>>  "Failed to read the DPCD register 0x%x\n",
>>  DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
>> - return 0;
>> + return false;
>>  }
>> 
>> + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
>> +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>> +}
>> +
>> +/*
>> + * Read the current backlight value from DPCD register(s) based
>> + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
>> + */
>> +static u32 intel_dp_aux_get_backlight(struct intel_connector
>> *connector)

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection

[Vivi, Rodrigo]

> On Oct 9, 2020, at 1:31 AM, K, SrinivasX  wrote:
> 
> Hi Rodrigo,
> 
> How do we get W/A and rc6 changes in, do you have any details?

I told based on what I was seeing on 
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html?
focusing on the issues that are exclusively for ehl and not happening on other 
platforms.

It looks like workarounds are fine there now. so I'm not sure if it was 
sporadic thing that day.

for the rc6 there are a few testcases failing around it:
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-fence.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-idle.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_selftest@live@gt_pm.html#dmesg-warnings415

> 
> Thanks,
> Srinivas
> 
> -Original Message-
> From: Souza, Jose 
> Sent: 06 October 2020 23:33
> To: Vivi, Rodrigo ; ch...@chris-wilson.co.uk
> Cc: Ausmus, James ; Nikula, Jani 
> ; Pandey, Hariom ; Roper, 
> Matthew D ; intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; K, SrinivasX ; 
> Surendrakumar Upadhyay, TejaskumarX 
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe 
> protection
> 
> On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote:
>> 
>>> On Oct 6, 2020, at 10:48 AM, Chris Wilson  wrote:
>>> 
>>> Quoting Souza, Jose (2020-10-06 18:46:45)
>>>> +Rodrigo and Jani
>>>> 
>>>> On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote:
>>>>> Removing force probe protection from EHL platform. Did not
>>>>> observe warnings, errors, flickering or any visual defects while
>>>>> doing ordinary tasks like browsing and editing documents in a
>>>>> two monitor setup.
>>>> 
>>>> One of the requirements was also to have CI BAT all green and
>>>> shards as green is possible but EHL don't show up in CI results, we 
>>>> actually have one single EHL machine in CI but I guess it is not able to 
>>>> run all tests that shards do:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html
>>> 
>>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html
>> 
>> we are really close to that point. We just need to fix some w/a and
>> rc6 issues before applying this change.
>> 
>>> -Chris
>> 
> 
> Huum okay we have drm-tip results for EHL but if someone sends a patch that 
> breaks EHL it will not be caught in pre-merge testing.
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection

[Vivi, Rodrigo]

> On Oct 6, 2020, at 10:48 AM, Chris Wilson  wrote:
> 
> Quoting Souza, Jose (2020-10-06 18:46:45)
>> +Rodrigo and Jani
>> 
>> On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote:
>>> Removing force probe protection from EHL platform. Did
>>> not observe warnings, errors, flickering or any visual
>>> defects while doing ordinary tasks like browsing and
>>> editing documents in a two monitor setup.
>> 
>> One of the requirements was also to have CI BAT all green and shards as 
>> green is possible but EHL don't show up in CI results, we actually have one
>> single EHL machine in CI but I guess it is not able to run all tests that 
>> shards do:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html

we are really close to that point. We just need to fix some w/a and rc6 issues
before applying this change.

> -Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make Wa_1606700617/22010271021 permanent

[Vivi, Rodrigo]

> On Sep 14, 2020, at 1:05 PM, Vivi, Rodrigo  wrote:
> 
> 
> 
>> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi 
>>  wrote:
>> 
>> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
> 
> duh! sorry...
> 
> more below:
> 
>> 
>> -Original Message-
>> From: Rodrigo Vivi  
>> Sent: Friday, September 11, 2020 6:10 PM
>> To: Dhanavanthri, Swathi 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make 
>> Wa_1606700617/22010271021 permanent
>> 
>> On Fri, Sep 11, 2020 at 03:11:58PM -0700, Swathi Dhanavanthri wrote:
>>> This workaround applies to all TGL and RKL steppings.
>>> 
>>> Signed-off-by: Swathi Dhanavanthri 
>>> ---
>>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
>>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> index 39817c5a7058..6c580d0d9ea8 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> @@ -1729,10 +1729,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
>>> struct i915_wa_list *wal)
>>>  GEN6_RC_SLEEP_PSMI_CONTROL,
>>>  GEN12_WAIT_FOR_EVENT_POWER_DOWN_DISABLE |
>>>  GEN8_RC_SEMA_IDLE_MSG_DISABLE);
>>> -   }
> 
> now I noticed this ^ :)
> 
>>> 
>>> -   if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
>> 
>> please notice this function is called for other gens.
>> In case you need to extend this to other platforms, please add them to the 
>> if instead of removing the if.
>> 
>>> -   /* Wa_1606700617:tgl */
>>> +   /*
>>> +* Wa_1606700617:tgl
>>> +* Wa_22010271021:tgl,rkl
> 
> 1. This HSD only mentions TGL-U. No mention to RKL.
> 2. No mention to anything related to this clock gate.
> 3. Actually no W/a description at all and no sw_impact at all. But It links 
> to another entry 22010288313,
> which describes the w/a as a 3dstate ff one...
> 
> What am I missing here?

missing that old bspec page of course. Thanks for pointing it out...

Reviewed-by: Rodrigo Vivi 

> 
> Thanks,
> Rodrigo.
> 
>>> +*/
>>> wa_masked_en(wal,
>>>  GEN9_CS_DEBUG_MODE1,
>>>  FF_DOP_CLOCK_GATE_DISABLE);
>>> --
>>> 2.20.1
>>> 
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make Wa_1606700617/22010271021 permanent

[Vivi, Rodrigo]

> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi 
>  wrote:
> 
> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {

duh! sorry...

more below:

> 
> -Original Message-
> From: Rodrigo Vivi  
> Sent: Friday, September 11, 2020 6:10 PM
> To: Dhanavanthri, Swathi 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make 
> Wa_1606700617/22010271021 permanent
> 
> On Fri, Sep 11, 2020 at 03:11:58PM -0700, Swathi Dhanavanthri wrote:
>> This workaround applies to all TGL and RKL steppings.
>> 
>> Signed-off-by: Swathi Dhanavanthri 
>> ---
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> index 39817c5a7058..6c580d0d9ea8 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> @@ -1729,10 +1729,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
>> struct i915_wa_list *wal)
>>   GEN6_RC_SLEEP_PSMI_CONTROL,
>>   GEN12_WAIT_FOR_EVENT_POWER_DOWN_DISABLE |
>>   GEN8_RC_SEMA_IDLE_MSG_DISABLE);
>> -}

now I noticed this ^ :)

>> 
>> -if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
> 
> please notice this function is called for other gens.
> In case you need to extend this to other platforms, please add them to the if 
> instead of removing the if.
> 
>> -/* Wa_1606700617:tgl */
>> +/*
>> + * Wa_1606700617:tgl
>> + * Wa_22010271021:tgl,rkl

1. This HSD only mentions TGL-U. No mention to RKL.
2. No mention to anything related to this clock gate.
3. Actually no W/a description at all and no sw_impact at all. But It links to 
another entry 22010288313,
which describes the w/a as a 3dstate ff one...

What am I missing here?

Thanks,
Rodrigo.

>> + */
>>  wa_masked_en(wal,
>>   GEN9_CS_DEBUG_MODE1,
>>   FF_DOP_CLOCK_GATE_DISABLE);
>> --
>> 2.20.1
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next

[Vivi, Rodrigo]

> On Sep 13, 2020, at 7:34 PM, Zhenyu Wang  wrote:
> 
> On 2020.09.11 19:58:25 -0400, Rodrigo Vivi wrote:
>> On Thu, Sep 10, 2020 at 01:37:20PM +0800, Zhenyu Wang wrote:
>>> 
>>> Hi,
>>> 
>>> As we split pull request for 5.10 this time, here's gvt-next pull
>>> for 5.10. For gvt ww lock fix, Zhi would send another pull based
>>> on gem-next.
>>> 
>>> This includes current command access flag cleanup for
>>> handlers which would be used for next refined cmd scan. And also
>>> two more recent fixes on workaround cmd access and MIA reset state.
>>> 
>>> Thanks
>>> --
>>> The following changes since commit ced026e959bec5046afa310d6474e147b6294da2:
>>> 
>>>  drm/i915: Update DRIVER_DATE to 20200824 (2020-08-24 14:26:38 -0400)
>>> 
>>> are available in the Git repository at:
>>> 
>>>  https://github.com/intel/gvt-linux tags/gvt-next-2020-09-10
>> 
>> This is a malformed pull request line which dim doesn't recognize.
>> Could you please regenerate it?
>> 
>> $ cat /tmp/gvt-next/cur/1599868544.259925_1.rdvivi-losangeles\:2\,S | dim 
>> apply-pull drm-intel-next-queued
>> dim: no pull request found
>> 
> 
> Hmm, strange, it pulls fine here when I tried this in local. I just copied in 
> mutt and
> cat /tmp/gvt-next.0910 | ./dim apply-pull drm-intel-next-queued

sorry... it was dim's fault ;)

dim now accepts python3, but a function used on email parser doesn't work in
the same way...

pulled now, thanks

> 
>>> 
>>> for you to fetch changes up to df398e33b8fd3ac28b3c7166de555e38d26e7391:
>>> 
>>>  drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESET (2020-09-10 13:49:05 
>>> +0800)
>>> 
>>> 
>>> gvt-next-2020-09-10
>>> 
>>> - Cleanup command access flag (Yan)
>>> - New workaround cmd access fix (Colin)
>>> - MIA reset state fix (Colin)
>>> 
>>> 
>>> Colin Xu (2):
>>>  drm/i915/gvt: Add F_CMD_ACCESS for some GEN9 SKU WA MMIO access
>>>  drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESET
>>> 
>>> Yan Zhao (4):
>>>  drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTX
>>>  drm/i915/gvt: remove flag F_CMD_ACCESSED
>>>  drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESS
>>>  drm/i915/gvt: remove F_CMD_ACCESS flag for some registers
>>> 
>>> drivers/gpu/drm/i915/gvt/cmd_parser.c   |  6 ++---
>>> drivers/gpu/drm/i915/gvt/gvt.h  | 44 
>>> +++--
>>> drivers/gpu/drm/i915/gvt/handlers.c | 32 +---
>>> drivers/gpu/drm/i915/gvt/mmio.c |  3 +++
>>> drivers/gpu/drm/i915/gvt/mmio_context.c |  2 +-
>>> 5 files changed, 49 insertions(+), 38 deletions(-)
>>> 
>>> -- 
>>> 
>>> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
>> 
>> 
>> ___
>> intel-gvt-dev mailing list
>> intel-gvt-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
> 
> -- 
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup

[Vivi, Rodrigo]

> On Sep 8, 2020, at 4:39 PM, Srivatsa, Anusha  
> wrote:
> 
> We currenty check for platform at multiple parts in the driver
> to grab the correct PLL. Let us begin to centralize it through a
> helper function.
> 
> v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
> 
> v3: Clean up combo_pll_disable() (Rodrigo)
> 
> Suggested-by: Matt Roper 
> Cc: Ville Syrjälä 
> Cc: Matt Roper 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Rodrigo Vivi 
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 29 +++
> 1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index c9013f8f766f..441b6f52e808 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -147,6 +147,18 @@ void assert_shared_dpll(struct drm_i915_private 
> *dev_priv,
>   pll->info->name, onoff(state), onoff(cur_state));
> }
> 
> +static
> +i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll)
> +{
> +
> + if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id == DPLL_ID_EHL_DPLL4))
> + return MG_PLL_ENABLE(0);
> +
> + return CNL_DPLL_ENABLE(pll->info->id);
> +
> +
> +}
> /**
>  * intel_prepare_shared_dpll - call a dpll's prepare hook
>  * @crtc_state: CRTC, and its state, which has a shared dpll
> @@ -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct 
> drm_i915_private *dev_priv,
>  struct intel_shared_dpll *pll,
>  struct intel_dpll_hw_state *hw_state)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> -
> - if (IS_ELKHARTLAKE(dev_priv) &&
> - pll->info->id == DPLL_ID_EHL_DPLL4) {
> - enable_reg = MG_PLL_ENABLE(0);
> - }
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> 
>   return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
> }
> @@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct drm_i915_private 
> *dev_priv,
> static void combo_pll_enable(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> 
>   if (IS_ELKHARTLAKE(dev_priv) &&
>   pll->info->id == DPLL_ID_EHL_DPLL4) {
> - enable_reg = MG_PLL_ENABLE(0);
> 
>   /*
>* We need to disable DC states when this DPLL is enabled.
> @@ -4157,19 +4163,18 @@ static void icl_pll_disable(struct drm_i915_private 
> *dev_priv,
> static void combo_pll_disable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> +
> + icl_pll_disable(dev_priv, pll, enable_reg);
> 
>   if (IS_ELKHARTLAKE(dev_priv) &&
>   pll->info->id == DPLL_ID_EHL_DPLL4) {
> - enable_reg = MG_PLL_ENABLE(0);
> - icl_pll_disable(dev_priv, pll, enable_reg);
> 
>   intel_display_power_put(dev_priv, POWER_DOMAIN_DPLL_DC_OFF,
>   pll->wakeref);
>   return;

this return can also be removed

>   }
> 
> - icl_pll_disable(dev_priv, pll, enable_reg);
> }
> 
> static void tbt_pll_disable(struct drm_i915_private *dev_priv,
> -- 
> 2.25.0
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup

[Vivi, Rodrigo]

> On Sep 3, 2020, at 10:04 AM, Srivatsa, Anusha  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: Vivi, Rodrigo 
>> Sent: Wednesday, September 2, 2020 2:32 PM
>> To: Srivatsa, Anusha 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register
>> lookup
>> 
>> 
>> 
>>> On Sep 2, 2020, at 12:30 PM, Srivatsa, Anusha
>>  wrote:
>>> 
>>> 
>>> 
>>>> -Original Message-
>>>> From: Rodrigo Vivi 
>>>> Sent: Tuesday, September 1, 2020 12:30 PM
>>>> To: Srivatsa, Anusha 
>>>> Cc: intel-gfx@lists.freedesktop.org
>>>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE
>>>> register lookup
>>>> 
>>>> On Tue, Sep 01, 2020 at 11:27:58AM -0700, Anusha Srivatsa wrote:
>>>>> We currenty check for platform at multiple parts in the driver to
>>>>> grab the correct PLL. Let us begin to centralize it through a helper
>>>>> function.
>>>>> 
>>>>> v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg()
>>>>> (Ville)
>>>>> 
>>>>> Suggested-by: Matt Roper 
>>>>> Cc: Ville Syrjälä 
>>>>> Cc: Matt Roper 
>>>>> Signed-off-by: Anusha Srivatsa 
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 25
>>>>> +++
>>>>> 1 file changed, 15 insertions(+), 10 deletions(-)
>>>>> 
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>>>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>>>> index c9013f8f766f..7440836c5e44 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>>>> @@ -147,6 +147,18 @@ void assert_shared_dpll(struct
>> drm_i915_private
>>>> *dev_priv,
>>>>>   pll->info->name, onoff(state), onoff(cur_state));  }
>>>>> 
>>>>> +static
>>>>> +i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private
>>>> *dev_priv,
>>>>> + struct intel_shared_dpll *pll) {
>>>>> +
>>>>> + if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id ==
>>>> DPLL_ID_EHL_DPLL4))
>>>>> + return MG_PLL_ENABLE(0);
>>>>> +
>>>>> + return CNL_DPLL_ENABLE(pll->info->id);
>>>>> +
>>>>> +
>>>>> +}
>>>>> /**
>>>>> * intel_prepare_shared_dpll - call a dpll's prepare hook
>>>>> * @crtc_state: CRTC, and its state, which has a shared dpll @@
>>>>> -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
>>>> drm_i915_private *dev_priv,
>>>>>  struct intel_shared_dpll *pll,
>>>>>  struct intel_dpll_hw_state *hw_state)  {
>>>>> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
>>>>> -
>>>>> - if (IS_ELKHARTLAKE(dev_priv) &&
>>>>> - pll->info->id == DPLL_ID_EHL_DPLL4) {
>>>>> - enable_reg = MG_PLL_ENABLE(0);
>>>>> - }
>>>>> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>>>>> 
>>>>>   return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
>>>>> } @@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct
>>>>> drm_i915_private *dev_priv,  static void combo_pll_enable(struct
>>>> drm_i915_private *dev_priv,
>>>>>struct intel_shared_dpll *pll)  {
>>>>> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
>>>>> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>>>>> 
>>>>>   if (IS_ELKHARTLAKE(dev_priv) &&
>>>>>   pll->info->id == DPLL_ID_EHL_DPLL4) {
>>>> 
>>>> there's probably something else that we can do now with the
>>>> power_{put,get} to get rid of the, now, doubled if checks...
>>> 
>>> Don't follow you here Rodrigo.
>> 
>> me neither ;)
>> I'm just brainstorming... thinking out lout.
>> 
>>> Are you suggesting using power_{put/get} to somehow get

Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup

[Vivi, Rodrigo]

> On Sep 2, 2020, at 12:30 PM, Srivatsa, Anusha  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: Rodrigo Vivi 
>> Sent: Tuesday, September 1, 2020 12:30 PM
>> To: Srivatsa, Anusha 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register
>> lookup
>> 
>> On Tue, Sep 01, 2020 at 11:27:58AM -0700, Anusha Srivatsa wrote:
>>> We currenty check for platform at multiple parts in the driver to grab
>>> the correct PLL. Let us begin to centralize it through a helper
>>> function.
>>> 
>>> v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
>>> 
>>> Suggested-by: Matt Roper 
>>> Cc: Ville Syrjälä 
>>> Cc: Matt Roper 
>>> Signed-off-by: Anusha Srivatsa 
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 25
>>> +++
>>> 1 file changed, 15 insertions(+), 10 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>> index c9013f8f766f..7440836c5e44 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>>> @@ -147,6 +147,18 @@ void assert_shared_dpll(struct drm_i915_private
>> *dev_priv,
>>> pll->info->name, onoff(state), onoff(cur_state));  }
>>> 
>>> +static
>>> +i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private
>> *dev_priv,
>>> +   struct intel_shared_dpll *pll) {
>>> +
>>> +   if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id ==
>> DPLL_ID_EHL_DPLL4))
>>> +   return MG_PLL_ENABLE(0);
>>> +
>>> +   return CNL_DPLL_ENABLE(pll->info->id);
>>> +
>>> +
>>> +}
>>> /**
>>>  * intel_prepare_shared_dpll - call a dpll's prepare hook
>>>  * @crtc_state: CRTC, and its state, which has a shared dpll @@
>>> -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
>> drm_i915_private *dev_priv,
>>>struct intel_shared_dpll *pll,
>>>struct intel_dpll_hw_state *hw_state)  {
>>> -   i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
>>> -
>>> -   if (IS_ELKHARTLAKE(dev_priv) &&
>>> -   pll->info->id == DPLL_ID_EHL_DPLL4) {
>>> -   enable_reg = MG_PLL_ENABLE(0);
>>> -   }
>>> +   i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>>> 
>>> return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);  }
>>> @@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct
>>> drm_i915_private *dev_priv,  static void combo_pll_enable(struct
>> drm_i915_private *dev_priv,
>>>  struct intel_shared_dpll *pll)  {
>>> -   i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
>>> +   i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>>> 
>>> if (IS_ELKHARTLAKE(dev_priv) &&
>>> pll->info->id == DPLL_ID_EHL_DPLL4) {
>> 
>> there's probably something else that we can do now with the
>> power_{put,get} to get rid of the, now, doubled if checks...
> 
> Don't follow you here Rodrigo.

me neither ;)
I'm just brainstorming... thinking out lout. 

> Are you suggesting using power_{put/get} to somehow get rid of doubled if?

after this patch, on this path we will do this if check twice.
not a big deal, but we can probably do something better.

However I don't understand why we had this get/put here at first place.
Only for this platform and only for this pll4. So, what I am wondering is
that we have something better to do with the power_well infrastructure
in general that would allow us to avoid the if (platform && pll4) in favor
of something more generic.

but definitely not a blocker for this patch itself.

> 
>>> -   enable_reg = MG_PLL_ENABLE(0);
>>> 
>>> /*
>>>  * We need to disable DC states when this DPLL is enabled.
>>> @@ -4157,11 +4163,10 @@ static void icl_pll_disable(struct
>>> drm_i915_private *dev_priv,  static void combo_pll_disable(struct
>> drm_i915_private *dev_priv,
>>>   struct intel_shared_dpll *pll)  {
>>> -   i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
>>> +   i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>>> 
>>> if (IS_ELKHARTLAKE(dev_priv) &&
>>> pll->info->id == DPLL_ID_EHL_DPLL4) {
>>> -   enable_reg = MG_PLL_ENABLE(0);
>>> icl_pll_disable(dev_priv, pll, enable_reg);
>> 
>> but here, at least, let's clean this function now...
>> move this call above and out of the if and delete the one below and keep
>> just the power_put inside the if...
> 
> Good change. Thanks!
> Will change that.
> 
> Anusha
> 
>>> 
>>> intel_display_power_put(dev_priv,
>> POWER_DOMAIN_DPLL_DC_OFF,
>>> --
>>> 2.25.0
>>> 
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Vivi, Rodrigo]

Art, any comment here?

I just checked and the  W/a 1143 is implemented as described, but it is
failing HDMI on this hybrid system.

> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng  
> wrote:
> 
> Hi,
> 
> There's a regression reported that HDMI output stops working after os upgrade:
> https://bugs.launchpad.net/bugs/1871721
> 
> Here's the bisect result:
> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit
> commit 0519c102f5285476d7868a387bdb6c58385e4074
> Author: Ville Syrjälä 
> Date:   Mon Jan 22 19:41:31 2018 +0200
> 
>drm/i915: Implement display w/a #1143
> 
>Apparently SKL/KBL/CFL need some manual help to get the
>programmed HDMI vswing to stick. Implement the relevant
>workaround (display w/a #1143).
> 
>Note that the relevant chicken bits live in a transcoder register
>even though the bits affect a specific DDI port rather than a
>specific transcoder. Hence we must pick the correct transcoder
>register instance based on the port rather than based on the
>cpu_transcoder.
> 
>Also note that for completeness I included support for DDI A/E
>in the code even though we never have HDMI on those ports.
> 
>v2: CFL needs the w/a as well (Rodrigo and Art)
> 
>Cc: Rodrigo Vivi 
>Cc: Art Runyan 
>Signed-off-by: Ville Syrjälä 
>Link: 
> https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrj...@linux.intel.com
>Reviewed-by: Rodrigo Vivi 
> 
> 
> dmesg from drm-tip with drm.debug=0xe can be found here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/64
> 
> Kai-Heng

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next

[Vivi, Rodrigo]

> On Jul 21, 2020, at 5:42 PM, Zhenyu Wang  wrote:
> 
> On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote:
>> Quoting Zhenyu Wang (2020-07-20 11:05:41)
>>> 
>>> Hi,
>>> 
>>> Sorry that this might be a bit late as last week our QA people were
>>> busy on something else..So this is gvt changes queued for 5.9 which is
>>> to improve guest suspend/resume with proper PCI PM state tracking for
>>> resource handling, e.g ppgtt. Hopefully this could still be in queue
>>> for 5.9.
>> 
>> Is this a regression fix to a problem introduced by previous
>> gvt-next PR targeting 5.9?
>> 
>> Or is it an incremental improvement over 5.8?
>> 
> 
> Second case. This is incremental improvement. Guest suspend/resume
> did work somehow before but has bad performance and possible failure
> with some guest versions.

I'm afraid Jani already sent the last pull request towards 5.9.
So if there are fixes inside this pull request this should move to the 
-next-fixes

and the remaining improvements to another 5.10 pull request

Thanks,
Rodrigo.

> 
> Thanks
> 
>> 
>>> 
>>> Thanks
>>> --
>>> The following changes since commit d524b87f77364db096855d7eb714ffacec974ddf:
>>> 
>>>  drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300)
>>> 
>>> are available in the Git repository at:
>>> 
>>>  https://github.com/intel/gvt-linux tags/gvt-next-2020-07-20
>>> 
>>> for you to fetch changes up to 02b5fc1527c0bb26a1012c6a806dc033f3b125a6:
>>> 
>>>  drm/i915/gvt: Remove intel_vgpu_reset_gtt() since no one use it. 
>>> (2020-07-14 16:42:14 +0800)
>>> 
>>> 
>>> gvt-next-2020-07-20
>>> 
>>> - Improve guest suspend/resume handling (Colin)
>>> 
>>> 
>>> Colin Xu (3):
>>>  drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.
>>>  drm/i915/gvt: Do not reset pv_notified when vGPU transit from D3->D0
>>>  drm/i915/gvt: Remove intel_vgpu_reset_gtt() since no one use it.
>>> 
>>> drivers/gpu/drm/i915/gvt/cfg_space.c | 24 
>>> drivers/gpu/drm/i915/gvt/gtt.c   | 20 +---
>>> drivers/gpu/drm/i915/gvt/gtt.h   |  3 ++-
>>> drivers/gpu/drm/i915/gvt/gvt.h   |  3 +++
>>> drivers/gpu/drm/i915/gvt/vgpu.c  | 20 +---
>>> 5 files changed, 47 insertions(+), 23 deletions(-)
>>> --
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: drop alpha_support for good in favour of force_probe

[Vivi, Rodrigo]

On Jan 21, 2020, at 4:01 AM, Joonas Lahtinen 
mailto:joonas.lahti...@linux.intel.com>> wrote:

Quoting Jani Nikula (2020-01-21 12:30:20)
It's been a long enough transition period since the DRM_I915_FORCE_PROBE
config and i915.force_probe module parameter were introduced in commit
7ef5ef5cdead ("drm/i915: add force_probe module parameter to replace
alpha_support"). Remove alpha support.

Cc: Arkadiusz Hiler 
mailto:arkadiusz.hi...@intel.com>>
Cc: Joonas Lahtinen 
mailto:joonas.lahti...@linux.intel.com>>
Cc: Rodrigo Vivi mailto:rodrigo.v...@intel.com>>
Cc: Tomi Sarvela mailto:tomi.p.sarv...@intel.com>>
Signed-off-by: Jani Nikula mailto:jani.nik...@intel.com>>

Reviewed-by: Joonas Lahtinen 
mailto:joonas.lahti...@linux.intel.com>>

Acked-by: Rodrigo Vivi mailto:rodrigo.v...@intel.com>>


Regards, Joonas

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: make debug printer shown_bug_once variable to drm_i915_private

[Vivi, Rodrigo]

> On Dec 11, 2019, at 7:25 AM, Joonas Lahtinen 
>  wrote:
> 
> Quoting Jani Nikula (2019-12-11 12:36:10)
>> On Fri, 15 Nov 2019, Chris Wilson  wrote:
>>> Quoting Jani Nikula (2019-11-15 11:04:28)
 On Fri, 15 Nov 2019, Chris Wilson  wrote:
> Quoting Jani Nikula (2019-11-15 10:18:40)
>> Get rid of the module specific static variable.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>> drivers/gpu/drm/i915/i915_drv.h   | 2 ++
>> drivers/gpu/drm/i915/i915_utils.c | 9 -
>> 2 files changed, 6 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 1779f600fcfb..e11ee3268ae3 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1283,6 +1283,8 @@ struct drm_i915_private {
>>/* Mutex to protect the above hdcp component related values. */
>>struct mutex hdcp_comp_mutex;
>> 
>> +   bool shown_bug_once;
>> +
>>I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>> 
>>/*
>> diff --git a/drivers/gpu/drm/i915/i915_utils.c 
>> b/drivers/gpu/drm/i915/i915_utils.c
>> index c47261ae86ea..f434274b0b29 100644
>> --- a/drivers/gpu/drm/i915/i915_utils.c
>> +++ b/drivers/gpu/drm/i915/i915_utils.c
>> @@ -13,11 +13,10 @@
>>"providing the dmesg log by booting with 
>> drm.debug=0xf"
>> 
>> void
>> -__i915_printk(struct drm_i915_private *dev_priv, const char *level,
>> +__i915_printk(struct drm_i915_private *i915, const char *level,
>>  const char *fmt, ...)
>> {
>> -   static bool shown_bug_once;
>> -   struct device *kdev = dev_priv->drm.dev;
>> +   struct device *kdev = i915->drm.dev;
>>bool is_error = level[1] <= KERN_ERR[1];
>>bool is_debug = level[1] == KERN_DEBUG[1];
>>struct va_format vaf;
>> @@ -39,7 +38,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const 
>> char *level,
>> 
>>va_end(args);
>> 
>> -   if (is_error && !shown_bug_once) {
>> +   if (is_error && !i915->shown_bug_once) {
>>/*
>> * Ask the user to file a bug report for the error, except
>> * if they may have caused the bug by fiddling with unsafe
>> @@ -47,7 +46,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const 
>> char *level,
>> */
>>if (!test_taint(TAINT_USER))
>>dev_notice(kdev, "%s", FDO_BUG_MSG);
> 
> I feel this plea to the users to file a bug report should be a one-time
> thing; a true global.
 
 Fair enough.
 
 I am wondering if we should have a convention of naming or commenting
 legit globals, both to help automation detecting new accidental ones,
 and to help people figure out not to send another conversion patch such
 as this.
>>> 
>>> global_i915_show_bug_once
>>> module_i915_show_bug_once
>> 
>> I'd be fine with either of the prefixes. Or i915_{global,module}_ for
> 
> My vote goes for i915_global_* or global_i915_* (if we could get some
> Kbuild infrastructure behind detecting global variables).

any of the provided options or combinations works for me. probably global
will be less confusing...

> 
> Regards, Joonas

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-fixes

[Vivi, Rodrigo]

pulled, thanks

> On Nov 11, 2019, at 10:18 PM, Zhenyu Wang  wrote:
> 
> 
> Hi,
> 
> Here's one GVT dmabuf reference drop fix from Pan Bian.
> 
> Thanks
> --
> The following changes since commit ee2c5ef8a9d640ee1617ec97b84fe2f634284e51:
> 
>  drm/i915/dp: Do not switch aux to TBT mode for non-TC ports (2019-11-04 
> 13:24:14 -0800)
> 
> are available in the Git repository at:
> 
>  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2019-11-12
> 
> for you to fetch changes up to 41d931459b53e32c67a1f8838d1e6826a69ee745:
> 
>  drm/i915/gvt: fix dropping obj reference twice (2019-11-08 11:04:07 +0800)
> 
> 
> gvt-fixes-2019-11-12
> 
> - Fix dmabuf reference drop (Pan)
> 
> 
> Pan Bian (1):
>  drm/i915/gvt: fix dropping obj reference twice
> 
> drivers/gpu/drm/i915/gvt/dmabuf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Merge in the drm-intel tree

[Vivi, Rodrigo]

Outch, it reapared on the backmerge I did yesterday and I didn't noticed. Sorry

Chris has fixed this now.

Thank you both.

> On Aug 22, 2019, at 3:20 AM, Stephen Rothwell  wrote:
> 
> Hi all,
> 
> I noticed that the drm tree has been back merge into the drm-intel
> tree.  Unfortunately, it seems that the file
> drivers/gpu/drm/i915/i915_gem_batch_pool.c has been resurrected.
> 
> It was removed in commit
> 
>  b40d73784ffc ("drm/i915: Replace struct_mutex for batch pool serialisation")
> 
> but has come back due to a conflict with commit
> 
>  52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> 
> from the drm tree.
> -- 
> Cheers,
> Stephen Rothwell

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Vivi, Rodrigo]

> On Jul 30, 2019, at 2:48 PM, Sasha Levin  wrote:
> 
> On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>> Hi Sasha,
> 
> Hello!
> 
>> On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin  wrote:
>>> 
>>> Hi,
>>> 
>>> [This is an automated email]
>> 
>> Where did you get this patch from? Since stable needs patches merged
> 
> This bot grabs them from various mailing lists.
> 
>> on Linus tree,
>> shouldn't your scripts run to try backporting only patches from there?
> 
> There's a note a few lines down that says:
> 
>   "NOTE: The patch will not be queued to stable trees until it is upstream."
> 
> Otherwise, no, there's no rule that says we can't look at patches before
> they are upstream. We can't queue them up, but we sure can poke them.
> 
> The reasoning behind this is that it's easier to get replies (and
> backports) from folks who are actively working on the patch now,


This is a very good reason indeed...

> rather
> than a few weeks later when Greg sends his "FAILED:" mails and gets
> ignored because said folks have moved on.

however this could potentially cause extra work and confusion like we can see 
on this
thread where the developer immediately responded to your email and sent the
backported patch to the stable mailing list.

Maybe it is just because we are used to Greg's failed to apply email or maybe
it was just a matter of education... 

But I wonder if there isn't something that could be improved on the automated
message here. Some message clearly stating:

- No action required at this point
- you can work to prepare the backport in advance
-  don't send it to stable before requested by Greg

Anyway, just few ideas. I just reached you to understand the flow and I'm 
already
happy to understand what happened here.

Thanks a lot for that,
Rodrigo.


> 
> --
> Thanks,
> Sasha
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/psr: Move logic to get TPS registers values to another function

[Vivi, Rodrigo]

> On Mar 11, 2019, at 5:15 PM, Pandiyan, Dhinakaran 
>  wrote:
> 
>> On Mon, 2019-03-11 at 16:28 -0700, Rodrigo Vivi wrote:
>> On Tue, Mar 05, 2019 at 03:47:33PM -0800, José Roberto de Souza
>> wrote:
>>> This will make hsw_activate_psr1() more easy to read and will make
>>> future modification to TPS registers more easy to review and read.
>>> 
>>> Cc: Dhinakaran Pandiyan 
>>> Signed-off-by: José Roberto de Souza 
>>> ---
>>> drivers/gpu/drm/i915/intel_psr.c | 56 +++-
>>> 
>>> 1 file changed, 33 insertions(+), 23 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/intel_psr.c
>>> b/drivers/gpu/drm/i915/intel_psr.c
>>> index 831f345b4ad8..2fa2f4c9c935 100644
>>> --- a/drivers/gpu/drm/i915/intel_psr.c
>>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>>> @@ -437,32 +437,13 @@ static void intel_psr_enable_sink(struct
>>> intel_dp *intel_dp)
>>>drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
>>> DP_SET_POWER_D0);
>>> }
>>> 
>>> -static void hsw_activate_psr1(struct intel_dp *intel_dp)
>>> +static u32 psr1_tps_regs_val_get(struct intel_dp *intel_dp)
>>> {
>>>struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>>> -u32 max_sleep_time = 0x1f;
>>> -u32 val = EDP_PSR_ENABLE;
>>> -
>>> -/* Let's use 6 as the minimum to cover all known cases
>>> including the
>>> - * off-by-one issue that HW has in some cases.
>>> - */
>>> -int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>>> -
>>> -/* sink_sync_latency of 8 means source has to wait for more
>>> than 8
>>> - * frames, we'll go with 9 frames for now
>>> - */
>>> -idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
>>> + 1);
>>> -val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>>> -
>>> -val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
>>> -if (IS_HASWELL(dev_priv))
>>> -val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>>> -
>>> -if (dev_priv->psr.link_standby)
>>> -val |= EDP_PSR_LINK_STANDBY;
>>> +u32 val = 0;
>>> 
>>>if (dev_priv->vbt.psr.tp1_wakeup_time_us == 0)
>>> -val |=  EDP_PSR_TP1_TIME_0us;
>>> +val |= EDP_PSR_TP1_TIME_0us;
>>>else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 100)
>>>val |= EDP_PSR_TP1_TIME_100us;
>>>else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 500)
>>> @@ -471,7 +452,7 @@ static void hsw_activate_psr1(struct intel_dp
>>> *intel_dp)
>>>val |= EDP_PSR_TP1_TIME_2500us;
>>> 
>>>if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us == 0)
>>> -val |=  EDP_PSR_TP2_TP3_TIME_0us;
>>> +val |= EDP_PSR_TP2_TP3_TIME_0us;
>>>else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
>>>val |= EDP_PSR_TP2_TP3_TIME_100us;
>>>else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
>>> @@ -485,6 +466,35 @@ static void hsw_activate_psr1(struct intel_dp
>>> *intel_dp)
>>>else
>>>val |= EDP_PSR_TP1_TP2_SEL;
>>> 
>>> +return val;
>>> +}
>>> +
>>> +static void hsw_activate_psr1(struct intel_dp *intel_dp)
>>> +{
>>> +struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>>> +u32 max_sleep_time = 0x1f;
>>> +u32 val = EDP_PSR_ENABLE;
>>> +
>>> +/* Let's use 6 as the minimum to cover all known cases
>>> including the
>>> + * off-by-one issue that HW has in some cases.
>>> + */
>>> +int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>>> +
>>> +/* sink_sync_latency of 8 means source has to wait for more
>>> than 8
>>> + * frames, we'll go with 9 frames for now
>>> + */
>>> +idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
>>> + 1);
>>> +val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>>> +
>>> +val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
>>> +if (IS_HASWELL(dev_priv))
>>> +val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>>> +
>>> +if (dev_priv->psr.link_standby)
>>> +val |= EDP_PSR_LINK_STANDBY;
>>> +
>>> +val |= psr1_tps_regs_val_get(intel_dp);
>> 
>> I'd prefer intel_psr1_tps...
>> 
> 
> intel_psr1_get_tp_time(intel_dp)?

+1

> 
>> Reviewed-by: Rodrigo Vivi 
>> 
>>> +
>>>if (INTEL_GEN(dev_priv) >= 8)
>>>val |= EDP_PSR_CRC_ENABLE;
>>> 
>>> -- 
>>> 2.21.0
>>> 
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] I messed up drm-intel-next-queued!

[Vivi, Rodrigo]

Hi Hans,

I’m traveling on vacation and didn’t bring my laptop. I believe Joonas and Jani 
are out this week as well.

I’m in favor of the forced push if you are sure you have the latest one with 
you.

In case you are not sure about the latest sabe head:
I had done a drm-intel-next tag last Friday... so worst case we could reator to 
the drive-update-date commit and ask around to see if someone had merged other 
patches after that and re-push.

Merry Christmas,
Rodrigo.


> On Dec 24, 2018, at 8:39 PM, Hans de Goede  wrote:
> 
> Hi,
> 
> Ugh, I just messed up drm-intel-next-queued big time.
> 
> I somehow rebased my work on top of drm-tip (I believe I did the rebase
> in the wrong dir) and then after running a bunch of tests I
> did a "dim push-branch drm-intel-next-queued" which pushed the
> patches I intended to push rebased on top of drm-tip
> pushing drm-tip to dinq :(
> 
> I'm so sorry about this.
> 
> I just checked my reflog and the last commit before me messing
> up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
> ("drm/i915: Unwind failure on pinning the gen7 ppgtt")
> 
> I think we should do a forced push to restore this, but
> I don't want to make things worse, so hence this email.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

[Vivi, Rodrigo]

> On Oct 2, 2018, at 9:20 PM, Yadav, Jyoti R  wrote:
> 
> DC5 and DC6 counter register tells about residency of DC5 and DC6.
> These registers are same for SKL and ICL.
> 
> v2 : Remove csr_version check.
> Added generic check regarding DC counters for  Gen9 onwards. (Rodrigo)
> v3 : Simplified gen checks. (Chris)
> 
> Signed-off-by: Jyoti Yadav 
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a5265c2..af13077 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2897,13 +2897,12 @@ static int i915_dmc_info(struct seq_file *m, void 
> *unused)
>seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
>   CSR_VERSION_MINOR(csr->version));
> 
> -if (IS_KABYLAKE(dev_priv) ||
> -(IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
> +if ((!IS_BROXTON(dev_priv)) && IS_GEN(dev_priv, 9, 11)) {
>seq_printf(m, "DC3 -> DC5 count: %d\n",
>   I915_READ(SKL_CSR_DC3_DC5_COUNT));
>seq_printf(m, "DC5 -> DC6 count: %d\n",
>   I915_READ(SKL_CSR_DC5_DC6_COUNT));
> -} else if (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
> +} else if (IS_BROXTON(dev_priv)) {
>seq_printf(m, "DC3 -> DC5 count: %d\n",
>   I915_READ(BXT_CSR_DC3_DC5_COUNT));
>}

Please do the other way around...
If is broxton {
} else if gen(9,11) {
}

So no need for repetition with nots...

> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8534f88..573d5f3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6985,6 +6985,7 @@ enum {
> /* MMIO address range for CSR program (0x8 - 0x82FFF) */
> #define CSR_MMIO_START_RANGE0x8
> #define CSR_MMIO_END_RANGE0x8
> +/* DC3_DC5 count and DC5_DC6 count registers are same for SKL and ICL */
> #define SKL_CSR_DC3_DC5_COUNT_MMIO(0x80030)
> #define SKL_CSR_DC5_DC6_COUNT_MMIO(0x8002C)
> #define BXT_CSR_DC3_DC5_COUNT_MMIO(0x80038)
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/edp: Only use alternate fixed mode when requested

[Vivi, Rodrigo]

> On Apr 12, 2018, at 2:21 PM, Taylor, Clinton A  
> wrote:
> 
> 
> 
>> On 04/11/2018 04:11 PM, Chris Wilson wrote:
>> Quoting clinton.a.tay...@intel.com (2018-04-12 00:13:26)
>>> From: Clint Taylor 
>>> 
>>> In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP
>>> if available."), the patch was always selecting the alternate refresh rate
>>> even though user space was asking for the higher rate. This patch adds a
>>> check for vrefresh rate as well as the rest of the mode geometry.
>>> 
>>> V2: use clock instead of vrefresh for compare.
>>> 
>>> Fixes: dc911f5bd8aac ("Allow alternate fixed mode for eDP if available.")
>>> Cc: David Weinehall 
>>> Cc: Rodrigo Vivi 
>>> Signed-off-by: Clint Taylor 
>> Still leaves the other discussion point in the other thread unresolved.
>> The fields are supplied by the user and can be arbitrary, so if they
>> request a clock for a 30Hz mode, instead of using the 40Hz alternative,
>> we use the 60Hz normal mode (by way of example). Is equality always the
>> best choice here?
> This feature is for testing PSR panels that don't support single frame setup 
> times in their preferred timing. The down-clocked mode is the timing that the 
> panel specifically states is supported. If a customer specifies a custom mode 
> either it should be rejected or the eDP fixed mode (preferred) should be 
> used. If we want to allow the users to set a custom timing to their eDP 
> panels then we should get rid of the fixed mode feature for eDP panels.

But that was the goal of dc911f5bd8aac because
most of the panels we had here by that time with PSR had that short vblank 
periods for higher mode...
So the idea was to remove the fixed mode allowing the alternate one with lower 
rate and consequently higher vblank period.

But the idea was never to respect the arbitrary user request. All panels we 
were targeting here had both modes listed as supported... one with 60Hz and one 
with 48 Hz. Both same resolution.

> 
> -Clint
> 
>> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

[Vivi, Rodrigo]

On Jan 4, 2018, at 10:07 PM, Kenneth Graunke 
> wrote:

On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote:
On Thu, Jan 04, 2018 at 11:39:23PM +, Kenneth Graunke wrote:
On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
Quoting Kenneth Graunke (2018-01-04 19:38:05)
Geminilake requires the 3D driver to select whether barriers are
intended for compute shaders, or tessellation control shaders, by
whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
switching pipelines.  Failure to do this properly can result in GPU
hangs.

Unfortunately, this means it needs to switch mid-batch, so only
userspace can properly set it.  To facilitate this, the kernel needs
to whitelist the register.

Signed-off-by: Kenneth Graunke 
>
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_reg.h| 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
2 files changed, 7 insertions(+)

Hello,

We unfortunately need to whitelist an extra register for GPU hang fix
on Geminilake.  Here's the corresponding Mesa patch:

Thankfully it appears to be context saved. Has a w/a name been assigned
for this?
-Chris

There doesn't appear to be one.  The workaround page lists it, but there
is no name.  The register description has a note saying that you need to
set this, but doesn't call it out as a workaround.

It mentions only BXT:ALL, but not mention to GLK.

Should we add to both then?

Well, that's irritating.

Indeed. As always :)

 On the workarounds page, it does indeed say
"BXT" with no mention of GLK.  But the workaround text says to set
"SLICE_COMMON_CHICKEN_ECO1 Barrier Mode [...] (bit 7 of MMIO 0x731C)."

Looking at the register definition for SLICE_COMMON_ECO_CHICKEN1, bit 7
is "Barrier Mode" on [GLK] only, with no mention of BXT.  It's marked
reserved PBC on [SKL+, not GLK, not KBL].  On KBL it's something else.

I have no ways to check this bit right now,
But your explanation makes sense so I agree with you...
Acked-by: Rodrigo Vivi >


I believe Mark saw hangs in tessellation control shader hangs on
Geminilake only, and never saw this issue on Broxton.  So, my guess is
that the workaround really is new on Geminilake, and the BXT tag on the
workarounds page is incorrect.  (Mark, does that sound right to you?)

Probably worth a mention on comment or commit msg?!


That's why I put a generic comment, rather than the name.

On Display side we started using the row name for this case, to help
easily finding this later.

ex: "Display WA #0390: skl,kbl"

The number for this apparently is:
WA #0862

Maybe we could use this one to start
/* GT WA #0862: bxt,glk */

GT? GEM?
Unnamed WA #0862?

Including #0862 seems like a good idea.  I'm happy to change the comment
to whatever you'd prefer.

Leave your comment and add WA #0862...
If later we define a standardized style we come back and change this.

Thanks
Rodrigo


--Ken
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-tip:drm-tip 1/7] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: error: redefinition of 'dm_dp_mst_dc_sink_create'

[Vivi, Rodrigo]

Drm-tip rebuild created this function duplication in some merge resolution... 
not sure where that came from or started... But Lucas had warned me yesterday 
morning...

So, yesterday night I added a fix-up on drm-rerere that remove the duplication 
on drm-tip... and that should be fixed by now I think...

Could you please fetch and recheck?!

On Dec 30, 2017, at 9:10 AM, Wu, Fengguang 
> wrote:

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   16432d39f2cbdc7a8798df3ebb4f7c882fb23132
commit: a79b622ef5cad1b3a868a1d7250494e39bb04c05 [1/7] Merge remote-tracking 
branch 'airlied/drm-next' into drm-tip
config: i386-randconfig-b0-12302345 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
   git checkout a79b622ef5cad1b3a868a1d7250494e39bb04c05
   # save the attached .config to linux build tree
   make ARCH=i386

Note: the drm-tip/drm-tip HEAD 16432d39f2cbdc7a8798df3ebb4f7c882fb23132 builds 
fine.
 It only hurts bisectibility.

All errors (new ones prefixed by >>):

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: 
error: redefinition of 'dm_dp_mst_dc_sink_create'
   void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
^
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:183:6: 
note: previous definition of 'dm_dp_mst_dc_sink_create' was here
   void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
^

vim +/dm_dp_mst_dc_sink_create +219 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c

54427651 Jerry Zuo   2017-09-20  218
becd0875 Jerry (Fangzhi  Zuo 2017-12-01 @219) void 
dm_dp_mst_dc_sink_create(struct drm_connector *connector)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  220) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  221)struct amdgpu_dm_connector 
*aconnector = to_amdgpu_dm_connector(connector);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  222)struct edid *edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  223)struct dc_sink *dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  224)struct dc_sink_init_data 
init_params = {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  225).link = 
aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  226).sink_signal = 
SIGNAL_TYPE_DISPLAY_PORT_MST };
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  227)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  228)edid = 
drm_dp_mst_get_edid(connector, >mst_port->mst_mgr, 
aconnector->port);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  229)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  230)if (!edid) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  231)
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  232)>base,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  233)NULL);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  234)return;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  235)}
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  236)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  237)aconnector->edid = edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  238)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  239)dc_sink = 
dc_link_add_remote_sink(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  240)aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  241)(uint8_t 
*)aconnector->edid,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  242)
(aconnector->edid->extensions + 1) * EDID_LENGTH,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  243)_params);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  244)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  245)dc_sink->priv = aconnector;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  246)aconnector->dc_sink = dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  247)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  248)
amdgpu_dm_add_sink_to_freesync_module(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  249)connector, 
aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  250)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  251)
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  252)
>base, aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  253) }
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  254)

:: The code at line 219 was first introduced by commit
:: becd0875f4393a992afbf57aa323f7bf1a71c3ff drm/amd/display: Fix rehook MST 
display not light back on

:: TO: Jerry (Fangzhi) Zuo >
:: CC: Alex Deucher 
>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
<.config.gz>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx