On Fri, Mar 06, 2009 at 04:07:16PM -0800, David Brownell wrote: > The boot_on semantics are kind of odd then ... > What I thought they meant: Bootloader turned this on. That's still roughly the case, though in practice there's no actual need to do this for the vast majority of regulators since it is possible for the kernel to just read the status of the regulator back at runtime which is obviously more reliable. > What you describe above: Kernel turn this on during startup. What's happening here is that the kernel is making sure that the information it was given about the state of the regulator is actually true in case it was important (things could drift if the bootloader or hardware are improved to boot up with a better default configuration, for example). The kernel could warn here but we'd need to be clear why the constraints tell us that the regulator is on. This also has the side effect of allowing the constraints to turn the regulator on at startup, perhaps to aid early boot or perhaps because not all the drivers in the system that need it have regulator support yet, but that wasn't the primary purpose. > Versus normal behavior: Consumer turns it on, as needed. That now works as normal. Originally using boot_on would've had the effect of setting an always_on constraint which really wasn't desirable since we already have that. > I wouldn't have thought there would be a need for that > second case, since the board-specific init code can > just define a consumer that turns it on if that's what > it needs. Yes, it could - or it could define an always_on constraint if that were what's needed. On the other hand, it's the sort of thing that more than one board is going to need to do so it does make sense to factor it out a bit. -- 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
