Re: [alsa-devel] [PATCH 1/3] ASoC: TWL6030: Add twl6030 codec driver

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.