device tree for arm soc ?

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

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

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