| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For a long time the gpio-omap custom PM calls have been annoying me so
let's replace them with cpu_pm instead. This will enable GPIO PM for
deeper idle states on omap4. And we can handle GPIO PM for omap2/3/4
in the same way.
Note that with this patch we are also slightly changing GPIO PM to be
less aggressive for omap3 and only will idle GPIO when PER context
may be lost.
For omap2, we don't need to save context and don't want to remove any
triggering so let's add a quirk flag for that.
Let's do this all in a single patch to avoid a situation where old
custom calls still are used with new code.
Cc: Aaro Koskinen <[email protected]>
Cc: Keerthy <[email protected]>
Cc: Ladislav Michl <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Acked-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
I noticed that unlike omap2 and 3 based SoCs, omap4 based SoCs keep
the GPIO clocks enabled for GPIO level interrupts with wakeup enabled.
This blocks deeper idle states as the whole domain will stay busy.
The GPIO functional clock seems to stay enabled if the wakeup register
is enabled and a level interrupt is triggered. In that case the only
way to have the GPIO module idle is to reset it. It is possible this
has gone unnoticed with OSWR (Open SWitch Retention) and off mode
during idle resetting GPIO context most GPIO instances in the earlier
Android trees for example.
Looks like the way to deal with this is to have omap4 based SoCs
only set wake for the duration of idle for level interrupts, and clear
level registers for the idle. With level interrupts we can do this as
the level interrupt from device will be still there on resume.
I've taken the long path to fixing this to avoid yet more hard to
read code. I've set up a quirks flag, and a struct for function
pointers so we can use these to clean up other quirk handling easier
in the later patches. The current level quirk handling is moved to
the new functions.
Cc: Aaro Koskinen <[email protected]>
Cc: Ladislav Michl <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Acked-by: Grygorii Strashko <[email protected]>
Tested-by: Keerthy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
matching GPIO hardware") forcibly tries to find an array member which
has its array index number equal to its hardware pin number and set
up an array info for possible fast bitmap processing of all arrray
pins belonging to that chip which also satisfy that numbering rule.
Depending on array content, it may happen that consecutive array
members which belong to the same chip but don't have array indexes
equal to their pin hardware numbers will be split into groups, some of
them processed together via the fast bitmap path, and rest of them
separetely. However, applications may expect all those pins being
processed together with a single call to .set_multiple() chip callback,
like that was done before the change.
Limit applicability of fast bitmap processing path to cases where all
pins of consecutive array members starting from 0 which belong to the
same chip have their hardware numbers equal to their corresponding
array indexes. That should still speed up processing of applications
using whole GPIO banks as I/O ports, while not breaking simultaneous
manipulation of consecutive pins of the same chip which don't follow
the equal numbering rule.
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Janusz Krzysztofik <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
processing path in get/set array"), bitmap index is not updated with
next found zero bit position as it should while skipping over pins
already processed via fast bitmap path, possibly resulting in an
infinite loop. Fix it.
Signed-off-by: Janusz Krzysztofik <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Give the HTC EGPIO chips unique names, htc-egpio-0,
htc-egpio-1 etc, so that it gets possible to associate
machine descriptor tables with individual chips.
Signed-off-by: Linus Walleij <[email protected]>
|
|
|
|
These defines, structs and inline functions are used only internally by
the driver, they do not belong in platform_data. Move them.
Signed-off-by: Andrew F. Davis <[email protected]>
Tested-by: Keerthy <[email protected]>
Acked-by: Keerthy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Previously we created a controller structure per bank of GPIO pins. This
has since been changed to one per controller, but the allocation size
was not changed. Fix this here.
This also leaves the variable 'nbank' unused, instead of removing it,
move it down and use it to clean up a loop. For loops with multiple
initializers and/or iteration expressions, especially ones that don't
use those loop counters are quite hard to follow, fix this.
Signed-off-by: Andrew F. Davis <[email protected]>
Tested-by: Keerthy <[email protected]>
Acked-by: Keerthy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use dev_name to get a unique label and use -1 for a base to get our
selection automatically. We pull in all GPIOs per chip now so this
does not have the effect of out of order labels like before.
We do these both together so we can drop all the static data in one
patch. This also lets us normalize the return paths as we don't need
any cleanup after this change.
Signed-off-by: Andrew F. Davis <[email protected]>
Tested-by: Keerthy <[email protected]>
Acked-by: Keerthy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The current code only frees N-1 gpios if an error occurs during
gpiod_set_transitory, gpiod_direction_output or gpiod_direction_input.
Leading to gpios that cannot be used by userspace nor other drivers.
Cc: Timur Tabi <[email protected]>
Cc: [email protected]
Fixes: ab3dbcf78f60f46d ("gpioib: do not free unrequested descriptors)
Reported-by: Jan Lorenzen <[email protected]>
Reported-by: Jim Paris <[email protected]>
Signed-off-by: Ricardo Ribalda Delgado <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
A bunch of core gpiolib files still include the <linux/gpio.h>
legacy API header for no good reason. After this only the
gpiolib-legacy.c file includes it, which is fine.
The sysfs ABI code has a pointless wrapper function around
gpio_to_desc() we can just loose.
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX license tag for these drivers.
Cc: [email protected]
Cc: Charles Keepax <[email protected]>
Cc: Mark Brown <[email protected]>
Acked-by: Richard Fitzgerald <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
These are GPIO drivers so just include <linux/gpio/driver.h>.
Cc: [email protected]
Cc: Charles Keepax <[email protected]>
Cc: Mark Brown <[email protected]>
Acked-by: Richard Fitzgerald <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX license tag for this file.
Cc: Kamlakant Patel <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Cc: Kamlakant Patel <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX header for the license.
Cc: Daniel Drake <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Cc: Daniel Drake <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX header for the license.
Cc: Lars Poeschel <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Cc: Lars Poeschel <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX header for the license.
Acked-by: Baruch Siach <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Acked-by: Baruch Siach <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This API is not used anywhere in the kernel and has remained
unused for years after being introduced.
Over time, we have developed a subsystem to deal with pin
control and this now managed pull up/down.
Delete the old and unused API. If this platform needs it,
we should implement a proper pin controller for it instead.
Cc: Yoichi Yuasa <[email protected]>
Cc: Ralf Baechle <[email protected]>
Acked-by: Paul Burton <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This switches this file to use the SPDX license tag.
Cc: Yoichi Yuasa <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Cc: Yoichi Yuasa <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Some drivers use a single irqchip for multiple gpiochips. As a result the
irqchip hooks are overridden for the first gpiochip that was added, but
for the other gpiochip instances this should not happen again, otherwise
we would go into an infinite recursion.
Check for this, but also log a message that the driver should be fixed
since this is bad practice.
Signed-off-by: Hans Verkuil <[email protected]>
Tested-by: Heikki Krogerus <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
EINVAL is very generic, use ENOTSUPP in case the gpiochip does not
provide this function. While removing the assignment from the 'status'
variable, use better indentation in the declaration block.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Certain GPIO descriptor arrays returned by gpio_get_array() may contain
information on direct mapping of array members to pins of a single GPIO
chip in hardware order. In such cases, bitmaps of values can be passed
directly from/to the chip's .get/set_multiple() callbacks without
wasting time on iterations.
Add respective code to gpiod_get/set_array_bitmap_complex() functions.
Pins not applicable for fast path are processed as before, skipping
over the 'fast' ones.
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Janusz Krzysztofik <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions. Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a user builds an array itself from single GPIOs.
Cc: Jonathan Corbet <[email protected]>
Cc: Miguel Ojeda Sandonis <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Sebastien Bourdelin <[email protected]>
Cc: Lukas Wunner <[email protected]>
Cc: Peter Korsgaard <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Rojhalat Ibrahim <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Cc: Russell King <[email protected]>
Cc: Kishon Vijay Abraham I <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Michael Hennerich <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Cc: Hartmut Knaack <[email protected]>
Cc: Peter Meerwald-Stadler <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Yegor Yefremov <[email protected]>
Cc: Uwe Kleine-König <[email protected]>
Signed-off-by: Janusz Krzysztofik <[email protected]>
Acked-by: Ulf Hansson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Certain GPIO array lookup results may map directly to GPIO pins of a
single GPIO chip in hardware order. If that condition is recognized
and handled efficiently, significant performance gain of get/set array
functions may be possible.
While processing a request for an array of GPIO descriptors, identify
those which represent corresponding pins of a single GPIO chip. Skip
over pins which require open source or open drain special processing.
Moreover, identify pins which require inversion. Pass a pointer to
that information with the array to the caller so it can benefit from
enhanced performance as soon as get/set array functions can accept and
make efficient use of it.
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Janusz Krzysztofik <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Most users of get/set array functions iterate consecutive bits of data,
usually a single integer, while processing array of results obtained
from, or building an array of values to be passed to those functions.
Save time wasted on those iterations by changing the functions' API to
accept bitmaps.
All current users are updated as well.
More benefits from the change are expected as soon as planned support
for accepting/passing those bitmaps directly from/to respective GPIO
chip callbacks if applicable is implemented.
Cc: Jonathan Corbet <[email protected]>
Cc: Miguel Ojeda Sandonis <[email protected]>
Cc: Sebastien Bourdelin <[email protected]>
Cc: Lukas Wunner <[email protected]>
Cc: Peter Korsgaard <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Rojhalat Ibrahim <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Cc: Russell King <[email protected]>
Cc: Kishon Vijay Abraham I <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Michael Hennerich <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Cc: Hartmut Knaack <[email protected]>
Cc: Peter Meerwald-Stadler <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Yegor Yefremov <[email protected]>
Cc: Uwe Kleine-König <[email protected]>
Signed-off-by: Janusz Krzysztofik <[email protected]>
Acked-by: Ulf Hansson <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This concerns gpio edge detection for GPIO IRQs used from
userspace for GPIO event listeners.
Trying to work out the right event if it's not sure that the
examined gpio actually moved is impossible.
Consider two gpios "gpioA" and "gpioB" that share an interrupt.
gpioA's irq should trigger on any edge, gpioB's on a falling edge.
If now the common irq fires and both gpio lines are high, there
are several possibilities that could have happend:
a) gpioA just had a low-to-high edge
b) gpioB just had a high-to-low-to-high spike
c) a combination of both a) and b)
While c) is unlikely (in most setups) a) and b) alone are bad
enough. Currently the code assumes case a) unconditionally and
doesn't report an event for gpioB. Note that even if there is no
irq sharing involved a spike for a gpio might not result in an
event if it's configured to trigger for a single edge only.
The only way to improve this is to drop support for interrupt
sharing. This way a spike results in an event for the right gpio
at least. Note that apart from dropping IRQF_SHARED this
effectively undoes commit df1e76f28ffe
("gpiolib: skip unwanted events, don't convert them to opposite edge").
This obviously breaks setups that rely on interrupt sharing,
but given that this cannot be reliable, this is probably an
acceptable trade-off.
Signed-off-by: Uwe Kleine-König <[email protected]>
[Assuming there are no users of interrupt sharing yet]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Just use the SPDX identifier for the license.
Acked-by: Stefan Agner <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so only include <linux/gpio/driver.h>.
Acked-by: Stefan Agner <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The SPI chipselects are assumed to be active low in the current
binding, so when we want to use GPIO descriptors and handle
the active low/high semantics in gpiolib, we need a special
parsing quirk to deal with this.
We check for the property "spi-cs-high" and if that is
NOT present we assume the CS line is active low.
If the line is tagged as active low in the device tree and
has no "spi-cs-high" property all is fine, the device
tree and the SPI bindings are in agreement.
If the line is tagged as active high in the device tree with
the second cell flag and has no "spi-cs-high" property we
enforce active low semantics (as this is the exception we can
just tag on the flag).
If the line is tagged as active low with the second cell flag
AND tagged with "spi-cs-high" the SPI active high property
takes precedence and we print a warning.
Cc: Mark Brown <[email protected]>
Cc: [email protected]
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Since this driver does not use the gpiolib irqchip helpers it will have to
allocate the irq resources and irq_en/disable itself.
Use the new gpiochip_req/relres_irq helpers to request/release all the
resources.
Signed-off-by: Hans Verkuil <[email protected]>
Cc: Ray Jui <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
When using the gpiolib irqchip helpers install irq_enable/disable
hooks for the irqchip to ensure that gpiolib knows when the irq
is enabled or disabled, allowing drivers to disable the irq and then
use it as an output pin, and later switch the direction to input and
re-enable the irq.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio
as an interrupt. This is done when the irq is requested and it marks the
gpio as in use by an interrupt.
This is problematic for cases where a gpio pin is used as an interrupt
pin, then, after the irq is disabled, is used as a regular gpio pin.
Currently it is not possible to do this other than by first freeing
the interrupt so gpiochip_unlock_as_irq is called, since an attempt to
switch the gpio direction for output will fail since gpiolib believes
that the gpio is in use for an interrupt and it does not know that it
the irq is actually disabled.
There are currently two drivers that would like to be able to do this:
the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
driver where you want to configure the gpio pin as an interrupt while
waiting for traffic over the CEC bus, or as a regular pin when receiving or
transmitting a CEC message.
The solution is to add a new flag that is set when the irq is enabled,
and have gpiod_direction_output check for that flag.
We also add functions that drivers that do not use GPIOLIB_IRQCHIP
can call when they enable/disable the irq.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Centralize setting the irq_request/release_resources callbacks
in one function since we'll be adding more callbacks to that.
Also fix the removal of the callback overrides: this should
only be done if we actually installed our own callback there.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into
the irq_request_resource and irq_release_resource callbacks of the
irq_chip so they correctly 'get' the module and lock the gpio line
for IRQ use.
This will simplify driver code.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The problem is that if port == ARRAY_SIZE() and "gc == &epg->gc[port]"
then that should be treated as invalid.
Fixes: fd935fc421e7 ("gpio: ep93xx: Do not pingpong irq numbers")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Currently the while loop checks for the end of the array using
the size of egp->gc rather that the number of elements in the array,
so fix this. Also, perform the array size check first as stylistically
it is always good to bounds check on an array first before referencing
the array (in this case, we're just computing the address of an
element in an array so this is a moot point).
Fixes: fd935fc421e7 ("gpio: ep93xx: Do not pingpong irq numbers")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The gpiolib cannot deduce the fact that every line is output
by itself, implement a .get_direction() callback so we can
inspect this.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
It's nice to use BIT() macros rather than open coding the same.
It's good practice as sometimes people use BIT(31) and forget
that the constant must be cast unsigned long.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use the SPDX header to indicate the license for this driver.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
It's nice to be able to read back the direction of the GPIO
line from the hardware so implement .get_direction() for
twl4030.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use the SPDX header to indicate the license for this driver.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a GPIO driver so include only <linux/gpio/driver.h>.
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This is a driver so include only <linux/gpio/driver.h>.
Signed-off-by: Linus Walleij <[email protected]>
|
|
The TS5500 GPIO driver apparently supports platform data
without making any use of it whatsoever. Delete this code,
last chance to speak up if you think it is needed.
Cc: [email protected]
Cc: Vivien Didelot <[email protected]>
Cc: Jerome Oufella <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|