1. 14 Jan, 2015 3 commits
  2. 02 Dec, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: fix deferred probe detection for legacy API · 0e9a5edf
      Alexandre Courbot authored
      Commit 14e85c0e ("gpio: remove gpio_descs global array") changed
      gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers
      not in the valid range, but also for all GPIOs whose controller has not
      been probed yet. Although this behavior is more correct (nothing hints
      that these GPIO numbers will be populated later), this affects
      gpio_request() and gpio_request_one() which call gpiod_request() with a
      NULL descriptor, causing it to return -EINVAL instead of the expected
      -EPROBE_DEFER for a non-probed GPIO.
      
      gpiod_request() is only called with a descriptor obtained from
      gpio_to_desc() from these two functions, so address the issue there.
      
      Other ways to obtain GPIOs rely on well-defined mappings and can thus
      return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected
      by this issue.
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      0e9a5edf
  3. 28 Nov, 2014 2 commits
  4. 27 Nov, 2014 2 commits
    • Geert Uytterhoeven's avatar
      gpio: Check if base is positive before calling gpio_is_valid() · 86256d1f
      Geert Uytterhoeven authored
      It doesn't make much sense to make some (possible expensive) calls to
      gpio_is_valid() first, and to ignore the result if the base number is
      negative. Check for a positive base number first.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      86256d1f
    • Rojhalat Ibrahim's avatar
      gpiolib: allow simultaneous setting of multiple GPIO outputs · 5f424243
      Rojhalat Ibrahim authored
      Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer
      interface which allow setting multiple outputs with just one function call.
      Also add an optional set_multiple function to the driver interface. Without an
      implementation of that function in the chip driver outputs are set
      sequentially.
      
      Implementing the set_multiple function in a chip driver allows for:
      - Improved performance for certain use cases. The original motivation for this
        was the task of configuring an FPGA. In that specific case, where 9 GPIO
        lines have to be set many times, configuration time goes down from 48 s to
        20 s when using the new function.
      - Simultaneous glitch-free setting of multiple pins on any kind of parallel
        bus attached to GPIOs provided they all reside on the same chip and bank.
      
      Limitations:
        Performance is only improved for normal high-low outputs. Open drain and
        open source outputs are always set separately from each other. Those kinds
        of outputs could probably be accelerated in a similar way if we could
        forgo the error checking when setting GPIO directions.
      
      Change log:
        v6: - rebase on current linux-gpio devel branch
        v5: - check can_sleep property per chip
            - remove superfluous checks
            - supplement documentation
        v4: - add gpiod_set_array function for setting logical values
            - change interface of the set_multiple driver function to use
              unsigned long as type for the bit fields
            - use generic bitops (which also use unsigned long for bit fields)
            - do not use ARCH_NR_GPIOS any more
        v3: - add documentation
            - change commit message
        v2: - use descriptor interface
            - allow arbitrary groups of GPIOs spanning multiple chips
      Signed-off-by: default avatarRojhalat Ibrahim <imr@rtschenk.de>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Reviewed-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      5f424243
  5. 04 Nov, 2014 2 commits
    • Mika Westerberg's avatar
      gpio: Support for unified device properties interface · 40b73183
      Mika Westerberg authored
      Some drivers need to deal with only firmware representation of its
      GPIOs. An example would be a GPIO button array driver where each button
      is described as a separate firmware node in device tree. Typically these
      child nodes do not have physical representation in the Linux device
      model.
      
      In order to help device drivers to handle such firmware child nodes we
      add dev[m]_get_named_gpiod_from_child() that takes a child firmware
      node pointer as its second argument (the first one is the parent device
      itself), finds the GPIO using whatever is the underlying firmware
      method, and requests the GPIO properly.
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Acked-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      40b73183
    • Mika Westerberg's avatar
      gpio / ACPI: Add support for _DSD device properties · 0d9a693c
      Mika Westerberg authored
      With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
      other things as well) returned by _CRS. Previously we were only able to
      use integer index to find the corresponding GPIO, which is pretty error
      prone if the order changes.
      
      With _DSD we can now query GPIOs using name instead of an integer index,
      like the below example shows:
      
        // Bluetooth device with reset and shutdown GPIOs
        Device (BTH)
        {
            Name (_HID, ...)
      
            Name (_CRS, ResourceTemplate ()
            {
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {15}
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
            })
      
            Name (_DSD, Package ()
            {
                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                Package ()
      	  {
                    Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
                    Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
                }
            })
        }
      
      The format of the supported GPIO property is:
      
        Package () { "name", Package () { ref, index, pin, active_low }}
      
        ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
              typically this is the device itself (BTH in our case).
        index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
        pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
        active_low - If 1 the GPIO is marked as active_low.
      
      Since ACPI GpioIo() resource does not have field saying whether it is
      active low or high, the "active_low" argument can be used here. Setting
      it to 1 marks the GPIO as active low.
      
      In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
      resource, second pin in that resource with the GPIO number of 31.
      
      This patch implements necessary support to gpiolib for extracting GPIOs
      using _DSD device properties.
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0d9a693c
  6. 28 Oct, 2014 1 commit
  7. 26 Sep, 2014 3 commits
  8. 24 Sep, 2014 3 commits
  9. 23 Sep, 2014 2 commits
  10. 29 Aug, 2014 1 commit
  11. 28 Jul, 2014 3 commits
    • Alexandre Courbot's avatar
      gpio: add flags argument to gpiod_get*() functions · 39b2bbe3
      Alexandre Courbot authored
      The huge majority of GPIOs have their direction and initial value set
      right after being obtained by one of the gpiod_get() functions. The
      integer GPIO API had gpio_request_one() that took a convenience flags
      parameter allowing to specify an direction and value applied to the
      returned GPIO. This feature greatly simplifies client code and ensures
      errors are always handled properly.
      
      A similar feature has been requested for the gpiod API. Since setting
      the direction of a GPIO is so often the very next action done after
      obtaining its descriptor, we prefer to extend the existing functions
      instead of introducing new functions that would raise the
      number of gpiod getters to 16 (!).
      
      The drawback of this approach is that all gpiod clients need to be
      updated. To limit the pain, temporary macros are introduced that allow
      gpiod_get*() to be called with or without the extra flags argument. They
      will be removed once all consumer code has been updated.
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Reviewed-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      39b2bbe3
    • Mika Westerberg's avatar
      gpio / ACPI: Move event handling registration to gpiolib irqchip helpers · afa82fab
      Mika Westerberg authored
      Since now we have irqchip helpers that the GPIO chip drivers are supposed
      to use if possible, we can move the registration of ACPI events to happen
      in these helpers. This seems to be more natural place and might encourage
      GPIO chip driver writers to take advantage of the irqchip helpers.
      
      We make the functions available to GPIO chip drivers via private gpiolib.h,
      just in case generic irqchip helpers are not suitable.
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      afa82fab
    • Linus Walleij's avatar
      gpio: split gpiod board registration into machine header · 0a6d3158
      Linus Walleij authored
      As per example from the regulator subsystem: put all defines and
      functions related to registering board info for GPIO descriptors
      into a separate <linux/gpio/machine.h> header.
      
      Cc: Andrew Victor <linux@maxim.org.za>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default avatarAlexandre Courbot <gnurou@gmail.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      0a6d3158
  12. 24 Jul, 2014 1 commit
  13. 23 Jul, 2014 3 commits
  14. 09 Jul, 2014 3 commits
  15. 12 Jun, 2014 1 commit
  16. 09 May, 2014 1 commit
    • Thierry Reding's avatar
      gpio: Add helpers for optional GPIOs · 29a1f233
      Thierry Reding authored
      Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers
      that make it easier for drivers to handle optional GPIOs.
      
      Currently in order to handle optional GPIOs, a driver needs to special
      case error handling for -ENOENT, such as this:
      
      	gpio = gpiod_get(dev, "foo");
      	if (IS_ERR(gpio)) {
      		if (PTR_ERR(gpio) != -ENOENT)
      			return PTR_ERR(gpio);
      
      		gpio = NULL;
      	}
      
      	if (gpio) {
      		/* set up GPIO */
      	}
      
      With these new helpers the above is reduced to:
      
      	gpio = gpiod_get_optional(dev, "foo");
      	if (IS_ERR(gpio))
      		return PTR_ERR(gpio);
      
      	if (gpio) {
      		/* set up GPIO */
      	}
      
      While at it, device-managed variants of these functions are also
      provided.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      29a1f233
  17. 02 May, 2014 1 commit
  18. 28 Apr, 2014 5 commits
  19. 14 Apr, 2014 1 commit
  20. 28 Mar, 2014 1 commit