[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40905280747l2b1c36b9q2d99d145d05dba@mail.gmail.com>
Date: Thu, 28 May 2009 08:47:13 -0600
From: Grant Likely <grant.likely@...retlab.ca>
To: Ben Dooks <ben-linux@...ff.org>
Cc: Jon Smirl <jonsmirl@...il.com>,
Scott Wood <scottwood@...escale.com>,
Russell King <rmk+lkml@....linux.org.uk>,
Peter Korsgaard <jacmet@...site.dk>,
Robert Schwebel <r.schwebel@...gutronix.de>,
devicetree-discuss <devicetree-discuss@...abs.org>,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.arm.linux.org.uk,
Janboe Ye <yuan-bo.ye@...orola.com>,
Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
On Thu, May 28, 2009 at 8:17 AM, Ben Dooks <ben-linux@...ff.org> wrote:
> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
>> On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@...escale.com> 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.
>> >
>> > But to restate, having external glue to create platform devices from the
>> > device tree is fine if that's what you want to do. We used to do that, but
>> > it was a pain compared to keeping everything in one place. Your experience
>> > may differ.
>>
>> Could 'struct platform_device' and 'struct of_platform_device" be
>> unified into a single structure? It's personal preference whether the
>> internal representation of the hardware is done via a device tree or
>> snippets of platform code, but do we need to have to different device
>> types?
>
> I was wondering what the pros/cons of having a system that takes a
> device tree and manufactures platform devices / etc from it? I think
> one of the cons is that if you change the platform device data, then
> you have not only the board definitions to change, but the of->platform
> code to modify as well...
Yes, this is the long term goal. And not just platform devices
either, i2c, spi, mdio, etc. The current problem is that there still
needs to be a per-driver mechanism to translate device tree data into
the correct pdata structure. That code is not hard, but it is
undetermined what is best for where that code should live and how it
should be triggered.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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