[Intel-gfx] [PATCH] drm/i915: manage PCH PLLs separately from pipes

[Eugeni Dodonov]

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.html>