linux-stable.git/include/asm-generic/gpio.h, branch v3.8 Linux kernel stable tree Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6 2012-12-11T21:00:56+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-12-11T21:00:56+00:00 b0885d01f9ab1274109c02942c881d598f939623 Pull GPIO updates from Grant Likely: "GPIO follow up patch and type change for v3.5 merge window Primarily device driver additions, features and bug fixes. Not much touching gpio common subsystem support. Should not be scary." * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits) gpio: Provide the STMPE GPIO driver with its own IRQ Domain gpio: add TS-5500 DIO blocks support gpio: pcf857x: use client->irq for gpio_to_irq() gpio: stmpe: Add DT support for stmpe gpio gpio: pl061 depends on ARM gpio/pl061: remove old comment gpio: SPEAr: add spi chipselect control driver gpio: gpio-max710x: Support device tree probing gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration gpio: tegra: read output value when gpio is set in direction_out gpio: pca953x: Add compatible strings to gpio-pca953x driver gpio: pca953x: Register an IRQ domain gpio: mvebu: Set free callback for gpio_chip gpio: tegra: Drop exporting static functions gpio: tegra: Staticize non-exported symbols gpio: tegra: fix suspend/resume apis gpio-pch: Set parent dev for gpio chip gpio: em: Fix build errors GPIO: clps711x: use platform_device_unregister in gpio_clps711x_init() gpio/tc3589x: convert to use the simple irqdomain ... 
Pull GPIO updates from Grant Likely:
 "GPIO follow up patch and type change for v3.5 merge window

  Primarily device driver additions, features and bug fixes.  Not much
  touching gpio common subsystem support.  Should not be scary."

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits)
  gpio: Provide the STMPE GPIO driver with its own IRQ Domain
  gpio: add TS-5500 DIO blocks support
  gpio: pcf857x: use client->irq for gpio_to_irq()
  gpio: stmpe: Add DT support for stmpe gpio
  gpio: pl061 depends on ARM
  gpio/pl061: remove old comment
  gpio: SPEAr: add spi chipselect control driver
  gpio: gpio-max710x: Support device tree probing
  gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
  gpio: tegra: read output value when gpio is set in direction_out
  gpio: pca953x: Add compatible strings to gpio-pca953x driver
  gpio: pca953x: Register an IRQ domain
  gpio: mvebu: Set free callback for gpio_chip
  gpio: tegra: Drop exporting static functions
  gpio: tegra: Staticize non-exported symbols
  gpio: tegra: fix suspend/resume apis
  gpio-pch: Set parent dev for gpio chip
  gpio: em: Fix build errors
  GPIO: clps711x: use platform_device_unregister in gpio_clps711x_init()
  gpio/tc3589x: convert to use the simple irqdomain
  ...
gpiolib: rename pin range arguments 2012-11-21T09:07:48+00:00 Linus Walleij linus.walleij@linaro.org 2012-11-21T07:48:09+00:00 316511c0134acec8f4ea730bd1897c7a1124a7c1 To be crystal clear on what the arguments mean in this funtion dealing with both GPIO and PIN ranges with confusing naming, we now have gpio_offset and pin_offset and we are on the clear that these are offsets into the specific GPIO and pin controller respectively. The GPIO chip itself will of course keep track of the base offset into the global GPIO number space. Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
To be crystal clear on what the arguments mean in this
funtion dealing with both GPIO and PIN ranges with confusing
naming, we now have gpio_offset and pin_offset and we are
on the clear that these are offsets into the specific GPIO
and pin controller respectively. The GPIO chip itself will
of course keep track of the base offset into the global
GPIO number space.

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib: let gpiochip_add_pin_range() specify offset 2012-11-21T07:55:03+00:00 Linus Walleij linus.walleij@linaro.org 2012-11-20T11:40:15+00:00 3f0f8670608766ef26a178d4e80cad3ce030fecc Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76 it is not always enough to specify all the pins of a gpio_chip from offset zero to be added to a pin map range, since the mapping from GPIO to pin controller may not be linear at all, but need to be broken into a few consecutive sub-ranges or 1-pin entries for complicated cases. The ranges may also be sparse. This alters the signature of the function to accept offsets into both the GPIO-chip local pinspace and the pin controller local pinspace. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76
it is not always enough to specify all the pins of a gpio_chip
from offset zero to be added to a pin map range, since the
mapping from GPIO to pin controller may not be linear at all,
but need to be broken into a few consecutive sub-ranges or
1-pin entries for complicated cases. The ranges may also be
sparse.

This alters the signature of the function to accept offsets
into both the GPIO-chip local pinspace and the pin controller
local pinspace.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib: iron out include ladder mistakes 2012-11-11T18:06:07+00:00 Linus Walleij linus.walleij@linaro.org 2012-11-06T16:16:39+00:00 50309a9c2e576ac4ad29e30f5854acb87bdc2ac4 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: Linus Walleij <linus.walleij@linaro.org> 
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: Linus Walleij <linus.walleij@linaro.org>
gpiolib: separation of pin concerns 2012-11-11T18:06:07+00:00 Linus Walleij linus.walleij@linaro.org 2012-11-06T15:03:35+00:00 1e63d7b9363f0c57d00991f9f2e0af374dfc591a 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: Linus Walleij <linus.walleij@linaro.org> 
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: Linus Walleij <linus.walleij@linaro.org>
gpiolib: fix up function prototypes etc 2012-11-11T18:06:04+00:00 Linus Walleij linus.walleij@linaro.org 2012-11-06T13:49:39+00:00 165adc9c1734a3f3bdbc6dc7c7a29bbefb424006 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: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib: provide provision to register pin ranges 2012-11-11T18:06:00+00:00 Shiraz Hashim shiraz.hashim@st.com 2012-10-27T09:51:36+00:00 f23f1516b6757c326cc638bed8c402c77e2a596e 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> [Edited documentation a bit] Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
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: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib: add gpio get direction callback support 2012-10-26T07:18:55+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2012-10-24T14:25:27+00:00 80b0a6029272247f19146bf8f88e5d4bba94cba5 Add .get_direction callback to gpio_chip. This allows gpiolib to check the current direction of a gpio. Used to show the correct gpio direction in sysfs and debug entries. If callback is not set then gpiolib will work as previously; e.g. guessing everything is input until a direction is set. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Add .get_direction callback to gpio_chip. This allows gpiolib
to check the current direction of a gpio.
Used to show the correct gpio direction in sysfs and debug entries.

If callback is not set then gpiolib will work as previously;
e.g. guessing everything is input until a direction is set.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: Document device_node's det_debounce 2012-09-30T08:27:01+00:00 Roland Stigge stigge@antcom.de 2012-09-25T07:56:14+00:00 1ae963143e34edaa14ab8855e0b0018c4fc77a83 This patch adds documentation for set_debounce in struct device_node. Signed-off-by: Roland Stigge <stigge@antcom.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
This patch adds documentation for set_debounce in struct device_node.

Signed-off-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib: Remove 'const' from data argument of gpiochip_find() 2012-05-19T05:01:05+00:00 Grant Likely grant.likely@secretlab.ca 2012-05-19T05:01:05+00:00 07ce8ec7308ab3fa55fe2861671b157f857fff58 Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO chips" changed the api of gpiochip_find to drop const from the data parameter of the match hook, but didn't also drop const from data causing a build warning. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 
Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO
chips" changed the api of gpiochip_find to drop const from the data
parameter of the match hook, but didn't also drop const from data
causing a build warning.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>