Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 09:52:23PM +0100, Mark Brown wrote:
> On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
> > On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
> 
> > > I'm not talking about platform specific code, I'm talking about code to  
> > > retrieve information about a device from the device tree.  There would  
> > > not be separate instances of this for "platforms X, Y and Z", just one  
> > > of_platform binding in each driver.  It's no different than having a  
> > > platform bus binding, except in the data structures used.
> 
> > I really don't see what OF buys us then, apart from additional dependencies
> > that have to be correct for the kernel to work.  I can only see disadvantages
> > if all OF is, is a way to pass some file to the kernel to (effectively) tell
> > it which drivers to use.
> 
> The main selling points of the device tree AFAICT are that some
> platforms have to use it it anyway due to the native OS and firmware for
> the platform use it, the possibility of using the same device tree with
> more than one OS (modulo unrepresentable holes) and the fact that some
> people find it more convenient to use than straight data tables
> (personally I find the two approaches to be much of a muchness there).
> Perhaps I'm missing something, though?

The tree structure as opposed to plain data tables is not a trivial
difference.  It makes it much, much more convenient to describe
complex device layouts unambiguously than flat tables.  It's not
perfect but it's about three shit loads better than flat data tables
(powerpc embedded went through that stage too, on the way to device
trees and it sucked mightily).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/