[patch -mm 00/20] chardev: GPIO for SCx200 & PC8736x: Intro

GPIO SUPPORT FOR SCx200 & PC8736x

The patch-set reworks the 2.4 vintage scx200_gpio driver for modern
2.6, and refactors GPIO support to reuse it in a new driver for the
GPIO on PC-8736x chips. Its handy for the Soekris.com net-4801, which
has both chips.

These patches have been seen recently on Kernel-Mentors, and then
Kernel-Newbies ML, where Jesper Juhl kindly reviewed it. His feedback
has been incorporated. Thanks Jesper !

Its also gone to soekris-tech@xxxxxxxxxxx for possible testing by
linux folks, Ive gotten 1 promise so far. Theyre mostly BSD folk over there,
but we'll see..


Device-file & Sysfs

The driver preserves the existing device-file interface, including the
write/cmd set, but adds v to 'view' the pin-settings & configs by
inducing, via gpio_dump(), a dev_info() call. Its a fairly crappy way
to get status, but it sticks to the syslog approach, conservatively.

Allowing users to voluntarily trigger logging is good, it gives them a
familiar way to confirm their app's control & use of the pins, and Ive
thus reduced the pin-mode-updates from dev_info to dev_dbg.

Ive recently bolted on a proto sysfs interface for both new drivers.
Im not including those patches here; they (the patch + doc-pre-patch) are
still quite raw (and unreviewed on KNML), and since they 'invent' a
convention for GPIO, a proper vetting is needed. Since this patchset
is much bigger than my previous ones, Id like to keep things simpler,
and address it 1st, before bolting on more stuff.

(Um. dumbass cant count, so to prevent 'missing patch' feedback,
is just sending the sysfs-gpio patch as 20th patch :-/, please be gentle)


The driver-split

The Geode CPU and the PC-87366 Super-IO chip have GPIO units which
share a common pin-architecture (same pin features, with same bits
controlling), but with different addressing mechanics and port
organizations.

The vintage driver expresses the pin capabilities with pin-mode
commands [OoPpTt],etc that change the pin configurations, and since
the 2 chips share pin-arch, we can reuse the read(), write() commands,
once the implementation is suitably adjusted.


The patchset adds a vtable: struct nsc_gpio_ops, to abstract the
existing gpio operations, then adjusts fileops.write() code to invoke
operations via that vtable. Driver specific open()s set private_data
to the vtable so its available for use by write().

The vtable gets the gpio_dump() too, since its user-friendly, and
(could be construed as) part of the current device-file interface. To
support use of dev_dbg() in write() & _dump(), the vtable gets a dev
ptr too, set by both scx200 & pc8736x _gpio drivers.

heres how the pins are presented in syslog:

[ 1890.176223] scx200_gpio.0: io00: 0x0044 TS OD PUE EDGE LO DEBOUNCE
[ 1890.287223] scx200_gpio.0: io01: 0x0003 OE PP PUD EDGE LO

nsc_gpio.c: new file is new home of several file-ops methods, which
are modified to get their vtable from filp->private_data, and use it
where needed.

scx200_gpio.c: keeps some of its existing gpio routines, but now wires
them up via the vtable (they're invoked by nsc_gpio.c:nsc_gpio_write()
thru this vtable). A driver-spcific open() initializes
filp->private_data with the vtable.

Once the split is clean, and the scx200_gpio driver is working, we
copy and modify the function and variable names, and rework the
access-method bodies for the different addressing scheme.



Heres a working overview of the patchset:

# series file for GPIO

# Spring Cleaning
gpio-scx/patch.preclean # scripts/Lindent fixes, editor-ctrl comments

# API Modernization

gpio-scx/patch.api26 # what I learned from LDD3
gpio-scx/patch.platform-dev-2 # get pdev, support for dev_dbg()
gpio-scx/patch.unsigned-minor # fix to match std practice

# Debuggability

gpio-scx/patch.dump-diet # shrink gpio_dump()
gpio-scx/patch.viewpins # add new 'command' to call dump()
gpio-scx/patch.init-refactor # pull shadow-register init to sub

# Access-Abstraction (add vtable)

gpio-scx/patch.access-vtable # introduce nsg_gpio_ops vtable, w dump
gpio-scx/patch.vtable-calls # add & use the vtable in scx200_gpio
gpio-scx/patch.nscgpio-shell # add empty driver for common-fops

# move code under abstraction
gpio-scx/patch.migrate-fops # move file-ops methods from scx200_gpio
gpio-scx/patch.common-dump # mv scx200.c:scx200_gpio_dump() to nsc_gpio.c
gpio-scx/patch.add-pc8736x-gpio # add new driver, like old, w chip adapt
# gpio-scx/patch.add-DEBUG # enable all dev_dbg()s

# Cleanups

# finish printk -> dev_dbg() etc
gpio-scx/patch.pdev-pc8736x # new drvr needs pdev too,
gpio-scx/patch.devdbg-nscgpio # add device to 'vtable', use in dev_dbg()

# gpio-scx/patch.pin-config-view # another 'c' 'command'
# gpio-scx/quiet-getset # take out excess dbg stuff (pretty quiet now)
gpio-scx/patch.shadow-current # imitate scx200_gpio's shadow regs in pc87*

# post KMentors-post patches ..

gpio-scx/patch.mutexes # use mutexes for config-locks
gpio-scx/patch.viewpins-values # extend dump to obsolete separate 'c' cmd

gpio-scx/patch.kconfig # add stuff for kbuild

# TBC
# combine api26 with pdev, which is just one step.
# merge c&v commands to single do-all-fn
# delay viewpins, dump-diet should also un-ifdef it too.

diff.sys-gpio-rollup-1



Signed-off-by: Jim Cromie <jim.cromie@xxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] atmel_serial: update the powersave handler to match serial core
    ... I think that a driver can do the request to a the gpio layer (may can be implemented ... pin change interrupt. ... For waking up, we need to switch on the main oscillator, wait until it ...
    (Linux-Kernel)
  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... For OMAP, those names can map one-to-one to integers. ... So the "gpio number" in AT91 would, as it turns out, also encode the line number in the lower 6 bits, and the controller number in the bits above that. ... Perhaps yet another reason why the gpio_request function might want to look at the hardware state--- so that drivers that aren't using the new API are still known to the GPIO resource manager by virtue of the signature they leave behind in the hardware configuration (you might not be able to detect that they're using a GPIO line, but you would be able to detect that a pin had been assigned to a non-GPIO function). ... HOW that is established is indeed explicitly left out of the driver itself, but it's awfully nice when there's a facility somewhere that can do it on the driver's behalf. ...
    (Linux-Kernel)
  • [PATCH v3] Add GPIO-based MMC/SD driver
    ... MMC/SD cards can be used on a GPIO based bus by bitbanging ... This driver provides a configfs interface to dynamically create ... The sysfs interface has been replaced by a configfs interface. ... * Driver an MMC/SD card on a bitbanging GPIO SPI bus. ...
    (Linux-Kernel)
  • Re: [patch/rfc 2/4] pcf857x I2C GPIO expander driver
    ... Since it's a new-style driver, these devices must be configured as ... with legacy drivers for these chips easier. ... The driver exposes the GPIO signals using the platform-neutral GPIO ... * GNU General Public License for more details. ...
    (Linux-Kernel)
  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... driver can can talk to the attached external hardware. ... Updating the GPIO controller is always done in terms ... of a number mapping to some controller and a bit number, ... drivers never care about pins. ...
    (Linux-Kernel)