Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-02-09 Thread Daniele Ceraolo Spurio




+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
+{
+   irqreturn_t ret = IRQ_NONE;
+   u16 irq[2][32];
+   u32 dw, ident;
+   unsigned long tmp;
+   unsigned int bank, bit, engine;
+   unsigned long wait_start, wait_end;
+
+   memset(irq, 0, sizeof(irq));
+
+   for (bank = 0; bank < 2; bank++) {
+   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
+   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+   if (!dw)
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
+   tmp = dw;
+   for_each_set_bit(bit, &tmp, 32) {
+   I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
<< bit);
+   wait_start = local_clock() >> 10;
+   /* NB: Specs do not specify how long to spin 
wait.
+* Taking 100us as an educated guess */
+   wait_end = wait_start + 100;
+   do {
+   ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
+   } while (!(ident & GEN11_INTR_DATA_VALID) &&
+!time_after((unsigned long)local_clock() 
>> 10, wait_end));
+
+   if (!(ident & GEN11_INTR_DATA_VALID))
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
out!\n",
+ bank, bit);
+
+   irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+   if (!irq[bank][bit])
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u 
blank!\n",
+ bank, bit);


I think having the identity reg valid but empty is a possible case and 
we shouldn't error on it. The scenario I'm thinking of is:


- Interrupt on engine, we read master IRQ and disable interrupts
- we read GEN11_GT_INTR_DW. the register is now locked until a write occurs
- a second interrupt arrives on the same engine, gets double buffered 
behind the current one in GEN11_GT_INTR_DW
- we read the irq vector (which will now contain both interrupts), 
process it and clear it
- we write to GEN11_GT_INTR_DW to clear it and the buffered value is now 
propagated to it
- GEN11_GT_INTR_DW now has the bit set, but we already serviced the 
interrupt so the identity register will be zero.


Just dropping the error message should be enough since we have correctly 
serviced everything.


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


Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-26 Thread Jani Nikula
On Fri, 19 Jan 2018, Chris Wilson  wrote:
> Quoting Paulo Zanoni (2018-01-19 18:10:51)
>> Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
>> > On 10/01/2018 10:16, Joonas Lahtinen wrote:
>> > > If these are in a later patch, should be squashed here.
>> > 
>> > It might be possible in some cases, or it might be quite
>> > challenging in others. Need to look into it but no promises. We
>> > might have to live with having place holders like this in the code
>> > which get removed by later patches/series. It's quite complex
>> > logistically to organise multiple series, written by multiple
>> > authors, at different times, and make it look 100% pretty. (And not
>> > just squash and butcher everything up at merge time.)
>> 
>> I agree with Tvrtko here and in the other points above. If we take
>> Joonas's point to the extreme, ICL enabling would be a single giant
>> patch. We have to accept that some things are going to be incomplete
>> in the series that enable a platform. We also have the alpha_support
>> option to protect us here, and CI to make sure ICL's incompleteness
>> doesn't affect the other platforms.
>
> Later in this series is a patch which fixes a bug in this patch. That
> certainly needs to be addressed. ;)

Might be helpful to point that out...

As to the larger point of squashing stuff, it's hard to make the
division into patches for large enabling series just right. Sometimes
it's just an arbitrary choice that's been made at some point to not
bloat the patches too much and to not make the rebasing unnecessarily
hard. All other things being equal, I'd err toward whatever gets us
closer to merging the patches.

BR,
Jani.





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

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-19 Thread Chris Wilson
Quoting Paulo Zanoni (2018-01-19 18:10:51)
> Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
> > On 10/01/2018 10:16, Joonas Lahtinen wrote:
> > > If these are in a later patch, should be squashed here.
> > 
> > It might be possible in some cases, or it might be quite challenging
> > in 
> > others. Need to look into it but no promises. We might have to live
> > with 
> > having place holders like this in the code which get removed by
> > later 
> > patches/series. It's quite complex logistically to organise multiple 
> > series, written by multiple authors, at different times, and make it 
> > look 100% pretty. (And not just squash and butcher everything up at 
> > merge time.)
> 
> I agree with Tvrtko here and in the other points above. If we take
> Joonas's point to the extreme, ICL enabling would be a single giant
> patch. We have to accept that some things are going to be incomplete in
> the series that enable a platform. We also have the alpha_support
> option to protect us here, and CI to make sure ICL's incompleteness
> doesn't affect the other platforms.

Later in this series is a patch which fixes a bug in this patch. That
certainly needs to be addressed. ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-19 Thread Paulo Zanoni
Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
> On 10/01/2018 10:16, Joonas Lahtinen wrote:
> > On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > v2: Rebase.
> > > 
> > > v3:
> > >* Remove DPF, it has been removed from SKL+.
> > >* Fix -internal rebase wrt. execlists interrupt handling.
> > > 
> > > v4: Rebase.
> > > 
> > > v5:
> > >* Updated for POR changes. (Daniele Ceraolo Spurio)
> > >* Merged with irq handling fixes by Daniele Ceraolo Spurio:
> > >* Simplify the code by using gen8_cs_irq_handler.
> > >* Fix interrupt handling for the upstream kernel.
> > > 
> > > v6:
> > >* Remove early bringup debug messages (Tvrtko)
> > >* Add NB about arbitrary spin wait timeout (Tvrtko)
> > > 
> > > v7 (from Paulo):
> > >* Don't try to write RO bits to registers.
> > >* Don't check for PCH types that don't exist. PCH interrupts
> > > are not
> > >  here yet.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Signed-off-by: Rodrigo Vivi 
> > > Signed-off-by: Daniele Ceraolo Spurio  > > l.com>
> > > Signed-off-by: Oscar Mateo 
> > > Signed-off-by: Paulo Zanoni 
> > 
> > 
> > 
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct
> > > drm_i915_private *dev_priv)
> > >   if (READ_ONCE(rps->interrupts_enabled))
> > >   return;
> > >   
> > > + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > > + return;
> > > +
> > >   spin_lock_irq(&dev_priv->irq_lock);
> > >   WARN_ON_ONCE(rps->pm_iir);
> > >   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
> > > dev_priv->pm_rps_events);
> > > @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct
> > > drm_i915_private *dev_priv)
> > >   if (!READ_ONCE(rps->interrupts_enabled))
> > >   return;
> > >   
> > > + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > > + return;
> > > +
> > 
> > These should be GEM_BUG_ON at most and should be the first thing in
> > function.
> 
> That would be a bit unfriendly when you are bringing up the codebase
> and 
> not all pices have been implemented yet. It gets removed later in
> the 
> series, or in a following series, whatever.
> 
> > >   spin_lock_irq(&dev_priv->irq_lock);
> > >   rps->interrupts_enabled = false;
> > >   
> > > @@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me
> > > *w)
> > >(W)->i915; 
> > >   \
> > >__fini_wedge((W)))
> > >   
> > > +static __always_inline void
> > > +gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> > > +{
> > > + gen8_cs_irq_handler(engine, iir, 0);
> > > +}
> > > +
> > > +static irqreturn_t
> > > +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32
> > > master_ctl)
> > 
> > This function could use some readability :)
> 
> Name or body?
> 
> > > +{
> > > + irqreturn_t ret = IRQ_NONE;
> > > + u16 irq[2][32];
> > > + u32 dw, ident;
> > > + unsigned long tmp;
> > > + unsigned int bank, bit, engine;
> > > + unsigned long wait_start, wait_end;
> > > +
> > > + memset(irq, 0, sizeof(irq));
> > > +
> > > + for (bank = 0; bank < 2; bank++) {
> > > + if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
> > 
> > Invert condition and use continue;
> > 
> > > + dw =
> > > I915_READ_FW(GEN11_GT_INTR_DW(bank));
> > > + if (!dw)
> > > + DRM_ERROR("GT_INTR_DW%u
> > > blank!\n", bank);
> > 
> > Probably needs a more appropriate action, GEM_BUG_ON if we've never
> > seen this on HW.
> 
> To early to know. TBD.
> 
> > > + tmp = dw;
> > > + for_each_set_bit(bit, &tmp, 32) {
> > > + I915_WRITE_FW(GEN11_IIR_REG_SELE
> > > CTOR(bank), 1 << bit);
> > 
> > BIT(bit)
> > 
> > + newline here
> 
> Yes sir!
> 
> > 
> > > + wait_start = local_clock() >>
> > > 10;
> > > + /* NB: Specs do not specify how
> > > long to spin wait.
> > > +  * Taking 100us as an educated
> > > guess */
> > > + wait_end = wait_start + 100;
> > > + do {
> > > + ident =
> > > I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
> > > + } while (!(ident &
> > > GEN11_INTR_DATA_VALID) &&
> > > +  !time_after((unsigned
> > > long)local_clock() >> 10, wait_end));
> > 
> > Uh oh, not a really nice thing to do in IRQ handler :( We should
> > probably look at some actual delay numbers and not do this.
> 
> Too early to know. TBD. Spec wants us to busy poll and doesn't
> specify 
> the timeout. Chris also complained and we chatted about this on IRC, 
> guess you missed this particular stream of conversation.


And so did I. What was the summary of the conversation? What did you
two conclude should be d

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-19 Thread Tvrtko Ursulin


On 10/01/2018 10:16, Joonas Lahtinen wrote:

On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:

From: Tvrtko Ursulin 

v2: Rebase.

v3:
   * Remove DPF, it has been removed from SKL+.
   * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
   * Updated for POR changes. (Daniele Ceraolo Spurio)
   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
   * Simplify the code by using gen8_cs_irq_handler.
   * Fix interrupt handling for the upstream kernel.

v6:
   * Remove early bringup debug messages (Tvrtko)
   * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
   * Don't try to write RO bits to registers.
   * Don't check for PCH types that don't exist. PCH interrupts are not
 here yet.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 





+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(&dev_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (!READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+


These should be GEM_BUG_ON at most and should be the first thing in
function.


That would be a bit unfriendly when you are bringing up the codebase and 
not all pices have been implemented yet. It gets removed later in the 
series, or in a following series, whatever.



spin_lock_irq(&dev_priv->irq_lock);
rps->interrupts_enabled = false;
  
@@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me *w)

 (W)->i915;  \
 __fini_wedge((W)))
  
+static __always_inline void

+gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+{
+   gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)


This function could use some readability :)


Name or body?


+{
+   irqreturn_t ret = IRQ_NONE;
+   u16 irq[2][32];
+   u32 dw, ident;
+   unsigned long tmp;
+   unsigned int bank, bit, engine;
+   unsigned long wait_start, wait_end;
+
+   memset(irq, 0, sizeof(irq));
+
+   for (bank = 0; bank < 2; bank++) {
+   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {


Invert condition and use continue;


+   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+   if (!dw)
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);


Probably needs a more appropriate action, GEM_BUG_ON if we've never
seen this on HW.


To early to know. TBD.


+   tmp = dw;
+   for_each_set_bit(bit, &tmp, 32) {
+   I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
<< bit);


BIT(bit)

+ newline here


Yes sir!




+   wait_start = local_clock() >> 10;
+   /* NB: Specs do not specify how long to spin 
wait.
+* Taking 100us as an educated guess */
+   wait_end = wait_start + 100;
+   do {
+   ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
+   } while (!(ident & GEN11_INTR_DATA_VALID) &&
+!time_after((unsigned long)local_clock() 
>> 10, wait_end));


Uh oh, not a really nice thing to do in IRQ handler :( We should
probably look at some actual delay numbers and not do this.


Too early to know. TBD. Spec wants us to busy poll and doesn't specify 
the timeout. Chris also complained and we chatted about this on IRC, 
guess you missed this particular stream of conversation.



+
+   if (!(ident & GEN11_INTR_DATA_VALID))
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
out!\n",
+ bank, bit);
+
+   irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+   if (!irq[bank][bit])
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u 
blank!\n",
+ bank, bit);


DRM_ERROR again seems like bit of an understatement for interrupt.


Precedent in "master control interrupt lied" messages. Can be revisited 
when it is known how the real silicon behaves.




+ newline here


+  

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-10 Thread Paulo Zanoni
Em Qua, 2018-01-10 às 12:16 +0200, Joonas Lahtinen escreveu:
> On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:
> > From: Tvrtko Ursulin 
> > 
> > v2: Rebase.
> > 
> > v3:
> >   * Remove DPF, it has been removed from SKL+.
> >   * Fix -internal rebase wrt. execlists interrupt handling.
> > 
> > v4: Rebase.
> > 
> > v5:
> >   * Updated for POR changes. (Daniele Ceraolo Spurio)
> >   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
> >   * Simplify the code by using gen8_cs_irq_handler.
> >   * Fix interrupt handling for the upstream kernel.
> > 
> > v6:
> >   * Remove early bringup debug messages (Tvrtko)
> >   * Add NB about arbitrary spin wait timeout (Tvrtko)
> > 
> > v7 (from Paulo):
> >   * Don't try to write RO bits to registers.
> >   * Don't check for PCH types that don't exist. PCH interrupts are
> > not
> > here yet.
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Daniele Ceraolo Spurio  > com>
> > Signed-off-by: Oscar Mateo 
> > Signed-off-by: Paulo Zanoni 
> 
> 
> 
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct
> > drm_i915_private *dev_priv)
> > if (READ_ONCE(rps->interrupts_enabled))
> > return;
> >  
> > +   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > +   return;
> > +
> > spin_lock_irq(&dev_priv->irq_lock);
> > WARN_ON_ONCE(rps->pm_iir);
> > WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & dev_priv-
> > >pm_rps_events);
> > @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct
> > drm_i915_private *dev_priv)
> > if (!READ_ONCE(rps->interrupts_enabled))
> > return;
> >  
> > +   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > +   return;
> > +
> 
> These should be GEM_BUG_ON at most and should be the first thing in
> function.
> 
> > spin_lock_irq(&dev_priv->irq_lock);
> > rps->interrupts_enabled = false;
> >  
> > @@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me
> > *w)
> >  (W)->i915; 
> > \
> >  __fini_wedge((W)))
> >  
> > +static __always_inline void
> > +gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> > +{
> > +   gen8_cs_irq_handler(engine, iir, 0);
> > +}
> > +
> > +static irqreturn_t
> > +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32
> > master_ctl)
> 
> This function could use some readability :)
> 
> > +{
> > +   irqreturn_t ret = IRQ_NONE;
> > +   u16 irq[2][32];
> > +   u32 dw, ident;
> > +   unsigned long tmp;
> > +   unsigned int bank, bit, engine;
> > +   unsigned long wait_start, wait_end;
> > +
> > +   memset(irq, 0, sizeof(irq));
> > +
> > +   for (bank = 0; bank < 2; bank++) {
> > +   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
> 
> Invert condition and use continue;
> 
> > +   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
> > +   if (!dw)
> > +   DRM_ERROR("GT_INTR_DW%u blank!\n",
> > bank);
> 
> Probably needs a more appropriate action, GEM_BUG_ON if we've never
> seen this on HW.
> 
> > +   tmp = dw;
> > +   for_each_set_bit(bit, &tmp, 32) {
> > +   I915_WRITE_FW(GEN11_IIR_REG_SELECT
> > OR(bank), 1 << bit);
> 
> BIT(bit)
> 
> + newline here
> 
> > +   wait_start = local_clock() >> 10;
> > +   /* NB: Specs do not specify how
> > long to spin wait.
> > +* Taking 100us as an educated
> > guess */
> > +   wait_end = wait_start + 100;
> > +   do {
> > +   ident =
> > I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
> > +   } while (!(ident &
> > GEN11_INTR_DATA_VALID) &&
> > +!time_after((unsigned
> > long)local_clock() >> 10, wait_end));
> 
> Uh oh, not a really nice thing to do in IRQ handler :( We should
> probably look at some actual delay numbers and not do this.
> 
> > +
> > +   if (!(ident &
> > GEN11_INTR_DATA_VALID))
> > +   DRM_ERROR("INTR_IDENTITY_R
> > EG%u:%u timed out!\n",
> > + bank, bit);
> > +
> > +   irq[bank][bit] = ident &
> > GEN11_INTR_ENGINE_MASK;
> > +   if (!irq[bank][bit])
> > +   DRM_ERROR("INTR_IDENTITY_R
> > EG%u:%u blank!\n",
> > + bank, bit);
> 
> DRM_ERROR again seems like bit of an understatement for interrupt.
> 
> + newline here
> 
> > +   I915_WRITE_FW(GEN11_INTR_IDENTITY_
> > REG(bank), ident);
> > +   }
> 
> + newline here
> 
> > +   I915_WRITE_FW(GEN11_GT_INTR_DW(bank), dw);
> > +   }
> > +   }
> > +
> > +   if (irq[0][GEN11_RCS0]) {
> 

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-10 Thread Joonas Lahtinen
On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:
> From: Tvrtko Ursulin 
> 
> v2: Rebase.
> 
> v3:
>   * Remove DPF, it has been removed from SKL+.
>   * Fix -internal rebase wrt. execlists interrupt handling.
> 
> v4: Rebase.
> 
> v5:
>   * Updated for POR changes. (Daniele Ceraolo Spurio)
>   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
>   * Simplify the code by using gen8_cs_irq_handler.
>   * Fix interrupt handling for the upstream kernel.
> 
> v6:
>   * Remove early bringup debug messages (Tvrtko)
>   * Add NB about arbitrary spin wait timeout (Tvrtko)
> 
> v7 (from Paulo):
>   * Don't try to write RO bits to registers.
>   * Don't check for PCH types that don't exist. PCH interrupts are not
> here yet.
> 
> Signed-off-by: Tvrtko Ursulin 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Oscar Mateo 
> Signed-off-by: Paulo Zanoni 



> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
> *dev_priv)
>   if (READ_ONCE(rps->interrupts_enabled))
>   return;
>  
> + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> + return;
> +
>   spin_lock_irq(&dev_priv->irq_lock);
>   WARN_ON_ONCE(rps->pm_iir);
>   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
> dev_priv->pm_rps_events);
> @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
> *dev_priv)
>   if (!READ_ONCE(rps->interrupts_enabled))
>   return;
>  
> + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> + return;
> +

