Sorry. This was intended for the list, not only to werner. On Tue, Jan 6, 2009 at 16:27, <[email protected]> wrote: > On 2008-11-18, Werner Almesberger <[email protected]> wrote: >> Andy Green wrote: >>> There's a choice about using the userland i2c stuff to access the >>> storage for the program or having a driver at all. >> >> All in user space. Even better ! >> >>> If we have a driver, >>> we probably make a /sys you dump the LED state machine binary "program" >>> down to set it. That's probably as far as we should take it if even >>> that far. >> >> Yup, or hex, like the driver Andrzej mentioned. >> >>> What would guide us towards having a driver is if kernelside could want >>> to use the LEDs itself, eg, to indicate panic. >> >> Panic indication would seem a valid excuse for having something in >> the kernel, yes. But that could also be just a "panic-only" driver. >> It may have to violate quite a few rules anyway, to be able to get >> through to the LED controller when the system is in trouble. >> >> We don't have any easily GPIO-accessible LED, do we ? > > That would be easy: > Assuming all the LED's are directly connected to the LED driver, > one can also route a GPIO pin from the CPU directly to the LED > (for use in cases of kernel panic, etc). >
_______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
