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 11:34 +0100, Russell King - ARM Linux wrote:
    > On Thu, May 28, 2009 at 08:11:33PM +1000, Benjamin Herrenschmidt wrote:
    > > 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...
    >
    > IrDA transceivers do not have MMIO registers. Transceivers are an IR
    > LED, an IR phototransitor andr receiver circuitry. They're typically
    > 9 pin devices with power, ground, transmit, receive and a bunch of
    > control signals.

    Right, I'm used to those transceivers. For some reason I read from your
    previous post that you had such a transceiver with registers. But it
    doesn't matter much, it's a valid example of how you can go "accross"
    the base hierarchy of the tree if needs be.

    In the case of a simple transciever like the ones controlled by GPIOs or
    via bit banging on flow control lines, yes, it would probably be a child
    of the UART node, eventually with properties describing which GPIOs
    (via phandles to GPIO nodes for example) are used to configure it.

    I think the -root- of the discussion at this stage is really the problem
    of providing those "methods" for power control, clock control, or other
    similar housekeeping things. I think the device-tree doesn't make things
    better or worse per se, and unless there's an actual live OF
    implementation underneath (in which case nodes do have methods you can
    call into via OF callbacks), then the device-tree doesn't provide an
    automatic way of solving that. But we can invent one :-)

    > The kind of reply I was hoping to get to my email was something more
    > along these lines - an informed view giving an idea how some of these
    > issues would be addressed with an OF device tree.
    >
    > I can see how the named functions/directory would work - that seems to
    > be relatively simple and straight forward.

    Right. It deviates a bit from the idea that the device-tree should be
    agnostic to the operating system and only represent the HW layout, but
    I'm no religious fanatic and I think it might be a very good compromise.

    In many case, sets of "standard" methods could be provided by the kernel
    that use properties in the target node as arguments. For example, things
    like "simple-enable-gpio" and "simple-reset-gpio" could be generically
    provided, using properties such as "enable-gpio" (phandle to a GPIO
    node), "enable-delay" (integer duration) etc... in the target node as
    "arguments". The platform can then register the more fancy onces it
    needs.

    > However, the pseudo-device approach I'm less clear about. With a separate
    > driver for the "power control" pseudo-device, how would you communicate
    > the state information down to that driver?

    It depends. It doesn't have to be "pseudo" actually... in the case of
    backlight, one could have a node for backlight control and a real driver
    binding to it that just does backlight control. The linkage between that
    and the main LCD driver, if necessary, can be done via phandle links in
    the tree, and recovering the driver from the node (a bit tricky but
    doable).

    > I am equating OF devices and drivers too much with the struct device and
    > struct driver model, which sounds like it's not the best thing to do with
    > OF.

    Well, it depends really. Mostly we -do- end up with a struct device for
    a node ... but it's not necessarily always true.

    Cheers,
    Ben.




    \
     
     \ /
      Last update: 2009-05-29 00:39    [W:0.047 / U:30.624 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site