That doesn't seem to change anything. Maybe I should have been more clear: I get the azx_get_response timeouts whenever the driver initializes; DMA never works for that codec. single_cmd mode just happens to work before a suspend, but not after. In other words, reloading the module doesn't really fix the problem, it just masks it decently enough. I'll work a little bit trying to figure out which commands cause the timeouts. And what *is* S2D?
Sorry about not CCing the mailing list, Gmail makes it way too easy to do that, and too unnoticeable when it happens. I'll be more careful.
On 6/20/07, Takashi Iwai tiwai@suse.de wrote:
[Please don't strip Cc to ML!]
At Tue, 19 Jun 2007 15:54:42 -0500, Matt Mullins wrote:
I played around with probe_mask, and found that probe_mask=0x1 causes the error, but probe_mask=0x2 does not cause the timeout. Codec 1 is my Sigmatel STAC9205, which is what plays sound on my laptop, and codec 2 is my Conexant modem. The modem isn't the codec causing problems; the audio codec is!
OK, good to know. Does this problem occur with S2D? What is the very first command that triggers this timeout error?
I'm wondering what is the difference between them -- according to your report, reloading the module fixes the problem. But, the resume callback is almost identical with the re-initiailzation. Perhaps it's something to do with the power-state management. What about the patch below?
Takashi
diff -r c531d63e820b sound/pci/hda/hda_intel.c --- a/sound/pci/hda/hda_intel.c Wed Jun 20 12:03:09 2007 +0200 +++ b/sound/pci/hda/hda_intel.c Wed Jun 20 12:09:40 2007 +0200 @@ -1450,7 +1450,7 @@ static int azx_suspend(struct pci_dev *p pci_disable_msi(chip->pci); pci_disable_device(pci); pci_save_state(pci);
pci_set_power_state(pci, pci_choose_state(pci, state));
/* pci_set_power_state(pci, pci_choose_state(pci, state)); */ return 0;}