On Mon, Nov 30, 2009 at 04:57:42PM +0100, Daniel Mack wrote: > The current aproach does not work reliably, unfortunately. It turns out > that the codec necessarily needs its analogue supply to maintain its > state. For all other operations (iow, any of the volatges not applied), > it has to be held in reset mode. I did that manually by driving the GPIO > directly before, but with the current regulator framework support, > that's not possible anymore. This is one of the reasons why your previous code looked suspect to me, actually - since the CODEC driver had no idea that you'd suspended the device it'd do things like try to write volume updates to the device while you were keeping the power off. > Hence, we can only power down the codec when we're in system suspend, When runtime PM hits in 2.6.33 I intend to try to enable support for it in ASoC, it's relatively straightforward I think. Unfortunately it'll end up depending on the platform bus on the relevant platform being capable of runtime pm but that should become more widely supported as things progress. Given this I would suggest doing the same thing the other drivers are doing and only turning things off when the device is suspended (either via the explicit functions or via set_bias_level()) and then let the ASoC core deal with actually doing the suspend - it's probably less hassle for you that way. Converting to use the shared register I/O code in soc-cache.c might also help here. > which is a pitty. But even for that, we should still drive the RESET > signal low. Can we make the GPIO pin number available to the codec > driver? Of course, use platform data. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
