gpio driver for Intel Baytrail platforms

This is the second version of the Intel baytrail GPIO driver.

After looking at the pinctrl subsystem that Linus W. suggested I think pinctrl suits platforms that don't have firmware configuring the pins before the operating system is started, or when pins need to be configured on the fly.

I'd still keep this driver under GPIO. Adding it to pinctrl feels like adding more complexity without any bigger use for the features.

We expect BIOS to set all pin configurations correctly.
The comments about pin muxing capabilities are removed from the driver. The same firmware is anyway listing gpio resources in ACPI tables, so pin configurations should be correct. (The previous indication in the driver about the need to configure pins was mostly because we're working with early develpment stage firmwares which still have small hickups)

Changes since v1:
- generic cleanups suggested by Andy S.
- removed text about pin muxing
- added missing 44:th pin to SUS controller
- added level triggering option
- prevent "forever loop" in case pin is stuck in "interrupt triggered" status,

Mathias Nyman (1):
gpio: add Intel BayTrail gpio driver

 drivers/gpio/Kconfig         |   12 +
 drivers/gpio/Makefile        |    1 +
 drivers/gpio/gpio-baytrail.c |  547 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 560 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/gpio-baytrail.c

1.7.4.1

Add support for gpio on Intel BayTrail platforms. BayTrail supports 3 banks of gpios called SCORE, NCORE ans SUS with 102, 28 and 44 gpio pins. Supports gpio interrupts and ACPI gpio events.

---
 drivers/gpio/Kconfig         |   12 +
 drivers/gpio/Makefile        |    1 +
 drivers/gpio/gpio-baytrail.c |  547 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 560 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/gpio-baytrail.c

index 573c449..b712006 100644
@@ -108,6 +108,18 @@ config GPIO_MAX730X
 
 comment "Memory mapped GPIO drivers:"
 
+config GPIO_BAYTRAIL
+	bool "Intel Baytrail GPIO support"
+	depends on ACPI && X86
+	select IRQ_DOMAIN
+	help
+	  driver for memory mapped GPIO functionality on Intel Baytrail
+	  platforms. Supports 3 banks with 102, 28 and 44 gpios.
+	  Most pins are usually muxed to some other functionality by firmware,
+	  so only a small amount is available for gpio use.
+
+	  Requires ACPI device enumeration code to set up a platform device.
+
 config GPIO_CLPS711X
 	def_bool y
 	depends on ARCH_CLPS711X

index 0cb2d65..bc1f6b3 100644
@@ -16,6 +16,7 @@ obj-$(CONFIG_GPIO_ADP5520)	+= gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588)	+= gpio-adp5588.o
 obj-$(CONFIG_GPIO_AMD8111)	+= gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA)	+= gpio-arizona.o
+obj-$(CONFIG_GPIO_BAYTRAIL)	+= gpio-baytrail.o
 obj-$(CONFIG_GPIO_BT8XX)	+= gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)	+= gpio-clps711x.o
 obj-$(CONFIG_GPIO_CS5535)	+= gpio-cs5535.o

1.7.4.1

This does not address the issue that you're reimplementing the GPIO ranges from the pinctrl subsystem, and just hours ago on the mailing list Christian Ruppert sent a patch making these more flexible I think.

Subject "Add pin-list based GPIO ranges", please check this patch, isn't that exactly the helper infrastructure you need?

Of course you can make an argument that is is a good idea to duplicate this, but I want that to be explicit. To me it is still quite obvious that these gpio to pad mappings are laid out according to the actual hardware registers, and that the actual hardware registers pertain to pads rather than what we call "GPIOs", which in kernel terms are only some line.

I would still vote to put the thing in drivers/pinctrl anyway, I am perfectly happy to house pure GPIO drivers there, especially if they're obviously masking something more pinctrl-like in reality, it will be way more flexible the day that you just want to add "this one little quirk for this pin config thing", then it'll fit just fine.

Yours,
Linus Walleij

It fits better yes, with that patch I could use
struct pinctrl_gpio_range instead of the custom struct gpio_bank. The .name entry can be used for acpi_id to identify the range.

Also the gpio_to_pad() function is usable.

That is true, it's about mapping between layout of hw registers. I guess it's a tradeoff between more

I'm fine with having it under drivers/pinctrl as a GPIO driver, either just as it is, or by using the pinctrl_gpio_range structure and helper functions such as gpio_to_pad(), once Christian Rupperts patch is accepted.

any naming preference?
gpio-baytrail.c
pinctrl-gpio-baytrail.c
pinctrl-baytrail.c

-Mathias

Christian's patch is merged into the pinctrl tree for v3.11.

Bingo!

Because the hardware is a pin controller after all.

I know there is some BIOS or ROM very much wanting it to look simpler than it is, but it sure is a pin controller :-)

Thanks,
Linus Walleij