These should be GEM_BUG_ON at most and should be the first thing in
function.

>   spin_lock_irq(&dev_priv->irq_lock);
>   rps->interrupts_enabled = false;
>  
> @@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me *w)
>(W)->i915; \
>__fini_wedge((W)))
>  
> +static __always_inline void
> +gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> +{
> + gen8_cs_irq_handler(engine, iir, 0);
> +}
> +
> +static irqreturn_t
> +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)

This function could use some readability :)

> +{
> + irqreturn_t ret = IRQ_NONE;
> + u16 irq[2][32];
> + u32 dw, ident;
> + unsigned long tmp;
> + unsigned int bank, bit, engine;
> + unsigned long wait_start, wait_end;
> +
> + memset(irq, 0, sizeof(irq));
> +
> + for (bank = 0; bank < 2; bank++) {
> + if (master_ctl & GEN11_GT_DW_IRQ(bank)) {

Invert condition and use continue;

> + dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
> + if (!dw)
> + DRM_ERROR("GT_INTR_DW%u blank!\n", bank);

Probably needs a more appropriate action, GEM_BUG_ON if we've never
seen this on HW.

> + tmp = dw;
> + for_each_set_bit(bit, &tmp, 32) {
> + I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
> << bit);

BIT(bit)

+ newline here

> + wait_start = local_clock() >> 10;
> + /* NB: Specs do not specify how long to spin 
> wait.
> +  * Taking 100us as an educated guess */
> + wait_end = wait_start + 100;
> + do {
> + ident = 
> I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
> + } while (!(ident & GEN11_INTR_DATA_VALID) &&
> +  !time_after((unsigned 
> long)local_clock() >> 10, wait_end));

Uh oh, not a really nice thing to do in IRQ handler :( We should
probably look at some actual delay numbers and not do this.

> +
> + if (!(ident & GEN11_INTR_DATA_VALID))
> + DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
> out!\n",
> +   bank, bit);
> +
> + irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
> + if (!irq[bank][bit])
> + DRM_ERROR("INTR_IDENTITY_REG%u:%u 
> blank!\n",
> +   bank, bit);

DRM_ERROR again seems like bit of an understatement for interrupt.

+ newline here

> + I915_WRITE_FW(GEN11_INTR_IDENTITY_REG(bank), 
> ident);
> + }

+ newline here

> + I915_WRITE_FW(GEN11_GT_INTR_DW(bank), dw);
> + }
> + }
> +
> + if (irq[0][GEN11_RCS0]) {
> + gen11_cs_irq_handler(dev_priv->engine[RCS],
> +  irq[0][GEN11_RCS0]);
> + ret = IRQ_HANDLED;
> + }
> +
> + if (irq[0][GEN11_BCS]) {
> + gen11_cs_irq_handler(dev_priv->engine[BCS],
> +   

[Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

2018-01-09 Thread Paulo Zanoni
From: Tvrtko Ursulin 

v2: Rebase.

v3:
  * Remove DPF, it has been removed from SKL+.
  * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
  * Updated for POR changes. (Daniele Ceraolo Spurio)
  * Merged with irq handling fixes by Daniele Ceraolo Spurio:
  * Simplify the code by using gen8_cs_irq_handler.
  * Fix interrupt handling for the upstream kernel.

v6:
  * Remove early bringup debug messages (Tvrtko)
  * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
  * Don't try to write RO bits to registers.
  * Don't check for PCH types that don't exist. PCH interrupts are not
here yet.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 210 
 drivers/gpu/drm/i915/intel_pm.c |   7 +-
 2 files changed, 216 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c6548e2c..49fb8d60f770 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (READ_ONCE(rps->interrupts_enabled))
return;
 
+   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
+   return;
+
spin_lock_irq(&dev_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (!READ_ONCE(rps->interrupts_enabled))
return;
 
+   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
+   return;
+
spin_lock_irq(&dev_priv->irq_lock);
rps->interrupts_enabled = false;
 
@@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
+static __always_inline void
+gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+{
+   gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
+{
+   irqreturn_t ret = IRQ_NONE;
+   u16 irq[2][32];
+   u32 dw, ident;
+   unsigned long tmp;
+   unsigned int bank, bit, engine;
+   unsigned long wait_start, wait_end;
+
+   memset(irq, 0, sizeof(irq));
+
+   for (bank = 0; bank < 2; bank++) {
+   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
+   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+   if (!dw)
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
+   tmp = dw;
+   for_each_set_bit(bit, &tmp, 32) {
+   I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
<< bit);
+   wait_start = local_clock() >> 10;
+   /* NB: Specs do not specify how long to spin 
wait.
+* Taking 100us as an educated guess */
+   wait_end = wait_start + 100;
+   do {
+   ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
+   } while (!(ident & GEN11_INTR_DATA_VALID) &&
+!time_after((unsigned 
long)local_clock() >> 10, wait_end));
+
+   if (!(ident & GEN11_INTR_DATA_VALID))
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
out!\n",
+ bank, bit);
+
+   irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+   if (!irq[bank][bit])
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u 
blank!\n",
+ bank, bit);
+   I915_WRITE_FW(GEN11_INTR_IDENTITY_REG(bank), 
ident);
+   }
+   I915_WRITE_FW(GEN11_GT_INTR_DW(bank), dw);
+   }
+   }
+
+   if (irq[0][GEN11_RCS0]) {
+   gen11_cs_irq_handler(dev_priv->engine[RCS],
+irq[0][GEN11_RCS0]);
+   ret = IRQ_HANDLED;
+   }
+
+   if (irq[0][GEN11_BCS]) {
+   gen11_cs_irq_handler(dev_priv->engine[BCS],
+irq[0][GEN11_BCS]);
+   ret = IRQ_HANDLED;
+   }
+
+   for (engine = 0; engine < 4; engine++) {
+   if (irq[1][GEN11_VCS(engine)]) {
+   gen11_cs_irq_handler(dev_priv->engine[_VCS(engine)],
+irq[1][GEN11_VCS(engine)]);
+   ret = IRQ_HANDL