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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
