GPIO driver

Phishfry

Phishfry

I started work on a GPIO driver and got it roughed in. Aiming for SCH3114 on Advantech boards.

Figures, I find this similar Nuvotron driver after I guessed my way through alot.

It is nice to see the proper way to proceed for review:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207405
So create bug report. File a patch. Find reviewers.
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-February/049136.html

Nice to see all the proper GPIO source directory locations too.
I had already somewhat figured it out but nice to see confirmation.

This also gives me a second GPIO device driver to bounce my work against.

Here is a video the author made. Showing his patch in action:
APU1C4 with GPIO's.

Very Good Job Daniel Wyatt, patch author
 
I thought I was going to make a driver for at least 5 Advantech boards/platforms but upon closer examination all 5 boards use a different base address's and register offsets for their GPIO. My dream of a unified driver blown to pieces. Might just end up with a separate driver for each just for personal usage. Maybe put up on github for each individual board/platform.

I might have to pick up Kongs book on FreeBSD devices drivers.
Is it still relevant?
I wonder if something like a gpio probe is not needed. Probe for known Super IO/GPIO chips and assign values from a chart..Dunno
I know a separate driver for each platform/motherboard is ridiculous and I understand why we don't have more x86/amd64 gpio platforms working..Even among one manufacturer 5 different implementations of the SCH3114 Super I/O chip.
Advantech has some good doc's but I did not pay attention to the base values until I started in earnest.
 
Phishfry said:
I thought I was going to make a driver for at least 5 Advantech boards/platforms but upon closer examination all 5 boards use a different base address's and register offsets for their GPIO.
Click to expand...

If the major differences are limited to base address and offsets, a single driver might still be the better way to go, with just a lookup table mapping model to parameters. I.e. if most of the code would / could be common between the different models. Alternatively a smaller number of drivers, if there are sane/logical groupings of the models by required behaviour.
 
I'm not familiar with all GPIOs, basically a general understanding, but in addition to what Murph suggests, maybe that your driver initialization can peek into memory looking for a fixed GPIO signature that it supports, and then test the newly discovered memory/register range if it's indeed a GPIO your driver should support.

If this is too big a step, the simpler development alternative is to create a configuration file that lists the base address of expected GPIOs, and their type so the driver knows which register set they each require.

Dominique.
 
Alot of GPIO's seem to attach to the base address of the Watchdog Timer as well.

How about the Jetway I have with an Intel N2930 SOC with GPIO lines directly to the CPU.
No more SuperIO chips with SOC i guess. I think think the Minnowboard uses the same arrangement.
 
Reason I mention the Watchdog is that Linux GPIO code reuses WDT routines to find the GPIOchip. The WDT routines have been around a while it appears.
 
Phishfry said:
Alot of GPIO's seem to attach to the base address of the Watchdog Timer as well.
Click to expand...

One of the many features of those chips is a watchdog timer, so no real surprise there. Adding various timers and the like to I/O chips has been quite common over the years. E.g. the 6522 VIA had a couple of handy general purpose timers in addition to its I/O ports.
 
Linux really excels at the device detection for GPIO chip yet its pin handling stinks. Export pin I understand the concept but what pin number? Subtract what from what?
At least with gpioctl -lv on FreeBSD you get a nice tidy list of pins with their states. Granted mapping software labels to actual pins is tough, but same thing on Linux when you export pin 252 there is no pin 252 labeled on the board. It's interpolated..

I really want to see gpioctl run on x86. I was thinking of messing with the Prolific PL2303HX usb-ttl adapter for 2 or 3 gpio pins. One thing at a time.
 
So I went ahead and bought an APU1D to try the GPIO driver out and it works well. After running the patch I loaded the module and bingo:

root@APU:~ # kldload nctgpio
root@APU:~ # gpioctl -lv
pin 00: 1 GPIO00<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 01: 1 GPIO01<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 02: 1 GPIO02<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 03: 1 GPIO03<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 04: 1 GPIO04<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 05: 1 GPIO05<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 06: 1 GPIO06<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 07: 1 GPIO07<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 08: 1 GPIO08<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 09: 1 GPIO09<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 10: 1 GPIO10<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 11: 1 GPIO11<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 12: 1 GPIO12<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 13: 1 GPIO13<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 14: 1 GPIO14<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
pin 15: 1 GPIO15<IN,OD>, caps:<IN,OUT,OD,PP,II,IO>
 
You must log in or register to reply here.
Back
Top