[Intel-gfx] [PATCH] drm/i915: manage PCH PLLs separately from pipes
Eugeni Dodonov
eugeni at dodonov.net
Mon Apr 23 23:08:47 CEST 2012
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.html>
More information about the Intel-gfx
mailing list