lkml.org 
[lkml]   [2012]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
    From
    Date
    Hi Grant,

    On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:

    > On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
    > <panto@antoniou-consulting.com> wrote:
    >> On Nov 6, 2012, at 12:14 PM, Grant Likely wrote:
    >>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
    >>> <panto@antoniou-consulting.com> wrote:
    >>>> For hot-plugging, you need it. Whether kernel code can deal with
    >>>> large parts of the DT going away... How about we use the dead
    >>>> properties method and move/tag the removed modes as such, and not
    >>>> really remove them.
    >>>
    >>> Nodes already use krefs, and I'm thinking about making them kobjects
    >>> so that they appear in sysfs and we'll have some tools to figure out
    >>> when reference counts don't get decremented properly.
    >>>
    >>
    >> From the little I've looked in the of code, and the drivers, it's going
    >> to be pretty bad. I don't think all users take references properly, and
    >> we have a big global lock for accessing the DT.
    >
    > I'm a lot more optimistic on this front... I wrote a patch today to
    > make the change and took some measurements:
    >
    > On the versatile express qemu model I measured the free memory with
    > /proc/device-tree, with /sys/device-tree, and with both. Here's what I
    > found:
    >
    > /proc/device-tree only: 114776kB free
    > /sys/device-tree only: 114792kB free
    > both enabled: 114716kB free
    >
    > The back of a napkin calculation indicates that on this platform
    > /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy
    > to see that using /sys instead of /proc appears to be slightly cheaper
    > which makes it easier to justify the change. The diffstat makes me
    > even happier:
    >
    > arch/arm/plat-omap/Kconfig | 1 -
    > arch/powerpc/platforms/pseries/dlpar.c | 23 -----------
    > arch/powerpc/platforms/pseries/reconfig.c | 40 ------------------
    > drivers/of/Kconfig | 8 ----
    > drivers/of/base.c | 116
    > ++++++++++++++++++++++++++++------------------------
    > drivers/of/fdt.c | 5 ++-
    > fs/proc/Makefile | 1 -
    > fs/proc/proc_devtree.c | 13 +-----
    > fs/proc/root.c | 4 +-
    > include/linux/of.h | 35 ++++++++++++----
    > include/linux/proc_fs.h | 16 --------
    > include/linux/string.h | 11 +++++
    > 12 files changed, 107 insertions(+), 166 deletions(-)
    >

    Interesting. Not so bad then.

    > There are still a few odds and ends that need to be tidied up, but
    > I'll get it out for review shortly. I've not touched the sparc code
    > yet, and I need to take another look over the existing OF_DYNAMIC
    > code. I think that CONFIG_OF_DYNAMIC will probably go away and the add
    > node/property functions will get used by fdt.c and pdt.c for initial
    > construction of the device tree.

    CONFIG_OF_DYNAMIC never made sense to me. Glad to see the config option
    gone. I'm not totally up to date with the -next dt stuff, but if we're
    there can we rename all the prom_ functions to something saner?

    >
    >> Adding and removing nodes at runtime as part of the normal operation of
    >> the system (and not as something that happens once in a blue moon under
    >> controlled conditions) will uncover lots of bugs.
    >
    > I'm hoping so! Its time to clean that mess up. :-) Fortunately adding
    > nodes is not where we're going to have problems. The problems will be
    > on node removal. Addition-only at least means we can have something
    > useful before hunting down and squashing all the bugs.

    I'll admit that removing nodes is going to be quite rare at least for
    me use cases. I did come across a couple of people that do hot-plugging
    (using something completely different) that could use it for sure.

    >
    >> So let's think about locking too
    >
    > Yes, the locking does need to be sorted out.
    >

    Perhaps come up with a dt-stress test tool/boot time validator?

    > g.

    Regards

    -- Pantelis

    P.S. Lots of teeth grinding in the ELCE about the lack of a DT preprocessor.
    The pinctrl arguments have been mentioned more than once.




    \
     
     \ /
      Last update: 2012-11-07 09:41    [W:4.184 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site