[Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0

[Daniel Vetter]

On Mon, Nov 17, 2014 at 07:28:28PM +0100, Daniel Vetter wrote:
> On Fri, Nov 14, 2014 at 05:24:35PM +0000, Damien Lespiau wrote:
> > Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> > index b5a279a..924f1ec 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -767,12 +767,20 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder,
> >  
> >  	pipe_config->port_clock = link_clock;
> >  
> > +	/*
> > +	 * On SKL the eDP DPLL (DPLL0 as we don't use SSC) is not part of the
> > +	 * shared DPLL framework and thus needs to be read out separately
> > +	 */
> > +	if (encoder->type == INTEL_OUTPUT_EDP)
> 
> Hw state readout shouldn't depend upon our sw state, and given the
> multiple personality nature of DDI ports I think this is the case here: We
> might have a different opinion than the bios guys about what's edp (it
> happened) or how consistently to apply this clock selection algo (also
> happened). So might be better to stuff this into the ddi clock readout
> code (the one where you patched away the WARN for DPLL0 I guess).

And after a night of pondering I stand correct on our irc discussion about
putting dpll0 into the shared dpll infrastructure - if the bios indeed
does something we don't expect and we don't properly track the use count
for dpll0 it'll blow up. So I guess we'll need indeed need that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch