On Mon, Apr 23, 2012 at 10:59, Eugeni Dodonov <eugeni at dodonov.net> wrote: > 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> > Also, I think I am feeling brave enough now to add a: Tested-by: Eugeni Dodonov <eugeni.dodonov at intel.com> after giving it a run on on SNB and IVB here. -- Eugeni Dodonov <http://eugeni.dodonov.net/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120423/9670c59a/attachment.htm>