Re: device tree for arm soc ?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Sep 21, 2013 at 09:40:47PM -0400, Dennis Ferguson 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.
> 
> 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?

Even getting the console and root device right in the kernel config file
may be tricky. tty0 may have different pad configuration (it does on
the am335x, I didn't check allwinner). And I see no reason to not allow
the framebuffer and USB keyboard to be console (especially on
beaglebone black or cubieboard, where the serial port needs an adapter).

The same is true for the root device; you can have the root device on
different peripherals, each of them can have different pad configurations.

> 
> 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?

Yes, among others:
- you can pass arbitrary information to the kernel, like the EDID for
  the framebuffer driver. I've not investigated much other peripheral on the
  SoCs to know yet if other drivers would need more information than just PAD
  config, but I suspect there is.

- you can also relations between devices more complext than a single tree.
  For example, if you're luky enough to have a display which can provide EDID,
  you have to tell the framebuffer driver from which I2C bus it can get
  the EDID. (in beaglebone world, most VGA, DVI or HDMI capes and some LVDS
  capes connects a I2C to the display, which allows to query the EDID, but not
  all use the same I2C bus). I've also pointed out the TPS65217 driver,
  which needs to query one of the SoC ADC to provide some informations.
  Another example would be which DMA can a peripheral use (the SD/MMC driver
  could make use of a DMA, but it needs to decide which one of the multiple
  DMA to use). These are only examples; as you can connect your own
  electronic design to these SoCs, you can build more dependances
  between drivers.

- you can use the the FDT to drive the kernel autoconf, instead of
  having addresses hardwired in the kernel config. So you can use
  the same kernel on different SoC variants which have different peripherals,
  or peripherals at different addresses, by just providing a different
  fdt at boot time.

I agree that it is desierable to be able to change some of these properties
at run time, without requiring a reboot. Linux solves this by allowing to
load/unload FDT fragments at run time. I can't see why we couldn't to
the same. Loading a FDT fragment would cause drivers to attach, unloading
it would cause drivers to detach. In this case, the FDT loaded at boot
time would only contain devices needed to boot (console and root device),
other devices would be loaded later by extending the FDT.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--