Messages in this thread | | | Date | Thu, 19 Apr 2012 13:42:04 +0100 | From | Mark Brown <> | Subject | Re: [PATCH] regulator: Provide a check for dummy regulator |
| |
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 :( [unhandled content-type:application/pgp-signature] | |