Re: device tree for arm soc ?

[Matt Thomas <matt%3am-software.com@localhost>]

On Sep 21, 2013, at 6:40 PM, Dennis Ferguson 
<dennis.c.ferguson%gmail.com@localhost> wrote:

> I strongly agree that having device drivers ask for the pins they
> want doesn't work.  It isn't possible for a device driver to know
> which of the multiple choices it has will interfere with the
> configuration of another device that the user needs to work, so
> the only way to end up with the configuration you want is good
> luck.  The pins are the scarce resource, so the way it needs to
> work is that the user designs what pins get connected to what and
> the devices look at what the user has configured to see if their
> pins are connected.  If their pins are connected the devices work,
> otherwise the devices don't.

Note that in the allwinner, cf_flags is used select the pins used.
So that isn't in the device drivers but in the configuration file
where it belongs.  I'll probably change it to use another locator
to specify which pinset to use.

> I don't think this is inherently a boot time autoconfiguration
> problem, however, even if treating it as that is a method to solve
> the issue. My quick hack to solve my own problems with this was a
> driver to expose the raw pin mux configuration to sysctl, so I can
> boot the board and then fiddle with the pin connections.  All the device
> drivers in the kernel autoconfigure (I wouldn't expect, say, conventional
> tty drivers to fail to autoconfigure just because nothing is currently
> plugged into the port, either), but only the ones currently connected
> to something actually work.  If you change the pin configuration you
> can make different devices work, there's no need to reboot.  I don't
> consider this particular thing a working solution to anything since it
> turns out devices whose pins aren't connected can behave badly if you
> open them by mistake, but there are other possibilities.  Device drivers
> could be informed when their pin configuration changes, or a pin
> reconfiguration could be treated like a hot swap, with the lucky device
> being attached and the unlucky device being detached, or something.

It would be nice if we could "extend" gpio to do some of that.

My feeling is you might must using drvctl first, the pins become
free, reconfigure them, and then rescan for the new device.

> You are right this doesn't work for everything.  A few things need
> to be set right either out of the bootstrap or early in the kernel
> boot, and can't wait until the root device is mounted.  I think,
> however, that the number of such things is really quite small;
> if the bootstrap gets the console and the root device right what
> else is there?

Note that allwinner uses a file which controls the muxing of the
gpios.  Not that NetBSD uses it but ...

> In any case, I'm not suggesting an alternative, I'm really just pointing
> out that there is nothing obvious about fiddling with those pin connections
> which inherently requires a reboot and a rerun of the kernel autoconf.
> That's a way to do it, but it's a pretty big hammer for a not-so-big
> problem.  I also don't know much about FDTs, but it seems clear
> that must be a solution for a whole lot more than just getting the pin
> mux registers set right.  Is there some other reason to want that
> beyond this particular problem?

I really dislike the TI/omap method of treating each pad individuallys.
Instead I'd rather see them grouped by function (sdmmc0, spio2, etc).
and allocate by function/instance/pinset.