Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression
129 views
Skip to first unread message
Kevin Fenzi
Dec 22, 2012, 4:40:02 PM12/22/12
to
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...@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.
kevin
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...@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.
kevin
Takashi Iwai
Jan 8, 2013, 10:30:02 AM1/8/13
to
At Sat, 22 Dec 2012 14:23:24 -0700,
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.
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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.
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kevin Fenzi
Jan 9, 2013, 7:10:02 PM1/9/13
to
On Tue, 08 Jan 2013 16:26:38 +0100
Takashi Iwai <ti...@suse.de> wrote:
> 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.
Thanks for the answer! :)
Takashi Iwai <ti...@suse.de> wrote:
> 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.
kevin
Kevin Fenzi
Jan 12, 2013, 1:50:01 PM1/12/13
to
- 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
hda-verb-27187 [001] .... 78907.305214: hda_get_response: [0:0]
val=0
hda-verb-27187 [001] .... 78907.305214: hda_power_count: [0:0]
power_count=0, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.682478: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683330: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683335: hda_power_count: [0:0]
power_count=3, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683336: hda_send_cmd: [0:0]
val=103a047
alsa-sink-17958 [000] .... 78933.683378: hda_get_response: [0:0]
val=0
alsa-sink-17958 [000] .... 78933.683379: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683380: hda_power_count: [0:0]
power_count=3, power_on=1, power_transition=0
...
kevin
Takashi Iwai
Jan 13, 2013, 4:10:01 AM1/13/13
to
At Sat, 12 Jan 2013 11:40:24 -0700,
Yes these are what I'd like to check.
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.
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.
Kevin Fenzi
Mar 10, 2013, 2:00:02 PM3/10/13
to
On Sun, 13 Jan 2013 10:06:41 +0100
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
> 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.
Please let me know if there's anything I can do to move this along or
try. ;(
kevin
Takashi Iwai
Mar 11, 2013, 4:00:02 AM3/11/13
to
At Sun, 10 Mar 2013 11:44:02 -0600,
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.
> > 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.
0 new messages