On Thursday 12 March 2009, Mark Brown wrote: > On Wed, Mar 11, 2009 at 06:32:15PM -0800, David Brownell wrote: > > > Make the regulator setup code cope more consistently with > > regulators undesirably left enabled by the bootloader. > > First up I'd just like to make it absolutely clear that I agree that > this is a feature we should have - it's obviously useful. Feature being "consistency". I'd say "essential", not merely "useful" ... this is bugfix territory. There are things that just can't work with the current regulator framework, because its handling of this routine scenario is so inconsistent. It's not necessarily going to be safe to force every (!!) driver into that dance you had described (enable-it-then-disable-it), just to force all regulators into the kind of self-consistent state that framework users always expect to start with. Especially: RIGHT AFTER INITIALIZATION!!! There's no excluse to be self-inconsistent that early, even if there were an excuse later on. The "v4" patch I posted resolves that inconsistency in about the simplest way I can find; but unlike this patch it doesn't solve the "force this regulator off" problem. > It is a particular problem for multi-function devices like pcf50633 > which not only register all their regulators by default but also embed > constraints within the general pcf50633 platform data. The pcf50633 driver didn't *need* to register all regulators; and I don't see what the issue would be with platform_data. Its MFD core could easily check the regulator init data and skip regulators that didn't initialize a key field. > If the user > simply turns on the regulator driver in their config they'll get this > behavior if they don't edit the code. Even with regulator code I'd not > be surprised if people were bitten by this for things like the memory or > a CPU core without regulator based DVFS. That would be part of why the twl4030 regulators are only registered on request! Not only will a given board tend to not use all those regulators, but a number of them really aren't intended to be managed by Linux. (And then there are board options, like what various control signals do.) Similar things could happen with a system using pcf50633. There's no reason one of the LDOs or switching regulators shouldn't be managed exclusively by another I2C master on that bus ... they each have dedicated registers, and its not uncommon to dedicate a microcontroller to managing just one part of a system (and its resources). > You've addressed some of the use cases for this by providing devmode but I think it's pretty ugly myself, but you did say something about wanting explicit support for reverse engineering. The "v4" patch which I just sent uses a simpler approach; such support doesn't need to be explicit in order to work. -- 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
