Message-ID: <s5h7gnhjvtq.wl%tiwai@suse.de>
Date:	Sun, 13 Jan 2013 10:06:41 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Kevin Fenzi <kevin@...ye.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

At Sat, 12 Jan 2013 11:40:24 -0700,
Kevin Fenzi wrote:
> 
> On Tue, 08 Jan 2013 16:26:38 +0100
> Takashi Iwai <tiwai@...e.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.

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.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists