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
03 Apr, 2009
1 commit
-
Allow GPIOs in GPIOLIB chips to be named. This name is then used when the
GPIO is exported to sysfs, although it could be used elsewhere if deemed
useful.Signed-off-by: Daniel Silverstone
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2008
3 commits
-
Add a new internal mechanism to gpiolib to support low power
operations by letting gpio_chip instances see when their GPIOs
are in use. When no GPIOs are active, chips may be able to
enter lower powered runtime states by disabling clocks and/or
power domains.Signed-off-by: David Brownell
Cc: "Magnus Damm"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add a new gpiolib mechanism: gpio_chip instances can provide mappings
between their (input) GPIOs and any associated IRQs. This makes it easier
for platforms to support IRQs that are provided by board-specific external
chips instead of as part of their core (such as SOC-integrated GPIOs).Also update the irq_to_gpio() description, saying to avoid it because it's
not always supported.Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Mark gpiochip label as a const char pointer. Fixes things like
arch/arm/common/scoop.c: In function `scoop_probe':
arch/arm/common/scoop.c:250: warning: assignment discards qualifiers from pointer target typeSigned-off-by: Dmitry Baryshkov
Acked-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Jul, 2008
1 commit
-
If CONFIG_GENERIC_GPIO=y && CONFIG_GPIO_SYSFS=n, gpio_export() in
asm-generic/gpio.h refers -ENOSYS and causes build error.Signed-off-by: Atsushi Nemoto
Acked-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Jul, 2008
1 commit
-
This fixes an off-by-one error in a comment.
Signed-off-by: Michael Buesch
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jul, 2008
2 commits
-
This patch adds functionality to the gpio-lib subsystem to make it
possible to enable the gpio-lib code even if the architecture code didn't
request to get it built in.The archtitecture code does still need to implement the gpiolib accessor
functions in its asm/gpio.h file. This patch adds the implementations for
x86 and PPC.With these changes it is possible to run generic GPIO expansion cards on
every architecture that implements the trivial wrapper functions. Support
for more architectures can easily be added.Signed-off-by: Michael Buesch
Cc: Benjamin Herrenschmidt
Cc: Stephen Rothwell
Cc: David Brownell
Cc: Russell King
Cc: Haavard Skinnemoen
Cc: Jesper Nilsson
Cc: Ralf Baechle
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Jean Delvare
Cc: Samuel Ortiz
Cc: Kumar Gala
Cc: Sam Ravnborg
Cc: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This adds a simple sysfs interface for GPIOs.
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write high, low
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)GPIOs claimed by kernel code may be exported by its owner using a new
gpio_export() call, which should be most useful for driver debugging.
Such exports may optionally be done without a "direction" attribute.Userspace may ask to take over a GPIO by writing to a sysfs control file,
helping to cope with incomplete board support or other "one-off"
requirements that don't merit full kernel support:echo 23 > /sys/class/gpio/export
... will gpio_request(23, "sysfs") and gpio_export(23);
use /sys/class/gpio/gpio-23/direction to (re)configure it,
when that GPIO can be used as both input and output.
echo 23 > /sys/class/gpio/unexport
... will gpio_free(23), when it was exported as aboveThe extra D-space footprint is a few hundred bytes, except for the sysfs
resources associated with each exported GPIO. The additional I-space
footprint is about two thirds of the current size of gpiolib (!). Since
no /dev node creation is involved, no "udev" support is needed.Related changes:
* This adds a device pointer to "struct gpio_chip". When GPIO
providers initialize that, sysfs gpio class devices become children of
that device instead of being "virtual" devices.* The (few) gpio_chip providers which have such a device node have
been updated.* Some gpio_chip drivers also needed to update their module "owner"
field ... for which missing kerneldoc was added.* Some gpio_chips don't support input GPIOs. Those GPIOs are now
flagged appropriately when the chip is registered.Based on previous patches, and discussion both on and off LKML.
A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
merges to mainline.[akpm@linux-foundation.org: a few maintenance build fixes]
Signed-off-by: David Brownell
Cc: Guennadi Liakhovetski
Cc: Greg KH
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 May, 2008
1 commit
-
This fixes various gpio-related build errors (mostly potential)
reported in part by Russell King and Uwe Kleine-König.Signed-off-by: David Brownell
Cc: Uwe Kleine-König
Cc: Russell King
Cc: Arnaud Patard
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 Apr, 2008
3 commits
-
Add a new function gpiochip_reserve() to reserve ranges of gpios that platform
code has pre-allocated. That is, this marks gpio numbers which will be
claimed by drivers that haven't yet been loaded, and thus are not available
for dynamic gpio number allocation.[akpm@linux-foundation.org: remove unneeded __must_check]
[david-b@pacbell.net: don't export gpiochip_reserve (section fix)]
Signed-off-by: Anton Vorontsov
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Introduce a gpio_is_valid() predicate; use it in gpiolib.
Signed-off-by: Guennadi Liakhovetski
[ use inline function; follow the gpio_* naming convention;
work without gpiolib; all programming interfaces need docs ]
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
As long as one or more GPIOs on a gpio chip are used its driver should not be
unloaded. The existing mechanism (gpiochip_remove failure) doesn't address
that, since rmmod can no longer be made to fail by having the cleanup code
report errors. Module usecounts are the solution.Assuming standard "initialize struct to zero" policies, this change won't
affect SOC platform drivers. However, drivers for external chips (on I2C and
SPI busses) should be updated if they can be built as modules.Signed-off-by: Guennadi Liakhovetski
[ gpio_ensure_requested() needs to update module usecounts too ]
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Feb, 2008
1 commit
-
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less than a dozen instructions, with the memory
cost being about a page (total) of extra data and code. The upside is:* Providing two features which were "want to have (but OK to defer)" when
GPIO interfaces were first discussed in November 2006:- A "struct gpio_chip" to plug in GPIOs that aren't directly supported
by SOC platforms, but come from FPGAs or other multifunction devices
using conventional device registers (like UCB-1x00 or SM501 GPIOs,
and southbridges in PCs with more open specs than usual).- Full support for message-based GPIO expanders, where registers are
accessed through sleeping I/O calls. Previous support for these
"cansleep" calls was just stubs. (One example: the widely used
pcf8574 I2C chips, with 8 GPIOs each.)* Including a non-stub implementation of the gpio_{request,free}() calls,
making those calls much more useful. The diagnostic labels are also
recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot
of all GPIOs known to this infrastructure.The driver programming interfaces introduced in 2.6.21 do not change at all;
this infrastructure is entirely below those covers.Signed-off-by: David Brownell
Cc: Sam Ravnborg
Cc: Jean Delvare
Cc: Eric Miao
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2007
1 commit
-
This defines a simple and minimalist programming interface for GPIO APIs:
- Documentation/gpio.txt ... describes things (read it)
- include/asm-arm/gpio.h ... defines the ARM hook, which just punts
to for any implementation- include/asm-generic/gpio.h ... implement "can sleep" variants as calling
the normal ones, for systems that don't handle i2c expanders.The immediate need for such a cross-architecture API convention is to support
drivers that work the same on AT91 ARM and AVR32 AP7000 chips, which embed many
of the same controllers but have different CPUs. However, several other users
have been reported, including a driver for a hardware watchdog chip and some
handhelds.org multi-CPU button drivers.Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds