Some newer Intel SoCs, like Braswell already have more than 256 GPIOs
available so the default limit is exceeded. Instead of adding more
architecture specific gpio.h files with custom ARCH_NR_GPIOs we increase
the gpiolib default limit to be twice the current.
Current generic ARCH_NR_GPIOS limit is 256 which starts to be too small
for newer Intel SoCs like Braswell. In order to support GPIO controllers
on these SoCs we increase ARCH_NR_GPIOS to be 512 which should be
sufficient for now.
The kernel size increases a bit with this change. Below is an example of
x86_64 kernel image.
ARCH_NR_GPIOS=256
text data bss dec hex filename
11476173 1971328 1265664 14713165 e0814d vmlinux
ARCH_NR_GPIOS=512
text data bss dec hex filename
11476173 1971328 1269760 14717261 e0914d vmlinux
So the BSS size and this the kernel image size increases by 4k.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_ensure_requested() has been introduced in Feb. 2008 by commit
d2876d08d8 to force users of the GPIO API to explicitly request GPIOs
before using them.
Hopefully by now all GPIOs are correctly requested and this extra check
can be omitted ; in any case the GPIO maintainers won't feel bad if
machines start failing after 6 years of warnings.
This patch removes that function from the dark ages.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_ensure_requested() only makes sense when using the integer-based
GPIO API, so make sure it is called from there instead of the gpiod
API which we know cannot be called with a non-requested GPIO anyway.
The uses of gpio_ensure_requested() in the gpiod API were kind of
out-of-place anyway, so putting them in gpio-legacy.c helps clearing the
code.
Actually, considering the time this ensure_requested mechanism has been
around, maybe we should just turn this patch into "remove
gpio_ensure_requested()" if we know for sure that no user depend on it
anymore?
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
are thus not using the old integer namespace. Therefore, there is no
reason to have gpiod variants of these functions working with
descriptors, especially since the (chip, offset) tuple is more suitable
to the users of these functions (GPIO drivers, whereas GPIO descriptors
are targeted at GPIO consumers).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The documentation was not clear about whether
gpio_direction_output should take a logical value or the physical
level on the output line, i.e. whether the ACTIVE_LOW status
would be taken into account.
This converts gpiod_direction_output to use the logical level
and adds a new gpiod_direction_output_raw for the raw value.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull GPIO changes from Linus Walleij:
"Here is the bulk of GPIO changes for the v3.13 development cycle.
I've got ACKs for the things that affect other subsystems (or it's my
own subsystem, like pinctrl). Most of that pertain to an attempt from
my side to consolidate and get rid of custom GPIO implementations in
the ARM tree. I will continue doing this.
The main change this time is the new GPIO descriptor API, background
for this can be found in Corbet's summary from this january in LWN:
http://lwn.net/Articles/533632/
Summary:
- Merged the GPIO descriptor API from Alexandre Courbot. This is a
first step toward trying to get rid of the global GPIO numberspace
for the future.
- Add an API so that driver can flag that a certain GPIO line is
being used by a irqchip backend for generating IRQs, so that we can
enforce checks, like not allowing users to switch that line to an
output at runtime, since this makes no sense. Implemented
corresponding calls in a few select drivers.
- ACPI GPIO cleanups, refactorings and switch to using the
descriptor-based interface.
- Support for the TPS80036 Palmas GPIO variant.
- A new driver for the Broadcom Kona GPIO SoC IP block.
- Device tree support for the PCF857x driver.
- A set of ARM GPIO refactorings with the goal of getting rid of a
bunch of custom GPIO implementations from the arch/arm/* tree:
* Move the IOP GPIO driver to the GPIO subsystem and fix all users
to use the gpiolib API for accessing GPIOs. Delete the old
custom GPIO implementation.
* Delete the unused custom PXA GPIO implemention.
* Convert all users of the IXP4 custom GPIO implementation to use
gpiolib and delete the custom implementation.
* Delete the custom Gemini GPIO implementation, also completely
unused.
- Various cleanups and renamings"
* tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits)
gpio: gpio-mxs: Remove unneeded dt checks
gpio: pl061: don't depend on CONFIG_ARM
gpio: bcm-kona: add missing .owner to struct gpio_chip
gpiolib: provide a declaration of seq_file in gpio/driver.h
gpiolib: include gpio/consumer.h in of_gpio.h for desc_to_gpio()
gpio: provide stubs for devres gpio functions
gpiolib: devres: add missing headers
gpiolib: make GPIO_DEVRES depend on GPIOLIB
gpiolib: devres: fix devm_gpiod_get_index()
gpiolib / ACPI: document the GPIO descriptor based interface
gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources
gpiolib / ACPI: add ACPI support for gpiod_get_index()
gpiolib / ACPI: convert to gpiod interfaces
gpiolib: add gpiod_get() and gpiod_put() functions
gpiolib: port of_ functions to use gpiod
gpiolib: export descriptor-based GPIO interface
Fixup "MAINTAINERS: GPIO-INTEL-MID: add maintainer"
gpio: bcm281xx: Don't print addresses of GPIO area in probe()
gpio: tegra: use new gpio_lock_as_irq() API
gpio: rcar: Include linux/of.h header
...
This patch exports the gpiod_* family of API functions, a safer
alternative to the legacy GPIO interface. Differences between the gpiod
and legacy gpio APIs are:
- gpio works with integers, whereas gpiod operates on opaque handlers
which cannot be forged or used before proper acquisition
- gpiod get/set functions are aware of the active low state of a GPIO
- gpio consumers should now include <linux/gpio/consumer.h> to access
the new interface, whereas chips drivers will use
<linux/gpio/driver.h>
The legacy gpio API is now built as inline functions on top of gpiod.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It is currently often possible in many GPIO drivers to request
a GPIO line to be used as IRQ after calling gpio_to_irq() and,
as the gpiolib is not aware of this, set the same line to
output and start driving it, with undesired side effects.
As it is a bogus usage scenario to request a line flagged as
output to used as IRQ, we introduce APIs to let gpiolib track
the use of a line as IRQ, and also set this flag from the
userspace ABI.
The API is symmetric so that lines can also be flagged from
.irq_enable() and unflagged from IRQ by .irq_disable().
The debugfs file is altered so that we see if a line is
reserved for IRQ.
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.orh>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
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 <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 list
Move 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 <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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
...
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>
Like with commit 3c739ad0df
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>
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 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>
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>
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>
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>
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>
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>
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 <stigge@antcom.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
