On Dec 19, 2011, at 20:38, Mark Brown wrote: > On Mon, Dec 19, 2011 at 10:56:41AM -0600, Moffett, Kyle D wrote: >> I still don't understand how the regulator API is supposed to help in my >> particular case (whole-system poweroff). > > Well, it depends what you need to do. In the ST-Ericsson case what they > needed to do was collapse the core supplies for the CPU. But previously > you were talking about power domains, not whole system poweroff. > Usually a power domain is a subset of the full system power.
Well, I have control of 3 separate power domains in the sense that there are 6 physically separate computers sharing a single supply, with 2 in each domain (and only 1 of the 6 controlling the shared supply). Obviously when the 'control computer' goes off the GPIOs will fluctuate wildly, so the power supply only responds to the GPIOs as a signal to cut power, not to re-enable it. The system is designed to require user intervention to resupply power after it has shut itself down. So I do have separate power domains, but in this particular hardware build I simply want to shut them all down in a fixed order (due to the specific arrangement of power supply connections). Previously I had about 200 lines of code in my machine_poweroff hook to walk a list of GPIOs in the device tree and turn them all off in a fixed order. After looking at that a while I decided it would be better off as a pseudo-generic driver that could be used by any DT platform with a GPIO used to shut down system power. I ended up with the "gpio-poweroff" driver which also makes the time delays configurable. Since I noticed that platform_drv also has a device-specific poweroff hook, I added a boolean DT value to switch between powering down at machine_poweroff() time and powering down during the device->poweroff() walk. I realize that this driver is basically incapable of any kind of runtime power management but it could be used on X86 platforms that convert to device-tree. In particular ones with embedded controllers and BMC devices would otherwise be using ACPI device methods to poke a few GPIOs in basically the same fashion. The benefit is that instead of ACPI AML (bytecode poking magic IO registers at some undocumented address) you have a standard GPIO driver and a piece of pseudo-self-documenting device-tree that basically says "the HW engineers set it up so you set these GPIOs in that order and it turns off". Make sense? Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
