Message-ID: <20090527162000.GM6805@pengutronix.de>
Date:	Wed, 27 May 2009 18:20:00 +0200
From:	Robert Schwebel <r.schwebel@...gutronix.de>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Timur Tabi <timur@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

Hi Grant,

On Wed, May 27, 2009 at 09:39:21AM -0600, Grant Likely wrote:
> This is a MPC5200 is the posterchild for device tree wreckage; mostly
> because of my own inexperience at the time.  A lot of mistakes were
> made and I freely admit that.
>
> However, my counter example is Xilinx Virtex support. The Virtex is an
> FPGA with all the devices instantiated in the FPGA fabric. It would
> be a nightmare to try and describe each different FPGA bitstream using
> hand coded platform devices, and the xparameters.h file exported by
> the Xilinx toolchain wasn't much better. Encoding the machine layout
> in a data structure (the device tree) has decoupled FPGA changes from
> the kernel image. Now FPGA engineers can make major changes to FPGA
> layouts without having to lockstep with changes in the kernel. I
> regularly boot a single kernel image on multiple bitstream images.
>
> That being said, the problems we have had are the reason why it is
> *not* recommended to hard link the device tree image into firmware.
> We do commit to not breaking old trees, but the ability to update is
> important; particularly for enabling new features/drivers.

Point taken.

We often have the situation that we have

- a SoC cpu from vendor A
- a module with the cpu+ram+peripherals from vendor B
- a baseboard from vendor C
- sometimes an extension board from vendor D

All that with non-introspectable busses, like chip select busses, SPI,
i2c, FPGA-internal busses etc. We recently tried to put oftree sniplets
into the devices (one into the module, one in the baseboard etc), let
u-boot collect these sniplets and build an oftree out of it. It doesn't
work. If you try this, you'll quickly find out that you would have to
put the schematics into the oftree. A peripheral pin can be routed to a
ball, goes from a connector of the module to a baseboard, to the
extension board, come back and go to another unit on the SoC. This
cannot be described in the oftree. At one place, you need to *know*
about the whole hardware that you have and have a single "we have X" to
"X's oftree" mapping.

In the end, having a single "X needs these platform data" kernel source
file is much, much cleaner and less error prone than what we currently
have with the oftree.

> > - The oftree layering is fundamentally broken. We already have a sane
> >  abstraction for arbitrary hardware in the kernel: platform devices.
> >  Why not instanciate platform devices from a generic oftree core?
>
> No; the oftree is a data structure. That is it, nothing more.

Unfortunately, it is an incomplete data structure regarding to what the
kernel needs.

> > - Platform data makes it possible to store function pointers. There
> >  is no equivalent to this concept in oftree-land.
>
> But there is concept of platform specific code. In the majority of
> cases platform specific function pointers aren't needed at all. In
> the cases where they are; platform devices can still be used.

In this case, they need an equivalent to a "machine number" information.

> > oftree could be a great tool if these things would be resolved.
> > Currently they are not, and in result, ARM just works and is easy,
> > whereas on PowerPC systems people often spend more time working on
> > binding stuff than on the actual functionality.
>
> That's a rather polarizing statement and I don't think its fair. The
> FDT is not a magic bullet. It makes aspects of platform independence,
> code sharing, and board porting simpler, but it is also requires
> forethought and has overhead associated with it. I don't think anyone
> is proposing to require all ARM platforms to use the FDT approach.

Sorry, it was not meant to be offending, it just reflects a certain
level of frustration.

Don't take me wrong: I consider the *idea* behind oftree a good one. It
just has unsolved problems. If we manage to turn this discussion into
something that accelerates things into a good direction, I'm all with
you.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists