Commit Graph

705984 Commits

Author SHA1 Message Date
Linus Walleij
9e9355bb20 pinctrl: bcm2835: Fix some merge fallout
Fixing a small merge problem in BCM2835 related to the
new irqchip code.

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-09 09:36:07 +01:00
Linus Walleij
ec47873e1f gpio: Fix undefined lock_dep_class
The struct is wrong, this is named lock_class_key.

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 21:40:41 +01:00
Thierry Reding
959bc7b22b gpio: Automatically add lockdep keys
In order to avoid lockdep boilerplate in individual drivers, turn the
gpiochip_add_data() function into a macro that creates a unique class
key for each driver.

Note that this has the slight disadvantage of adding a key for each
driver registered with the system. However, these keys are 8 bytes in
size, which is negligible and a small price to pay for generic
infrastructure.

Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
[renane __gpiochip_add_data() to gpiochip_add_data_with_key]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:24:51 +01:00
Thierry Reding
8302cf5852 gpio: Introduce struct gpio_irq_chip.first
Some GPIO chips cannot support sparse IRQ numbering and therefore need
to manually allocate their interrupt descriptors statically. For these
cases, a driver can pass the first allocated IRQ via the struct
gpio_irq_chip's "first" field and thereby cause the IRQ domain to map
all IRQs during initialization.

Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:17:12 +01:00
Thierry Reding
60ed54cae8 gpio: Disambiguate struct gpio_irq_chip.nested
The nested field in struct gpio_irq_chip currently has two meanings. On
one hand it marks an IRQ chip as being nested (as opposed to chained),
while on the other hand it also means that an IRQ chip uses nested
thread handlers.

However, nested IRQ chips can already be identified by the fact that
they don't pass a parent handler (the driver would instead already have
installed a nested handler using request_irq()).

Therefore, the only use for the nested attribute is to inform gpiolib
that an IRQ chip uses nested thread handlers (as opposed to regular,
non-threaded handlers). To clarify its purpose, rename the field to
"threaded".

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:16:06 +01:00
Thierry Reding
5b2b135a87 gpio: Add Tegra186 support
Tegra186 has two GPIO controllers that are largely register compatible
between one another but are completely different from the controller
found on earlier generations.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:14:51 +01:00
Thierry Reding
1b95b4eb56 gpio: Export gpiochip_irq_{map,unmap}()
Export these functions so that drivers can explicitly use these when
setting up their IRQ domain.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:14:09 +01:00
Thierry Reding
e0d8972898 gpio: Implement tighter IRQ chip integration
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:12:01 +01:00
Thierry Reding
ca9df053fb gpio: Move lock_key into struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:10:54 +01:00
Thierry Reding
dc7b0387ee gpio: Move irq_valid_mask into struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:10:18 +01:00
Thierry Reding
dc6bafee86 gpio: Move irq_nested into struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:09:24 +01:00
Thierry Reding
39e5f09695 gpio: Move irq_chained_parent to struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:08:46 +01:00
Thierry Reding
3634eeb0fe gpio: Move irq_default_type to struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:08:05 +01:00
Thierry Reding
c7a0aa5952 gpio: Move irq_handler to struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:07:20 +01:00
Thierry Reding
f0fbe7bce7 gpio: Move irqdomain into struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 14:06:21 +01:00
Thierry Reding
da80ff81a8 gpio: Move irqchip into struct gpio_irq_chip
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 13:59:24 +01:00
Thierry Reding
c44eafd79b gpio: Introduce struct gpio_irq_chip
This new structure will be used to group all fields related to interrupt
handling in a GPIO chip. Doing so will properly namespace these fields
and make it easier to distinguish which fields are used for IRQ support.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-08 13:58:19 +01:00
Arnd Bergmann
b53b8300bf pinctrl: armada-37xx: remove unused variable
A cleanup left behind a temporary variable that is now unused:

drivers/pinctrl/mvebu/pinctrl-armada-37xx.c: In function 'armada_37xx_irq_startup':
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:693:20: error: unused variable 'chip' [-Werror=unused-variable]

This removes the declarations as well.

