On Tue, May 27, 2014 at 10:24:14PM +0200, Daniel Vetter wrote: > On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote: > > On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote: > > > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > > > that it resets the whole common lane section of the PHY. This is > > > required on machines where the BIOS doesn't do this for us on boot or > > > resume to properly re-calibrate and get the PHY ready to transmit data. > > > > > > Without this patch, such machines won't resume correctly much of the time, > > > with the symptom being a 'port ready' timeout and/or a link training > > > failure. > > > > > > Note that simply asserting reset at suspend and de-asserting at resume > > > is not sufficient, nor is simply de-asserting at boot. Both of these > > > cases have been tested and have still been found to have failures on > > > some configurations. > > > > > > v2: extract simpler set_power_well function for use in reset_dpio (Imre) > > > move to reset_dpio (Daniel & Ville) > > > v3: don't reset if DPIO reset is already de-asserted (Imre) > > > > > > Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > > > > The series matches my understanding of the limitations of the PHY, so: > > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > All merged to dinq, thanks. > > > But if these limitations are real, then I think we would also need to > > adjust the power domains to power up all the wells whenever even a > > single one is required. > > > > This should be testable I think by simply: > > 1. disable both ports > > 2. enable one port > > 3. enable the other port > > > > At step 3. the common well is already up, so the TX wells for the second > > port should come up in some kind of poor state. > > Hm, if we need this we might forc a modeset for _all_ pipes on vlv, even > for unchanged ports. At elast as long as we enable something new. That > should make this work properly I hope. Yeah that would work too, but obviously would cause some blinking that might be a bit disturbing. But we may have such blinking already due to adjusting cdclk. If the blinking is disturbing for users we might want to have a knob for controlling it: either use less power but blink more, or waste a bit of power and blink less. But I don't know if anyone would really want to waste power. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
