From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [REGRESSION] i915: failure to interoperate with HP ZR30w using an X230 Date: Sat, 3 Nov 2012 11:21:58 +0100 Message-ID: <20121103102158.GP5755@phenom.ffwll.local> References: <87hapcqu97.fsf@intel.com> <87zk34gok8.fsf@intel.com> <20121030203221.GA4537@thunk.org> <20121103005831.GA3978@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id EF6219E9DB for ; Sat, 3 Nov 2012 03:20:52 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id n13so1671470eaa.36 for ; Sat, 03 Nov 2012 03:20:51 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20121103005831.GA3978@thunk.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Theodore Ts'o , Jani Nikula , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Fri, Nov 02, 2012 at 08:58:31PM -0400, Theodore Ts'o wrote: > Ping? > > On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote: > > On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote: > > > > [1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel > > > > > > Hmm, actually not. Either drm-intel-fixes branch, or Linus' master. > > > > Confirmed, the drm-intel-fixes branch from Daniel's tree > > (3.7.0-rc2-00031-g1623392) works fine for me. > > > > Do you know which commit(s) are likely to have fixed the problem, so we > > can cherry pick the appropriate fix(es) to the 3.6.x tree? Well, we know for sure that fdi link training is broken - it doesn't match at all what the spec says we should do. I've been working on this lately, since in quite a few circumstances the link train fails without the relevent bits indicating so. While testing I've also noticed that this entire thing is highly timing dependent, e.g. denpending upon which desktop is running and which tool I use to change the configuration it fails or succeeds. So I have no suggestions for what could help your system and what should get backported, since the current code is still broken. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch