From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 2/2] drm/i915: don't disable DP port after a failed link training Date: Thu, 16 Jan 2014 22:27:37 +0100 Message-ID: <20140116212737.GD4770@phenom.ffwll.local> References: <1389890158-30938-1-git-send-email-imre.deak@intel.com> <1389890158-30938-2-git-send-email-imre.deak@intel.com> <20140116165814.GA4864@nuc-i3427.alporthouse.com> <20140116203938.GB4864@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by gabe.freedesktop.org (Postfix) with ESMTP id 6EBD6105A2E for ; Thu, 16 Jan 2014 13:27:42 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id o10so1382607eaj.32 for ; Thu, 16 Jan 2014 13:27:41 -0800 (PST) Content-Disposition: inline In-Reply-To: <20140116203938.GB4864@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Chris Wilson , Daniel Vetter , Imre Deak , intel-gfx List-Id: intel-gfx@lists.freedesktop.org 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 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