On Mon, Nov 30, 2009 at 01:36:17PM +0100, Daniel Mack wrote:
On Mon, Nov 30, 2009 at 12:01:59PM +0000, Mark Brown wrote:
On Sat, Nov 28, 2009 at 07:46:22PM -0700, Tabi Timur-B04825 wrote:
Have you tested it on a Freescale MPC8610 HPCD? Are you sure it still compiles and builds on any PowerPC system?
I can do a compile test on PowerPC (and that's one of the platforms that gets tested with linux-next too) but I don't have hardware to do runtime tests with. Timur, would you be OK with compile tests for now - I'd not expect to see 2.6.33 go out this year so if there are any runtime issues it should be possible to fix them once you're back in the office?
Wait a sec before applying this, please. We might have caused a regression, I'm still investiating.
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.
Hence, we can only power down the codec when we're in system suspend, 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?
In any case, the current patch is plainly wrong and can be dropped. Sorry for the noise caused.
Daniel