Inspired by the excellent overlay created by Bas Laarhoven for the
BeBoPr boards, I am reworking my PRU code for LinuxCNC and plan on
creating a "universal" device tree overlay.
The basic idea is to enable all of the expected useful SoC features
(GPIO, I2C, serial ports, timers, PRU direct I/O) and have control over
the function of each individual pin via sysfs entries. This should
allow things like using the Rx pin of a serial port for communications,
and the Tx pin of the same port for GPIO.
Questions:
* Is there any fundamental reason why this seems like it won't work or
is otherwise a bad idea?
* Has this been done already? It seems too useful for someone else not
to have implemented, and I'd rather not reinvent the wheel if it's
already out there.
Inspired by the excellent overlay created by Bas Laarhoven for the
BeBoPr boards, I am reworking my PRU code for LinuxCNC and plan on
creating a "universal" device tree overlay.
The basic idea is to enable all of the expected useful SoC features
(GPIO, I2C, serial ports, timers, PRU direct I/O) and have control over
the function of each individual pin via sysfs entries. This should
allow things like using the Rx pin of a serial port for communications,
and the Tx pin of the same port for GPIO.
Questions:
* Is there any fundamental reason why this seems like it won't work or
is otherwise a bad idea?
The SYSFS entries for such a thing are unlikely to land upstream. I like
the idea in that it simplifies the command-line user's experience and would
save me some work in creating a subset of such a driver to toggle between
gpio-keys and PWM that I need to write for Arduino Tre (because there is no
tolerance there for fighting device tree stuff). The fact that I can't see
it being upstreamed is the only fundamental reason I can see for it being a
bad idea. If we can come up with a bit of a generic "switch function"
interface with the device tree describing the functions to be switched
between, perhaps that can be resolved. Other than that, it just sounds like
a lot of work.
* Has this been done already? It seems too useful for someone else not
to have implemented, and I'd rather not reinvent the wheel if it's
already out there.
The old way of using omapmux kinda did this in that you could enable all
the peripherals and just switch the function of the pins. I'm not aware of
other generic approaches being implemented, but suggest you take it up on
the linux-omap list and perhaps even a broader list to see if someone is
already doing something like this. Probably best to spend a bit of time
writing up an RFC, but not so much time you get frustrated when it gets
shot down or you hear someone else is working on it.
I'm building my own Xenomai patched kernels already, so I'm not too
worried about this getting pulled upstream. It's just a collection of
device-tree entries that don't really need to be in the mainline kernel
anyway. It's sort of a "tinkerer's" took-kit, if you will, and might be
helpful in bringing up a new board but probably shouldn't be in the
"official" kernel. That said, having a somewhat thought out namespace
and usage convention could help make the idea more useful to others, and
maybe some _has_ done something similar already.
I'll craft up a bit of an RFC and see what the folks over on the OMAP
list think.