Re: [PATCH] regulator: Provide a check for dummy regulator

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

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

On Thu, Apr 19, 2012 at 03:21:37PM +0530, Jassi Brar wrote:
> Usually changing the regulator output involves delays before/after the
> operation.
> There are consumer drivers shared by platforms, where some may
> not really have a regulator in the path. Which causes the consumer
> to unnecessarily (sometimes disruptively) incur delays for the
> "dummy" regulator.

This analysis doesn't sound quite right - if it's the dummy regulator
then obviously these delays don't happen so presumably the cost is
actually coming from the rdev mutex and recursion up the regulator tree
- the basic overheads of calling into the regulator API.

> Since the 'struct regulator' is opaque outside of the core,
> provide a function to check if the given regulator is a dummy one.

No, this isn't great from a usability and abstraction point of view.  

In usability terms this sort of performance optimisation is going to be
desired by a wide range of drivers (and wouldn't hurt those that don't
urgently need it) so we shouldn't force every user to open code the use
of this information.  Worse, the whole point of the dummy regulator is
that it allows users to not worry about this sort of stuff so it'd mean
that the dummy regulator was failing to perform its only function.

In abstraction terms it's not the fact that it's a dummy regulator
that's interesting here but rather the fact that the regulator doesn't
have control the consumer can use and there's a whole raft of other
reasons why that might be the case.  The constraints may not permit
status changes, or a real regulator may not physically support enable
and disable operations (eg, if there's a GPIO for enable and it's tied
on all the time).  If there's a useful performance win for dummy
regulators it'll apply equally well to all these other cases so we
should't be special casing dummy regulators.

I've just sent out an untested patch (you're CCed) which should give a
substantial win for the enable/disable case which will hopefully address
the issue for you.  If you're concerned about voltage change rather than
enable/disable I'd like to understand better exactly where the
performance is going but we can certainly do a similar fast path for
fixed voltage regulators.  I'd be surprised if consumers that need to
change voltages played nicely with the fixed voltage regulator while
using it often enough for anyone to care about performance.

I really don't understand why people are so keen to special case things
like this in individual consumers, not sure what we can do to encourage
more generic fixes.  There was a guy from Qualcomm the other week who
was absolutely insistent that we had to do some fragile special case
stuff with supplies for similar reasons :(

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]