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 lookup. > > 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.
