[alsa-devel] Alsa 1.0.13 (and others) does not work on ALC880

[acallan.alsa at ugnet.org]

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...