Re: [PATCH] ASoC: add RT5640 CODEC driver

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

On Wed, Apr 17, 2013 at 12:56:30PM -0600, Stephen Warren wrote:
> On 04/17/2013 12:52 PM, Mark Brown wrote:

> > Not if you do it at the other end - do it during device registration.
> > If nothing is set up then feed the regulator API whatever the default
> > configuration is for the device, otherwise use what you were given.
> > The consumer side can't tell where the configuration came from and will
> > always have one.

> > This does mean you need to do the regulator driver if you support
> > non-default configurations but that's no bad thing.

> OK, so something like:

> During DT parsing:

> if (!dt_property_exits())
>     // regulator API call to set up a dummy regulator for this device

You should probably have an actual regulator for the regulator that's
physically there and doing things but yes.  If (as one should) you're
supporting platform data as well then the DT code should just work with
no extra effort.

The WM8994 code I posted recently does all this, the regulator side is
in -next though Samuel didn't pick up the DT stuff yet and non-default
configurations just aren't supported except with platform data since I
am not aware of any such designs.

> The one thing I may have forgotten to mention here for the LDO1 case is
> that if we don't explicitly support regulators right away, then instead
> the driver needs to explicitly request a GPIO to control the LDO1_EN
> input on the chip; without that, the device won't even respond to I2C
> accesses. And hence, that GPIO also needs to be described in device
> tree. The other regulators could certainly all work as you're pointing out.

That's expected, yes - you can just define a property for the GPIO and
move it over to being handled by a proper regulator driver when you
write one.