From: Theodore Tso <tytso@mit.edu>
To: Takashi Iwai <tiwai@suse.de>
Cc: Roland Dreier <rdreier@cisco.com>, linux-kernel@vger.kernel.org
Subject: Re: snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s
Date: Thu, 22 Nov 2007 12:42:42 -0500 [thread overview]
Message-ID: <20071122174242.GB17181@thunk.org> (raw)
In-Reply-To: <s5hhcjqhkty.wl%tiwai@suse.de>
On Tue, Nov 13, 2007 at 04:43:05AM +0100, Takashi Iwai wrote:
> > By the way, the "polling mode" seems to work OK: I still get normal
> > playback of music etc.
>
> Yes, the polling mode should work in most cases, too.
Out of curiosity, how many wakeups/interrupts are involved with the
sound going into polling mode? Is it going to make a difference as
far as battery life is concerned?
I'm seeing the message:
hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x005f000c
on my X61s laptop as well, where the last_cmd varies quite a bit.
Over the past two weeks, I've seen last cmd be:
0x003f000c, 0x004f000c, 0x005f000c, 0x006f000c, 0x00db8000,
0x011b8000, 0x011ba000, 0x012ba000, 0x012f000c, 0x013f000c,
0x014f000d, 0x019f000c, 0x020b0001, 0x020b0003, 0x020b2000,
0x020b2001, 0x020b2002, 0x025f0012
Interestingly, when I was using a post 2.6.24-rc1 and -rc2 kernel, I
was getting a lot of these "switching polling to mode messages",
usually within a minute of the machine booting. Now that I have
switched to a recent rc3 kernel, they seem to have largely gone away.
Looking at my kernel, it looks like the patch you suggested to Roland
was *not* applied, and "git log sound/pci/hda" shows that the only
change to that directory was a patch from Ingo Molnar that I had
cherry picked from LKML. Given that we were doing a
schedule_timeout_uninterruptible for a full second, that certainly
seems to be a likely candidate for why we were getting the response
timeout message! Does this analysis make sense to you?
Regards,
- Ted
commit 2f7e58208e0d59ca6e4ad1561f47391d4efa19fa
Author: Ingo Molnar <mingo@elte.hu>
Date: Fri Nov 16 11:35:05 2007 -0500
snd hda suspend latency: shorten codec read
not sleeping for every codec read/write but doing a short udelay and
a conditional reschedule has cut suspend+resume latency by about 1
second on my T60.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3fa0f97..62b9fb3 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -555,7 +555,8 @@ static unsigned int azx_rirb_get_response(struct hda_codec *codec)
}
if (!chip->rirb.cmds)
return chip->rirb.res; /* the last value */
- schedule_timeout_uninterruptible(1);
+ udelay(10);
+ cond_resched();
} while (time_after_eq(timeout, jiffies));
if (chip->msi) {
next prev parent reply other threads:[~2007-11-22 22:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 22:48 snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s Roland Dreier
2007-11-12 7:39 ` Takashi Iwai
2007-11-12 16:59 ` Roland Dreier
2007-11-12 13:41 ` Takashi Iwai
2007-11-12 18:46 ` Roland Dreier
2007-11-13 3:43 ` Takashi Iwai
2007-11-14 16:39 ` Roland Dreier
2007-11-14 13:19 ` Takashi Iwai
2007-11-14 17:22 ` Roland Dreier
2007-11-14 13:33 ` Takashi Iwai
2007-11-22 17:42 ` Theodore Tso [this message]
2007-11-23 7:06 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071122174242.GB17181@thunk.org \
--to=tytso@mit.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox