Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver

[Nishanth Menon <nm@ti.com>]

On 20:35-20130402, Andrii Tseglytskyi wrote:
> On 04/02/2013 08:16 PM, Mike Turquette wrote:
> >Quoting Nishanth Menon (2013-04-01 20:35:45)
> >>On 17:05-20130401, Mike Turquette wrote:
> >>>OK, so we're in agreement on what The Future looks like.  What does that
> >>>mean for Andrii's patchset?
> >>Unless anyone has an fundamental issue with the approach of an "Super
> >>regulator" controlling "sub regulators", I think, in-line with your
> >>view, we should probably make ABB as an regulator instead of inventing
> >>our own API and hooking it around clock notifiers.
> >ACK.  Making the ABB code into a regulator driver is the right thing to
> >do regardless of whether or not we use a Super Regulator(tm) or just
> >chain together Not So Super Regulators(tm).
> >
> >I'm not an expert at the regulator framework, but I encourage Andrii to
> >look into regulator_set_mode(), which might be a more semantically
> >accurate alternative than regulator_set_voltage() for the ABB ldo.
> 
> 
> Agree. It is a good idea in general.
> regulator_set_mode() API seems to be good enough for handling ABB
> mode (FBB/RBB/Bypass).
> Knowledge about ABB mode on each OPP can be moved from ABB regulator
> to "Super regulator".
> Thanks a lot for all your comments.
> 

Digging a little more on this:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/regulator/consumer.h#n41

If we were to mean usage of mode to mean - usage of PWM/PFM etc
mode(like in tps/twl chips), this makes sense. However, if we mean
forward, reverse and bypass as "modes" we might be misusing the original
intent of the API.

-- 
Regards,
Nishanth Menon