Skip to contentSkip to conversation

gpio: Add GPIO support for the WinSystems WS16C48

PATCH In review William Breathitt Gray 2 participants 3 messages Jan 20, 2016 – Jan 28, 2016

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH v5 1/1 gpio: Add GPIO support for the WinSystems WS16C48

The WinSystems WS16C48 device provides 48 lines of digital I/O. In addition, the first 24 lines may be used for interrupt-handled edge detection; rising edge detection and falling edge detection are supported.

This driver provides GPIO and IRQ support for these 48 channels of digital I/O. The base port address for the device may be configured via the ws16c48_base module parameter. The interrupt line number for the device may be configured via the ws16c48_irq module parameter.

---
Changes in v5:
- Allow sharing the IRQ

 MAINTAINERS                 |   6 +
 drivers/gpio/Kconfig        |   9 +
 drivers/gpio/Makefile       |   1 +
 drivers/gpio/gpio-ws16c48.c | 436 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 452 insertions(+)
 create mode 100644 drivers/gpio/gpio-ws16c48.c
MAINTAINERS +6 -0
index 4d7d83c..1cdb661 100644
@@ -11659,6 +11659,12 @@ M:	David Härdeman <[email protected]>
 S:	Maintained
 F:	drivers/media/rc/winbond-cir.c
 
+WINSYSTEMS WS16C48 GPIO DRIVER
+M:	William Breathitt Gray <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	drivers/gpio/gpio-ws16c48.c
+
 WIMAX STACK
 M:	Inaky Perez-Gonzalez <[email protected]>
 M:	[email protected]
drivers/gpio/Kconfig +9 -0
index cb212eb..b391139 100644
@@ -577,6 +577,15 @@ config GPIO_TS5500
 	  blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
 	  LCD port.
 
+config GPIO_WS16C48
+	tristate "WinSystems WS16C48 GPIO support"
+	select GPIOLIB_IRQCHIP
+	help
+	  Enables GPIO support for the WinSystems WS16C48. The base port address
+	  for the device may be configured via the ws16c48_base module
+	  parameter. The interrupt line number for the device may be configured
+	  via the ws16c48_irq module parameter.
+
 endmenu
 
 menu "I2C GPIO expanders"
drivers/gpio/Makefile +1 -0
index 548e9b5..bcb6cbe 100644
@@ -112,6 +112,7 @@ obj-$(CONFIG_GPIO_VX855)	+= gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
 obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
+obj-$(CONFIG_GPIO_WS16C48)	+= gpio-ws16c48.o
 obj-$(CONFIG_GPIO_XGENE)	+= gpio-xgene.o
 obj-$(CONFIG_GPIO_XGENE_SB)	+= gpio-xgene-sb.o
 obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
drivers/gpio/gpio-ws16c48.c new file +436 -0

436 lines not on this page · raw message

Signature · 6 lines
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1 lore raw
Quoted 10 lines · William Breathitt Gray

The WinSystems WS16C48 device provides 48 lines of digital I/O. In addition, the first 24 lines may be used for interrupt-handled edge detection; rising edge detection and falling edge detection are supported.

This driver provides GPIO and IRQ support for these 48 channels of digital I/O. The base port address for the device may be configured via the ws16c48_base module parameter. The interrupt line number for the device may be configured via the ws16c48_irq module parameter.

Quoted 4 lines

---
Changes in v5:
- Allow sharing the IRQ

Patch applied.

Out of curiosity: what is your usecase for all these exotic GPIO cards?

Yours,
Linus Walleij

#2 lore raw
Quoted 2 lines · Linus Walleij

Out of curiosity: what is your usecase for all these exotic GPIO cards?

My motivated mainly by philosophy. Despite their popularity in the embedded systems industry, there isn't much support in the baseline kernel for PC/104 and other cards. Typically, when a user purchases one of these devices, they receive some general drivers which serve more as proof that the device is working rather than as practical driver.

The user is lucky if they receive Linux drivers rather than just the usual Windows drivers. Even if Linux drivers are provided, the drivers are often written for ancient kernel versions (e.g. version 2.4), and implement some custom character device structure rather than utilize the Linux device model.

I'm writing these drivers to help bring support for these devices to the baseline Linux kernel, in the hopes that it will be useful to someone, and perhaps even motivate the companies to improve and share their own Linux drivers.

William Breathitt Gray