On Sat, Jun 18, 2016 at 12:29:24AM +0300, Imre Deak wrote: > Atm on ILK we attempt to detect if eDP is present even if LVDS was > already detected and an encoder for it was registered. This involves > trying to read out the eDP EDID, which in turn needs the same power > sequencer that LVDS uses. Poking at the VDD line at an unexpected time > may or may not interfere with the LVDS panel, but it's probably safer to > prevent this. Registering both an LVDS and an eDP connector would also > present a similar problem accessing the shared PPS at any point later in > an unexpected way. > > We also need this to be able fix PPS initialization before its first use > in the next patch. For that we want to be sure that PPS is not in use > by LVDS. > > v2: > - Split out the PPS init fix to a separate patch. (Chris) > - Add comment about eDP init depending on LVDS init. (Chris) > - Make the use of the intel_encoder ptr less error prone. > > CC: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > CC: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx> Main worry here is what if the LVDS detection was false? (I believe that LVDS/eDP doesn't coexist...) I'm just wondering if calling lvds_encoder->post_disable() to force the LVDS off in this circumstance is viable. Worst case (false eDP, real LVDS), we lose the output on the console until a mode is restored by fbdev. Best case (false LVDS, real eDP) we don't regress detection of eDP. (Or knowing the internals, we could just do a save restore of LVDS PP_CONTROL around the eDP detection.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx