Re: Pin multiplexing on the cheap

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

On 31 Mar, 2014, at 21:37 , Matt Thomas <matt%3am-software.com@localhost> wrote:
> On Mar 31, 2014, at 6:48 PM, Dennis Ferguson 
> <dennis.c.ferguson%gmail.com@localhost> wrote:
> 
>> 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.
> 
> I think you might want to look at what I did for the allwinner.

Matt,

I think there are two models for pin configuration.  One model is
that you tell each device which pins it should use for its signals
in configuration, have the device driver ask for the signals to be
connected to those pins, and not have devices in the configuration
which can't be connected to pins.  The other is that you add devices
to the kernel configuration without telling them which which pins
to use, configure the pins separately either at run time, at boot
time (via a u-boot script?) or in the kernel configuration, and
then have the device driver look at run time to see if the signals
it needs have been connected to pins.  If they have been connected the
device uses those pins, otherwise the device fails to work.  The
first model demands that you know which pins a device will use before
you even put it in the kernel configuration, the second lets you put
any devices you want in the kernel configuration by separating that
from pin configuration.

What I want to be able to do is be able to have nearly every device we
have a driver for configured into a board's generic kernel configuration
file, so that if you want to use some subset of those devices you don't
have to compile a new kernel to do it.  Part of the reason for this is
that for application development it is convenient to just be able to
take the standard kernel for the platform and use that, rather than
having to figure out how to compile a kernel with the peripherals you
need before you can do anything else.  Another part of the reason for
this is that if you write a driver which isn't included in the default
kernel which gets made during standard builds then that driver will bit
rot as things are changed and the driver is forgotten about because the
standard compilation didn't fail in the driver's code.  Note that I'm
not opposed to compiling custom kernels if you want to prune out the
drivers you aren't using and maybe hardwire configuration you've been
doing by hand, and I accept that there might be some drivers that can't
be accomodated in the generic kernel (say an lcd driver that you want to
be used for the console), but for the most part if a device and its driver
exists it should go into the generic kernel for the board.  The second
model above allows this but the first model explicitly precludes this
since, for TI processors at least, there is no one pin arrangement which
would allow you to put all possible devices in the generic kernel.

Note that I'm assuming something else about this which I should probably
make explicit.  Right now all pin multiplexing stuff is done at device
attach time, which makes a sysctl interface less than useful because
the attaches are already done before you can use this.  It is the case
that some devices, say bus devices which might have children or things
that are used without an explicit open and close, must continue to
do this at attach time.  For devices which are only put to use between
a first open and last close, however, what I'm assuming is that they can
unconditionally attach themselves but call back to the machine-dependent
part of the driver at first open to examine the pin configuration and
reserve it, with another call back at last close to free the pins again
(the same call back could be used if you wanted to gate the device core's
clock off when it's not in use to save power; the com driver has an
appropriate callback already).  This means that while "attach" devices
reserve their pins early, "open" devices only reserve them when the device
is open.  For the latter you can use sysctl to rearrange pins before the
device is put to use, for the former you could maybe use drvctl to detach
something, sysctl to rearrange the pins and drvctl to attach something
else (though I know drvctl is a bit awkward and might not work), or you
could get u-boot to do the pin rearrangement for "attach" devices from a
boot script and reboot.

This gives you the following approach to developing something which uses
odd devices:

- Boot the generic kernel, use sysctl to get the devices you want configured
  to the pins you want (maybe with drvctl to do detaches/attaches).
  Rearrange as necessary.

- Preserve this across reboots by copying the sysctl stuff you typed for
  "open" devices to be done from rc, while maybe torquing the u-boot script
  to do pin rearrangement for "attach" devices.

- Once you are happy compile a custom kernel for the applications with the
  devices you aren't using compiled out and the pin configuration you
  arrived at hardwired in.

Your way seems to demand that you start at the last step, adding drivers
that aren't in the generic configuration rather than subtracting the
drivers you don't need, and compiling a kernel before you can even start
to play.  I think my way is better, and avoids the maintenance problem of
not having a fairly complete set of all drivers for the platform regularly
compiled.

Dennis Ferguson