12 Feb, 2013
1 commit
-
Add a pointer to the gpio_chip structure that references the array of
GPIO descriptors belonging to the chip, and update gpiolib code to use
this pointer instead of the global gpio_desc[] array. This is another
step towards the removal of the gpio_desc[] global array.Signed-off-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Signed-off-by: Grant Likely
09 Feb, 2013
1 commit
-
Add a list member to gpio_chip that allows all chips to be parsed
quickly. The current method requires parsing the entire GPIO integer
space, which is painfully slow. Using a list makes many chip operations
that involve lookup or parsing faster, and also simplifies the code. It
is also necessary to eventually get rid of the global gpio_desc[] array.The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.Signed-off-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Signed-off-by: Grant Likely
05 Feb, 2013
1 commit
-
gpiochip_reserve() has no user and stands in the way of the removal of
the static gpio_desc[] array. Remove this function as well as the now
unneeded RESERVED flag of struct gpio_desc.Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij
22 Jan, 2013
2 commits
-
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: Shawn Guo
Signed-off-by: Linus Walleij -
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 listMove pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
since it appears that pinctrl gpio range support depends on GPIOLIB.Signed-off-by: Shawn Guo
Signed-off-by: Linus Walleij
12 Dec, 2012
1 commit
-
Pull GPIO updates from Grant Likely:
"GPIO follow up patch and type change for v3.5 merge windowPrimarily 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
...
21 Nov, 2012
2 commits
-
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
Signed-off-by: Linus Walleij -
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
Reviewed-by: Viresh Kumar
Signed-off-by: Linus Walleij
12 Nov, 2012
4 commits
-
The 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
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
-
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
-
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
(previously the actual prototypes were declared
here...)- Declare the gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() functions in
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
Signed-off-by: Linus Walleij -
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
Signed-off-by: Viresh Kumar
Signed-off-by: Shiraz Hashim
[Edited documentation a bit]
Signed-off-by: Linus Walleij
26 Oct, 2012
1 commit
-
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
Signed-off-by: Linus Walleij
30 Sep, 2012
1 commit
-
This patch adds documentation for set_debounce in struct device_node.
Signed-off-by: Roland Stigge
Signed-off-by: Linus Walleij
19 May, 2012
3 commits
-
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
-
This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node. This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device. With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.Tested-by: Roland Stigge
Acked-by: Arnd Bergmann
Signed-off-by: Grant Likely -
Allow drivers to use the modern request and configure idiom together
with devres.As with plain gpio_request() and gpio_request_one() we can't implement
the old school version in terms of _one() as this would force the
explicit selection of a direction in gpio_request() which could break
systems if we pick the wrong one. Implementing devm_gpio_request_one()
in terms of devm_gpio_request() would needlessly complicate things or
lead to duplication from the unmanaged version depending on how it's
done.Signed-off-by: Mark Brown
Acked-by: Linus Walleij
Signed-off-by: Grant Likely
03 Mar, 2012
1 commit
-
Signed-off-by: Grant Likely
05 Jan, 2012
1 commit
-
This patch adds 2 functions that allow managed devices to request GPIOs.
These GPIOs will then be managed by drivers/base/devres.c.Signed-off-by: John Crispin
Signed-off-by: Grant Likely
13 Dec, 2011
2 commits
-
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 entriesReviewed-by: Shawn Guo
Signed-off-by: Grant Likely -
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: Grant Likely
Cc: Benjamin Herrenschmidt
Cc: Kumar Gala
27 Oct, 2011
1 commit
-
Should call the platform-specific __gpio_{get,set}_value
instead of generic gpio_{get,set}_valueSigned-off-by: Yang Bai
Acked-by: Arnd Bergmann
Signed-off-by: Grant Likely
24 Oct, 2011
1 commit
-
Currently struct gpio is only defined when using gpiolib which makes the
stub gpio_request_array() much less useful in drivers than is ideal as
they can't work with struct gpio. Since there are no other definitions
in kernel instead make the define always available no matter if gpiolib
is selectable or selected, ensuring that drivers can always use the
type.Signed-off-by: Mark Brown
Signed-off-by: Grant Likely
16 Jun, 2011
1 commit
-
Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
is enabled by moving them to .Fixes these build errors in linux-next:
sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)Signed-off-by: Randy Dunlap
Signed-off-by: Grant Likely
28 May, 2011
1 commit
-
gpio_{request,free}_array should not (and do not) modify the passed gpio
array, so make the parameter const.Signed-off-by: Lars-Peter Clausen
Acked-by: Eric Miao
Acked-by: Wolfram Sang
Signed-off-by: Andrew Morton
Signed-off-by: Grant Likely
27 May, 2011
1 commit
-
Make the code a bit more readable.
Instead of casting an int to an unsigned then comparing to
MAX_NR_GPIOS, add a >= 0 test and let the compiler optimizer
do the conversion to unsigned.The generated code should be the same.
Signed-off-by: Joe Perches
Acked-by: Linus Walleij
Signed-off-by: Grant Likely
14 Jan, 2011
2 commits
-
This reverts commit 0fdae42d361bbb431ca0ab0efed5126a94821177, which
wasn't really supposed to go in, and causes lots of annoying warnings.Quoth Andrew:
"Complete brainfart - I meant to drop that patch ages ago."Quoth Greg:
"Ick, yeah, that patch isn't ok to go in as-is, all of the callers
need to be fixed up first, which is what I thought we had agreed on..."Reported-by: Stephen Rothwell
Acked-by: Andrew Morton
Acked-by: Greg KH
Signed-off-by: Linus Torvalds -
Because GPIOs can have crucial functions especially in embedded systems,
we are better safe than sorry regarding their configuration. For
gpio_request, the documentation is simply enforced: "The return
value of gpio_request() must be checked." For gpio_direction_* and
gpio_request_*, we now act accordingly.Signed-off-by: Wolfram Sang
Cc: David Brownell
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 Oct, 2010
1 commit
-
commit 7444a72effa632fcd8edc566f88 ("gpiolib: allow user-selection")
removed HAVE_GPIO_LIB Kconfig symbol, but the header file still uses the
name [to confuse readers wrt #ifdef/#else/#endif location].The real Kconfig symbol nowadays is CONFIG_GPIOLIB.
Signed-off-by: Anton Vorontsov
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Sep, 2010
1 commit
-
There's been some recent confusion about error checking GPIO numbers.
briefly, it should be handled mostly during setup, when gpio_request() is
called, and NEVER by expectig gpio_is_valid to report more than
never-usable GPIO numbers.[akpm@linux-foundation.org: terminate unterminated comment]
Signed-off-by: David Brownell
Cc: Eric Miao"
Cc: "Ryan Mallon"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Jul, 2010
2 commits
-
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 -
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
28 May, 2010
3 commits
-
A few architectures, like OMAP, allow you to set a debouncing time for the
gpio before generating the IRQ. Teach gpiolib about that.Mark said:
: This would be generally useful for embedded systems, especially where
: the interrupt concerned is a wake source. It allows drivers to avoid
: spurious interrupts from noisy sources so if the hardware supports it
: the driver can avoid having to explicitly wait for the signal to become
: stable and software has to cope with fewer events. We've lived without
: it for quite some time, though.David said:
: I looked at adding debounce support to the generic GPIO calls (and thus
: gpiolib) some time back, but decided against it. I forget why at this
: time (check list archives) but it wasn't because of lack of utility in
: certain contexts.
:
: One thing to watch out for is just how variable the hardware capabilities
: are. Atmel GPIOs have something like a fixed number of 32K clock cycles
: for debounce, twl4030 had something odd, OMAPs were more like the Atmel
: chips but with a different clock. In some cases debouncing had to be
: ganged, not per-GPIO. And so forth.Signed-off-by: Felipe Balbi
Cc: Tony Lindgren
Cc: David Brownell
Reviewed-by: Mark Brown
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Uwe Kleine-König
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
gpiolib doesn't need to modify the names and I assume most initializers
use string constants that shouldn't be modified anyhow.[akpm@linux-foundation.org: fix drivers/gpio/cs5535-gpio.c]
Signed-off-by: Uwe Kleine-König
Cc: Kevin Wells
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Mar, 2010
1 commit
-
gpio_request() without initial configuration of the GPIO is normally
useless, introduce gpio_request_one() together with GPIOF_ flags for
input/output direction and initial output level.gpio_{request,free}_array() for multiple GPIOs.
Signed-off-by: Eric Miao
Cc: David Brownell
Cc: Ben Nizette
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Dec, 2009
1 commit
-
Drivers may use gpiolib sysfs as part of their public user space
interface. The GPIO number and polarity might change from board to
board. The gpio_export_link() call can be used to hide the GPIO number
from user space. Add support for also hiding the GPIO line polarity
changes from user space.Signed-off-by: Jani Nikula
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Dec, 2009
1 commit
-
After the recent commit a4177ee7f, attempting to include asm-generic/gpio.h
in otherwise "slim" code results in ugly warnings like so:CC arch/blackfin/kernel/bfin_gpio.o
In file included from arch/blackfin/include/asm/gpio.h:278,
from arch/blackfin/kernel/bfin_gpio.c:15:
include/asm-generic/gpio.h:193: warning:
‘struct device’ declared inside parameter list
its scope is only this definition or declaration, which is probably not what you wantSo add simple C forward decls of the struct device to avoid these.
Signed-off-by: Mike Frysinger
Signed-off-by: Arnd Bergmann
02 Oct, 2009
1 commit
-
The asm-generic/gpio.h header uses the might_sleep() macro but doesn't
include the header for it, so any source code that might include
linux/gpio.h before linux/kernel.h can easily lead to a build failure.Signed-off-by: Mike Frysinger
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Sep, 2009
1 commit
-
Commit 926b663ce8215ba448960e1ff6e58b67a2c3b99b (gpiolib: allow GPIOs to
be named) already provides naming on the chip level. This patch provides
more flexibility by allowing multiple names where ever in sysfs on a per
GPIO basis.Adapted from David Brownell's comments on a similar concept:
http://lkml.org/lkml/2009/4/20/203.[randy.dunlap@oracle.com: fix build for CONFIG_GENERIC_GPIO=n]
Signed-off-by: Jani Nikula
Acked-by: David Brownell
Cc: Daniel Silverstone
Signed-off-by: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds