On Mon, Apr 23, 2012 at 10:59, Eugeni Dodonov <[email protected]> wrote:
> On Fri, Apr 20, 2012 at 13:11, Chris Wilson <[email protected]>wrote: > >> From: Jesse Barnes <[email protected]> >> >> 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 <[email protected]> (up to v2) >> Signed-off-by: Chris Wilson <[email protected]> (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 <[email protected]> > Also, I think I am feeling brave enough now to add a: Tested-by: Eugeni Dodonov <[email protected]> after giving it a run on on SNB and IVB here. -- Eugeni Dodonov <http://eugeni.dodonov.net/>
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
