Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Linus, please revert the commit 57a04513cb3 as now. The life can go well without this patch. hda_intel.c works for me in rc8. Many thanx to all Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote: > At Mon, 14 Jan 2008 16:03:22 -0500, > > Daniel Hazelton wrote: > > On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: > > > > > > > > Could this have anything to do with the following messages I've seen > > > > when trying -rc7 ? > > > > > > > > [7.760269] pnpacpi: exceeded the max number of mem resources: 12 > > > > > > Judging from Harald's report, it looks like a different problem. > > > The buggy patch (regarding HDA-intel) was, at least, already reverted > > > on Linus git tree. Could you give it a try? > > > > > > > > > Takashi > > > > Sorry, still no sound. Config, lspci and dmesg attached to help. System > > is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. > > Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? > > Anyway, try to change HZ=300. I got a report that HZ=1000 causes the > similar problem but HZ=300 not. > > > Takashi That did it. Looks like the hardware really is that sensitive to the timing. Strange, but I've seen worse. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Mon, 14 Jan 2008 16:03:22 -0500, Daniel Hazelton wrote: > > On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: > > > > > > > Could this have anything to do with the following messages I've seen when > > > trying -rc7 ? > > > > > > [7.760269] pnpacpi: exceeded the max number of mem resources: 12 > > > > Judging from Harald's report, it looks like a different problem. > > The buggy patch (regarding HDA-intel) was, at least, already reverted > > on Linus git tree. Could you give it a try? > > > > > > Takashi > > Sorry, still no sound. Config, lspci and dmesg attached to help. System is, > as > stated, Dell Inspiron 1420n running a 64bit kernel and userland. Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? Anyway, try to change HZ=300. I got a report that HZ=1000 causes the similar problem but HZ=300 not. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Mon, 14 Jan 2008 21:46:58 +0100, Harald Dunkel wrote: > > Dear Takashi-san, > > Takashi Iwai wrote: > > > > The "regression" was your original problem, no sound on rc7, which was > > fixed by reverting the patch. Now I'd like to know that my new patch > > doesn't break after reverting the broken patch. > > > > Seems that there was some misunderstanding: I thought your patch > for sigmatel.c was supposed to fix the "missing sound" problem, > too. > > > In short, try my patch on the latest Linus git tree. Check whether > > the sound still works. > > > > It does. > > rc7 plus the big "clean-up" patch for sigmatel.c plus hda_intel.c > taken from rc6 worked, too. Seems that I missed to mention it in a > previous EMail. OK, thanks. Then I'll queue this clean-up patch to ALSA tree. > > It's simply a delay. Basically Ingo's patch changed msleep() to > > udelay() to reduce *unneeded* delays. The function waits until the > > all pending commands are processed. The delay is simply to reduce the > > system load. And, now, changing this delay causes a problem > > surprisingly. > > > > I am glad to help, but could you please do me a favour? If I am > supposed to try some new version, then please create a complete(!) > patch using rc7 on kernel.org as the base, and send it as an > attachment using a unique filename. Very likely you have a much > better overview about the most recent kernel changes, but some > statements like "new patch" or "Ingo's patch" don't mean very much > to me. The "reverted" patch is a new patch, too, and AFAIK Ingo > reverted it, so maybe you can imagine that this is highly confusing. There are three patches. - Ingo's patch to reduce latency. This was applied after rc6, and reverted after rc7. - My first test patch - My second test patch (clean-up patch you tested lastly) > >> AFAICS I did use the mm branch. The command to grab the sources was > >> > >> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm > >> > >> Is this correct? > > > > No. You'd better to clone Linus git tree, then pull from alsa.git mm > > branch. > > > > % git-clone $LINUS/linux-2.6.git > > % cd linux-2.6 > > % git-pull $ALSA/alsa.git mm > > > > AFAICS there shouldn't be a difference to my one-liner, unless Linus' > and Alsa's git trees are out of sync. Is this correct? No, the second argument of git-clone is the destination directory to clone, not the branch to pick up. The cloned repo has all branches but doesn't point mm branch. And, Linus and ALSA git trees are likely out of sync. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Mon, 14 Jan 2008 16:03:22 -0500, Daniel Hazelton wrote: On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: snip Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 Judging from Harald's report, it looks like a different problem. The buggy patch (regarding HDA-intel) was, at least, already reverted on Linus git tree. Could you give it a try? Takashi Sorry, still no sound. Config, lspci and dmesg attached to help. System is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? Anyway, try to change HZ=300. I got a report that HZ=1000 causes the similar problem but HZ=300 not. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote: At Mon, 14 Jan 2008 16:03:22 -0500, Daniel Hazelton wrote: On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: snip Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 Judging from Harald's report, it looks like a different problem. The buggy patch (regarding HDA-intel) was, at least, already reverted on Linus git tree. Could you give it a try? Takashi Sorry, still no sound. Config, lspci and dmesg attached to help. System is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? Anyway, try to change HZ=300. I got a report that HZ=1000 causes the similar problem but HZ=300 not. Takashi That did it. Looks like the hardware really is that sensitive to the timing. Strange, but I've seen worse. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Linus, please revert the commit 57a04513cb3 as now. The life can go well without this patch. hda_intel.c works for me in rc8. Many thanx to all Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Dear Takashi-san, Takashi Iwai wrote: The "regression" was your original problem, no sound on rc7, which was fixed by reverting the patch. Now I'd like to know that my new patch doesn't break after reverting the broken patch. Seems that there was some misunderstanding: I thought your patch for sigmatel.c was supposed to fix the "missing sound" problem, too. In short, try my patch on the latest Linus git tree. Check whether the sound still works. It does. rc7 plus the big "clean-up" patch for sigmatel.c plus hda_intel.c taken from rc6 worked, too. Seems that I missed to mention it in a previous EMail. It's simply a delay. Basically Ingo's patch changed msleep() to udelay() to reduce *unneeded* delays. The function waits until the all pending commands are processed. The delay is simply to reduce the system load. And, now, changing this delay causes a problem surprisingly. I am glad to help, but could you please do me a favour? If I am supposed to try some new version, then please create a complete(!) patch using rc7 on kernel.org as the base, and send it as an attachment using a unique filename. Very likely you have a much better overview about the most recent kernel changes, but some statements like "new patch" or "Ingo's patch" don't mean very much to me. The "reverted" patch is a new patch, too, and AFAIK Ingo reverted it, so maybe you can imagine that this is highly confusing. >> AFAICS I did use the mm branch. The command to grab the sources was >> >> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm >> >> Is this correct? > > No. You'd better to clone Linus git tree, then pull from alsa.git mm > branch. > > % git-clone $LINUS/linux-2.6.git > % cd linux-2.6 > % git-pull $ALSA/alsa.git mm > AFAICS there shouldn't be a difference to my one-liner, unless Linus' and Alsa's git trees are out of sync. Is this correct? Sorry, I am more familiar with ClearCase and Accurev than with Git. Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Sat, 12 Jan 2008 12:11:20 -0500, Daniel Hazelton wrote: > > On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: > > Takashi Iwai wrote: > > > At Thu, 10 Jan 2008 23:02:53 +0100, > > > > > > Harald Dunkel wrote: > > >> Takashi Iwai wrote: > > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > > >>> that I'd like to apply later. > > >> > > >> Sorry, no sound. > > > > > > OK, but I'd like to know whether this makes no regression to rc6. > > > Could you check? > > > > > > Also, what exactly did you test? "No sound" means that no sound from > > > the headphone / line-out or from the speaker? > > > > > > One interesting test would be to increase the value of udelay() in the > > > reverted patch. What happens if it's set to 500? > > > > There is no udelay() in the reverted patch. If I replace "udelay(10)" > > by "udelay(500)" in the original rc7, then there is still no sound. > > > > This is like fishing in the dark. We've got a working version. Why not > > keep it? > > > > > > Regards > > > > Harri > > Could this have anything to do with the following messages I've seen when > trying -rc7 ? > > [7.760269] pnpacpi: exceeded the max number of mem resources: 12 Judging from Harald's report, it looks like a different problem. The buggy patch (regarding HDA-intel) was, at least, already reverted on Linus git tree. Could you give it a try? Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Sat, 12 Jan 2008 12:11:20 -0500, Daniel Hazelton wrote: On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace udelay(10) by udelay(500) in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 Judging from Harald's report, it looks like a different problem. The buggy patch (regarding HDA-intel) was, at least, already reverted on Linus git tree. Could you give it a try? Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Dear Takashi-san, Takashi Iwai wrote: The regression was your original problem, no sound on rc7, which was fixed by reverting the patch. Now I'd like to know that my new patch doesn't break after reverting the broken patch. Seems that there was some misunderstanding: I thought your patch for sigmatel.c was supposed to fix the missing sound problem, too. In short, try my patch on the latest Linus git tree. Check whether the sound still works. It does. rc7 plus the big clean-up patch for sigmatel.c plus hda_intel.c taken from rc6 worked, too. Seems that I missed to mention it in a previous EMail. It's simply a delay. Basically Ingo's patch changed msleep() to udelay() to reduce *unneeded* delays. The function waits until the all pending commands are processed. The delay is simply to reduce the system load. And, now, changing this delay causes a problem surprisingly. I am glad to help, but could you please do me a favour? If I am supposed to try some new version, then please create a complete(!) patch using rc7 on kernel.org as the base, and send it as an attachment using a unique filename. Very likely you have a much better overview about the most recent kernel changes, but some statements like new patch or Ingo's patch don't mean very much to me. The reverted patch is a new patch, too, and AFAIK Ingo reverted it, so maybe you can imagine that this is highly confusing. AFAICS I did use the mm branch. The command to grab the sources was git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm Is this correct? No. You'd better to clone Linus git tree, then pull from alsa.git mm branch. % git-clone $LINUS/linux-2.6.git % cd linux-2.6 % git-pull $ALSA/alsa.git mm AFAICS there shouldn't be a difference to my one-liner, unless Linus' and Alsa's git trees are out of sync. Is this correct? Sorry, I am more familiar with ClearCase and Accurev than with Git. Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Sat, 12 Jan 2008 10:41:21 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >>> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > > > There is no udelay() in the reverted patch. Hm? Ingo's patch replaces msleep(1) with udelay(10) + cond_resched(). This is the patch we're arguing. This was already reverted (based on your report) on git. > If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. Interesting... What about udelay(1000)? Then it'll be closer to msleep(1). > This is like fishing in the dark. We've got a working version. Why not > keep it? Yes, we are shooting in the dark now indeed. Honestly, I have no concrete idea why the patch breaks the sound initialization. It seems that Dell machines (or STAC codecs) have problems with the initialization timing. I don't think that all commands but only certain some command sequences that are so sensitive to the access timing. We need to identify this. Ingo's patch is basically a really nice fix. It reduces the unnecessary delay, especially improves resume speed much. I'd love to have it. And above all, I need to understand what is the real problem. Unfortunately, I have no this hardware and the precise h/w data, so must rely on testers and a guess work. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Fri, 11 Jan 2008 22:55:28 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >>> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > "Regression" sounds like a test suite to me, verifying that the > old problems didn't come back. Maybe you could send me a pointer? The "regression" was your original problem, no sound on rc7, which was fixed by reverting the patch. Now I'd like to know that my new patch doesn't break after reverting the broken patch. In short, try my patch on the latest Linus git tree. Check whether the sound still works. > Of course I didn't try that much yet. The kernel booted as expected, > I saw XWindow running, the mouse pointer was moving, etc. There was > just no sound, as before with rc7. Yeah, I know that it doesn't fix the rc7. > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > Speaker and first headphone are the same on this laptop. If I plugin > the headphone, then the tiny speakers are disconnected. But for the > last tests no headphone was plugged in. > > I tested it by running gnome-alsamixer. I tried to switch off and > on the mute buttons, change the volume and other sliders, etc. Hm. Looks like the problem appearing only with IDT STAC codecs. The symptom indicates that it's not about the EAPD for the speaker but in the deeper core initialization part... > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > > > I will try tomorrow. What exactly is this delay good for? It's simply a delay. Basically Ingo's patch changed msleep() to udelay() to reduce *unneeded* delays. The function waits until the all pending commands are processed. The delay is simply to reduce the system load. And, now, changing this delay causes a problem surprisingly. > >>> The perex/alsa.git mm branch on kernel.org has many fixes. Could you > >>> give it a try, too? > >>> > >> This version seems to work. But AFAICS it just reverts hda_intel.c back > >> to rc6 again, so this is no surprise. > > > > Use mm branch. The main branch is just an old Linus tree. > > > > AFAICS I did use the mm branch. The command to grab the sources was > > git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm > > Is this correct? No. You'd better to clone Linus git tree, then pull from alsa.git mm branch. % git-clone $LINUS/linux-2.6.git % cd linux-2.6 % git-pull $ALSA/alsa.git mm Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Fri, 11 Jan 2008 22:55:28 +0100, Harald Dunkel wrote: Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Regression sounds like a test suite to me, verifying that the old problems didn't come back. Maybe you could send me a pointer? The regression was your original problem, no sound on rc7, which was fixed by reverting the patch. Now I'd like to know that my new patch doesn't break after reverting the broken patch. In short, try my patch on the latest Linus git tree. Check whether the sound still works. Of course I didn't try that much yet. The kernel booted as expected, I saw XWindow running, the mouse pointer was moving, etc. There was just no sound, as before with rc7. Yeah, I know that it doesn't fix the rc7. Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? Speaker and first headphone are the same on this laptop. If I plugin the headphone, then the tiny speakers are disconnected. But for the last tests no headphone was plugged in. I tested it by running gnome-alsamixer. I tried to switch off and on the mute buttons, change the volume and other sliders, etc. Hm. Looks like the problem appearing only with IDT STAC codecs. The symptom indicates that it's not about the EAPD for the speaker but in the deeper core initialization part... One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? I will try tomorrow. What exactly is this delay good for? It's simply a delay. Basically Ingo's patch changed msleep() to udelay() to reduce *unneeded* delays. The function waits until the all pending commands are processed. The delay is simply to reduce the system load. And, now, changing this delay causes a problem surprisingly. The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. AFAICS I did use the mm branch. The command to grab the sources was git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm Is this correct? No. You'd better to clone Linus git tree, then pull from alsa.git mm branch. % git-clone $LINUS/linux-2.6.git % cd linux-2.6 % git-pull $ALSA/alsa.git mm Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Sat, 12 Jan 2008 10:41:21 +0100, Harald Dunkel wrote: Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. Hm? Ingo's patch replaces msleep(1) with udelay(10) + cond_resched(). This is the patch we're arguing. This was already reverted (based on your report) on git. If I replace udelay(10) by udelay(500) in the original rc7, then there is still no sound. Interesting... What about udelay(1000)? Then it'll be closer to msleep(1). This is like fishing in the dark. We've got a working version. Why not keep it? Yes, we are shooting in the dark now indeed. Honestly, I have no concrete idea why the patch breaks the sound initialization. It seems that Dell machines (or STAC codecs) have problems with the initialization timing. I don't think that all commands but only certain some command sequences that are so sensitive to the access timing. We need to identify this. Ingo's patch is basically a really nice fix. It reduces the unnecessary delay, especially improves resume speed much. I'd love to have it. And above all, I need to understand what is the real problem. Unfortunately, I have no this hardware and the precise h/w data, so must rely on testers and a guess work. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > There is no udelay() in the reverted patch. If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. > > This is like fishing in the dark. We've got a working version. Why not > keep it? > > > Regards > > Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a "pop" from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? "No sound" means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace "udelay(10)" by "udelay(500)" in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace udelay(10) by udelay(500) in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace udelay(10) by udelay(500) in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a pop from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp from 00:11:50:fa:d4:ba (capab=0x411 status=0 a id=2) [
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? "Regression" sounds like a test suite to me, verifying that the old problems didn't come back. Maybe you could send me a pointer? Of course I didn't try that much yet. The kernel booted as expected, I saw XWindow running, the mouse pointer was moving, etc. There was just no sound, as before with rc7. Also, what exactly did you test? "No sound" means that no sound from the headphone / line-out or from the speaker? Speaker and first headphone are the same on this laptop. If I plugin the headphone, then the tiny speakers are disconnected. But for the last tests no headphone was plugged in. I tested it by running gnome-alsamixer. I tried to switch off and on the mute buttons, change the volume and other sliders, etc. One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? I will try tomorrow. What exactly is this delay good for? The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. AFAICS I did use the mm branch. The command to grab the sources was git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm Is this correct? Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Regression sounds like a test suite to me, verifying that the old problems didn't come back. Maybe you could send me a pointer? Of course I didn't try that much yet. The kernel booted as expected, I saw XWindow running, the mouse pointer was moving, etc. There was just no sound, as before with rc7. Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? Speaker and first headphone are the same on this laptop. If I plugin the headphone, then the tiny speakers are disconnected. But for the last tests no headphone was plugged in. I tested it by running gnome-alsamixer. I tried to switch off and on the mute buttons, change the volume and other sliders, etc. One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? I will try tomorrow. What exactly is this delay good for? The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. AFAICS I did use the mm branch. The command to grab the sources was git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm Is this correct? Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > > > Hm... Just to be sure, try the patch below. It's a clean up patch > > that I'd like to apply later. > > > > Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? "No sound" means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? > > The perex/alsa.git mm branch on kernel.org has many fixes. Could you > > give it a try, too? > > > > This version seems to work. But AFAICS it just reverts hda_intel.c back > to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Wed, 09 Jan 2008 21:10:41 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> >
> > Thanks. Then the possible reason might be the registers that don't
> > appear in this proc output, such as GPIO.
> > Could you try the patch below with the latency patch (you reverted) in
> > rc7?
> >
>
> Using rc7:
>
> hda_intel.c(rc6) + patch for sigmatel.c: sound works
> hda_intel.c(rc7) + patch for sigmatel.c: sound does not work
>
> Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix
> the problem.
Hm... Just to be sure, try the patch below. It's a clean up patch
that I'd like to apply later.
The perex/alsa.git mm branch on kernel.org has many fixes. Could you
give it a try, too?
thanks,
Takashi
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 0401223..9048d43 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -110,7 +110,6 @@ struct sigmatel_spec {
unsigned int mic_switch: 1;
unsigned int alt_switch: 1;
unsigned int hp_detect: 1;
- unsigned int gpio_mute: 1;
unsigned int gpio_mask, gpio_data;
@@ -1245,22 +1244,6 @@ static void stac92xx_set_config_regs(struct hda_codec
*codec)
spec->pin_configs[i]);
}
-static void stac92xx_enable_gpio_mask(struct hda_codec *codec)
-{
- struct sigmatel_spec *spec = codec->spec;
- /* Configure GPIOx as output */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, spec->gpio_mask);
- /* Configure GPIOx as CMOS */
- snd_hda_codec_write_cache(codec, codec->afg, 0, 0x7e7, 0x);
- /* Assert GPIOx */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DATA, spec->gpio_data);
- /* Enable GPIOx */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_MASK, spec->gpio_mask);
-}
-
/*
* Analog playback callbacks
*/
@@ -2183,38 +2166,38 @@ static int stac9200_parse_auto_config(struct hda_codec
*codec)
* funky external mute control using GPIO pins.
*/
-static void stac922x_gpio_mute(struct hda_codec *codec, int pin, int muted)
+static void stac_gpio_set(struct hda_codec *codec, unsigned int mask,
+ unsigned int data)
{
unsigned int gpiostate, gpiomask, gpiodir;
+ if (!mask)
+ return;
+
gpiostate = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_DATA, 0);
-
- if (!muted)
- gpiostate |= (1 << pin);
- else
- gpiostate &= ~(1 << pin);
+ gpiostate = (gpiostate & ~mask) | (data & mask);
gpiomask = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_MASK, 0);
- gpiomask |= (1 << pin);
+ gpiomask |= mask;
gpiodir = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_DIRECTION, 0);
- gpiodir |= (1 << pin);
+ gpiodir |= mask;
- /* AppleHDA seems to do this -- WTF is this verb?? */
+ /* Configure GPIOx as CMOS */
snd_hda_codec_write(codec, codec->afg, 0, 0x7e7, 0);
snd_hda_codec_write(codec, codec->afg, 0,
AC_VERB_SET_GPIO_MASK, gpiomask);
- snd_hda_codec_write(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, gpiodir);
+ snd_hda_codec_read(codec, codec->afg, 0,
+ AC_VERB_SET_GPIO_DIRECTION, gpiodir); /* sync */
msleep(1);
- snd_hda_codec_write(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DATA, gpiostate);
+ snd_hda_codec_read(codec, codec->afg, 0,
+ AC_VERB_SET_GPIO_DATA, gpiostate); /* sync */
}
static void enable_pin_detect(struct hda_codec *codec, hda_nid_t nid,
@@ -2273,10 +2256,7 @@ static int stac92xx_init(struct hda_codec *codec)
stac92xx_auto_set_pinctl(codec, cfg->dig_in_pin,
AC_PINCTL_IN_EN);
- if (spec->gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec->gpio_mask, spec->gpio_data);
return 0;
}
@@ -2400,10 +2380,7 @@ static int stac92xx_resume(struct hda_codec *codec)
stac92xx_set_config_regs(codec);
snd_hda_sequence_write(codec, spec->init);
- if (spec->gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec->gpio_mask, spec->gpio_data);
snd_hda_codec_resume_amp(codec);
snd_hda_codec_resume_cache(codec);
/* invoke unsolicited event to reset the HP state */
@@ -2567,7 +2544,7 @@ static
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Wed, 09 Jan 2008 21:10:41 +0100,
Harald Dunkel wrote:
Takashi Iwai wrote:
Thanks. Then the possible reason might be the registers that don't
appear in this proc output, such as GPIO.
Could you try the patch below with the latency patch (you reverted) in
rc7?
Using rc7:
hda_intel.c(rc6) + patch for sigmatel.c: sound works
hda_intel.c(rc7) + patch for sigmatel.c: sound does not work
Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix
the problem.
Hm... Just to be sure, try the patch below. It's a clean up patch
that I'd like to apply later.
The perex/alsa.git mm branch on kernel.org has many fixes. Could you
give it a try, too?
thanks,
Takashi
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 0401223..9048d43 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -110,7 +110,6 @@ struct sigmatel_spec {
unsigned int mic_switch: 1;
unsigned int alt_switch: 1;
unsigned int hp_detect: 1;
- unsigned int gpio_mute: 1;
unsigned int gpio_mask, gpio_data;
@@ -1245,22 +1244,6 @@ static void stac92xx_set_config_regs(struct hda_codec
*codec)
spec-pin_configs[i]);
}
-static void stac92xx_enable_gpio_mask(struct hda_codec *codec)
-{
- struct sigmatel_spec *spec = codec-spec;
- /* Configure GPIOx as output */
- snd_hda_codec_write_cache(codec, codec-afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, spec-gpio_mask);
- /* Configure GPIOx as CMOS */
- snd_hda_codec_write_cache(codec, codec-afg, 0, 0x7e7, 0x);
- /* Assert GPIOx */
- snd_hda_codec_write_cache(codec, codec-afg, 0,
- AC_VERB_SET_GPIO_DATA, spec-gpio_data);
- /* Enable GPIOx */
- snd_hda_codec_write_cache(codec, codec-afg, 0,
- AC_VERB_SET_GPIO_MASK, spec-gpio_mask);
-}
-
/*
* Analog playback callbacks
*/
@@ -2183,38 +2166,38 @@ static int stac9200_parse_auto_config(struct hda_codec
*codec)
* funky external mute control using GPIO pins.
*/
-static void stac922x_gpio_mute(struct hda_codec *codec, int pin, int muted)
+static void stac_gpio_set(struct hda_codec *codec, unsigned int mask,
+ unsigned int data)
{
unsigned int gpiostate, gpiomask, gpiodir;
+ if (!mask)
+ return;
+
gpiostate = snd_hda_codec_read(codec, codec-afg, 0,
AC_VERB_GET_GPIO_DATA, 0);
-
- if (!muted)
- gpiostate |= (1 pin);
- else
- gpiostate = ~(1 pin);
+ gpiostate = (gpiostate ~mask) | (data mask);
gpiomask = snd_hda_codec_read(codec, codec-afg, 0,
AC_VERB_GET_GPIO_MASK, 0);
- gpiomask |= (1 pin);
+ gpiomask |= mask;
gpiodir = snd_hda_codec_read(codec, codec-afg, 0,
AC_VERB_GET_GPIO_DIRECTION, 0);
- gpiodir |= (1 pin);
+ gpiodir |= mask;
- /* AppleHDA seems to do this -- WTF is this verb?? */
+ /* Configure GPIOx as CMOS */
snd_hda_codec_write(codec, codec-afg, 0, 0x7e7, 0);
snd_hda_codec_write(codec, codec-afg, 0,
AC_VERB_SET_GPIO_MASK, gpiomask);
- snd_hda_codec_write(codec, codec-afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, gpiodir);
+ snd_hda_codec_read(codec, codec-afg, 0,
+ AC_VERB_SET_GPIO_DIRECTION, gpiodir); /* sync */
msleep(1);
- snd_hda_codec_write(codec, codec-afg, 0,
- AC_VERB_SET_GPIO_DATA, gpiostate);
+ snd_hda_codec_read(codec, codec-afg, 0,
+ AC_VERB_SET_GPIO_DATA, gpiostate); /* sync */
}
static void enable_pin_detect(struct hda_codec *codec, hda_nid_t nid,
@@ -2273,10 +2256,7 @@ static int stac92xx_init(struct hda_codec *codec)
stac92xx_auto_set_pinctl(codec, cfg-dig_in_pin,
AC_PINCTL_IN_EN);
- if (spec-gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec-gpio_mask, spec-gpio_data);
return 0;
}
@@ -2400,10 +2380,7 @@ static int stac92xx_resume(struct hda_codec *codec)
stac92xx_set_config_regs(codec);
snd_hda_sequence_write(codec, spec-init);
- if (spec-gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec-gpio_mask, spec-gpio_data);
snd_hda_codec_resume_amp(codec);
snd_hda_codec_resume_cache(codec);
/* invoke unsolicited event to reset the HP state */
@@ -2567,7 +2544,7 @@ static int patch_stac922x(struct hda_codec *codec)
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? The perex/alsa.git mm branch on kernel.org has many fixes. Could you give it a try, too? This version seems to work. But AFAICS it just reverts hda_intel.c back to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Thanks. Then the possible reason might be the registers that don't appear in this proc output, such as GPIO. Could you try the patch below with the latency patch (you reverted) in rc7? Using rc7: hda_intel.c(rc6) + patch for sigmatel.c: sound works hda_intel.c(rc7) + patch for sigmatel.c: sound does not work Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix the problem. Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Thanks. Then the possible reason might be the registers that don't appear in this proc output, such as GPIO. Could you try the patch below with the latency patch (you reverted) in rc7? Using rc7: hda_intel.c(rc6) + patch for sigmatel.c: sound works hda_intel.c(rc7) + patch for sigmatel.c: sound does not work Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix the problem. Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Wed, 09 Jan 2008 07:03:18 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > > > Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware > > (laptop, product name, whatever) exactly? > > > > CONFIG_SND_HDA_POWER_SAVE is not set. That's fine. > Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz, > 2 GByte RAM. lspci: > > 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c) > 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c) > 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 > (rev 02) > 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 > (rev 02) > 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 > (rev 02) > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio > Controller (rev 02) > 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 > (rev 02) > 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 > (rev 02) > 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 > (rev 02) > 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 > (rev 02) > 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 > (rev 02) > 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 > (rev 02) > 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 > (rev 02) > 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 > (rev 02) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) > 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02) > 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02) > 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev > 02) > 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev > 02) > 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 > (rev a1) > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05) > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 > SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) > 03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter > (rev 12) > 03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) > 09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02) > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network > Connection (rev 02) > > > Also, please show the contents of /proc/asound/card0/codec#* files. > > Do you see difference in these files between with and without the > > patch? > > > > See below. There is no difference between both. Thanks. Then the possible reason might be the registers that don't appear in this proc output, such as GPIO. Could you try the patch below with the latency patch (you reverted) in rc7? Takashi diff -r d773ad622068 sound/pci/hda/patch_sigmatel.c --- a/sound/pci/hda/patch_sigmatel.cTue Jan 08 18:13:27 2008 +0100 +++ b/sound/pci/hda/patch_sigmatel.cWed Jan 09 08:29:49 2008 +0100 @@ -1624,12 +1624,13 @@ static void stac92xx_enable_gpio_mask(st AC_VERB_SET_GPIO_DIRECTION, spec->gpio_mask); /* Configure GPIOx as CMOS */ snd_hda_codec_write_cache(codec, codec->afg, 0, 0x7e7, 0x); + /* Enable GPIOx */ + snd_hda_codec_write_cache(codec, codec->afg, 0, + AC_VERB_SET_GPIO_MASK, spec->gpio_mask); + msleep(1); /* Assert GPIOx */ snd_hda_codec_write_cache(codec, codec->afg, 0, AC_VERB_SET_GPIO_DATA, spec->gpio_data); - /* Enable GPIOx */ - snd_hda_codec_write_cache(codec, codec->afg, 0, - AC_VERB_SET_GPIO_MASK, spec->gpio_mask); } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware (laptop, product name, whatever) exactly? CONFIG_SND_HDA_POWER_SAVE is not set. Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz, 2 GByte RAM. lspci: 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05) 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Also, please show the contents of /proc/asound/card0/codec#* files. Do you see difference in these files between with and without the patch? See below. There is no difference between both. Regards Harri Codec: SigmaTel STAC9228 Address: 0 Vendor Id: 0x83847616 Subsystem Id: 0x10280209 Revision Id: 0x100201 No Modem Function Group found Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x7f 0x7f] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1b Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1c Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1d Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x02214020: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green Pin-ctls: 0xc0: OUT HP Connection: 2 0x02* 0x03 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x02a19080: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink Pin-ctls: 0x24: IN Connection: 2 0x02 0x03* Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x0181304e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue Pin-ctls: 0x20: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01a19040: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x24:
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Tue, 08 Jan 2008 18:01:48 +0100, Harald Dunkel wrote: > > Dear Takashi-san, > > Takashi Iwai wrote: > > > > Could you revert it and check whether the problem still exists? > > > > I did, and sound is back :-). Wow, you are the first bug reporter regarding this patch. Linus, please revert the commit 57a04513cb3 as now. The life can go well without this patch. But, anyway we need to track down the problem. So... > Please mail, if you need the .config file. BTW, I missed to send > the output of uname. Here is: > > Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware (laptop, product name, whatever) exactly? Also, please show the contents of /proc/asound/card0/codec#* files. Do you see difference in these files between with and without the patch? thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Dear Takashi-san, Takashi Iwai wrote: Could you revert it and check whether the problem still exists? I did, and sound is back :-). Please mail, if you need the .config file. BTW, I missed to send the output of uname. Here is: Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux Its 64bit. Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
* Takashi Iwai <[EMAIL PROTECTED]> wrote:
> > The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
> > this:
> >
> > diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
> > linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
> > --- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21
> > 02:25:48.0 +0100
> > +++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06
> > 22:45:38.0 +0100
> > @@ -555,7 +555,8 @@
> > }
> > 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) {
> >
> >
> > Do you think this could be related to the problem?
>
> Could you revert it and check whether the problem still exists?
>
> I hardly believe it's the culprit, but if this is the only change in
> the sound subsystem...
lets revert it (commit 57a04513cb3) if it's causing problems. This patch
sat in -mm for quite some time - so it seems -rc7 is getting pretty good
test coverage.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
* Takashi Iwai [EMAIL PROTECTED] wrote:
The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
this:
diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
--- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21
02:25:48.0 +0100
+++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06
22:45:38.0 +0100
@@ -555,7 +555,8 @@
}
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) {
Do you think this could be related to the problem?
Could you revert it and check whether the problem still exists?
I hardly believe it's the culprit, but if this is the only change in
the sound subsystem...
lets revert it (commit 57a04513cb3) if it's causing problems. This patch
sat in -mm for quite some time - so it seems -rc7 is getting pretty good
test coverage.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Dear Takashi-san, Takashi Iwai wrote: Could you revert it and check whether the problem still exists? I did, and sound is back :-). Please mail, if you need the .config file. BTW, I missed to send the output of uname. Here is: Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux Its 64bit. Regards Harri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Tue, 08 Jan 2008 18:01:48 +0100, Harald Dunkel wrote: Dear Takashi-san, Takashi Iwai wrote: Could you revert it and check whether the problem still exists? I did, and sound is back :-). Wow, you are the first bug reporter regarding this patch. Linus, please revert the commit 57a04513cb3 as now. The life can go well without this patch. But, anyway we need to track down the problem. So... Please mail, if you need the .config file. BTW, I missed to send the output of uname. Here is: Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware (laptop, product name, whatever) exactly? Also, please show the contents of /proc/asound/card0/codec#* files. Do you see difference in these files between with and without the patch? thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware (laptop, product name, whatever) exactly? CONFIG_SND_HDA_POWER_SAVE is not set. Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz, 2 GByte RAM. lspci: 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05) 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Also, please show the contents of /proc/asound/card0/codec#* files. Do you see difference in these files between with and without the patch? See below. There is no difference between both. Regards Harri Codec: SigmaTel STAC9228 Address: 0 Vendor Id: 0x83847616 Subsystem Id: 0x10280209 Revision Id: 0x100201 No Modem Function Group found Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x7f 0x7f] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1b Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1c Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1d Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x02214020: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green Pin-ctls: 0xc0: OUT HP Connection: 2 0x02* 0x03 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x02a19080: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink Pin-ctls: 0x24: IN Connection: 2 0x02 0x03* Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x0181304e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue Pin-ctls: 0x20: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01a19040: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x24:
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Wed, 09 Jan 2008 07:03:18 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware (laptop, product name, whatever) exactly? CONFIG_SND_HDA_POWER_SAVE is not set. That's fine. Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz, 2 GByte RAM. lspci: 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05) 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Also, please show the contents of /proc/asound/card0/codec#* files. Do you see difference in these files between with and without the patch? See below. There is no difference between both. Thanks. Then the possible reason might be the registers that don't appear in this proc output, such as GPIO. Could you try the patch below with the latency patch (you reverted) in rc7? Takashi diff -r d773ad622068 sound/pci/hda/patch_sigmatel.c --- a/sound/pci/hda/patch_sigmatel.cTue Jan 08 18:13:27 2008 +0100 +++ b/sound/pci/hda/patch_sigmatel.cWed Jan 09 08:29:49 2008 +0100 @@ -1624,12 +1624,13 @@ static void stac92xx_enable_gpio_mask(st AC_VERB_SET_GPIO_DIRECTION, spec-gpio_mask); /* Configure GPIOx as CMOS */ snd_hda_codec_write_cache(codec, codec-afg, 0, 0x7e7, 0x); + /* Enable GPIOx */ + snd_hda_codec_write_cache(codec, codec-afg, 0, + AC_VERB_SET_GPIO_MASK, spec-gpio_mask); + msleep(1); /* Assert GPIOx */ snd_hda_codec_write_cache(codec, codec-afg, 0, AC_VERB_SET_GPIO_DATA, spec-gpio_data); - /* Enable GPIOx */ - snd_hda_codec_write_cache(codec, codec-afg, 0, - AC_VERB_SET_GPIO_MASK, spec-gpio_mask); } /* -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Mon, 07 Jan 2008 20:53:33 +0100,
Harald Dunkel wrote:
>
> Hi folks,
>
> Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
> can access /dev/dsp, change the volume and so on, but the speakers
> are quiet. Moving back to rc6 there is no such problem.
>
> Of course the config files are the same (except for some new
> CONFIG_SLABINFO variable).
>
>
> lspci says:
>
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
> Controller (rev 02)
> 00:1b.0 0403: 8086:284b (rev 02)
>
> % aplay -l
> List of PLAYBACK Hardware Devices
> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
> card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
>
>
>
> The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
> this:
>
> diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
> linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
> --- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c2007-12-21
> 02:25:48.0 +0100
> +++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c2008-01-06
> 22:45:38.0 +0100
> @@ -555,7 +555,8 @@
> }
> 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) {
>
>
> Do you think this could be related to the problem?
Could you revert it and check whether the problem still exists?
I hardly believe it's the culprit, but if this is the only change in
the sound subsystem...
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc7, intel audio: alsa doesn't say a beep
Hi folks,
Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
can access /dev/dsp, change the volume and so on, but the speakers
are quiet. Moving back to rc6 there is no such problem.
Of course the config files are the same (except for some new
CONFIG_SLABINFO variable).
lspci says:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 02)
00:1b.0 0403: 8086:284b (rev 02)
% aplay -l
List of PLAYBACK Hardware Devices
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
this:
diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
--- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21 02:25:48.0
+0100
+++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06 22:45:38.0
+0100
@@ -555,7 +555,8 @@
}
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) {
Do you think this could be related to the problem?
Any hint would be highly appreciated. Please mail if I can help to
track this down.
Regards
Harri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc7, intel audio: alsa doesn't say a beep
Hi folks,
Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
can access /dev/dsp, change the volume and so on, but the speakers
are quiet. Moving back to rc6 there is no such problem.
Of course the config files are the same (except for some new
CONFIG_SLABINFO variable).
lspci says:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 02)
00:1b.0 0403: 8086:284b (rev 02)
% aplay -l
List of PLAYBACK Hardware Devices
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
this:
diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
--- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21 02:25:48.0
+0100
+++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06 22:45:38.0
+0100
@@ -555,7 +555,8 @@
}
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) {
Do you think this could be related to the problem?
Any hint would be highly appreciated. Please mail if I can help to
track this down.
Regards
Harri
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Mon, 07 Jan 2008 20:53:33 +0100,
Harald Dunkel wrote:
Hi folks,
Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
can access /dev/dsp, change the volume and so on, but the speakers
are quiet. Moving back to rc6 there is no such problem.
Of course the config files are the same (except for some new
CONFIG_SLABINFO variable).
lspci says:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 02)
00:1b.0 0403: 8086:284b (rev 02)
% aplay -l
List of PLAYBACK Hardware Devices
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
this:
diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c
linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
--- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c2007-12-21
02:25:48.0 +0100
+++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c2008-01-06
22:45:38.0 +0100
@@ -555,7 +555,8 @@
}
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) {
Do you think this could be related to the problem?
Could you revert it and check whether the problem still exists?
I hardly believe it's the culprit, but if this is the only change in
the sound subsystem...
thanks,
Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
