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