All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH] drm/i915: disable interrupts earlier in the driver unload code
Date: Wed, 24 Apr 2013 11:51:31 +0200	[thread overview]
Message-ID: <20130424095131.GP6169@phenom.ffwll.local> (raw)
In-Reply-To: <20130424093516.GC11689@cantiga.alporthouse.com>

On Wed, Apr 24, 2013 at 10:35:16AM +0100, Chris Wilson wrote:
> On Wed, Apr 24, 2013 at 11:19:20AM +0200, Daniel Vetter wrote:
> > Our rps code relies on the interrupts being off to prevent re-arming
> > of the work items at inopportune moments.
> > 
> > Also drop the redundant cancel_work for the main rps work,
> > disable_gt_powersave already takes care of that.
> > 
> > Finally add a WARN_ON to ensure we obey that piece of ordering
> > constraint. Long term I want to lock down the setup/teardown code in a
> > similar way to how we painstakingly check modeset sequence constraints
> > already.
> 
> Reminds me, did we every get around to flushing our deferred hw tasks
> upon suspend? I've a funny feeling that is still missing.

I think with the unification between suspend and driver unload we're
mostly there. Like I've said I think it's time to encode all these
constraints properly into debug asserts, but the problem I have is that I
don't have a good idea to encode things like "this work item is now
guaranteed to never get re-armed again".

There's the object debug code in the kernel, but that only fires when the
work/timer is actually armed. Since a lot of the work stuff happens rarely
or is not delayed that's not really good enough ...

Ideas for this very much welcome, since the lack of these self-checks
makes any attempt to solve this for real futile. devres.c might help a bit
in preventing resource leaks and tidy up the code, but it doesn't help at
all for correct ordering and cleanup of async workers/timers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2013-04-24  9:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24  9:19 [PATCH] drm/i915: disable interrupts earlier in the driver unload code Daniel Vetter
2013-04-24  9:35 ` Chris Wilson
2013-04-24  9:51   ` Daniel Vetter [this message]
2013-04-24 10:08 ` Jani Nikula
2013-04-24 10:21   ` Daniel Vetter
2013-04-24 10:58     ` Jani Nikula

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=20130424095131.GP6169@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    /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.