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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.