Re: [alsa-devel] Alsa 1.0.13 (and others) does not work on ALC880
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi
Based on this information, I'll go ahead and add your device ID to the codec driver so you won't need to add the "model=" modprobe parameter (see attached patch). The probe_mask issue will need more work to figure out what exactly is going on. I wonder if it might be acpi related?
---- cut --------- cut --------- cut --------- cut -----
Summary: hda-codec: Add support for Clevo D900 system
This patch adds subsystem ID for the D900 system to the ALC880 code.
Signed off by Tobin Davis tdavis@dsl-only.net
---- cut --------- cut --------- cut --------- cut -----
On Sat, 2007-05-19 at 17:11 +0200, Takashi Iwai wrote:
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Well, on this laptop (D900t Eurocom) BIOS modification is very limited, and it is not possible to modify or switch codecs, so as I think it is enabled it is not possible to disable it ...
Takashi Iwai a écrit :
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Try "probe_mask=3". That should enable the audio and modem codec to see if it is the cause of these issues. If it is, there is an issue with it. If not, it's in the probe routine.
Tobin
On Sat, 2007-05-19 at 19:22 +0200, E.D.V. wrote:
Well, on this laptop (D900t Eurocom) BIOS modification is very limited, and it is not possible to modify or switch codecs, so as I think it is enabled it is not possible to disable it ...
Takashi Iwai a écrit :
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
The Phoenix cME FirstBIOS Pro, Revision V146 1.00.01 on this machine has very limited options in general. There is not any option for enabling/disabling the modem (or other devices such as NIC, wireless NIC, sound, etc.). So I guess I would assume that it is always enabled through the BIOS?
Andrew
On Sat, 19 May 2007, Takashi Iwai wrote:
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I tried probe_mask=3. aplay -l shows the Si3054 Modem device again. Sound does not work. So I guess this points to the modem rather than the probing. It looks like Eric has the same modem as I do; the Vendor Id, Subsystem Id, and Revision Id all match.
Andrew
On Sat, 19 May 2007, Takashi Iwai wrote:
At Sat, 19 May 2007 02:08:14 -0500 (CDT), Andrew Callan wrote:
I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange.
First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model.
Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this.
If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output.
One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output.
Thanks for the help you gave in the thread with Eric.
Andrew
Interesting. I've seen similar reports that probe_mask helps. Do you disable the modem codec on BIOS or is it enabled?
If this happens even though it's enabled on BIOS, we'd need a blacklist of non-working devices, or a more robust probing routine...
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I've tried to chase this problem deeper. The chip has two codecs, 1 is audio, 2 is modem. In setup_fg_nodes() [hda_codec.c], the call to snd_hda_get_sub_nodes() returns total_nodes=1 and nid=0x01 for the audio codec. The same call returns total_nodes=39 and nid=0x00 for the modem codec.
Calls to azx_corb_send_cmd() [hda_intel.c] can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, AC_PAR_NODE_COUNT, and AC_PAR_FUNCTION_TYPE for the audio codec. 32 calls to azx_corb_send_cmd() can then be seen for AC_PAR_AUDIO_WIDGET_CAP for the audio codec. For the modem codec, calls to azx_corb_send_cmd() can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, and AC_PAR_NODE_COUNT followed by 39 calls to azx_corb_send_cmd() for AC_PAR_FUNCTION_TYPE for the modem codec. These each return the value AC_GRP_MODEM_FUNCTION and so the codec->mfg ends up being set to the 39th nid (0x26). Everything appears to be going smoothly until read_widget_caps() is called for them modem codec. When snd_hda_get_sub_nodes() is called inside read_widget_caps() for fg_node 0x26, this triggers a call to azx_corb_send_cmd() for AC_PAR_NODE_COUNT. The function azx_rirb_get_response() ends up timing out with the following lines appearing in my dmesg log: hda_intel: azx_get_response timeout, switching to polling mode... hda_intel: azx_get_response timeout, switching to single_cmd mode...
_From following the code, it appears that chip->single_cmd = 1 from this point on. The note above the function azx_single_send_cmd() makes it clear that this function should not be used for normal operation. And, indeed, after this point, calls to the chip for the audio codec seem to return bogus values (as could be seen in the Default PCM and Node sections of the Codec information at http://pastebin.ca/496293).
So, I have a few questions: 1) Does it make sense that the modem codec would have 39 fg nodes? 2) Does it make sense that the switch to single_cmd mode would possibly be the cause of the bogus values being returned later? (I haven't really traced much past this point since that comment about azx_single_send_cmd seemed to make it clear that I was already in trouble by this point.) 3) What other things would it be helpful to look at to try to chase this problem further?
Andrew
At Sat, 2 Jun 2007 22:20:04 -0500 (CDT), acallan.alsa@ugnet.org wrote:
I've tried to chase this problem deeper. The chip has two codecs, 1 is audio, 2 is modem. In setup_fg_nodes() [hda_codec.c], the call to snd_hda_get_sub_nodes() returns total_nodes=1 and nid=0x01 for the audio codec. The same call returns total_nodes=39 and nid=0x00 for the modem codec.
Calls to azx_corb_send_cmd() [hda_intel.c] can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, AC_PAR_NODE_COUNT, and AC_PAR_FUNCTION_TYPE for the audio codec. 32 calls to azx_corb_send_cmd() can then be seen for AC_PAR_AUDIO_WIDGET_CAP for the audio codec. For the modem codec, calls to azx_corb_send_cmd() can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, and AC_PAR_NODE_COUNT followed by 39 calls to azx_corb_send_cmd() for AC_PAR_FUNCTION_TYPE for the modem codec. These each return the value AC_GRP_MODEM_FUNCTION and so the codec->mfg ends up being set to the 39th nid (0x26). Everything appears to be going smoothly until read_widget_caps() is called for them modem codec. When snd_hda_get_sub_nodes() is called inside read_widget_caps() for fg_node 0x26, this triggers a call to azx_corb_send_cmd() for AC_PAR_NODE_COUNT. The function azx_rirb_get_response() ends up timing out with the following lines appearing in my dmesg log: hda_intel: azx_get_response timeout, switching to polling mode... hda_intel: azx_get_response timeout, switching to single_cmd mode...
OK, then the problem gets started at reading the widget capabilities. Thanks for the analysis!
From following the code, it appears that chip->single_cmd = 1 from this point on. The note above the function azx_single_send_cmd() makes it clear that this function should not be used for normal operation. And, indeed, after this point, calls to the chip for the audio codec seem to return bogus values (as could be seen in the Default PCM and Node sections of the Codec information at http://pastebin.ca/496293).
Yes, that's already a known issue.
So, I have a few questions:
- Does it make sense that the modem codec would have 39 fg nodes?
That should be OK.
- Does it make sense that the switch to single_cmd mode would possibly
be the cause of the bogus values being returned later? (I haven't really traced much past this point since that comment about azx_single_send_cmd seemed to make it clear that I was already in trouble by this point.)
Yes, some devices have been broken. And, I guess it won't be get recovered even if you don't change to single_cmd mode.
- What other things would it be helpful to look at to try to chase this
problem further?
Could you try the patch below?
thanks,
Takashi diff -r eb7241f88cdd pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_codec.c Mon Jun 04 16:11:02 2007 +0200 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) { + if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM; diff -r eb7241f88cdd pci/hda/hda_local.h --- a/pci/hda/hda_local.h Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_local.h Mon Jun 04 16:09:27 2007 +0200 @@ -271,7 +271,7 @@ int snd_hda_parse_pin_def_config(struct */ static inline u32 get_wcaps(struct hda_codec *codec, hda_nid_t nid) { - if (nid < codec->start_nid || + if (!codec->wcaps || nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); return codec->wcaps[nid - codec->start_nid];
That patch gets me further. However, the same rirb timeout / single_cmd mode occurs when hda_set_power_state() calls snd_hda_get_sub_nodes() on the modem codec with the fg set to the last nid (0x26) -- the same condition which you worked around in your patch.
I wrapped the three calls to hda_set_power_state() (in hda_codec.c) with: if (codec->afg) and the sound now works even with modprobe=3. However, I am assuming that this leaves the power state for the modem codec in an uninitialized state.
Andrew
On Mon, 4 Jun 2007, Takashi Iwai wrote:
At Sat, 2 Jun 2007 22:20:04 -0500 (CDT), acallan.alsa@ugnet.org wrote:
I've tried to chase this problem deeper. The chip has two codecs, 1 is audio, 2 is modem. In setup_fg_nodes() [hda_codec.c], the call to snd_hda_get_sub_nodes() returns total_nodes=1 and nid=0x01 for the audio codec. The same call returns total_nodes=39 and nid=0x00 for the modem codec.
Calls to azx_corb_send_cmd() [hda_intel.c] can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, AC_PAR_NODE_COUNT, and AC_PAR_FUNCTION_TYPE for the audio codec. 32 calls to azx_corb_send_cmd() can then be seen for AC_PAR_AUDIO_WIDGET_CAP for the audio codec. For the modem codec, calls to azx_corb_send_cmd() can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, and AC_PAR_NODE_COUNT followed by 39 calls to azx_corb_send_cmd() for AC_PAR_FUNCTION_TYPE for the modem codec. These each return the value AC_GRP_MODEM_FUNCTION and so the codec->mfg ends up being set to the 39th nid (0x26). Everything appears to be going smoothly until read_widget_caps() is called for them modem codec. When snd_hda_get_sub_nodes() is called inside read_widget_caps() for fg_node 0x26, this triggers a call to azx_corb_send_cmd() for AC_PAR_NODE_COUNT. The function azx_rirb_get_response() ends up timing out with the following lines appearing in my dmesg log: hda_intel: azx_get_response timeout, switching to polling mode... hda_intel: azx_get_response timeout, switching to single_cmd mode...
OK, then the problem gets started at reading the widget capabilities. Thanks for the analysis!
From following the code, it appears that chip->single_cmd = 1 from this point on. The note above the function azx_single_send_cmd() makes it clear that this function should not be used for normal operation. And, indeed, after this point, calls to the chip for the audio codec seem to return bogus values (as could be seen in the Default PCM and Node sections of the Codec information at http://pastebin.ca/496293).
Yes, that's already a known issue.
So, I have a few questions:
- Does it make sense that the modem codec would have 39 fg nodes?
That should be OK.
- Does it make sense that the switch to single_cmd mode would possibly
be the cause of the bogus values being returned later? (I haven't really traced much past this point since that comment about azx_single_send_cmd seemed to make it clear that I was already in trouble by this point.)
Yes, some devices have been broken. And, I guess it won't be get recovered even if you don't change to single_cmd mode.
- What other things would it be helpful to look at to try to chase this
problem further?
Could you try the patch below?
thanks,
Takashi diff -r eb7241f88cdd pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_codec.c Mon Jun 04 16:11:02 2007 +0200 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) {
- if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM;
diff -r eb7241f88cdd pci/hda/hda_local.h --- a/pci/hda/hda_local.h Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_local.h Mon Jun 04 16:09:27 2007 +0200 @@ -271,7 +271,7 @@ int snd_hda_parse_pin_def_config(struct */ static inline u32 get_wcaps(struct hda_codec *codec, hda_nid_t nid) {
- if (nid < codec->start_nid ||
- if (!codec->wcaps || nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); return codec->wcaps[nid - codec->start_nid];
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Mon, 4 Jun 2007 23:17:33 -0500 (CDT), acallan.alsa@ugnet.org wrote:
That patch gets me further. However, the same rirb timeout / single_cmd mode occurs when hda_set_power_state() calls snd_hda_get_sub_nodes() on the modem codec with the fg set to the last nid (0x26) -- the same condition which you worked around in your patch.
I wrapped the three calls to hda_set_power_state() (in hda_codec.c) with: if (codec->afg) and the sound now works even with modprobe=3. However, I am assuming that this leaves the power state for the modem codec in an uninitialized state.
Yes, possibly. But, many codecs chip don't require this power setup, and the modem codec is likely such a one.
In your analysis, the problem happens on the certain widget node (0x26). What happens when you run "cat /proc/asound/card0/codec#1" (after your patch)? This should also access to that widget, so in theory, the same problem may occur.
Takashi
Andrew
On Mon, 4 Jun 2007, Takashi Iwai wrote:
At Sat, 2 Jun 2007 22:20:04 -0500 (CDT), acallan.alsa@ugnet.org wrote:
I've tried to chase this problem deeper. The chip has two codecs, 1 is audio, 2 is modem. In setup_fg_nodes() [hda_codec.c], the call to snd_hda_get_sub_nodes() returns total_nodes=1 and nid=0x01 for the audio codec. The same call returns total_nodes=39 and nid=0x00 for the modem codec.
Calls to azx_corb_send_cmd() [hda_intel.c] can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, AC_PAR_NODE_COUNT, and AC_PAR_FUNCTION_TYPE for the audio codec. 32 calls to azx_corb_send_cmd() can then be seen for AC_PAR_AUDIO_WIDGET_CAP for the audio codec. For the modem codec, calls to azx_corb_send_cmd() can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, and AC_PAR_NODE_COUNT followed by 39 calls to azx_corb_send_cmd() for AC_PAR_FUNCTION_TYPE for the modem codec. These each return the value AC_GRP_MODEM_FUNCTION and so the codec->mfg ends up being set to the 39th nid (0x26). Everything appears to be going smoothly until read_widget_caps() is called for them modem codec. When snd_hda_get_sub_nodes() is called inside read_widget_caps() for fg_node 0x26, this triggers a call to azx_corb_send_cmd() for AC_PAR_NODE_COUNT. The function azx_rirb_get_response() ends up timing out with the following lines appearing in my dmesg log: hda_intel: azx_get_response timeout, switching to polling mode... hda_intel: azx_get_response timeout, switching to single_cmd mode...
OK, then the problem gets started at reading the widget capabilities. Thanks for the analysis!
From following the code, it appears that chip->single_cmd = 1 from this point on. The note above the function azx_single_send_cmd() makes it clear that this function should not be used for normal operation. And, indeed, after this point, calls to the chip for the audio codec seem to return bogus values (as could be seen in the Default PCM and Node sections of the Codec information at http://pastebin.ca/496293).
Yes, that's already a known issue.
So, I have a few questions:
- Does it make sense that the modem codec would have 39 fg nodes?
That should be OK.
- Does it make sense that the switch to single_cmd mode would possibly
be the cause of the bogus values being returned later? (I haven't really traced much past this point since that comment about azx_single_send_cmd seemed to make it clear that I was already in trouble by this point.)
Yes, some devices have been broken. And, I guess it won't be get recovered even if you don't change to single_cmd mode.
- What other things would it be helpful to look at to try to chase this
problem further?
Could you try the patch below?
thanks,
Takashi diff -r eb7241f88cdd pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_codec.c Mon Jun 04 16:11:02 2007 +0200 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) {
- if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM;
diff -r eb7241f88cdd pci/hda/hda_local.h --- a/pci/hda/hda_local.h Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_local.h Mon Jun 04 16:09:27 2007 +0200 @@ -271,7 +271,7 @@ int snd_hda_parse_pin_def_config(struct */ static inline u32 get_wcaps(struct hda_codec *codec, hda_nid_t nid) {
- if (nid < codec->start_nid ||
- if (!codec->wcaps || nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); return codec->wcaps[nid - codec->start_nid];
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
cat /proc/asound/card0/codec#1 works just fine, and sound still works fine even after that. Looking at the function print_codec_info() (hda_proc.c), there is already the check: if (! codec->afg) return; after the vendor, subsystem, and revision are retrieved but before the pcm, amp caps, and node information are retrieved.
Andrew
On Tue, 5 Jun 2007, Takashi Iwai wrote:
At Mon, 4 Jun 2007 23:17:33 -0500 (CDT), acallan.alsa@ugnet.org wrote:
That patch gets me further. However, the same rirb timeout / single_cmd mode occurs when hda_set_power_state() calls snd_hda_get_sub_nodes() on the modem codec with the fg set to the last nid (0x26) -- the same condition which you worked around in your patch.
I wrapped the three calls to hda_set_power_state() (in hda_codec.c) with: if (codec->afg) and the sound now works even with modprobe=3. However, I am assuming that this leaves the power state for the modem codec in an uninitialized state.
Yes, possibly. But, many codecs chip don't require this power setup, and the modem codec is likely such a one.
In your analysis, the problem happens on the certain widget node (0x26). What happens when you run "cat /proc/asound/card0/codec#1" (after your patch)? This should also access to that widget, so in theory, the same problem may occur.
Takashi
Andrew
On Mon, 4 Jun 2007, Takashi Iwai wrote:
At Sat, 2 Jun 2007 22:20:04 -0500 (CDT), acallan.alsa@ugnet.org wrote:
I've tried to chase this problem deeper. The chip has two codecs, 1 is audio, 2 is modem. In setup_fg_nodes() [hda_codec.c], the call to snd_hda_get_sub_nodes() returns total_nodes=1 and nid=0x01 for the audio codec. The same call returns total_nodes=39 and nid=0x00 for the modem codec.
Calls to azx_corb_send_cmd() [hda_intel.c] can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, AC_PAR_NODE_COUNT, and AC_PAR_FUNCTION_TYPE for the audio codec. 32 calls to azx_corb_send_cmd() can then be seen for AC_PAR_AUDIO_WIDGET_CAP for the audio codec. For the modem codec, calls to azx_corb_send_cmd() can be seen for AC_PAR_VENDOR_ID, AC_PAR_SUBSYSTEM_ID, AC_PAR_REV_ID, and AC_PAR_NODE_COUNT followed by 39 calls to azx_corb_send_cmd() for AC_PAR_FUNCTION_TYPE for the modem codec. These each return the value AC_GRP_MODEM_FUNCTION and so the codec->mfg ends up being set to the 39th nid (0x26). Everything appears to be going smoothly until read_widget_caps() is called for them modem codec. When snd_hda_get_sub_nodes() is called inside read_widget_caps() for fg_node 0x26, this triggers a call to azx_corb_send_cmd() for AC_PAR_NODE_COUNT. The function azx_rirb_get_response() ends up timing out with the following lines appearing in my dmesg log: hda_intel: azx_get_response timeout, switching to polling mode... hda_intel: azx_get_response timeout, switching to single_cmd mode...
OK, then the problem gets started at reading the widget capabilities. Thanks for the analysis!
From following the code, it appears that chip->single_cmd = 1 from this point on. The note above the function azx_single_send_cmd() makes it clear that this function should not be used for normal operation. And, indeed, after this point, calls to the chip for the audio codec seem to return bogus values (as could be seen in the Default PCM and Node sections of the Codec information at http://pastebin.ca/496293).
Yes, that's already a known issue.
So, I have a few questions:
- Does it make sense that the modem codec would have 39 fg nodes?
That should be OK.
- Does it make sense that the switch to single_cmd mode would possibly
be the cause of the bogus values being returned later? (I haven't really traced much past this point since that comment about azx_single_send_cmd seemed to make it clear that I was already in trouble by this point.)
Yes, some devices have been broken. And, I guess it won't be get recovered even if you don't change to single_cmd mode.
- What other things would it be helpful to look at to try to chase this
problem further?
Could you try the patch below?
thanks,
Takashi diff -r eb7241f88cdd pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_codec.c Mon Jun 04 16:11:02 2007 +0200 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) {
- if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM;
diff -r eb7241f88cdd pci/hda/hda_local.h --- a/pci/hda/hda_local.h Mon Jun 04 09:21:19 2007 +0200 +++ b/pci/hda/hda_local.h Mon Jun 04 16:09:27 2007 +0200 @@ -271,7 +271,7 @@ int snd_hda_parse_pin_def_config(struct */ static inline u32 get_wcaps(struct hda_codec *codec, hda_nid_t nid) {
- if (nid < codec->start_nid ||
- if (!codec->wcaps || nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); return codec->wcaps[nid - codec->start_nid];
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Wed, 6 Jun 2007 01:07:15 -0500 (CDT), acallan.alsa@ugnet.org wrote:
cat /proc/asound/card0/codec#1 works just fine, and sound still works fine even after that. Looking at the function print_codec_info() (hda_proc.c), there is already the check: if (! codec->afg) return; after the vendor, subsystem, and revision are retrieved but before the pcm, amp caps, and node information are retrieved.
Oh silly me.
I guess the following patch works alone. Could you test it?
Takashi
diff -r 8bc69e73a655 pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_codec.c Wed Jun 06 14:52:15 2007 +0200 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) { + if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM; diff -r 8bc69e73a655 pci/hda/hda_local.h --- a/pci/hda/hda_local.h Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_local.h Wed Jun 06 14:53:03 2007 +0200 @@ -274,7 +274,7 @@ static inline u32 get_wcaps(struct hda_c if (nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); - return codec->wcaps[nid - codec->start_nid]; + return codec->wcaps ? codec->wcaps[nid - codec->start_nid] : 0; }
int snd_hda_override_amp_caps(struct hda_codec *codec, hda_nid_t nid, int dir,
On Wed, 6 Jun 2007, Takashi Iwai wrote:
At Wed, 6 Jun 2007 01:07:15 -0500 (CDT), acallan.alsa@ugnet.org wrote:
cat /proc/asound/card0/codec#1 works just fine, and sound still works fine even after that. Looking at the function print_codec_info() (hda_proc.c), there is already the check: if (! codec->afg) return; after the vendor, subsystem, and revision are retrieved but before the pcm, amp caps, and node information are retrieved.
Oh silly me.
I guess the following patch works alone. Could you test it?
Takashi
I had to also add in the workarounds for the power states as in the following patch.
Andrew
diff -r 8bc69e73a655 pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_codec.c Wed Jun 06 23:35:39 2007 -0500 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) { + if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM; @@ -1389,9 +1389,8 @@ int __devinit snd_hda_build_controls(str /* initialize */ list_for_each_entry(codec, &bus->codec_list, list) { int err; - hda_set_power_state(codec, - codec->afg ? codec->afg : codec->mfg, - AC_PWRST_D0); + if (codec->afg) + hda_set_power_state(codec, codec->afg, AC_PWRST_D0); if (!codec->patch_ops.init) continue; err = codec->patch_ops.init(codec); @@ -2375,9 +2374,8 @@ int snd_hda_suspend(struct hda_bus *bus, list_for_each_entry(codec, &bus->codec_list, list) { if (codec->patch_ops.suspend) codec->patch_ops.suspend(codec, state); - hda_set_power_state(codec, - codec->afg ? codec->afg : codec->mfg, - AC_PWRST_D3); + if (codec->afg) + hda_set_power_state(codec, codec->afg, AC_PWRST_D3); } return 0; } @@ -2394,9 +2392,8 @@ int snd_hda_resume(struct hda_bus *bus) struct hda_codec *codec;
list_for_each_entry(codec, &bus->codec_list, list) { - hda_set_power_state(codec, - codec->afg ? codec->afg : codec->mfg, - AC_PWRST_D0); + if (codec->afg) + hda_set_power_state(codec, codec->afg, AC_PWRST_D0); if (codec->patch_ops.resume) codec->patch_ops.resume(codec); } diff -r 8bc69e73a655 pci/hda/hda_local.h --- a/pci/hda/hda_local.h Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_local.h Wed Jun 06 23:32:46 2007 -0500 @@ -274,7 +274,7 @@ static inline u32 get_wcaps(struct hda_c if (nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); - return codec->wcaps[nid - codec->start_nid]; + return codec->wcaps ? codec->wcaps[nid - codec->start_nid] : 0; }
int snd_hda_override_amp_caps(struct hda_codec *codec, hda_nid_t nid, int dir,
At Thu, 7 Jun 2007 01:01:54 -0500 (CDT), acallan.alsa@ugnet.org wrote:
On Wed, 6 Jun 2007, Takashi Iwai wrote:
At Wed, 6 Jun 2007 01:07:15 -0500 (CDT), acallan.alsa@ugnet.org wrote:
cat /proc/asound/card0/codec#1 works just fine, and sound still works fine even after that. Looking at the function print_codec_info() (hda_proc.c), there is already the check: if (! codec->afg) return; after the vendor, subsystem, and revision are retrieved but before the pcm, amp caps, and node information are retrieved.
Oh silly me.
I guess the following patch works alone. Could you test it?
Takashi
I had to also add in the workarounds for the power states as in the following patch.
Did you try my latest patch? It sets the power state of only the FG node, and doesn't touch child nodes any more for modem FG. You patch will skip the power state completely for modem FG.
Takashi
Andrew
diff -r 8bc69e73a655 pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_codec.c Wed Jun 06 23:35:39 2007 -0500 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) {
- if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM;
@@ -1389,9 +1389,8 @@ int __devinit snd_hda_build_controls(str /* initialize */ list_for_each_entry(codec, &bus->codec_list, list) { int err;
hda_set_power_state(codec,codec->afg ? codec->afg : codec->mfg,AC_PWRST_D0);
if (codec->afg)hda_set_power_state(codec, codec->afg, AC_PWRST_D0);@@ -2375,9 +2374,8 @@ int snd_hda_suspend(struct hda_bus *bus, list_for_each_entry(codec, &bus->codec_list, list) { if (codec->patch_ops.suspend) codec->patch_ops.suspend(codec, state);
hda_set_power_state(codec,codec->afg ? codec->afg : codec->mfg,AC_PWRST_D3);
if (codec->afg)hda_set_power_state(codec, codec->afg, AC_PWRST_D3);} @@ -2394,9 +2392,8 @@ int snd_hda_resume(struct hda_bus *bus) struct hda_codec *codec;
list_for_each_entry(codec, &bus->codec_list, list) {
hda_set_power_state(codec,codec->afg ? codec->afg : codec->mfg,AC_PWRST_D0);
if (codec->afg)hda_set_power_state(codec, codec->afg, AC_PWRST_D0);diff -r 8bc69e73a655 pci/hda/hda_local.h --- a/pci/hda/hda_local.h Wed Jun 06 14:48:52 2007 +0200 +++ b/pci/hda/hda_local.h Wed Jun 06 23:32:46 2007 -0500 @@ -274,7 +274,7 @@ static inline u32 get_wcaps(struct hda_c if (nid < codec->start_nid || nid >= codec->start_nid + codec->num_nodes) return snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP);
- return codec->wcaps[nid - codec->start_nid];
- return codec->wcaps ? codec->wcaps[nid - codec->start_nid] : 0;
}
int snd_hda_override_amp_caps(struct hda_codec *codec, hda_nid_t nid, int dir,
Yes, I had tried it, and it did not work. However, I hadn't grasped what you were trying to accomplish with it. The problem was that hda_set_power_state() still called snd_hda_get_sub_nodes() on the modem codec before looping over the calls to get_wcaps(), and snd_hda_get_sub_nodes() is the function causing problems for my chip.
The following patch works for me, and I think it accomplishes what you wanted.
Andrew
On Fri, 8 Jun 2007, Takashi Iwai wrote:
At Thu, 7 Jun 2007 01:01:54 -0500 (CDT), acallan.alsa@ugnet.org wrote:
On Wed, 6 Jun 2007, Takashi Iwai wrote:
At Wed, 6 Jun 2007 01:07:15 -0500 (CDT), acallan.alsa@ugnet.org wrote:
cat /proc/asound/card0/codec#1 works just fine, and sound still works fine even after that. Looking at the function print_codec_info() (hda_proc.c), there is already the check: if (! codec->afg) return; after the vendor, subsystem, and revision are retrieved but before the pcm, amp caps, and node information are retrieved.
Oh silly me.
I guess the following patch works alone. Could you test it?
Takashi
I had to also add in the workarounds for the power states as in the following patch.
Did you try my latest patch? It sets the power state of only the FG node, and doesn't touch child nodes any more for modem FG. You patch will skip the power state completely for modem FG.
Takashi
diff -r 95e93362c92d pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Mon Jun 11 12:23:31 2007 +0200 +++ b/pci/hda/hda_codec.c Mon Jun 11 23:27:33 2007 -0500 @@ -562,7 +562,7 @@ int __devinit snd_hda_codec_new(struct h return -ENODEV; }
- if (read_widget_caps(codec, codec->afg ? codec->afg : codec->mfg) < 0) { + if (codec->afg && read_widget_caps(codec, codec->afg) < 0) { snd_printk(KERN_ERR "hda_codec: cannot malloc\n"); snd_hda_codec_free(codec); return -ENOMEM; @@ -1351,6 +1351,8 @@ static void hda_set_power_state(struct h snd_hda_codec_write(codec, fg, 0, AC_VERB_SET_POWER_STATE, power_state);
+ if (! codec->afg) + return; nodes = snd_hda_get_sub_nodes(codec, fg, &nid_start); for (nid = nid_start; nid < nodes + nid_start; nid++) { if (get_wcaps(codec, nid) & AC_WCAP_POWER)
At Tue, 12 Jun 2007 00:51:48 -0500 (CDT), acallan.alsa@ugnet.org wrote:
Yes, I had tried it, and it did not work. However, I hadn't grasped what you were trying to accomplish with it. The problem was that hda_set_power_state() still called snd_hda_get_sub_nodes() on the modem codec before looping over the calls to get_wcaps(), and snd_hda_get_sub_nodes() is the function causing problems for my chip.
The following patch works for me, and I think it accomplishes what you wanted.
Hm, then your modem codec doesn't follow the compliance. The subordinate node count parameter must be supported by any codecs, according to HD-audio specification. I suppose your modem has never worked?
If so, the right way to achieve it is to simply deactivate the modem codec chip, e.g. by creating a blacklist, rather than disabling the necessary functionalities.
Takashi
participants (5)
-
acallan.alsa＠ugnet.org -
Andrew Callan
-
E.D.V. -
Takashi Iwai -
Tobin Davis