Re: [PATCH 2/2] drm/i915: don't disable DP port after a failed link training

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Jan 16, 2014 at 08:39:38PM +0000, Chris Wilson wrote:
> On Thu, Jan 16, 2014 at 06:01:28PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 16, 2014 at 5:58 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
> > >> The driver shouldn't disable the DP port itself, but let userspace do it
> > >> through a modeset. See the previous patch for the reasoning.
> > >
> > > Eh, this occurs not just during link detection, but also during
> > > intel_enable_dp, so this comment does not hold.  The biggest
> > > issue of this function is that it can fail but never propagates
> > > that failure, which itself breaks the users and API expectations,
> > > as neither the driver or userspace is aware that it is required to
> > > takeaction.
> > 
> > Yeah, but imo that's a separate issue - atm we kill the DP port, which
> > stops the pipe, which is something our code never expects. Resulting
> > in piles of funny bug reports from angry users who's machine got stuck
> > because of this.
> 
> But this alone will not stop the bug reports - the display will still be
> blank but kernel/userspace will continue to believe that the modeset
> took place.
> 
> I did not say that the patch was not sensible, just insufficient ;-)

Well if we're lucky the next modeset works, or the 2nd display still
works, or at least X isn't stuck and maybe apps can still autosave. I
agree it's not the full solution, but it should be quite a bit better than
what we currently do ;-)

The other issue is that atm I don't have a good idea for how we could wire
this up correctly. In a way for all other outputs we don't tell userspace
that stuff went wrong either ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch