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
    > I'm still uncertain whether that's actually a true statement.  For some
    > cases, of course it's true, but I have a nasty suspicion that we have
    > corner cases where OF won't cope well with.
    >
    > As I see it, if we were to convert to OF, we're boxing ourselves in to
    > a corner that would be extremely difficult to get out of. We would
    > never be able to step back from OF. Lets take an example. If we were
    > to convert PXA to OF including all the PXA SoC drivers, and a board
    > configuration came along which required hacks to a driver. Later on
    > we find that most platform authors are applying similar hacks because
    > their hardware is subtly different but those differences can't be
    > expressed via OF. At this point, what do we do? We can't say "well,
    > OF doesn't work well on this platform, we want to get rid of it" that
    > would be extremely difficult to impossible to do.

    I understand your concern. However, I yet have to encounter a case where
    the device-tree mechanism doesn't allow to convey the necessary
    informations. From my experience, it's always been superior in that area
    to any other mechanism we came up with.

    However, it's hard to give a final judgment without actual examples. But
    I see you are providing one below, let's see...

    > For example, how would an IrDA transceiver be expressed in OF?
    >
    > Obviously it would have to start off with some sort of UART definition
    > for SIR, with a separate (and sometimes unrelated in terms of register
    > space and SoC pin configuration) FIR unit. Whether FIR is used or not
    > is platform specific. So far so good, I don't see a problem yet.

    Right. Well, there are various ways to approach this. One is to have the
    transceiver be a child of the UART but that doesn't necessarily work
    well in term of addressing and conveying the necessary register
    informations.

    However, it would be reasonably simple and not unheard of to instead for
    example stick a property in the UART node, for example "fir-transceiver"
    that contains a phandle (a phandle is a pointer to another node) that
    points to the node that represents the transceiver and has the necessary
    register mapping informations.

    We have that kind of cross-node relationships expressed in various ways
    for things like network interfaces where the PHY controller sits on a
    different part of the SoC for example. It works reasonably well.

    > We then have one or two GPIOs doing some function - eg, one GPIO might
    > be a simple power on/off while the other controls FIR or SIR mode in
    > the transceiver itself. Or the two lines might be a bit combination
    > which selects 'off', 'on + sir', 'on + fir' modes depending on the
    > transceiver used. In the case of one GPIO it might be the mode select
    > or it might be the power control.

    One approach is to have the FIR node contain a property called
    "power-gpio" pointing to the GPIO node for the power GPIO etc...

    It's only one way.

    If the stuff gets too tricky due to multi-usage or multiplexing of the
    said GPIO, you could have instead a node for a "pseudo device" that
    would be fir-power-control or whatever else that contains some
    information and that the platform uses to provide a callback to the FIR
    drivers.

    The device-tree doesn't corner yet there. A given device binding might
    define the basics for devices of that type, but I yet have to see a case
    where you cannot express dependencies reasonably well in the
    device-tree.

    One thing to keep in mind is that the "tree" doesn't mean that there is
    one strict hierarchy of devices. The "main" hierarchy of the device-tree
    is generally chosen based on addressing capabilities to convey register
    address translations.

    But you can cross that via node pointers easily and provide alternate
    hierarchies within the tree. It's commonly use for interrupt routing for
    example where devices can have an "interrupt-parent" property that
    points to the PIC they are attached to (or to a node that convert
    interrupt domains when that makes more sense, called an interrupt map,
    this is commonly used for PCI). By default, if you don't provide such an
    explicit parent, the tree parent is considered as the interrupt parent
    (and may itself contain an interrupt-parent property that points to the
    PIC for all its children).

    The possibilities are almost endless. When you hit a real corner case,
    you can always create some kind of pseudo device that is backed by
    actual C code to resolve the situation in the kernel, or some kind of
    'power-method' property that you can use to lookup a table of platform
    provided methods. That's just ideas...

    One thing I agree with is that it takes some time to get familiar with
    the various ways the device tree can be used and thus use it
    efficiently. As I said earlier, it's a tool, it's very powerful but can
    be misused like any tool. I believe a good approach for ARM isn't to
    convert altogether to a device-tree based approach that requires all
    platforms to use it, but to start providing the infrastructure for
    platforms to "opt-in" and see how it goes from there.

    And you always still have the choice of hard wiring something in the
    platform code if you really want to :-)

    > I suspect this can be expressed by having some sort of OF table specifying
    > several gpios & their value for each combination of power & mode...
    > except some platforms have special control registers in FPGAs which do
    > not appear as GPIOs... so how are those expressed? We have function
    > pointers back into platform code to cope with this at present.

    You can still do something like that. I don't think the tree limits
    your ability to do that sort of thing.

    > Another example - LCD displays. Some platforms need a certain sequence
    > of GPIO activations with delays between when powering up and down the
    > LCD display. Currently we express this in the platform support file and
    > pass a function pointer into the LCD Driver. Can this be expressed with
    > OF?

    The tree itself wouldn't contain a function pointer no. There are
    several approaches here. If what you are trying to express can
    reasonably well be done via some kind of table of values & delays, you
    can define a property format that contains that to stick into the LCD
    node.

    A more flexible approach may be to have a "power-method" property as I
    proposed above. You can then create some kind of mechanism to export
    various such methods based on their name that the platforms can provide
    or that can be in separate files and have the driver lookup the right
    one using the property in the LCD node.

    Apple tried to do some ACPI-ish kind of "scripts" in the device-tree
    where they actually stick tokenized kinds of sequences of things which
    themselves are method calls to other drivers and pseudo-instructions all
    in one property.

    This is a possibility, and we do have an interpreter for that stuff in
    the kernel, but I find it gross and over-engineered myself at least the
    way it was done. But if we feel it's worth doing something like that
    cleanly, then why not ?

    > Another example - backlights. Some platforms need to twiddle a GPIO
    > at a certain point in the brightness scale and reset the PWM, and they
    > currently do this via an (optional) function pointer in the generic PWM
    > backlight driver. Can this be expressed with OF?

    Similar to the above, there are ways to express things, but to a certain
    extent, when things gets too tricky, C code might be the best approach,
    however nothing prevents you from having a mechanism to name those
    methods and register the callbacks and use that. Or keep your old way.

    I think at this stage, it's really a matter of trying it out on a few
    platforms and see how it goes.

    I don't pretend it's going to magically solve everything or make
    everything nicer. But it has the potential of solving many things and
    making many things nicer.

    > That's just a few examples of areas where we haven't been able to describe
    > platforms using pure data-based descriptions, and they're all things that
    > we don't want to stuff into the individual drivers (doing so involves lots
    > of ifdefs and namespace pollution - we saw that in 2.4 kernels.)

    Yup, I understand this problem well, it's what Apple tried to solve in
    the example above, and what ACPI tries to solve with AML, and while we
    -could- try to define some kind of scripted mechanism, I'm not sure its
    worth the challenge and we may as well go back to actual C code for
    those special cases. But I don't think having a device-tree makes that
    problem any worse than it is, ie, existing solutions would still work.
    It has even the potential of making it a bit cleaner to separate the
    magic handlers and access them by names.

    Now, if we want to go crazy, we can look into the full OF rather than
    just the device-tree, ie, bring in the tokenized F-code interpreter in,
    and express things as F-code methods :-) but that might be overkill, at
    least I believe it is for most our embedded cases on powerpc.

    > In order for me to be convinced that OF is not going to cause us grief,
    > I'd like to see a range of platforms converted to OF to check that we're
    > not going to find any unexpected problems - eg, a load of PXA platforms,
    > particularly those with the above kinds of problems.

    I think we need to distinguish using the OF-style device-tree, which is
    I think what this thread initially is about, from using a full blown OF
    as a firmware, and potentially trying to either keep it alive along with
    the kernel to be able to call into it (which is possible but hard) or
    bring in an f-code interpreter into the kernel.

    The former is mostly what I advocate for now for embedded. The later is
    something interesting to explore I suppose but not on my personal agenda
    right now.

    > And no, Dave Miller saying "I've been using this for 15 years on Sparc"
    > "Three architectures are using it" isn't going to convince me. The proof
    > is in the code, not the waffle.

    Well, sparc has the advantage of having a full OF implementation from
    day one with people who have been smart enough to provide reasonably
    good representations of things in their device-trees. Also, sparc
    doesn't have to deal with some of the intricacies of the embedded world
    (same deal with ppc64) so I tend to agree here that the situation isn't
    that clear cut.

    However, it's probably worth giving it a go.

    Cheers,
    Ben.




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