This is the bulk of GPIO changes for the v5.1 cycle:

Core changes:

- The big change this time around is the irqchip handling in
  the qualcomm pin controllers, closely coupled with the
  gpiochip. This rework, in a classic fall-between-the-chairs
  fashion has been sidestepped for too long. The Qualcomm
  IRQchips using the SPMI and SSBI transport mechanisms have
  been rewritten to use hierarchical irqchip. This creates
  the base from which I intend to gradually pull support for
  hierarchical irqchips into the gpiolib irqchip helpers to
  cut down on duplicate code. We have too many hacks in the
  kernel because people have been working around the missing
  hierarchical irqchip for years, and once it was there,
  noone understood it for a while. We are now slowly adapting
  to using it. This is why this pull requests include changes
  to MFD, SPMI, IRQchip core and some ARM Device Trees
  pertaining to the Qualcomm chip family. Since Qualcomm have
  so many chips and such large deployments it is paramount
  that this platform gets this right, and now it (hopefully)

- Core support for pull-up and pull-down configuration, also
  from the device tree. When a simple GPIO chip support a
  "off or on" pull-up or pull-down resistor, we provide a
  way to set this up using machine descriptors or device tree.
  If more elaborate control of pull up/down (such as
  resistance shunt setting) is required, drivers should be
  phased over to use pin control. We do not yet provide a
  userspace ABI for this pull up-down setting but I suspect
  the makers are going to ask for it soon enough. PCA953x
  is the first user of this new API.

- The GPIO mockup driver has been revamped after some
  discussion improving the IRQ simulator in the process.
  The idea is to make it possible to use the mockup for
  both testing and virtual prototyping, e.g. when you do
  not yet have a GPIO expander to play with but really
  want to get something to develop code around before
  hardware is available. It's neat. The blackbox testing
  usecase is currently making its way into kernelci.

- ACPI GPIO core preserves non direction flags when updating

- A new device core helper for devm_platform_ioremap_resource()
  is funneled through the GPIO tree with Greg's ACK.

New drivers:

- TQ-Systems QTMX86 GPIO controllers (using port-mapped

- Gateworks PLD GPIO driver (vaccumed up from OpenWrt)

- AMD G-Series PCH (Platform Controller Hub) GPIO driver.

- Fintek F81804 & F81966 subvariants.

- PCA953x now supports NXP PCAL6416.

Driver improvements:

- IRQ support on the Nintendo Wii (Hollywood) GPIO.

- get_direction() support for the MVEBU driver.

- Set the right output level on SAMA5D2.

- Drop the unused irq trigger setting on the Spreadtrum

- Wakeup support for PCA953x.

- A slew of cleanups in the various Intel drivers.

gpio: gpio-omap: fix level interrupt idling

Tony notes that the GPIO module does not idle when level interrupts are
in use, as the wakeup appears to get stuck.

After extensive investigation, it appears that the wakeup will only be
cleared if the interrupt status register is cleared while the interrupt
is enabled. However, we are currently clearing it with the interrupt
disabled for level-based interrupts.

It is acknowledged that this observed behaviour conflicts with a
statement in the TRM:

  After servicing the interrupt, the status bit in the interrupt status
  register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be
  reset and the interrupt line released (by setting the corresponding
  bit of the interrupt status register to 1) before enabling an
  interrupt for the GPIO channel in the interrupt-enable register
  the occurrence of unexpected interrupts when enabling an interrupt
  for the GPIO channel.

However, this does not appear to be a practical problem.

Further, as reported by Grygorii Strashko <>,
the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP:
Fix the sequence to clear the IRQ status" saying:

 if the status is cleared after disabling the IRQ then sWAKEUP will not
 be cleared and gates the module transition

When we unmask the level interrupt after the interrupt has been handled,
enable the interrupt and only then clear the interrupt. If the interrupt
is still pending, the hardware will re-assert the interrupt status.

Should the caution note in the TRM prove to be a problem, we could
use a clear-enable-clear sequence instead.

Cc: Aaro Koskinen <>
Cc: Keerthy <>
Cc: Peter Ujfalusi <>
Signed-off-by: Russell King <>
[ updated comments based on an earlier TI patch]
Signed-off-by: Tony Lindgren <>
Acked-by: Grygorii Strashko <>
Signed-off-by: Linus Walleij <>
1 file changed