On Tue, Apr 22, 2014 at 06:25:12PM -0300, Paulo Zanoni wrote: > 2014-04-11 6:02 GMT-03:00 Daniel Vetter <daniel@xxxxxxxx>: > > On Thu, Apr 10, 2014 at 10:52:26AM -0700, Ben Widawsky wrote: > >> On Thu, Apr 10, 2014 at 10:50:43AM -0700, Ben Widawsky wrote: > >> > On Thu, Apr 10, 2014 at 09:04:47AM +0200, Daniel Vetter wrote: > >> > > This reverts commit 4b28a1f3ef55a3b0b68dbab1fe6dbaf18e186710. > >> > > > >> > > This patch duct-tapes over some issue in the current bdw rps patches > >> > > which must wait with enabling rc6/rps until the very first batch has > >> > > been submitted by userspace. > >> > > > >> > > But those patches aren't merged yet, and for upstream we need to have > >> > > an in-kernel emission of the very first batch. I shouldn't have > >> > > merged this patch so let's revert it again. > >> > > >> > I said this on the mailing last before you merged the patch. > >> > >> 20140402050338.GB13824@xxxxxxxxxxxx > > > > 20140402145813.GV7225@phenom.ffwll.local will explain things. > > There's now a regression report pointing to the revert: > https://bugs.freedesktop.org/show_bug.cgi?id=77565 . > > What is the proposed solution now? Just WARN and still avoid the > infinite loop? Or keep the infinite loop and leave the bug open? > Disable BDW runtime PM? I've thought that we can only hit this with the as-yet unmerged rc6 patches on bdw, so I'm really confused why this blows up now? In any case I've thought Imre has stumbled over a similar issue on byt and he has a fix to prevent runtime pm until the delayed rps init has run. I've assigned the bug to him. Still confused why this suddenly blew up ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
