Re: device tree for arm soc ?

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

On Sat, Sep 21, 2013 at 06:51:39PM -0700, Matt Thomas wrote:
> 
> 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.

But it's still the device driver which asks for the mux change, based on
the cf_flags it gets.

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

I can't see how this would play with the cf_flags above. Or would it be a
different mechanism for boot time too ?

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

You'll have then function variants, which will do a lot of pin configuration
at the end (and we'll probably miss some, so the user will still have to
modify kernel sources at the end).
For example, on am335x, the UART can work in RS232 or IR mode, which makes
2 functions for RS232, with sighlty different pin sets.
But then you can use RS232 with or without hardware flow control, or in
single-direction mode. So you end up with the following functions for
RS232:
- RS232 full duplex with hardware flow control
- RS232 full duplex without hardware flow control,
- RS232 full duplex with RX hardware flow control only
- RS232 full duplex with TX hardware flow control only
- RS232 RX with hardware flow control
- RS232 RX without hardware flow control,
- RS232 TX with hardware flow control
- RS232 TX without hardware flow control,
- IR

If you look at the LCD controller, you'll also see that there is a wide
pannel of PAD usage, depending on the mode in use.

and we still need a way to provide informations other than PAD mux
configuration to drivers (again, look at the LCD controller, you'll
see that a kernel config file won't work here).

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