lkml.org 
[lkml]   [2008]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectOpenFirmware GPIO LED driver
    This series of patches adds support for OpenFirmware bindings for GPIO based
    LEDs.

    I last posted a version of this in July but discussion of the OF binding
    details didn't seem to be going anywhere.

    I've since been contacted by some people who are actually using the previous
    patches and have been motivated to try again.

    All the users of this code are satisfied with the current version and it does
    everything they need it to do.

    The first patch extends the of_get_gpio() function to provide the gpio flags.

    The way this already works (i.e., this is not something I'm adding, it's
    what's already there) is that the OF gpio specifier is an opaque sequence of
    words. The GPIO controller driver (of which only one currently exists)
    provides an ->xlate() method that turns this into a Linux gpiolib gpio number.
    All current gpio controllers have flags in their gpio specifier, but there is
    no way to get them. So I extend the xlate method to also produce the flags in
    a Linux format, the same way it produces a Linux gpio number.

    The second patch adds OF bindings to the gpio-leds driver. The existing code
    is refactored so that almost all of the common code is shared between the two
    binding methods. Either or both bindings can be selected via Kconfig. The
    bindings do have one "linux," property, but no one has been able to come up
    with something close to workable that avoids this and still satisfies the
    *requirement* that the default trigger be settable from the OF bindings.

    The second and third patches add some additional capabilities for gpio leds
    that some users need.

    One is to have a LED start in the on state when it's made known to Linux.
    There is already a "default-on" trigger that does this, but it produces a
    glitch where an LED that is already on will turn off then back on. My (tiny)
    patch avoids this problem.

    The next lets an LED stay, without glitches, in whatever state it was already
    in when it's made known to Linux. It may have been put into this state by the
    BIOS, firmware, bootloader, or the hardware itself.


    \
     
     \ /
      Last update: 2008-10-25 01:09    [from the cache]
    ©2003-2011 Jasper Spaans