On Mon, Nov 30, 2009 at 04:12:09PM +0000, Mark Brown wrote: > 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. Yes, I totally agree. It's just that the whole power regulator framework was new to me, and hence I didn't use and fully understand it. Once you know what it is designed for, it all makes sense. > 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. Ok, I'll first post a new version for the regulators again and will care for the rest later :) Daniel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
