Andy Green wrote: > We still have been through a PMU suspend at some point and not NOPOWER > since then.
Yup, and a lot may have happened since, including a different kernel doing the reboot or, perhaps more likely, a kexec. > Right, hence the bit about drivers should be responsible to assert state > of the thing they're driving when they start. Yet they may be absent, e.g., if compiled as a module. We could introduce stub drivers - like the *_pm_* we have in plat-s3c24xx already - that take care of this on their behalf, or have one central instance that takes care of this. I prefer the central instance because it puts all the information in one place and there can be no ambiguity about what gets set when the kernel starts. We care about these things even in the absence of the driver because we wouldn't want an unused component burn power for no good reason. > That's telling us something different, changing the bootloader to init > less exposed something else that did need init. It doesn't mean we're > on the wrong path. Yes, agreed. The boot loader should be free to control as much as it likes. My concern is about the kernel, who shouldn't have to rely on an initial state that's influenced by just too many other parties. > Here is a complete list and analysis of impact of PMU NOPOWER and > suspend modes compared with Qi init for GTA02: Great list, thanks ! So Qi is already taking almost complete control. - Werner
