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