On 06/15/2015 01:14 PM, Damien Lespiau wrote:
On Mon, Jun 15, 2015 at 01:54:40PM +0200, Daniel Vetter wrote:
On Wed, Jun 03, 2015 at 03:45:08PM +0300, Mika Kahola wrote:
From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Signed-off-by: Mika Kahola <mika.kahola@xxxxxxxxx>
This patch needs to be extended to also cover the recently added
skl_max_scale. Tvrtko has recently written a patch to add some checks to
that code too, would be good to resurrect that too. Chandra can help with
any questions wrt the skl scaler code.
Not quite I'm afraid. The CDCLK used in skl_max_scale() has to be part
of the atomic state, even bumping CDCLK if possible/needed.
If you use the cached cdclk in skl_max_scale(), it won't do the right
thing when CDCLK is off (ie cached frew is the fallback 24Mhz ref clock)
and we try to do the first modeset before waking up the display.
I filed a bug about it already to track it:
https://bugs.freedesktop.org/show_bug.cgi?id=90874
I know nothing about these specific clocks, but FWIW, my patch was only
about enabling new platforms - making skl_max_scale more robust in cases
where clock querying does not yet work correctly.
My reasoning was based on a comment from Ville that one of those two
clocks must never be lower than the other.
So it sounded reasonable to ignore such cases ie. assume no scaling is
possible and allow a normal (unscaled) modeset to succeed rather than
fail it and display nothing.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
