* [PATCH] drm/i915: Do hw quiescing first during unload
@ 2013-10-17 12:02 Chris Wilson
2013-10-17 19:07 ` Ben Widawsky
0 siblings, 1 reply; 8+ messages in thread
From: Chris Wilson @ 2013-10-17 12:02 UTC (permalink / raw)
To: intel-gfx
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_dma.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index fd848ef043c0..1781be7bf845 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1704,6 +1704,12 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
+ ret = i915_gem_suspend(dev);
+ if (ret) {
+ DRM_ERROR("failed to idle hardware: %d\n", ret);
+ return ret;
+ }
+
intel_gpu_ips_teardown();
if (HAS_POWER_WELL(dev)) {
@@ -1719,10 +1725,6 @@ int i915_driver_unload(struct drm_device *dev)
if (dev_priv->mm.inactive_shrinker.scan_objects)
unregister_shrinker(&dev_priv->mm.inactive_shrinker);
- ret = i915_gem_suspend(dev);
- if (ret)
- DRM_ERROR("failed to idle hardware: %d\n", ret);
-
io_mapping_free(dev_priv->gtt.mappable);
arch_phys_wc_del(dev_priv->gtt.mtrr);
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-17 12:02 [PATCH] drm/i915: Do hw quiescing first during unload Chris Wilson
@ 2013-10-17 19:07 ` Ben Widawsky
2013-10-17 19:37 ` Chris Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Ben Widawsky @ 2013-10-17 19:07 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> If we force the hw to idle as our first step during unload, we can abort
> the unload upon failure. Later we can probe whether the hardware remain
> active even after we try to shut it down.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
what we want?
> ---
> drivers/gpu/drm/i915/i915_dma.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index fd848ef043c0..1781be7bf845 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1704,6 +1704,12 @@ int i915_driver_unload(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
>
> + ret = i915_gem_suspend(dev);
> + if (ret) {
> + DRM_ERROR("failed to idle hardware: %d\n", ret);
> + return ret;
> + }
> +
> intel_gpu_ips_teardown();
>
> if (HAS_POWER_WELL(dev)) {
> @@ -1719,10 +1725,6 @@ int i915_driver_unload(struct drm_device *dev)
> if (dev_priv->mm.inactive_shrinker.scan_objects)
> unregister_shrinker(&dev_priv->mm.inactive_shrinker);
>
> - ret = i915_gem_suspend(dev);
> - if (ret)
> - DRM_ERROR("failed to idle hardware: %d\n", ret);
> -
> io_mapping_free(dev_priv->gtt.mappable);
> arch_phys_wc_del(dev_priv->gtt.mtrr);
>
> --
> 1.8.4.rc3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-17 19:07 ` Ben Widawsky
@ 2013-10-17 19:37 ` Chris Wilson
2013-10-17 21:04 ` Ben Widawsky
0 siblings, 1 reply; 8+ messages in thread
From: Chris Wilson @ 2013-10-17 19:37 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > If we force the hw to idle as our first step during unload, we can abort
> > the unload upon failure. Later we can probe whether the hardware remain
> > active even after we try to shut it down.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> what we want?
It may be mean, but it seems to me to be the right thing to do if we
cannot turn off the hardware to unload the driver...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-17 19:37 ` Chris Wilson
@ 2013-10-17 21:04 ` Ben Widawsky
2013-10-17 21:19 ` Chris Wilson
2013-10-18 7:36 ` Ville Syrjälä
0 siblings, 2 replies; 8+ messages in thread
From: Ben Widawsky @ 2013-10-17 21:04 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > If we force the hw to idle as our first step during unload, we can abort
> > > the unload upon failure. Later we can probe whether the hardware remain
> > > active even after we try to shut it down.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >
> > Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> > what we want?
>
> It may be mean, but it seems to me to be the right thing to do if we
> cannot turn off the hardware to unload the driver...
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
And what about my suggestion of simply using pci_clear_master?
--
Ben Widawsky, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-17 21:04 ` Ben Widawsky
@ 2013-10-17 21:19 ` Chris Wilson
2013-10-18 7:36 ` Ville Syrjälä
1 sibling, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2013-10-17 21:19 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote:
> On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> > On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > > If we force the hw to idle as our first step during unload, we can abort
> > > > the unload upon failure. Later we can probe whether the hardware remain
> > > > active even after we try to shut it down.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> > > what we want?
> >
> > It may be mean, but it seems to me to be the right thing to do if we
> > cannot turn off the hardware to unload the driver...
>
> And what about my suggestion of simply using pci_clear_master?
I have no idea.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-17 21:04 ` Ben Widawsky
2013-10-17 21:19 ` Chris Wilson
@ 2013-10-18 7:36 ` Ville Syrjälä
2013-10-18 18:09 ` Ben Widawsky
1 sibling, 1 reply; 8+ messages in thread
From: Ville Syrjälä @ 2013-10-18 7:36 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote:
> On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> > On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > > If we force the hw to idle as our first step during unload, we can abort
> > > > the unload upon failure. Later we can probe whether the hardware remain
> > > > active even after we try to shut it down.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> > > what we want?
> >
> > It may be mean, but it seems to me to be the right thing to do if we
> > cannot turn off the hardware to unload the driver...
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
>
> And what about my suggestion of simply using pci_clear_master?
Might that hang some boxes?
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-18 7:36 ` Ville Syrjälä
@ 2013-10-18 18:09 ` Ben Widawsky
2013-10-18 18:18 ` Ville Syrjälä
0 siblings, 1 reply; 8+ messages in thread
From: Ben Widawsky @ 2013-10-18 18:09 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Fri, Oct 18, 2013 at 10:36:30AM +0300, Ville Syrjälä wrote:
> On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote:
> > On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> > > On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > > > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > > > If we force the hw to idle as our first step during unload, we can abort
> > > > > the unload upon failure. Later we can probe whether the hardware remain
> > > > > active even after we try to shut it down.
> > > > >
> > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > >
> > > > Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> > > > what we want?
> > >
> > > It may be mean, but it seems to me to be the right thing to do if we
> > > cannot turn off the hardware to unload the driver...
> > > -Chris
> > >
> > > --
> > > Chris Wilson, Intel Open Source Technology Centre
> >
> > And what about my suggestion of simply using pci_clear_master?
>
> Might that hang some boxes?
>
Hmm, why are you thinking?
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Do hw quiescing first during unload
2013-10-18 18:09 ` Ben Widawsky
@ 2013-10-18 18:18 ` Ville Syrjälä
0 siblings, 0 replies; 8+ messages in thread
From: Ville Syrjälä @ 2013-10-18 18:18 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
On Fri, Oct 18, 2013 at 11:09:15AM -0700, Ben Widawsky wrote:
> On Fri, Oct 18, 2013 at 10:36:30AM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote:
> > > On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> > > > On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > > > > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > > > > If we force the hw to idle as our first step during unload, we can abort
> > > > > > the unload upon failure. Later we can probe whether the hardware remain
> > > > > > active even after we try to shut it down.
> > > > > >
> > > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > >
> > > > > Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield
> > > > > what we want?
> > > >
> > > > It may be mean, but it seems to me to be the right thing to do if we
> > > > cannot turn off the hardware to unload the driver...
> > > > -Chris
> > > >
> > > > --
> > > > Chris Wilson, Intel Open Source Technology Centre
> > >
> > > And what about my suggestion of simply using pci_clear_master?
> >
> > Might that hang some boxes?
> >
>
> Hmm, why are you thinking?
No particular reason. Just my well honed "hardware is often borked"
reflex.
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-10-18 18:18 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-17 12:02 [PATCH] drm/i915: Do hw quiescing first during unload Chris Wilson
2013-10-17 19:07 ` Ben Widawsky
2013-10-17 19:37 ` Chris Wilson
2013-10-17 21:04 ` Ben Widawsky
2013-10-17 21:19 ` Chris Wilson
2013-10-18 7:36 ` Ville Syrjälä
2013-10-18 18:09 ` Ben Widawsky
2013-10-18 18:18 ` Ville Syrjälä
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.