From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir
Date: Thu, 15 Feb 2018 20:35:22 +0200 [thread overview]
Message-ID: <20180215183522.GT5453@intel.com> (raw)
In-Reply-To: <151871040461.11261.1982076111992938940@mail.alporthouse.com>
On Thu, Feb 15, 2018 at 04:00:04PM +0000, Chris Wilson wrote:
> Quoting Mika Kuoppala (2018-02-15 15:21:33)
> > Chris Wilson <chris@chris-wilson.co.uk> writes:
> >
> > > Keep the master iir and use it to reduce the number of reads and writes
> > > to the GT iir array, i.e. only the bits marked as set by the master iir
> > > are valid inside GT iir array and will be handled during the interrupt.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 51 +++++++++++++++++++++++++----------------
> > > 1 file changed, 31 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > > index b886bd459acc..b7b377ba7b6e 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1416,6 +1416,14 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
> > > static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> > > u32 master_ctl, u32 gt_iir[4])
> > > {
> > > +#define GEN8_GT_IRQS (GEN8_GT_RCS_IRQ | \
> > > + GEN8_GT_BCS_IRQ | \
> > > + GEN8_GT_VCS1_IRQ | \
> > > + GEN8_GT_VCS2_IRQ | \
> > > + GEN8_GT_VECS_IRQ | \
> > > + GEN8_GT_PM_IRQ | \
> > > + GEN8_GT_GUC_IRQ)
> > > +
> > > if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
> > > gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0));
> > > if (gt_iir[0])
> > > @@ -1446,31 +1454,34 @@ static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> > > }
> > >
> > > static void gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
> > > - u32 gt_iir[4])
> > > + u32 master_ctl, u32 gt_iir[4])
> > > {
> > > - if (gt_iir[0]) {
> > > + if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
> > > gen8_cs_irq_handler(dev_priv->engine[RCS],
> > > gt_iir[0], GEN8_RCS_IRQ_SHIFT);
> > > gen8_cs_irq_handler(dev_priv->engine[BCS],
> > > gt_iir[0], GEN8_BCS_IRQ_SHIFT);
> > > }
> > >
> > > - if (gt_iir[1]) {
> > > + if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
> > > gen8_cs_irq_handler(dev_priv->engine[VCS],
> > > gt_iir[1], GEN8_VCS1_IRQ_SHIFT);
> > > gen8_cs_irq_handler(dev_priv->engine[VCS2],
> > > gt_iir[1], GEN8_VCS2_IRQ_SHIFT);
> > > }
> > >
> > > - if (gt_iir[3])
> > > + if (master_ctl & GEN8_GT_VECS_IRQ) {
> > > gen8_cs_irq_handler(dev_priv->engine[VECS],
> > > gt_iir[3], GEN8_VECS_IRQ_SHIFT);
> > > + }
> > >
> > > - if (gt_iir[2] & dev_priv->pm_rps_events)
> > > - gen6_rps_irq_handler(dev_priv, gt_iir[2]);
> > > + if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
> > > + if (gt_iir[2] & dev_priv->pm_rps_events)
> > > + gen6_rps_irq_handler(dev_priv, gt_iir[2]);
> > >
> > > - if (gt_iir[2] & dev_priv->pm_guc_events)
> > > - gen9_guc_irq_handler(dev_priv, gt_iir[2]);
> > > + if (gt_iir[2] & dev_priv->pm_guc_events)
> > > + gen9_guc_irq_handler(dev_priv, gt_iir[2]);
> > > + }
> > > }
> > >
> > > static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > @@ -2085,9 +2096,9 @@ static irqreturn_t cherryview_irq_handler(int irq, void *arg)
> > >
> > > do {
> > > u32 master_ctl, iir;
> > > - u32 gt_iir[4] = {};
> > > u32 pipe_stats[I915_MAX_PIPES] = {};
> > > u32 hotplug_status = 0;
> > > + u32 gt_iir[4];
> > > u32 ier = 0;
> > >
> > > master_ctl = I915_READ(GEN8_MASTER_IRQ) & ~GEN8_MASTER_IRQ_CONTROL;
> > > @@ -2140,7 +2151,7 @@ static irqreturn_t cherryview_irq_handler(int irq, void *arg)
> > > I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> > > POSTING_READ(GEN8_MASTER_IRQ);
> > >
> > > - gen8_gt_irq_handler(dev_priv, gt_iir);
> > > + gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
> > >
> > > if (hotplug_status)
> > > i9xx_hpd_irq_handler(dev_priv, hotplug_status);
> > > @@ -2675,10 +2686,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> > >
> > > static irqreturn_t gen8_irq_handler(int irq, void *arg)
> > > {
> > > - struct drm_device *dev = arg;
> > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > > + struct drm_i915_private *dev_priv = to_i915(arg);
> > > u32 master_ctl;
> > > - u32 gt_iir[4] = {};
> > > + u32 gt_iir[4];
> > >
> > > if (!intel_irqs_enabled(dev_priv))
> > > return IRQ_NONE;
> > > @@ -2690,18 +2700,19 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
> > >
> > > I915_WRITE_FW(GEN8_MASTER_IRQ, 0);
> > >
> > > - /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> > > - disable_rpm_wakeref_asserts(dev_priv);
> > > -
> > > /* Find, clear, then process each source of interrupt */
> > > gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
> > > - gen8_gt_irq_handler(dev_priv, gt_iir);
> > > - gen8_de_irq_handler(dev_priv, master_ctl);
> > > +
> > > + /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> > > + if (master_ctl & ~GEN8_GT_IRQS) {
> > > + disable_rpm_wakeref_asserts(dev_priv);
> > > + gen8_de_irq_handler(dev_priv, master_ctl);
> > > + enable_rpm_wakeref_asserts(dev_priv);
> > > + }
> > >
> > > I915_WRITE_FW(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> > > - POSTING_READ_FW(GEN8_MASTER_IRQ);
> > >
> > > - enable_rpm_wakeref_asserts(dev_priv);
> > > + gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
> >
> > You want to serve display first? Do you recommend the
> > same approach to gen11?
>
> The idea is that having squirrel the iir and acked the secondary
> sources, we re-enabled the primary interrupt so that we service the next
> interrupt quicker; whilst we continue to process the previous irq on
> this cpu. Not sure if it makes a big difference in the end, we have a
> lot of serialisation to overcome, but it's a nice consequence of Ville's
> cleanup of splitting the ack/processing of the sources.
I've occasionally pondered about moving the processing part to a thread,
with maybe leaving some super duper critical execlist stuff in the hard
irq part. Though I'm not sure if that would be siginificantly different
to just moving the entire thing into a thread, or just leaving it all
where it is now. Would need to collect some hard data I suppose.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-02-15 18:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 7:37 [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir Chris Wilson
2018-02-15 7:37 ` [PATCH 2/2] drm/i915: Prune gen8_gt_irq_handler Chris Wilson
2018-02-15 16:57 ` Chris Wilson
2018-02-15 17:04 ` Mika Kuoppala
2018-02-19 10:09 ` [PATCH v2] " Chris Wilson
2018-02-19 13:59 ` Mika Kuoppala
2018-02-19 14:12 ` Chris Wilson
2018-02-15 7:58 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Track GT interrupt handling using the master iir Patchwork
2018-02-15 8:14 ` ✓ Fi.CI.BAT: success " Patchwork
2018-02-15 13:31 ` ✓ Fi.CI.IGT: " Patchwork
2018-02-15 15:21 ` [PATCH 1/2] " Mika Kuoppala
2018-02-15 16:00 ` Chris Wilson
2018-02-15 18:35 ` Ville Syrjälä [this message]
2018-02-19 10:31 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Track GT interrupt handling using the master iir (rev2) Patchwork
2018-02-19 11:41 ` ✓ Fi.CI.IGT: " Patchwork
2018-02-19 15:51 ` Chris Wilson
2018-02-19 13:47 ` [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir Mika Kuoppala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180215183522.GT5453@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox