On Tue, Jan 24, 2012 at 10:24:21AM -0800, Jesse Barnes wrote: > On Mon, 23 Jan 2012 20:40:27 +0100 > Daniel Vetter <daniel at ffwll.ch> wrote: > > > On Sat, Jan 21, 2012 at 08:36:38PM -0800, Keith Packard wrote: > > > On Sun, 22 Jan 2012 01:36:48 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > This was completely spamming dmesg on my i855gm. > > > > > > This comes from intel_disable_pll, which wants to turn the pll off, but > > > if the pipe is still active, it won't be able to. This seems bad to me. > > > > I honestly can't reconcile your comment with the code&patch. Afaics > > - the pll disable code checks for the pipe a quirk and does an early exit > > before mucking around with the hw and calling assert_pipe. > > - assert_pipe only does a WARN and the patch only changes whether we hit > > that WARN. All reg reads/writes should be unchanged. > > - the backtrace I'm seeing goes through crtc_disable. > > Ah ok so it's coming from the new pipe disabled check Chris added. > Patch looks fine... and reminds me to be puzzled about the pipe a force > quirk on 855. :) Ok, I've queued this for next with an improved commit msg stating that this was only shortly introduced in -next (plus citing the offending commit). Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
