On Thu, Apr 07, 2016 at 08:17:25PM +0200, Martin Fuzzey wrote: > On 07/04/16 19:02, Mark Brown wrote:
> >No, this is not sensible. You should be telling the framework about the > >slew rate and letting the framework work out how long it's going to take > >to transition. Your driver shouldn't be peering around inside other > >regulators, it should be telling the framework what it does itself and > >any handling of interrelationships should be in the framework. > Ok, but I fail to see any way to do that (at least with the framework as > is). Then send patches for the framework. One of the great things about working on Linux is that the whole OS is free software so you don't have to work around things in your driver! I've not looked at the code for this specific case. > Or are you saying I should extend the framework to add a .get_ramp_delay > driver callback and make the framework do the calculation itself? Yes. > While moving it to the framework will avoid the driver knowing about other > regulators it won't fix the underlying issues I mentionned. > For a regulator configured as always-on the framework doesn't lookup and > enable the parent regulators until regulator_register_resolve_supply() > is caused right at the end of regulator_register(). > This means that, when the always-on register is enabled it has no supply > assigned, even at the framework level. You might find this changing very shortly but in any case the answer is still the same, change the framework if it needs changing.
signature.asc
Description: PGP signature
