Pin multiplexing on the cheap

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

I think there is considerable need to address the problem of pin
multiplexing on processors with a TI-style pin mux arrangement,
since it is currently quite difficult to use peripherals whose
pin assignments aren't being taken care of by u-boot.  While
device tree might be the current preferred way to do this it
requires a lot of work, some of it painful.  I was hence
wondering if there was interest in a cheaper-to-implement poor
man's way to do this.

A while ago I did a quick hack to deal with this on the Beaglebone,
essentially by exposing the pin mux register configuration to sysctl.
The interface is ugly as sin but it lets you look at the current pin
arrangement (which you can't do now) and change it around to your
liking with a tool that already exists.  This has a low implementation
cost, is probably quickly portable to other processors which do pin
multiplexing in the style of the AM335x (spend an hour or two
cutting and pasting the signal and pin names, and register offsets,
from the processor data sheet and awk'ing that into a .h file which
programs the rest of the code) and is effective at letting you get
what you need to do done both during development where you might want
to fiddle and once you arrive at a stable pin arrangement.  Its
major problem was that it was accident prone. I only did the sysctl
bit and thought I might get away without code in device drivers
to deal with it.  This meant that drivers would happily try to
operate without the signals they needed being connected, and that
sysctl boo-boos could disconnect signals that open devices were
relying on.  As it turns out very bad things can happen when the
signals a device needs connected aren't, it was fragile the way
it was.

I've since added logic to allow device drivers to determine if
the signals they need are attached to pins, to reserve these so
they can't be changed while the device is still using them, and to
keep one from doing things that the processor manual says you
shouldn't like attaching the same signal to two different pins.
I believe this should make the code reliable by preventing most
accidents.

Could this be added to the code base?  The pin multiplexing code
that is in there now doesn't seem to work since pin assignment
on these processors generally needs human input but that code
has no user interface (that I understand).  There certainly needs
to be something.  As was pointed out to me recently, while the BBB
has 6 near-identical UARTs for which we have a driver only one of
them (the console) can be configured since that is the only one
which has a fixed pin configuration that the bootstrap sets
up for you.  If you need another serial port it should be minimally
possible to pick one that can be mapped to a convenient set of pins,
do the pin configuration and use it, even when running the generic
kernel for the board.

Dennis Ferguson