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@xxxxxxxxx> > > --- > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
