26 Jul, 2008

1 commit

  • This adds a simple sysfs interface for GPIOs.

    /sys/class/gpio
    /export ... asks the kernel to export a GPIO to userspace
    /unexport ... to return a GPIO to the kernel
    /gpioN ... for each exported GPIO #N
    /value ... always readable, writes fail for input GPIOs
    /direction ... r/w as: in, out (default low); write high, low
    /gpiochipN ... for each gpiochip; #N is its first GPIO
    /base ... (r/o) same as N
    /label ... (r/o) descriptive, not necessarily unique
    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)

    GPIOs claimed by kernel code may be exported by its owner using a new
    gpio_export() call, which should be most useful for driver debugging.
    Such exports may optionally be done without a "direction" attribute.

    Userspace may ask to take over a GPIO by writing to a sysfs control file,
    helping to cope with incomplete board support or other "one-off"
    requirements that don't merit full kernel support:

    echo 23 > /sys/class/gpio/export
    ... will gpio_request(23, "sysfs") and gpio_export(23);
    use /sys/class/gpio/gpio-23/direction to (re)configure it,
    when that GPIO can be used as both input and output.
    echo 23 > /sys/class/gpio/unexport
    ... will gpio_free(23), when it was exported as above

    The extra D-space footprint is a few hundred bytes, except for the sysfs
    resources associated with each exported GPIO. The additional I-space
    footprint is about two thirds of the current size of gpiolib (!). Since
    no /dev node creation is involved, no "udev" support is needed.

    Related changes:

    * This adds a device pointer to "struct gpio_chip". When GPIO
    providers initialize that, sysfs gpio class devices become children of
    that device instead of being "virtual" devices.

    * The (few) gpio_chip providers which have such a device node have
    been updated.

    * Some gpio_chip drivers also needed to update their module "owner"
    field ... for which missing kerneldoc was added.

    * Some gpio_chips don't support input GPIOs. Those GPIOs are now
    flagged appropriately when the chip is registered.

    Based on previous patches, and discussion both on and off LKML.

    A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
    merges to mainline.

    [akpm@linux-foundation.org: a few maintenance build fixes]
    Signed-off-by: David Brownell
    Cc: Guennadi Liakhovetski
    Cc: Greg KH
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

25 May, 2008

1 commit

  • The last gpio belonging to a chip is chip->base + chip->ngpios - 1. Some
    places in the code, but not all, forgot the critical minus one.

    Signed-off-by: Trent Piepho
    Acked-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trent Piepho
     

30 Apr, 2008

1 commit


28 Apr, 2008

4 commits

  • Add a new function gpiochip_reserve() to reserve ranges of gpios that platform
    code has pre-allocated. That is, this marks gpio numbers which will be
    claimed by drivers that haven't yet been loaded, and thus are not available
    for dynamic gpio number allocation.

    [akpm@linux-foundation.org: remove unneeded __must_check]
    [david-b@pacbell.net: don't export gpiochip_reserve (section fix)]
    Signed-off-by: Anton Vorontsov
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Vorontsov
     
  • If gpio_chip->base is negative during registration, gpiolib performs dynamic
    base allocation. This is useful for devices that aren't always present, such
    as GPIOs on hotplugged devices rather than mainboards. (This behavior was
    previously specified but not implemented.)

    To avoid using any numbers that may have been explicitly assigned but not yet
    registered, this dynamic allocation assigns GPIO numbers from the biggest
    number on down, instead of from the smallest on up.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Vorontsov
     
  • Introduce a gpio_is_valid() predicate; use it in gpiolib.

    Signed-off-by: Guennadi Liakhovetski
    [ use inline function; follow the gpio_* naming convention;
    work without gpiolib; all programming interfaces need docs ]
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski
     
  • As long as one or more GPIOs on a gpio chip are used its driver should not be
    unloaded. The existing mechanism (gpiochip_remove failure) doesn't address
    that, since rmmod can no longer be made to fail by having the cleanup code
    report errors. Module usecounts are the solution.

    Assuming standard "initialize struct to zero" policies, this change won't
    affect SOC platform drivers. However, drivers for external chips (on I2C and
    SPI busses) should be updated if they can be built as modules.

    Signed-off-by: Guennadi Liakhovetski
    [ gpio_ensure_requested() needs to update module usecounts too ]
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Guennadi Liakhovetski
     

06 Feb, 2008

1 commit

  • Provide new implementation infrastructure that platforms may choose to use
    when implementing the GPIO programming interface. Platforms can update their
    GPIO support to use this. In many cases the incremental cost to access a
    non-inlined GPIO should be less than a dozen instructions, with the memory
    cost being about a page (total) of extra data and code. The upside is:

    * Providing two features which were "want to have (but OK to defer)" when
    GPIO interfaces were first discussed in November 2006:

    - A "struct gpio_chip" to plug in GPIOs that aren't directly supported
    by SOC platforms, but come from FPGAs or other multifunction devices
    using conventional device registers (like UCB-1x00 or SM501 GPIOs,
    and southbridges in PCs with more open specs than usual).

    - Full support for message-based GPIO expanders, where registers are
    accessed through sleeping I/O calls. Previous support for these
    "cansleep" calls was just stubs. (One example: the widely used
    pcf8574 I2C chips, with 8 GPIOs each.)

    * Including a non-stub implementation of the gpio_{request,free}() calls,
    making those calls much more useful. The diagnostic labels are also
    recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot
    of all GPIOs known to this infrastructure.

    The driver programming interfaces introduced in 2.6.21 do not change at all;
    this infrastructure is entirely below those covers.

    Signed-off-by: David Brownell
    Cc: Sam Ravnborg
    Cc: Jean Delvare
    Cc: Eric Miao
    Cc: Haavard Skinnemoen
    Cc: Philipp Zabel
    Cc: Russell King
    Cc: Ben Gardner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell