From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: hda: Bug - (timing?) problem causes DP monitor to not get activated Date: Fri, 28 Feb 2014 14:23:34 +0100 Message-ID: References: <20140228104726.GA3730@sn-dd496.dd.secunet.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 836D026510C for ; Fri, 28 Feb 2014 14:23:34 +0100 (CET) In-Reply-To: <20140228104726.GA3730@sn-dd496.dd.secunet.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Daniel Martin Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Fri, 28 Feb 2014 11:47:27 +0100, Daniel Martin wrote: > > Hi, > > I'm having a bug here, where the loaded hda module causes some (timing?) > problem resulting in a monitor connected to the DP not to get active. > I can reproduce this on a Lenovo X201 and T410 (Ironlake) sitting on a > docking station, which has a monitor (Dell U2410) connected to a DP. > > Steps to reproduce: > 1. boot with the laptop at the docking station and the monitor plugged in > 2. start the X-Server > ... output on LVDS and DP is okay > 3. disable the DP: xrandr --output LVDS1 --preferred --output DP1 --off > ... output on LVDS - okay > 4. switch to DP: xrandr --output LVDS1 --off --output DP1 --preferred > ... DP _usually_ doesn't gets active, it turn off into suspend state > > Why I think that it is related to the hda module? If I boot a kernel > without the hda module step 4 always works. When having the hda module > loaded I need some luck and some iterations of step 3 and 4 to activate > the monitor at the DP. > > I verified that the problem exists in kernel v3.13.1 and v3.14-rc4. > > > The logs I have attached have been created on the T410 with kernel > v3.14-rc4. The first alsa-info....txt has been created right after > booting, the second one after step 4 failed. The kernel has been build > with all alsa debug options I could find, the config is attached as > well, and the kernel has been booted with drm.debug=0xe - this might be > to much, but it shows pretty clear when the outputs have been switched. > > I hope that anyone can read something usefull - something that went > wrong - out of the log files. My unexercised eye can't spot anything > obvious. > > If more logs are necessary, I'll send them. Could you rather post it to intel-gfx ML? (Please keep me in Cc.) For IronLake, i915_request_power_well() must be irrelevant, thus it can't be the HD-audio's runtime PM refcount. There is no other direct communication with the graphics device, but only via HD-audio's controller and codec; i.e. it's communicated via a normal hardware channel. If anything in the graphic output doesn't work in that situation, the likely culprit is rather in the graphics side. thanks, Takashi