[lkml]   [2009]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH] Device Tree on ARM platform
    On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
    > On Wed, May 27, 2009 at 1:39 PM, Jean-Christophe PLAGNIOL-VILLARD
    > <> wrote:
    > > On 20:21 Wed 27 May     , Russell King - ARM Linux 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 <> 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?
    > >>
    > >> That's a damned good question - platform devices have been around since
    > >> the dawn of the device model, so the real question which needs to be
    > >> asked is: what was the reason that of_platform_device created rather
    > >> than unifying it with the already provided platform_device ?
    > > I agree at 100%
    > >
    > > when you have to support the same driver for non OF and OF platform it's
    > > really a pain in the ass
    > There are two issues that keep the of_platform and platform busses
    > separate. They aren't show stoppers, but they reflect the current
    > state.
    > 1) Source of data: a platform_device carries a pdata structure with it
    > to describe the hardware. An of_device carries a device_node pointer.
    > Before dropping of_platform bus, a mechanism needs to be in place to
    > add hooks for translating the device tree data into a pdata structure
    > for each platform device.
    > 2) Driver binding mechanism: device tree nodes usually have a
    > "compatible" property which is a list of strings. The first string
    > describes exactly what the device is (ie. "atmel,24c08") and an
    > optional list of other devices which it is register interface
    > backwards compatible with. The intent is that newer devices can claim
    > compatibility with older ones so that existing device drivers will
    > work without needing to be told the new device name. However, it
    > leaves the option when a device errata or something similar raises
    > it's ugly head, a driver can still get information about the exact
    > device name and apply the appropriate workarounds. Driver probing
    > should walk the list and give preference to higher priority compatible
    > values. of_platform bus does this, but I cannot think of a clean way
    > to do the same thing with the platform bus.
    > One option that has been suggested (more than once) is to make the
    > adapter code an of_platform_driver which translates the device tree
    > data and then registers the appropriate platform_devices. This neatly
    > solves the problem, but I don't like the overhead involved in
    > registering 2 struct devices with the kernel for every device node in
    > the device tree.

    Surely the code could simply run at init time, throwing away the data
    and code it doesn't need once it is done?


    Q: What's a light-year?
    A: One-third less calories than a regular year.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-05-28 16:25    [W:0.030 / U:37.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site