Re: device tree for arm soc ?

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

On Sat, Sep 21, 2013 at 01:25:19PM -0700, Matt Thomas wrote:
> 
> On Sep 21, 2013, at 12:05 PM, Manuel Bouyer 
> <bouyer%antioche.eu.org@localhost> wrote:
> 
> > Hello,
> > with arm SoCs (and this probably applies to other SoCs as well), we have to
> > setup I/O pins. The difficulty being that a I/O pin can be multiplexed
> > to several different peripherals. Additionnally a peripheral function
> > can be routed to different pins. For example, on a AM3359,
> > pin E18 can be configured to be either eCAP0_in_PWM0_out, uart3_txd,
> > spi1_cs1 pr1_ecap0_ecap_capin_apwm_0, spi1_sclk, mmc0_sdwp,
> > xdma_event_intr2 or gpio0_7.
> > On the other hand, uart3_txd can be configured to be routed to E18,
> > N16 or G18. So enabling a peripheral is not enough to get it working,
> > we have to choose to which I/O pins its signal will be routed. And this is
> > at minimum board-dependant (but in the general case it's application
> > dependant: where you want uart3_txd depends on how you wired the cape
> > you plug on top of your beaglebone :)
> > 
> > Right now we don't have a good way to deal with this; sitara_cm.c and
> > am335x_cm_padconf.c is a start for a driver to request a pin when it needs 
> > one,
> > but the pins are hardcoded in the driver at this time (look at ti_iic.c).
> > I can't think of a good way to specify this in a kernel config file;
> > in addition we probably want something more dynamic. Providing the
> > information from userland after boot is probably not good enough, because 
> > you
> > want to configure some peripheral and associated I/O pins before mounting 
> > root
> > (for the mass storage or network controller, or the console).
> > 
> > Linux solved this by providing a device tree at boot time, which describe
> > the hardware including the device to I/O ping associations.
> > The device tree file is loaded at the same time as the kernel by the
> > boot loader. FreeBSD has also gone this route. Of course they're not
> > using the same DT ...
> > 
> > Before I start looking deeper at this, does anyone has comments,
> > objections, etc ... ?
> 
> 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.

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