[Intel-gfx] [PATCH V3] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

[Daniel Vetter]

On Wed, Feb 10, 2016 at 05:37:20PM -0800, Marc Herbert wrote:
> On 10/02/16 06:27, Ville Syrjälä wrote:
> > On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.taylor at intel.com wrote:
> >> From: Clint Taylor <clinton.a.taylor at intel.com>
> >>
> >> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> >> to set cdclk based on the max required pixel clock based on VCO
> >> selected.
> >>
> >> The vco should be tracked at the atomic level and all CRTCs updated if
> >> the required vco is changed. At this time the eDP pll is configured
> >> inside the encoder which has no visibility into the atomic state.
> > 
> > Yes it does. The passed in pipe_config is the crtc's state. And
> > if you want to store the thing in the top level atomic state you
> > just dig up that up from the crtc state:
> > to_intel_atomic_state(pipe_config->base.state) 
> > or something along those lines).
> 
> Hi, I'm writing this message with Clint. We understand the following:
> 
> - This V3 patch as it is now is fixing many use cases for hardware that has been
>   on the shelves for months.
> 
> - It does not fix all use cases with future eDP 1.4 panels.
>   Example: boot with external monitor and eDP 1.4 lid closed; then lid is
>   opened and causes a VCO change. However such cases are not supported yet anyway! 
>   If this happens today, the CD clock will move to some uncontrolled value
>   and the pipelines will NOT be reprogrammed. So this patch does *not regress* any
>   use case - not even future use cases.
> 
> - Present and future use cases can be addressed in two consecutive patches: first
>   this V3 patch now; then atomic modeset VCO tracking later. This won't increase
>   development complexity in any way. In other words, the second patch will almost not
>   change the code of the first patch.
> 
> - From a validation perspective this first patch can be validated today with today's
>   hardware. The second patch cannot be validated yet because eDP 1.4 hardware
>   is not readily available yet.
> 
> - Getting atomic modeset VCO tracking right will take additional development time.
>   And... did I mention validation already?
> 
> - This first patch is fixing many use cases for hardware that has been
>   on the shelves for months, including failures to reach max resolution.
> 
> So - you saw me coming from a distance - can we agree on splitting this work
> in two separate patches so we can merge this first V3 patch now? Products have
> been needing this for months, thanks!

Atomic is the new world, we need this thing to be atomic. Please work
together with Mika Kahola (who's done all the dynamic cdclk infrastucture
together with Ville).

Wrt validation: That's what we have testcases and CI for, plus in-kernel
consistency checks of atomic state.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch