-
Notifications
You must be signed in to change notification settings - Fork 165
sysfs-gpio: support ATSAM CPUs unconventional gpio naming #370
Comments
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:
Are |
I can't find anything yet to trigger the
/sys/kernel/debug/gpio has some clues:
|
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 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:
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. |
It's been four years, so the code should simply switch to /sys/bus/gpiochipN. |
What kind of new feature are you looking for?
Do you plan to:
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!
The text was updated successfully, but these errors were encountered: