[PATCH] qi: initialize / policy for reset and IO bringup

Andy Green andy at openmoko.com
Sun Jan 25 12:41:27 CET 2009


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

Somebody in the thread at some point said:

|> What did you actually suggest "a long time" ago?
|
| To make the kernel's GPIO and PMU setup self-contained:
| http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002553.html
| (Section "Stand-alone kernel".)

I think it's simpler (certainly less wordy :-) ) if I just explain what
our hardware -> bootloader -> kernel design policy should be.

1) We need every IO state to be appropriate from hardware reset.  Saying
that we will set all state in bootloader or kernel is really accepting a
window in time between reset and the bootloader starting where stuff can
be at the wrong level.  It's just a workaround for broken hardware
design.  If we need to stick inverters in if we can't select something
that has the right levels by default then it won't kill us.

2) If we can't guarantee device behaviour from reset due to closed
firmware, make its power switched and default it to off from hardware
reset.  Then when the driver and stack needed to talk to it are ready,
we can assert its state properly.

3) Defer all other init to the point that something runs that makes a
logical assertion about the functional state, eg, the bootloader for
some things necessary to boot Linux, but mainly the Linux driver,
whether it is in a module or not.  That goes the same for regulator
bringup as IO.

Then we have the leanest, easiest maintained bootloader and drivers, and
guaranteed safe behaviour from reset.

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

iEYEARECAAYFAkl8T+cACgkQOjLpvpq7dMqkYgCeJ5cjwLjowYAEFym+zqiZ5Ih7
oNMAoIB9Ry2KIyJwWGeKhXtQ3X0MmdS0
=+BOM
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list