[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090528044732.GK1464@yookeroo.seuss>
Date: Thu, 28 May 2009 14:47:32 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: David Miller <davem@...emloft.net>
Cc: linux@....linux.org.uk, jonsmirl@...il.com,
devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
timur@...escale.com, scottwood@...escale.com,
yuan-bo.ye@...orola.com, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
On Wed, May 27, 2009 at 09:27:30PM -0700, David Miller wrote:
> From: David Gibson <david@...son.dropbear.id.au>
> Date: Thu, 28 May 2009 12:52:58 +1000
>
> > The of_platform bus model is conceptually completely broken, but in
> > practice only slightly broken for all common cases.
>
> The fact that every single SBUS and EBUS driver for sparc is now an
> of_platform driver, and the fact that as a further result joint
> SBUS/PCI drivers are now almost completely unified, speaks volumes to
> the fact that it is not broken.
Only because the set of busses that need to be probed using devtree
information has a very large overlap with the set of busses that are
specific to OF aware platforms.
The conceptual problem becomes apparent when you consider things like
i2c. The devtree is the obvious source to discover what i2c device
are present, but they need to be instantiated as i2c devices on the
i2c bus, not of platform devices.
The of_platform bus and the platform bus are just different
implementations of a "dumb" bus (roughly: single address space mapped
somewhere into MMIO, no introspection), the "of" variant being more
convenient for devtree based probing. There's no inherent reason they
can't be merged, only a whole bunch of little fiddly reasons.
--
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@...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