Messages in this thread | | | Date | Mon, 11 Mar 2013 08:54:51 +0100 | From | Takashi Iwai <> | Subject | Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression |
| |
At Sun, 10 Mar 2013 11:44:02 -0600, Kevin Fenzi wrote: > > On Sun, 13 Jan 2013 10:06:41 +0100 > Takashi Iwai <tiwai@suse.de> wrote: > > > At Sat, 12 Jan 2013 11:40:24 -0700, > > Kevin Fenzi wrote: > > > > > > On Tue, 08 Jan 2013 16:26:38 +0100 > > > Takashi Iwai <tiwai@suse.de> 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
| |