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
