Messages in this thread | | | Date | Sun, 10 Mar 2013 11:44:02 -0600 | From | Kevin Fenzi <> | Subject | Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression |
| |
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?
> 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. > > Last but not least, you can try my very latest code in sound-unstable > tree: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git > > Either master or test/hda-migrate branch contains the latest code for > Conexant codecs.
I'll note that the problem persists in 3.9.0-0.rc1
Please let me know if there's anything I can do to move this along or try. ;(
kevin [unhandled content-type:application/pgp-signature] | |