On Thu, Apr 02, 2009 at 02:31:24PM +0100, Russell King - ARM Linux wrote:
So, basically, we're starting to access the AC97 bus without first initializing the controller. This can't work on _any_ PXA platform.
Ah, that explains it - yes, this just isn't going to do suspend/resume as-is (but see the patch below).
That happens in the probe just fine because one of the first actions that the core ALSA AC97 code does is to issue a cold reset - see sound/pci/ac97/ac97_codec.c:snd_ac97_mixer() where it calls the bus reset() method.
The core ALSA AC97 code shouldn't be getting involved for ASoC-specific CODEC drivers. An ASoC-specific driver should be doing whatever is required to the CODEC directly - one of the reasons for having an ASoC-specific driver is to allow more detailed management of the device than can be supported within the standard ALSA AC97 framework.
ac97.c calls into the standard ALSA AC97 code to provide an adaption layer which allows the generic AC97 support to be used with an ASoC AC97 controller driver for devices which don't need or want any additional support.
I now find that the board crashes inexplicably on suspend... because... Argh, Ian, what pile of mess have you created in wm9705?
You do:
ret = snd_soc_new_ac97_codec(codec, &soc_ac97_ops, 0);
which doesn't actually give us an AC97 codec device - it only kmallocs some memory for them.
That's what an ASoC AC97 driver should do - it is responsible for bringing up the link by issuing a reset operation (which the wm9705 driver is doing) and doing any other setup required. The ASoC core will then go and register the AC97 bus device for child devices like the
Okay, I'm going to shelve this project for at least the next three months now, and will return to it when (and if) the ASoC codec situation improves.
Before doing that could you please try the patch below to wm9705.c implementing suspend and resume operations? It's completely speculative, I don't have a WM9705 test system to hand but I'm moderately confident