From: Alan Tull <atull@altera.com> To: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Grant Likely <grant.likely@secretlab.ca>, Kevin Hilman <khilman@ti.com>, Matt Porter <mporter@ti.com>, Koen Kooi <koen@dominion.thruhere.net>, linux-kernel <linux-kernel@vger.kernel.org>, Felipe Balbi <balbi@ti.com>, Deepak Saxena <dsaxena@linaro.org>, Scott Wood <scottwood@freescale.com>, Russ Dill <Russ.Dill@ti.com>, <linux-omap@vger.kernel.org>, <devicetree-discuss@lists.ozlabs.org> Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Wed, 7 Nov 2012 09:33:21 -0600 [thread overview] Message-ID: <1352302401.4067.11.camel@atull-linux1> (raw) In-Reply-To: <B1277EA3-9284-4856-A7E8-1B1CA9D30327@antoniou-consulting.com> On Wed, 2012-11-07 at 09:06 +0100, Pantelis Antoniou wrote: > 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? > I'd be glad to see the dynamic stuff be integrated better than it currently is. Currently unflatten_dt_node assumes that the flattened tree will stay around and not be freed. So using it to unflatten dynamic nodes after boot is problematic if the nodes may be later removed. > > > >> 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. > We have been looking at an approach that would allow adding/deleting whole nodes under userspace direction. Such as a variation of the real-time video processing system example where the FPGA has some IP blocks that are dsp filters. The user could rearrange them from some userspace GUI without having to reboot. For that to work, device nodes that are removed really have to be freed or there's a memory leak. > > > >> 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. > > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss >
WARNING: multiple messages have this Message-ID (diff)
From: Alan Tull <atull@altera.com> To: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Grant Likely <grant.likely@secretlab.ca>, Kevin Hilman <khilman@ti.com>, Matt Porter <mporter@ti.com>, Koen Kooi <koen@dominion.thruhere.net>, linux-kernel <linux-kernel@vger.kernel.org>, Felipe Balbi <balbi@ti.com>, Deepak Saxena <dsaxena@linaro.org>, Scott Wood <scottwood@freescale.com>, Russ Dill <Russ.Dill@ti.com>, linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Wed, 7 Nov 2012 09:33:21 -0600 [thread overview] Message-ID: <1352302401.4067.11.camel@atull-linux1> (raw) In-Reply-To: <B1277EA3-9284-4856-A7E8-1B1CA9D30327@antoniou-consulting.com> On Wed, 2012-11-07 at 09:06 +0100, Pantelis Antoniou wrote: > 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? > I'd be glad to see the dynamic stuff be integrated better than it currently is. Currently unflatten_dt_node assumes that the flattened tree will stay around and not be freed. So using it to unflatten dynamic nodes after boot is problematic if the nodes may be later removed. > > > >> 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. > We have been looking at an approach that would allow adding/deleting whole nodes under userspace direction. Such as a variation of the real-time video processing system example where the FPGA has some IP blocks that are dsp filters. The user could rearrange them from some userspace GUI without having to reboot. For that to work, device nodes that are removed really have to be freed or there's a memory leak. > > > >> 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. > > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss >
next prev parent reply other threads:[~2012-11-07 15:36 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-05 20:40 [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Grant Likely 2012-11-05 21:40 ` Tabi Timur-B04825 2012-11-05 21:40 ` Tabi Timur-B04825 2012-11-05 23:22 ` Tony Lindgren 2012-11-05 23:22 ` Tony Lindgren 2012-11-09 12:06 ` Grant Likely 2012-11-09 12:06 ` Grant Likely 2012-11-06 0:07 ` Grant Likely 2012-11-06 0:07 ` Grant Likely 2012-11-06 10:31 ` Pantelis Antoniou 2012-11-06 10:31 ` Pantelis Antoniou 2012-11-07 22:35 ` Ryan Mallon 2012-11-07 22:35 ` Ryan Mallon 2012-11-08 13:28 ` Koen Kooi 2012-11-08 13:28 ` Koen Kooi 2012-11-08 14:09 ` Timur Tabi 2012-11-08 14:09 ` Timur Tabi 2012-11-08 17:00 ` Mitch Bradley 2012-11-08 17:00 ` Mitch Bradley 2012-11-06 10:30 ` Pantelis Antoniou 2012-11-06 11:14 ` Grant Likely 2012-11-06 18:35 ` Tony Lindgren 2012-11-06 19:29 ` Russ Dill 2012-11-06 19:41 ` Pantelis Antoniou 2012-11-06 19:41 ` Pantelis Antoniou 2012-11-06 22:17 ` Stephen Warren 2012-11-06 22:17 ` Stephen Warren 2012-11-06 19:34 ` Pantelis Antoniou 2012-11-06 20:45 ` Grant Likely 2012-11-06 20:50 ` Grant Likely 2012-11-07 8:06 ` Pantelis Antoniou 2012-11-07 15:33 ` Alan Tull [this message] 2012-11-07 15:33 ` Alan Tull 2012-11-09 17:03 ` Grant Likely 2012-11-07 8:13 ` Pantelis Antoniou 2012-11-07 10:19 ` Benoit Cousson 2012-11-07 10:19 ` Benoit Cousson 2012-11-07 11:02 ` Pantelis Antoniou 2012-11-07 11:02 ` Pantelis Antoniou 2012-11-07 11:12 ` Benoit Cousson 2012-11-07 11:12 ` Benoit Cousson 2012-11-07 11:23 ` Pantelis Antoniou 2012-11-07 11:23 ` Pantelis Antoniou 2012-11-09 20:33 ` Grant Likely 2012-11-12 11:34 ` Pantelis Antoniou 2012-11-12 13:01 ` Grant Likely 2012-11-07 17:25 ` Stephen Warren 2012-11-07 22:10 ` Pantelis Antoniou 2012-11-07 22:10 ` Pantelis Antoniou 2012-11-08 10:36 ` Cousson, Benoit 2012-11-08 10:36 ` Cousson, Benoit 2012-11-09 5:32 ` Joel A Fernandes 2012-11-09 14:29 ` David Gibson 2012-11-10 3:15 ` Joel A Fernandes 2012-11-09 21:22 ` Grant Likely 2012-11-12 11:47 ` Pantelis Antoniou 2012-11-12 11:47 ` Pantelis Antoniou 2012-11-13 3:59 ` Joel A Fernandes 2012-11-09 22:59 ` Stephen Warren [not found] ` <-4237940489086529028@unknownmsgid> [not found] ` <559B8433-67C3-4A1A-A5D6-859907655176@antoniou-consulting.com> 2012-11-10 3:36 ` Joel A Fernandes 2012-11-10 3:36 ` Joel A Fernandes 2012-11-12 12:48 ` Pantelis Antoniou 2012-11-13 2:28 ` David Gibson 2012-11-06 22:37 ` Stephen Warren 2012-11-06 22:37 ` Stephen Warren 2012-11-07 0:54 ` Mitch Bradley 2012-11-07 0:54 ` Mitch Bradley 2012-11-09 17:02 ` Grant Likely 2012-11-12 11:29 ` Pantelis Antoniou 2012-11-07 8:47 ` Pantelis Antoniou 2012-11-07 17:18 ` Stephen Warren 2012-11-07 22:08 ` Pantelis Antoniou 2012-11-07 22:08 ` Pantelis Antoniou 2012-11-09 16:28 ` Grant Likely 2012-11-09 23:23 ` Stephen Warren 2012-11-09 23:40 ` Grant Likely 2012-11-12 10:53 ` Koen Kooi 2012-11-12 12:10 ` Pantelis Antoniou 2012-11-12 12:10 ` Pantelis Antoniou 2012-11-12 16:52 ` Stephen Warren 2012-11-13 7:25 ` David Gibson 2012-11-13 8:09 ` Pantelis Antoniou 2012-11-13 8:09 ` Pantelis Antoniou 2012-11-13 12:24 ` Grant Likely 2012-11-13 13:38 ` Pantelis Antoniou 2012-11-13 13:38 ` Pantelis Antoniou 2012-11-15 4:57 ` David Gibson 2012-11-13 17:10 ` Stephen Warren 2012-11-13 23:30 ` David Gibson 2012-11-13 23:30 ` David Gibson 2012-11-14 0:00 ` Pantelis Antoniou 2012-11-13 16:57 ` Stephen Warren 2012-11-13 18:10 ` Mitch Bradley 2012-11-13 18:10 ` Mitch Bradley 2012-11-13 18:29 ` Stephen Warren 2012-11-13 18:29 ` Stephen Warren 2012-11-13 19:09 ` Mitch Bradley 2012-11-13 19:11 ` Pantelis Antoniou 2012-11-17 22:27 ` Jean-Christophe PLAGNIOL-VILLARD 2012-11-20 17:09 ` Grant Likely 2012-11-11 20:47 ` Rob Landley 2012-11-12 12:50 ` Pantelis Antoniou 2012-11-12 16:54 ` Stephen Warren 2012-11-12 16:54 ` Stephen Warren 2012-11-12 11:23 ` Pantelis Antoniou 2012-11-12 16:49 ` Stephen Warren 2012-11-12 17:00 ` Pantelis Antoniou 2012-11-12 17:10 ` Stephen Warren 2012-11-12 17:19 ` Pantelis Antoniou 2012-11-12 17:29 ` Stephen Warren 2012-11-12 17:38 ` Pantelis Antoniou 2012-11-12 20:16 ` Russ Dill 2012-11-12 16:45 ` Stephen Warren 2012-11-09 2:26 ` David Gibson 2012-11-09 15:40 ` Pantelis Antoniou 2012-11-13 0:03 ` David Gibson 2012-11-13 0:03 ` David Gibson 2012-11-09 21:08 ` Grant Likely 2012-11-13 0:05 ` David Gibson 2012-11-13 0:05 ` David Gibson 2012-11-09 21:42 ` Grant Likely 2012-11-13 1:05 ` David Gibson 2012-11-13 1:05 ` David Gibson 2012-11-13 5:22 ` Stephen Warren 2012-11-13 6:54 ` David Gibson 2012-11-13 6:54 ` David Gibson 2012-11-09 22:57 ` Stephen Warren 2012-11-09 23:27 ` Grant Likely 2012-11-12 12:05 ` Pantelis Antoniou 2012-11-09 23:14 ` Stephen Warren 2012-11-09 23:14 ` Stephen Warren 2012-11-09 23:06 ` Stephen Warren 2012-11-09 23:32 ` Grant Likely 2012-11-12 11:03 ` Koen Kooi 2012-11-12 11:03 ` Koen Kooi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1352302401.4067.11.camel@atull-linux1 \ --to=atull@altera.com \ --cc=Russ.Dill@ti.com \ --cc=balbi@ti.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dsaxena@linaro.org \ --cc=grant.likely@secretlab.ca \ --cc=khilman@ti.com \ --cc=koen@dominion.thruhere.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mporter@ti.com \ --cc=panto@antoniou-consulting.com \ --cc=scottwood@freescale.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.