[alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
mokomull at gmail.com
Wed Jun 20 23:18:46 CEST 2007
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 at 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?
> 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_set_power_state(pci, pci_choose_state(pci, state));
> + /* pci_set_power_state(pci, pci_choose_state(pci, state)); */
> return 0;
More information about the Alsa-devel