GTA03 LED controller: LP5521
joerg at openmoko.org
Tue Jan 13 22:48:30 CET 2009
Am Di 6. Januar 2009 schrieb Flemming Richter Mikkelsen:
> Sorry. This was intended for the list, not only to werner.
> On Tue, Jan 6, 2009 at 16:27, <quatrox at gmail.com> wrote:
> > On 2008-11-18, Werner Almesberger <werner at openmoko.org> 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).
Nope, you can't do that this easily.
The chip is using a charge pump to impose correct current to the LED,
independent of a series R (iirc).
This isn't plain compatible with driving the LED from CPU GPIO. Also creeping
currents from LED driver chip into suspended CPU need consideration, as well
as short circuit current on collision between GPIO state and LED driver
output (we don't want to implement a CPU self destruct mechanism ;)
The chip has a GPIO which can be used to trigger a different program, so
assertion from CPU via simple GPIO would be easy this way - anyway it
requires loading a program to the chip that actually handles this switching
via digital line. I would prefer to hook up some more interesting signals
than a mere CPU GPIO to this pin though, preferably signals you might want to
monitor while CPU suspended (BT activity? Charging state?).
I don't think this direct CPU GPIO thing would be a better alternative to an
emergency driver directly accessing I2C to force some few bytes into the LED
controller. Userland should be STOPed completely on kernel panic anyway, so
no possibility for collisions on driver chip usage. For the kernel emergency
driver I don't see the big difference between asserting a GPIO and pushing a
few bytes to I2C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20090113/c2459127/attachment.pgp
More information about the hardware