From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: Improve irq handling after gpu resets
Date: Mon, 26 May 2014 11:36:33 +0300 [thread overview]
Message-ID: <20140526083633.GE27580@intel.com> (raw)
In-Reply-To: <1400789902-31759-1-git-send-email-daniel.vetter@ffwll.ch>
On Thu, May 22, 2014 at 10:18:21PM +0200, Daniel Vetter wrote:
> Currently we do a full re-init of all interrupts after a gpu hang.
> Which is pretty bad since we don't restore the interrupts we've
> enabled at runtime correctly. Even with that addressed it's rather
> horribly race.
>
> But on g4x and later we only reset the gt and not the entire gpu.
> Which means we only need to reset the GT interrupt bits. Which has the
> nice benefit that vblank waits, pipe CRC interrupts and everything
> else display related just keeps on working.
>
> The downside is that gt interrupt handling (i.e. ring->get/put_irq) is
> still racy. But as long as the gpu hang reliably wakes all waters and
> we have a short time where the refcount drops to 0 we'll recover. So
> not that bad really.
>
> v2: Ville noticed that GTIMR and PMIMR don't get cleared, only the
> subordinate per-ring registers. So let's rip out all the interrupt dancing.
> The FIXME comment is still required though since the ring irq handling
> happens at the per-ring interrupt mask registers, too.
>
> Testcase: igt/kms_flip/vblank-vs-hang
> Testcase: igt/kms_pipe_crc_basic/hang-*
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both patches:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
And to answer you earlier question, yes things seemd to work fine after
a GPU reset if I didn't touch the interrupt registers. In fact I also
tried killing most of the gem_hw_init() stuff (basically just left
ring->init(), l3_remap, and context enable) and things still seemed to
work just fine.
> ---
> drivers/gpu/drm/i915/i915_drv.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c83c83b74bf4..7ae906c811bb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -811,17 +811,17 @@ int i915_reset(struct drm_device *dev)
> }
>
> /*
> - * FIXME: This is horribly race against concurrent pageflip and
> - * vblank wait ioctls since they can observe dev->irqs_disabled
> - * being false when they shouldn't be able to.
> + * FIXME: This races pretty badly against concurrent holders of
> + * ring interrupts. This is possible since we've started to drop
> + * dev->struct_mutex in select places when waiting for the gpu.
> */
> - drm_irq_uninstall(dev);
> - drm_irq_install(dev, dev->pdev->irq);
>
> - /* rps/rc6 re-init is necessary to restore state lost after the
> - * reset and the re-install of drm irq. Skip for ironlake per
> + /*
> + * rps/rc6 re-init is necessary to restore state lost after the
> + * reset and the re-install of gt irqs. Skip for ironlake per
> * previous concerns that it doesn't respond well to some forms
> - * of re-init after reset. */
> + * of re-init after reset.
> + */
> if (INTEL_INFO(dev)->gen > 5)
> intel_reset_gt_powersave(dev);
I'm suspecting that GPU reset doesn't affect the RPS/RC6 stuff either.
But I suppose it shouldn't really hurt anything to do it, so it's just
something to look into if we want to reduce the amount of stuff we do
at reset.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-05-26 8:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 15:56 [PATCH 1/5] drm/i915: Add fifo underrun reporting state to debugfs Daniel Vetter
2014-05-22 15:56 ` [PATCH 2/5] drm/i915: Fix up fifo underrun tracking, take N Daniel Vetter
2014-05-22 16:55 ` Ville Syrjälä
2014-05-22 20:10 ` Daniel Vetter
2014-05-23 8:11 ` Ville Syrjälä
2014-05-23 8:21 ` Daniel Vetter
2014-05-26 8:09 ` Ville Syrjälä
2014-05-26 8:11 ` Daniel Vetter
2014-05-22 15:56 ` [PATCH 3/5] drm/i915: Disable gpu reset on i965g/gm Daniel Vetter
2014-05-22 15:56 ` [PATCH 4/5] drm/i915: Inline ilk/gen8_irq_reset Daniel Vetter
2014-05-22 15:56 ` [PATCH 5/5] drm/i915: Improve irq handling after gpu resets Daniel Vetter
2014-05-22 16:51 ` Ville Syrjälä
2014-05-22 17:06 ` Ville Syrjälä
2014-05-22 20:12 ` Daniel Vetter
2014-05-22 20:18 ` [PATCH 1/2] " Daniel Vetter
2014-05-22 20:18 ` [PATCH 2/2] drm/i915: Extract gen8_gt_irq_reset Daniel Vetter
2014-05-26 8:36 ` Ville Syrjälä [this message]
2014-05-26 10:48 ` [PATCH 1/2] drm/i915: Improve irq handling after gpu resets Daniel Vetter
2014-05-22 17:02 ` [PATCH 1/5] drm/i915: Add fifo underrun reporting state to debugfs Ville Syrjälä
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=20140526083633.GE27580@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.