Fixes: 3ee9e605ca ("pinctrl: armada-37xx: Stop using struct gpio_chip.irq_base")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-03 23:19:48 +01:00
Ard Biesheuvel
eb32889928 gpio: mb86s70: Revert "Return error if requesting an already assigned gpio"
Commit fd9c963c56 ("gpio: mb86s70: Return error if requesting an
already assigned gpio") adds code that infers from the state of the
GPIO Pin Function Register (PFR) whether a GPIO has been assigned
already. This assumes that the pin functions are set to 'peripheral'
when the driver is loaded, which is not guaranteed. Also, the GPIO
layer is perfectly capable of keeping track of which GPIOs have been
assigned already, so we shouldn't need this check in the first place.

This reverts commit fd9c963c56.

Cc: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 13:13:34 +01:00
Ard Biesheuvel
e1289dba18 gpio: mb86s7x: share with other SoCs as module
In order to reuse this driver for the Socionext Synquacer SC2A11 SoC,
which inherited this IP from Fujitsu, remove the ARCH_MB86S7X Kconfig
dependency, and revert the changes that prevent it from being built as
a module.

This reverts commits d65aa4b67b and
d5610e514e.

Cc: Geliang Tang <geliangtang@gmail.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[Folded in module_platform_driver() fixup]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 13:11:38 +01:00
Doug Berger
4714221b0c gpio: brcmstb: implement suspend/resume/shutdown
This commit corrects problems with the previous wake implementation
by implementing suspend and resume power management operations and
the driver shutdown operation.

Wake masks are used to keep track of which GPIO should wake the
device.  On suspend the GPIO state is saved and the possible wakeup
sources are explicitly unmasked in the hardware. Non-wakeup sources
are explicitly masked so IRQCHIP_MASK_ON_SUSPEND is no longer
necessary.  The saved state of the GPIO is restored upon resume.
It is important not to write to the GPIO status register since this
has the effect of clearing bits.  The status register is explicitly
removed from the register save and restore to ensure this.

The shutdown operation allows the hardware to be put into the same
quiesced state as the suspend operation and removes the need for
the reboot notifier.

Unfortunately, there appears to be some confusion about whether
a pending disabled wake interrupt should wake the system. If a wake
capable interrupt is disabled using the default "lazy disable"
behavior and it is triggered before the suspend_device_irq call
the interrupt hardware will be acknowledged by mask_ack_irq and the
IRQS_PENDING flag is added to its state. However, the IRQS_PENDING
flag of wake interrupts is not checked to prevent the transition to
suspend and the hardware has been acked which prevents its wakeup.
If the lazy disabled interrupt is triggered after the call to
suspend_device_irqs then the wakeup logic will abort the suspend.
The irq_disable method is defined by this GPIO driver to prevent
lazy disable so that the pending hardware state remains asserted
allowing the hardware to wake and providing a consistent behavior.

In addition, the IRQ_DISABLE_UNLAZY flag is set for the non-wake
parent interrupt as a convenience to prevent the need to add code
to the brcmstb_gpio_irq_handler to support "lazy disable" of the
non-wake parent interrupt when it is disabled during suspend and
resume. Chained interrupt parents are not normally disabled, but
these GPIO devices have different parent interrupts for wake and
non-wake handling. It is convenient to mask the non-wake parent
when suspending to preserve the hardware state for proper wakeup
accounting when the driver is resumed.

Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:51:40 +01:00
Doug Berger
0ba31dc201 gpio: brcmstb: consolidate interrupt domains
The GPIOLIB IRQ chip helpers were very appealing, but badly broke
the 1:1 mapping between a GPIO controller's device_node and its
interrupt domain.

When another device-tree node references a GPIO device as its
interrupt parent, the irq_create_of_mapping() function looks for
the irq domain of the GPIO device and since all bank irq domains
reference the same GPIO device node it always resolves to the irq
domain of the first bank regardless of which bank the number of
the GPIO should resolve. This domain can only map hwirq numbers
0-31 so interrupts on GPIO above that can't be mapped by the
device-tree.

This commit effectively reverts the patch from Gregory Fong [1]
that was accepted upstream and replaces it with a consolidated
irq domain implementation with one larger interrupt domain per
GPIO controller instance spanning multiple GPIO banks based on
an earlier patch [2] also submitted by Gregory Fong.

[1] https://patchwork.kernel.org/patch/6921561/
[2] https://patchwork.kernel.org/patch/6347811/

Fixes: 19a7b6940b ("gpio: brcmstb: Add interrupt and wakeup source support")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Gregory Fong <gregory.0xf0@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:34:40 +01:00
Doug Berger
633007a36e gpio: brcmstb: correct the configuration of level interrupts
This commit corrects a bug when configuring the GPIO hardware for
IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH interrupt types. The
hardware is now correctly configured to support those types.

Fixes: 19a7b6940b ("gpio: brcmstb: Add interrupt and wakeup source support")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:30:44 +01:00
Doug Berger
2c218b9f1b gpio: brcmstb: switch to handle_level_irq flow
Reading and writing the gpio bank status register each time a pending
interrupt bit is serviced could cause new pending bits to be cleared
without servicing the associated interrupts.

By using the handle_level_irq flow instead of the handle_simple_irq
flow we get proper handling of interrupt masking as well as acking
of interrupts.  The irq_ack method is added to support this.

Fixes: 19a7b6940b ("gpio: brcmstb: Add interrupt and wakeup source support")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:29:53 +01:00
Doug Berger
142c168e0e gpio: brcmstb: release the bgpio lock during irq handlers
The basic memory-mapped GPIO controller lock must be released
before calling the registered GPIO interrupt handlers to allow
the interrupt handlers to access the hardware.

Examples of why a GPIO interrupt handler might want to access
the GPIO hardware include an interrupt that is configured to
trigger on rising and falling edges that needs to read the
current level of the input to know how to respond, or an
interrupt that causes a change in a GPIO output in the same
bank. If the lock is not released before enterring the handler
the hardware accesses will deadlock when they attempt to grab
the lock.

Since the lock is only needed to protect the calculation of
unmasked pending interrupts create a dedicated function to
perform this and hide the complexity.

Fixes: 19a7b6940b ("gpio: brcmstb: Add interrupt and wakeup source support")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:28:46 +01:00
Doug Berger
0752df6611 gpio: brcmstb: allow all instances to be wakeup sources
This commit allows a wakeup parent interrupt to be shared between
instances.

It also removes the redundant can_wake member of the private data
structure by using whether the parent_wake_irq has been defined to
indicate that the GPIO device can wake.

Fixes: 19a7b6940b ("gpio: brcmstb: Add interrupt and wakeup source support")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:27:59 +01:00
Markus Elfring
5ac9d2df5b gpio-adnp: Use common error handling code in adnp_gpio_dbg_show()
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 10:09:04 +01:00
Sergei Shtylyov
5a24d4b601 gpio-rcar: use devm_ioremap_resource()
Using devm_ioremap_resource() has several advantages over devm_ioremap():
- it checks the passed resource's validity;
- it calls devm_request_mem_region() to check for the resource overlap;
- it prints an error message in case of error.

We can call devm_ioremap_resource() instead of devm_ioremap_nocache()
as ioremap() and ioremap_nocache()  are implemented identically on ARM.
Doing this saves 2 LoCs and 80 bytes (AArch64 gcc 4.8.5).

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-31 09:52:13 +01:00
Linus Walleij
80057cb417 gpio-mmio: Use the new .get_multiple() callback
It is possible to read all lines of a generic MMIO GPIO chip
with a single register read so support this if we are in
native endianness.

Add an especially quirky callback to read multiple lines for
the variants that require you to read values from the
output registers if and only if the line is set as output.
We managed to do that with a maximum of two register reads,
and just one read if the requested lines are all input or all
output.

Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-30 08:35:32 +01:00
Linus Walleij
24efd94bc3 gpio: mmio: Make pin2mask() a private business
The vtable call pin2mask() was introducing a vtable function call
in every gpiochip callback for a generic MMIO GPIO chip. This was
not exactly efficient. (Maybe link-time optimization could get rid of
it, I don't know.)

After removing all external calls into this API we can make it a
boolean flag in the struct gpio_chip call and sink the function into
the gpio-mmio driver yielding encapsulation and potential speedups.

Cc: Anton Vorontsov <anton@enomsg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:41 +02:00
Linus Walleij
b3222f7147 gpio: mpc8xxx: Do not reverse bits using bgpio
The MPC8xxx driver is always instantiating its generic GPIO functions
with the flag BGPIOF_BIG_ENDIAN. This means "big-endian bit order"
and means the bits representing the GPIO lines in the registers are
reversed around 31 bits so line 0 is at bit 31 and so forth down to
line 31 in bit 0.

Instead of looping into the generic MMIO gpio to do the simple
calculation of a bitmask, through a vtable call with two parameters
likely using stack frames etc (unless the compiler optimize it)
and obscuring the view for the programmer, let's just open-code
what the call does. This likely executes faster, saves space and
makes the code easier to read.

Cc: Liu Gang <Gang.Liu@nxp.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:40 +02:00
Linus Walleij
d74423687f gpio: brcmstb: Do not use gc->pin2mask()
The pin2mask() accessor only shuffles BIT ORDER in big endian systems,
i.e. the bitstuffing is swizzled big endian so "bit 0" is bit 7 or
bit 15 or bit 31 or so.

The brcmstb only uses big endian BYTE ORDER which will be taken car of
by the ->write_reg() callback.

Just use BIT(offset) to assign the bit.

Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:39 +02:00
Linus Walleij
5c7b0c4e7d gpio: grgpio: Do not use gc->pin2mask()
The pin2mask() accessor only shuffles BIT ORDER in big endian systems,
i.e. the bitstuffing is swizzled big endian so "bit 0" is bit 7 or
bit 15 or bit 31 or so.

The grgpio only uses big endian BYTE ORDER which will be taken car of
by the ->write_reg() callback.

Just use BIT(offset) to assign the bit.

Acked-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:38 +02:00
Linus Walleij
fe29416b5c gpio: loongson1: fix bgpio usage
When no flags are given, the native endianness is used to access
the MMIO registers, and the pin2mask() call can simply be
converted to a BIT() call, as per the default pin2mask()
implementation in gpio-mmio.c.

Cc: Kelvin Cheung <keguang.zhang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:38 +02:00
Linus Walleij
d97a1b5688 gpio: dwapb: fix bgpio usage
The DW APB GPIO driver uses the generic GPIO library gpio-mmio,
and initialize the flags as "false", which should be 0.

When no flags are given, the native endianness is used to access
the MMIO registers, and the pin2mask() call can simply be
converted to a BIT() call, as per the default pin2mask()
implementation in gpio-mmio.c.

Acked-by: Alan Tull <atull@kernel.org>
Acked-by: Hoan Tran <hotran@apm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-25 11:25:10 +02:00
Masahiro Yamada
dbe776c2ca gpio: uniphier: add UniPhier GPIO controller driver
This GPIO controller is used on UniPhier SoC family.

It also serves as an interrupt controller, but interrupt signals are
just delivered to the parent irqchip without any latching or OR'ing.
This type of hardware can be well described with hierarchy IRQ domain.

One unfortunate thing for this device is that the interrupt mapping to
the interrupt parent is not contiguous.

I asked how DT can describe interrupt mapping between two irqchips [1],
but I could not find a good solution (at least in the framework level).
In fact, irqchip drivers using hierarchy domain generally hard-code the
DT binding of their parent.

After tackling on several approaches such as hard-code of hwirqs,
irq_domain_push_irq(), I ended up with a vendor specific property.
If we come up with a good idea to support this in the framework, we
can migrate over to it, but we can live with a driver-level solution
for now.

[1] https://lkml.org/lkml/2017/7/6/758

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-23 10:37:31 +02:00
Masahiro Yamada
1c59d04505 dt-bindings: gpio: uniphier: add UniPhier GPIO binding
This GPIO controller is used on UniPhier SoC family.

The vendor specific property "socionext,interrupt-ranges" is for
specifying interrupt mapping to the parent interrupt controller
because the mapping is not contiguous.  It works like "ranges",
but transforms "interrupts" instead of "reg".

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-23 10:36:58 +02:00
Andrew Jeffery
2cbfca66ba gpio: Fix loose spelling
Literally.

I expect "lose" was meant here, rather than "loose", though you could feasibly
use a somewhat uncommon definition of "loose" to mean what would be meant by
"lose": "Loose the hounds" for instance, as in "Release the hounds".
Substituting in "value" for "hounds" gives "release the value", and makes some
sense, but futher substituting back to loose gives "loose the value" which
overall just seems a bit anachronistic.

Instead, use modern, pragmatic English and save a character.

Cc: Russell Currey <ruscur@russell.cc>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-20 09:37:32 +02:00
Lukas Wunner
b2f68edfd5 gpio: Add driver for Maxim MAX3191x industrial serializer
The driver was developed for and tested with the MAX31913 built into
the Revolution Pi by KUNBUS, but should work with all members of the
MAX3191x family:

MAX31910: low power
MAX31911: LED drivers
MAX31912: LED drivers + 2nd voltage monitor + low power
MAX31913: LED drivers + 2nd voltage monitor
MAX31953: LED drivers + 2nd voltage monitor + isolation
MAX31963: LED drivers + 2nd voltage monitor + isolation + buck regulator

Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:40:07 +02:00
Lukas Wunner
c019c18da1 dt-bindings: gpio: max3191x: Document new driver
Add device tree bindings for Maxim MAX3191x industrial serializer.

Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:35:59 +02:00
Lukas Wunner
1f63fab955 dt-bindings: Document common property for daisy-chained devices
Many serially-attached GPIO and IIO devices are daisy-chainable.

    Examples for GPIO devices are Maxim MAX3191x and TI SN65HVS88x:
    https://datasheets.maximintegrated.com/en/ds/MAX31913.pdf
    http://www.ti.com/lit/ds/symlink/sn65hvs880.pdf

    Examples for IIO devices are TI DAC128S085 and TI DAC161S055:
    http://www.ti.com/lit/ds/symlink/dac128s085.pdf
    http://www.ti.com/lit/ds/symlink/dac161s055.pdf

We already have drivers for daisy-chainable devices in the tree but
their devicetree bindings are somewhat inconsistent and ill-named:

    The gpio-74x164.c driver uses "registers-number" to convey the
    number of devices in the daisy-chain.  (Sans vendor prefix,
    multiple vendors sell compatible versions of this chip.)

    The gpio-pisosr.c driver takes a different approach and calculates
    the number of devices in the daisy-chain by dividing the common
    "ngpios" property (Documentation/devicetree/bindings/gpio/gpio.txt)
    by 8 (which assumes that each chip has 8 inputs).

Let's standardize on a common "#daisy-chained-devices" property.
That name was chosen because it's the term most frequently used in
datasheets.  (A less frequently used synonym is "cascaded devices".)

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:33:11 +02:00
Martin Kaiser
5048f0aefb gpiolib: clear irq handler and data in one go
Replace the two separate calls for clearing the irqchip's chained handler
and its data with a single irq_set_chained_handler_and_data() call.

Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:41 +02:00
Thierry Reding
3ee9e605ca pinctrl: armada-37xx: Stop using struct gpio_chip.irq_base
The Armada 37xx driver always initializes the IRQ base to 0, hence the
subtraction is a no-op. Remove the subtraction and thereby the last user
of struct gpio_chip's .irq_base field.

Note that this was also actually a bug and only worked because of the
above assumption. If the IRQ base had been dynamically allocated, the
subtraction would've caused the wrong mask to be generated since the
struct irq_data.hwirq field is an index local to the IRQ domain. As a
result, it should now be safe to also allocate this chip's IRQ base
dynamically, unless there are consumers left that refer to the IRQs by
their global number.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:41 +02:00
Tom Saeger
0747c3ecfb Documentation: fix ref to gpio.txt
Signed-off-by: Tom Saeger <tom.saeger@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:40 +02:00
Gustavo A. R. Silva
e80df7b823 gpio: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:40 +02:00
Bartosz Golaszewski
609aaf6a60 gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags for input
OPEN_DRAIN and OPEN_SOURCE flags only affect the way we drive a GPIO
line, so they only make sense for output mode. Just as we only allow
input mode for event handle requests, don't allow passing open-drain
and open-source flags for any other mode than explicit output.

Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:39 +02:00
Bartosz Golaszewski
418ee8e91f gpiolib: only check line handle flags once
There's no need to check the validity of handle request flags more
than once, right after copying the data from user. Move the check
out of the for loop and simplify the error path by bailing out before
allocating any resources.

Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:39 +02:00
Lukas Wunner
eec1d566cd gpio: Introduce ->get_multiple callback
SPI-attached GPIO controllers typically read out all inputs in one go.
If callers desire the values of multipe inputs, ideally a single readout
should take place to return the desired values.  However the current
driver API only offers a ->get callback but no ->get_multiple (unlike
->set_multiple, which is present).  Thus, to read multiple inputs, a
full readout needs to be performed for every single value (barring
driver-internal caching), which is inefficient.

In fact, the lack of a ->get_multiple callback has been bemoaned
repeatedly by the gpio subsystem maintainer:
http://www.spinics.net/lists/linux-gpio/msg10571.html
http://www.spinics.net/lists/devicetree/msg121734.html

Introduce the missing callback.  Add corresponding consumer functions
such as gpiod_get_array_value().  Amend linehandle_ioctl() to take
advantage of the newly added infrastructure.  Update the documentation.

Cc: Rojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:39 +02:00
Lukas Wunner
5307e2ad69 bitops: Introduce assign_bit()
A common idiom is to assign a value to a bit with:

    if (value)
        set_bit(nr, addr);
    else
        clear_bit(nr, addr);

Likewise common is the one-line expression variant:

    value ? set_bit(nr, addr) : clear_bit(nr, addr);

Commit 9a8ac3ae68 ("dm mpath: cleanup QUEUE_IF_NO_PATH bit
manipulation by introducing assign_bit()") introduced assign_bit()
to the md subsystem for brevity.

Make it available to others, specifically gpiolib and the upcoming
driver for Maxim MAX3191x industrial serializer chips.

As requested by Peter Zijlstra, change the argument order to reflect
traditional "dst = src" in C, hence "assign_bit(nr, addr, value)".

Cc: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Neil Brown <neilb@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:38 +02:00
Alan Tull
07901a94f9 gpio: gpio-dwapb: add optional reset
Some platforms require reset to be released to allow register
access.

Signed-off-by: Alan Tull <atull@kernel.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
[Added DT bindings oneliner for standard reset binding]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-19 22:32:38 +02:00