sysfs-gpio: support ATSAM CPUs unconventional gpio naming
cbrake opened this issue · 8 comments
What kind of new feature are you looking for?
- Hardware: ATSAMA5Dxx
Do you plan to:
- contribute an initial driver in experimental: Yes
- do all the work needed to get the driver promoted to _stable_¹: hopefully some day
Hi, I'm trying to get periph.io working on the ATSAMA5D27. The gpio naming for this cpu is somewhat non-standard in that in /sys/class/gpio it uses names like "PA3", "PD25" instead of "gpio121". This causes the host/sysfs/gpio driver not to find any of the GPIO.
So, I forked the host/sysfs/gpio driver to host/atsam/gpio and got it to work. Currently the code is very rough (but at least WaitForEdge is working).
Does anyone have any thoughts how support for this chip should be implemented? Could sysfs/gpio be made more general, or is simply forking the sysfs/gpio code the right path?
My experimental code is here:
https://github.com/cbrake/periph/tree/master/host/atsam
(needs a lot of cleanup)
Thanks!
Will take a look later today. Preferably I'd make sysfs-gpio more generic as needed. allwinner also has gpio groups, but the gpio exposed in sysfs are still numbered.
Observations:
- According to http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf page 18-35, there's 4 groups (PA to PD), each with 32 pins, for a total for 128 gpios (as advertised). As I noted above, this grouping is similar to Allwinner's CPUs.
- If you want you could create a
atsama5d2xpackage that would do the mapping, but unless you plan about memory mapped GPIO, I don't think it's worth the trouble. - So I'd make sysfs-gpio handle non-number pins properly upstream.
- Do not use GPIOnn as the pin name here, since it's not applicable. This is fine.
Are gpiochip* exported? It here any hint in there to guide that Pxnn form should be used instead of gpionn ? If so we could leverage this. If not, I'm fine with a one-off probing for this format.
I can't find anything yet to trigger the Pxnn form. There is only one gpiochip entry that has a count of 128:
root@sama5d27-som1-ek-sd:/sys/class/gpio# ls
PB11 PB2 PD25 export gpiochip0 unexport
root@sama5d27-som1-ek-sd:/sys/class/gpio# cat gpiochip0/base
0
root@sama5d27-som1-ek-sd:/sys/class/gpio# cat gpiochip0/ngpio
128
root@sama5d27-som1-ek-sd:/sys/class/gpio#
/sys/kernel/debug/gpio has some clues:
root@sama5d27-som1-ek-sd:/sys/class/gpio# cat /sys/kernel/debug/gpio |more
gpiochip0: GPIOs 0-127, parent: platform/fc038000.pinctrl, fc038000.pinctrl:
gpio-0 (PA0 )
gpio-1 (PA1 )
gpio-2 (PA2 )
gpio-3 (PA3 )
gpio-4 (PA4 )
gpio-5 (PA5 )
gpio-6 (PA6 )
gpio-7 (PA7 )
gpio-8 (PA8 )
gpio-9 (PA9 )
gpio-10 (PA10 |red ) out lo
gpio-11 (PA11 )
gpio-12 (PA12 )
gpio-13 (PA13 )
gpio-14 (PA14 )
gpio-15 (PA15 )
gpio-16 (PA16 )
gpio-17 (PA17 )
gpio-18 (PA18 )
gpio-19 (PA19 )
gpio-20 (PA20 )
gpio-21 (PA21 )
gpio-22 (PA22 )
gpio-23 (PA23 )
gpio-24 (PA24 )
gpio-25 (PA25 )
gpio-26 (PA26 )
gpio-27 (PA27 |atmel,vbus ) out hi
gpio-28 (PA28 )
gpio-29 (PA29 |USER ) in hi
gpio-30 (PA30 )
gpio-31 (PA31 |blue ) out lo
gpio-32 (PB0 )
gpio-33 (PB1 |green ) out lo
gpio-34 (PB2 |sysfs ) out lo
where would you put the one-off probing?
Thanks for the infos. I looked at acquiring a dev board but it's not cheap.
I'm fine with a "hack" here to try a second time with Pxnn (with x:='A'+(n/32); n:=n%32 when gpionn is not found, and document accordingly.
What's the kernel version of the system? Because another option would be to only support the new gpio API; I filed #371 for this, it's "work" but it seems feasible without user visible change, at least at first glance, but it would require a 4.8+ kernel.
Kernel version is:
Linux version 4.14.73-linux4sam_6.0
I'll look into the gpio API to see if there is any information that can be gleaned there.
Ok then if supporting older kernels is irrelevant, it could be a non-hacky permanent solution.