[PATCH] qi: initialize PMU GPIOs

[Werner Almesberger]

Andy Green wrote:
> It's not the "next step" but exactly what I wrote.

I was thinking of a central table, like port_init_gta02 in Qi's
src/cpu/s3c2442/gta02.c, not individual setup in each driver.

The latter would of course make the drivers more self-contained,
but the former has the advantage that we have the entire system
at one glance, everything gets set up at the same time, and we
don't have to worry about things that may only exist as a module.

Another possibility would be to let every driver fend for itself,
but to automatically generate such a table (for Qi and for humans)
from the driver code.

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

And then there's further discussion in the subthread starting here:
http://lists.openmoko.org/pipermail/openmoko-kernel/2008-August/004649.html

There, I also suggested not to worry about GPIOs the boot loader
doesn't care about. I now think we can be a bit more aggressive.
There's why - it comes down to three issues:

1) if we try to minimize power consumption, the boot loader should
   control all items that aren't guaranteed to be in the perfect
   state at reset

2) if we do u-turns in our design, such as having an active-low
   nSELFDESTRUCT in one version and an active-high SELFDESTRUCT in
   the next one, both on the same GPIO, then the best policy is to
   touch as little as possible

3) try to avoid code duplication and divergence

I think the scale now tips more to the side of 1) than 2), and the
kernel is now also less eager to turn on all the lights as soon as
it gets the chance. So if the kernel starts providing a set of
authoritative settings it would make sense to just make the boot
loader track what the kernel does.

>  NOR U-Boot action is
> an obvious fly in the ointment.

Naw, NOR doesn't matter. It's just one more reason why we shouldn't
trust the boot loader to do all the initialization.

> It does though increase the number of times when there is temporary
> possibility of different state in the hardware.

This is true, but most of those extra cases are just the ones
where the boot loader does something the kernel later has to undo,
particularly if we follow the concept described above.

Also, in a way it doesn't matter. The boot loader's job is to load
the kernel and hand it a system it can run in. So if it leaves some
mess somewhere, then that's no drama as long as the kernel can clean
it up on its own.

> No it's death to try to tie one of three bootloaders that can be in use
> to kernel patchlevel.

Alright, how about using a format that allows the file just to be
copied over manually ? That should give us both, easy convergence
and control.

> The pullup is just wrong regardless of PMU private state :-)

It's not as if we had much of a choice, given that the PMU's GPIO
is open-collector. What would have been be nice is an active-low
enable input for the switch, like in the RT9711.

- Werner