06 Jul, 2010

3 commits

  • Implement generic OF gpio hooks and thus make device-enabled GPIO chips
    (i.e. the ones that have gpio_chip->dev specified) automatically attach
    to the OpenFirmware subsystem. Which means that now we can handle I2C and
    SPI GPIO chips almost* transparently.

    * "Almost" because some chips still require platform data, and for these
    chips OF-glue is still needed, though with this change the glue will
    be much smaller.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Grant Likely
    Cc: David Brownell
    Cc: Bill Gatliff
    Cc: Dmitry Eremin-Solenikov
    Cc: Benjamin Herrenschmidt
    Cc: Jean Delvare
    Cc: Andrew Morton
    CC: linux-kernel@vger.kernel.org
    CC: devicetree-discuss@lists.ozlabs.org

    Anton Vorontsov
     
  • Currently the kernel uses the struct device_node.data pointer to resolve
    a struct gpio_chip pointer from a device tree node. However, the .data
    member doesn't provide any type checking and there aren't any rules
    enforced on what it should be used for. There's no guarantee that the
    data stored in it actually points to an gpio_chip pointer.

    Instead of relying on the .data pointer, this patch modifies the code
    to add a lookup function which scans through the registered gpio_chips
    and returns the gpio_chip that has a pointer to the specified
    device_node.

    Signed-off-by: Grant Likely
    CC: Andrew Morton
    CC: Anton Vorontsov
    CC: Grant Likely
    CC: David Brownell
    CC: Bill Gatliff
    CC: Dmitry Eremin-Solenikov
    CC: Benjamin Herrenschmidt
    CC: Jean Delvare
    CC: linux-kernel@vger.kernel.org
    CC: devicetree-discuss@lists.ozlabs.org

    Grant Likely
     
  • The OF gpio infrastructure is great for describing GPIO connections within
    the device tree. However, using a GPIO binding still requires changes to
    the gpio controller just to add an of_gpio structure. In most cases, the
    gpio controller doesn't actually need any special support and the simple
    OF gpio mapping function is more than sufficient. Additional, the current
    scheme of using of_gpio_chip requires a convoluted scheme to maintain
    1:1 mappings between of_gpio_chip and gpio_chip instances.

    If the struct of_gpio_chip data members were moved into struct gpio_chip,
    then it would simplify the processing of OF gpio bindings, and it would
    make it trivial to use device tree OF connections on existing gpiolib
    controller drivers.

    This patch eliminates the of_gpio_chip structure and moves the relevant
    fields into struct gpio_chip (conditional on CONFIG_OF_GPIO). This move
    simplifies the existing code and prepares for adding automatic device tree
    support to existing drivers.

    Signed-off-by: Grant Likely
    Cc: Andrew Morton
    Cc: Anton Vorontsov
    Cc: Grant Likely
    Cc: David Brownell
    Cc: Bill Gatliff
    Cc: Dmitry Eremin-Solenikov
    Cc: Benjamin Herrenschmidt
    Cc: Jean Delvare

    Anton Vorontsov
     

21 Dec, 2008

1 commit


03 Dec, 2008

1 commit

  • This adds a new function, of_get_gpio_flags, which is like
    of_get_gpio(), but accepts a new "flags" argument. This new function
    will be used by the drivers that need to retrieve additional GPIO
    information, such as active-low flag.

    Also, this changes the default ("simple") .xlate routine to warn about
    bogus (< 2) #gpio-cells usage: the second cell should always be present
    for GPIO flags.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Paul Mackerras

    Anton Vorontsov
     

22 Jul, 2008

1 commit

  • Since commit 7560fa60fcdcdb0da662f6a9fad9064b554ef46c (gpio:
    and "no GPIO support here" stubs) drivers can use GPIOs if they're available,
    but don't require them.

    This patch actually enables this feature.

    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: Anton Vorontsov
    Signed-off-by: Benjamin Herrenschmidt

    Wolfgang Grandegger
     

17 Apr, 2008

1 commit

  • This implements various helpers to support OF bindings for the GPIO
    LIB API.

    Previously this was PowerPC specific, but it seems this code isn't
    arch-dependent anyhow, so let's place it into of/.

    SPARC will not see this addition yet, real hardware seem to not use
    GPIOs at all. But this might change:

    http://www.leox.org/docs/faq_MLleon.html

    "16-bit I/O port" sounds promising. :-)

    Signed-off-by: Anton Vorontsov
    Acked-by: Grant Likely
    Signed-off-by: Paul Mackerras

    Anton Vorontsov