1. 07 Sep, 2016 1 commit
  2. 23 Jun, 2016 5 commits
  3. 08 Jun, 2016 1 commit
    • Linus Walleij's avatar
      gpio: include <linux/io-mapping.h> in gpiolib-of · 7d4defe2
      Linus Walleij authored
      When enabling the gpiolib for all archs a build robot came
      up with this:
      
      All errors (new ones prefixed by >>):
      
         drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data':
      >> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of
         function 'iounmap' [-Werror=implicit-function-declaration]
           iounmap(mm_gc->regs);
           ^~~~~~~
         cc1: some warnings being treated as errors
      
      Fix this by including <linux/io-mapping.h> explicitly.
      
      Fixes: 296ad4ac ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      7d4defe2
  4. 07 Jun, 2016 1 commit
  5. 10 May, 2016 1 commit
    • Linus Walleij's avatar
      gpio: of: make it possible to name GPIO lines · fd9c5531
      Linus Walleij authored
      Make it possible to name the producer side of a GPIO line using
      a "gpio-line-names" property array, modeled on the
      "clock-output-names" property from the clock bindings.
      
      This naming is especially useful for:
      
      - Debugging: lines are named after function, not just opaque
        offset numbers.
      
      - Exploration: systems where some or all GPIO lines are available
        to end users, such as prototyping, one-off's "makerspace usecases"
        users are helped by the names of the GPIO lines when tinkering.
        This usecase has been surfacing recently.
      
      The gpio-line-names attribute is completely optional.
      
      Example output from lsgpio on a patched Snowball tree:
      
      GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines
              line  0: unnamed unused
              line  1: "AP_GPIO161" "extkb3" [kernel]
              line  2: "AP_GPIO162" "extkb4" [kernel]
              line  3: "ACCELEROMETER_INT1_RDY" unused [kernel]
              line  4: "ACCELEROMETER_INT2" unused
              line  5: "MAG_DRDY" unused [kernel]
              line  6: "GYRO_DRDY" unused [kernel]
              line  7: "RSTn_MLC" unused
              line  8: "RSTn_SLC" unused
              line  9: "GYRO_INT" unused
              line 10: "UART_WAKE" unused
              line 11: "GBF_RESET" unused
              line 12: unnamed unused
      
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Amit Kucheria <amit.kucheria@linaro.org>
      Cc: David Mandala <david.mandala@linaro.org>
      Cc: Lee Campbell <leecam@google.com>
      Cc: devicetree@vger.kernel.org
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fd9c5531
  6. 14 Apr, 2016 1 commit
  7. 13 Apr, 2016 1 commit
  8. 05 Jan, 2016 1 commit
  9. 19 Nov, 2015 1 commit
    • Linus Walleij's avatar
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij authored
      The name .dev in a struct is normally reserved for a struct device
      that is let us say a superclass to the thing described by the struct.
      struct gpio_chip stands out by confusingly using a struct device *dev
      to point to the parent device (such as a platform_device) that
      represents the hardware. As we want to give gpio_chip:s real devices,
      this is not working. We need to rename this member to parent.
      
      This was done by two coccinelle scripts, I guess it is possible to
      combine them into one, but I don't know such stuff. They look like
      this:
      
      @@
      struct gpio_chip *var;
      @@
      -var->dev
      +var->parent
      
      and:
      
      @@
      struct gpio_chip var;
      @@
      -var.dev
      +var.parent
      
      and:
      
      @@
      struct bgpio_chip *var;
      @@
      -var->gc.dev
      +var->gc.parent
      
      Plus a few instances of bgpio that I couldn't figure out how
      to teach Coccinelle to rewrite.
      
      This patch hits all over the place, but I *strongly* prefer this
      solution to any piecemal approaches that just exercise patch
      mechanics all over the place. It mainly hits drivers/gpio and
      drivers/pinctrl which is my own backyard anyway.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Alek Du <alek.du@intel.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      58383c78
  10. 24 Sep, 2015 1 commit
  11. 28 Jul, 2015 1 commit
  12. 16 Jul, 2015 1 commit
  13. 15 Jul, 2015 1 commit
  14. 19 May, 2015 1 commit
  15. 04 Mar, 2015 1 commit
    • Benoit Parrot's avatar
      gpio: add GPIO hogging mechanism · f625d460
      Benoit Parrot authored
      Based on Boris Brezillion's work this is a reworked patch
      of his initial GPIO hogging mechanism.
      This patch provides a way to initially configure specific GPIO
      when the GPIO controller is probed.
      
      The actual DT scanning to collect the GPIO specific data is performed
      as part of gpiochip_add().
      
      The purpose of this is to allow specific GPIOs to be configured
      without any driver specific code.
      This is particularly useful because board design are getting
      increasingly complex and given SoC pins can now have more
      than 10 mux values, a lot of connections are now dependent on
      external IO muxes to switch various modes.
      
      Specific drivers should not necessarily need to be aware of
      what accounts to a specific board implementation. This board level
      "description" should be best kept as part of the dts file.
      Signed-off-by: default avatarBenoit Parrot <bparrot@ti.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f625d460
  16. 23 Feb, 2015 1 commit
  17. 15 Jan, 2015 2 commits
  18. 17 Aug, 2014 1 commit
  19. 23 Jul, 2014 2 commits
  20. 09 Jul, 2014 1 commit
  21. 21 May, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: make of_get_named_gpiod_flags() private · f01d9075
      Alexandre Courbot authored
      of_get_named_gpiod_flags() is visible and directly usable by GPIO
      consumers, but it really should not as the gpiod interface relies
      on the simpler gpiod_get() to provide properly-configured GPIOs.
      
      of_get_named_gpiod_flags() is just used internally by gpiolib to
      implement gpiod_get(), and by the old of_get_named_gpio_flags()
      function, therefore it makes sense to make it gpiolib-private.
      
      As a side-effect, the unused (and unneeded) of_get_gpiod_flags()
      inline function is also removed, and of_get_named_gpio_flags() is moved
      from a static inline function to a regular one in gpiolib-of.c
      
      This results in all references to gpiod_* functions in of_gpio.h being
      gone, which is the way it should be since this file is part of the old
      integer GPIO interface.
      
      Changes since v1:
      - Fixed compilation error when CONFIG_OF_GPIO is not defined
      - Fixed warning due to of_gpio_flags enum not being declared
        in private gpiolib.h header
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f01d9075
  22. 28 Apr, 2014 1 commit
  23. 06 Feb, 2014 1 commit
  24. 19 Oct, 2013 1 commit
  25. 16 Oct, 2013 1 commit
  26. 29 Aug, 2013 1 commit
  27. 16 Aug, 2013 1 commit
  28. 27 Mar, 2013 1 commit
  29. 06 Mar, 2013 2 commits
  30. 13 Feb, 2013 1 commit
  31. 21 Jan, 2013 1 commit
  32. 21 Nov, 2012 1 commit
  33. 11 Nov, 2012 1 commit
    • 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