GTA03 LED controller: LP5521

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

GTA03 LED controller: LP5521

Werner Almesberger
This is a discussion that started on an internal list but that really
ought to be public. So I'm dragging it here, kicking and screaming ...

In GTA03, we'll use the following controller chip for some LEDs:
http://www.national.com/pf/LP/LP5521.html

One thing that's interesting about it is that it can be programmed
in some form of primitive assembler language. National magnificently
call the tool to translate this language to its binary representation
a "compiler".

There's been concern about whether National would give us the right
to redistribute their Windows-based compiler. However, since the
translation task seems to be more than trivial, I think we're better
off just rewriting the thing from scratch.

To make a nice parser in little time, lex and yacc are useful. Here's
an example using them:
http://svn.openmoko.org/developers/werner/greg/

The above example also shows how one can easily add cpp to one's
parser. That way, the usual convenience items (comments, macros, and
include files) are taken care of.

Some people have suggested that the translator is so simple that one
should even put it into the kernel ...

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

andrzej zaborowski
Hi,

2008/11/18 Werner Almesberger <[hidden email]>:

> This is a discussion that started on an internal list but that really
> ought to be public. So I'm dragging it here, kicking and screaming ...
>
> In GTA03, we'll use the following controller chip for some LEDs:
> http://www.national.com/pf/LP/LP5521.html
>
> One thing that's interesting about it is that it can be programmed
> in some form of primitive assembler language. National magnificently
> call the tool to translate this language to its binary representation
> a "compiler".
>
> There's been concern about whether National would give us the right
> to redistribute their Windows-based compiler. However, since the
> translation task seems to be more than trivial, I think we're better
> off just rewriting the thing from scratch.
>
> To make a nice parser in little time, lex and yacc are useful. Here's
> an example using them:
> http://svn.openmoko.org/developers/werner/greg/
>
> The above example also shows how one can easily add cpp to one's
> parser. That way, the usual convenience items (comments, macros, and
> include files) are taken care of.
>
> Some people have suggested that the translator is so simple that one
> should even put it into the kernel ...

linux-omap-2.6 people thought so and made a very simple interface for
programming the lp5521 where the compilation is left to be done in
user's head.  It's described in this mail:
http://markmail.org/message/nbfweohulpjd5fx2
Obviously it's very limited compared to your compiler, I find the
compiler very cool.  (Is it turing complete? ( - assuming that cpp
isn't))

Their driver is at
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=drivers/i2c/chips/lp5521.c;h=c0862d9f2690f0f0daa38f21659aed7011dff175;hb=HEAD
, I don't know if you planned to use it.

Cheers

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

andy green-3
In reply to this post by Werner Almesberger
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| Some people have suggested that the translator is so simple that one
| should even put it into the kernel ...

There's a choice about using the userland i2c stuff to access the
storage for the program or having a driver at all.  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.

What would guide us towards having a driver is if kernelside could want
to use the LEDs itself, eg, to indicate panic.

Another aspect suggesting we need a driver is trying to integrate the
LED actions and colours / programs with led class stuff like triggers.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkiiNYACgkQOjLpvpq7dMrMXgCcCTq9UxF8oOHzdmSOGKsiLSPz
zGMAn3cGssJgiX/GpxRXA1wNQ91Ffirq
=P5Rk
-----END PGP SIGNATURE-----

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

Werner Almesberger
In reply to this post by andrzej zaborowski
andrzej zaborowski wrote:
> Their driver is at
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=drivers/i2c/chips/lp5521.c;h=c0862d9f2690f0f0daa38f21659aed7011dff175;hb=HEAD
> , I don't know if you planned to use it.

Neat ! If this is going into mainline, we should definitely consider
using it.

Thanks,
- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

Werner Almesberger
In reply to this post by andy green-3
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 ?

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

andy green-3
In reply to this post by andrzej zaborowski
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| linux-omap-2.6 people thought so and made a very simple interface for
| programming the lp5521 where the compilation is left to be done in
| user's head.  It's described in this mail:
| http://markmail.org/message/nbfweohulpjd5fx2
| Obviously it's very limited compared to your compiler, I find the
| compiler very cool.  (Is it turing complete? ( - assuming that cpp
| isn't))
|
| Their driver is at
|
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=drivers/i2c/chips/lp5521.c;h=c0862d9f2690f0f0daa38f21659aed7011dff175;hb=HEAD
| , I don't know if you planned to use it.

It's a really good find Andrzej, we should just use this.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkijQUACgkQOjLpvpq7dMqbIQCePpMd7xkpvvegbdfcv9VYqbHJ
PMgAni6qy+KfzVDZnNbVYGB2uH4r5hKx
=hlbc
-----END PGP SIGNATURE-----

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

Michael 'Mickey' Lauer
Fwiw, I have no preference from the framework's point of view. Whether we use
the sys interface or something more fancy won't make a difference for us,
we'll get every monster to hide behind a shiny dbus interface :)

--
:M:

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

Flemming Richter Mikkelsen
In reply to this post by Werner Almesberger
Sorry. This was intended for the list, not only to werner.

On Tue, Jan 6, 2009 at 16:27,  <[hidden email]> wrote:

> On 2008-11-18, Werner Almesberger <[hidden email]> 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
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: 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,  <[hidden email]> wrote:
> > On 2008-11-18, Werner Almesberger <[hidden email]> 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

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

Werner Almesberger
Joerg Reisenweber wrote:
> 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.

A device can block the I2C bus indefinitely under some circumstances,
e.g., if you're unlucky enough to crash while in the middle of an I2C
transfer, SCL is low, and the device is sending a 0 or an ACK.

Interestingly, not even a start condition is a reliable way to clear
a stuck bus. (As I found out when experimenting with I2C from IDBG.)

We used to have I2C bus issues fairly often in the past, perhaps also
due to excessively large pull-ups causing badly deformed signals on
some earlier boards, but it seems that this subsystem is reasonably
under control now.

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Reply | Threaded
Open this post in threaded view
|

Re: GTA03 LED controller: LP5521

andy green-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Joerg Reisenweber wrote:
|> 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.
|
| A device can block the I2C bus indefinitely under some circumstances,
| e.g., if you're unlucky enough to crash while in the middle of an I2C
| transfer, SCL is low, and the device is sending a 0 or an ACK.

The devices we have on GTA02 are simple state machines for I2C action,
all of them are rated at 400Hz so they won't have SCK-driving
arrangements anyway to enforce slower SCK.

So I don't think we need to worry about this kind of scenario.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklttOoACgkQOjLpvpq7dMrN9wCcCVNyC6LckblzYOrY+ouJzIn+
bEoAn31N77/V1Mq52UIpBsOpM3DPBODL
=gtJj
-----END PGP SIGNATURE-----

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware