diff mbox series

drm/i915: Reserving some Multi-thread forcewake bits.

Message ID 20220413213927.40927-1-rodrigo.vivi@intel.com (mailing list archive)
State New, archived
Headers show
Series drm/i915: Reserving some Multi-thread forcewake bits. | expand

Commit Message

Rodrigo Vivi April 13, 2022, 9:39 p.m. UTC
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.
	      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 <tilak.tangudu@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Matt Roper April 14, 2022, 9:14 p.m. UTC | #1
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.

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.

   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.


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 <tilak.tangudu@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  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)
> +#define   FORCEWAKE_USER			BIT(2)
> +#define   FORCEWAKE_PCODE			BIT(3)
> +#define   FORCEWAKE_PSMI			BIT(4)
>  #define   FORCEWAKE_KERNEL_FALLBACK		BIT(15)
>  #define FORCEWAKE_ACK				_MMIO(0x130090)
>  #define VLV_GTLC_WAKE_CTRL			_MMIO(0x130090)
> -- 
> 2.34.1
>
Rodrigo Vivi April 14, 2022, 9:30 p.m. UTC | #2
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 <tilak.tangudu@intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> >  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)
> > +#define   FORCEWAKE_USER                       BIT(2)
> > +#define   FORCEWAKE_PCODE                      BIT(3)
> > +#define   FORCEWAKE_PSMI                       BIT(4)
> >  #define   FORCEWAKE_KERNEL_FALLBACK            BIT(15)
> >  #define FORCEWAKE_ACK                          _MMIO(0x130090)
> >  #define VLV_GTLC_WAKE_CTRL                     _MMIO(0x130090)
> > -- 
> > 2.34.1
> > 
>
diff mbox series

Patch

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)
+#define   FORCEWAKE_USER			BIT(2)
+#define   FORCEWAKE_PCODE			BIT(3)
+#define   FORCEWAKE_PSMI			BIT(4)
 #define   FORCEWAKE_KERNEL_FALLBACK		BIT(15)
 #define FORCEWAKE_ACK				_MMIO(0x130090)
 #define VLV_GTLC_WAKE_CTRL			_MMIO(0x130090)