Re: device tree for arm soc ?

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

On 21 Sep, 2013, at 17:13 , Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
>> 
>> fdt is a pain and isn't always available.
> 
> I've worked with it for other projets, I find it manageable not so hard
> do understand. And, if we reuse the linux or freebsd formats, we'll have it
> already there for commonly available hardware.
> 
>> 
>> Look at the way I did this for cubie/allwinner.  
> 
> I think it's not flexible enough. 
> One example is a LCD display: the combinaison of output pins is more
> complex and I'm not sure you can list them all in the driver.
> In addition, you have extra properties to pass to the driver, like
> resolution and timing informations (I have a LCD cape for the beaglebone
> which doesn't provide EDID information - with a properly set up device tree
> I've been able to get it working with linux anyway without rebuilding the
> kernel).
> 
> Another example if the interraction of the TPS65217 power controller with the
> SoC: it's connected via a I2C bus, but also has an ouput connected to a
> GPIO which has to be confifured as a ADC input. It's easy to describe with
> a FDT, but not with our kernel config file.
> 
> So maybe a FDT is not the best format to describe the hardware but I'm sure
> that kernel config flags with ad-hoc descriptions in the drivers attachements
> is not the way to go. We need something more flexible for this kind of
> hardware. On other major platforms kernel autoconf is driven by an
> external platform description (usually provided by boot firmware).
> These SoC don't provide one but it doesn't mean we shouldn't build one
> for them.

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.

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.

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?

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?

Dennis Ferguson