1. 18 Feb, 2016 1 commit
  2. 12 May, 2015 1 commit
    • Johan Hovold's avatar
      gpio: remove gpiod_sysfs_set_active_low · 166a85e4
      Johan Hovold authored
      Remove gpiod_sysfs_set_active_low (and gpio_sysfs_set_active_low) which
      allowed code to change the polarity of a gpio line even after it had
      been exported through sysfs.
      
      Drivers should not care, and generally does not know, about gpio-line
      polarity which is a hardware feature that needs to be described by
      firmware.
      
      It is currently possible to define gpio-line polarity in device-tree and
      acpi firmware or using platform data. Userspace can also change the
      polarity through sysfs.
      
      Note that drivers using the legacy gpio interface could still use
      GPIOF_ACTIVE_LOW to change the polarity before exporting the gpio.
      
      There are no in-kernel users of this interface.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Harry Wei <harryxiyou@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-kernel@zh-kernel.org
      Cc: linux-arch@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      166a85e4
  3. 19 Mar, 2015 1 commit
  4. 23 Sep, 2014 1 commit
    • Mika Westerberg's avatar
      gpio: Increase ARCH_NR_GPIOs to 512 · 7ca267fa
      Mika Westerberg authored
      Some newer Intel SoCs, like Braswell already have more than 256 GPIOs
      available so the default limit is exceeded. Instead of adding more
      architecture specific gpio.h files with custom ARCH_NR_GPIOs we increase
      the gpiolib default limit to be twice the current.
      
      Current generic ARCH_NR_GPIOS limit is 256 which starts to be too small
      for newer Intel SoCs like Braswell. In order to support GPIO controllers
      on these SoCs we increase ARCH_NR_GPIOS to be 512 which should be
      sufficient for now.
      
      The kernel size increases a bit with this change. Below is an example of
      x86_64 kernel image.
      
      ARCH_NR_GPIOS=256
       text     data    bss     dec      hex    filename
       11476173 1971328 1265664 14713165 e0814d vmlinux
      
      ARCH_NR_GPIOS=512
       text     data    bss     dec      hex    filename
       11476173 1971328 1269760 14717261 e0914d vmlinux
      
      So the BSS size and this the kernel image size increases by 4k.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      7ca267fa
  5. 24 Jul, 2014 1 commit
  6. 23 Jul, 2014 2 commits
    • Alexandre Courbot's avatar
      gpio: move gpio_ensure_requested() into legacy C file · d82da797
      Alexandre Courbot authored
      gpio_ensure_requested() only makes sense when using the integer-based
      GPIO API, so make sure it is called from there instead of the gpiod
      API which we know cannot be called with a non-requested GPIO anyway.
      
      The uses of gpio_ensure_requested() in the gpiod API were kind of
      out-of-place anyway, so putting them in gpio-legacy.c helps clearing the
      code.
      
      Actually, considering the time this ensure_requested mechanism has been
      around, maybe we should just turn this patch into "remove
      gpio_ensure_requested()" if we know for sure that no user depend on it
      anymore?
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d82da797
    • Alexandre Courbot's avatar
      gpio: remove gpiod_lock/unlock_as_irq() · d74be6df
      Alexandre Courbot authored
      gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
      are thus not using the old integer namespace. Therefore, there is no
      reason to have gpiod variants of these functions working with
      descriptors, especially since the (chip, offset) tuple is more suitable
      to the users of these functions (GPIO drivers, whereas GPIO descriptors
      are targeted at GPIO consumers).
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d74be6df
  7. 07 Feb, 2014 1 commit
  8. 19 Oct, 2013 1 commit
    • Alexandre Courbot's avatar
      gpiolib: export descriptor-based GPIO interface · 79a9becd
      Alexandre Courbot authored
      This patch exports the gpiod_* family of API functions, a safer
      alternative to the legacy GPIO interface. Differences between the gpiod
      and legacy gpio APIs are:
      
      - gpio works with integers, whereas gpiod operates on opaque handlers
        which cannot be forged or used before proper acquisition
      - gpiod get/set functions are aware of the active low state of a GPIO
      - gpio consumers should now include <linux/gpio/consumer.h> to access
        the new interface, whereas chips drivers will use
        <linux/gpio/driver.h>
      
      The legacy gpio API is now built as inline functions on top of gpiod.
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      79a9becd
  9. 16 Oct, 2013 2 commits
  10. 11 Feb, 2013 1 commit
  11. 09 Feb, 2013 1 commit
  12. 04 Feb, 2013 1 commit
  13. 22 Jan, 2013 2 commits
    • Shawn Guo's avatar
      gpio: devm_gpio_* support should not depend on GPIOLIB · 6a89a314
      Shawn Guo authored
      Some architectures (e.g. blackfin) provide gpio API without requiring
      GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB).  devm_gpio_* functions
      should also work for these architectures, since they do not really
      depend on GPIOLIB.
      
      Add a new option GPIO_DEVRES (enabled by default) to control the build
      of devres.c.  It also removes the empty version of devm_gpio_*
      functions for !GENERIC_GPIO build from linux/gpio.h, and moves the
      function declarations from asm-generic/gpio.h into linux/gpio.h.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      6a89a314
    • Shawn Guo's avatar
      gpio: fix warning of 'struct gpio_chip' declaration · d59b4eaa
      Shawn Guo authored
      The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
      but it's referenced by gpiochip_add_pin_range() and
      gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
      Thus, we see the following warning when building blackfin image, where
      GPIOLIB is not required.
      
        CC      arch/blackfin/kernel/bfin_gpio.o
        CC      init/version.o
      In file included from arch/blackfin/include/asm/gpio.h:321,
                       from arch/blackfin/kernel/bfin_gpio.c:15:
      include/asm-generic/gpio.h:298: warning: 'struct gpio_chip' declared inside parameter list
      include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
      include/asm-generic/gpio.h:304: warning: 'struct gpio_chip' declared inside parameter list
      
      Move pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
      since it appears that pinctrl gpio range support depends on GPIOLIB.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d59b4eaa
  14. 21 Nov, 2012 2 commits
  15. 11 Nov, 2012 4 commits
    • Linus Walleij's avatar
      gpiolib: iron out include ladder mistakes · 50309a9c
      Linus Walleij authored
      The <*/gpio.h> includes are updated again: now we need to account
      for the problem introduced by commit:
      595679a8038584df7b9398bf34f61db3c038bfea
      "gpiolib: fix up function prototypes etc"
      
      Actually we need static inlines in include/asm-generic/gpio.h
      as well since we may have GPIOLIB but not PINCTRL.
      Make sure to move all the CONFIG_PINCTRL business
      to the end of the file so we are sure we have
      declared struct gpio_chip.
      
      And we need to keep the static inlines in <linux/gpio.h>
      but here for the !CONFIG_GENERIC_GPIO case, and then we
      may as well throw in a few warnings like the other
      prototypes there, if someone would have the bad taste
      of compiling without GENERIC_GPIO even.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      50309a9c
    • Linus Walleij's avatar
      gpiolib: separation of pin concerns · 1e63d7b9
      Linus Walleij authored
      The fact that of_gpiochip_add_pin_range() and
      gpiochip_add_pin_range() share too much code is fragile and
      will invariably mean that bugs need to be fixed in two places
      instead of one.
      
      So separate the concerns of gpiolib.c and gpiolib-of.c and
      have the latter call the former as back-end. This is necessary
      also when going forward with other device descriptions such
      as ACPI.
      
      This is done by:
      
      - Adding a return code to gpiochip_add_pin_range() so we can
        reliably check whether this succeeds.
      
      - Get rid of the custom of_pinctrl_add_gpio_range() from
        pinctrl. Instead create of_pinctrl_get() to just retrive the
        pin controller per se from an OF node. This composite
        function was just begging to be deleted, it was way to
        purpose-specific.
      
      - Use pinctrl_dev_get_name() to get the name of the retrieved
        pin controller and use that to call back into the generic
        gpiochip_add_pin_range().
      
      Now the pin range is only allocated and tied to a pin
      controller from the core implementation in gpiolib.c.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      1e63d7b9
    • Linus Walleij's avatar
      gpiolib: fix up function prototypes etc · 165adc9c
      Linus Walleij authored
      Commit 69e1601bca88809dc118abd1becb02c15a02ec71
      "gpiolib: provide provision to register pin ranges"
      
      Got most of it's function prototypes wrong, so fix this up by:
      
      - Moving the void declarations into static inlines in
        <linux/gpio.h> (previously the actual prototypes were declared
        here...)
      
      - Declare the gpiochip_add_pin_range() and
        gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h>
        together with the pin range struct declaration itself.
      
      - Actually only implement these very functions in gpiolib.c
        if CONFIG_PINCTRL is set.
      
      - Additionally export the symbols since modules will need to
        be able to do this.
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      165adc9c
    • Shiraz Hashim's avatar
      gpiolib: provide provision to register pin ranges · f23f1516
      Shiraz Hashim authored
      pinctrl subsystem needs gpio chip base to prepare set of gpio
      pin ranges, which a given pinctrl driver can handle. This is
      important to handle pinctrl gpio request calls in order to
      program a given pin properly for gpio operation.
      
      As gpio base is allocated dynamically during gpiochip
      registration, presently there exists no clean way to pass this
      information to the pinctrl subsystem.
      
      After few discussions from [1], it was concluded that may be
      gpio controller reporting the pin range it supports, is a
      better way than pinctrl subsystem directly registering it.
      
      [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
      
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarShiraz Hashim <shiraz.hashim@st.com>
      [Edited documentation a bit]
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f23f1516
  16. 26 Oct, 2012 1 commit
  17. 30 Sep, 2012 1 commit
  18. 18 May, 2012 3 commits
  19. 02 Mar, 2012 1 commit
  20. 04 Jan, 2012 1 commit
  21. 12 Dec, 2011 2 commits
    • Grant Likely's avatar
      of: create of_phandle_args to simplify return of phandle parsing data · 15c9a0ac
      Grant Likely authored
      of_parse_phandle_with_args() needs to return quite a bit of data.  Rather
      than making each datum a separate **out_ argument, this patch creates
      struct of_phandle_args to contain all the returned data and reworks the
      user of the function.  This patch also enables of_parse_phandle_with_args()
      to return the device node pointer for the phandle node.
      
      This patch also ends up being fairly major surgery to
      of_parse_handle_with_args().  The existing structure didn't work well
      when extending to use of_phandle_args, and I discovered bugs during testing.
      I also took the opportunity to rename the function to be like the
      existing of_parse_phandle().
      
      v2: - moved declaration of of_phandle_args to fix compile on non-DT builds
          - fixed incorrect index in example usage
          - fixed incorrect return code handling for empty entries
      Reviewed-by: default avatarShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      15c9a0ac
    • Grant Likely's avatar
      gpio/powerpc: Eliminate duplication of of_get_named_gpio_flags() · 1a2d397a
      Grant Likely authored
      A large chunk of qe_pin_request() is unnecessarily cut-and-paste
      directly from of_get_named_gpio_flags().  This patch cuts out the
      duplicate code and replaces it with a call to of_get_gpio().
      
      v2: fixed compile error due to missing gpio_to_chip()
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      1a2d397a
  22. 26 Oct, 2011 1 commit
  23. 24 Oct, 2011 1 commit
  24. 16 Jun, 2011 1 commit
  25. 27 May, 2011 1 commit
  26. 26 May, 2011 1 commit
  27. 13 Jan, 2011 2 commits
  28. 27 Oct, 2010 1 commit
  29. 09 Sep, 2010 1 commit