From: Tabi Timur-B04825 <B04825@freescale.com> To: Grant Likely <grant.likely@secretlab.ca> Cc: Pantelis Antoniou <panto@antoniou-consulting.com>, Rob Herring <robherring2@gmail.com>, Deepak Saxena <dsaxena@linaro.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Wood Scott-B07421 <B07421@freescale.com>, Tony Lindgren <tony@atomide.com>, 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>, Russ Dill <Russ.Dill@ti.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "devicetree-discuss@lists.ozlabs.org" <devicetree-discuss@lists.ozlabs.org> Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Mon, 5 Nov 2012 21:40:16 +0000 [thread overview] Message-ID: <6AE080B68D46FC4BA2D2769E68D765B708174B7D@039-SN2MPN1-023.039d.mgd.msft.net> (raw) In-Reply-To: <CACxGe6vu8ek7-K-yDDMXyg9x-oKiFt_cSz+Pz-yZf5U5vwe=0g@mail.gmail.com> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > Jane is building custom BeagleBone expansion boards called 'capes'. She > can boot the system with a stock BeagleBoard device tree, but additional > data is needed before a cape can be used. She could replace the FDT file > used by U-Boot with one that contains the extra data, but she uses the > same Linux system image regardless of the cape, and it is inconvenient > to have to select a different device tree at boot time depending on the > cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. > Nigel is building a real-time video processing system around a MIPS SoC > and a Virtex FPGA. Video data is streamed through the FPGA for post > processing operations like motion tracking or compression. The FPGA is > configured via the SPI bus, and is also connected to GPIO lines and the > memory mapped peripheral bus. Nigel has designed several FPGA > configurations for different video processing tasks. The user will > choose which configuration to load which can even be reprogrammed at > runtime to switch tasks. Now this, on the other hand, makes more sense. If the hardware configuration is literally user-configurable, then okay. However, I'm not sure I see the need to update the device tree. The device tree is generally for hardware that cannot be discovered/probed by the device driver. If we're loading a configuration from user space, doesn't the driver already know what the hardware's capabilities are, since it's the one doing the uploading of a new FPGA code? Why not skip the device tree update and just tell the driver what the new capabilities are? -- Timur Tabi Linux kernel developer at Freescale
WARNING: multiple messages have this Message-ID (diff)
From: Tabi Timur-B04825 <B04825-KZfg59tc24xl57MIdRCFDg@public.gmane.org> To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>, Wood Scott-B07421 <B07421-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, Matt Porter <mporter-l0cyMroinI0@public.gmane.org>, Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>, Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>, Deepak Saxena <dsaxena-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Russ Dill <Russ.Dill-l0cyMroinI0@public.gmane.org>, "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org> Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Mon, 5 Nov 2012 21:40:16 +0000 [thread overview] Message-ID: <6AE080B68D46FC4BA2D2769E68D765B708174B7D@039-SN2MPN1-023.039d.mgd.msft.net> (raw) In-Reply-To: <CACxGe6vu8ek7-K-yDDMXyg9x-oKiFt_cSz+Pz-yZf5U5vwe=0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > Jane is building custom BeagleBone expansion boards called 'capes'. She > can boot the system with a stock BeagleBoard device tree, but additional > data is needed before a cape can be used. She could replace the FDT file > used by U-Boot with one that contains the extra data, but she uses the > same Linux system image regardless of the cape, and it is inconvenient > to have to select a different device tree at boot time depending on the > cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. > Nigel is building a real-time video processing system around a MIPS SoC > and a Virtex FPGA. Video data is streamed through the FPGA for post > processing operations like motion tracking or compression. The FPGA is > configured via the SPI bus, and is also connected to GPIO lines and the > memory mapped peripheral bus. Nigel has designed several FPGA > configurations for different video processing tasks. The user will > choose which configuration to load which can even be reprogrammed at > runtime to switch tasks. Now this, on the other hand, makes more sense. If the hardware configuration is literally user-configurable, then okay. However, I'm not sure I see the need to update the device tree. The device tree is generally for hardware that cannot be discovered/probed by the device driver. If we're loading a configuration from user space, doesn't the driver already know what the hardware's capabilities are, since it's the one doing the uploading of a new FPGA code? Why not skip the device tree update and just tell the driver what the new capabilities are? -- Timur Tabi Linux kernel developer at Freescale
next prev parent reply other threads:[~2012-11-05 21:41 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 [this message] 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 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=6AE080B68D46FC4BA2D2769E68D765B708174B7D@039-SN2MPN1-023.039d.mgd.msft.net \ --to=b04825@freescale.com \ --cc=B07421@freescale.com \ --cc=Russ.Dill@ti.com \ --cc=balbi@ti.com \ --cc=benh@kernel.crashing.org \ --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=robherring2@gmail.com \ --cc=tony@atomide.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.