From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Richter Subject: Re: Broken in 3.10.10 (was: Questions on display pipes on 835GM) Date: Mon, 07 Oct 2013 23:58:59 +0200 Message-ID: <52532EA3.90200@math.tu-berlin.de> References: <1377298288-2830-1-git-send-email-przanoni@gmail.com> <20130830172552.GN11428@intel.com> <29427_1378101775_52242A0E_29427_747_1_20130902060151.GE9374@phenom.ffwll.local> <524FCEE8.4010307@math.tu-berlin.de> <29761_1380973482_524FFBA9_29761_4042_1_20131005114432.GE9395@intel.com> <52504289.10107@math.tu-berlin.de> <29761_1381001928_52506AC8_29761_5606_1_20131005193904.GX31334@phenom.ffwll.local> <52509C3D.2020603@math.tu-berlin.de> <5132_1381149082_5252A99A_5132_80_1_CAKMK7uHkOJ=urFKCacocf_i+6YL9Azf5vK=Au-kRJMi=sNBP1Q@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from medousa.rus.uni-stuttgart.de (medousa.rus.uni-stuttgart.de [129.69.192.4]) by gabe.freedesktop.org (Postfix) with ESMTP id 105B6E5C94 for ; Mon, 7 Oct 2013 14:59:09 -0700 (PDT) In-Reply-To: <5132_1381149082_5252A99A_5132_80_1_CAKMK7uHkOJ=urFKCacocf_i+6YL9Azf5vK=Au-kRJMi=sNBP1Q@mail.gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On 06.10.2013 01:37, Daniel Vetter wrote: > On Sun, Oct 6, 2013 at 1:09 AM, Thomas Richter wrote: >>> Now if you follow the callchains around the dvo->dpms callbacks the DVO >>> port and DPLL are always enabled at that point in time, so I think we >>> should be able to fix this all by moving the modeset code around to that >>> place. >> >> >> True, but probably with the high-speed bit in the wrong state. > > We always program the dpll with the high-speed select bit set when > using it for a DVO port, so this will also automatically be taken care > of. Actually, I was testing with the 3.10.10 kernel here. Unfortunately, I need to tell you that 3.11.4 and 3.12.0-rc.4 does *not work at all*. All I get on these kernel releases is a blank screen, though with a working mouse cursor. Apparently, nothing is rendered on the screen at all. Otherwise, it does the same as 3.10.10, namely lock up if I connect an external monitor during bootstrap. For 3.12.0-rc.4, if I connect the monitor *after* bootup on the gdm login, I first see nothing on the external screen, and the mouse pointer on the internal TFT. Then, after logging in blindly, the cursor appears at the external monitor, the system beeps and then crashes and hangs. Thus, sorry, but: broken in 3.11 and up... Sorry for the bad news, please try try again. Thomas