- 08 Nov, 2017 10 commits
-
-
Thierry Reding authored
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>
-
Thierry Reding authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 03 Nov, 2017 1 commit
-
-
Arnd Bergmann authored
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: 3ee9e605 ("pinctrl: armada-37xx: Stop using struct gpio_chip.irq_base") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 31 Oct, 2017 10 commits
-
-
Ard Biesheuvel authored
Commit fd9c963c ("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 fd9c963c. 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:
-
Ard Biesheuvel authored
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 d65aa4b6 and d5610e51. Cc: Geliang Tang <geliangtang@gmail.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Doug Berger authored
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:
-
Doug Berger authored
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: 19a7b694 ("gpio: brcmstb: Add interrupt and wakeup source support") Signed-off-by:
-
Doug Berger authored
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: 19a7b694 ("gpio: brcmstb: Add interrupt and wakeup source support") Signed-off-by:
-
Doug Berger authored
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: 19a7b694 ("gpio: brcmstb: Add interrupt and wakeup source support") Signed-off-by:
-
Doug Berger authored
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: 19a7b694 ("gpio: brcmstb: Add interrupt and wakeup source support") Signed-off-by:
-
Doug Berger authored
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: 19a7b694 ("gpio: brcmstb: Add interrupt and wakeup source support") Signed-off-by:
-
Markus Elfring authored
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:
-
Sergei Shtylyov authored
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:
-
- 30 Oct, 2017 1 commit
-
-
Linus Walleij authored
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:
-
- 25 Oct, 2017 6 commits
-
-
Linus Walleij authored
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 authored
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 authored
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:
-
Linus Walleij authored
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 authored
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 authored
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:
-
- 23 Oct, 2017 2 commits
-
-
Masahiro Yamada authored
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/758Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 20 Oct, 2017 1 commit
-
-
Andrew Jeffery authored
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:
-
- 19 Oct, 2017 9 commits
-
-
Lukas Wunner authored
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:
-
Lukas Wunner authored
Add device tree bindings for Maxim MAX3191x industrial serializer. Cc: Mathias Duckeck <m.duckeck@kunbus.de> Signed-off-by:
-
Lukas Wunner authored
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:Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by:
-
Martin Kaiser authored
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:
-
Thierry Reding authored
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:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Tom Saeger authored
Signed-off-by:
Tom Saeger <tom.saeger@oracle.com> Signed-off-by:
-
Gustavo A. R. Silva authored
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:
-
Bartosz Golaszewski authored
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:
-
Bartosz Golaszewski authored
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:
-
