Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Jani Nikula <jani.nikula@linux.intel.com>]

On Thu, 01 Jun 2017, Imre Deak <imre.deak@intel.com> wrote:
> On Thu, Jun 01, 2017 at 04:58:50PM +0300, Ville Syrjälä wrote:
>> On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote:
>> > On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> > > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
>> > >> Atm disabling either DP or eDP outputs can generate a spurious short
>> > >> pulse interrupt. The reason is that after disabling the port the source
>> > >> will stop sending a valid stream data, while the sink expects either a
>> > >> valid stream or the idle pattern. Since neither of this is sent the sink
>> > >> assumes (after an arbitrary delay) that the link is lost and requests
>> > >> for link retraining with a short pulse.
>> > >> 
>> > >> The spurious pulse is a real problem at least for eDP panels with long
>> > >> power-off / power-cycle delays: as part of disabling the output we
>> > >> disable the panel power. The subsequent spurious short pulse handling
>> > >> will have to turn the power back on, which means the driver has to do a
>> > >> redundant wait for the power-off and power-cycle delays. During system
>> > >> suspend this leads to an unnecessary delay up to ~1s on systems with
>> > >> such panels as reported by Rui.
>> > >> 
>> > >> To fix this put the sink to DPMS D3 state before turning off the port.
>> > >> According to the DP spec in this state the sink should not request
>> > >> retraining. This is also what we do already on pre-ddi platforms.
>> > >> 
>> > >> As an alternative I also tried configuring the port to send idle pattern
>> > >> - which is against BSPec - and leave the port in normal mode before
>> > >> turning off the port. Neither of these resolved the problem.
>> > >> 
>> > >> Cc: Zhang Rui <rui.zhang@intel.com>
>> > >> Cc: David Weinehall <david.weinehall@linux.intel.com>
>> > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > >> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
>> > >> Signed-off-by: Imre Deak <imre.deak@intel.com>
>> > >
>> > > Makes sense to me.
>> > 
>> > I wonder if we should write D0 on hotplug.
>> 
>> D0 is the default power state IIRC, so when you plug something in it
>> should automagically go into D0. That's actually a slight problem
>> power-wise if there's no subsequent modeset to drop it into D3.
>
> There was this DP->VGA adaptor that seems to require that we set D0
> explicitly:
> https://bugs.freedesktop.org/show_bug.cgi?id=99114#c5
>
> But it's an odd behaviour, the DPCD read itself succeeds, only reading a
> certain register fails (DPCD_SINK_COUNT). Based on the DP spec a sink
> should respond to AUX transfers even after being put to D3, possibly
> with a longer wake-up delay (up to 20ms AFAIR).

Also [1] where AFAICT there isn't even a hotplug after D3.

BR,
Jani.



[1] https://bugs.freedesktop.org/show_bug.cgi?id=101044

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx