Re: [Intel-gfx] [PATCH] drm/i915/pvc: Update forcewake domain for CCS register ranges

2022-10-18 Thread Chegondi, Harish
On Fri, 2022-10-14 at 16:30 -0700, Matt Roper wrote:
> The bspec was just updated with a correction to the forcewake domain
> required when accessing registers in the CCS engine ranges (0x1a000 -
> 0x1 and 0x26000 - 0x27fff) on PVC; these ranges require a wake on
> the RENDER domain, not the GT domain.
> 
> Bspec: 67609
> Signed-off-by: Matt Roper 

Reviewed-by: Harish Chegondi 

>  drivers/gpu/drm/i915/intel_uncore.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index c058cdc6d8a0..2a3e2869fe71 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1682,25 +1682,27 @@ static const struct intel_forcewake_range
> __pvc_fw_ranges[] = {
> GEN_FW_RANGE(0x12000, 0x12fff, 0), /*
> 0x12000 - 0x127ff: always on
> 0x12800 - 0x12fff: reserved */
> -   GEN_FW_RANGE(0x13000, 0x23fff, FORCEWAKE_GT), /*
> +   GEN_FW_RANGE(0x13000, 0x19fff, FORCEWAKE_GT), /*
> 0x13000 - 0x135ff: gt
> 0x13600 - 0x147ff: reserved
> 0x14800 - 0x153ff: gt
> -   0x15400 - 0x19fff: reserved
> -   0x1a000 - 0x1: gt
> -   0x2 - 0x21fff: reserved
> -   0x22000 - 0x23fff: gt */
> +   0x15400 - 0x19fff: reserved */
> +   GEN_FW_RANGE(0x1a000, 0x21fff, FORCEWAKE_RENDER), /*
> +   0x1a000 - 0x1: render
> +   0x2 - 0x21fff: reserved */
> +   GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_GT),
> GEN_FW_RANGE(0x24000, 0x2417f, 0), /*
> 24000 - 0x2407f: always on
> 24080 - 0x2417f: reserved */
> -   GEN_FW_RANGE(0x24180, 0x3, FORCEWAKE_GT), /*
> +   GEN_FW_RANGE(0x24180, 0x25fff, FORCEWAKE_GT), /*
> 0x24180 - 0x241ff: gt
> 0x24200 - 0x251ff: reserved
> 0x25200 - 0x252ff: gt
> -   0x25300 - 0x25fff: reserved
> -   0x26000 - 0x27fff: gt
> -   0x28000 - 0x2: reserved
> -   0x3 - 0x3: gt */
> +   0x25300 - 0x25fff: reserved */
> +   GEN_FW_RANGE(0x26000, 0x2, FORCEWAKE_RENDER), /*
> +   0x26000 - 0x27fff: render
> +   0x28000 - 0x2: reserved */
> +   GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT),
> GEN_FW_RANGE(0x4, 0x1b, 0),
> GEN_FW_RANGE(0x1c, 0x1c3fff, FORCEWAKE_MEDIA_VDBOX0), /*
> 0x1c - 0x1c2bff: VD0



Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add MTL forcewake support

2022-09-18 Thread Chegondi, Harish
Reviewed-by: Harish Chegondi 

-Original Message-
From: Intel-gfx  On Behalf Of Matt 
Roper
Sent: Friday, September 9, 2022 5:17 PM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915/mtl: Add MTL forcewake support

MTL has separate forcewake tables for the primary/render GT and the media GT; 
each GT's intel_uncore will use a separate forcewake table and should only 
initialize the domains that are relevant to that GT.  The GT ack register also 
moves to a new location of (GSI base + 0xDFC) on this platform.

Note that although our uncore handlers take care of transparently redirecting 
all register accesses in the media GT's GSI range to their new offset at 
0x38, the forcewake ranges listed in the table should use the final, 
post-translation offsets.

NOTE:  There are two ranges in the media IP that have multicast registers where 
the two register instances reside in different power wells (either VD0 or VD2). 
 We don't have an easy way to deal with this today (and in fact we don't even 
access these register ranges in the driver today), so for now we just mark 
those ranges as FORCEWAKE_ALL which will cause all of the media power wells to 
be grabbed, ensuring proper operation.  If we start reading/writing in those 
ranges in the future, we can re-visit whether it's worth adding extra steering 
complexity into our forcewake support.

Bspec: 67788, 67789, 52077
Cc: Radhakrishna Sripada 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/intel_uncore.c   | 258 +-
 drivers/gpu/drm/i915/intel_uncore.h   |   2 +
 drivers/gpu/drm/i915/selftests/intel_uncore.c |   4 +
 4 files changed, 258 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..1cbb7226400b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,9 @@
 #define FORCEWAKE_ACK_RENDER_GEN9  _MMIO(0xd84)
 #define FORCEWAKE_ACK_MEDIA_GEN9   _MMIO(0xd88)
 
+#define FORCEWAKE_ACK_GSC  _MMIO(0xdf8)
+#define FORCEWAKE_ACK_GT_MTL   _MMIO(0xdfc)
+
 #define MCFG_MCR_SELECTOR  _MMIO(0xfd0)
 #define SF_MCR_SELECTOR_MMIO(0xfd8)
 #define GEN8_MCR_SELECTOR  _MMIO(0xfdc)
@@ -898,6 +901,8 @@
 #define FORCEWAKE_MEDIA_VDBOX_GEN11(n) _MMIO(0xa540 + (n) * 4)
 #define FORCEWAKE_MEDIA_VEBOX_GEN11(n) _MMIO(0xa560 + (n) * 4)
 
+#define FORCEWAKE_REQ_GSC  _MMIO(0xa618)
+
 #define CHV_POWER_SS0_SIG1 _MMIO(0xa720)
 #define CHV_POWER_SS0_SIG2 _MMIO(0xa724)
 #define CHV_POWER_SS1_SIG1 _MMIO(0xa728)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 5cd423c7b646..c058cdc6d8a0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -104,6 +104,7 @@ static const char * const forcewake_domain_names[] = {
"vebox1",
"vebox2",
"vebox3",
+   "gsc",
 };
 
 const char *
@@ -888,10 +889,13 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
spin_unlock_irq(&uncore->lock);
 }
 
-/* We give fast paths for the really cool registers */
+/*
+ * We give fast paths for the really cool registers.  The second range 
+includes
+ * media domains (and the GSC starting from Xe_LPM+)  */
 #define NEEDS_FORCE_WAKE(reg) ({ \
u32 __reg = (reg); \
-   __reg < 0x4 || __reg >= GEN11_BSD_RING_BASE; \
+   __reg < 0x4 || __reg >= 0x116000; \
 })
 
 static int fw_range_cmp(u32 offset, const struct intel_forcewake_range *entry) 
@@ -1131,6 +1135,45 @@ static const struct i915_range pvc_shadowed_regs[] = {
{ .start = 0x1F8510, .end = 0x1F8550 },  };
 
+static const struct i915_range mtl_shadowed_regs[] = {
+   { .start =   0x2030, .end =   0x2030 },
+   { .start =   0x2510, .end =   0x2550 },
+   { .start =   0xA008, .end =   0xA00C },
+   { .start =   0xA188, .end =   0xA188 },
+   { .start =   0xA278, .end =   0xA278 },
+   { .start =   0xA540, .end =   0xA56C },
+   { .start =   0xC050, .end =   0xC050 },
+   { .start =   0xC340, .end =   0xC340 },
+   { .start =   0xC4C8, .end =   0xC4C8 },
+   { .start =   0xC4E0, .end =   0xC4E0 },
+   { .start =   0xC600, .end =   0xC600 },
+   { .start =   0xC658, .end =   0xC658 },
+   { .start =   0xCFD4, .end =   0xCFDC },
+   { .start =  0x22030, .end =  0x22030 },
+   { .start =  0x22510, .end =  0x22550 }, };
+
+static const struct i915_range xelpmp_shadowed_regs[] = {
+   { .start = 0x1C0030, .end = 0x1C0030 },
+   { .start = 0x1C0510, .end = 0x1C0550 },
+   { .start = 0x1C8030, .end = 0x1C8030 },
+   { .sta

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs

2019-10-23 Thread Chegondi, Harish
Hi,

Even though I tried to link this patch with it's first version by
specifying --in-reply-to=, it wasn't successful. So here is
the link to the first version of the patch and the discussion.

https://patchwork.freedesktop.org/patch/305153/?series=60697&rev=1

The first version of this patch has been "Acked-by" but wasn't
"Reviewed-by" as the patch adds another workaround on top of an already
existing workaround. The patch doesn't fix the cause of invalid CRCs
being generated which still needs to be investigated and fixed. I am
rebasing and resending the patch to seek feedback on how to move
further with this patch.

Thank You
Harish

On Wed, 2019-10-23 at 00:24 -0700, Harish Chegondi wrote:
> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and
> the
> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT
> which
> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> 
> v2: Rebase
> 
> Cc: Jani Saarinen 
> Cc: Tomi Sarvela 
> Cc: Petri Latvala 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Acked-by: Jani Nikula 
> Signed-off-by: Harish Chegondi 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 572a5c37cc61..312ca9d5292a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1565,11 +1565,11 @@ static void
> display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>* bonkers. So let's just wait for the next vblank and read
>* out the buggy result.
>*
> -  * On GEN8+ sometimes the second CRC is bonkers as well, so
> +  * On GEN7+ sometimes the second CRC is bonkers as well, so
>* don't trust that one either.
>*/
>   if (pipe_crc->skipped <= 0 ||
> - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
>   pipe_crc->skipped++;
>   spin_unlock(&pipe_crc->lock);
>   return;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs

2019-05-16 Thread Chegondi, Harish
On Thu, 2019-05-16 at 16:30 +0300, Ville Syrjälä wrote:
> On Thu, May 16, 2019 at 03:55:25PM +0300, Jani Nikula wrote:
> > On Thu, 16 May 2019, Maarten Lankhorst <
> > maarten.lankho...@linux.intel.com> wrote:
> > > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> > > > display_pipe_crc_irq_handler() skips the first CRC for all GPUs
> > > > and the
> > > > second CRC for GEN8+ GPUs. The second CRC is invalid even for
> > > > BYT which
> > > > is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> > > > 
> > > > Cc: Jani Nikula 
> > > > Cc: Tomi Sarvela 
> > > > Cc: Petri Latvala 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Maarten Lankhorst 
> > > > Signed-off-by: Harish Chegondi 
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 233211fde0ea..3809e9f7fae2 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -1775,11 +1775,11 @@ static void
> > > > display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
> > > >  * bonkers. So let's just wait for the next vblank and
> > > > read
> > > >  * out the buggy result.
> > > >  *
> > > > -* On GEN8+ sometimes the second CRC is bonkers as
> > > > well, so
> > > > +* On GEN7+ sometimes the second CRC is bonkers as
> > > > well, so
> > > >  * don't trust that one either.
> > > >  */
> > > > if (pipe_crc->skipped <= 0 ||
> > > > -   (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped ==
> > > > 1)) {
> > > > +   (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped ==
> > > > 1)) {
> > > > pipe_crc->skipped++;
> > > > spin_unlock(&pipe_crc->lock);
> > > > return;
> > > 
> > > I would be interested in the results, haswell is different from
> > > VLV. Has it ever been observed on that platform?
> > 
> > Good point. I looked at [1] which I presumed was on VLV, but it
> > says
> > nothing about HSW.
> 
> This whole thing is just a pile of duct tape anyway. The reason(s)
> for these funky crcs has never been properly analysed.

Ville,
Are the patches in your branch :
git://github.com/vsyrjala/linux.git g4x_fixes_4
related to fixing these invalid CRCs ?

Thanks!
Harish


smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs

2019-05-16 Thread Chegondi, Harish
On Thu, 2019-05-16 at 15:55 +0300, Jani Nikula wrote:
> On Thu, 16 May 2019, Maarten Lankhorst <
> maarten.lankho...@linux.intel.com> wrote:
> > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> > > display_pipe_crc_irq_handler() skips the first CRC for all GPUs
> > > and the
> > > second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT
> > > which
> > > is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Tomi Sarvela 
> > > Cc: Petri Latvala 
> > > Cc: Ville Syrjälä 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Harish Chegondi 
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> > > ---
> > >  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 233211fde0ea..3809e9f7fae2 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1775,11 +1775,11 @@ static void
> > > display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
> > >* bonkers. So let's just wait for the next vblank and read
> > >* out the buggy result.
> > >*
> > > -  * On GEN8+ sometimes the second CRC is bonkers as well, so
> > > +  * On GEN7+ sometimes the second CRC is bonkers as well, so
> > >* don't trust that one either.
> > >*/
> > >   if (pipe_crc->skipped <= 0 ||
> > > - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> > > + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
> > >   pipe_crc->skipped++;
> > >   spin_unlock(&pipe_crc->lock);
> > >   return;
> > 
> > I would be interested in the results, haswell is different from
> > VLV. Has it ever been observed on that platform?
> 
> Good point. I looked at [1] which I presumed was on VLV, but it says
> nothing about HSW.

In fdo # 103191, CRC mismatch failures in igt@kms_pipe_crc_basic@*
tests have not been observed on HSW. These tests have been very
consistently failing on CI fi-byt-squawks system which is a chromebook,
sporadically failing on CI fi-byt-clapper system which is also a
chromebook. However the tests are passing on other CI BYT systems like
fi-byt-n2820 and fi-byt-j1900 which are not chromebooks and the display
is not eDP. I haven't seen these failures happening on other GEN7 GPUs.
Instead of skipping the second CRC just for BYT, I thought it may be a
better idea to skip the second CRC on all GEN7 GPUs as the current code
is already skipping the second CRC on all GEN8+ GPUs.

Thanks!
Harish.

> 
> BR,
> Jani.
> 
> 
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=103191#c34
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx