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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 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.

Anything that the first kernel made assertions about the second kernel
can do it too.  So if the first kernel brought up WLAN (and wrongly
failed to take it down again when it was leaving), the second kernel is
in a position to control its state again properly when the driver for it
starts.

The worst that happens is WLAN stays up due to the broken boot menu
rootfs until that's fixed.

|> 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.

No that's fine that they're not doing anything about state of things if
they're not running.  Just that if you do start a driver in a module
controlling WLAN, say, it should have a policy about how WLAN comes up
in terms of on or off and apply it when it starts.

Before then, it isn't running and so had no assertion to make about it.

| 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.

It'd be bad news from a maintainence POV.  And there are situations
where you can't even meaningfully talk to the device without the
accompanying stack in-kernel, for example SDIO for WLAN.  So it makes
good sense to accept that we do not impact state of devices from sane
powerup default until their driver starts, module or not.

| 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

The bootloader should only touch things needed to get the Linux image in
the first place, and fix any non-sane defaults from reset or powerup
that couldn't be avoided (variant defaults in PMU for example).  It
shouldn't do anything else.

| 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.

Right but the point is that Qi does it by asserting state on a small
important subset of available PMU regs and inheriting sane defaults from
global state transitions that occurred before it started.

That's the same model we need in the kernel.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkl/lx0ACgkQOjLpvpq7dMoE+wCeKpEIVy3PJpOO/YmeeDweXdUq
tUwAn1lrO6WMeKs6hYJ7AH8nQgoH/MOg
=g8H1
-----END PGP SIGNATURE-----