GTA03 LED controller: LP5521

[Joerg Reisenweber]

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.

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20090113/c2459127/attachment.pgp