At Thu, 10 May 2012 11:06:46 +0200, Daniel Vetter wrote: > > On Thu, May 10, 2012 at 10:40:52AM +0200, Takashi Iwai wrote: > > At Thu, 10 May 2012 10:29:19 +0200, > > Daniel Vetter wrote: > > > > > > On Thu, May 10, 2012 at 08:34:43AM +0200, Takashi Iwai wrote: > > > > At Wed, 25 Apr 2012 10:14:51 +0200, > > > > Takashi Iwai wrote: > > > > > > > > > > At Thu, 19 Apr 2012 20:11:53 +0200, > > > > > Takashi Iwai wrote: > > > > > > > > > > > > At Thu, 19 Apr 2012 13:55:04 -0400, > > > > > > Adam Jackson wrote: > > > > > > > > > > > > > > On Thu, 2012-04-19 at 18:10 +0200, Takashi Iwai wrote: > > > > > > > > > > > > > > > This patch adds a flag to disable the hotplug during PM operation for > > > > > > > > avoiding such a race. > > > > > > > > > > > > > > > > Cc: <stable at kernel.org> > > > > > > > > Signed-off-by: Takashi Iwai <tiwai at suse.de> > > > > > > > > > > > > > > This seems simpler (untested): > > > > > > > > > > > > This looks promising. I'll ask a test with your patch. > > > > > > > > > > Tester reported a positive feedback. But he also experienced with a > > > > > blank screen after a couple of S4 resumes. Now it's being checked > > > > > whether it's a regression by the patch or not. > > > > > > > > It seems unrelated with the patch itself. So, from my side, > > > > Reviewed-by: Takashi Iwai <tiwai at suse.de> > > > > > > > > Adam, could you resubmit it with a proper sign-off so that it can be > > > > merged for 3.4 or 3.5, preferably with Cc to stable kernel? > > > > > > Note that > > > > > > daniel at phenom:~/linux/src$ git show > > > 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8 > > > commit 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8 > > > Author: Chris Wilson <chris at chris-wilson.co.uk> > > > Date: Tue Apr 24 22:59:41 2012 +0100 > > > > > > drm/i915: Unconditionally initialise the interrupt workers > > > > > > in drm-intel-next is closes a race around suspend/resume that could lead > > > to an oops somewhere on resume. > > > > I don't think it's missing hotplug initializations. It's no Oops but > > the race between the resume procedure being processed and the hotplug > > work triggered during the resume procedure. > > This patch is not just for hotplug, but for all the delayed work and timer > stuff the driver does. And we _do_ have a bug report that leaking the rps > work (for snb+ turbo mode) across either a s/r cycle or a gpu reset kills > the driver. Yes, but my point is that Chris's patch (at least the commit above alone) won't fix the problem we faced. Takashi
