On Fri, 20 Apr 2012 17:11:53 +0100 Chris Wilson <chris at chris-wilson.co.uk> wrote: > From: Jesse Barnes <jbarnes at virtuousgeek.org> > > PCH PLLs aren't required for outputs on the CPU, so we shouldn't just > treat them as part of the pipe. > > So split the code out and manage PCH PLLs separately, allocating them > when needed or trying to re-use existing PCH PLL setups when the timings > match. > > v2: add num_pch_pll field to dev_priv (Daniel) > don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) > put register offsets in pll struct (Chris) > > v3: Decouple enable/disable of PLLs from get/put. > v4: Track temporary PLL disabling during modeset > v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni) > v6: Avoid mishandling allocation failure by embedding the small array of > PLLs into the device struct > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org> (up to v2) > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> (v3+) > --- Tested-by: Jesse Barnes <jbarnes at virtuousgeek.org> Only comment is that the ->on tracking bugs me a little. We seem to have a hard time keeping our cached values in sync with hardware in general (CRTC active and DPMS state for example), but that shouldn't get in the way of merging this fix. This one needs lots of QA too, like the last one. Thanks, -- Jesse Barnes, Intel Open Source Technology Center
