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

[Marc Herbert]

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!

Cheers,

Marc