On Saturday 14 March 2009, Mark Brown wrote: > On Sat, Mar 14, 2009 at 12:08:30PM -0700, David Brownell wrote: > > > The basic problem is that still-unfixed goofage in the regulator > > framework: it seriously mis-handles regulators that bootloaders > > leave enabled. This can be teased apart into at least two bugs, > > possibly as many as four. The fix for one of them is queued in > > the regulator-next tree. > > For clarity, what David is referring to here is that it's not currently > possible for the machine constraints to turn off a regulator that has > been left enabled when the kernel starts. Not quite -- that would be one solution, for the first several cases I had to deal with. But thinking about how to handle the video support makes it clear that's not always the best solution. One needs bootloaders to be able to throw a splash screen which stays active until the window system kicks in ... but turning off video regulators would clearly blacken the screen, which is the wrong model. (And marking them as "always on" or "boot_on" is wrong for other reasons.) The way clocks handle that is with a late disable, so drivers have a chance to start up. You rejected the REGULATOR_DISABLE_UNUSED patch I sent, applying that model ... and that's why I started to think about other approaches, as in the "early disable" patch I sent earlier in this thread. A third approach (after applying that one patch that's in the regulator-next tree) would be if (rdev->is_enabled() > 0) rdev->use_count = 1; when initializing regulators. I updated the TWL4030 code so is_enabled() checks only the Linux enables, while get_status() reports the true state, so maybe that would be a solution you'd accept. Of course that makes use_count be even more of a misnomer, but that's a separate issue ... refcounts should be handled by the driver model. - Dave -- 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
