From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752341Ab3CKHy4 (ORCPT ); Mon, 11 Mar 2013 03:54:56 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34357 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638Ab3CKHyy (ORCPT ); Mon, 11 Mar 2013 03:54:54 -0400 Date: Mon, 11 Mar 2013 08:54:51 +0100 Message-ID: From: Takashi Iwai To: Kevin Fenzi Cc: linux-kernel@vger.kernel.org Subject: Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression In-Reply-To: <20130310114402.2953273c@jelerak.scrye.com> References: <20121222142324.73586307@jelerak.scrye.com> <20130112114024.551d37b5@jelerak.scrye.com> <20130310114402.2953273c@jelerak.scrye.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Sun, 10 Mar 2013 11:44:02 -0600, Kevin Fenzi wrote: > > On Sun, 13 Jan 2013 10:06:41 +0100 > Takashi Iwai wrote: > > > At Sat, 12 Jan 2013 11:40:24 -0700, > > Kevin Fenzi wrote: > > > > > > On Tue, 08 Jan 2013 16:26:38 +0100 > > > Takashi Iwai wrote: > > > > > > > At Sat, 22 Dec 2012 14:23:24 -0700, > > > > Kevin Fenzi wrote: > > > > > > > > > > Greetings. > > > > > > > > > > I've got an issue with sound on my t510. It started in the late > > > > > 3.4.x kernels. Sound works on boot and for 5-10min after, then > > > > > the speakers stop working at all. > > > > > > > > > > I posted a while back on the alsa-users list, and someone else > > > > > had the same issue: > > > > > > > > > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html > > > > > > > > > > It seems that the speakers(?) are getting moved to state D3 and > > > > > turning off. You can manually get it to come back for a few > > > > > minutes by using hda-verb to move it back to D0: > > > > > > > > > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0 > > > > > > > > > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd > > > > > is my alsa-info. > > > > > > > > > > I'd file a bug on the alsa bug tracker, but it still seems to be > > > > > down (for many months now?). No response on alsa-users, so now > > > > > that I have a bit of time, I am posting here in hopes someone > > > > > can look. ;) > > > > > > > > > > Happy to provide more info or try things. > > > > > > > > It's a known problem that some people have already reported, but > > > > currently no clue who actually turns down the pin to D3. > > > > Conexant guys wrote me that the codec doesn't do it by itself, > > > > and the driver neither, AFAIK. A possible answer is the > > > > firmware / BIOS, but who knows. > > > > > > > > In anyway, could you try to trace the hd-audio events and see > > > > whether the power down is *not* issued by the driver when you see > > > > this state? See Documentation/sound/alsa/HD-Audio.txt, the > > > > section "Tracepoints" for a brief instruction. > > > > > > ok. I am not sure I am doing the right thing, but: > > > > > > - echo 1 > /sys/kernel/debug/tracing/events/hda/enable > > > - Run hda-verb to get sound working. > > > - Play a video to confirm. > > > - check /sys/kernel/debug/tracing/trace > > > - Wait a while. > > > - Play another sound that doesn't come out of speakers. > > > - check /sys/kernel/debug/tracing/trace for anything new. > > > > > > The only things I see in the trace file are my hda-verb call, and > > > the sounds playing. Nothing else. > > > > > > I then tried to duplicate it, but the trace file didn't seem to > > > update properly. Is there some reset needed? > > > > > > Or is this not the info you were looking for? > > > > > > hda-verb-27187 [001] .... 78907.305149: hda_power_count: > > > [0:0] power_count=1, power_on=1, power_transition=0 > > > hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0] > > > val=1f70500 > > > > Yes these are what I'd like to check. > > Sorry for the long delay here... was the above info of any use? These lines alone don't. Please check what I had wrote in below. > > The point to check here is exactly which verbs have been sent, and how > > is the codec power status. Check what is the last power_on value when > > the problem appears. If it's power_on=1, it's fine. > > And you can concentrate on the verb to NID 0x1f, namely, hda_send_cmd > > with a value 1fxxxxx. In the example above, 1f70500 means it's > > setting the power state of 0x1f to D0. thanks, Takashi