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

Andy Green andy at openmoko.com
Wed Jan 28 10:00:02 CET 2009


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> The bootloader should only touch things needed to get the Linux image in
|> the first place,
|
| While making sure it does so without leaving the 100mA (well, 80mA)
| envelope. That's why Qi has to control so many things already.

Wah it seems to be coming around to "nothing is possible" thread again.

| I mean, this is an obviously fragile design, its fragility has already
| revealed itself in real bugs, and I'm quite sure that we'll find more
| once we proceed looking into current consumption in GTA02.

The same kernel runs on GTA01 and 03 and other things... the kernel
needs to be stood off from all detail that doesn't concern what it is
claiming to be providing.  What you're suggesting is "reverse U-Boot
scenario" where we reproduce the bootloader in the kernel for no reason
and with consequent unmaintainability and genuine fragility through that.

After all, the kernel can't be running unless things are in a sane,
inherited state already, so it's actually an unavoidable implicit
requirement: I am just making it explicit so we can take care of it more
clearly.

At the point a driver runs it makes a claim about controlling of a piece
of hardware so it's then it needs to enforce its state, and it is in the
right position to do so as well (SDIO stack case for WLAN for example).

| Besides, Qi already does a fairly comprehensive initialization of
| GPIOs and the PMU, so ...
|
|> That's the same model we need in the kernel.
|
| ... perhaps we do agree after all ? :-)

Actually the GPIO init needs chopping down to just the ones that are not
set to right level by default.  The reason they're all set is I read the
"undef" notation in the manual for GPIO reset level as meaning their
output level was undefined at reset, but it seems they merely mean the
read value depends on what the GPIO is hooked to.

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

iEYEARECAAYFAkmAHpIACgkQOjLpvpq7dMoF9wCfblH0UVc674Vhv3NLup5HNZtV
5x0Anj5Z4R6Ri79+8N6vfkTpqGtVvIOC
=y+wd
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list