On Fri, Apr 20, 2012 at 13:11, 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+) > As I talked with Jesse and Daniel over irc, I hit some WARN with LPT with those patches, but it is not the fault of the patch itself as it is due to differences with Lynx Point/Haswell we have, for which I still reuse those code paths. In the end, I think we'll end up using a different path for Haswell-onwards for crtc enabling sequence, and those will be gone. So besides those items, the v6 looks correct to me, and works in my test cases, and I haven't found anything else to bikeshed about so far. So: Reviewed-by: Eugeni Dodonov <eugeni.dodonov at intel.com> -- Eugeni Dodonov <http://eugeni.dodonov.net/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120423/703a5267/attachment.htm>
