[PATCH] qi: initialize / canonical PMU state effects vs Qi init

[Werner Almesberger]

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