lkml.org 
[lkml]   [2005]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: best way to handle LEDs
    From
    On Tue, November 1, 2005 6:39 pm, Richard Purdie said:
    > On Wed, 2005-11-02 at 00:44 +0100, Pavel Machek wrote:
    >> Handheld machines have limited number of software-controlled status
    >> LEDs. Collie, for example has two of them; one is labeled "charge" and
    >> second is labeled "mail".
    >
    >> I think even slow blinking was used somewhere. I have some code from
    >> John Lenz (attached); it uses sysfs interface, exports led collor, and
    >> allows setting different frequencies.
    >>
    >> Is that acceptable, or should some other interface be used?
    >
    > This has been discussed before and I know there are several differing
    > opinions.
    >
    > Based upon previous discussion both here, on linux-arm-kernel and in the
    > handhelds community in general I came up with some ideas which I've yet
    > to have time to code. I'll try and describe it though:
    >
    > The system would be in two sections (classes?), leds themselves and led
    > triggers. The leds would be driven by something similar to John's driver
    > Pavel attached. I think colour and other unchanging properties of the
    > device should be something exported in the device name which could have
    > some format like: device_name-colour-otherprops.

    I believe that this can be built on top of my patch. If you take a look
    at the led patch Pavel posted, it allows for in kernel code to acquire the
    led by calling leds_acquire. Once a led is acquired through leds_acquire
    function, any input from userspace is ignored.

    Any interested kernel code can also register an interface to watch for led
    additions and removals.

    >
    > Led triggers would be kernel sources of led on/off events. Some
    > examples:
    >
    > 2Hz Heartbeat - useful for debugging (and/or Generic Timer)

    This is included already in the leds driver part, although it could be
    removed I guess...

    > CPU Load indicator
    > Charging indicator
    > HDD activity (useful for microdrive on handheld)
    > Network activity
    > no doubt many more

    All these are great ideas for triggers.

    >
    > led triggers would be connected to leds via sysfs. Each trigger would
    > probably have a number you could echo into an led's trigger attribute.
    > Sensible default mappings could be had by assigning a default trigger to
    > a device by name in the platform code that declares the led.

    This would be part of the triggers module... passing the right stuff into
    those sysfs options would cause the triggers module to call leds_acquire
    on the right led_properties structure.

    >
    > A trigger of "0" would mean the led becomes under userspace control via
    > sysfs for whatever userspace wishes to do with it.

    A trigger of "0" would call leds_release, which would cause the input from
    userspace in the leds driver to be accepted again.

    >
    > The underlying principle would be to keep this class as simple as
    > possible whilst maximising the options open for triggering the leds from
    > both the kernel and userspace.
    >
    > Does this sound like a sensible way forward?
    >

    I think it can already be done from my patch... all the functions are
    already there for in kernel manipulation.

    John

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-11-02 02:06    [W:0.044 / U:239.604 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site