accessing SD_3V3 in drivers/mmc/host/s3cmci.c

Mark Brown broonie at
Thu Feb 5 13:48:09 CET 2009

On Thu, Feb 05, 2009 at 10:13:08AM -0200, Werner Almesberger wrote:
> Balaji Rao wrote:

> > In mach-gta02.c, when we define SD_3V3, we also have to specify which
> > device is the consumer - which means the supply namespace is not global
> > and it depends on the device and not the platform.

> Yes, that's why it works. But I'm somewhat doubtful whether this is
> really how regulator_get is meant to be used. Perhaps Mark can
> comment ? (Copied him.)

Yes, that's exactly the intention.  If you don't do this you force every
device that uses regulators to have platform data specifying which
regulators to use and every platform that wants to use them to specify
per-device platform data.  Doing things this way mirrors the clock API
and greatly reduces the amount of boilerplate required in platforms and
drivers to set things up (you only have a single table on the regulator
device, rather than having every single device using regulator APIs
needing platform data).

Note that when you add consumers you're specifying a per-consumer name
that the consumer will use to request the regulator - it's just a key
used for lookup.  The regulator driver can name the actual regulator
anything it likes and the machine can override what gets displayed using
the constraints.  The name the client uses is just a key used to do a

> > So, I think it's
> > reasonable to assume that any regulator that supplies it will be
> > named SD_3V3 ?

> Ah, but who says that there will be a regulator ? Or something that's
> electronically a regulator but for some reason doesn't use the
> regulator API ? Or something that needs a chain of things to be set
> up, maybe involving a regulator ?

I suggest dealing with this by providing a standard regulator API
set_power() in the s3cmci driver that platforms which use regulators can
assign in their platform data.  This avoids people rewriting the
standard regulator API implementation.

More information about the openmoko-kernel mailing list