On Tue, Sep 15, 2009 at 05:39:09PM -0500, Lopez Cruz, Misael wrote:
Mark Brown wrote:
I'd not expect full interoperability but I'd expect that at least the basic PDM support would interoperate happily. It wouldn't surprise me if more than one manufacturer came up with the same extension for multi channel PDM.
If that's the case, then a more appropriate name should be chosen. Or is it fine for you _MCPDM?
I'd suggest just plain _PDM.
The codec is turned on/off through an external line (i.e. with a gpio). Then, codec enable is board-dependent.
Might it make more sense to specify a GPIO line instead, at least by default?
Not sure, if the GPIO line is in TWL6030 (mfd) as well then probably it's fine, which may be the case for now. But isn't it violating CODEC independency anyway?
I don't see an abstraction problem - gpiolib can handle this well enough.
If you mean to sustitute the codec_enable function by the GPIO line, then it opens the possibility to make the CODEC to request and operate a GPIO line belonging to a different chip, for example to the application processor.
If the CODEC GPIOs are supported via gpiolib that shouldn't be a problem. If you specify the GPIO as an int then it'll also be possible to have invalid values so that cases with the CODEC hard wired to power up will also be handled.
It just seems easier for boards to have the CODEC do the gpio request and so on so that it's a simple data value that needs to be set.