lkml.org 
[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
    From
    Date
    On Thu, 2009-05-28 at 02:57 -0700, David Miller wrote:
    > From: Russell King - ARM Linux <linux@arm.linux.org.uk>
    > Date: Thu, 28 May 2009 10:15:13 +0100
    >
    > > For example, how would an IrDA transceiver be expressed in OF?
    >
    > As a child device node of the IRDA device, with associated
    > properties.
    >
    > You can express _ANYTHING_ using the OF device tree. It is
    > not even something to discuss, it's flexible enough.

    Well, that example is interesting because you may not want the
    transceiver to be a child of the UART :-) The tree hierachy is mostly
    about addressing, and addressing below a UART doesn't mean much.

    So if the transceiver has a bunch of MMIO registers, it might be better
    off located elsewhere, and have the UART have a "fir-transceiver"
    property with a phandle to the actual device...

    But yes, I definitely agree, it's flexible enough for a lot of that
    stuff. Where things get tricky is to express "methods" rather than just
    relationships. This is where x86 loses big time with ACPI, Apple lost
    with their platform functions in OF properties, and appart from having a
    real OF implementation under the hood that is kept alive along with the
    kernel to call in, the tree doesn't provide a simple solution.

    However, it doesn't either invalidate existing solutions based on
    function pointers into the platform code... it might even make it nicer
    by naming those functions into some kind of directory where they can be
    registered by the platform code and "named" by a property in the node,
    though I tend to prefer the approach of having a property with a phandle
    to a node that is a pseudo-device ("power-control") or so, which has its
    own driver providing the methods.

    The possibilities are endless. _BUT_ it does require some careful
    thinking to get things right. To that extent, I do agree with Russell
    that rather than a "violent" conversion, ARM should first try things out
    as an opt-in for a few platforms and see how it goes.

    Cheers,
    Ben.




    \
     
     \ /
      Last update: 2009-05-28 12:17    [W:7.400 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site