* [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-05 20:40 Grant Likely 2012-11-05 21:40 ` Tabi Timur-B04825 ` (5 more replies) 0 siblings, 6 replies; 135+ messages in thread From: Grant Likely @ 2012-11-05 20:40 UTC (permalink / raw) To: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren Cc: Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose ======= Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories ============ Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. 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. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. 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. Each FPGA has a different interface to the processor, so the kernel needs additional data before it can use each device. Nigel is passing that data to the kernel using an FDT overlay. When Linux loads a new FPGA configuration, it uses request_firmare() to obtain the overlay for that FPGA. When the FPGA gets reprogrammed, the kernel throws away the previous overlay data and uses request_firmware() to get the overlay for the new design. Mandy has a Raspberry Pi which she has wired by hand up to sensors and motor controllers in her prototype autonomous robot project. She is doing self-hosted driver development on the Raspberry Pi itself. However, she needs a method to tell the kernel about the attached devices. By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Amit is writing kernel drivers for Jane's BeagleBone capes, but he finds loading new DT files into the root filesystem inconvenient. Instead, he includes the FDT overlay file in the initramfs that is built and linked in at kernel compile time so that the kernel can find and load overlays automatically. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. .... Summary points: - Create an FDT overlay data format and usage model - SHALL reliable resolve or validate of phandles between base and overlay trees - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered over changes. If not possible, then SHALL detect when the base tree doesn't match and refuse to apply the overlay. - dts syntax needs to be extended for overlay .dtb files - DTC tool needs to be modified to support overlay .dtb generation - Overlays SHOULD be able to be applied either by firmware or the kernel - libfdt SHALL be extended to parse and apply overlays - Linux SHALL be extended to parse and apply overlays from userspace - Linux SHALL be extended to notify drivers of changes to device tree - Linux MAY use request_firmware() to load overlays via sysfs - (mechanism for triggering overlay load TBD) - Linux MAY support removal of overlays (harder, but some use-cases want this) - Linux MAY be extended to remove devices associated with removed overlays Technical details to resolve: - How does an overlay get attached to the correct base tree nodes? - How are phandles fixed up and/or verified? - What is the model for overlays? - Can an overlay modify existing properties? - Can an overlay add new properties to existing nodes? - Can an overlay delete existing nodes/properties? - Does FDT need a schema? - Schema should be tightly associated with binding documentation. Verifying schema at runtime should be simple. Runtime checking is harder, but could be used as part of phandle fixup. - Similarly, does FDT need data typing? Other than reading the binding there is no mechanism to determine if a single cell is a phandle, an integer (possibly enum), a flags field, or part of a string. - Data typing would require additional per-property data; probably by adding companion properties containing the data typing. ie. an optional '.reg,format' property could contain the format of the 'reg' property. (The naming scheme for the new property can be debated, it just needs to be something that won't conflict with regular names). - Data type data could be used as part of phandle fixups. - How do bus drivers get notified when FDT data changes? - node addition/removal - property changes on existing nodes - A notifier chain may work here, or maybe a generic "firmware data changed" device driver callback. I could see this being generically useful for other driver data like ACPI Project plan ============ 1) Create syntax for overlays ----------------------------- DTC already uses an overlay model internally which is often used in conjunction with .dtsi files. It should be a natural extension to generate FDT overlay files from the existing syntax (maybe minor modifications) Doing this will require a method to differentiate between overlay and include directives. Maybe they aren't really different at all and it will depend on dtc options to determine whether or not to produce an overlay. Suggestions are welcome here. 2) Create a data format for overlays ------------------------------------ The overlay data format could be a direct extension from the existing dtb data format. One option is to construct the overlay tree by creating empty nodes for each node that it either adds children to or references the phandle of in the base tree. Empty nodes could even be tagged as a prereq by adding a '.readonly' property to those nodes. When an overlay parser encounters those nodes, it would know that it needs to already exist in the tree. There is a problem though with phandles. If the phandle values in the base tree don't match the ones in the overlay, then the overlay won't be able to correctly reference base nodes. At a minimum, the parser must verify that the phandles match before applying the overlay. Ideally, phandles in the overlay should be fixed up at application time, but this isn't easy. It would probably require first adding property data type information to the device tree. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. Example: an overlay source file might look something like this: /include/ "base-file.dts" /* 'include' may not be the best syntax here */ &i2c0 { /* i2c0 resolved by label */ touchpad@10 { compatible = "acme,touchpad"; reg = <0x10>; interrupt-parent = <&intc>; interrupts = <100>; }; }; And the generated overlay dtb may look like this: / { .readonly; interrupt-controller@0x10005000 { .readonly; phandle = <0x1234>; }; peripheral-bus { .readonly; i2c@20001000 { touchpad@10 { compatible = "acme,touchpad"; reg = <0x10>; interrupt-parent = <0x1234>; interrupts = <100>; }; }; }; }; Which is obviously missing a bunch of information for the rest of the system, but contains enough data to ensure that the path to the touchpad node is valid and that the phandle has not changed. This handles many of the use cases, but it assumes that an overlay is board specific. If it ever is required to support multiple base boards with a single overlay file then there is a problem. The .dtb overlays generated in this manor cannot handle different phandles or nodes that are in a different place. On the other hand, the overlay source files should have no problem being compiled for multiple targets. 3) Modify DTC and libfdt to process overlays -------------------------------------------- Direct follow on from above. This will require DTC to be modified to generate the overlay output format and new test cases to verify it works. In the process libfdt will get modified to add overlay support which will immediately be available to U-Boot and other bootloaders. 4) Teach Linux to request FDT overlays -------------------------------------- Add request_firmware() hook for adding overlays. If the platform supports detecting the attached expansion board, then this may manipulate the filename for a specific file. The kernel will graft the overlay into the existing live tree Workitems: Document device tree node lifecycle Add tests to enforce device tree node lifecycle Add interface to firmware_request() an FDT overlay Add support to merge overlay FDT nodes into base tree Add support to track FDT changes per-overlay Add runtime fixups of overlay phandles - Without this overlay phandles must exactly match the base tree Add support to remove an overlay (question: is this important?) 5) Teach Linux driver model to respond to device tree changes ------------------------------------------------------------- There are several parts to this. The most obvious are adding hooks for platform_device, i2c_device and spi_device creation. In all three cases, the users should already be providing enough information to support dynamic addition (and possibly removal) of dt nodes. of_platform_populate() is called for platform devices, of_register_spi_devices() for spi and of_i2c_register_devices(). Right now all three functions register all the child devices and then immediately return. However, if they could set up a notifier for node addition, then it would be easy to trigger additional device creation when new nodes are added. Other busses would be similar, but i2c, spi and platform are the most common use cases currently. Workitems: Modify of_platform_populate() to get new node notifications Modify of_register_spi_devices to get new node notifications Modify of_register_i2c_devices to get new node notifications 6) Other work ------------- The device node user space interface could use some work. Here are some random work items that are peripherally related to the overlay feature. Other Workitems: Define FDT schema syntax Add FDT schema support to FDT (basically lint-style testing) Investigate runtime schema validation Make device_nodes first-class kobjects and remove the procfs interface - it can be emulated with a symlink Add symlinks from devices to devicetree nodes in sysfs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-05 21:40 ` Tabi Timur-B04825 0 siblings, 0 replies; 135+ messages in thread From: Tabi Timur-B04825 @ 2012-11-05 21:40 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-05 21:40 ` Tabi Timur-B04825 0 siblings, 0 replies; 135+ messages in thread From: Tabi Timur-B04825 @ 2012-11-05 21:40 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Wood Scott-B07421, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 21:40 ` Tabi Timur-B04825 @ 2012-11-05 23:22 ` Tony Lindgren -1 siblings, 0 replies; 135+ messages in thread From: Tony Lindgren @ 2012-11-05 23:22 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi, * Tabi Timur-B04825 <B04825@freescale.com> [121105 13:42]: > 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. I guess the beaglebone capes could be stackable and hotpluggable if handled carefully enough. Regards, Tony ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-05 23:22 ` Tony Lindgren 0 siblings, 0 replies; 135+ messages in thread From: Tony Lindgren @ 2012-11-05 23:22 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi, * Tabi Timur-B04825 <B04825@freescale.com> [121105 13:42]: > 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. I guess the beaglebone capes could be stackable and hotpluggable if handled carefully enough. Regards, Tony ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-09 12:06 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 12:06 UTC (permalink / raw) To: Tony Lindgren Cc: Tabi Timur-B04825, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Mon, Nov 5, 2012 at 11:22 PM, Tony Lindgren <tony@atomide.com> wrote: > Hi, > > * Tabi Timur-B04825 <B04825@freescale.com> [121105 13:42]: >> 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. > > I guess the beaglebone capes could be stackable and hotpluggable if > handled carefully enough. And even if it can't on the beaglebone, it will happen somewhere else. I don't want to exclude that use-case just because nobody thought about it. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-09 12:06 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 12:06 UTC (permalink / raw) To: Tony Lindgren Cc: Kevin Hilman, Wood Scott-B07421, Matt Porter, Tabi Timur-B04825, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Mon, Nov 5, 2012 at 11:22 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote: > Hi, > > * Tabi Timur-B04825 <B04825-KZfg59tc24xl57MIdRCFDg@public.gmane.org> [121105 13:42]: >> 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. > > I guess the beaglebone capes could be stackable and hotpluggable if > handled carefully enough. And even if it can't on the beaglebone, it will happen somewhere else. I don't want to exclude that use-case just because nobody thought about it. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 21:40 ` Tabi Timur-B04825 @ 2012-11-06 0:07 ` Grant Likely -1 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-06 0:07 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Tabi Timur-B04825 <B04825@freescale.com> wrote: >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. >From the discussion in the previous thread, I'm sufficiently convinced that it is an important use case. I certainly disagree with the assertion that it is always easier to do it in U-Boot. Sometimes the kernel is the better place. > >> 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? Not if the driver is only responsible for loading the bitstream. There is already a xilinx driver that does things this way. > Why not skip the >device tree update and just tell the driver what the new capabilities >are? How? What format will that data be in if not device tree? g. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 0:07 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-06 0:07 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Tabi Timur-B04825 <B04825@freescale.com> wrote: >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. >From the discussion in the previous thread, I'm sufficiently convinced that it is an important use case. I certainly disagree with the assertion that it is always easier to do it in U-Boot. Sometimes the kernel is the better place. > >> 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? Not if the driver is only responsible for loading the bitstream. There is already a xilinx driver that does things this way. > Why not skip the >device tree update and just tell the driver what the new capabilities >are? How? What format will that data be in if not device tree? g. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 21:40 ` Tabi Timur-B04825 @ 2012-11-06 10:31 ` Pantelis Antoniou -1 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 10:31 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: > 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. > Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. >> 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 Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 10:31 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 10:31 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: > 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. > Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. >> 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 Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 21:40 ` Tabi Timur-B04825 @ 2012-11-07 22:35 ` Ryan Mallon -1 siblings, 0 replies; 135+ messages in thread From: Ryan Mallon @ 2012-11-07 22:35 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 06/11/12 08:40, Tabi Timur-B04825 wrote: > 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. This is probably okay for some hardware, but doesn't work in the general case. Not all hardware is detectable, for example a cape which just adds a set of LEDs for GPIO pins. Also, some hardware might not easily be detectable without adding additional complexity to the boot loader. ~Ryan ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 22:35 ` Ryan Mallon 0 siblings, 0 replies; 135+ messages in thread From: Ryan Mallon @ 2012-11-07 22:35 UTC (permalink / raw) To: Tabi Timur-B04825 Cc: Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 06/11/12 08:40, Tabi Timur-B04825 wrote: > 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. This is probably okay for some hardware, but doesn't work in the general case. Not all hardware is detectable, for example a cape which just adds a set of LEDs for GPIO pins. Also, some hardware might not easily be detectable without adding additional complexity to the boot loader. ~Ryan ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 22:35 ` Ryan Mallon @ 2012-11-08 13:28 ` Koen Kooi -1 siblings, 0 replies; 135+ messages in thread From: Koen Kooi @ 2012-11-08 13:28 UTC (permalink / raw) To: Ryan Mallon Cc: Tabi Timur-B04825, Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Op 7 nov. 2012, om 23:35 heeft Ryan Mallon <rmallon@gmail.com> het volgende geschreven: > On 06/11/12 08:40, Tabi Timur-B04825 wrote: >> 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. > > This is probably okay for some hardware, but doesn't work in the general > case. Not all hardware is detectable, for example a cape which just adds > a set of LEDs for GPIO pins. Also, some hardware might not easily be > detectable without adding additional complexity to the boot loader. And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. regards, Koen ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-08 13:28 ` Koen Kooi 0 siblings, 0 replies; 135+ messages in thread From: Koen Kooi @ 2012-11-08 13:28 UTC (permalink / raw) To: Ryan Mallon Cc: Tabi Timur-B04825, Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Op 7 nov. 2012, om 23:35 heeft Ryan Mallon <rmallon@gmail.com> het volgende geschreven: > On 06/11/12 08:40, Tabi Timur-B04825 wrote: >> 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. > > This is probably okay for some hardware, but doesn't work in the general > case. Not all hardware is detectable, for example a cape which just adds > a set of LEDs for GPIO pins. Also, some hardware might not easily be > detectable without adding additional complexity to the boot loader. And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. regards, Koen ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-08 13:28 ` Koen Kooi @ 2012-11-08 14:09 ` Timur Tabi -1 siblings, 0 replies; 135+ messages in thread From: Timur Tabi @ 2012-11-08 14:09 UTC (permalink / raw) To: Koen Kooi Cc: Ryan Mallon, Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Koen Kooi wrote: > And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Well, U-Boot does allow you to manipulate the device tree from the command-line, but I understand that this feature doesn't work that well. -- Timur Tabi Linux kernel developer at Freescale ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-08 14:09 ` Timur Tabi 0 siblings, 0 replies; 135+ messages in thread From: Timur Tabi @ 2012-11-08 14:09 UTC (permalink / raw) To: Koen Kooi Cc: Ryan Mallon, Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Wood Scott-B07421, Tony Lindgren, Kevin Hilman, Matt Porter, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Koen Kooi wrote: > And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Well, U-Boot does allow you to manipulate the device tree from the command-line, but I understand that this feature doesn't work that well. -- Timur Tabi Linux kernel developer at Freescale ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-08 13:28 ` Koen Kooi @ 2012-11-08 17:00 ` Mitch Bradley -1 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-08 17:00 UTC (permalink / raw) To: Koen Kooi Cc: Ryan Mallon, Kevin Hilman, Wood Scott-B07421, Matt Porter, Tabi Timur-B04825, devicetree-discuss, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, linux-omap On 11/8/2012 3:28 AM, Koen Kooi wrote: > > Op 7 nov. 2012, om 23:35 heeft Ryan Mallon <rmallon@gmail.com> het volgende geschreven: > >> On 06/11/12 08:40, Tabi Timur-B04825 wrote: >>> 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. >> >> This is probably okay for some hardware, but doesn't work in the general >> case. Not all hardware is detectable, for example a cape which just adds >> a set of LEDs for GPIO pins. Also, some hardware might not easily be >> detectable without adding additional complexity to the boot loader. > > And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. One possibility for dynamic device tree mods would be to run Open Firmware from u-boot and have it generate the device tree and possibly modify it either interactively or from a script loaded from a file or the network. OFW could then either load Linux directly or return to u-boot, which would proceed with loading. > > Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. > > regards, > > Koen > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-08 17:00 ` Mitch Bradley 0 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-08 17:00 UTC (permalink / raw) To: Koen Kooi Cc: Ryan Mallon, Kevin Hilman, Wood Scott-B07421, Matt Porter, Tabi Timur-B04825, devicetree-discuss, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, linux-omap On 11/8/2012 3:28 AM, Koen Kooi wrote: > > Op 7 nov. 2012, om 23:35 heeft Ryan Mallon <rmallon@gmail.com> het volgende geschreven: > >> On 06/11/12 08:40, Tabi Timur-B04825 wrote: >>> 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. >> >> This is probably okay for some hardware, but doesn't work in the general >> case. Not all hardware is detectable, for example a cape which just adds >> a set of LEDs for GPIO pins. Also, some hardware might not easily be >> detectable without adding additional complexity to the boot loader. > > And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. One possibility for dynamic device tree mods would be to run Open Firmware from u-boot and have it generate the device tree and possibly modify it either interactively or from a script loaded from a file or the network. OFW could then either load Linux directly or return to u-boot, which would proceed with loading. > > Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. > > regards, > > Koen > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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-06 10:30 ` Pantelis Antoniou 2012-11-06 11:14 ` Grant Likely ` (2 more replies) 2012-11-06 22:37 ` Stephen Warren ` (3 subsequent siblings) 5 siblings, 3 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 10:30 UTC (permalink / raw) To: Grant Likely Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. > > Device Tree Overlay Feature > > Purpose > ======= > Sometimes it is not convenient to describe an entire system with a > single FDT. For example, processor modules that are plugged into one or > more modules (a la the BeagleBone), or systems with an FPGA peripheral > that is programmed after the system is booted. > > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at > runtime by loading additional overlay FDTs that amend the original data. > > User Stories > ============ > Note - These are potential use cases, but just because it is listed here > doesn't mean it is important. I just want to thoroughly think through the > implications before making design decisions. > > > 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. > > Jane solves this problem by storing an FDT overlay for each cape in the > root filesystem. When the kernel detects that a cape is installed it > reads the cape's eeprom to identify it and uses request_firmware() to > obtain the appropriate overlay. Userspace passes the overlay to the > kernel in the normal way. If the cape doesn't have an eeprom, then the > kernel will still use firmware_request(), but userspace needs to already > know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. > > > 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. > > Each FPGA has a different interface to the processor, so the kernel > needs additional data before it can use each device. Nigel is passing > that data to the kernel using an FDT overlay. When Linux loads a new > FPGA configuration, it uses request_firmare() to obtain the overlay for > that FPGA. When the FPGA gets reprogrammed, the kernel throws away the > previous overlay data and uses request_firmware() to get the overlay for > the new design. > > > Mandy has a Raspberry Pi which she has wired by hand up to sensors and > motor controllers in her prototype autonomous robot project. She is doing > self-hosted driver development on the Raspberry Pi itself. However, she > needs a method to tell the kernel about the attached devices. > > By installing dtc on the Pi, Mandy compiles the overlay for her > prototype hardware. However, she doesn't have a copy of the Pi's > original FDT source, so instead she uses the dtc 'fs' input format to > compile the overlay file against the live DT data in /proc. > > Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. > Amit is writing kernel drivers for Jane's BeagleBone capes, but he > finds loading new DT files into the root filesystem inconvenient. > Instead, he includes the FDT overlay file in the initramfs that is built > and linked in at kernel compile time so that the kernel can find and > load overlays automatically. > > > Joanne has purchased one of Jane's capes and packaged it into a rugged > case for data logging. As far as Joanne is concerned, the BeagleBone and > cape together are a single unit and she'd prefer a single monolithic FDT > instead of using an FDT overlay. > Option A: Using dtc, she uses the BeagleBone and cape .dts source files > to generate a single .dtb for the entire system which is > loaded by U-Boot. -or- Unlikely. > Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files > (instead of .dts files), -or- Possible but low probability. > Option C: U-Boot loads both the base and overlay FDT files, merges them, > and passes the resolved tree to the kernel. > Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. > .... > > Summary points: > - Create an FDT overlay data format and usage model > - SHALL reliable resolve or validate of phandles between base and > overlay trees > - SHOULD reliably handle changes between different underlying overlays > (ie. what happens to existing .dtb overly files if the structure of > the dtb it is layered over changes. If not possible, then SHALL > detect when the base tree doesn't match and refuse to apply the > overlay. > - dts syntax needs to be extended for overlay .dtb files > - DTC tool needs to be modified to support overlay .dtb generation > - Overlays SHOULD be able to be applied either by firmware or the kernel > - libfdt SHALL be extended to parse and apply overlays - ftdump should be fixed and work for the overlay syntax too. > - Linux SHALL be extended to parse and apply overlays from userspace > - Linux SHALL be extended to notify drivers of changes to device tree > - Linux MAY use request_firmware() to load overlays via sysfs > - (mechanism for triggering overlay load TBD) > - Linux MAY support removal of overlays (harder, but some use-cases want > this) > - Linux MAY be extended to remove devices associated with removed overlays > > Technical details to resolve: > - How does an overlay get attached to the correct base tree nodes? > - How are phandles fixed up and/or verified? > - What is the model for overlays? > - Can an overlay modify existing properties? > - Can an overlay add new properties to existing nodes? > - Can an overlay delete existing nodes/properties? > - Does FDT need a schema? - Schema should be tightly associated with binding > documentation. Verifying schema at runtime should be simple. Runtime > checking is harder, but could be used as part of phandle fixup. > - Similarly, does FDT need data typing? Other than reading the binding > there is no mechanism to determine if a single cell is a phandle, an > integer (possibly enum), a flags field, or part of a string. > - Data typing would require additional per-property data; probably by > adding companion properties containing the data typing. ie. an > optional '.reg,format' property could contain the format of the > 'reg' property. (The naming scheme for the new property can be > debated, it just needs to be something that won't conflict with > regular names). > - Data type data could be used as part of phandle fixups. > - How do bus drivers get notified when FDT data changes? > - node addition/removal > - property changes on existing nodes > - A notifier chain may work here, or maybe a generic "firmware data > changed" device driver callback. I could see this being generically > useful for other driver data like ACPI > This is much grander in vision that I had in mind :) It can handle our use cases, but I'm worried if we're bitting more that what we can chew. Perhaps a staged approach? I.e. target the low hanging fruit first, get it work, and then work on the hardest parts? > Project plan > ============ > > 1) Create syntax for overlays > ----------------------------- > DTC already uses an overlay model internally which is often used in > conjunction with .dtsi files. It should be a natural extension to > generate FDT overlay files from the existing syntax (maybe minor > modifications) > > Doing this will require a method to differentiate between overlay and > include directives. Maybe they aren't really different at all and it > will depend on dtc options to determine whether or not to produce an > overlay. Suggestions are welcome here. > > 2) Create a data format for overlays > ------------------------------------ > The overlay data format could be a direct extension from the existing > dtb data format. One option is to construct the overlay tree by creating > empty nodes for each node that it either adds children to or references > the phandle of in the base tree. Empty nodes could even be tagged as a > prereq by adding a '.readonly' property to those nodes. When an overlay > parser encounters those nodes, it would know that it needs to already > exist in the tree. > > There is a problem though with phandles. If the phandle values in the > base tree don't match the ones in the overlay, then the overlay won't be > able to correctly reference base nodes. At a minimum, the parser must > verify that the phandles match before applying the overlay. Ideally, > phandles in the overlay should be fixed up at application time, but this > isn't easy. It would probably require first adding property data type > information to the device tree. > > It may be sufficient to solve it by making the phandle values less > volatile. Right now dtc generates phandles linearly. Generated phandles > could be overridden with explicit phandle properties, but it isn't a > fantastic solution. Perhaps generating the phandle from a hash of the > node name would be sufficient. > I doubt the hash method will work reliably. We only have 32 bits to work with, nothing like the SHA hashes of git. > Example: an overlay source file might look something like this: > > /include/ "base-file.dts" /* 'include' may not be the best syntax here */ > &i2c0 { /* i2c0 resolved by label */ > touchpad@10 { > compatible = "acme,touchpad"; > reg = <0x10>; > interrupt-parent = <&intc>; > interrupts = <100>; > }; > }; > > And the generated overlay dtb may look like this: > > / { > .readonly; > interrupt-controller@0x10005000 { > .readonly; > phandle = <0x1234>; > }; > peripheral-bus { > .readonly; > i2c@20001000 { > touchpad@10 { > compatible = "acme,touchpad"; > reg = <0x10>; > interrupt-parent = <0x1234>; > interrupts = <100>; > }; > }; > }; > }; > > Which is obviously missing a bunch of information for the rest of the > system, but contains enough data to ensure that the path to the touchpad > node is valid and that the phandle has not changed. > > This handles many of the use cases, but it assumes that an overlay is > board specific. If it ever is required to support multiple base boards > with a single overlay file then there is a problem. The .dtb overlays > generated in this manor cannot handle different phandles or nodes that > are in a different place. On the other hand, the overlay source files > should have no problem being compiled for multiple targets. It will work for our case. The board-file dependency problem is not a big concern right now. > > 3) Modify DTC and libfdt to process overlays > -------------------------------------------- > Direct follow on from above. This will require DTC to be modified to > generate the overlay output format and new test cases to verify it > works. > > In the process libfdt will get modified to add overlay support which > will immediately be available to U-Boot and other bootloaders. > > 4) Teach Linux to request FDT overlays > -------------------------------------- > Add request_firmware() hook for adding overlays. If the platform > supports detecting the attached expansion board, then this may > manipulate the filename for a specific file. > > The kernel will graft the overlay into the existing live tree > 5) Have a method to attach FDT overlay to a kernel module. For some drivers it might be better if the kernel module and the DT overlay is packaged in the same file. You be in a part of the module binary as a special section that request_firmware can pick up automatically. > Workitems: > Document device tree node lifecycle > Add tests to enforce device tree node lifecycle > Add interface to firmware_request() an FDT overlay > Add support to merge overlay FDT nodes into base tree > Add support to track FDT changes per-overlay > Add runtime fixups of overlay phandles > - Without this overlay phandles must exactly match the base tree > Add support to remove an overlay (question: is this important?) > 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. > 5) Teach Linux driver model to respond to device tree changes > ------------------------------------------------------------- > There are several parts to this. The most obvious are adding hooks for > platform_device, i2c_device and spi_device creation. In all three cases, > the users should already be providing enough information to support > dynamic addition (and possibly removal) of dt nodes. > of_platform_populate() is called for platform devices, > of_register_spi_devices() for spi and of_i2c_register_devices(). Right > now all three functions register all the child devices and then > immediately return. However, if they could set up a notifier for node > addition, then it would be easy to trigger additional device creation > when new nodes are added. > > Other busses would be similar, but i2c, spi and platform are the most > common use cases currently. > > Workitems: > Modify of_platform_populate() to get new node notifications > Modify of_register_spi_devices to get new node notifications > Modify of_register_i2c_devices to get new node notifications > w1 is the same. Possibly more. Another can of worms is the pinctrl nodes. > 6) Other work > ------------- > The device node user space interface could use some work. Here are some > random work items that are peripherally related to the overlay feature. > > Other Workitems: > Define FDT schema syntax > Add FDT schema support to FDT (basically lint-style testing) > Investigate runtime schema validation > Make device_nodes first-class kobjects and remove the procfs interface > - it can be emulated with a symlink > Add symlinks from devices to devicetree nodes in sysfs That's going to take a while :) Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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:34 ` Pantelis Antoniou 2012-11-09 5:32 ` Joel A Fernandes [not found] ` <-4237940489086529028@unknownmsgid> 2 siblings, 2 replies; 135+ messages in thread From: Grant Likely @ 2012-11-06 11:14 UTC (permalink / raw) To: Pantelis Antoniou Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > Hi Grant, > > On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: > >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. >> >> Device Tree Overlay Feature >> >> Purpose >> ======= >> Sometimes it is not convenient to describe an entire system with a >> single FDT. For example, processor modules that are plugged into one or >> more modules (a la the BeagleBone), or systems with an FPGA peripheral >> that is programmed after the system is booted. >> >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at >> runtime by loading additional overlay FDTs that amend the original data. >> >> User Stories >> ============ >> Note - These are potential use cases, but just because it is listed here >> doesn't mean it is important. I just want to thoroughly think through the >> implications before making design decisions. >> >> >> 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. >> >> Jane solves this problem by storing an FDT overlay for each cape in the >> root filesystem. When the kernel detects that a cape is installed it >> reads the cape's eeprom to identify it and uses request_firmware() to >> obtain the appropriate overlay. Userspace passes the overlay to the >> kernel in the normal way. If the cape doesn't have an eeprom, then the >> kernel will still use firmware_request(), but userspace needs to already >> know which cape is installed. > > Jane is a really productive hardware engineer - she manages to fix a > number of problems with her cape design by spinning different revisions > of the cape. Using the flexibility that the DT provides, documents and > defines the hardware changes of the cape revisions in the FDT overlay. > The loader matches the revision of the cape with the proper FDT overlay > so that the drivers are relieved of having to do revision management. Okay >> By installing dtc on the Pi, Mandy compiles the overlay for her >> prototype hardware. However, she doesn't have a copy of the Pi's >> original FDT source, so instead she uses the dtc 'fs' input format to >> compile the overlay file against the live DT data in /proc. > > Jane (the cape designer) can use this too. Developing the cape, she really > appreciates that she doesn't have to reboot every time she makes a change > in the cape hardware. By removing the FDT overlay, compiling with the dtc > on the board, and re-inserting the overlay, she can be more productive by > waiting less. Yes, but I'll leave this paragraph out of the spec. It isn't significantly different from what is already there. > Johnny, Jane's little son, doesn't know anything about device trees, linux > kernel trees, or hard-core s/w engineering. He is a bright kid, and due to > the board having a node.js based educational electronic design kit, he > can use the web-based simplified development environment, that allows > him graphically to connect the parts in his kit. He can save the design > and the IDE creates on the fly the DT overlay for later use. Yes. >> Joanne has purchased one of Jane's capes and packaged it into a rugged >> case for data logging. As far as Joanne is concerned, the BeagleBone and >> cape together are a single unit and she'd prefer a single monolithic FDT >> instead of using an FDT overlay. >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >> to generate a single .dtb for the entire system which is >> loaded by U-Boot. -or- > Unlikely. >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >> (instead of .dts files), -or- > Possible but low probability. >> Option C: U-Boot loads both the base and overlay FDT files, merges them, >> and passes the resolved tree to the kernel. > Could be made to work. Only really required if Joanne wants the > cape interface to work for u-boot too. For example if the cape has some > kind of network interface that u-boot will use to boot from. Unlikely for your focus perhaps, but I'm trying to capture all the relevant permutations, and I can guarantee that some people really will want this. If not on the bone, then on some other platform. >> Summary points: >> - Create an FDT overlay data format and usage model >> - SHALL reliable resolve or validate of phandles between base and >> overlay trees >> - SHOULD reliably handle changes between different underlying overlays >> (ie. what happens to existing .dtb overly files if the structure of >> the dtb it is layered over changes. If not possible, then SHALL >> detect when the base tree doesn't match and refuse to apply the >> overlay. >> - dts syntax needs to be extended for overlay .dtb files >> - DTC tool needs to be modified to support overlay .dtb generation >> - Overlays SHOULD be able to be applied either by firmware or the kernel >> - libfdt SHALL be extended to parse and apply overlays > > - ftdump should be fixed and work for the overlay syntax too. Okay > This is much grander in vision that I had in mind :) > > It can handle our use cases, but I'm worried if we're bitting more > that what we can chew. Perhaps a staged approach? I.e. target the > low hanging fruit first, get it work, and then work on the hardest > parts? Actually, I'm not to scared about the work and yes I think that it *must* be a staged approach. To start focus on adding overlays without phandle resolution (phandles must match) or unloading support. Unloading and phandle resolution can be separate follow-on features. Unloading and phandle resolution are the hard bits anyway. >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. >> > > I doubt the hash method will work reliably. We only have 32 bits to work with, > nothing like the SHA hashes of git. > I think the biggest trees have on the order of 100 nodes and a 32 bit numberspace is 4Gi. Surely collisions can be avoided. :-) It is also possible to explicitly specify the phandle when the hash method breaks down, or if the node full path needs to change, but I'd like to avoid that approach as much as possible. > 5) Have a method to attach FDT overlay to a kernel module. > > For some drivers it might be better if the kernel module and the > DT overlay is packaged in the same file. You be in a part of > the module binary as a special section that request_firmware can > pick up automatically. It used to be that firmware blobs could be linked into the kernel and request_firmware() would find them. I'd like to investigate if that is still possible. >> Add support to remove an overlay (question: is this important?) >> > > 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. >> Workitems: >> Modify of_platform_populate() to get new node notifications >> Modify of_register_spi_devices to get new node notifications >> Modify of_register_i2c_devices to get new node notifications >> > > w1 is the same. Possibly more. w1? > > Another can of worms is the pinctrl nodes. Yes... new pinctrl data would need to trigger adding new data to pinctrl. I don't know if the pinctrl api supports that. > >> 6) Other work >> ------------- >> The device node user space interface could use some work. Here are some >> random work items that are peripherally related to the overlay feature. >> >> Other Workitems: >> Define FDT schema syntax >> Add FDT schema support to FDT (basically lint-style testing) >> Investigate runtime schema validation >> Make device_nodes first-class kobjects and remove the procfs interface >> - it can be emulated with a symlink >> Add symlinks from devices to devicetree nodes in sysfs > > That's going to take a while :) :-) But as you've already pointed out this should be taken in a staged approach. Simple overlay support is still useful and shouldn't be too complex to implement. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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:34 ` Pantelis Antoniou 1 sibling, 1 reply; 135+ messages in thread From: Tony Lindgren @ 2012-11-06 18:35 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss * Grant Likely <grant.likely@secretlab.ca> [121106 03:16]: > On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > > > > Another can of worms is the pinctrl nodes. > > Yes... new pinctrl data would need to trigger adding new data to > pinctrl. I don't know if the pinctrl api supports that. The actual pins stay the same, just their configuration changes. AFAIK all that is already supported using the pinctrl framework. For example, considering hotplugging capes on the beaglebone: 1. You need to map all the sensible modes for the pins exposed to the capes in the board specific .dts file. This will add roughly 4 x nr_capbus_pins named modes in the .dts file so not too bad. 2. Claim all the capebus pins during the capbus driver probe and set them to some safe mode. 3. Try to detect the connected cape(s) over i2c. 4. Use pinctr_select_state to set the desired modes for the pins used by the cape(s). 5. Enable capebus regulators and clocks etc. 6. Load the driver modules for whatever omap internal devices the cape supports. You could also claim the pin for the omap internal devices instead of claiming them in the capebus, but then things can get messy with binding and unbinding the drivers. So just claiming all the pins in the capebus probably keeps things simpler. Regards, Tony ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 18:35 ` Tony Lindgren @ 2012-11-06 19:29 ` Russ Dill 2012-11-06 19:41 ` Pantelis Antoniou 0 siblings, 1 reply; 135+ messages in thread From: Russ Dill @ 2012-11-06 19:29 UTC (permalink / raw) To: Tony Lindgren Cc: Grant Likely, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <tony@atomide.com> wrote: > * Grant Likely <grant.likely@secretlab.ca> [121106 03:16]: >> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >> <panto@antoniou-consulting.com> wrote: >> > >> > Another can of worms is the pinctrl nodes. >> >> Yes... new pinctrl data would need to trigger adding new data to >> pinctrl. I don't know if the pinctrl api supports that. > > The actual pins stay the same, just their configuration > changes. AFAIK all that is already supported using the > pinctrl framework. > > For example, considering hotplugging capes on the beaglebone: > > 1. You need to map all the sensible modes for the pins exposed > to the capes in the board specific .dts file. This will > add roughly 4 x nr_capbus_pins named modes in the .dts file > so not too bad. > > 2. Claim all the capebus pins during the capbus driver probe > and set them to some safe mode. > > 3. Try to detect the connected cape(s) over i2c. > > 4. Use pinctr_select_state to set the desired modes for > the pins used by the cape(s). > > 5. Enable capebus regulators and clocks etc. > > 6. Load the driver modules for whatever omap internal > devices the cape supports. > > You could also claim the pin for the omap internal > devices instead of claiming them in the capebus, but then > things can get messy with binding and unbinding the > drivers. So just claiming all the pins in the capebus > probably keeps things simpler. That assumes that for a particular external bus, certain pins aren't already shared with functions already on the board, for instance if an I²C bus brought out to the external bus already has a chip connected to it. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 19:41 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 19:41 UTC (permalink / raw) To: Russ Dill Cc: Tony Lindgren, Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Russ, On Nov 6, 2012, at 8:29 PM, Russ Dill wrote: > On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <tony@atomide.com> wrote: >> * Grant Likely <grant.likely@secretlab.ca> [121106 03:16]: >>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>> <panto@antoniou-consulting.com> wrote: >>>> >>>> Another can of worms is the pinctrl nodes. >>> >>> Yes... new pinctrl data would need to trigger adding new data to >>> pinctrl. I don't know if the pinctrl api supports that. >> >> The actual pins stay the same, just their configuration >> changes. AFAIK all that is already supported using the >> pinctrl framework. >> >> For example, considering hotplugging capes on the beaglebone: >> >> 1. You need to map all the sensible modes for the pins exposed >> to the capes in the board specific .dts file. This will >> add roughly 4 x nr_capbus_pins named modes in the .dts file >> so not too bad. >> >> 2. Claim all the capebus pins during the capbus driver probe >> and set them to some safe mode. >> >> 3. Try to detect the connected cape(s) over i2c. >> >> 4. Use pinctr_select_state to set the desired modes for >> the pins used by the cape(s). >> >> 5. Enable capebus regulators and clocks etc. >> >> 6. Load the driver modules for whatever omap internal >> devices the cape supports. >> >> You could also claim the pin for the omap internal >> devices instead of claiming them in the capebus, but then >> things can get messy with binding and unbinding the >> drivers. So just claiming all the pins in the capebus >> probably keeps things simpler. > > That assumes that for a particular external bus, certain pins aren't > already shared with functions already on the board, for instance if an > I²C bus brought out to the external bus already has a chip connected > to it. This is our case on the bone. We don't enable the peripheral until a cape that references it is enabled. I don't think that very big changes are going to be needed TBH. So now we use: am3358_pinmux: pinmux@44e10800 { .... bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { pinctrl-single,pins = < 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ >; }; .... }; And in the cape definition: pinctrl-0 = <&bone_geiger_cape_pins>; Ideally if we could do this in the cape definition: cape_pinmux { parent = <&am3358_pinmux>; bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { pinctrl-single,pins = < 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ >; }; pinctrl-0 = <&bone_geiger_cape_pins>; It would be just fine. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 19:41 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 19:41 UTC (permalink / raw) To: Russ Dill Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Russ, On Nov 6, 2012, at 8:29 PM, Russ Dill wrote: > On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote: >> * Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> [121106 03:16]: >>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>> <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >>>> >>>> Another can of worms is the pinctrl nodes. >>> >>> Yes... new pinctrl data would need to trigger adding new data to >>> pinctrl. I don't know if the pinctrl api supports that. >> >> The actual pins stay the same, just their configuration >> changes. AFAIK all that is already supported using the >> pinctrl framework. >> >> For example, considering hotplugging capes on the beaglebone: >> >> 1. You need to map all the sensible modes for the pins exposed >> to the capes in the board specific .dts file. This will >> add roughly 4 x nr_capbus_pins named modes in the .dts file >> so not too bad. >> >> 2. Claim all the capebus pins during the capbus driver probe >> and set them to some safe mode. >> >> 3. Try to detect the connected cape(s) over i2c. >> >> 4. Use pinctr_select_state to set the desired modes for >> the pins used by the cape(s). >> >> 5. Enable capebus regulators and clocks etc. >> >> 6. Load the driver modules for whatever omap internal >> devices the cape supports. >> >> You could also claim the pin for the omap internal >> devices instead of claiming them in the capebus, but then >> things can get messy with binding and unbinding the >> drivers. So just claiming all the pins in the capebus >> probably keeps things simpler. > > That assumes that for a particular external bus, certain pins aren't > already shared with functions already on the board, for instance if an > I²C bus brought out to the external bus already has a chip connected > to it. This is our case on the bone. We don't enable the peripheral until a cape that references it is enabled. I don't think that very big changes are going to be needed TBH. So now we use: am3358_pinmux: pinmux@44e10800 { .... bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { pinctrl-single,pins = < 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ >; }; .... }; And in the cape definition: pinctrl-0 = <&bone_geiger_cape_pins>; Ideally if we could do this in the cape definition: cape_pinmux { parent = <&am3358_pinmux>; bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { pinctrl-single,pins = < 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ >; }; pinctrl-0 = <&bone_geiger_cape_pins>; It would be just fine. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 19:41 ` Pantelis Antoniou @ 2012-11-06 22:17 ` Stephen Warren -1 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-06 22:17 UTC (permalink / raw) To: Pantelis Antoniou Cc: Russ Dill, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, linux-omap, devicetree-discuss On 11/06/2012 12:41 PM, Pantelis Antoniou wrote: > Hi Russ, > > On Nov 6, 2012, at 8:29 PM, Russ Dill wrote: > >> On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <tony@atomide.com> wrote: >>> * Grant Likely <grant.likely@secretlab.ca> [121106 03:16]: >>>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>>> <panto@antoniou-consulting.com> wrote: >>>>> >>>>> Another can of worms is the pinctrl nodes. >>>> >>>> Yes... new pinctrl data would need to trigger adding new data to >>>> pinctrl. I don't know if the pinctrl api supports that. >>> >>> The actual pins stay the same, just their configuration >>> changes. AFAIK all that is already supported using the >>> pinctrl framework. >>> >>> For example, considering hotplugging capes on the beaglebone: ... >> That assumes that for a particular external bus, certain pins aren't >> already shared with functions already on the board, for instance if an >> I²C bus brought out to the external bus already has a chip connected >> to it. > > This is our case on the bone. We don't enable the peripheral until > a cape that references it is enabled. > > I don't think that very big changes are going to be needed TBH. ... > Ideally if we could do this in the cape definition: > > cape_pinmux { > parent = <&am3358_pinmux>; I think the cape overlay would simply add nodes to the existing pin controller node, so I'd presume you would replace the two lines immediately above with: am3358_pinmux: pinmux { > > bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { > pinctrl-single,pins = < > 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ > 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ > >; > }; > > pinctrl-0 = <&bone_geiger_cape_pins>; ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 22:17 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-06 22:17 UTC (permalink / raw) To: Pantelis Antoniou Cc: Russ Dill, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, linux-omap, devicetree-discuss On 11/06/2012 12:41 PM, Pantelis Antoniou wrote: > Hi Russ, > > On Nov 6, 2012, at 8:29 PM, Russ Dill wrote: > >> On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <tony@atomide.com> wrote: >>> * Grant Likely <grant.likely@secretlab.ca> [121106 03:16]: >>>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>>> <panto@antoniou-consulting.com> wrote: >>>>> >>>>> Another can of worms is the pinctrl nodes. >>>> >>>> Yes... new pinctrl data would need to trigger adding new data to >>>> pinctrl. I don't know if the pinctrl api supports that. >>> >>> The actual pins stay the same, just their configuration >>> changes. AFAIK all that is already supported using the >>> pinctrl framework. >>> >>> For example, considering hotplugging capes on the beaglebone: ... >> That assumes that for a particular external bus, certain pins aren't >> already shared with functions already on the board, for instance if an >> I²C bus brought out to the external bus already has a chip connected >> to it. > > This is our case on the bone. We don't enable the peripheral until > a cape that references it is enabled. > > I don't think that very big changes are going to be needed TBH. ... > Ideally if we could do this in the cape definition: > > cape_pinmux { > parent = <&am3358_pinmux>; I think the cape overlay would simply add nodes to the existing pin controller node, so I'd presume you would replace the two lines immediately above with: am3358_pinmux: pinmux { > > bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { > pinctrl-single,pins = < > 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | MODE7 */ > 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | MODE7 */ > >; > }; > > pinctrl-0 = <&bone_geiger_cape_pins>; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 11:14 ` Grant Likely 2012-11-06 18:35 ` Tony Lindgren @ 2012-11-06 19:34 ` Pantelis Antoniou 2012-11-06 20:45 ` Grant Likely 1 sibling, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-06 19:34 UTC (permalink / raw) To: Grant Likely Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Grant, 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: >> Hi Grant, >> >> On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: >> >>> Hey folks, >>> >>> As promised, here is my early draft to try and capture what device >>> tree overlays need to do and how to get there. Comments and >>> suggestions greatly appreciated. >>> >>> Device Tree Overlay Feature >>> >>> Purpose >>> ======= >>> Sometimes it is not convenient to describe an entire system with a >>> single FDT. For example, processor modules that are plugged into one or >>> more modules (a la the BeagleBone), or systems with an FPGA peripheral >>> that is programmed after the system is booted. >>> >>> For these cases it is proposed to implement an overlay feature for the >>> so that the initial device tree data can be modified by userspace at >>> runtime by loading additional overlay FDTs that amend the original data. >>> >>> User Stories >>> ============ >>> Note - These are potential use cases, but just because it is listed here >>> doesn't mean it is important. I just want to thoroughly think through the >>> implications before making design decisions. >>> >>> >>> 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. >>> >>> Jane solves this problem by storing an FDT overlay for each cape in the >>> root filesystem. When the kernel detects that a cape is installed it >>> reads the cape's eeprom to identify it and uses request_firmware() to >>> obtain the appropriate overlay. Userspace passes the overlay to the >>> kernel in the normal way. If the cape doesn't have an eeprom, then the >>> kernel will still use firmware_request(), but userspace needs to already >>> know which cape is installed. >> >> Jane is a really productive hardware engineer - she manages to fix a >> number of problems with her cape design by spinning different revisions >> of the cape. Using the flexibility that the DT provides, documents and >> defines the hardware changes of the cape revisions in the FDT overlay. >> The loader matches the revision of the cape with the proper FDT overlay >> so that the drivers are relieved of having to do revision management. > > Okay > >>> By installing dtc on the Pi, Mandy compiles the overlay for her >>> prototype hardware. However, she doesn't have a copy of the Pi's >>> original FDT source, so instead she uses the dtc 'fs' input format to >>> compile the overlay file against the live DT data in /proc. >> >> Jane (the cape designer) can use this too. Developing the cape, she really >> appreciates that she doesn't have to reboot every time she makes a change >> in the cape hardware. By removing the FDT overlay, compiling with the dtc >> on the board, and re-inserting the overlay, she can be more productive by >> waiting less. > > Yes, but I'll leave this paragraph out of the spec. It isn't > significantly different from what is already there. > No problem. >> Johnny, Jane's little son, doesn't know anything about device trees, linux >> kernel trees, or hard-core s/w engineering. He is a bright kid, and due to >> the board having a node.js based educational electronic design kit, he >> can use the web-based simplified development environment, that allows >> him graphically to connect the parts in his kit. He can save the design >> and the IDE creates on the fly the DT overlay for later use. > > Yes. > >>> Joanne has purchased one of Jane's capes and packaged it into a rugged >>> case for data logging. As far as Joanne is concerned, the BeagleBone and >>> cape together are a single unit and she'd prefer a single monolithic FDT >>> instead of using an FDT overlay. >>> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >>> to generate a single .dtb for the entire system which is >>> loaded by U-Boot. -or- >> Unlikely. >>> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >>> (instead of .dts files), -or- >> Possible but low probability. >>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>> and passes the resolved tree to the kernel. >> Could be made to work. Only really required if Joanne wants the >> cape interface to work for u-boot too. For example if the cape has some >> kind of network interface that u-boot will use to boot from. > > Unlikely for your focus perhaps, but I'm trying to capture all the > relevant permutations, and I can guarantee that some people really > will want this. If not on the bone, then on some other platform. > No problem there. Certainly they are valid scenarios. >>> Summary points: >>> - Create an FDT overlay data format and usage model >>> - SHALL reliable resolve or validate of phandles between base and >>> overlay trees >>> - SHOULD reliably handle changes between different underlying overlays >>> (ie. what happens to existing .dtb overly files if the structure of >>> the dtb it is layered over changes. If not possible, then SHALL >>> detect when the base tree doesn't match and refuse to apply the >>> overlay. >>> - dts syntax needs to be extended for overlay .dtb files >>> - DTC tool needs to be modified to support overlay .dtb generation >>> - Overlays SHOULD be able to be applied either by firmware or the kernel >>> - libfdt SHALL be extended to parse and apply overlays >> >> - ftdump should be fixed and work for the overlay syntax too. > > Okay > >> This is much grander in vision that I had in mind :) >> >> It can handle our use cases, but I'm worried if we're bitting more >> that what we can chew. Perhaps a staged approach? I.e. target the >> low hanging fruit first, get it work, and then work on the hardest >> parts? > > Actually, I'm not to scared about the work and yes I think that it > *must* be a staged approach. To start focus on adding overlays without > phandle resolution (phandles must match) or unloading support. > Unloading and phandle resolution can be separate follow-on features. > Unloading and phandle resolution are the hard bits anyway. > Okay. >>> It may be sufficient to solve it by making the phandle values less >>> volatile. Right now dtc generates phandles linearly. Generated phandles >>> could be overridden with explicit phandle properties, but it isn't a >>> fantastic solution. Perhaps generating the phandle from a hash of the >>> node name would be sufficient. >>> >> >> I doubt the hash method will work reliably. We only have 32 bits to work with, >> nothing like the SHA hashes of git. >> > > I think the biggest trees have on the order of 100 nodes and a 32 bit > numberspace is 4Gi. Surely collisions can be avoided. :-) > > It is also possible to explicitly specify the phandle when the hash > method breaks down, or if the node full path needs to change, but I'd > like to avoid that approach as much as possible. > Something like foo = <&bar>; unresolved-phandle-paths { bar = "/soc/bar@deadbeef"; } ? It is not very nice looking admittedly. Could you explain your hashing method a bit? How will you deal with the possible conflicts? >> 5) Have a method to attach FDT overlay to a kernel module. >> >> For some drivers it might be better if the kernel module and the >> DT overlay is packaged in the same file. You be in a part of >> the module binary as a special section that request_firmware can >> pick up automatically. > > It used to be that firmware blobs could be linked into the kernel and > request_firmware() would find them. I'd like to investigate if that is > still possible. > It should work. Modules should work too. >>> Add support to remove an overlay (question: is this important?) >>> >> >> 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. 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. So let's think about locking too. >>> Workitems: >>> Modify of_platform_populate() to get new node notifications >>> Modify of_register_spi_devices to get new node notifications >>> Modify of_register_i2c_devices to get new node notifications >>> >> >> w1 is the same. Possibly more. > > w1? One-Wire. Very simple sensor bus using one wire. > >> >> Another can of worms is the pinctrl nodes. > > Yes... new pinctrl data would need to trigger adding new data to > pinctrl. I don't know if the pinctrl api supports that. > I would be happy for now just being able to move the pinctrl definitions in the DT fragment. I have been told this has been a topic of discussion and people decided that their place being all together was better. I'm hoping we can address this. >> >>> 6) Other work >>> ------------- >>> The device node user space interface could use some work. Here are some >>> random work items that are peripherally related to the overlay feature. >>> >>> Other Workitems: >>> Define FDT schema syntax >>> Add FDT schema support to FDT (basically lint-style testing) >>> Investigate runtime schema validation >>> Make device_nodes first-class kobjects and remove the procfs interface >>> - it can be emulated with a symlink >>> Add symlinks from devices to devicetree nodes in sysfs >> >> That's going to take a while :) > > :-) But as you've already pointed out this should be taken in a staged > approach. Simple overlay support is still useful and shouldn't be too > complex to implement. > Famous last words... :) > g. One final thing. Some people have expressed concern that DT processing tends to take some time; time that badly affects booting speed. Perhaps if large parts of the DT are disabled, or if the system can operate in some manner using a lazy parsing method, we could look at that too. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 19:34 ` Pantelis Antoniou @ 2012-11-06 20:45 ` Grant Likely 2012-11-06 20:50 ` Grant Likely ` (2 more replies) 0 siblings, 3 replies; 135+ messages in thread From: Grant Likely @ 2012-11-06 20:45 UTC (permalink / raw) To: Pantelis Antoniou Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss 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(-) 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. > 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. > So let's think about locking too Yes, the locking does need to be sorted out. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 20:45 ` Grant Likely @ 2012-11-06 20:50 ` Grant Likely 2012-11-07 8:06 ` Pantelis Antoniou 2012-11-07 8:13 ` Pantelis Antoniou 2 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-06 20:50 UTC (permalink / raw) To: Pantelis Antoniou Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Tue, Nov 6, 2012 at 8:45 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > 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(-) Make that 96 insertions. I got an extra patch caught up in that diffstat. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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-09 17:03 ` Grant Likely 2012-11-07 8:13 ` Pantelis Antoniou 2 siblings, 2 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 8:06 UTC (permalink / raw) To: Grant Likely Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss 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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 8:06 ` Pantelis Antoniou @ 2012-11-07 15:33 ` Alan Tull 2012-11-09 17:03 ` Grant Likely 1 sibling, 0 replies; 135+ messages in thread From: Alan Tull @ 2012-11-07 15:33 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss 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 > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 15:33 ` Alan Tull 0 siblings, 0 replies; 135+ messages in thread From: Alan Tull @ 2012-11-07 15:33 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss 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 > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 8:06 ` Pantelis Antoniou 2012-11-07 15:33 ` Alan Tull @ 2012-11-09 17:03 ` Grant Likely 1 sibling, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 17:03 UTC (permalink / raw) To: Pantelis Antoniou Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Wed, Nov 7, 2012 at 8:06 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > Hi Grant, > > On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: >> Yes, the locking does need to be sorted out. >> > > Perhaps come up with a dt-stress test tool/boot time validator? I would like that. I've started adding DT test cases to the kernel source tree. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 20:45 ` Grant Likely 2012-11-06 20:50 ` Grant Likely 2012-11-07 8:06 ` Pantelis Antoniou @ 2012-11-07 8:13 ` Pantelis Antoniou 2012-11-07 10:19 ` Benoit Cousson 2 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 8:13 UTC (permalink / raw) To: Grant Likely Cc: Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss 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: [ snip ] > > g. Since we've started talking about longer term goals, and the versioning provision seems to stand, I hope we address how much the fragment versioning thing is similar to the way board revisions progress. If a versioning syntax is available then one could create a single DT file for a bunch of 'almost' similar board and board revisions. Using a single DTB in the same manner you have a single uImage would make some people quite happy, since you won't have to do any bootloader magic to make sure you pass the correct DTB for the specific revision. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 10:19 ` Benoit Cousson 0 siblings, 0 replies; 135+ messages in thread From: Benoit Cousson @ 2012-11-07 10:19 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Panto, On 11/07/2012 09:13 AM, 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: > > [ snip ] >> >> g. > > Since we've started talking about longer term goals, and the versioning > provision seems to stand, I hope we address how much the fragment versioning > thing is similar to the way board revisions progress. > > If a versioning syntax is available then one could create a single DT > file for a bunch of 'almost' similar board and board revisions. I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: compatible-version = "ti,panda-version", "panda"; Then at runtime we should create only the node with the correct match between the driver version and the string version. /* regular panda audio routing */ sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; compatible-version = "ti,panda-version", "panda"; /* Audio routing */ ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", "AFMR", "Line In"; }; /* Audio routing is different between PandaBoard4430 and PandaBoardES */ &sound { ti,model = "PandaBoardES"; compatible-version = "ti,panda-version", "panda-es"; /* Audio routing */ ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", "AFMR", "Line In"; }; Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 10:19 ` Benoit Cousson 0 siblings, 0 replies; 135+ messages in thread From: Benoit Cousson @ 2012-11-07 10:19 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Panto, On 11/07/2012 09:13 AM, 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-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: > > [ snip ] >> >> g. > > Since we've started talking about longer term goals, and the versioning > provision seems to stand, I hope we address how much the fragment versioning > thing is similar to the way board revisions progress. > > If a versioning syntax is available then one could create a single DT > file for a bunch of 'almost' similar board and board revisions. I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: compatible-version = "ti,panda-version", "panda"; Then at runtime we should create only the node with the correct match between the driver version and the string version. /* regular panda audio routing */ sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; compatible-version = "ti,panda-version", "panda"; /* Audio routing */ ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", "AFMR", "Line In"; }; /* Audio routing is different between PandaBoard4430 and PandaBoardES */ &sound { ti,model = "PandaBoardES"; compatible-version = "ti,panda-version", "panda-es"; /* Audio routing */ ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", "AFMR", "Line In"; }; Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 10:19 ` Benoit Cousson @ 2012-11-07 11:02 ` Pantelis Antoniou -1 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 11:02 UTC (permalink / raw) To: Benoit Cousson Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Benoit, On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > Hi Panto, > > On 11/07/2012 09:13 AM, 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: >> >> [ snip ] >>> >>> g. >> >> Since we've started talking about longer term goals, and the versioning >> provision seems to stand, I hope we address how much the fragment versioning >> thing is similar to the way board revisions progress. >> >> If a versioning syntax is available then one could create a single DT >> file for a bunch of 'almost' similar board and board revisions. > > I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. > > Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. > > We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. > > Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: > > compatible-version = "ti,panda-version", "panda"; > > Then at runtime we should create only the node with the correct match between the driver version and the string version. > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > /* regular panda audio routing */ > sound: sound { > compatible = "ti,abe-twl6040"; > ti,model = "PandaBoard"; > compatible-version = "ti,panda-version", "panda"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > > /* Audio routing is different between PandaBoard4430 and PandaBoardES */ > &sound { > ti,model = "PandaBoardES"; > compatible-version = "ti,panda-version", "panda-es"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > We use this syntax for capebus (totally non-standard of-course), sound: sound { compatible = "ti,abe-twl6040"; model@0 { ti,model = "PandaBoard"; ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", "AFMR", "Line In"; }; model@1 { ti,model = "PandaBoardES"; ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", "AFMR", "Line In"; }; /* common properties for either model */ }; The difference is that you don't get to repeat the common properties. I don't know if this breaks any conventions but seems to work fine for our case. > > Maybe some extra version match table can just be passed during the board machine_init > > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. > > Regards, > Benoit Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 11:02 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 11:02 UTC (permalink / raw) To: Benoit Cousson Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Benoit, On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > Hi Panto, > > On 11/07/2012 09:13 AM, 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: >> >> [ snip ] >>> >>> g. >> >> Since we've started talking about longer term goals, and the versioning >> provision seems to stand, I hope we address how much the fragment versioning >> thing is similar to the way board revisions progress. >> >> If a versioning syntax is available then one could create a single DT >> file for a bunch of 'almost' similar board and board revisions. > > I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. > > Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. > > We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. > > Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: > > compatible-version = "ti,panda-version", "panda"; > > Then at runtime we should create only the node with the correct match between the driver version and the string version. > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > /* regular panda audio routing */ > sound: sound { > compatible = "ti,abe-twl6040"; > ti,model = "PandaBoard"; > compatible-version = "ti,panda-version", "panda"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > > /* Audio routing is different between PandaBoard4430 and PandaBoardES */ > &sound { > ti,model = "PandaBoardES"; > compatible-version = "ti,panda-version", "panda-es"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > We use this syntax for capebus (totally non-standard of-course), sound: sound { compatible = "ti,abe-twl6040"; model@0 { ti,model = "PandaBoard"; ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", "AFMR", "Line In"; }; model@1 { ti,model = "PandaBoardES"; ti,audio-routing = "Headset Stereophone", "HSOL", "Headset Stereophone", "HSOR", "Ext Spk", "HFL", "Ext Spk", "HFR", "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", "AFMR", "Line In"; }; /* common properties for either model */ }; The difference is that you don't get to repeat the common properties. I don't know if this breaks any conventions but seems to work fine for our case. > > Maybe some extra version match table can just be passed during the board machine_init > > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. > > Regards, > Benoit Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 11:12 ` Benoit Cousson 0 siblings, 0 replies; 135+ messages in thread From: Benoit Cousson @ 2012-11-07 11:12 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: > Hi Benoit, > > On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> > > We use this syntax for capebus (totally non-standard of-course), > > sound: sound { > compatible = "ti,abe-twl6040"; > > > model@0 { > ti,model = "PandaBoard"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > model@1 { > ti,model = "PandaBoardES"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > /* common properties for either model */ > }; > > The difference is that you don't get to repeat the common properties. > > I don't know if this breaks any conventions but seems to work fine for our case. Yeah, my main concern with that approach is that you change the structure of the tree by adding an extra node/hierarchy that will not be there in case of non-versioned tree. That's why I think we should have something lighter that will not change the structure. Ideally we should be able to add extra versioned node to the original dts without changing it at all. >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >> > > Would we need explicit of_platform_populate calls if we have node modification notifiers? > In that case the notifier would pick it up automatically, and can do the per > version matching internally. Yes indeed, but here I was thinking about an intermediate step, i.e. now, without any dynamic node insertion mechanism. Thanks to this simple approach, when can already fix the board versionning problem. Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 11:12 ` Benoit Cousson 0 siblings, 0 replies; 135+ messages in thread From: Benoit Cousson @ 2012-11-07 11:12 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: > Hi Benoit, > > On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> > > We use this syntax for capebus (totally non-standard of-course), > > sound: sound { > compatible = "ti,abe-twl6040"; > > > model@0 { > ti,model = "PandaBoard"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > model@1 { > ti,model = "PandaBoardES"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > /* common properties for either model */ > }; > > The difference is that you don't get to repeat the common properties. > > I don't know if this breaks any conventions but seems to work fine for our case. Yeah, my main concern with that approach is that you change the structure of the tree by adding an extra node/hierarchy that will not be there in case of non-versioned tree. That's why I think we should have something lighter that will not change the structure. Ideally we should be able to add extra versioned node to the original dts without changing it at all. >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >> > > Would we need explicit of_platform_populate calls if we have node modification notifiers? > In that case the notifier would pick it up automatically, and can do the per > version matching internally. Yes indeed, but here I was thinking about an intermediate step, i.e. now, without any dynamic node insertion mechanism. Thanks to this simple approach, when can already fix the board versionning problem. Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 11:12 ` Benoit Cousson @ 2012-11-07 11:23 ` Pantelis Antoniou -1 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 11:23 UTC (permalink / raw) To: Benoit Cousson Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Benoit, On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote: > On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: >> Hi Benoit, >> [snip] >> I don't know if this breaks any conventions but seems to work fine for our case. > > Yeah, my main concern with that approach is that you change the > structure of the tree by adding an extra node/hierarchy that will not be > there in case of non-versioned tree. > That's why I think we should have something lighter that will not change > the structure. > Ideally we should be able to add extra versioned node to the original > dts without changing it at all. > You will still need the versioned nodes to be injected to the non-versioned ones. FWIW the driver will use the standard of_property_read_* interface. You can patch of_property_read to hide the version node matching, and it will work. I'll leave Grant answer what approach is better, I don't claim to have the insight to handle all cases. >>> Maybe some extra version match table can just be passed during the board machine_init >>> >>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>> >> >> Would we need explicit of_platform_populate calls if we have node modification notifiers? >> In that case the notifier would pick it up automatically, and can do the per >> version matching internally. > > Yes indeed, but here I was thinking about an intermediate step, i.e. > now, without any dynamic node insertion mechanism. > Thanks to this simple approach, when can already fix the board > versionning problem. > As I pointed, with a kind of injection mechanism. the versioned node contents end up in the proper place in the device tree. Your method will work in a much more simpler way. > Regards, > Benoit > Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 11:23 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 11:23 UTC (permalink / raw) To: Benoit Cousson Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Benoit, On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote: > On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: >> Hi Benoit, >> [snip] >> I don't know if this breaks any conventions but seems to work fine for our case. > > Yeah, my main concern with that approach is that you change the > structure of the tree by adding an extra node/hierarchy that will not be > there in case of non-versioned tree. > That's why I think we should have something lighter that will not change > the structure. > Ideally we should be able to add extra versioned node to the original > dts without changing it at all. > You will still need the versioned nodes to be injected to the non-versioned ones. FWIW the driver will use the standard of_property_read_* interface. You can patch of_property_read to hide the version node matching, and it will work. I'll leave Grant answer what approach is better, I don't claim to have the insight to handle all cases. >>> Maybe some extra version match table can just be passed during the board machine_init >>> >>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>> >> >> Would we need explicit of_platform_populate calls if we have node modification notifiers? >> In that case the notifier would pick it up automatically, and can do the per >> version matching internally. > > Yes indeed, but here I was thinking about an intermediate step, i.e. > now, without any dynamic node insertion mechanism. > Thanks to this simple approach, when can already fix the board > versionning problem. > As I pointed, with a kind of injection mechanism. the versioned node contents end up in the proper place in the device tree. Your method will work in a much more simpler way. > Regards, > Benoit > Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 11:02 ` Pantelis Antoniou (?) (?) @ 2012-11-09 20:33 ` Grant Likely 2012-11-12 11:34 ` Pantelis Antoniou -1 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-09 20:33 UTC (permalink / raw) To: Pantelis Antoniou Cc: Benoit Cousson, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >> > > Would we need explicit of_platform_populate calls if we have node modification notifiers? > In that case the notifier would pick it up automatically, and can do the per > version matching internally. There still needs to be something to register "everything below this node is interesting" which is exactly what of_platform_populate() does now. I see the notifiers being used by the of_platform_populate backend to know when nodes have been created (or destroyed). g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 20:33 ` Grant Likely @ 2012-11-12 11:34 ` Pantelis Antoniou 2012-11-12 13:01 ` Grant Likely 0 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 11:34 UTC (permalink / raw) To: Grant Likely Cc: Benoit Cousson, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Grant, On Nov 9, 2012, at 10:33 PM, Grant Likely wrote: > On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: >> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: >>> Maybe some extra version match table can just be passed during the board machine_init >>> >>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>> >> >> Would we need explicit of_platform_populate calls if we have node modification notifiers? >> In that case the notifier would pick it up automatically, and can do the per >> version matching internally. > > There still needs to be something to register "everything below this > node is interesting" which is exactly what of_platform_populate() does > now. I see the notifiers being used by the of_platform_populate > backend to know when nodes have been created (or destroyed). > > g. I see. So of_platform_populate could just register the notifier and not do the tree walk itself. Perhaps the name is a bit misleading then? Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 11:34 ` Pantelis Antoniou @ 2012-11-12 13:01 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-12 13:01 UTC (permalink / raw) To: Pantelis Antoniou Cc: Benoit Cousson, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Mon, Nov 12, 2012 at 11:34 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > Hi Grant, > > On Nov 9, 2012, at 10:33 PM, Grant Likely wrote: > >> On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou >> <panto@antoniou-consulting.com> wrote: >>> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: >>>> Maybe some extra version match table can just be passed during the board machine_init >>>> >>>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>>> >>> >>> Would we need explicit of_platform_populate calls if we have node modification notifiers? >>> In that case the notifier would pick it up automatically, and can do the per >>> version matching internally. >> >> There still needs to be something to register "everything below this >> node is interesting" which is exactly what of_platform_populate() does >> now. I see the notifiers being used by the of_platform_populate >> backend to know when nodes have been created (or destroyed). >> >> g. > > I see. So of_platform_populate could just register the notifier and > not do the tree walk itself. Perhaps the name is a bit misleading then? Kind of, yes. of_platform_populate() would still have the same effect that it does now except that it would also pay attention to additions and removals from the DT nodes it is interested in. This would work cleanly enough for node additions/removals, but it wouldn't process changes to properties on existing nodes. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 10:19 ` Benoit Cousson (?) (?) @ 2012-11-07 17:25 ` Stephen Warren 2012-11-07 22:10 ` Pantelis Antoniou 2012-11-08 10:36 ` Cousson, Benoit -1 siblings, 2 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-07 17:25 UTC (permalink / raw) To: Benoit Cousson Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/07/2012 03:19 AM, Benoit Cousson wrote: > Hi Panto, > > On 11/07/2012 09:13 AM, 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: >> >> [ snip ] >>> >>> g. >> >> Since we've started talking about longer term goals, and the versioning >> provision seems to stand, I hope we address how much the fragment versioning >> thing is similar to the way board revisions progress. >> >> If a versioning syntax is available then one could create a single DT >> file for a bunch of 'almost' similar board and board revisions. > > I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. > > Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. > > We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. > > Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: > > compatible-version = "ti,panda-version", "panda"; > > Then at runtime we should create only the node with the correct match between the driver version and the string version. > > > /* regular panda audio routing */ > sound: sound { > compatible = "ti,abe-twl6040"; > ti,model = "PandaBoard"; > compatible-version = "ti,panda-version", "panda"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > > /* Audio routing is different between PandaBoard4430 and PandaBoardES */ > &sound { > ti,model = "PandaBoardES"; > compatible-version = "ti,panda-version", "panda-es"; > > /* Audio routing */ > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > > Maybe some extra version match table can just be passed during the board machine_init > > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Is the only difference here the content of the ti,audio-routing property? If so, then I don't think there's any need for infra-structure for this; the driver code already reads that property and adjusts its behaviour based upon it. I do see that "Headset Mic" exists only in one of the tables above. Perhaps the driver could scan the routing table, and only create the ASoC object for the headset if it's mentioned in the routing table? If there are additional differences, then you can always use the .data field in of_device_id to automatically associate some configuration data with different compatible values. Even better might be to extend the binding so that all HW differences are represented explicitly as properties; that way you wouldn't even need different compatible values. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 22:10 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 22:10 UTC (permalink / raw) To: Stephen Warren Cc: Benoit Cousson, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 7, 2012, at 6:25 PM, Stephen Warren wrote: > On 11/07/2012 03:19 AM, Benoit Cousson wrote: >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > > Is the only difference here the content of the ti,audio-routing > property? If so, then I don't think there's any need for infra-structure > for this; the driver code already reads that property and adjusts its > behaviour based upon it. > > I do see that "Headset Mic" exists only in one of the tables above. > Perhaps the driver could scan the routing table, and only create the > ASoC object for the headset if it's mentioned in the routing table? > > If there are additional differences, then you can always use the .data > field in of_device_id to automatically associate some configuration data > with different compatible values. > > Even better might be to extend the binding so that all HW differences > are represented explicitly as properties; that way you wouldn't even > need different compatible values. I think that perhaps the choice of the SoC specific driver was unfortunate. There are cases where a standard driver should be configured differently depending on the board revision/model. In that case per-revision driver changes are out of the question. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 22:10 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 22:10 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Stephen, On Nov 7, 2012, at 6:25 PM, Stephen Warren wrote: > On 11/07/2012 03:19 AM, Benoit Cousson wrote: >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > > Is the only difference here the content of the ti,audio-routing > property? If so, then I don't think there's any need for infra-structure > for this; the driver code already reads that property and adjusts its > behaviour based upon it. > > I do see that "Headset Mic" exists only in one of the tables above. > Perhaps the driver could scan the routing table, and only create the > ASoC object for the headset if it's mentioned in the routing table? > > If there are additional differences, then you can always use the .data > field in of_device_id to automatically associate some configuration data > with different compatible values. > > Even better might be to extend the binding so that all HW differences > are represented explicitly as properties; that way you wouldn't even > need different compatible values. I think that perhaps the choice of the SoC specific driver was unfortunate. There are cases where a standard driver should be configured differently depending on the board revision/model. In that case per-revision driver changes are out of the question. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 17:25 ` Stephen Warren @ 2012-11-08 10:36 ` Cousson, Benoit 2012-11-08 10:36 ` Cousson, Benoit 1 sibling, 0 replies; 135+ messages in thread From: Cousson, Benoit @ 2012-11-08 10:36 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss, Peter Ujfalusi + Peter Hi Stephen, On 11/7/2012 6:25 PM, Stephen Warren wrote: > On 11/07/2012 03:19 AM, Benoit Cousson wrote: >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > > Is the only difference here the content of the ti,audio-routing > property? If so, then I don't think there's any need for infra-structure > for this; the driver code already reads that property and adjusts its > behaviour based upon it. That was just an example, and maybe not the best one. It could be any kind of HW differences, like a different GPIO line, a different I2C peripheral, an extra DCDC... The point was just that you might have several version of the same node with different attributes depending of the board revision. Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-08 10:36 ` Cousson, Benoit 0 siblings, 0 replies; 135+ messages in thread From: Cousson, Benoit @ 2012-11-08 10:36 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss, Peter Ujfalusi + Peter Hi Stephen, On 11/7/2012 6:25 PM, Stephen Warren wrote: > On 11/07/2012 03:19 AM, Benoit Cousson wrote: >> Hi Panto, >> >> On 11/07/2012 09:13 AM, 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: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); > > Is the only difference here the content of the ti,audio-routing > property? If so, then I don't think there's any need for infra-structure > for this; the driver code already reads that property and adjusts its > behaviour based upon it. That was just an example, and maybe not the best one. It could be any kind of HW differences, like a different GPIO line, a different I2C peripheral, an extra DCDC... The point was just that you might have several version of the same node with different attributes depending of the board revision. Regards, Benoit ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 10:30 ` Pantelis Antoniou 2012-11-06 11:14 ` Grant Likely @ 2012-11-09 5:32 ` Joel A Fernandes 2012-11-09 14:29 ` David Gibson ` (2 more replies) [not found] ` <-4237940489086529028@unknownmsgid> 2 siblings, 3 replies; 135+ messages in thread From: Joel A Fernandes @ 2012-11-09 5:32 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Pantelis, I hope I'm not too late to reply as I'm traveling. On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > >> >> Joanne has purchased one of Jane's capes and packaged it into a rugged >> case for data logging. As far as Joanne is concerned, the BeagleBone and >> cape together are a single unit and she'd prefer a single monolithic FDT >> instead of using an FDT overlay. >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >> to generate a single .dtb for the entire system which is >> loaded by U-Boot. -or- > > Unlikely. >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >> (instead of .dts files), -or- > Possible but low probability. > >> Option C: U-Boot loads both the base and overlay FDT files, merges them, >> and passes the resolved tree to the kernel. >> > > Could be made to work. Only really required if Joanne wants the > cape interface to work for u-boot too. For example if the cape has some > kind of network interface that u-boot will use to boot from. > I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the simple tree merging for all cases, and not the kernel reasons mentioned below. (1) >From a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. (2) Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. I think doing tree merging in kernel is messy and we should do it in uboot considering we might have to read EEPROM for this use case. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. >> > > I doubt the hash method will work reliably. We only have 32 bits to work with, > nothing like the SHA hashes of git. > I was wondering I have worked with kernel's crypto code in the past to generate 32 bit md5sums of 1000s of dataitems, from what I've seen, collisions are rare and since we are talking about just a few nodes that are being referenced in the base dt. I think the probability is even less (ofcourse such an analysis strongly depends on dataset). this method also takes away a lot of complexity with having it to do runtime fixups and will help us get off the ground quickly. We can also put in a collision handling mechanism if needed. I think it is worthy doing a sample hash of all nodes in all dts we have in a script and see for once if we have collisions and what it looks like. Alternatively to hashing, reading David Gibson's paper I followed, phandle is supposed to 'uniquely' identity node. I wonder why the node name itself is not sufficient to uniquely identify. The code that does the tree walking can then just strcmp the node name while it walks the tree instead of having to find a node with a phandle number. I guess the reason is phandles are small to store as data values. Another approach can be to arrange the string block in alphabetical order (unless it already is), and store phandle as index of the node name referenced relative to the starting of the strong block. This will not affect nodes in dtb being moved around since they will still have the same index value. the problem being adding or removing nodes Changes the index of all other nodes in the string block as well.. Hmm. Regards, Joel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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-09 22:59 ` Stephen Warren 2 siblings, 1 reply; 135+ messages in thread From: David Gibson @ 2012-11-09 14:29 UTC (permalink / raw) To: Joel A Fernandes Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 09, 2012 at 12:32:09AM -0500, Joel A Fernandes wrote: > Hi Pantelis, > > I hope I'm not too late to reply as I'm traveling. > > On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > > >> Joanne has purchased one of Jane's capes and packaged it into a rugged > >> case for data logging. As far as Joanne is concerned, the BeagleBone and > >> cape together are a single unit and she'd prefer a single monolithic FDT > >> instead of using an FDT overlay. > >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files > >> to generate a single .dtb for the entire system which is > >> loaded by U-Boot. -or- > > > > Unlikely. > >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files > >> (instead of .dts files), -or- > > Possible but low probability. > > > >> Option C: U-Boot loads both the base and overlay FDT files, merges them, > >> and passes the resolved tree to the kernel. > >> > > > > Could be made to work. Only really required if Joanne wants the > > cape interface to work for u-boot too. For example if the cape has some > > kind of network interface that u-boot will use to boot from. > > > > I love Grant's hashing idea a lot keeping the phandle problem for > compile time and not requiring fixups. Well, using a hash only moves the problem of fixed phandles to a problem of fixed node paths. The details of node paths are, if anything, more mutable than phandles. [snip] > Alternatively to hashing, reading David Gibson's paper I followed, > phandle is supposed to 'uniquely' identity node. I wonder why the node > name itself is not sufficient to uniquely identify. Node names are not unique, not even close. If you have two similar NICs in slot 0 of two different PCI domains, they'll almost certainly both be called 'ethernet@0,0'. Similar examples abound on other buses. Node paths are unique, but they are long. The other big reason for phandles in OF history is that they would be more stable than paths. The device tree could be manipulated during OF runtime, but phandles would generally be internal pointers in OF and so remain a consistent handle even if the node moved in the tree. That's not really relevant for flat trees, but we need to work with the same structures. > The code that does > the tree walking can then just strcmp the node name while it walks the > tree instead of having to find a node with a phandle number. I guess > the reason is phandles are small to store as data values. Another > approach can be to arrange the string block in alphabetical order > (unless it already is), They're not, and doing so would be a painful change to maintain compatibility across. And in any case only property names use the strings block, not node names. > and store phandle as index of the node name > referenced relative to the starting of the strong block. This will not > affect nodes in dtb being moved around since they will still have the > same index value. the problem being adding or removing nodes Changes > the index of all other nodes in the string block as well.. Hmm. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 14:29 ` David Gibson @ 2012-11-10 3:15 ` Joel A Fernandes 0 siblings, 0 replies; 135+ messages in thread From: Joel A Fernandes @ 2012-11-10 3:15 UTC (permalink / raw) To: David Gibson Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 8:29 AM, David Gibson <david@gibson.dropbear.id.au> wrote: > On Fri, Nov 09, 2012 at 12:32:09AM -0500, Joel A Fernandes wrote: >> Hi Pantelis, >> >> I hope I'm not too late to reply as I'm traveling. >> >> On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou >> <panto@antoniou-consulting.com> wrote: >> >> >> Joanne has purchased one of Jane's capes and packaged it into a rugged >> >> case for data logging. As far as Joanne is concerned, the BeagleBone and >> >> cape together are a single unit and she'd prefer a single monolithic FDT >> >> instead of using an FDT overlay. >> >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >> >> to generate a single .dtb for the entire system which is >> >> loaded by U-Boot. -or- >> > >> > Unlikely. >> >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >> >> (instead of .dts files), -or- >> > Possible but low probability. >> > >> >> Option C: U-Boot loads both the base and overlay FDT files, merges them, >> >> and passes the resolved tree to the kernel. >> >> >> > >> > Could be made to work. Only really required if Joanne wants the >> > cape interface to work for u-boot too. For example if the cape has some >> > kind of network interface that u-boot will use to boot from. >> > >> >> I love Grant's hashing idea a lot keeping the phandle problem for >> compile time and not requiring fixups. > > Well, using a hash only moves the problem of fixed phandles to a > problem of fixed node paths. The details of node paths are, if > anything, more mutable than phandles. So what you're saying is there's no way to make a phandle a signature of a (property of a node) since no one property is unique. If I follow, even node path can't be used because hash value changes if node is moved around in the tree. This shoots down the hashing idea then, which I guess is looked down upon anyway due to dynamic changes to the base DT as discussed in the usecases. > [snip] >> Alternatively to hashing, reading David Gibson's paper I followed, >> phandle is supposed to 'uniquely' identity node. I wonder why the node >> name itself is not sufficient to uniquely identify. > > Node names are not unique, not even close. If you have two similar > NICs in slot 0 of two different PCI domains, they'll almost certainly > both be called 'ethernet@0,0'. Similar examples abound on other > buses. Node paths are unique, but they are long. > > The other big reason for phandles in OF history is that they would be > more stable than paths. The device tree could be manipulated during > OF runtime, but phandles would generally be internal pointers in OF > and so remain a consistent handle even if the node moved in the tree. > That's not really relevant for flat trees, but we need to work with > the same structures. Thanks. >> The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), > > They're not, and doing so would be a painful change to maintain > compatibility across. And in any case only property names use the > strings block, not node names. Understood, thanks. Regards, Joel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 5:32 ` Joel A Fernandes 2012-11-09 14:29 ` David Gibson @ 2012-11-09 21:22 ` Grant Likely 2012-11-12 11:47 ` Pantelis Antoniou 2012-11-13 3:59 ` Joel A Fernandes 2012-11-09 22:59 ` Stephen Warren 2 siblings, 2 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 21:22 UTC (permalink / raw) To: Joel A Fernandes Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes <agnel.joel@gmail.com> wrote: > Hi Pantelis, > > I hope I'm not too late to reply as I'm traveling. > > On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > >> >>> >>> Joanne has purchased one of Jane's capes and packaged it into a rugged >>> case for data logging. As far as Joanne is concerned, the BeagleBone and >>> cape together are a single unit and she'd prefer a single monolithic FDT >>> instead of using an FDT overlay. >>> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >>> to generate a single .dtb for the entire system which is >>> loaded by U-Boot. -or- >> >> Unlikely. >>> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >>> (instead of .dts files), -or- >> Possible but low probability. >> >>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>> and passes the resolved tree to the kernel. >>> >> >> Could be made to work. Only really required if Joanne wants the >> cape interface to work for u-boot too. For example if the cape has some >> kind of network interface that u-boot will use to boot from. >> > > I love Grant's hashing idea a lot keeping the phandle problem for > compile time and not requiring fixups. > > IMO it is still a cleaner approach if u-boot does the simple tree merging for > all cases, and not the kernel reasons mentioned below. I'm more than sufficiently convinced that making changes at runtime from userspace is pretty much required. Also consider: it is order of magnitudes easier to modify the kernel than it is to change the firmware for end users. > (1) > From a development standpoint, very little or nothing will > have to be changed in kernel (except for scripts/dtc) considering we > are moving forward with hashing. > > (2) > Also this discussed a while back but at some point is going to brought > up again- loading of dt fragment directly from EEPROM and merging at > run time. If we were to implement this in kernel, we would have to add > cape specific EEPROM reading code, merge the tree before it is > unflattened and parse. Unless it is required for boot to userspace I'm not considering merging before userspace starts. That's well after the tree is unflattened into the live form. If it is require to boot then I agree that is should be done in firmware. I see zero problem with having a beaglebone specific cape driver that knows to read the eeprom and request a specific configuration file. Heck, the kernel doesn't even need to parse the eeprom data. It can be read from userspace and userspace decides which overlay to provide. There's nothing stopping userspace from reading the eeprom, looking up the correct dts for the board, downloading the file from the Internet, compiling it with dtc and installing it.... and yes that is getting a little extreme. > I think doing tree merging in kernel is messy > and we should do it in uboot considering we might have to read EEPROM for > this use case. Ideally reading the fragment from the EEPROM for all capes > and merging without worrying about version detection, Doing the merge and > passing the merged blob to the kernel which (kernel) works the same way > it does today. > >>> It may be sufficient to solve it by making the phandle values less >>> volatile. Right now dtc generates phandles linearly. Generated phandles >>> could be overridden with explicit phandle properties, but it isn't a >>> fantastic solution. Perhaps generating the phandle from a hash of the >>> node name would be sufficient. >>> >> >> I doubt the hash method will work reliably. We only have 32 bits to work with, >> nothing like the SHA hashes of git. >> > > I was wondering I have worked with kernel's crypto code in the past to > generate 32 bit md5sums of 1000s of dataitems, from what I've seen, > collisions are rare and since we are talking about just a few nodes > that are being referenced in the base dt. I think the probability is > even less (ofcourse such an analysis strongly depends on dataset). > this method also takes away a lot of complexity with having it to do > runtime fixups and will help us get off the ground quickly. It wouldn't be hard to put together a test and run it on all the .dts files in the kernel; generating md5 sums for all the full_name paths and seeing if we've got any collisions yet. > We can also put in a collision handling mechanism if needed. > I think it is worthy doing a sample hash of all nodes in all dts we > have in a script and see for once if we have collisions and what it > looks like. Collision handling is a must, but again this is all internal to dtc. I don't foresee any problems with it. > Alternatively to hashing, reading David Gibson's paper I followed, > phandle is supposed to 'uniquely' identity node. I wonder why the node > name itself is not sufficient to uniquely identify. Simply because the FDT draws upon the existing OFW bindings which use a 32bit value to reference other nodes. > The code that does > the tree walking can then just strcmp the node name while it walks the > tree instead of having to find a node with a phandle number. I guess > the reason is phandles are small to store as data values. Another > approach can be to arrange the string block in alphabetical order > (unless it already is), and store phandle as index of the node name > referenced relative to the starting of the strong block. This will not > affect nodes in dtb being moved around since they will still have the > same index value. the problem being adding or removing nodes Changes > the index of all other nodes in the string block as well.. Hmm. And that still doesn't help find all the phandle locations in the tree for doing fixups. It would need to be a table of nodes+properties+offsets that contain phandles for fixup to work, but I shy away from that approach because I think it will be fragile. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 11:47 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 11:47 UTC (permalink / raw) To: Grant Likely Cc: Joel A Fernandes, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Grant, On Nov 9, 2012, at 11:22 PM, Grant Likely wrote: > On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes <agnel.joel@gmail.com> wrote: >> Hi Pantelis, >> >> I hope I'm not too late to reply as I'm traveling. >> >> On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou >> <panto@antoniou-consulting.com> wrote: >> >>> >>>> >>>> Joanne has purchased one of Jane's capes and packaged it into a rugged >>>> case for data logging. As far as Joanne is concerned, the BeagleBone and >>>> cape together are a single unit and she'd prefer a single monolithic FDT >>>> instead of using an FDT overlay. >>>> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >>>> to generate a single .dtb for the entire system which is >>>> loaded by U-Boot. -or- >>> >>> Unlikely. >>>> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >>>> (instead of .dts files), -or- >>> Possible but low probability. >>> >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>> and passes the resolved tree to the kernel. >>>> >>> >>> Could be made to work. Only really required if Joanne wants the >>> cape interface to work for u-boot too. For example if the cape has some >>> kind of network interface that u-boot will use to boot from. >>> >> >> I love Grant's hashing idea a lot keeping the phandle problem for >> compile time and not requiring fixups. >> >> IMO it is still a cleaner approach if u-boot does the simple tree merging for >> all cases, and not the kernel reasons mentioned below. > > I'm more than sufficiently convinced that making changes at runtime > from userspace is pretty much required. > > Also consider: it is order of magnitudes easier to modify the kernel > than it is to change the firmware for end users. > Complete agreement here. >> (1) >> From a development standpoint, very little or nothing will >> have to be changed in kernel (except for scripts/dtc) considering we >> are moving forward with hashing. >> >> (2) >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. > > Unless it is required for boot to userspace I'm not considering > merging before userspace starts. That's well after the tree is > unflattened into the live form. If it is require to boot then I agree > that is should be done in firmware. I see zero problem with having a > beaglebone specific cape driver that knows to read the eeprom and > request a specific configuration file. Heck, the kernel doesn't even > need to parse the eeprom data. It can be read from userspace and > userspace decides which overlay to provide. There's nothing stopping > userspace from reading the eeprom, looking up the correct dts for the > board, downloading the file from the Internet, compiling it with dtc > and installing it.... and yes that is getting a little extreme. > We're trying to come up with the method that will work best for us. >From an ease of use perspective, having a kernel driver doing the probing and performing the DT fragment insertion looks the best. It's especially nice for the manufacturer, since he can make sure that when he ships a board a single kernel image will contain everything with no possibility of RMAs. For h/w prototyping, where the user is tinkering around with his own design, the user space approach would be best. The downloading over the internet DTS file, is a bit extreme for now :) >> I think doing tree merging in kernel is messy >> and we should do it in uboot considering we might have to read EEPROM for >> this use case. Ideally reading the fragment from the EEPROM for all capes >> and merging without worrying about version detection, Doing the merge and >> passing the merged blob to the kernel which (kernel) works the same way >> it does today. >> >>>> It may be sufficient to solve it by making the phandle values less >>>> volatile. Right now dtc generates phandles linearly. Generated phandles >>>> could be overridden with explicit phandle properties, but it isn't a >>>> fantastic solution. Perhaps generating the phandle from a hash of the >>>> node name would be sufficient. >>>> >>> >>> I doubt the hash method will work reliably. We only have 32 bits to work with, >>> nothing like the SHA hashes of git. >>> >> >> I was wondering I have worked with kernel's crypto code in the past to >> generate 32 bit md5sums of 1000s of dataitems, from what I've seen, >> collisions are rare and since we are talking about just a few nodes >> that are being referenced in the base dt. I think the probability is >> even less (ofcourse such an analysis strongly depends on dataset). >> this method also takes away a lot of complexity with having it to do >> runtime fixups and will help us get off the ground quickly. > > It wouldn't be hard to put together a test and run it on all the .dts > files in the kernel; generating md5 sums for all the full_name paths > and seeing if we've got any collisions yet. > >> We can also put in a collision handling mechanism if needed. >> I think it is worthy doing a sample hash of all nodes in all dts we >> have in a script and see for once if we have collisions and what it >> looks like. > > Collision handling is a must, but again this is all internal to dtc. I > don't foresee any problems with it. > >> Alternatively to hashing, reading David Gibson's paper I followed, >> phandle is supposed to 'uniquely' identity node. I wonder why the node >> name itself is not sufficient to uniquely identify. > > Simply because the FDT draws upon the existing OFW bindings which use > a 32bit value to reference other nodes. > >> The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the index of all other nodes in the string block as well.. Hmm. > > And that still doesn't help find all the phandle locations in the tree > for doing fixups. It would need to be a table of > nodes+properties+offsets that contain phandles for fixup to work, but > I shy away from that approach because I think it will be fragile. > > g. Maybe, but IMHO it will work. I don't know, we're at the point where we have to start coding and see what come out. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 11:47 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 11:47 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, Deepak Saxena, Scott Wood, Joel A Fernandes, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Grant, On Nov 9, 2012, at 11:22 PM, Grant Likely wrote: > On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes <agnel.joel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Hi Pantelis, >> >> I hope I'm not too late to reply as I'm traveling. >> >> On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou >> <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >> >>> >>>> >>>> Joanne has purchased one of Jane's capes and packaged it into a rugged >>>> case for data logging. As far as Joanne is concerned, the BeagleBone and >>>> cape together are a single unit and she'd prefer a single monolithic FDT >>>> instead of using an FDT overlay. >>>> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >>>> to generate a single .dtb for the entire system which is >>>> loaded by U-Boot. -or- >>> >>> Unlikely. >>>> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >>>> (instead of .dts files), -or- >>> Possible but low probability. >>> >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>> and passes the resolved tree to the kernel. >>>> >>> >>> Could be made to work. Only really required if Joanne wants the >>> cape interface to work for u-boot too. For example if the cape has some >>> kind of network interface that u-boot will use to boot from. >>> >> >> I love Grant's hashing idea a lot keeping the phandle problem for >> compile time and not requiring fixups. >> >> IMO it is still a cleaner approach if u-boot does the simple tree merging for >> all cases, and not the kernel reasons mentioned below. > > I'm more than sufficiently convinced that making changes at runtime > from userspace is pretty much required. > > Also consider: it is order of magnitudes easier to modify the kernel > than it is to change the firmware for end users. > Complete agreement here. >> (1) >> From a development standpoint, very little or nothing will >> have to be changed in kernel (except for scripts/dtc) considering we >> are moving forward with hashing. >> >> (2) >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. > > Unless it is required for boot to userspace I'm not considering > merging before userspace starts. That's well after the tree is > unflattened into the live form. If it is require to boot then I agree > that is should be done in firmware. I see zero problem with having a > beaglebone specific cape driver that knows to read the eeprom and > request a specific configuration file. Heck, the kernel doesn't even > need to parse the eeprom data. It can be read from userspace and > userspace decides which overlay to provide. There's nothing stopping > userspace from reading the eeprom, looking up the correct dts for the > board, downloading the file from the Internet, compiling it with dtc > and installing it.... and yes that is getting a little extreme. > We're trying to come up with the method that will work best for us. >From an ease of use perspective, having a kernel driver doing the probing and performing the DT fragment insertion looks the best. It's especially nice for the manufacturer, since he can make sure that when he ships a board a single kernel image will contain everything with no possibility of RMAs. For h/w prototyping, where the user is tinkering around with his own design, the user space approach would be best. The downloading over the internet DTS file, is a bit extreme for now :) >> I think doing tree merging in kernel is messy >> and we should do it in uboot considering we might have to read EEPROM for >> this use case. Ideally reading the fragment from the EEPROM for all capes >> and merging without worrying about version detection, Doing the merge and >> passing the merged blob to the kernel which (kernel) works the same way >> it does today. >> >>>> It may be sufficient to solve it by making the phandle values less >>>> volatile. Right now dtc generates phandles linearly. Generated phandles >>>> could be overridden with explicit phandle properties, but it isn't a >>>> fantastic solution. Perhaps generating the phandle from a hash of the >>>> node name would be sufficient. >>>> >>> >>> I doubt the hash method will work reliably. We only have 32 bits to work with, >>> nothing like the SHA hashes of git. >>> >> >> I was wondering I have worked with kernel's crypto code in the past to >> generate 32 bit md5sums of 1000s of dataitems, from what I've seen, >> collisions are rare and since we are talking about just a few nodes >> that are being referenced in the base dt. I think the probability is >> even less (ofcourse such an analysis strongly depends on dataset). >> this method also takes away a lot of complexity with having it to do >> runtime fixups and will help us get off the ground quickly. > > It wouldn't be hard to put together a test and run it on all the .dts > files in the kernel; generating md5 sums for all the full_name paths > and seeing if we've got any collisions yet. > >> We can also put in a collision handling mechanism if needed. >> I think it is worthy doing a sample hash of all nodes in all dts we >> have in a script and see for once if we have collisions and what it >> looks like. > > Collision handling is a must, but again this is all internal to dtc. I > don't foresee any problems with it. > >> Alternatively to hashing, reading David Gibson's paper I followed, >> phandle is supposed to 'uniquely' identity node. I wonder why the node >> name itself is not sufficient to uniquely identify. > > Simply because the FDT draws upon the existing OFW bindings which use > a 32bit value to reference other nodes. > >> The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the index of all other nodes in the string block as well.. Hmm. > > And that still doesn't help find all the phandle locations in the tree > for doing fixups. It would need to be a table of > nodes+properties+offsets that contain phandles for fixup to work, but > I shy away from that approach because I think it will be fragile. > > g. Maybe, but IMHO it will work. I don't know, we're at the point where we have to start coding and see what come out. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 21:22 ` Grant Likely 2012-11-12 11:47 ` Pantelis Antoniou @ 2012-11-13 3:59 ` Joel A Fernandes 1 sibling, 0 replies; 135+ messages in thread From: Joel A Fernandes @ 2012-11-13 3:59 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, Linux OMAP List, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Grant, On Fri, Nov 9, 2012 at 3:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote: >> (2) >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. > > Unless it is required for boot to userspace I'm not considering > merging before userspace starts. That's well after the tree is > unflattened into the live form. If it is require to boot then I agree > that is should be done in firmware. I see zero problem with having a > beaglebone specific cape driver that knows to read the eeprom and > request a specific configuration file. Heck, the kernel doesn't even > need to parse the eeprom data. It can be read from userspace and > userspace decides which overlay to provide. There's nothing stopping > userspace from reading the eeprom, looking up the correct dts for the > board, downloading the file from the Internet, compiling it with dtc > and installing it.... and yes that is getting a little extreme. Actually, I was speaking of the case where today we read EEPROM anyway for capes before userspace, so it would convenient do the overlay this way. Further, userspace doesn't have to do any parsing as kernel/u-boot could blindly load the dtb overlay directly from EEPROM regardless of which cape. So we don't have do any revision detection and dtb search, the dtb itself being in the EEPROM. That way no matter what the userspace is, the cape hardware is already configured and ready to use by userspace. This might be a corner-case just for beaglebone though, and if requesting overlay from userspace is a more general solution for all usecases, then probably we should go with that approach. OTOH, I guess there's no harm in doing some overlays from kernel for some cases, and userspace for others. >> The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the index of all other nodes in the string block as well.. Hmm. > > And that still doesn't help find all the phandle locations in the tree > for doing fixups. It would need to be a table of > nodes+properties+offsets that contain phandles for fixup to work, but > I shy away from that approach because I think it will be fragile. I guess this approach (which wouldn't work for other reasons) was intended to serve the same purpose as Hashing, having a phandle that doesn't easily change hence not requiring overlay fixups. Actually I'm a bit confused if how maintaining a list of name/node-paths for fix up will even work, because node names are not unique as we discussed. Also node paths can change, so what will the overlay dtb store in its fixup table (say there is one)? A table of node,properties etc as you mentioned might not be unique as there can be 2 nodes with same name and properties. Also if we use node path, instead of node name, in this table, then moving nodes around wont be possible as the fixup table will be pointing to node path references that have now changed- how will the kernel now what's the node's new actual path, say, if there are 2 nodes with the same name? Only thing possible is, to do a _mandatory_ recompile of overlay dtb if a node's path changes. Would be you be in agreement that- When a node's path changes in base dtb, Overlays have to be recompiled and a new fixup table has to be created, or a new hash has to be generated out of the new node path regardless. So moving nodes around in base dtb can't be dynamically accommodated without recompiling overlay. Considering the above is ok, the only 2 approaches I can see for phandle resolutions are: (1) hashing of the full node path and avoiding runtime fixups. (2) Using today's linear phandle increment approach, maintaining a table in the overlay with the key as 'node path' and value as 'phandle fixup offset', and then doing runtime fixups. I believe (2) is considered fragile and it does the same thing as (1) except that (2) can even handle collisions but at the cost of storing the full node path in the overlay's fixup table. So (1) looks like our only possible and meaningful approach. Do you agree with this analysis? Or, maybe I am missing something. Regards, Joel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 5:32 ` Joel A Fernandes 2012-11-09 14:29 ` David Gibson 2012-11-09 21:22 ` Grant Likely @ 2012-11-09 22:59 ` Stephen Warren 2 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-09 22:59 UTC (permalink / raw) To: Joel A Fernandes Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/08/2012 10:32 PM, Joel A Fernandes wrote: ... > Alternatively to hashing, reading David Gibson's paper I followed, > phandle is supposed to 'uniquely' identity node. I wonder why the node > name itself is not sufficient to uniquely identify. The code that does > the tree walking can then just strcmp the node name while it walks the > tree instead of having to find a node with a phandle number. Node names or node paths? If you're talking node names, consider an SoC with two different I2C controllers each attached to an I2C EEPROM with the same I2C address. The nodes representing those EEPROMs might both get the name "eeprom@2c" for example. The node paths should be unique though. ^ permalink raw reply [flat|nested] 135+ messages in thread
[parent not found: <-4237940489086529028@unknownmsgid>]
[parent not found: <559B8433-67C3-4A1A-A5D6-859907655176@antoniou-consulting.com>]
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-10 3:36 ` Joel A Fernandes 0 siblings, 0 replies; 135+ messages in thread From: Joel A Fernandes @ 2012-11-10 3:36 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Pantelis, On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>> and passes the resolved tree to the kernel. >>>> >>> >>> Could be made to work. Only really required if Joanne wants the >>> cape interface to work for u-boot too. For example if the cape has some >>> kind of network interface that u-boot will use to boot from. >>> >> >> I love Grant's hashing idea a lot keeping the phandle problem for >> compile time and not requiring fixups. >> >> IMO it is still a cleaner approach if u-boot does the tree merging for >> all cases, and not the kernel. >> >> That way from a development standpoint, very little or nothing will >> have to be changed in kernel (except for scripts/dtc) considering we >> are moving forward with hashing. >> >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. I think doing tree merging in kernel is messy >> and we should do it in uboot. Ideally reading the fragment from the >> EEPROM for all capes and merging without worrying about version >> detection, Doing the merge and passing the merged blob to the kernel >> which (kernel) works the same way it does today. > > Not going to work, for a lot of cases. Doing it in the kernel seems to be > the cleaner option. There are valid use cases for doing in u-boot too. True, if dynamic runtime stuff from userspace is what we're talking about, then yeah I see the important need for kernel to do the merge. >> Alternatively to hashing, reading david gibsons paper I followed, >> phandle is supposed to 'uniquely' identity node. I wonder why the node >> name itself is not sufficient to unquiely identify. The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the offsets of all other nodes in the string block as well.. Hmm. >> > > This is pretty radical change to the DT format, no? Yes, true and the only way hypothetically to replace the phandle tree-walking mechanism is to store node paths instead of phandle which David pointed is too long to store, so I guess this wont work after all. Anyway this was an interesting exercise, thanks. Regards, Joel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-10 3:36 ` Joel A Fernandes 0 siblings, 0 replies; 135+ messages in thread From: Joel A Fernandes @ 2012-11-10 3:36 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Pantelis, On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>> and passes the resolved tree to the kernel. >>>> >>> >>> Could be made to work. Only really required if Joanne wants the >>> cape interface to work for u-boot too. For example if the cape has some >>> kind of network interface that u-boot will use to boot from. >>> >> >> I love Grant's hashing idea a lot keeping the phandle problem for >> compile time and not requiring fixups. >> >> IMO it is still a cleaner approach if u-boot does the tree merging for >> all cases, and not the kernel. >> >> That way from a development standpoint, very little or nothing will >> have to be changed in kernel (except for scripts/dtc) considering we >> are moving forward with hashing. >> >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. I think doing tree merging in kernel is messy >> and we should do it in uboot. Ideally reading the fragment from the >> EEPROM for all capes and merging without worrying about version >> detection, Doing the merge and passing the merged blob to the kernel >> which (kernel) works the same way it does today. > > Not going to work, for a lot of cases. Doing it in the kernel seems to be > the cleaner option. There are valid use cases for doing in u-boot too. True, if dynamic runtime stuff from userspace is what we're talking about, then yeah I see the important need for kernel to do the merge. >> Alternatively to hashing, reading david gibsons paper I followed, >> phandle is supposed to 'uniquely' identity node. I wonder why the node >> name itself is not sufficient to unquiely identify. The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the offsets of all other nodes in the string block as well.. Hmm. >> > > This is pretty radical change to the DT format, no? Yes, true and the only way hypothetically to replace the phandle tree-walking mechanism is to store node paths instead of phandle which David pointed is too long to store, so I guess this wont work after all. Anyway this was an interesting exercise, thanks. Regards, Joel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-10 3:36 ` Joel A Fernandes (?) @ 2012-11-12 12:48 ` Pantelis Antoniou -1 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 12:48 UTC (permalink / raw) To: Joel A Fernandes Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Koen Kooi, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Hi Joel, Again, sorry for the late reply due to travel. On Nov 10, 2012, at 5:36 AM, Joel A Fernandes wrote: > Hi Pantelis, > > On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > >>>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>>> and passes the resolved tree to the kernel. >>>>> >>>> >>>> Could be made to work. Only really required if Joanne wants the >>>> cape interface to work for u-boot too. For example if the cape has some >>>> kind of network interface that u-boot will use to boot from. >>>> >>> >>> I love Grant's hashing idea a lot keeping the phandle problem for >>> compile time and not requiring fixups. >>> >>> IMO it is still a cleaner approach if u-boot does the tree merging for >>> all cases, and not the kernel. >>> >>> That way from a development standpoint, very little or nothing will >>> have to be changed in kernel (except for scripts/dtc) considering we >>> are moving forward with hashing. >>> >>> Also this discussed a while back but at some point is going to brought >>> up again- loading of dt fragment directly from EEPROM and merging at >>> run time. If we were to implement this in kernel, we would have to add >>> cape specific EEPROM reading code, merge the tree before it is >>> unflattened and parse. I think doing tree merging in kernel is messy >>> and we should do it in uboot. Ideally reading the fragment from the >>> EEPROM for all capes and merging without worrying about version >>> detection, Doing the merge and passing the merged blob to the kernel >>> which (kernel) works the same way it does today. >> >> Not going to work, for a lot of cases. Doing it in the kernel seems to be >> the cleaner option. There are valid use cases for doing in u-boot too. > > True, if dynamic runtime stuff from userspace is what we're talking > about, then yeah I see the important need for kernel to do the merge. > Kernel doing the merge is our use case, and I feel it's the use case of about 90% of users. u-boot doing the merge is the rest. >>> Alternatively to hashing, reading david gibsons paper I followed, >>> phandle is supposed to 'uniquely' identity node. I wonder why the node >>> name itself is not sufficient to unquiely identify. The code that does >>> the tree walking can then just strcmp the node name while it walks the >>> tree instead of having to find a node with a phandle number. I guess >>> the reason is phandles are small to store as data values. Another >>> approach can be to arrange the string block in alphabetical order >>> (unless it already is), and store phandle as index of the node name >>> referenced relative to the starting of the strong block. This will not >>> affect nodes in dtb being moved around since they will still have the >>> same index value. the problem being adding or removing nodes Changes >>> the offsets of all other nodes in the string block as well.. Hmm. >>> >> >> This is pretty radical change to the DT format, no? > > Yes, true and the only way hypothetically to replace the phandle > tree-walking mechanism is to store node paths instead of phandle which > David pointed is too long to store, so I guess this wont work after > all. Anyway this was an interesting exercise, thanks. > It is always nice to have a fresh perspective. Thank you. > Regards, > Joel Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-10 3:36 ` Joel A Fernandes (?) (?) @ 2012-11-13 2:28 ` David Gibson -1 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 2:28 UTC (permalink / raw) To: Joel A Fernandes Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 09, 2012 at 09:36:26PM -0600, Joel A Fernandes wrote: > Hi Pantelis, > > On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > > >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, > >>>> and passes the resolved tree to the kernel. > >>>> > >>> > >>> Could be made to work. Only really required if Joanne wants the > >>> cape interface to work for u-boot too. For example if the cape has some > >>> kind of network interface that u-boot will use to boot from. > >>> > >> > >> I love Grant's hashing idea a lot keeping the phandle problem for > >> compile time and not requiring fixups. > >> > >> IMO it is still a cleaner approach if u-boot does the tree merging for > >> all cases, and not the kernel. > >> > >> That way from a development standpoint, very little or nothing will > >> have to be changed in kernel (except for scripts/dtc) considering we > >> are moving forward with hashing. > >> > >> Also this discussed a while back but at some point is going to brought > >> up again- loading of dt fragment directly from EEPROM and merging at > >> run time. If we were to implement this in kernel, we would have to add > >> cape specific EEPROM reading code, merge the tree before it is > >> unflattened and parse. I think doing tree merging in kernel is messy > >> and we should do it in uboot. Ideally reading the fragment from the > >> EEPROM for all capes and merging without worrying about version > >> detection, Doing the merge and passing the merged blob to the kernel > >> which (kernel) works the same way it does today. > > > > Not going to work, for a lot of cases. Doing it in the kernel seems to be > > the cleaner option. There are valid use cases for doing in u-boot too. > > True, if dynamic runtime stuff from userspace is what we're talking > about, then yeah I see the important need for kernel to do the merge. > > >> Alternatively to hashing, reading david gibsons paper I followed, > >> phandle is supposed to 'uniquely' identity node. I wonder why the node > >> name itself is not sufficient to unquiely identify. The code that does > >> the tree walking can then just strcmp the node name while it walks the > >> tree instead of having to find a node with a phandle number. I guess > >> the reason is phandles are small to store as data values. Another > >> approach can be to arrange the string block in alphabetical order > >> (unless it already is), and store phandle as index of the node name > >> referenced relative to the starting of the strong block. This will not > >> affect nodes in dtb being moved around since they will still have the > >> same index value. the problem being adding or removing nodes Changes > >> the offsets of all other nodes in the string block as well.. Hmm. > >> > > > > This is pretty radical change to the DT format, no? > > Yes, true and the only way hypothetically to replace the phandle > tree-walking mechanism is to store node paths instead of phandle which > David pointed is too long to store, so I guess this wont work after > all. Anyway this was an interesting exercise, thanks. They're not too long to store, but changing to paths would break years of existing OF practice. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 22:37 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-06 22:37 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/05/2012 01:40 PM, Grant Likely wrote: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: "for the so" split across those two lines. > Jane solves this problem by storing an FDT overlay for each cape in the > root filesystem. When the kernel detects that a cape is installed it > reads the cape's eeprom to identify it and uses request_firmware() to > obtain the appropriate overlay. Userspace passes the overlay to the > kernel in the normal way. If the cape doesn't have an eeprom, then the > kernel will still use firmware_request(), but userspace needs to already > know which cape is installed. As mentioned by Pantelis, multiple versions of a board is also very common. We already have the following .dts files in the kernel where this applies, for the main board even: arch/arm/boot/dts/tegra30-cardhu.dtsi arch/arm/boot/dts/tegra30-cardhu-a02.dts arch/arm/boot/dts/tegra30-cardhu-a04.dts > Summary points: > - SHOULD reliably handle changes between different underlying overlays > (ie. what happens to existing .dtb overly files if the structure of > the dtb it is layered over changes. If not possible, then SHALL > detect when the base tree doesn't match and refuse to apply the > overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? > - What is the model for overlays? > - Can an overlay modify existing properties? > - Can an overlay add new properties to existing nodes? > - Can an overlay delete existing nodes/properties? This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. > It may be sufficient to solve it by making the phandle values less > volatile. Right now dtc generates phandles linearly. Generated phandles > could be overridden with explicit phandle properties, but it isn't a > fantastic solution. Perhaps generating the phandle from a hash of the > node name would be sufficient. Node names don't have to be unique though right; perhaps hash the path-name instead of the node-name? But then, why not just reference by path name; similar to <{&/path/to/node}> rather than <&label>? > This handles many of the use cases, but it assumes that an overlay is > board specific. If it ever is required to support multiple base boards > with a single overlay file then there is a problem. The .dtb overlays > generated in this manor cannot handle different phandles or nodes that > are in a different place. On the other hand, the overlay source files > should have no problem being compiled for multiple targets. s/manor/manner/ I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. My earlier thoughts on how to support this included explicit inter-board/-component connector objects in the .dts files that allow "renaming" of GPIOs, I2C buses, regulators, etc.: http://lists.denx.de/pipermail/u-boot/2012-October/138476.html http://lists.denx.de/pipermail/u-boot/2012-November/138925.html ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-06 22:37 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-06 22:37 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/05/2012 01:40 PM, Grant Likely wrote: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: "for the so" split across those two lines. > Jane solves this problem by storing an FDT overlay for each cape in the > root filesystem. When the kernel detects that a cape is installed it > reads the cape's eeprom to identify it and uses request_firmware() to > obtain the appropriate overlay. Userspace passes the overlay to the > kernel in the normal way. If the cape doesn't have an eeprom, then the > kernel will still use firmware_request(), but userspace needs to already > know which cape is installed. As mentioned by Pantelis, multiple versions of a board is also very common. We already have the following .dts files in the kernel where this applies, for the main board even: arch/arm/boot/dts/tegra30-cardhu.dtsi arch/arm/boot/dts/tegra30-cardhu-a02.dts arch/arm/boot/dts/tegra30-cardhu-a04.dts > Summary points: > - SHOULD reliably handle changes between different underlying overlays > (ie. what happens to existing .dtb overly files if the structure of > the dtb it is layered over changes. If not possible, then SHALL > detect when the base tree doesn't match and refuse to apply the > overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? > - What is the model for overlays? > - Can an overlay modify existing properties? > - Can an overlay add new properties to existing nodes? > - Can an overlay delete existing nodes/properties? This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. > It may be sufficient to solve it by making the phandle values less > volatile. Right now dtc generates phandles linearly. Generated phandles > could be overridden with explicit phandle properties, but it isn't a > fantastic solution. Perhaps generating the phandle from a hash of the > node name would be sufficient. Node names don't have to be unique though right; perhaps hash the path-name instead of the node-name? But then, why not just reference by path name; similar to <{&/path/to/node}> rather than <&label>? > This handles many of the use cases, but it assumes that an overlay is > board specific. If it ever is required to support multiple base boards > with a single overlay file then there is a problem. The .dtb overlays > generated in this manor cannot handle different phandles or nodes that > are in a different place. On the other hand, the overlay source files > should have no problem being compiled for multiple targets. s/manor/manner/ I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. My earlier thoughts on how to support this included explicit inter-board/-component connector objects in the .dts files that allow "renaming" of GPIOs, I2C buses, regulators, etc.: http://lists.denx.de/pipermail/u-boot/2012-October/138476.html http://lists.denx.de/pipermail/u-boot/2012-November/138925.html ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 0:54 ` Mitch Bradley 0 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-07 0:54 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/6/2012 12:37 PM, Stephen Warren wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Interesting. This just came up internally at NVIDIA within the last > couple weeks, and was discussed on the U-Boot mailing list very recently > too: > > http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 > (it spills into the November archive too) > >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at > > I don't know if you're maintaining this as a document and taking patches > to it, but if so: > > "for the so" split across those two lines. > >> Jane solves this problem by storing an FDT overlay for each cape in the >> root filesystem. When the kernel detects that a cape is installed it >> reads the cape's eeprom to identify it and uses request_firmware() to >> obtain the appropriate overlay. Userspace passes the overlay to the >> kernel in the normal way. If the cape doesn't have an eeprom, then the >> kernel will still use firmware_request(), but userspace needs to already >> know which cape is installed. > > As mentioned by Pantelis, multiple versions of a board is also very > common. We already have the following .dts files in the kernel where > this applies, for the main board even: > > arch/arm/boot/dts/tegra30-cardhu.dtsi > arch/arm/boot/dts/tegra30-cardhu-a02.dts > arch/arm/boot/dts/tegra30-cardhu-a04.dts > >> Summary points: > >> - SHOULD reliably handle changes between different underlying overlays >> (ie. what happens to existing .dtb overly files if the structure of >> the dtb it is layered over changes. If not possible, then SHALL >> detect when the base tree doesn't match and refuse to apply the >> overlay. > > Perhaps use (versioned) DT bindings to represent the interface between > the two .dts files? See the links to the U-Boot mailing list discussions > below? > >> - What is the model for overlays? >> - Can an overlay modify existing properties? >> - Can an overlay add new properties to existing nodes? >> - Can an overlay delete existing nodes/properties? > > This proposal is very oriented at an overlay-based approach. I'm not > totally convinced that a pure overlay approach (as in how dtc does > overlayed DT nodes) will be flexible enough, but would love to be > persuaded. Again see below. An overlay approach will not be powerful enough to solve the sorts of problems that occur when a product goes into full production, becomes a family, and starts to evolve. Issues like second-source parts that aren't quite compatible and need to be detected and reported, board-stuff options for different customer profiles, speed grades of parts that aren't properly probeable but instead need to be identified by some subterfuge, the list of tedious issues goes on and on. It's nice to pretend that the world fits into a few coherent simple use cases, but 30 years of experience shipping computer product families proves otherwise. You need a programming language to solve the full set of problems - which I why the device tree is designed so it can be generated and modified by a program. > >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. > > Node names don't have to be unique though right; perhaps hash the > path-name instead of the node-name? But then, why not just reference by > path name; similar to <{&/path/to/node}> rather than <&label>? > >> This handles many of the use cases, but it assumes that an overlay is >> board specific. If it ever is required to support multiple base boards >> with a single overlay file then there is a problem. The .dtb overlays >> generated in this manor cannot handle different phandles or nodes that >> are in a different place. On the other hand, the overlay source files >> should have no problem being compiled for multiple targets. > > s/manor/manner/ > > I do rather suspect this use-case is quite common. NVIDIA certainly has > a bunch of development boards with pluggable > PMIC/audio/WiFi/display/..., and I believe there's some ability to > re-use the pluggable components with a variety of base-boards. > > Given people within NVIDIA started talking about this recently, I asked > them to enumerate all the boards we have that support pluggable > components, and how common it is that some boards support being plugged > into different main boards. I don't know when that enumeration will > complete (or even start) but hopefully I can provide some feedback on > how common the use-case is for us once it's done. > > My earlier thoughts on how to support this included explicit > inter-board/-component connector objects in the .dts files that allow > "renaming" of GPIOs, I2C buses, regulators, etc.: > > http://lists.denx.de/pipermail/u-boot/2012-October/138476.html > http://lists.denx.de/pipermail/u-boot/2012-November/138925.html > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 0:54 ` Mitch Bradley 0 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-07 0:54 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/6/2012 12:37 PM, Stephen Warren wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Interesting. This just came up internally at NVIDIA within the last > couple weeks, and was discussed on the U-Boot mailing list very recently > too: > > http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 > (it spills into the November archive too) > >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at > > I don't know if you're maintaining this as a document and taking patches > to it, but if so: > > "for the so" split across those two lines. > >> Jane solves this problem by storing an FDT overlay for each cape in the >> root filesystem. When the kernel detects that a cape is installed it >> reads the cape's eeprom to identify it and uses request_firmware() to >> obtain the appropriate overlay. Userspace passes the overlay to the >> kernel in the normal way. If the cape doesn't have an eeprom, then the >> kernel will still use firmware_request(), but userspace needs to already >> know which cape is installed. > > As mentioned by Pantelis, multiple versions of a board is also very > common. We already have the following .dts files in the kernel where > this applies, for the main board even: > > arch/arm/boot/dts/tegra30-cardhu.dtsi > arch/arm/boot/dts/tegra30-cardhu-a02.dts > arch/arm/boot/dts/tegra30-cardhu-a04.dts > >> Summary points: > >> - SHOULD reliably handle changes between different underlying overlays >> (ie. what happens to existing .dtb overly files if the structure of >> the dtb it is layered over changes. If not possible, then SHALL >> detect when the base tree doesn't match and refuse to apply the >> overlay. > > Perhaps use (versioned) DT bindings to represent the interface between > the two .dts files? See the links to the U-Boot mailing list discussions > below? > >> - What is the model for overlays? >> - Can an overlay modify existing properties? >> - Can an overlay add new properties to existing nodes? >> - Can an overlay delete existing nodes/properties? > > This proposal is very oriented at an overlay-based approach. I'm not > totally convinced that a pure overlay approach (as in how dtc does > overlayed DT nodes) will be flexible enough, but would love to be > persuaded. Again see below. An overlay approach will not be powerful enough to solve the sorts of problems that occur when a product goes into full production, becomes a family, and starts to evolve. Issues like second-source parts that aren't quite compatible and need to be detected and reported, board-stuff options for different customer profiles, speed grades of parts that aren't properly probeable but instead need to be identified by some subterfuge, the list of tedious issues goes on and on. It's nice to pretend that the world fits into a few coherent simple use cases, but 30 years of experience shipping computer product families proves otherwise. You need a programming language to solve the full set of problems - which I why the device tree is designed so it can be generated and modified by a program. > >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. > > Node names don't have to be unique though right; perhaps hash the > path-name instead of the node-name? But then, why not just reference by > path name; similar to <{&/path/to/node}> rather than <&label>? > >> This handles many of the use cases, but it assumes that an overlay is >> board specific. If it ever is required to support multiple base boards >> with a single overlay file then there is a problem. The .dtb overlays >> generated in this manor cannot handle different phandles or nodes that >> are in a different place. On the other hand, the overlay source files >> should have no problem being compiled for multiple targets. > > s/manor/manner/ > > I do rather suspect this use-case is quite common. NVIDIA certainly has > a bunch of development boards with pluggable > PMIC/audio/WiFi/display/..., and I believe there's some ability to > re-use the pluggable components with a variety of base-boards. > > Given people within NVIDIA started talking about this recently, I asked > them to enumerate all the boards we have that support pluggable > components, and how common it is that some boards support being plugged > into different main boards. I don't know when that enumeration will > complete (or even start) but hopefully I can provide some feedback on > how common the use-case is for us once it's done. > > My earlier thoughts on how to support this included explicit > inter-board/-component connector objects in the .dts files that allow > "renaming" of GPIOs, I2C buses, regulators, etc.: > > http://lists.denx.de/pipermail/u-boot/2012-October/138476.html > http://lists.denx.de/pipermail/u-boot/2012-November/138925.html > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 0:54 ` Mitch Bradley (?) @ 2012-11-09 17:02 ` Grant Likely 2012-11-12 11:29 ` Pantelis Antoniou -1 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-09 17:02 UTC (permalink / raw) To: Mitch Bradley Cc: Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Wed, Nov 7, 2012 at 12:54 AM, Mitch Bradley <wmb@firmworks.com> wrote: > On 11/6/2012 12:37 PM, Stephen Warren wrote: >> This proposal is very oriented at an overlay-based approach. I'm not >> totally convinced that a pure overlay approach (as in how dtc does >> overlayed DT nodes) will be flexible enough, but would love to be >> persuaded. Again see below. > > > An overlay approach will not be powerful enough to solve the sorts of > problems that occur when a product goes into full production, becomes a > family, and starts to evolve. Issues like second-source parts that > aren't quite compatible and need to be detected and reported, > board-stuff options for different customer profiles, speed grades of > parts that aren't properly probeable but instead need to be identified > by some subterfuge, the list of tedious issues goes on and on. > > It's nice to pretend that the world fits into a few coherent simple > use cases, but 30 years of experience shipping computer product families > proves otherwise. You need a programming language to solve the full > set of problems - which I why the device tree is designed so it can > be generated and modified by a program. I'm not going to argue with that. There is nothing saying that the overlay wouldn't be generated or applied by a script. However, I do strongly think that the data model needs to be independent of any tool or execution environment used to manipulate it. I certainly am not interested in encoding scripts or bytecode into the tree - the opposite of the approach used by ACPI which must execute AML to even retrieve the device tree. I like the overlay approach because it is conceptually straightforward and provides a working model of how changes could be made from userspace while still being usable by firmware. An alternate approach from userspace would be to use a live virtual filesystem to manipulate the device tree, though that approach only applies to Linux userspace. Firmware would still need its own approach. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 17:02 ` Grant Likely @ 2012-11-12 11:29 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 11:29 UTC (permalink / raw) To: Grant Likely Cc: Mitch Bradley, Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss Hi Grant, On Nov 9, 2012, at 7:02 PM, Grant Likely wrote: > On Wed, Nov 7, 2012 at 12:54 AM, Mitch Bradley <wmb@firmworks.com> wrote: >> On 11/6/2012 12:37 PM, Stephen Warren wrote: >>> This proposal is very oriented at an overlay-based approach. I'm not >>> totally convinced that a pure overlay approach (as in how dtc does >>> overlayed DT nodes) will be flexible enough, but would love to be >>> persuaded. Again see below. >> >> >> An overlay approach will not be powerful enough to solve the sorts of >> problems that occur when a product goes into full production, becomes a >> family, and starts to evolve. Issues like second-source parts that >> aren't quite compatible and need to be detected and reported, >> board-stuff options for different customer profiles, speed grades of >> parts that aren't properly probeable but instead need to be identified >> by some subterfuge, the list of tedious issues goes on and on. >> >> It's nice to pretend that the world fits into a few coherent simple >> use cases, but 30 years of experience shipping computer product families >> proves otherwise. You need a programming language to solve the full >> set of problems - which I why the device tree is designed so it can >> be generated and modified by a program. > > I'm not going to argue with that. There is nothing saying that the > overlay wouldn't be generated or applied by a script. However, I do > strongly think that the data model needs to be independent of any tool > or execution environment used to manipulate it. I certainly am not > interested in encoding scripts or bytecode into the tree - the > opposite of the approach used by ACPI which must execute AML to even > retrieve the device tree. I like the overlay approach because it is > conceptually straightforward and provides a working model of how > changes could be made from userspace while still being usable by > firmware. > > An alternate approach from userspace would be to use a live virtual > filesystem to manipulate the device tree, though that approach only > applies to Linux userspace. Firmware would still need its own > approach. > > g. I completely agree here. I certainly wouldn't want to introduce any kind of bytecode or a programming model for manipulating DT. I know OF has a full blown forth interpreter, but that's not what modern DT should be (IMHO). Having DT provide such a programming model will preclude a number of users of accessing it, and on top of that, complexity will increase considerably. When faced with a new problem, vendors will just code a workaround, never bothering fixing it properly. In a nutshell, let's not turn DT into ACPI, please. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 22:37 ` Stephen Warren (?) (?) @ 2012-11-07 8:47 ` Pantelis Antoniou 2012-11-07 17:18 ` Stephen Warren -1 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 8:47 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Interesting. This just came up internally at NVIDIA within the last > couple weeks, and was discussed on the U-Boot mailing list very recently > too: > > http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 > (it spills into the November archive too) I am aware of this discussion. For our use case u-boot DT manipulation was tried, but then abandoned. Asking our user base to modify anything in u-boot was ruled out. > >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at > > I don't know if you're maintaining this as a document and taking patches > to it, but if so: > > "for the so" split across those two lines. > >> Jane solves this problem by storing an FDT overlay for each cape in the >> root filesystem. When the kernel detects that a cape is installed it >> reads the cape's eeprom to identify it and uses request_firmware() to >> obtain the appropriate overlay. Userspace passes the overlay to the >> kernel in the normal way. If the cape doesn't have an eeprom, then the >> kernel will still use firmware_request(), but userspace needs to already >> know which cape is installed. > > As mentioned by Pantelis, multiple versions of a board is also very > common. We already have the following .dts files in the kernel where > this applies, for the main board even: > > arch/arm/boot/dts/tegra30-cardhu.dtsi > arch/arm/boot/dts/tegra30-cardhu-a02.dts > arch/arm/boot/dts/tegra30-cardhu-a04.dts > Exactly. I've made this point in another email, but IMHO board-revision management is exactly the same with cape revision management. Ideally you'd like to get rid of those three, and replace it with only one that's properly versioned. >> Summary points: > >> - SHOULD reliably handle changes between different underlying overlays >> (ie. what happens to existing .dtb overly files if the structure of >> the dtb it is layered over changes. If not possible, then SHALL >> detect when the base tree doesn't match and refuse to apply the >> overlay. > > Perhaps use (versioned) DT bindings to represent the interface between > the two .dts files? See the links to the U-Boot mailing list discussions > below? > >> - What is the model for overlays? >> - Can an overlay modify existing properties? >> - Can an overlay add new properties to existing nodes? >> - Can an overlay delete existing nodes/properties? > > This proposal is very oriented at an overlay-based approach. I'm not > totally convinced that a pure overlay approach (as in how dtc does > overlayed DT nodes) will be flexible enough, but would love to be > persuaded. Again see below. > >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. > > Node names don't have to be unique though right; perhaps hash the > path-name instead of the node-name? But then, why not just reference by > path name; similar to <{&/path/to/node}> rather than <&label>? > It would work for references to the known base DTS. If you have a cape that's cross-device compatible that can simply fail. I like this for it's simplicity though. >> This handles many of the use cases, but it assumes that an overlay is >> board specific. If it ever is required to support multiple base boards >> with a single overlay file then there is a problem. The .dtb overlays >> generated in this manor cannot handle different phandles or nodes that >> are in a different place. On the other hand, the overlay source files >> should have no problem being compiled for multiple targets. > > s/manor/manner/ > > I do rather suspect this use-case is quite common. NVIDIA certainly has > a bunch of development boards with pluggable > PMIC/audio/WiFi/display/..., and I believe there's some ability to > re-use the pluggable components with a variety of base-boards. > > Given people within NVIDIA started talking about this recently, I asked > them to enumerate all the boards we have that support pluggable > components, and how common it is that some boards support being plugged > into different main boards. I don't know when that enumeration will > complete (or even start) but hopefully I can provide some feedback on > how common the use-case is for us once it's done. > > My earlier thoughts on how to support this included explicit > inter-board/-component connector objects in the .dts files that allow > "renaming" of GPIOs, I2C buses, regulators, etc.: > > http://lists.denx.de/pipermail/u-boot/2012-October/138476.html > http://lists.denx.de/pipermail/u-boot/2012-November/138925.html Sounds very similar to our case. Very interesting to say the least ;) Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-07 8:47 ` Pantelis Antoniou @ 2012-11-07 17:18 ` Stephen Warren 2012-11-07 22:08 ` Pantelis Antoniou 0 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-07 17:18 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/07/2012 01:47 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote: > >> On 11/05/2012 01:40 PM, Grant Likely wrote: >>> Hey folks, >>> >>> As promised, here is my early draft to try and capture what device >>> tree overlays need to do and how to get there. Comments and >>> suggestions greatly appreciated. >> >> Interesting. This just came up internally at NVIDIA within the last >> couple weeks, and was discussed on the U-Boot mailing list very recently >> too: >> >> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >> (it spills into the November archive too) > > I am aware of this discussion. For our use case u-boot DT manipulation was > tried, but then abandoned. Asking our user base to modify anything in u-boot > was ruled out. > >> >>> For these cases it is proposed to implement an overlay feature for the >>> so that the initial device tree data can be modified by userspace at >> >> I don't know if you're maintaining this as a document and taking patches >> to it, but if so: >> >> "for the so" split across those two lines. >> >>> Jane solves this problem by storing an FDT overlay for each cape in the >>> root filesystem. When the kernel detects that a cape is installed it >>> reads the cape's eeprom to identify it and uses request_firmware() to >>> obtain the appropriate overlay. Userspace passes the overlay to the >>> kernel in the normal way. If the cape doesn't have an eeprom, then the >>> kernel will still use firmware_request(), but userspace needs to already >>> know which cape is installed. >> >> As mentioned by Pantelis, multiple versions of a board is also very >> common. We already have the following .dts files in the kernel where >> this applies, for the main board even: >> >> arch/arm/boot/dts/tegra30-cardhu.dtsi >> arch/arm/boot/dts/tegra30-cardhu-a02.dts >> arch/arm/boot/dts/tegra30-cardhu-a04.dts > > Exactly. I've made this point in another email, but IMHO board-revision > management is exactly the same with cape revision management. > > Ideally you'd like to get rid of those three, and replace it with only > one that's properly versioned. I don't expect we would ever get rid of some of those .dts files; there is after all a common subset that applies to all boards, and an incremental difference that applies to only A02/3, and another for A04/5/... Representing those as separate source files seems appropriate to me. If we try and dump all the multiple versions into a single file with some markup indicating which version of the board some sub-sections of the .dts apply to, I think we'll end up with rather complex .dts files. In this case, the simple overlay model works extremely well. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 22:08 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 22:08 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 7, 2012, at 6:18 PM, Stephen Warren wrote: > On 11/07/2012 01:47 AM, Pantelis Antoniou wrote: >> Hi Stephen, >> >> On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote: >> >>> On 11/05/2012 01:40 PM, Grant Likely wrote: >>>> Hey folks, >>>> >>>> As promised, here is my early draft to try and capture what device >>>> tree overlays need to do and how to get there. Comments and >>>> suggestions greatly appreciated. >>> >>> Interesting. This just came up internally at NVIDIA within the last >>> couple weeks, and was discussed on the U-Boot mailing list very recently >>> too: >>> >>> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >>> (it spills into the November archive too) >> >> I am aware of this discussion. For our use case u-boot DT manipulation was >> tried, but then abandoned. Asking our user base to modify anything in u-boot >> was ruled out. >> >>> >>>> For these cases it is proposed to implement an overlay feature for the >>>> so that the initial device tree data can be modified by userspace at >>> >>> I don't know if you're maintaining this as a document and taking patches >>> to it, but if so: >>> >>> "for the so" split across those two lines. >>> >>>> Jane solves this problem by storing an FDT overlay for each cape in the >>>> root filesystem. When the kernel detects that a cape is installed it >>>> reads the cape's eeprom to identify it and uses request_firmware() to >>>> obtain the appropriate overlay. Userspace passes the overlay to the >>>> kernel in the normal way. If the cape doesn't have an eeprom, then the >>>> kernel will still use firmware_request(), but userspace needs to already >>>> know which cape is installed. >>> >>> As mentioned by Pantelis, multiple versions of a board is also very >>> common. We already have the following .dts files in the kernel where >>> this applies, for the main board even: >>> >>> arch/arm/boot/dts/tegra30-cardhu.dtsi >>> arch/arm/boot/dts/tegra30-cardhu-a02.dts >>> arch/arm/boot/dts/tegra30-cardhu-a04.dts >> >> Exactly. I've made this point in another email, but IMHO board-revision >> management is exactly the same with cape revision management. >> >> Ideally you'd like to get rid of those three, and replace it with only >> one that's properly versioned. > > I don't expect we would ever get rid of some of those .dts files; there > is after all a common subset that applies to all boards, and an > incremental difference that applies to only A02/3, and another for > A04/5/... Representing those as separate source files seems appropriate > to me. If we try and dump all the multiple versions into a single file > with some markup indicating which version of the board some sub-sections > of the .dts apply to, I think we'll end up with rather complex .dts > files. In this case, the simple overlay model works extremely well. If that's your use case, fine. We're not really trying to impose any special format for the DT files. We think that for our use cases a single DT works better, not so much from the developer point of view but from the users. A single DT is much easier to support, especially for users that aren't so great at boot-loader option juggling. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-07 22:08 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-07 22:08 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Stephen, On Nov 7, 2012, at 6:18 PM, Stephen Warren wrote: > On 11/07/2012 01:47 AM, Pantelis Antoniou wrote: >> Hi Stephen, >> >> On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote: >> >>> On 11/05/2012 01:40 PM, Grant Likely wrote: >>>> Hey folks, >>>> >>>> As promised, here is my early draft to try and capture what device >>>> tree overlays need to do and how to get there. Comments and >>>> suggestions greatly appreciated. >>> >>> Interesting. This just came up internally at NVIDIA within the last >>> couple weeks, and was discussed on the U-Boot mailing list very recently >>> too: >>> >>> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >>> (it spills into the November archive too) >> >> I am aware of this discussion. For our use case u-boot DT manipulation was >> tried, but then abandoned. Asking our user base to modify anything in u-boot >> was ruled out. >> >>> >>>> For these cases it is proposed to implement an overlay feature for the >>>> so that the initial device tree data can be modified by userspace at >>> >>> I don't know if you're maintaining this as a document and taking patches >>> to it, but if so: >>> >>> "for the so" split across those two lines. >>> >>>> Jane solves this problem by storing an FDT overlay for each cape in the >>>> root filesystem. When the kernel detects that a cape is installed it >>>> reads the cape's eeprom to identify it and uses request_firmware() to >>>> obtain the appropriate overlay. Userspace passes the overlay to the >>>> kernel in the normal way. If the cape doesn't have an eeprom, then the >>>> kernel will still use firmware_request(), but userspace needs to already >>>> know which cape is installed. >>> >>> As mentioned by Pantelis, multiple versions of a board is also very >>> common. We already have the following .dts files in the kernel where >>> this applies, for the main board even: >>> >>> arch/arm/boot/dts/tegra30-cardhu.dtsi >>> arch/arm/boot/dts/tegra30-cardhu-a02.dts >>> arch/arm/boot/dts/tegra30-cardhu-a04.dts >> >> Exactly. I've made this point in another email, but IMHO board-revision >> management is exactly the same with cape revision management. >> >> Ideally you'd like to get rid of those three, and replace it with only >> one that's properly versioned. > > I don't expect we would ever get rid of some of those .dts files; there > is after all a common subset that applies to all boards, and an > incremental difference that applies to only A02/3, and another for > A04/5/... Representing those as separate source files seems appropriate > to me. If we try and dump all the multiple versions into a single file > with some markup indicating which version of the board some sub-sections > of the .dts apply to, I think we'll end up with rather complex .dts > files. In this case, the simple overlay model works extremely well. If that's your use case, fine. We're not really trying to impose any special format for the DT files. We think that for our use cases a single DT works better, not so much from the developer point of view but from the users. A single DT is much easier to support, especially for users that aren't so great at boot-loader option juggling. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-06 22:37 ` Stephen Warren ` (2 preceding siblings ...) (?) @ 2012-11-09 16:28 ` Grant Likely 2012-11-09 23:23 ` Stephen Warren ` (3 more replies) -1 siblings, 4 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 16:28 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Interesting. This just came up internally at NVIDIA within the last > couple weeks, and was discussed on the U-Boot mailing list very recently > too: > > http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 > (it spills into the November archive too) > >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at > > I don't know if you're maintaining this as a document and taking patches > to it, but if so: Sure, why not... http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary > > "for the so" split across those two lines. fixed >> - SHOULD reliably handle changes between different underlying overlays >> (ie. what happens to existing .dtb overly files if the structure of >> the dtb it is layered over changes. If not possible, then SHALL >> detect when the base tree doesn't match and refuse to apply the >> overlay. > > Perhaps use (versioned) DT bindings to represent the interface between > the two .dts files? See the links to the U-Boot mailing list discussions > below? Implementing versioning is conceptually a lot more complex than plain overlays since it means either the kernel or u-boot needs to start filtering the data that it's given. This can get really complex in a hurry. Mitch makes a valid point later in this thread that when it comes to manipulating the data depending on the board then the data overlay model alone doesn't handle it well. I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Suggestions and proposals are definitely welcome here. > >> - What is the model for overlays? >> - Can an overlay modify existing properties? >> - Can an overlay add new properties to existing nodes? >> - Can an overlay delete existing nodes/properties? > > This proposal is very oriented at an overlay-based approach. I'm not > totally convinced that a pure overlay approach (as in how dtc does > overlayed DT nodes) will be flexible enough, but would love to be > persuaded. Again see below. The way I'm currently thinking about the overlay approach is as a discrete set of changes that all can be applied at once.* That certainly doesn't preclude the change being generated with a script or other tool in either firmware or userspace. For most changes it works really well. Of the scenarios that don't work well, I can think of two. The first is it moving or renaming existing nodes, and the second is if the structure of the base tree changes (say due to a firmware update). Although the second limitation is specifically with binary .dtb overlays. Recompiling the dts overlay against the new tree would work fine.** *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? ** all this is based on my current ideas about the .dtb overlay format which would be trivial to implement, but I'm not committed to that approach just yet. The above problems could be solved. >> It may be sufficient to solve it by making the phandle values less >> volatile. Right now dtc generates phandles linearly. Generated phandles >> could be overridden with explicit phandle properties, but it isn't a >> fantastic solution. Perhaps generating the phandle from a hash of the >> node name would be sufficient. > > Node names don't have to be unique though right; perhaps hash the > path-name instead of the node-name? But then, why not just reference by > path name; similar to <{&/path/to/node}> rather than <&label>? I was thinking about using the full_name for generating phandles. On the odd chance there is a collision, one of the nodes will get something like the hash value +1. Or in that condition we can require one of the nodes to have the phandle value explicitly set in the source file. Note; this doesn't actually affect anything outside of dtc. Right now dtc starts at 1 and assigns phandles incrementally. I'm suggesting using a hash of the full_name to assign the phandle for a node so that it will not change unless the full_path changes. >> This handles many of the use cases, but it assumes that an overlay is >> board specific. If it ever is required to support multiple base boards >> with a single overlay file then there is a problem. The .dtb overlays >> generated in this manor cannot handle different phandles or nodes that >> are in a different place. On the other hand, the overlay source files >> should have no problem being compiled for multiple targets. > > s/manor/manner/ Fixed > > I do rather suspect this use-case is quite common. NVIDIA certainly has > a bunch of development boards with pluggable > PMIC/audio/WiFi/display/..., and I believe there's some ability to > re-use the pluggable components with a variety of base-boards. > > Given people within NVIDIA started talking about this recently, I asked > them to enumerate all the boards we have that support pluggable > components, and how common it is that some boards support being plugged > into different main boards. I don't know when that enumeration will > complete (or even start) but hopefully I can provide some feedback on > how common the use-case is for us once it's done. >From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 16:28 ` Grant Likely @ 2012-11-09 23:23 ` Stephen Warren 2012-11-09 23:40 ` Grant Likely ` (2 more replies) 2012-11-11 20:47 ` Rob Landley ` (2 subsequent siblings) 3 siblings, 3 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-09 23:23 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/09/2012 09:28 AM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: ... >> I do rather suspect this use-case is quite common. NVIDIA certainly has >> a bunch of development boards with pluggable >> PMIC/audio/WiFi/display/..., and I believe there's some ability to >> re-use the pluggable components with a variety of base-boards. >> >> Given people within NVIDIA started talking about this recently, I asked >> them to enumerate all the boards we have that support pluggable >> components, and how common it is that some boards support being plugged >> into different main boards. I don't know when that enumeration will >> complete (or even start) but hopefully I can provide some feedback on >> how common the use-case is for us once it's done. > > From your perspective, is it important to use the exact same .dtb > overlays for those add-on boards, or is it okay to have a separate > build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) I suppose it would be acceptable for the shield vendor to ship the .dts file rather than the .dtb, and hence need to build the shield .dtb for a specific base board. However, I think the process for an end-user needs to be as simple as "drop this .dts/.dtb file into some standard directory", and I imagine it'll be much easier for distros/... to make that process work if they're dealing with a .dtb that they can just blast into the kernel's firmware loader interface, rather than having to also locate the base-board .dts/.dtb file, and run dtc and/or other tools on both .dts files together. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 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-17 22:27 ` Jean-Christophe PLAGNIOL-VILLARD 2 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-09 23:40 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 11:23 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/09/2012 09:28 AM, Grant Likely wrote: >> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > ... >>> I do rather suspect this use-case is quite common. NVIDIA certainly has >>> a bunch of development boards with pluggable >>> PMIC/audio/WiFi/display/..., and I believe there's some ability to >>> re-use the pluggable components with a variety of base-boards. >>> >>> Given people within NVIDIA started talking about this recently, I asked >>> them to enumerate all the boards we have that support pluggable >>> components, and how common it is that some boards support being plugged >>> into different main boards. I don't know when that enumeration will >>> complete (or even start) but hopefully I can provide some feedback on >>> how common the use-case is for us once it's done. >> >> From your perspective, is it important to use the exact same .dtb >> overlays for those add-on boards, or is it okay to have a separate >> build of the overlay for each base tree? > > I certainly think it'd be extremely beneficial to use the exact same > child board .dtb with arbitrary base boards. > > Consider something like the Arduino shield connector format, which I > /believe/ has been re-used across a wide variety of Arduino boards and > other compatible or imitation boards. Now consider a vendor of an > Arduino shield. The shield vendor probably wants to publish a single > .dtb file that works for users irrespective of which board they're using > it with. > > (Well, I'm not sure that Arduino can run Linux; perhaps that's why you > picked BeagleBone capes for your document!) Correct, the Arduino is only an AVR with a tiny amount of ram. No Linux there. However, Arduino shields are a good example of a use case. I think there are even some Arduino shield compatible Linux boards out there. > I suppose it would be acceptable for the shield vendor to ship the .dts > file rather than the .dtb, and hence need to build the shield .dtb for a > specific base board. That would be better I think than relying on a binary. However, some though needs to go into how to handle base boards that /aren't/ mostly equivalent. Such as if they have a different GPIO controller. It may be that for gpios and irqs, the solution really is to use interrupt-map and create a gpio-map. i2c, spi and others still would need to become children of the correct bus. > However, I think the process for an end-user needs to be as simple as > "drop this .dts/.dtb file into some standard directory", and I imagine > it'll be much easier for distros/... to make that process work if > they're dealing with a .dtb that they can just blast into the kernel's > firmware loader interface, rather than having to also locate the > base-board .dts/.dtb file, and run dtc and/or other tools on both .dts > files together. The base-board .dts is unnecessary. dtc is fully capable of using /proc/device-tree as the source material. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 23:40 ` Grant Likely @ 2012-11-12 10:53 ` Koen Kooi 0 siblings, 0 replies; 135+ messages in thread From: Koen Kooi @ 2012-11-12 10:53 UTC (permalink / raw) To: Grant Likely Cc: Stephen Warren, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Op 10 nov. 2012, om 00:40 heeft Grant Likely <grant.likely@secretlab.ca> het volgende geschreven: > On Fri, Nov 9, 2012 at 11:23 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 11/09/2012 09:28 AM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> ... >>>> I do rather suspect this use-case is quite common. NVIDIA certainly has >>>> a bunch of development boards with pluggable >>>> PMIC/audio/WiFi/display/..., and I believe there's some ability to >>>> re-use the pluggable components with a variety of base-boards. >>>> >>>> Given people within NVIDIA started talking about this recently, I asked >>>> them to enumerate all the boards we have that support pluggable >>>> components, and how common it is that some boards support being plugged >>>> into different main boards. I don't know when that enumeration will >>>> complete (or even start) but hopefully I can provide some feedback on >>>> how common the use-case is for us once it's done. >>> >>> From your perspective, is it important to use the exact same .dtb >>> overlays for those add-on boards, or is it okay to have a separate >>> build of the overlay for each base tree? >> >> I certainly think it'd be extremely beneficial to use the exact same >> child board .dtb with arbitrary base boards. >> >> Consider something like the Arduino shield connector format, which I >> /believe/ has been re-used across a wide variety of Arduino boards and >> other compatible or imitation boards. Now consider a vendor of an >> Arduino shield. The shield vendor probably wants to publish a single >> .dtb file that works for users irrespective of which board they're using >> it with. >> >> (Well, I'm not sure that Arduino can run Linux; perhaps that's why you >> picked BeagleBone capes for your document!) > > Correct, the Arduino is only an AVR with a tiny amount of ram. No Linux there. > > However, Arduino shields are a good example of a use case. I think > there are even some Arduino shield compatible Linux boards out there. A good example of those would be the Rascal Micro: http://rascalmicro.com/ regards, Koen ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 12:10 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 12:10 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: > On 11/09/2012 09:28 AM, Grant Likely wrote: >> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > ... >>> I do rather suspect this use-case is quite common. NVIDIA certainly has >>> a bunch of development boards with pluggable >>> PMIC/audio/WiFi/display/..., and I believe there's some ability to >>> re-use the pluggable components with a variety of base-boards. >>> >>> Given people within NVIDIA started talking about this recently, I asked >>> them to enumerate all the boards we have that support pluggable >>> components, and how common it is that some boards support being plugged >>> into different main boards. I don't know when that enumeration will >>> complete (or even start) but hopefully I can provide some feedback on >>> how common the use-case is for us once it's done. >> >> From your perspective, is it important to use the exact same .dtb >> overlays for those add-on boards, or is it okay to have a separate >> build of the overlay for each base tree? > > I certainly think it'd be extremely beneficial to use the exact same > child board .dtb with arbitrary base boards. > Oh yes. In fact if one was to use a single kernel image for beagleboard and beaglebone, for the cape to work for both, it is required for it's dtb to be compatible. We're not there yet, but people would like to have an upgrade path. beaglebone -> beagleboard -> pandaboard -> future-boards It is not possible yet, but perhaps newer boards could have that. > Consider something like the Arduino shield connector format, which I > /believe/ has been re-used across a wide variety of Arduino boards and > other compatible or imitation boards. Now consider a vendor of an > Arduino shield. The shield vendor probably wants to publish a single > .dtb file that works for users irrespective of which board they're using > it with. > > (Well, I'm not sure that Arduino can run Linux; perhaps that's why you > picked BeagleBone capes for your document!) > Arduino can't possible do it. Using arduino shields with an adapter could be possible though. > I suppose it would be acceptable for the shield vendor to ship the .dts > file rather than the .dtb, and hence need to build the shield .dtb for a > specific base board. > > However, I think the process for an end-user needs to be as simple as > "drop this .dts/.dtb file into some standard directory", and I imagine > it'll be much easier for distros/... to make that process work if > they're dealing with a .dtb that they can just blast into the kernel's > firmware loader interface, rather than having to also locate the > base-board .dts/.dtb file, and run dtc and/or other tools on both .dts > files together. Yes. A single supported dtb is the way to go ideally. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 12:10 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 12:10 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Stephen, On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: > On 11/09/2012 09:28 AM, Grant Likely wrote: >> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote: > ... >>> I do rather suspect this use-case is quite common. NVIDIA certainly has >>> a bunch of development boards with pluggable >>> PMIC/audio/WiFi/display/..., and I believe there's some ability to >>> re-use the pluggable components with a variety of base-boards. >>> >>> Given people within NVIDIA started talking about this recently, I asked >>> them to enumerate all the boards we have that support pluggable >>> components, and how common it is that some boards support being plugged >>> into different main boards. I don't know when that enumeration will >>> complete (or even start) but hopefully I can provide some feedback on >>> how common the use-case is for us once it's done. >> >> From your perspective, is it important to use the exact same .dtb >> overlays for those add-on boards, or is it okay to have a separate >> build of the overlay for each base tree? > > I certainly think it'd be extremely beneficial to use the exact same > child board .dtb with arbitrary base boards. > Oh yes. In fact if one was to use a single kernel image for beagleboard and beaglebone, for the cape to work for both, it is required for it's dtb to be compatible. We're not there yet, but people would like to have an upgrade path. beaglebone -> beagleboard -> pandaboard -> future-boards It is not possible yet, but perhaps newer boards could have that. > Consider something like the Arduino shield connector format, which I > /believe/ has been re-used across a wide variety of Arduino boards and > other compatible or imitation boards. Now consider a vendor of an > Arduino shield. The shield vendor probably wants to publish a single > .dtb file that works for users irrespective of which board they're using > it with. > > (Well, I'm not sure that Arduino can run Linux; perhaps that's why you > picked BeagleBone capes for your document!) > Arduino can't possible do it. Using arduino shields with an adapter could be possible though. > I suppose it would be acceptable for the shield vendor to ship the .dts > file rather than the .dtb, and hence need to build the shield .dtb for a > specific base board. > > However, I think the process for an end-user needs to be as simple as > "drop this .dts/.dtb file into some standard directory", and I imagine > it'll be much easier for distros/... to make that process work if > they're dealing with a .dtb that they can just blast into the kernel's > firmware loader interface, rather than having to also locate the > base-board .dts/.dtb file, and run dtc and/or other tools on both .dts > files together. Yes. A single supported dtb is the way to go ideally. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 12:10 ` Pantelis Antoniou (?) @ 2012-11-12 16:52 ` Stephen Warren 2012-11-13 7:25 ` David Gibson -1 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-12 16:52 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: > >> On 11/09/2012 09:28 AM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> ... >>>> I do rather suspect this use-case is quite common. NVIDIA certainly has >>>> a bunch of development boards with pluggable >>>> PMIC/audio/WiFi/display/..., and I believe there's some ability to >>>> re-use the pluggable components with a variety of base-boards. >>>> >>>> Given people within NVIDIA started talking about this recently, I asked >>>> them to enumerate all the boards we have that support pluggable >>>> components, and how common it is that some boards support being plugged >>>> into different main boards. I don't know when that enumeration will >>>> complete (or even start) but hopefully I can provide some feedback on >>>> how common the use-case is for us once it's done. >>> >>> From your perspective, is it important to use the exact same .dtb >>> overlays for those add-on boards, or is it okay to have a separate >>> build of the overlay for each base tree? >> >> I certainly think it'd be extremely beneficial to use the exact same >> child board .dtb with arbitrary base boards. >> > > Oh yes. In fact if one was to use a single kernel image for beagleboard > and beaglebone, for the cape to work for both, it is required for it's > dtb to be compatible. Well, as Grant pointed out, it's not actually strictly necessary for the .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb can be generated at run-time using dtc for example. Of course, relying on .dts compatibility rather than .dtb compatibility might negatively impact the complexity of an initrd environment if we end up loading overlays from there... > We're not there yet, but people would like to have an upgrade path. > > beaglebone -> beagleboard -> pandaboard -> future-boards > > It is not possible yet, but perhaps newer boards could have that. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 16:52 ` Stephen Warren @ 2012-11-13 7:25 ` David Gibson 2012-11-13 8:09 ` Pantelis Antoniou 2012-11-13 16:57 ` Stephen Warren 0 siblings, 2 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 7:25 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: > On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: [snip] > > Oh yes. In fact if one was to use a single kernel image for beagleboard > > and beaglebone, for the cape to work for both, it is required for it's > > dtb to be compatible. > > Well, as Grant pointed out, it's not actually strictly necessary for the > .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb > can be generated at run-time using dtc for example. So, actually, I think a whole bunch of problems with phandle resolution disappear if we don't try to define an overlay .dtb format, or at least treat it only as a very shortlived object. A more precise proposal below. Note that this works more or less equally well with either the original overlay approach or the graft/graft-bundle proposal I made elsewhere. 1) We annotate the base tree with some extra label information for nodes which overlays are likely to want to reference by phandle. e.g. beaglebone_pic: interrupt-controller@XXXXX { ... phandle,symbolic-name = "beaglebone_pic"; }; We could extend dtc to (optionally?) auto-generate those properties from its existing label syntax. Not sure if that's a good idea or not yet. In any case, we compile this augmented base tree to .dtb as normal and boot our kernel with it. 2) The information for the capes/modules/whatever is distributed/packaged as .dts, never .dtb. When userspace detects the new module (or the user explicitly tells it, if it's not probeable) it picks up the correct dts and runs it through dtc in a special mode. In this mode dtc takes the existing base tree (from /proc/device-tree, say) as well as the new dts. In this mode, dtc allocates phandles for the new tree fragment so as not to collide with anything from the supplied base tree (as well as avoiding internal conflicts, obviously). It also allows node references to the base tree by using those label annotations from (1) to match symbolic names to the phandle values in the base tree. 3) The resulting partial .dtb for the module is highly specific to the base tree (which if the base tree was generated at runtime by firmware could even be specific to a particular boot). But that's ok, because we just spit it into the kernel, absolute phandle values and all, then throw it away. Next time we need the module info, we recompile it again. > Of course, relying on .dts compatibility rather than .dtb compatibility > might negatively impact the complexity of an initrd environment if we > end up loading overlays from there... Well, it does mean we'd need dtc in the initrd. But dtc has no library dependencies except libc, so that really shouldn't be too bad. In return we entirely avoid inventing a new phandle resolution protocol. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 8:09 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-13 8:09 UTC (permalink / raw) To: David Gibson Cc: Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss Hi David, On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > [snip] >>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>> and beaglebone, for the cape to work for both, it is required for it's >>> dtb to be compatible. >> >> Well, as Grant pointed out, it's not actually strictly necessary for the >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >> can be generated at run-time using dtc for example. > > So, actually, I think a whole bunch of problems with phandle > resolution disappear if we don't try to define an overlay .dtb format, > or at least treat it only as a very shortlived object. A more precise > proposal below. Note that this works more or less equally well with > either the original overlay approach or the graft/graft-bundle > proposal I made elsewhere. > > 1) We annotate the base tree with some extra label information for > nodes which overlays are likely to want to reference by phandle. e.g. > > beaglebone_pic: interrupt-controller@XXXXX { > ... > phandle,symbolic-name = "beaglebone_pic"; > }; > > We could extend dtc to (optionally?) auto-generate those properties > from its existing label syntax. Not sure if that's a good idea or > not yet. In any case, we compile this augmented base tree to .dtb as > normal and boot our kernel with it. > I'm fine with that. You can auto-generate when there's a label to a node. The cape dt fragment will use the label name to reference a node. More details below... > 2) The information for the capes/modules/whatever is > distributed/packaged as .dts, never .dtb. When userspace detects the > new module (or the user explicitly tells it, if it's not probeable) it > picks up the correct dts and runs it through dtc in a special mode. > In this mode dtc takes the existing base tree (from /proc/device-tree, > say) as well as the new dts. In this mode, dtc allocates phandles for > the new tree fragment so as not to collide with anything from the > supplied base tree (as well as avoiding internal conflicts, > obviously). It also allows node references to the base tree by using > those label annotations from (1) to match symbolic names to the > phandle values in the base tree. > Not good to rely on userspace kicking off dtc and compiling from source. Some capes/expansion boards might have your root fs device, for example there is an eMMC cape coming up, while networking capes are common too. However I have a compromise. I agree that compiling from source can be an option for a runtime definable cape, but for built-in capes we could do a bit better. In particular, I don't see any particular need to have a DT fragment reference anything that dependent of the runtime device tree. It should be possible to compile the DT fragment in kernel, against the generated flattened device tree, producing a flattened DT fragment with the phandles already resolved. So the sequence could be something like this: $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. Alternatively we could have a way to statically assign a phandle range for well known capes. All the others will have to use the runtime compile mechanism. $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts With the cape dtses having a /phandle-range/ statement at the top. This can work because the cape dts do not cross-reference each other, and neither the boot dts references the capes. That way we can use request_firmware() pretty early in the boot sequence and get the DT fragment we need even before user-space starts and root fs has mounted. request_firmware() can locate the fragments in the kernel image before rootfs. I don't know if this will cover all the cases Grant has in mind though. So just to make sure I got it right, this could work for our case. i2c2: i2c@4819c000 { compatible = "ti,omap4-i2c"; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c3"; reg = <0x4819c000 0x1000>; interrupt-parent = <&intc>; interrupts = <30>; status = "disabled"; }; And in the cape definition (when compiled with the special mode I describe below) / { plugin-bundle; compatible = "cco,weather-cape"; version = <00A0>; i2c2-graft = { compatible = <dt,graft>; graft-point = <&i2c2>; #address-cells = <1>; #size-cells = <0>; /* Ambient light sensor */ tsl2550@39 { compatible = "tsl,tsl2550"; reg = <0x39>; }; }; }; DTC when compiling in the special fragment mode will pick up that &i2c2 can not be resolved and lookup the phandle on the main dtb. That way, even 'phandle,symbolic-name = "i2c2";' is redundant. > 3) The resulting partial .dtb for the module is highly specific to the > base tree (which if the base tree was generated at runtime by firmware > could even be specific to a particular boot). But that's ok, because > we just spit it into the kernel, absolute phandle values and all, then > throw it away. Next time we need the module info, we recompile it > again. > >> Of course, relying on .dts compatibility rather than .dtb compatibility >> might negatively impact the complexity of an initrd environment if we >> end up loading overlays from there... > > Well, it does mean we'd need dtc in the initrd. But dtc has no > library dependencies except libc, so that really shouldn't be too > bad. In return we entirely avoid inventing a new phandle resolution > protocol. > Not every board boots with initrd; most embedded boards don't use it at all. This way we make initrd a hard requirement. It's best if we avoid it. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 8:09 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-13 8:09 UTC (permalink / raw) To: David Gibson Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi David, On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > [snip] >>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>> and beaglebone, for the cape to work for both, it is required for it's >>> dtb to be compatible. >> >> Well, as Grant pointed out, it's not actually strictly necessary for the >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >> can be generated at run-time using dtc for example. > > So, actually, I think a whole bunch of problems with phandle > resolution disappear if we don't try to define an overlay .dtb format, > or at least treat it only as a very shortlived object. A more precise > proposal below. Note that this works more or less equally well with > either the original overlay approach or the graft/graft-bundle > proposal I made elsewhere. > > 1) We annotate the base tree with some extra label information for > nodes which overlays are likely to want to reference by phandle. e.g. > > beaglebone_pic: interrupt-controller@XXXXX { > ... > phandle,symbolic-name = "beaglebone_pic"; > }; > > We could extend dtc to (optionally?) auto-generate those properties > from its existing label syntax. Not sure if that's a good idea or > not yet. In any case, we compile this augmented base tree to .dtb as > normal and boot our kernel with it. > I'm fine with that. You can auto-generate when there's a label to a node. The cape dt fragment will use the label name to reference a node. More details below... > 2) The information for the capes/modules/whatever is > distributed/packaged as .dts, never .dtb. When userspace detects the > new module (or the user explicitly tells it, if it's not probeable) it > picks up the correct dts and runs it through dtc in a special mode. > In this mode dtc takes the existing base tree (from /proc/device-tree, > say) as well as the new dts. In this mode, dtc allocates phandles for > the new tree fragment so as not to collide with anything from the > supplied base tree (as well as avoiding internal conflicts, > obviously). It also allows node references to the base tree by using > those label annotations from (1) to match symbolic names to the > phandle values in the base tree. > Not good to rely on userspace kicking off dtc and compiling from source. Some capes/expansion boards might have your root fs device, for example there is an eMMC cape coming up, while networking capes are common too. However I have a compromise. I agree that compiling from source can be an option for a runtime definable cape, but for built-in capes we could do a bit better. In particular, I don't see any particular need to have a DT fragment reference anything that dependent of the runtime device tree. It should be possible to compile the DT fragment in kernel, against the generated flattened device tree, producing a flattened DT fragment with the phandles already resolved. So the sequence could be something like this: $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. Alternatively we could have a way to statically assign a phandle range for well known capes. All the others will have to use the runtime compile mechanism. $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts With the cape dtses having a /phandle-range/ statement at the top. This can work because the cape dts do not cross-reference each other, and neither the boot dts references the capes. That way we can use request_firmware() pretty early in the boot sequence and get the DT fragment we need even before user-space starts and root fs has mounted. request_firmware() can locate the fragments in the kernel image before rootfs. I don't know if this will cover all the cases Grant has in mind though. So just to make sure I got it right, this could work for our case. i2c2: i2c@4819c000 { compatible = "ti,omap4-i2c"; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c3"; reg = <0x4819c000 0x1000>; interrupt-parent = <&intc>; interrupts = <30>; status = "disabled"; }; And in the cape definition (when compiled with the special mode I describe below) / { plugin-bundle; compatible = "cco,weather-cape"; version = <00A0>; i2c2-graft = { compatible = <dt,graft>; graft-point = <&i2c2>; #address-cells = <1>; #size-cells = <0>; /* Ambient light sensor */ tsl2550@39 { compatible = "tsl,tsl2550"; reg = <0x39>; }; }; }; DTC when compiling in the special fragment mode will pick up that &i2c2 can not be resolved and lookup the phandle on the main dtb. That way, even 'phandle,symbolic-name = "i2c2";' is redundant. > 3) The resulting partial .dtb for the module is highly specific to the > base tree (which if the base tree was generated at runtime by firmware > could even be specific to a particular boot). But that's ok, because > we just spit it into the kernel, absolute phandle values and all, then > throw it away. Next time we need the module info, we recompile it > again. > >> Of course, relying on .dts compatibility rather than .dtb compatibility >> might negatively impact the complexity of an initrd environment if we >> end up loading overlays from there... > > Well, it does mean we'd need dtc in the initrd. But dtc has no > library dependencies except libc, so that really shouldn't be too > bad. In return we entirely avoid inventing a new phandle resolution > protocol. > Not every board boots with initrd; most embedded boards don't use it at all. This way we make initrd a hard requirement. It's best if we avoid it. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 8:09 ` Pantelis Antoniou (?) @ 2012-11-13 12:24 ` Grant Likely 2012-11-13 13:38 ` Pantelis Antoniou -1 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-13 12:24 UTC (permalink / raw) To: Pantelis Antoniou Cc: David Gibson, Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > Not good to rely on userspace kicking off dtc and compiling from source. > Some capes/expansion boards might have your root fs device, for example > there is an eMMC cape coming up, while networking capes are common too. > > However I have a compromise. > > I agree that compiling from source can be an option for a runtime definable > cape, but for built-in capes we could do a bit better. > > In particular, I don't see any particular need to have a DT fragment > reference anything that dependent of the runtime device tree. It should > be possible to compile the DT fragment in kernel, against the generated > flattened device tree, producing a flattened DT fragment with the phandles > already resolved. Do you mean linking dtc into the kernel? > So the sequence could be something like this: > > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} > > The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. > > Alternatively we could have a way to statically assign a phandle range > for well known capes. All the others will have to use the runtime compile > mechanism. > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts > > With the cape dtses having a /phandle-range/ statement at the top. I really think the whole phandle allocation thing is a non problem. Generating phandles is the easy part, and using a good hash function pretty much solves it entirely. I know people are worried about collisions, but there are only two scenarios where collisions may happen: 1) base and overlay try to define same phandle - Easy to detect - kernel can complain and refuse to load if it happens - Will never happen when overlay is compiled against the base used to boot (dtc can resolve the conflict) - Hash phandle generation makes this exceptionally rare 2) two overlays try to define same phandle - Also easy to detect on loading the second overlay - kernel will - Hash phandle generation still makes this exceptionally rare In both cases a collision is extremely rare and if it does happen it will not fail silently. Besides, in the odd scenario where it does happen, a node can be manually assigned a phandle. It is far better to do the manual override maybe once or twice (actually, I'd be surprised if it is ever needed) than to get into any kind of numberspace management for phandles. That's just a maintenance nightmare. The hard bit to solve has always been when the overlay expects different phandles than the base is using, and that problem only occurs if the overlay is compiled against a different base dtb than was used to boot the system. Hashed phandle generation even makes phandles very stable when the base dtb is recompiled, and if they do change, then the kernel can detect it and report an error. Again, no silent failures. Phandle fixup does make the problem disappears entirely but I'm concerned that it is still incomplete (see below) and would be conceptually expensive. Once of the requests is to support one overlay .dtb with many different baseboards, but now that I've thought about it more I realize that it just won't work for anything beyond the most trivial case. Phandle fixup isn's sufficient. The format of GPIO, Interrupt, clock, etc specifiers may change if the base board nodes change. The specifiers are not portable. So, I no longer think that plain dtb overlays alone will work against any base board. Something more is needed. It may be the mechanism for loading new data into the kernel, but something really generic does require either being compiled at runtime (as David suggests) or each expansion interface (ie. the BeagleBone expansion or the RPi expansion) to really specify what kinds of references are allowed and run all specifiers through translation nodes. Similar to how interrupt-map works. > i2c2: i2c@4819c000 { > compatible = "ti,omap4-i2c"; > #address-cells = <1>; > #size-cells = <0>; > ti,hwmods = "i2c3"; > reg = <0x4819c000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <30>; > status = "disabled"; > }; > > And in the cape definition (when compiled with the special mode I describe > below) > > / { > plugin-bundle; > compatible = "cco,weather-cape"; > version = <00A0>; > > i2c2-graft = { > compatible = <dt,graft>; > graft-point = <&i2c2>; Since overlays are different, we can interpret them slightly differently. The node name itself could be the graft point, and the name could be either a full path "/foo/bar/i2c@10002000" or an alias reference "i2c2". I think that is a bit better than a new graft-point property. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 13:38 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-13 13:38 UTC (permalink / raw) To: Grant Likely Cc: David Gibson, Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss Hi Grant, On Nov 13, 2012, at 2:24 PM, Grant Likely wrote: > On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: >> On Nov 13, 2012, at 9:25 AM, David Gibson wrote: >> Not good to rely on userspace kicking off dtc and compiling from source. >> Some capes/expansion boards might have your root fs device, for example >> there is an eMMC cape coming up, while networking capes are common too. >> >> However I have a compromise. >> >> I agree that compiling from source can be an option for a runtime definable >> cape, but for built-in capes we could do a bit better. >> >> In particular, I don't see any particular need to have a DT fragment >> reference anything that dependent of the runtime device tree. It should >> be possible to compile the DT fragment in kernel, against the generated >> flattened device tree, producing a flattened DT fragment with the phandles >> already resolved. > > Do you mean linking dtc into the kernel? No, no :) Typo there, s/in kernel/outside of the kernel/ > >> So the sequence could be something like this: >> >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} >> >> The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. >> >> Alternatively we could have a way to statically assign a phandle range >> for well known capes. All the others will have to use the runtime compile >> mechanism. >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts >> >> With the cape dtses having a /phandle-range/ statement at the top. > > I really think the whole phandle allocation thing is a non problem. > Generating phandles is the easy part, and using a good hash function > pretty much solves it entirely. I know people are worried about > collisions, but there are only two scenarios where collisions may > happen: > > 1) base and overlay try to define same phandle > - Easy to detect - kernel can complain and refuse to load if it happens > - Will never happen when overlay is compiled against the base used > to boot (dtc can resolve the conflict) > - Hash phandle generation makes this exceptionally rare > 2) two overlays try to define same phandle > - Also easy to detect on loading the second overlay - kernel will > - Hash phandle generation still makes this exceptionally rare > > In both cases a collision is extremely rare and if it does happen it > will not fail silently. Besides, in the odd scenario where it does > happen, a node can be manually assigned a phandle. It is far better to > do the manual override maybe once or twice (actually, I'd be surprised > if it is ever needed) than to get into any kind of numberspace > management for phandles. That's just a maintenance nightmare. > The reason people (or at least me) is wary of collisions is that it throws the user completely out of the normal workflow. i.e. normal workflow is like this: a) Edit cape DTS b) Feed the DTB to the running kernel c) It works. When a collision happens c turns into c.1) Fails with a message that 'there's a phandle collision' c.2) Google about the error message, land on a page describing solution. c.3) Modify the cape DTS to use an explicit phandle value. c.4) It finally works. Let's just say I don't expect users to deal with this easily. Anyway, it's all academic at this point. I mostly care about making the in-kernel dtc compile to handle the collisions automatically. I think we agree that compiling a fragment that doesn't export any phandles against the base dts, should produce a dtb that would load without any collisions. > The hard bit to solve has always been when the overlay expects > different phandles than the base is using, and that problem only > occurs if the overlay is compiled against a different base dtb than > was used to boot the system. Hashed phandle generation even makes > phandles very stable when the base dtb is recompiled, and if they do > change, then the kernel can detect it and report an error. Again, no > silent failures. Phandle fixup does make the problem disappears > entirely but I'm concerned that it is still incomplete (see below) and > would be conceptually expensive. > > Once of the requests is to support one overlay .dtb with many > different baseboards, but now that I've thought about it more I > realize that it just won't work for anything beyond the most trivial > case. Phandle fixup isn's sufficient. The format of GPIO, Interrupt, > clock, etc specifiers may change if the base board nodes change. The > specifiers are not portable. > My intention wasn't never to make overlays overly portable. My intention was to make them in a way that portability can be introduced if the boards are 'close' enough, but not for arbitrary boards. There have to be compatible interfaces both on the base, and the overlay dtbs. > So, I no longer think that plain dtb overlays alone will work against > any base board. Something more is needed. It may be the mechanism for > loading new data into the kernel, but something really generic does > require either being compiled at runtime (as David suggests) or each > expansion interface (ie. the BeagleBone expansion or the RPi > expansion) to really specify what kinds of references are allowed and > run all specifiers through translation nodes. Similar to how > interrupt-map works. > All things point to the latter. >> i2c2: i2c@4819c000 { >> compatible = "ti,omap4-i2c"; >> #address-cells = <1>; >> #size-cells = <0>; >> ti,hwmods = "i2c3"; >> reg = <0x4819c000 0x1000>; >> interrupt-parent = <&intc>; >> interrupts = <30>; >> status = "disabled"; >> }; >> >> And in the cape definition (when compiled with the special mode I describe >> below) >> >> / { >> plugin-bundle; >> compatible = "cco,weather-cape"; >> version = <00A0>; >> >> i2c2-graft = { >> compatible = <dt,graft>; >> graft-point = <&i2c2>; > > Since overlays are different, we can interpret them slightly > differently. The node name itself could be the graft point, and the > name could be either a full path "/foo/bar/i2c@10002000" or an alias > reference "i2c2". I think that is a bit better than a new graft-point > property. > Can you expand a bit on the exact syntax? > g. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 13:38 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-13 13:38 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ Hi Grant, On Nov 13, 2012, at 2:24 PM, Grant Likely wrote: > On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou > <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >> On Nov 13, 2012, at 9:25 AM, David Gibson wrote: >> Not good to rely on userspace kicking off dtc and compiling from source. >> Some capes/expansion boards might have your root fs device, for example >> there is an eMMC cape coming up, while networking capes are common too. >> >> However I have a compromise. >> >> I agree that compiling from source can be an option for a runtime definable >> cape, but for built-in capes we could do a bit better. >> >> In particular, I don't see any particular need to have a DT fragment >> reference anything that dependent of the runtime device tree. It should >> be possible to compile the DT fragment in kernel, against the generated >> flattened device tree, producing a flattened DT fragment with the phandles >> already resolved. > > Do you mean linking dtc into the kernel? No, no :) Typo there, s/in kernel/outside of the kernel/ > >> So the sequence could be something like this: >> >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} >> >> The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. >> >> Alternatively we could have a way to statically assign a phandle range >> for well known capes. All the others will have to use the runtime compile >> mechanism. >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts >> >> With the cape dtses having a /phandle-range/ statement at the top. > > I really think the whole phandle allocation thing is a non problem. > Generating phandles is the easy part, and using a good hash function > pretty much solves it entirely. I know people are worried about > collisions, but there are only two scenarios where collisions may > happen: > > 1) base and overlay try to define same phandle > - Easy to detect - kernel can complain and refuse to load if it happens > - Will never happen when overlay is compiled against the base used > to boot (dtc can resolve the conflict) > - Hash phandle generation makes this exceptionally rare > 2) two overlays try to define same phandle > - Also easy to detect on loading the second overlay - kernel will > - Hash phandle generation still makes this exceptionally rare > > In both cases a collision is extremely rare and if it does happen it > will not fail silently. Besides, in the odd scenario where it does > happen, a node can be manually assigned a phandle. It is far better to > do the manual override maybe once or twice (actually, I'd be surprised > if it is ever needed) than to get into any kind of numberspace > management for phandles. That's just a maintenance nightmare. > The reason people (or at least me) is wary of collisions is that it throws the user completely out of the normal workflow. i.e. normal workflow is like this: a) Edit cape DTS b) Feed the DTB to the running kernel c) It works. When a collision happens c turns into c.1) Fails with a message that 'there's a phandle collision' c.2) Google about the error message, land on a page describing solution. c.3) Modify the cape DTS to use an explicit phandle value. c.4) It finally works. Let's just say I don't expect users to deal with this easily. Anyway, it's all academic at this point. I mostly care about making the in-kernel dtc compile to handle the collisions automatically. I think we agree that compiling a fragment that doesn't export any phandles against the base dts, should produce a dtb that would load without any collisions. > The hard bit to solve has always been when the overlay expects > different phandles than the base is using, and that problem only > occurs if the overlay is compiled against a different base dtb than > was used to boot the system. Hashed phandle generation even makes > phandles very stable when the base dtb is recompiled, and if they do > change, then the kernel can detect it and report an error. Again, no > silent failures. Phandle fixup does make the problem disappears > entirely but I'm concerned that it is still incomplete (see below) and > would be conceptually expensive. > > Once of the requests is to support one overlay .dtb with many > different baseboards, but now that I've thought about it more I > realize that it just won't work for anything beyond the most trivial > case. Phandle fixup isn's sufficient. The format of GPIO, Interrupt, > clock, etc specifiers may change if the base board nodes change. The > specifiers are not portable. > My intention wasn't never to make overlays overly portable. My intention was to make them in a way that portability can be introduced if the boards are 'close' enough, but not for arbitrary boards. There have to be compatible interfaces both on the base, and the overlay dtbs. > So, I no longer think that plain dtb overlays alone will work against > any base board. Something more is needed. It may be the mechanism for > loading new data into the kernel, but something really generic does > require either being compiled at runtime (as David suggests) or each > expansion interface (ie. the BeagleBone expansion or the RPi > expansion) to really specify what kinds of references are allowed and > run all specifiers through translation nodes. Similar to how > interrupt-map works. > All things point to the latter. >> i2c2: i2c@4819c000 { >> compatible = "ti,omap4-i2c"; >> #address-cells = <1>; >> #size-cells = <0>; >> ti,hwmods = "i2c3"; >> reg = <0x4819c000 0x1000>; >> interrupt-parent = <&intc>; >> interrupts = <30>; >> status = "disabled"; >> }; >> >> And in the cape definition (when compiled with the special mode I describe >> below) >> >> / { >> plugin-bundle; >> compatible = "cco,weather-cape"; >> version = <00A0>; >> >> i2c2-graft = { >> compatible = <dt,graft>; >> graft-point = <&i2c2>; > > Since overlays are different, we can interpret them slightly > differently. The node name itself could be the graft point, and the > name could be either a full path "/foo/bar/i2c@10002000" or an alias > reference "i2c2". I think that is a bit better than a new graft-point > property. > Can you expand a bit on the exact syntax? > g. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 13:38 ` Pantelis Antoniou (?) @ 2012-11-15 4:57 ` David Gibson -1 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-15 4:57 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Tue, Nov 13, 2012 at 03:38:18PM +0200, Pantelis Antoniou wrote: > Hi Grant, > > On Nov 13, 2012, at 2:24 PM, Grant Likely wrote: > > On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou [snip] > My intention wasn't never to make overlays overly portable. My intention > was to make them in a way that portability can be introduced if the boards > are 'close' enough, but not for arbitrary boards. > > There have to be compatible interfaces both on the base, and the overlay > dtbs. Right. And this is why I'm arguing that those interfaces should be described explicitly - using existing OF mechanisms like interrupt-map where possible, rather than having a very general, but very low-level interface to make arbitrary changes to the DT. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 8:09 ` Pantelis Antoniou (?) (?) @ 2012-11-13 17:10 ` Stephen Warren -1 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-13 17:10 UTC (permalink / raw) To: Pantelis Antoniou Cc: David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/13/2012 01:09 AM, Pantelis Antoniou wrote: > On Nov 13, 2012, at 9:25 AM, David Gibson wrote: ... >> 1) We annotate the base tree with some extra label information for >> nodes which overlays are likely to want to reference by phandle. e.g. >> >> beaglebone_pic: interrupt-controller@XXXXX { >> ... >> phandle,symbolic-name = "beaglebone_pic"; >> }; >> >> We could extend dtc to (optionally?) auto-generate those properties >> from its existing label syntax. Not sure if that's a good idea or >> not yet. In any case, we compile this augmented base tree to .dtb as >> normal and boot our kernel with it. > > I'm fine with that. You can auto-generate when there's a label to a node. > The cape dt fragment will use the label name to reference a node. > More details below... > >> 2) The information for the capes/modules/whatever is >> distributed/packaged as .dts, never .dtb. When userspace detects the >> new module (or the user explicitly tells it, if it's not probeable) it >> picks up the correct dts and runs it through dtc in a special mode. >> In this mode dtc takes the existing base tree (from /proc/device-tree, >> say) as well as the new dts. In this mode, dtc allocates phandles for >> the new tree fragment so as not to collide with anything from the >> supplied base tree (as well as avoiding internal conflicts, >> obviously). It also allows node references to the base tree by using >> those label annotations from (1) to match symbolic names to the >> phandle values in the base tree. > > Not good to rely on userspace kicking off dtc and compiling from source. > Some capes/expansion boards might have your root fs device, for example > there is an eMMC cape coming up, while networking capes are common too. > > However I have a compromise. > > I agree that compiling from source can be an option for a runtime definable > cape, but for built-in capes we could do a bit better. > > In particular, I don't see any particular need to have a DT fragment > reference anything that dependent of the runtime device tree. It should > be possible to compile the DT fragment in kernel, against the generated > flattened device tree, producing a flattened DT fragment with the phandles > already resolved. > > So the sequence could be something like this: > > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} > > The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. I'm not sure that will avoid phandle collisions though. If you build everything at runtime, you'll always be compiling each new partial .dtb based on the phandles actually in-use in the kernel's current complete device tree. You can always easily avoid collisions that way. If you instead pre-compile both the based .dtb /and/ some partial .dtbs, then you're essentially statically defining some phandle values, but splitting those static assignments across 3 (in your example) different .dtbs. However, what guarantees that those 3 .dtbs are already loaded into the system when some fourth partial .dtb is loaded, such that the static phandle assignments influence that fourth partial .dtb's runtime compilation? Put another way, what happens when you: 1) Boot the kernel using am335x-bone.dtb. 2) Incrementally load weather-cape.dtb. Don't incrementally load geiger-cape.dtb for whatever reason. 3) Load runtime-compiled-cape.dtb. This avoids conflicts with the already-loaded am335x-bone.dtb and weather-cape.dtb since runtime-compiled-cape.dtb is compiled at runtime based on the currently loaded .dtbs. However, it may well end up conflicting with geiger-cape.dtb since that isn't loaded. 4) Now attempt to load geiger-cape.dtb - possible conflict. Given all of that, I'd assert that if you want to statically assign any phandles, all static assignments need to be done in the base .dtb that the kernel is loaded with, and not in any pre-compiled partial .dtbs. So, if your root filesystem is on an eMMC cape, then you need to create a board .dts file that /include/s the base board .dts and the cape .dts files and boot the kernel with that. Or, you get U-Boot/... to merge the relevant pre-compiled .dtbs and boot the kernel with that. Or I suppose you could have a well-known range of phandles for pre-compiled .dtbs that the runtime dtc mode always avoided, preferably without the need for explicit phandle-range statements in the .dts files, e.g. driven by a dtc static-assignment-vs-dynamic-assignment command-line option? ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 23:30 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 23:30 UTC (permalink / raw) To: Pantelis Antoniou Cc: Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Tue, Nov 13, 2012 at 10:09:28AM +0200, Pantelis Antoniou wrote: > Hi David, > > On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > > > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: > >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > > [snip] > >>> Oh yes. In fact if one was to use a single kernel image for beagleboard > >>> and beaglebone, for the cape to work for both, it is required for it's > >>> dtb to be compatible. > >> > >> Well, as Grant pointed out, it's not actually strictly necessary for the > >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb > >> can be generated at run-time using dtc for example. > > > > So, actually, I think a whole bunch of problems with phandle > > resolution disappear if we don't try to define an overlay .dtb format, > > or at least treat it only as a very shortlived object. A more precise > > proposal below. Note that this works more or less equally well with > > either the original overlay approach or the graft/graft-bundle > > proposal I made elsewhere. > > > > 1) We annotate the base tree with some extra label information for > > nodes which overlays are likely to want to reference by phandle. e.g. > > > > beaglebone_pic: interrupt-controller@XXXXX { > > ... > > phandle,symbolic-name = "beaglebone_pic"; > > }; > > > > We could extend dtc to (optionally?) auto-generate those properties > > from its existing label syntax. Not sure if that's a good idea or > > not yet. In any case, we compile this augmented base tree to .dtb as > > normal and boot our kernel with it. > > > > I'm fine with that. You can auto-generate when there's a label to a node. > The cape dt fragment will use the label name to reference a node. > More details below... > > > 2) The information for the capes/modules/whatever is > > distributed/packaged as .dts, never .dtb. When userspace detects the > > new module (or the user explicitly tells it, if it's not probeable) it > > picks up the correct dts and runs it through dtc in a special mode. > > In this mode dtc takes the existing base tree (from /proc/device-tree, > > say) as well as the new dts. In this mode, dtc allocates phandles for > > the new tree fragment so as not to collide with anything from the > > supplied base tree (as well as avoiding internal conflicts, > > obviously). It also allows node references to the base tree by using > > those label annotations from (1) to match symbolic names to the > > phandle values in the base tree. > > > > Not good to rely on userspace kicking off dtc and compiling from source. > Some capes/expansion boards might have your root fs device, for example > there is an eMMC cape coming up, while networking capes are common too. So? dtc can go in an initramfs, just like mdadm or whatever other tools are there. > However I have a compromise. > > I agree that compiling from source can be an option for a runtime definable > cape, but for built-in capes we could do a bit better. > > In particular, I don't see any particular need to have a DT fragment > reference anything that dependent of the runtime device tree. It should > be possible to compile the DT fragment in kernel, against the generated > flattened device tree, producing a flattened DT fragment with the phandles > already resolved. Um..? Sorry, I can't parse that paragraph. > So the sequence could be something like this: > > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} > > The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. > > Alternatively we could have a way to statically assign a phandle range > for well known capes. All the others will have to use the runtime compile > mechanism. > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts > > With the cape dtses having a /phandle-range/ statement at the top. > > This can work because the cape dts do not cross-reference each other, and > neither the boot dts references the capes. > > That way we can use request_firmware() pretty early in the boot sequence > and get the DT fragment we need even before user-space starts and root fs > has mounted. request_firmware() can locate the fragments in the kernel > image before rootfs. > > I don't know if this will cover all the cases Grant has in mind though. > > So just to make sure I got it right, this could work for our case. > > i2c2: i2c@4819c000 { > compatible = "ti,omap4-i2c"; > #address-cells = <1>; > #size-cells = <0>; > ti,hwmods = "i2c3"; > reg = <0x4819c000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <30>; > status = "disabled"; > }; > > And in the cape definition (when compiled with the special mode I describe > below) > > / { > plugin-bundle; > compatible = "cco,weather-cape"; > version = <00A0>; > > i2c2-graft = { > compatible = <dt,graft>; > graft-point = <&i2c2>; > > #address-cells = <1>; > #size-cells = <0>; > > /* Ambient light sensor */ > tsl2550@39 { > compatible = "tsl,tsl2550"; > reg = <0x39>; > }; > }; > }; > > DTC when compiling in the special fragment mode will pick up that > &i2c2 can not be resolved and lookup the phandle on the main dtb. > That way, even 'phandle,symbolic-name = "i2c2";' is redundant. Well, no, because I'm assuming dtc fragment mode only has access to the base dtb, not the base dts, so labels will be gone from it, unless we add properties to preserve them especially. That's what the symbolic-name thing is about. > > 3) The resulting partial .dtb for the module is highly specific to the > > base tree (which if the base tree was generated at runtime by firmware > > could even be specific to a particular boot). But that's ok, because > > we just spit it into the kernel, absolute phandle values and all, then > > throw it away. Next time we need the module info, we recompile it > > again. > > > >> Of course, relying on .dts compatibility rather than .dtb compatibility > >> might negatively impact the complexity of an initrd environment if we > >> end up loading overlays from there... > > > > Well, it does mean we'd need dtc in the initrd. But dtc has no > > library dependencies except libc, so that really shouldn't be too > > bad. In return we entirely avoid inventing a new phandle resolution > > protocol. > > Not every board boots with initrd; most embedded boards don't use it > at all. This way we make initrd a hard requirement. Well, not really. You can use initramfs, or you can assemble all the necessary dt fragents for boot into a complete dtb included with the kernel. Doing that involves pretty much the same sorts of things you need to do to statically configure a kernel for boot without initramfs. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 23:30 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 23:30 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Tue, Nov 13, 2012 at 10:09:28AM +0200, Pantelis Antoniou wrote: > Hi David, > > On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > > > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: > >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > > [snip] > >>> Oh yes. In fact if one was to use a single kernel image for beagleboard > >>> and beaglebone, for the cape to work for both, it is required for it's > >>> dtb to be compatible. > >> > >> Well, as Grant pointed out, it's not actually strictly necessary for the > >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb > >> can be generated at run-time using dtc for example. > > > > So, actually, I think a whole bunch of problems with phandle > > resolution disappear if we don't try to define an overlay .dtb format, > > or at least treat it only as a very shortlived object. A more precise > > proposal below. Note that this works more or less equally well with > > either the original overlay approach or the graft/graft-bundle > > proposal I made elsewhere. > > > > 1) We annotate the base tree with some extra label information for > > nodes which overlays are likely to want to reference by phandle. e.g. > > > > beaglebone_pic: interrupt-controller@XXXXX { > > ... > > phandle,symbolic-name = "beaglebone_pic"; > > }; > > > > We could extend dtc to (optionally?) auto-generate those properties > > from its existing label syntax. Not sure if that's a good idea or > > not yet. In any case, we compile this augmented base tree to .dtb as > > normal and boot our kernel with it. > > > > I'm fine with that. You can auto-generate when there's a label to a node. > The cape dt fragment will use the label name to reference a node. > More details below... > > > 2) The information for the capes/modules/whatever is > > distributed/packaged as .dts, never .dtb. When userspace detects the > > new module (or the user explicitly tells it, if it's not probeable) it > > picks up the correct dts and runs it through dtc in a special mode. > > In this mode dtc takes the existing base tree (from /proc/device-tree, > > say) as well as the new dts. In this mode, dtc allocates phandles for > > the new tree fragment so as not to collide with anything from the > > supplied base tree (as well as avoiding internal conflicts, > > obviously). It also allows node references to the base tree by using > > those label annotations from (1) to match symbolic names to the > > phandle values in the base tree. > > > > Not good to rely on userspace kicking off dtc and compiling from source. > Some capes/expansion boards might have your root fs device, for example > there is an eMMC cape coming up, while networking capes are common too. So? dtc can go in an initramfs, just like mdadm or whatever other tools are there. > However I have a compromise. > > I agree that compiling from source can be an option for a runtime definable > cape, but for built-in capes we could do a bit better. > > In particular, I don't see any particular need to have a DT fragment > reference anything that dependent of the runtime device tree. It should > be possible to compile the DT fragment in kernel, against the generated > flattened device tree, producing a flattened DT fragment with the phandles > already resolved. Um..? Sorry, I can't parse that paragraph. > So the sequence could be something like this: > > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} > > The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. > > Alternatively we could have a way to statically assign a phandle range > for well known capes. All the others will have to use the runtime compile > mechanism. > $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts > $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts > $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts > > With the cape dtses having a /phandle-range/ statement at the top. > > This can work because the cape dts do not cross-reference each other, and > neither the boot dts references the capes. > > That way we can use request_firmware() pretty early in the boot sequence > and get the DT fragment we need even before user-space starts and root fs > has mounted. request_firmware() can locate the fragments in the kernel > image before rootfs. > > I don't know if this will cover all the cases Grant has in mind though. > > So just to make sure I got it right, this could work for our case. > > i2c2: i2c@4819c000 { > compatible = "ti,omap4-i2c"; > #address-cells = <1>; > #size-cells = <0>; > ti,hwmods = "i2c3"; > reg = <0x4819c000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <30>; > status = "disabled"; > }; > > And in the cape definition (when compiled with the special mode I describe > below) > > / { > plugin-bundle; > compatible = "cco,weather-cape"; > version = <00A0>; > > i2c2-graft = { > compatible = <dt,graft>; > graft-point = <&i2c2>; > > #address-cells = <1>; > #size-cells = <0>; > > /* Ambient light sensor */ > tsl2550@39 { > compatible = "tsl,tsl2550"; > reg = <0x39>; > }; > }; > }; > > DTC when compiling in the special fragment mode will pick up that > &i2c2 can not be resolved and lookup the phandle on the main dtb. > That way, even 'phandle,symbolic-name = "i2c2";' is redundant. Well, no, because I'm assuming dtc fragment mode only has access to the base dtb, not the base dts, so labels will be gone from it, unless we add properties to preserve them especially. That's what the symbolic-name thing is about. > > 3) The resulting partial .dtb for the module is highly specific to the > > base tree (which if the base tree was generated at runtime by firmware > > could even be specific to a particular boot). But that's ok, because > > we just spit it into the kernel, absolute phandle values and all, then > > throw it away. Next time we need the module info, we recompile it > > again. > > > >> Of course, relying on .dts compatibility rather than .dtb compatibility > >> might negatively impact the complexity of an initrd environment if we > >> end up loading overlays from there... > > > > Well, it does mean we'd need dtc in the initrd. But dtc has no > > library dependencies except libc, so that really shouldn't be too > > bad. In return we entirely avoid inventing a new phandle resolution > > protocol. > > Not every board boots with initrd; most embedded boards don't use it > at all. This way we make initrd a hard requirement. Well, not really. You can use initramfs, or you can assemble all the necessary dt fragents for boot into a complete dtb included with the kernel. Doing that involves pretty much the same sorts of things you need to do to statically configure a kernel for boot without initramfs. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 23:30 ` David Gibson (?) @ 2012-11-14 0:00 ` Pantelis Antoniou -1 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-14 0:00 UTC (permalink / raw) To: David Gibson Cc: Grant Likely, Stephen Warren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss [-- Attachment #1: Type: text/plain, Size: 8545 bytes --] Hi David, Since this is getting to be too long-winded I went ahead a coded something quick and dirty. On Nov 14, 2012, at 1:30 AM, David Gibson wrote: > On Tue, Nov 13, 2012 at 10:09:28AM +0200, Pantelis Antoniou wrote: >> Hi David, >> >> On Nov 13, 2012, at 9:25 AM, David Gibson wrote: >> >>> On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >>>> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: >>> [snip] >>>>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>>>> and beaglebone, for the cape to work for both, it is required for it's >>>>> dtb to be compatible. >>>> >>>> Well, as Grant pointed out, it's not actually strictly necessary for the >>>> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >>>> can be generated at run-time using dtc for example. >>> >>> So, actually, I think a whole bunch of problems with phandle >>> resolution disappear if we don't try to define an overlay .dtb format, >>> or at least treat it only as a very shortlived object. A more precise >>> proposal below. Note that this works more or less equally well with >>> either the original overlay approach or the graft/graft-bundle >>> proposal I made elsewhere. >>> >>> 1) We annotate the base tree with some extra label information for >>> nodes which overlays are likely to want to reference by phandle. e.g. >>> >>> beaglebone_pic: interrupt-controller@XXXXX { >>> ... >>> phandle,symbolic-name = "beaglebone_pic"; >>> }; >>> >>> We could extend dtc to (optionally?) auto-generate those properties >>> from its existing label syntax. Not sure if that's a good idea or >>> not yet. In any case, we compile this augmented base tree to .dtb as >>> normal and boot our kernel with it. >>> >> >> I'm fine with that. You can auto-generate when there's a label to a node. >> The cape dt fragment will use the label name to reference a node. >> More details below... >> >>> 2) The information for the capes/modules/whatever is >>> distributed/packaged as .dts, never .dtb. When userspace detects the >>> new module (or the user explicitly tells it, if it's not probeable) it >>> picks up the correct dts and runs it through dtc in a special mode. >>> In this mode dtc takes the existing base tree (from /proc/device-tree, >>> say) as well as the new dts. In this mode, dtc allocates phandles for >>> the new tree fragment so as not to collide with anything from the >>> supplied base tree (as well as avoiding internal conflicts, >>> obviously). It also allows node references to the base tree by using >>> those label annotations from (1) to match symbolic names to the >>> phandle values in the base tree. >>> >> >> Not good to rely on userspace kicking off dtc and compiling from source. >> Some capes/expansion boards might have your root fs device, for example >> there is an eMMC cape coming up, while networking capes are common too. > > So? dtc can go in an initramfs, just like mdadm or whatever other > tools are there. > Embedded systems aren't servers. Having an initramfs is one more thing that can break, or require people to modify their build systems. >> However I have a compromise. >> >> I agree that compiling from source can be an option for a runtime definable >> cape, but for built-in capes we could do a bit better. >> >> In particular, I don't see any particular need to have a DT fragment >> reference anything that dependent of the runtime device tree. It should >> be possible to compile the DT fragment in kernel, against the generated >> flattened device tree, producing a flattened DT fragment with the phandles >> already resolved. > > Um..? Sorry, I can't parse that paragraph. > No need for runtime resolution for common use cases. >> So the sequence could be something like this: >> >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} >> >> The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. >> >> Alternatively we could have a way to statically assign a phandle range >> for well known capes. All the others will have to use the runtime compile >> mechanism. >> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts >> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts >> >> With the cape dtses having a /phandle-range/ statement at the top. >> >> This can work because the cape dts do not cross-reference each other, and >> neither the boot dts references the capes. >> >> That way we can use request_firmware() pretty early in the boot sequence >> and get the DT fragment we need even before user-space starts and root fs >> has mounted. request_firmware() can locate the fragments in the kernel >> image before rootfs. >> >> I don't know if this will cover all the cases Grant has in mind though. >> >> So just to make sure I got it right, this could work for our case. >> >> i2c2: i2c@4819c000 { >> compatible = "ti,omap4-i2c"; >> #address-cells = <1>; >> #size-cells = <0>; >> ti,hwmods = "i2c3"; >> reg = <0x4819c000 0x1000>; >> interrupt-parent = <&intc>; >> interrupts = <30>; >> status = "disabled"; >> }; >> >> And in the cape definition (when compiled with the special mode I describe >> below) >> >> / { >> plugin-bundle; >> compatible = "cco,weather-cape"; >> version = <00A0>; >> >> i2c2-graft = { >> compatible = <dt,graft>; >> graft-point = <&i2c2>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> /* Ambient light sensor */ >> tsl2550@39 { >> compatible = "tsl,tsl2550"; >> reg = <0x39>; >> }; >> }; >> }; >> >> DTC when compiling in the special fragment mode will pick up that >> &i2c2 can not be resolved and lookup the phandle on the main dtb. >> That way, even 'phandle,symbolic-name = "i2c2";' is redundant. > > Well, no, because I'm assuming dtc fragment mode only has access to > the base dtb, not the base dts, so labels will be gone from it, unless > we add properties to preserve them especially. That's what the > symbolic-name thing is about. > They can be easily included, as the patch shows. >>> 3) The resulting partial .dtb for the module is highly specific to the >>> base tree (which if the base tree was generated at runtime by firmware >>> could even be specific to a particular boot). But that's ok, because >>> we just spit it into the kernel, absolute phandle values and all, then >>> throw it away. Next time we need the module info, we recompile it >>> again. >>> >>>> Of course, relying on .dts compatibility rather than .dtb compatibility >>>> might negatively impact the complexity of an initrd environment if we >>>> end up loading overlays from there... >>> >>> Well, it does mean we'd need dtc in the initrd. But dtc has no >>> library dependencies except libc, so that really shouldn't be too >>> bad. In return we entirely avoid inventing a new phandle resolution >>> protocol. >> >> Not every board boots with initrd; most embedded boards don't use it >> at all. This way we make initrd a hard requirement. > > Well, not really. You can use initramfs, or you can assemble all the > necessary dt fragents for boot into a complete dtb included with the > kernel. Doing that involves pretty much the same sorts of things you > need to do to statically configure a kernel for boot without > initramfs. > You can't assemble the dtb without runtime probing of what's out there. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Anyway, here's a small patch that shows that it is possible to do both fixups and symbol tracking using relatively unmodified DT syntax. The only thing new is the /plugin/; statement. Also included two dumps of generated dtbs as well as the plugin dts. Should be relatively simple to come up with a kernel loader and linker using something similar like this. Regards -- Pantelis [-- Attachment #2: dtc-symbols-fixups-test.patch --] [-- Type: application/octet-stream, Size: 8758 bytes --] commit 874ee3c0dceaf2735ebb82b4ad117108b6d2125b Author: Pantelis Antoniou <panto@antoniou-consulting.com> Date: Wed Nov 14 23:40:59 2012 +0200 Implement fixups and symbols Introduce symbols and a fixup nodes in the root tree. diff --git a/checks.c b/checks.c index ee96a25..b1b87ed 100644 --- a/checks.c +++ b/checks.c @@ -459,20 +459,73 @@ static void fixup_phandle_references(struct check *c, struct node *dt, struct marker *m = prop->val.markers; struct node *refnode; cell_t phandle; + int has_phandle_refs; + + has_phandle_refs = 0; + for_each_marker_of_type(m, REF_PHANDLE) { + has_phandle_refs = 1; + break; + } + + if (!has_phandle_refs) + return; for_each_marker_of_type(m, REF_PHANDLE) { assert(m->offset + sizeof(cell_t) <= prop->val.len); refnode = get_node_by_ref(dt, m->ref); - if (! refnode) { + if (! refnode && !dt->is_plugin) { FAIL(c, "Reference to non-existent node or label \"%s\"\n", - m->ref); + m->ref); continue; } - phandle = get_node_phandle(dt, refnode); + if (! refnode) { + struct fixup *f, **fp; + struct fixup_entry *fe, **fep; + + /* allocate fixup entry */ + fe = xmalloc(sizeof(*fe)); + + fe->node = node; + fe->prop = prop; + fe->offset = m->offset; + fe->next = NULL; + + /* search for an already existing fixup */ + for_each_fixup(dt, f) + if (strcmp(f->ref, m->ref) == 0) + break; + + /* no fixup found, add new */ + if (f == NULL) { + f = xmalloc(sizeof(*f)); + f->ref = m->ref; + f->entries = NULL; + f->next = NULL; + + /* add it to the tree */ + fp = &dt->fixups; + while (*fp) + fp = &((*fp)->next); + *fp = f; + } + + /* and now append fixup entry */ + fep = &f->entries; + while (*fep) + fep = &((*fep)->next); + *fep = fe; + + /* mark the entry as unresolved */ + phandle = 0xdeadbeef; + } else { + phandle = get_node_phandle(dt, refnode); + } + *((cell_t *)(prop->val.val + m->offset)) = cpu_to_fdt32(phandle); } + } ERROR(phandle_references, NULL, NULL, fixup_phandle_references, NULL, &duplicate_node_names, &explicit_phandles); @@ -651,6 +704,42 @@ static void check_obsolete_chosen_interrupt_controller(struct check *c, } TREE_WARNING(obsolete_chosen_interrupt_controller, NULL); +static void check_auto_label_phandles(struct check *c, struct node *dt, + struct node *node) +{ + struct label *l; + struct symbol *s, **sp; + int has_label; + + has_label = 0; + for_each_label(node->labels, l) { + has_label = 1; + break; + } + + if (!has_label) + return; + + /* force allocation of a phandle for this node */ + (void)get_node_phandle(dt, node); + + /* add the symbol */ + for_each_label(node->labels, l) { + + s = xmalloc(sizeof(*s)); + s->label = l; + s->node = node; + s->next = NULL; + + /* add it to the symbols list */ + sp = &dt->symbols; + while (*sp) + sp = &((*sp)->next); + *sp = s; + } +} +NODE_WARNING(auto_label_phandles, NULL); + static struct check *check_table[] = { &duplicate_node_names, &duplicate_property_names, &node_name_chars, &node_name_format, &property_name_chars, @@ -669,6 +758,8 @@ static struct check *check_table[] = { &avoid_default_addr_size, &obsolete_chosen_interrupt_controller, + &auto_label_phandles, + &always_fail, }; diff --git a/dtc-lexer.l b/dtc-lexer.l index 254d5af..2cef406 100644 --- a/dtc-lexer.l +++ b/dtc-lexer.l @@ -112,6 +112,11 @@ static int pop_input_file(void); return DT_V1; } +<*>"/plugin/" { + DPRINT("Keyword: /plugin/\n"); + return DT_PLUGIN; + } + <*>"/memreserve/" { DPRINT("Keyword: /memreserve/\n"); BEGIN_DEFAULT(); diff --git a/dtc-parser.y b/dtc-parser.y index f412460..e444acf 100644 --- a/dtc-parser.y +++ b/dtc-parser.y @@ -20,6 +20,7 @@ %{ #include <stdio.h> +#include <inttypes.h> #include "dtc.h" #include "srcpos.h" @@ -56,9 +57,11 @@ static unsigned char eval_char_literal(const char *s); struct node *nodelist; struct reserve_info *re; uint64_t integer; + int is_plugin; } %token DT_V1 +%token DT_PLUGIN %token DT_MEMRESERVE %token DT_LSHIFT DT_RSHIFT DT_LE DT_GE DT_EQ DT_NE DT_AND DT_OR %token DT_BITS @@ -76,6 +79,7 @@ static unsigned char eval_char_literal(const char *s); %type <data> propdata %type <data> propdataprefix +%type <is_plugin> plugindecl %type <re> memreserve %type <re> memreserves %type <array> arrayprefix @@ -106,10 +110,23 @@ static unsigned char eval_char_literal(const char *s); %% sourcefile: - DT_V1 ';' memreserves devicetree + DT_V1 ';' plugindecl memreserves devicetree { - the_boot_info = build_boot_info($3, $4, - guess_boot_cpuid($4)); + $5->is_plugin = $3; + $5->is_root = 1; + the_boot_info = build_boot_info($4, $5, + guess_boot_cpuid($5)); + } + ; + +plugindecl: + /* empty */ + { + $$ = 0; + } + | DT_PLUGIN ';' + { + $$ = 1; } ; diff --git a/dtc.h b/dtc.h index 3e42a07..2659142 100644 --- a/dtc.h +++ b/dtc.h @@ -133,6 +133,25 @@ struct label { struct label *next; }; +struct fixup_entry { + int offset; + struct node *node; + struct property *prop; + struct fixup_entry *next; +}; + +struct fixup { + char *ref; + struct fixup_entry *entries; + struct fixup *next; +}; + +struct symbol { + struct label *label; + struct node *node; + struct symbol *next; +}; + struct property { int deleted; char *name; @@ -159,6 +178,11 @@ struct node { int addr_cells, size_cells; struct label *labels; + + int is_root; + int is_plugin; + struct fixup *fixups; + struct symbol *symbols; }; #define for_each_label_withdel(l0, l) \ @@ -182,6 +206,15 @@ struct node { for_each_child_withdel(n, c) \ if (!(c)->deleted) +#define for_each_fixup(n, f) \ + for ((f) = (n)->fixups; (f); (f) = (f)->next) + +#define for_each_fixup_entry(f, fe) \ + for ((fe) = (f)->entries; (fe); (fe) = (fe)->next) + +#define for_each_symbol(n, s) \ + for ((s) = (n)->symbols; (s); (s) = (s)->next) + void add_label(struct label **labels, char *label); void delete_labels(struct label **labels); diff --git a/fdtdump.c b/fdtdump.c index 207a46d..d4fa6d7 100644 --- a/fdtdump.c +++ b/fdtdump.c @@ -21,13 +21,23 @@ static void print_data(const char *data, int len) { int i; const char *p = data; + const char *s; /* no data, don't print */ if (len == 0) return; if (util_is_printable_string(data, len)) { - printf(" = \"%s\"", (const char *)data); + printf(" = "); + + s = data; + do { + printf("\"%s\"", s); + s += strlen(s) + 1; + if (s < data + len) + printf(", "); + } while (s < data + len); + } else if ((len % 4) == 0) { printf(" = <"); for (i = 0; i < len; i += 4) diff --git a/flattree.c b/flattree.c index 665dad7..f250672 100644 --- a/flattree.c +++ b/flattree.c @@ -310,6 +310,81 @@ static void flatten_tree(struct node *tree, struct emitter *emit, flatten_tree(child, emit, etarget, strbuf, vi); } + /* add the symbol nodes */ + if (tree->is_root) { + struct symbol *s; + int nameoff, vallen; + + emit->beginnode(etarget, NULL); + emit->string(etarget, "@symbols@", 0); + emit->align(etarget, sizeof(cell_t)); + + for_each_symbol(tree, s) { + + vallen = strlen(s->node->fullpath); + + nameoff = stringtable_insert(strbuf, s->label->label); + + emit->property(etarget, NULL); + emit->cell(etarget, vallen + 1); + emit->cell(etarget, nameoff); + + if ((vi->flags & FTF_VARALIGN) && vallen >= 8) + emit->align(etarget, 8); + + emit->string(etarget, s->node->fullpath, strlen(s->node->fullpath)); + emit->align(etarget, sizeof(cell_t)); + } + + emit->endnode(etarget, NULL); + } + + /* add the fixup nodes */ + if (tree->is_root && tree->is_plugin) { + struct fixup *f; + struct fixup_entry *fe; + char *name, *s; + int namesz, nameoff, vallen; + + emit->beginnode(etarget, NULL); + emit->string(etarget, "@fixups@", 0); + emit->align(etarget, sizeof(cell_t)); + + for_each_fixup(tree, f) { + + namesz = 0; + for_each_fixup_entry(f, fe) + namesz += strlen(fe->node->fullpath) + 1 + + strlen(fe->prop->name) + 1 + 32; + + name = xmalloc(namesz); + + s = name; + for_each_fixup_entry(f, fe) { + snprintf(s, name + namesz - s, "%s:%s:%d", + fe->node->fullpath, fe->prop->name, fe->offset); + s += strlen(s) + 1; + } + + nameoff = stringtable_insert(strbuf, f->ref); + vallen = s - name; + + emit->property(etarget, NULL); + emit->cell(etarget, vallen); + emit->cell(etarget, nameoff); + + if ((vi->flags & FTF_VARALIGN) && vallen >= 8) + emit->align(etarget, 8); + + emit->string(etarget, name, vallen); + emit->align(etarget, sizeof(cell_t)); + + free(name); + } + + emit->endnode(etarget, tree->labels); + } + emit->endnode(etarget, tree->labels); } [-- Attachment #3: geiger-cape.fdtdump --] [-- Type: application/octet-stream, Size: 1914 bytes --] /dts-v1/; // magic: 0xd00dfeed // totalsize: 0x577 (1399) // off_dt_struct: 0x38 // off_dt_strings: 0x440 // off_mem_rsvmap: 0x28 // version: 17 // last_comp_version: 16 // boot_cpuid_phys: 0x0 // size_dt_strings: 0x137 // size_dt_struct: 0x408 / { compatible = "bone-geiger-cape"; board-name = "Geiger Cape"; version = "00A0", "00A1", "00A2"; pinctrl-names = "default"; pinctrl-0 = <0xdeadbeef>; pwms = <0xdeadbeef 0x00000000 0x0007a120 0x00000000>; pwm-names = "bone-geiger-cape"; pwm-frequency = <0x00004e20>; pwm-duty-cycle = <0x0000003c>; event-blink-delay = <0x0000001e>; gpios = <0xdeadbeef 0x00000011 0x00000000>; vsense-name = "AIN5"; vsense-scale = <0x000091cd>; tscadc { compatible = "ti-tscadc-dt"; ti,hwmods = "adc_tsc"; adc-channels = <0x00000008>; linux,phandle = <0x00000001>; phandle = <0x00000001>; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0xdeadbeef>; linux,phandle = <0x00000002>; phandle = <0x00000002>; geiger-led0 { label = "geiger:green:usr0"; gpios = <0xdeadbeef 0x00000017 0x00000000>; linux,default-trigger = "geiger-run"; default-state = "off"; }; geiger-led1 { label = "geiger:red:usr1"; gpios = <0xdeadbeef 0x00000019 0x00000000>; linux,default-trigger = "geiger-event"; default-state = "off"; }; }; @fixups@ { bone_geiger_cape_pins = "/:pinctrl-0:0"; ehrpwm1 = "/:pwms:0"; gpio4 = "/:gpios:0"; bone_geiger_cape_led_pins = "/gpio-leds:pinctrl-0:0"; gpio3 = "/gpio-leds/geiger-led0:gpios:0", "/gpio-leds/geiger-led1:gpios:0"; }; @symbols@ { tscadc = "/tscadc"; gpioleds1 = "/gpio-leds"; }; }; [-- Attachment #4: geiger-cape.dts --] [-- Type: application/octet-stream, Size: 1342 bytes --] /* * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ /dts-v1/; /plugin/; / { compatible = "bone-geiger-cape"; board-name = "Geiger Cape"; version = "00A0", "00A1", "00A2"; /* note that these can't be versioned... */ pinctrl-names = "default"; pinctrl-0 = <&bone_geiger_cape_pins>; pwms = <&ehrpwm1 0 500000 0>; pwm-names = "bone-geiger-cape"; pwm-frequency = <20000>; /* 20KHz */ pwm-duty-cycle = <60>; /* 60% */ event-blink-delay = <30>; /* 30ms */ gpios = <&gpio4 17 0>; /* pulse */ vsense-name = "AIN5"; /* analog vsense */ vsense-scale = <37325>; /* scaling */ tscadc: tscadc { compatible = "ti-tscadc-dt"; ti,hwmods = "adc_tsc"; adc-channels = <8>; }; gpioleds1: gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&bone_geiger_cape_led_pins>; geiger-led0 { label = "geiger:green:usr0"; gpios = <&gpio3 23 0>; linux,default-trigger = "geiger-run"; default-state = "off"; }; geiger-led1 { label = "geiger:red:usr1"; gpios = <&gpio3 25 0>; linux,default-trigger = "geiger-event"; default-state = "off"; }; }; }; [-- Attachment #5: am335x-bone.fdtdump --] [-- Type: application/octet-stream, Size: 46791 bytes --] /dts-v1/; // magic: 0xd00dfeed // totalsize: 0x5de6 (24038) // off_dt_struct: 0x38 // off_dt_strings: 0x546c // off_mem_rsvmap: 0x28 // version: 17 // last_comp_version: 16 // boot_cpuid_phys: 0x0 // size_dt_strings: 0x97a // size_dt_struct: 0x5434 / { #address-cells = <0x00000001>; #size-cells = <0x00000001>; compatible = "ti,am335x-bone", "ti,am33xx"; model = "TI AM335x BeagleBone"; chosen { }; aliases { serial0 = "/ocp/serial@44e09000"; serial1 = "/ocp/serial@48022000"; serial2 = "/ocp/serial@48024000"; serial3 = "/ocp/serial@481a6000"; serial4 = "/ocp/serial@481a8000"; serial5 = "/ocp/serial@481aa000"; }; memory { device_type = "memory"; reg = <0x80000000 0x10000000>; }; cpus { cpu@0 { compatible = "arm,cortex-a8"; operating-points = <0x000afc80 0x00139b88 0x000927c0 0x0012b128 0x0007a120 0x00112a88 0x00043238 0x00112a88>; voltage-tolerance = <0x00000002>; clock-latency = <0x000493e0>; cpu0-supply = <0x00000001>; }; }; soc { compatible = "ti,omap-infra"; mpu { compatible = "ti,omap3-mpu"; ti,hwmods = "mpu"; }; }; pinmux@44e10800 { compatible = "pinctrl-single"; reg = <0x44e10800 0x00000238>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; pinctrl-single,register-width = <0x00000020>; pinctrl-single,function-mask = <0x0000007f>; linux,phandle = <0x00000022>; phandle = <0x00000022>; pinmux_spi1_pins { pinctrl-single,pins = <0x00000190 0x00000013 0x00000194 0x00000033 0x00000198 0x00000013 0x0000019c 0x00000013>; linux,phandle = <0x00000008>; phandle = <0x00000008>; }; pinmux_lcd_pins { pinctrl-single,pins = <0x000001a4 0x00000017 0x000001ac 0x00000017>; linux,phandle = <0x00000021>; phandle = <0x00000021>; }; pinmux_gpevt_pins { pinctrl-single,pins = <0x00000090 0x00000037>; linux,phandle = <0x0000000b>; phandle = <0x0000000b>; }; pinmux_userled_pins { pinctrl-single,pins = <0x00000054 0x00000007 0x00000058 0x00000017 0x0000005c 0x00000007 0x00000060 0x00000017>; linux,phandle = <0x00000009>; phandle = <0x00000009>; }; pinmux_i2c2_pins { pinctrl-single,pins = <0x00000178 0x00000073 0x0000017c 0x00000073>; linux,phandle = <0x00000003>; phandle = <0x00000003>; }; pinmux_bone_dvi_cape_led_pins { pinctrl-single,pins = <0x00000048 0x00000007 0x0000004c 0x00000007>; linux,phandle = <0x00000013>; phandle = <0x00000013>; }; pinmux_bone_dvi_cape_dvi_00A0_pins { pinctrl-single,pins = <0x0000001c 0x00000007 0x000000a0 0x00000008 0x000000a4 0x00000008 0x000000a8 0x00000008 0x000000ac 0x00000008 0x000000b0 0x00000008 0x000000b4 0x00000008 0x000000b8 0x00000008 0x000000bc 0x00000008 0x000000c0 0x00000008 0x000000c4 0x00000008 0x000000c8 0x00000008 0x000000cc 0x00000008 0x000000d0 0x00000008 0x000000d4 0x00000008 0x000000d8 0x00000008 0x000000dc 0x00000008 0x000000e0 0x00000000 0x000000e4 0x00000000 0x000000e8 0x00000000 0x000000ec 0x00000000>; linux,phandle = <0x00000011>; phandle = <0x00000011>; }; pinmux_bone_dvi_cape_dvi_00A1_pins { pinctrl-single,pins = <0x00000084 0x00000007 0x000000a0 0x00000008 0x000000a4 0x00000008 0x000000a8 0x00000008 0x000000ac 0x00000008 0x000000b0 0x00000008 0x000000b4 0x00000008 0x000000b8 0x00000008 0x000000bc 0x00000008 0x000000c0 0x00000008 0x000000c4 0x00000008 0x000000c8 0x00000008 0x000000cc 0x00000008 0x000000d0 0x00000008 0x000000d4 0x00000008 0x000000d8 0x00000008 0x000000dc 0x00000008 0x000000e0 0x00000000 0x000000e4 0x00000000 0x000000e8 0x00000000 0x000000ec 0x00000000>; linux,phandle = <0x00000012>; phandle = <0x00000012>; }; pinmux_bone_geiger_cape_led_pins { pinctrl-single,pins = <0x000000e4 0x00000007 0x000000ec 0x00000007>; linux,phandle = <0x00000017>; phandle = <0x00000017>; }; pinmux_bone_geiger_cape_pins { pinctrl-single,pins = <0x00000048 0x00000006 0x0000019c 0x00000037>; linux,phandle = <0x00000014>; phandle = <0x00000014>; }; pinmux_bone_lcd3_cape_led_00A0_pins { pinctrl-single,pins = <0x00000048 0x00000007 0x0000004c 0x00000007>; linux,phandle = <0x0000001a>; phandle = <0x0000001a>; }; pinmux_bone_lcd3_cape_lcd_pins { pinctrl-single,pins = <0x000000a0 0x00000008 0x000000a4 0x00000008 0x000000a8 0x00000008 0x000000ac 0x00000008 0x000000b0 0x00000008 0x000000b4 0x00000008 0x000000b8 0x00000008 0x000000bc 0x00000008 0x000000c0 0x00000008 0x000000c4 0x00000008 0x000000c8 0x00000008 0x000000cc 0x00000008 0x000000d0 0x00000008 0x000000d4 0x00000008 0x000000d8 0x00000008 0x000000dc 0x00000008 0x000000e0 0x00000000 0x000000e4 0x00000000 0x000000e8 0x00000000 0x000000ec 0x00000000>; linux,phandle = <0x00000018>; phandle = <0x00000018>; }; pinmux_bone_lcd3_cape_keys_00A0_pins { pinctrl-single,pins = <0x00000040 0x0000002f 0x00000044 0x0000002f 0x000001a4 0x0000002f 0x00000078 0x0000002f 0x00000164 0x0000002f>; linux,phandle = <0x0000001b>; phandle = <0x0000001b>; }; pinmux_pwm_bl_pins { pinctrl-single,pins = <0x0000004c 0x00000006>; linux,phandle = <0x0000001f>; phandle = <0x0000001f>; }; pinmux_weather_cape_w1_pins { pinctrl-single,pins = <0x0000000c 0x00000037>; linux,phandle = <0x0000001e>; phandle = <0x0000001e>; }; }; ocp { compatible = "simple-bus"; #address-cells = <0x00000001>; #size-cells = <0x00000001>; ranges; ti,hwmods = "l3_main"; interrupt-controller@48200000 { compatible = "ti,omap2-intc"; interrupt-controller; #interrupt-cells = <0x00000001>; ti,intc-size = <0x00000080>; reg = <0x48200000 0x00001000>; linux,phandle = <0x00000002>; phandle = <0x00000002>; }; edma@49000000 { compatible = "ti,edma3"; ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; reg = <0x49000000 0x00010000 0x44e10f90 0x00000010>; interrupt-parent = <0x00000002>; interrupts = <0x0000000c 0x0000000d 0x0000000e>; #dma-cells = <0x00000001>; dma-channels = <0x00000040>; ti,edma-regions = <0x00000004>; ti,edma-slots = <0x00000100>; ti,edma-reserved-channels = <0x00000000 0x00000002 0x0000000e 0x00000002 0x0000001a 0x00000006 0x00000030 0x00000004 0x00000038 0x00000008>; ti,edma-reserved-slots = <0x00000000 0x00000002 0x0000000e 0x00000002 0x0000001a 0x00000006 0x00000030 0x00000004 0x00000038 0x00000008 0x00000040 0x0000007f>; ti,edma-queue-tc-map = <0x00000000 0x00000000 0x00000001 0x00000001 0x00000002 0x00000002>; ti,edma-queue-priority-map = <0x00000000 0x00000000 0x00000001 0x00000001 0x00000002 0x00000002>; ti,edma-default-queue = <0x00000000>; ti,edma-xbar-event-map = <0x00000020 0x0000000c>; linux,phandle = <0x00000004>; phandle = <0x00000004>; }; gpio@44e07000 { compatible = "ti,omap4-gpio"; ti,hwmods = "gpio1"; gpio-controller; #gpio-cells = <0x00000002>; interrupt-controller; #interrupt-cells = <0x00000001>; reg = <0x44e07000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x00000060>; linux,phandle = <0x0000001c>; phandle = <0x0000001c>; }; gpio@4804c000 { compatible = "ti,omap4-gpio"; ti,hwmods = "gpio2"; gpio-controller; #gpio-cells = <0x00000002>; interrupt-controller; #interrupt-cells = <0x00000001>; reg = <0x4804c000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x00000062>; linux,phandle = <0x0000000a>; phandle = <0x0000000a>; }; gpio@481ac000 { compatible = "ti,omap4-gpio"; ti,hwmods = "gpio3"; gpio-controller; #gpio-cells = <0x00000002>; interrupt-controller; #interrupt-cells = <0x00000001>; reg = <0x481ac000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x00000020>; linux,phandle = <0x0000000c>; phandle = <0x0000000c>; }; gpio@481ae000 { compatible = "ti,omap4-gpio"; ti,hwmods = "gpio4"; gpio-controller; #gpio-cells = <0x00000002>; interrupt-controller; #interrupt-cells = <0x00000001>; reg = <0x481ae000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x0000003e>; linux,phandle = <0x00000016>; phandle = <0x00000016>; }; serial@44e09000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart1"; clock-frequency = <0x02dc6c00>; reg = <0x44e09000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x00000048>; status = "okay"; linux,phandle = <0x00000023>; phandle = <0x00000023>; }; serial@48022000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart2"; clock-frequency = <0x02dc6c00>; reg = <0x48022000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x00000049>; status = "disabled"; linux,phandle = <0x00000024>; phandle = <0x00000024>; }; serial@48024000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart3"; clock-frequency = <0x02dc6c00>; reg = <0x48024000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x0000004a>; status = "disabled"; linux,phandle = <0x00000025>; phandle = <0x00000025>; }; serial@481a6000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart4"; clock-frequency = <0x02dc6c00>; reg = <0x481a6000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x0000002c>; status = "disabled"; linux,phandle = <0x00000026>; phandle = <0x00000026>; }; serial@481a8000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart5"; clock-frequency = <0x02dc6c00>; reg = <0x481a8000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x0000002d>; status = "disabled"; linux,phandle = <0x00000027>; phandle = <0x00000027>; }; serial@481aa000 { compatible = "ti,omap3-uart"; ti,hwmods = "uart6"; clock-frequency = <0x02dc6c00>; reg = <0x481aa000 0x00002000>; interrupt-parent = <0x00000002>; interrupts = <0x0000002e>; status = "disabled"; linux,phandle = <0x00000028>; phandle = <0x00000028>; }; i2c@44e0b000 { compatible = "ti,omap4-i2c"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; ti,hwmods = "i2c1"; reg = <0x44e0b000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x00000046>; status = "okay"; clock-frequency = <0x00061a80>; linux,phandle = <0x00000029>; phandle = <0x00000029>; tps@24 { reg = <0x00000024>; compatible = "ti,tps65217"; linux,phandle = <0x00000019>; phandle = <0x00000019>; regulators { #address-cells = <0x00000001>; #size-cells = <0x00000000>; regulator@0 { reg = <0x00000000>; regulator-compatible = "dcdc1"; regulator-always-on; linux,phandle = <0x0000002a>; phandle = <0x0000002a>; }; regulator@1 { reg = <0x00000001>; regulator-compatible = "dcdc2"; regulator-name = "vdd_mpu"; regulator-min-microvolt = <0x000e1d48>; regulator-max-microvolt = <0x001437c8>; regulator-boot-on; regulator-always-on; linux,phandle = <0x00000001>; phandle = <0x00000001>; }; regulator@2 { reg = <0x00000002>; regulator-compatible = "dcdc3"; regulator-name = "vdd_core"; regulator-min-microvolt = <0x000e1d48>; regulator-max-microvolt = <0x00118c30>; regulator-boot-on; regulator-always-on; linux,phandle = <0x0000002b>; phandle = <0x0000002b>; }; regulator@3 { reg = <0x00000003>; regulator-compatible = "ldo1"; regulator-always-on; linux,phandle = <0x0000002c>; phandle = <0x0000002c>; }; regulator@4 { reg = <0x00000004>; regulator-compatible = "ldo2"; regulator-always-on; linux,phandle = <0x0000002d>; phandle = <0x0000002d>; }; regulator@5 { reg = <0x00000005>; regulator-compatible = "ldo3"; regulator-min-microvolt = <0x001b7740>; regulator-max-microvolt = <0x00325aa0>; regulator-always-on; linux,phandle = <0x00000005>; phandle = <0x00000005>; }; regulator@6 { reg = <0x00000006>; regulator-compatible = "ldo4"; regulator-always-on; linux,phandle = <0x0000002e>; phandle = <0x0000002e>; }; }; }; baseboard_eeprom@50 { compatible = "at,24c256"; reg = <0x00000050>; linux,phandle = <0x0000002f>; phandle = <0x0000002f>; }; }; i2c@4802a000 { compatible = "ti,omap4-i2c"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; ti,hwmods = "i2c2"; reg = <0x4802a000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x00000047>; status = "disabled"; linux,phandle = <0x00000030>; phandle = <0x00000030>; }; i2c@4819c000 { compatible = "ti,omap4-i2c"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; ti,hwmods = "i2c3"; reg = <0x4819c000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x0000001e>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x00000003>; clock-frequency = <0x000186a0>; linux,phandle = <0x0000001d>; phandle = <0x0000001d>; cape_eeprom_0@54 { compatible = "at,24c256"; reg = <0x00000054>; linux,phandle = <0x0000000d>; phandle = <0x0000000d>; }; cape_eeprom_1@55 { compatible = "at,24c256"; reg = <0x00000055>; linux,phandle = <0x0000000e>; phandle = <0x0000000e>; }; cape_eeprom_2@56 { compatible = "at,24c256"; reg = <0x00000056>; linux,phandle = <0x0000000f>; phandle = <0x0000000f>; }; cape_eeprom_3@57 { compatible = "at,24c256"; reg = <0x00000057>; linux,phandle = <0x00000010>; phandle = <0x00000010>; }; }; mmc@48060000 { compatible = "ti,omap3-hsmmc"; ti,hwmods = "mmc1"; ti,dual-volt; ti,needs-special-reset; ti,needs-special-hs-handling; dmas = <0x00000004 0x00000018 0x00000004 0x00000019>; dma-names = "tx", "rx"; vmmc-supply = <0x00000005>; linux,phandle = <0x00000031>; phandle = <0x00000031>; }; mmc@481d8000 { compatible = "ti,omap3-hsmmc"; ti,hwmods = "mmc2"; ti,needs-special-reset; ti,needs-special-hs-handling; dmas = <0x00000004 0x00000002 0x00000004 0x00000003>; dma-names = "tx", "rx"; status = "disabled"; vmmc-supply = <0x00000005>; bus-width = <0x00000004>; ti,non-removable; linux,phandle = <0x00000032>; phandle = <0x00000032>; }; mmc@47810000 { compatible = "ti,omap3-hsmmc"; ti,hwmods = "mmc3"; ti,needs-special-reset; ti,needs-special-hs-handling; status = "disabled"; linux,phandle = <0x00000033>; phandle = <0x00000033>; }; phy0 { compatible = "nop-xceiv-usb"; linux,phandle = <0x00000006>; phandle = <0x00000006>; }; phy1 { compatible = "nop-xceiv-usb"; linux,phandle = <0x00000007>; phandle = <0x00000007>; }; usb_otg_hs { compatible = "ti,musb-am33xx"; ti,hwmods = "usb_otg_hs"; multipoint = <0x00000001>; num-eps = <0x00000010>; ram-bits = <0x0000000c>; port0-mode = <0x00000003>; port1-mode = <0x00000001>; power = <0x000000fa>; usb0-phy = <0x00000006>; usb1-phy = <0x00000007>; linux,phandle = <0x00000034>; phandle = <0x00000034>; }; rtc { compatible = "ti,da830-rtc"; ti,hwmods = "rtc"; }; spi@48030000 { compatible = "ti,omap4-mcspi"; ti,hwmods = "spi0"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; reg = <0x48030000 0x00000400>; interrupt-parent = <0x00000002>; interrupt = <0x00000041>; dmas = <0x00000004 0x00000010 0x00000004 0x00000011 0x00000004 0x00000012 0x00000004 0x00000013>; dma-names = "tx0", "rx0", "tx1", "rx1"; ti,spi-num-cs = <0x00000002>; status = "disabled"; linux,phandle = <0x00000035>; phandle = <0x00000035>; }; spi@481a0000 { compatible = "ti,omap4-mcspi"; ti,hwmods = "spi1"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; reg = <0x481a0000 0x00000400>; interrupt-parent = <0x00000002>; interrupt = <0x0000007d>; dmas = <0x00000004 0x0000002a 0x00000004 0x0000002b 0x00000004 0x0000002c 0x00000004 0x0000002d>; dma-names = "tx0", "rx0", "tx1", "rx1"; ti,spi-num-cs = <0x00000002>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <0x00000008>; linux,phandle = <0x00000020>; phandle = <0x00000020>; }; wdt@44e35000 { compatible = "ti,omap3-wdt"; ti,hwmods = "wd_timer2"; reg = <0x44e35000 0x00001000>; interrupt-parent = <0x00000002>; interrupts = <0x0000005b>; linux,phandle = <0x00000036>; phandle = <0x00000036>; }; ethernet@4A100000 { compatible = "ti,cpsw"; ti,hwmods = "cpgmac0"; cpdma_channels = <0x00000008>; host_port_no = <0x00000000>; cpdma_reg_ofs = <0x00000800>; cpdma_sram_ofs = <0x00000a00>; ale_reg_ofs = <0x00000d00>; ale_entries = <0x00000400>; host_port_reg_ofs = <0x00000108>; hw_stats_reg_ofs = <0x00000900>; bd_ram_ofs = <0x00002000>; bd_ram_size = <0x00002000>; no_bd_ram = <0x00000000>; rx_descs = <0x00000040>; mac_control = <0x00000020>; slaves = <0x00000002>; reg = <0x4a100000 0x00000800 0x4a101200 0x00000100 0x4a101000 0x00000100>; #address-cells = <0x00000001>; #size-cells = <0x00000001>; interrupt-parent = <0x00000002>; interrupts = <0x00000028 0x00000029 0x0000002a 0x0000002b>; ranges; linux,phandle = <0x00000037>; phandle = <0x00000037>; slave@0 { slave_reg_ofs = <0x00000208>; sliver_reg_ofs = <0x00000d80>; mac-address = [00 00 00 00 00 00]; phy_id = "4a101000.mdio:00"; linux,phandle = <0x00000038>; phandle = <0x00000038>; }; slave@1 { slave_reg_ofs = <0x00000308>; sliver_reg_ofs = <0x00000dc0>; mac-address = [00 00 00 00 00 00]; phy_id = "4a101000.mdio:01"; linux,phandle = <0x00000039>; phandle = <0x00000039>; }; mdio@4a101000 { compatible = "ti,davinci_mdio"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; ti,hwmods = "davinci_mdio"; bus_freq = <0x000f4240>; reg = <0x4a101000 0x00000100>; linux,phandle = <0x0000003a>; phandle = <0x0000003a>; }; }; ehrpwm@48300200 { compatible = "ti,omap2-ehrpwm"; reg = <0x48300200 0x00000100 0x48300000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x00000056 0x0000003a>; ti,hwmods = "ehrpwm0"; #pwm-cells = <0x00000003>; status = "disabled"; linux,phandle = <0x0000003b>; phandle = <0x0000003b>; }; ehrpwm@48302200 { compatible = "ti,omap2-ehrpwm"; reg = <0x48302200 0x00000100 0x48302000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x00000057 0x0000003b>; ti,hwmods = "ehrpwm1"; #pwm-cells = <0x00000003>; status = "okay"; linux,phandle = <0x00000015>; phandle = <0x00000015>; }; ehrpwm@48304200 { compatible = "ti,omap2-ehrpwm"; reg = <0x48304200 0x00000100 0x48304000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x00000027 0x0000003c>; ti,hwmods = "ehrpwm2"; #pwm-cells = <0x00000003>; status = "disabled"; linux,phandle = <0x0000003c>; phandle = <0x0000003c>; }; ecap@48300100 { compatible = "ti,omap2-ecap"; reg = <0x48300100 0x00000080 0x48300000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x0000001f>; ti,hwmods = "ecap0"; #pwm-cells = <0x00000003>; status = "disabled"; linux,phandle = <0x0000003d>; phandle = <0x0000003d>; }; ecap@48302100 { compatible = "ti,omap2-ecap"; reg = <0x48302100 0x00000080 0x48302000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x0000002f>; ti,hwmods = "ecap1"; #pwm-cells = <0x00000003>; status = "disabled"; linux,phandle = <0x0000003e>; phandle = <0x0000003e>; }; ecap@48304100 { compatible = "ti,omap2-ecap"; reg = <0x48304100 0x00000080 0x48304000 0x00000010>; interrupt-parent = <0x00000002>; interrupt = <0x0000003d>; ti,hwmods = "ecap2"; #pwm-cells = <0x00000003>; status = "disabled"; linux,phandle = <0x0000003f>; phandle = <0x0000003f>; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x00000009>; led0 { label = "beaglebone:green:usr0"; gpios = <0x0000000a 0x00000015 0x00000000>; linux,default-trigger = "heartbeat"; default-state = "off"; }; led1 { label = "beaglebone:green:usr1"; gpios = <0x0000000a 0x00000016 0x00000000>; linux,default-trigger = "mmc0"; default-state = "off"; }; led2 { label = "beaglebone:green:usr2"; gpios = <0x0000000a 0x00000017 0x00000000>; linux,default-trigger = "cpu0"; default-state = "off"; }; led3 { label = "beaglebone:green:usr3"; gpios = <0x0000000a 0x00000018 0x00000000>; default-state = "off"; linux,default-trigger = "mmc1"; }; }; gpevt { compatible = "gpevt"; pinctrl-names = "default"; pinctrl-0 = <0x0000000b>; dmas = <0x00000004 0x0000000c>; dma-names = "gpioevt"; gpio-evt = <0x0000000c 0x00000002 0x00000000>; }; }; capebus@0 { compatible = "bone-capebus"; slots = <0x0000000d 0x0000000e 0x0000000f 0x00000010>; linux,phandle = <0x00000040>; phandle = <0x00000040>; cape@0 { compatible = "bone-generic-cape"; board-name = "BeagleBone DVI-D CAPE"; linux,phandle = <0x00000041>; phandle = <0x00000041>; version@00A0 { version = "00A0"; dvi { compatible = "da8xx-dt"; pinctrl-names = "default"; pinctrl-0 = <0x00000011>; ti,hwmods = "lcdc"; disp-pll = <0x2160ec00>; panel-type = "1024x768@60"; powerdn-gpio = <0x0000000a 0x00000007 0x00000000>; }; }; version@00A1 { version = "00A1", "01"; dvi { compatible = "da8xx-dt"; pinctrl-names = "default"; pinctrl-0 = <0x00000012>; ti,hwmods = "lcdc"; disp-pll = <0x2160ec00>; panel-type = "1024x768@60"; powerdn-gpio = <0x0000000a 0x0000001f 0x00000000>; }; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x00000013>; dvi-led0 { label = "dvi:green:usr0"; gpios = <0x0000000a 0x00000012 0x00000000>; linux,default-trigger = "heartbeat"; default-state = "off"; }; dvi-led1 { label = "dvi:green:usr1"; gpios = <0x0000000a 0x00000013 0x00000000>; linux,default-trigger = "mmc0"; default-state = "off"; }; }; }; cape@1 { compatible = "bone-geiger-cape"; board-name = "Geiger Cape"; pinctrl-names = "default"; pinctrl-0 = <0x00000014>; pwms = <0x00000015 0x00000000 0x0007a120 0x00000000>; pwm-names = "bone-geiger-cape"; pwm-frequency = <0x00004e20>; pwm-duty-cycle = <0x0000003c>; event-blink-delay = <0x0000001e>; gpios = <0x00000016 0x00000011 0x00000000>; vsense-name = "AIN5"; vsense-scale = <0x000091cd>; linux,phandle = <0x00000042>; phandle = <0x00000042>; tscadc { compatible = "ti-tscadc-dt"; ti,hwmods = "adc_tsc"; adc-channels = <0x00000008>; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x00000017>; geiger-led0 { label = "geiger:green:usr0"; gpios = <0x0000000c 0x00000017 0x00000000>; linux,default-trigger = "geiger-run"; default-state = "off"; }; geiger-led1 { label = "geiger:red:usr1"; gpios = <0x0000000c 0x00000019 0x00000000>; linux,default-trigger = "geiger-event"; default-state = "off"; }; }; }; cape@2 { compatible = "bone-generic-cape"; board-name = "BeagleBone LCD3 CAPE"; linux,phandle = <0x00000043>; phandle = <0x00000043>; lcd3 { compatible = "da8xx-dt"; pinctrl-names = "default"; pinctrl-0 = <0x00000018>; ti,hwmods = "lcdc"; disp-pll = <0x00f42400>; panel-type = "CDTech_S035Q01"; }; tscadc { compatible = "ti-tscadc-dt"; ti,hwmods = "adc_tsc"; tsc-wires = <0x00000004>; tsc-x-plate-resistance = <0x000000c8>; tsc-steps = <0x00000006>; adc-channels = <0x00000004>; }; version@00A0 { version = "00A0"; backlight { compatible = "tps65217-backlight"; isel = <0x00000001>; fdim = <0x000000c8>; tps = <0x00000019>; brightness = <0x00000064>; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x0000001a>; lcd3-led0 { label = "lcd3:green:usr0"; gpios = <0x0000000a 0x00000012 0x00000000>; linux,default-trigger = "heartbeat"; default-state = "off"; }; lcd3-led1 { label = "lcd3:green:usr1"; gpios = <0x0000000a 0x00000013 0x00000000>; linux,default-trigger = "cpu0"; default-state = "off"; }; }; gpio_keys { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <0x0000001b>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; button@1 { debounce_interval = <0x00000032>; linux,code = <0x00000069>; label = "left"; gpios = <0x0000000a 0x00000010 0x00000000>; gpio-key,wakeup; autorepeat; }; button@2 { debounce_interval = <0x00000032>; linux,code = <0x0000006a>; label = "right"; gpios = <0x0000000a 0x00000011 0x00000000>; gpio-key,wakeup; autorepeat; }; button@3 { debounce_interval = <0x00000032>; linux,code = <0x00000067>; label = "up"; gpios = <0x00000016 0x00000013 0x00000000>; gpio-key,wakeup; autorepeat; }; button@4 { debounce_interval = <0x00000032>; linux,code = <0x0000006c>; label = "down"; gpios = <0x0000000a 0x0000001c 0x00000000>; gpio-key,wakeup; autorepeat; }; button@5 { debounce_interval = <0x00000032>; linux,code = <0x0000001c>; label = "enter"; gpios = <0x0000001c 0x00000007 0x00000000>; gpio-key,wakeup; }; }; }; }; cape@3 { compatible = "bone-lcd7-cape"; board-name = "BeagleBone LCD7 CAPE"; linux,phandle = <0x00000044>; phandle = <0x00000044>; lcd7 { compatible = "da8xx-dt"; pinctrl-names = "default"; pinctrl-0 = <0x00000018>; ti,hwmods = "lcdc"; disp-pll = <0x03938700>; panel-type = "TFC_S9700RTWV35TR_01B"; }; tscadc { compatible = "ti-tscadc-dt"; ti,hwmods = "adc_tsc"; tsc-wires = <0x00000004>; tsc-x-plate-resistance = <0x000000c8>; tsc-steps = <0x00000006>; adc-channels = <0x00000004>; }; version@00A0 { version = "00A0"; backlight { compatible = "tps65217-backlight"; isel = <0x00000001>; fdim = <0x000000c8>; tps = <0x00000019>; brightness = <0x00000064>; }; gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x0000001a>; lcd3-led0 { label = "lcd3:green:usr0"; gpios = <0x0000000a 0x00000012 0x00000000>; linux,default-trigger = "heartbeat"; default-state = "off"; }; lcd3-led1 { label = "lcd3:green:usr1"; gpios = <0x0000000a 0x00000013 0x00000000>; linux,default-trigger = "cpu0"; default-state = "off"; }; }; gpio_keys { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <0x0000001b>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; button@1 { debounce_interval = <0x00000032>; linux,code = <0x00000069>; label = "left"; gpios = <0x0000000a 0x00000010 0x00000000>; gpio-key,wakeup; autorepeat; }; button@2 { debounce_interval = <0x00000032>; linux,code = <0x0000006a>; label = "right"; gpios = <0x0000000a 0x00000011 0x00000000>; gpio-key,wakeup; autorepeat; }; button@3 { debounce_interval = <0x00000032>; linux,code = <0x00000067>; label = "up"; gpios = <0x00000016 0x00000013 0x00000000>; gpio-key,wakeup; autorepeat; }; button@4 { debounce_interval = <0x00000032>; linux,code = <0x0000006c>; label = "down"; gpios = <0x0000000a 0x0000001c 0x00000000>; gpio-key,wakeup; autorepeat; }; button@5 { debounce_interval = <0x00000032>; linux,code = <0x0000001c>; label = "enter"; gpios = <0x0000001c 0x00000007 0x00000000>; gpio-key,wakeup; }; }; }; }; cape@4 { compatible = "bone-generic-cape"; board-name = "BeagleBone Weather CAPE"; linux,phandle = <0x00000045>; phandle = <0x00000045>; i2c2-devices { compatible = "i2c-dt"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; parent = <0x0000001d>; tsl2550@39 { compatible = "tsl,tsl2550"; reg = <0x00000039>; }; sht21@40 { compatible = "sensiron,sht21"; reg = <0x00000040>; }; bmp085@77 { compatible = "bosch,bmp085"; reg = <0x00000077>; }; }; onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; pinctrl-0 = <0x0000001e>; status = "okay"; gpios = <0x0000000a 0x00000003 0x00000000>; }; }; cape@5 { compatible = "bone-generic-cape"; board-name = "Adafruit 1.8 Cape"; linux,phandle = <0x00000046>; phandle = <0x00000046>; backlight { compatible = "pwm-backlight"; pinctrl-names = "default"; pinctrl-0 = <0x0000001f>; pwms = <0x00000015 0x00000001 0x0007a120 0x00000000>; pwm-names = "st7735fb"; brightness-levels = <0x00000000 0x00000001 0x00000002 0x00000003 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000d 0x0000000e 0x0000000f 0x00000010 0x00000011 0x00000012 0x00000013 0x00000014 0x00000015 0x00000016 0x00000017 0x00000018 0x00000019 0x0000001a 0x0000001b 0x0000001c 0x0000001d 0x0000001e 0x0000001f 0x00000020 0x00000021 0x00000022 0x00000023 0x00000024 0x00000025 0x00000026 0x00000027 0x00000028 0x00000029 0x0000002a 0x0000002b 0x0000002c 0x0000002d 0x0000002e 0x0000002f 0x00000030 0x00000031 0x00000032 0x00000033 0x00000034 0x00000035 0x00000036 0x00000037 0x00000038 0x00000039 0x0000003a 0x0000003b 0x0000003c 0x0000003d 0x0000003e 0x0000003f 0x00000040 0x00000041 0x00000042 0x00000043 0x00000044 0x00000045 0x00000046 0x00000047 0x00000048 0x00000049 0x0000004a 0x0000004b 0x0000004c 0x0000004d 0x0000004e 0x0000004f 0x00000050 0x00000051 0x00000052 0x00000053 0x00000054 0x00000055 0x00000056 0x00000057 0x00000058 0x00000059 0x0000005a 0x0000005b 0x0000005c 0x0000005d 0x0000005e 0x0000005f 0x00000060 0x00000061 0x00000062 0x00000063 0x00000064>; default-brightness-level = <0x00000032>; }; spi1-devices { compatible = "spi-dt"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; parent = <0x00000020>; lcd@0 { compatible = "adafruit,tft-lcd-1.8-red", "sitronix,st7735"; spi-max-frequency = <0x007a1200>; reg = <0x00000000>; spi-cpol; spi-cpha; pinctrl-names = "default"; pinctrl-0 = <0x00000021>; st7735-rst = <0x00000016 0x00000013 0x00000000>; st7735-dc = <0x00000016 0x00000015 0x00000000>; }; }; }; }; @symbols@ { am3358_pinmux = "/pinmux@44e10800"; spi1_pins = "/pinmux@44e10800/pinmux_spi1_pins"; lcd_pins = "/pinmux@44e10800/pinmux_lcd_pins"; gpevt_pins = "/pinmux@44e10800/pinmux_gpevt_pins"; userled_pins = "/pinmux@44e10800/pinmux_userled_pins"; i2c2_pins = "/pinmux@44e10800/pinmux_i2c2_pins"; bone_dvi_cape_led_pins = "/pinmux@44e10800/pinmux_bone_dvi_cape_led_pins"; bone_dvi_cape_dvi_00A0_pins = "/pinmux@44e10800/pinmux_bone_dvi_cape_dvi_00A0_pins"; bone_dvi_cape_dvi_00A1_pins = "/pinmux@44e10800/pinmux_bone_dvi_cape_dvi_00A1_pins"; bone_geiger_cape_led_pins = "/pinmux@44e10800/pinmux_bone_geiger_cape_led_pins"; bone_geiger_cape_pins = "/pinmux@44e10800/pinmux_bone_geiger_cape_pins"; bone_lcd3_cape_led_00A0_pins = "/pinmux@44e10800/pinmux_bone_lcd3_cape_led_00A0_pins"; bone_lcd3_cape_lcd_pins = "/pinmux@44e10800/pinmux_bone_lcd3_cape_lcd_pins"; bone_lcd3_cape_keys_00A0_pins = "/pinmux@44e10800/pinmux_bone_lcd3_cape_keys_00A0_pins"; pwm_bl_pins = "/pinmux@44e10800/pinmux_pwm_bl_pins"; weather_cape_w1_pins = "/pinmux@44e10800/pinmux_weather_cape_w1_pins"; intc = "/ocp/interrupt-controller@48200000"; edma = "/ocp/edma@49000000"; gpio1 = "/ocp/gpio@44e07000"; gpio2 = "/ocp/gpio@4804c000"; gpio3 = "/ocp/gpio@481ac000"; gpio4 = "/ocp/gpio@481ae000"; uart1 = "/ocp/serial@44e09000"; uart2 = "/ocp/serial@48022000"; uart3 = "/ocp/serial@48024000"; uart4 = "/ocp/serial@481a6000"; uart5 = "/ocp/serial@481a8000"; uart6 = "/ocp/serial@481aa000"; i2c0 = "/ocp/i2c@44e0b000"; tps = "/ocp/i2c@44e0b000/tps@24"; dcdc1_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@0"; dcdc2_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@1"; dcdc3_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@2"; ldo1_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@3"; ldo2_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@4"; ldo3_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@5"; ldo4_reg = "/ocp/i2c@44e0b000/tps@24/regulators/regulator@6"; baseboard_eeprom = "/ocp/i2c@44e0b000/baseboard_eeprom@50"; i2c1 = "/ocp/i2c@4802a000"; i2c2 = "/ocp/i2c@4819c000"; cape_eeprom_0 = "/ocp/i2c@4819c000/cape_eeprom_0@54"; cape_eeprom_1 = "/ocp/i2c@4819c000/cape_eeprom_1@55"; cape_eeprom_2 = "/ocp/i2c@4819c000/cape_eeprom_2@56"; cape_eeprom_3 = "/ocp/i2c@4819c000/cape_eeprom_3@57"; mmc1 = "/ocp/mmc@48060000"; mmc2 = "/ocp/mmc@481d8000"; mmc3 = "/ocp/mmc@47810000"; usb0_phy = "/ocp/phy0"; usb1_phy = "/ocp/phy1"; usb_otg_hs = "/ocp/usb_otg_hs"; spi0 = "/ocp/spi@48030000"; spi1 = "/ocp/spi@481a0000"; wdt2 = "/ocp/wdt@44e35000"; mac = "/ocp/ethernet@4A100000"; cpsw_emac0 = "/ocp/ethernet@4A100000/slave@0"; cpsw_emac1 = "/ocp/ethernet@4A100000/slave@1"; davinci_mdio = "/ocp/ethernet@4A100000/mdio@4a101000"; ehrpwm0 = "/ocp/ehrpwm@48300200"; ehrpwm1 = "/ocp/ehrpwm@48302200"; ehrpwm2 = "/ocp/ehrpwm@48304200"; ecap0 = "/ocp/ecap@48300100"; ecap1 = "/ocp/ecap@48302100"; ecap2 = "/ocp/ecap@48304100"; capebus = "/capebus@0"; bone_dvi_cape = "/capebus@0/cape@0"; bone_geiger_cape = "/capebus@0/cape@1"; bone_lcd3_cape = "/capebus@0/cape@2"; bone_lcd7_cape = "/capebus@0/cape@3"; bone_weather_cape = "/capebus@0/cape@4"; bone_adafruit_cape = "/capebus@0/cape@5"; }; }; ^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 7:25 ` David Gibson 2012-11-13 8:09 ` Pantelis Antoniou @ 2012-11-13 16:57 ` Stephen Warren 2012-11-13 18:10 ` Mitch Bradley 1 sibling, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-13 16:57 UTC (permalink / raw) To: David Gibson Cc: Pantelis Antoniou, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/13/2012 12:25 AM, David Gibson wrote: > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > [snip] >>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>> and beaglebone, for the cape to work for both, it is required for it's >>> dtb to be compatible. >> >> Well, as Grant pointed out, it's not actually strictly necessary for the >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >> can be generated at run-time using dtc for example. > > So, actually, I think a whole bunch of problems with phandle > resolution disappear if we don't try to define an overlay .dtb format, > or at least treat it only as a very shortlived object. A more precise > proposal below. Note that this works more or less equally well with > either the original overlay approach or the graft/graft-bundle > proposal I made elsewhere. > > 1) We annotate the base tree with some extra label information for > nodes which overlays are likely to want to reference by phandle. e.g. > > beaglebone_pic: interrupt-controller@XXXXX { > ... > phandle,symbolic-name = "beaglebone_pic"; > }; > > We could extend dtc to (optionally?) auto-generate those properties > from its existing label syntax. Not sure if that's a good idea or > not yet. In any case, we compile this augmented base tree to .dtb as > normal and boot our kernel with it. Yes, I think a name-based approach is preferable over using opaque/arbitrary phandle IDs/ranges/... > 2) The information for the capes/modules/whatever is > distributed/packaged as .dts, never .dtb. When userspace detects the > new module (or the user explicitly tells it, if it's not probeable) it > picks up the correct dts and runs it through dtc in a special mode. > In this mode dtc takes the existing base tree (from /proc/device-tree, > say) as well as the new dts. In this mode, dtc allocates phandles for > the new tree fragment so as not to collide with anything from the > supplied base tree (as well as avoiding internal conflicts, > obviously). It also allows node references to the base tree by using > those label annotations from (1) to match symbolic names to the > phandle values in the base tree. > > 3) The resulting partial .dtb for the module is highly specific to the > base tree (which if the base tree was generated at runtime by firmware > could even be specific to a particular boot). But that's ok, because > we just spit it into the kernel, absolute phandle values and all, then > throw it away. Next time we need the module info, we recompile it > again. Once you've booted with a base tree, and loaded a partial .dtb for one child board, and are then loading a .dtb for another child board (or you unloaded the original child board and are loading a replacement), then presumably the current in-kernel device tree also depends on all the runtime history too. So then going back to your point (2), that means we need to have user-space serialize the dtc execution so that we don't compile two new partial .dtbs in parallel, and end up with each not conflicting with the current in-kernel device tree, but still conflicting with each-other. I imagine that's easily solvable though. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 18:10 ` Mitch Bradley 0 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-13 18:10 UTC (permalink / raw) To: Stephen Warren Cc: David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap, devicetree-discuss It seems to me that this capebus discussion is missing an important point. The name capebus suggests that it is a bus, so there should be a parent node to represent that bus. It should have a driver whose API implements all of the system-interface functions a cape needs. If you look at the way that interrupt specifiers work, the default case is that a child device implicitly delegates the mapping to its parent. The use of phandles to break out of the tree structure was intended for use within the "hardwired motherboard domain", not for plug-in devices. The "new" phandle-based GPIO and clock mechanisms don't have that parent-delegation feature, but they should, because hierarchical hardware is a good thing when it exists. One fix would be to designate a reserved phandle value - for example 0 or -1 - to mean "my parent". t The parent node would contain some translator to resolve the actual target node, similarly to interrupts and addresses. If done correctly, capebus "overlays" would then just be proper child nodes of the capebus bus node and there would no need to refer to "global" information like non-parent phandles. If something about the design of capebus makes that impossible, I respectfully suggest that its design should be reviewed, taking into account the many years of industry experience about modularity. Mitch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 18:10 ` Mitch Bradley 0 siblings, 0 replies; 135+ messages in thread From: Mitch Bradley @ 2012-11-13 18:10 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ It seems to me that this capebus discussion is missing an important point. The name capebus suggests that it is a bus, so there should be a parent node to represent that bus. It should have a driver whose API implements all of the system-interface functions a cape needs. If you look at the way that interrupt specifiers work, the default case is that a child device implicitly delegates the mapping to its parent. The use of phandles to break out of the tree structure was intended for use within the "hardwired motherboard domain", not for plug-in devices. The "new" phandle-based GPIO and clock mechanisms don't have that parent-delegation feature, but they should, because hierarchical hardware is a good thing when it exists. One fix would be to designate a reserved phandle value - for example 0 or -1 - to mean "my parent". t The parent node would contain some translator to resolve the actual target node, similarly to interrupts and addresses. If done correctly, capebus "overlays" would then just be proper child nodes of the capebus bus node and there would no need to refer to "global" information like non-parent phandles. If something about the design of capebus makes that impossible, I respectfully suggest that its design should be reviewed, taking into account the many years of industry experience about modularity. Mitch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 18:29 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-13 18:29 UTC (permalink / raw) To: Mitch Bradley Cc: David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap, devicetree-discuss On 11/13/2012 11:10 AM, Mitch Bradley wrote: > It seems to me that this capebus discussion is missing an important > point. The name capebus suggests that it is a bus, so there should be a > parent node to represent that bus. It should have a driver whose API > implements all of the system-interface functions a cape needs. It was discussed earlier that capebus isn't actually a bus. It's simply a collection of a bunch of pins from the SoC hooked up to connectors. I'd agree that it's mis-named. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 18:29 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-13 18:29 UTC (permalink / raw) To: Mitch Bradley Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/13/2012 11:10 AM, Mitch Bradley wrote: > It seems to me that this capebus discussion is missing an important > point. The name capebus suggests that it is a bus, so there should be a > parent node to represent that bus. It should have a driver whose API > implements all of the system-interface functions a cape needs. It was discussed earlier that capebus isn't actually a bus. It's simply a collection of a bunch of pins from the SoC hooked up to connectors. I'd agree that it's mis-named. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 18:29 ` Stephen Warren (?) @ 2012-11-13 19:09 ` Mitch Bradley 2012-11-13 19:11 ` Pantelis Antoniou -1 siblings, 1 reply; 135+ messages in thread From: Mitch Bradley @ 2012-11-13 19:09 UTC (permalink / raw) To: Stephen Warren Cc: David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap, devicetree-discuss On 11/13/2012 8:29 AM, Stephen Warren wrote: > On 11/13/2012 11:10 AM, Mitch Bradley wrote: >> It seems to me that this capebus discussion is missing an important >> point. The name capebus suggests that it is a bus, so there should be a >> parent node to represent that bus. It should have a driver whose API >> implements all of the system-interface functions a cape needs. > > It was discussed earlier that capebus isn't actually a bus. It's simply > a collection of a bunch of pins from the SoC hooked up to connectors. > I'd agree that it's mis-named. > Nevertheless, to the extent that the set of pins is finite and well-defined, it should be possible to define a set of software interfaces to support the functionality represented by those pins. It might depend on the underlying SoC, but even so, it would still be best to encapsulate the interface set. I hear all these use cases that presuppose a wide variety of user skill sets. If one really wants to support such users well, it's important to define a coherent single point of interface. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 19:09 ` Mitch Bradley @ 2012-11-13 19:11 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-13 19:11 UTC (permalink / raw) To: Mitch Bradley Cc: Stephen Warren, David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap, devicetree-discuss Hi Mitch, On Nov 13, 2012, at 9:09 PM, Mitch Bradley wrote: > On 11/13/2012 8:29 AM, Stephen Warren wrote: >> On 11/13/2012 11:10 AM, Mitch Bradley wrote: >>> It seems to me that this capebus discussion is missing an important >>> point. The name capebus suggests that it is a bus, so there should be a >>> parent node to represent that bus. It should have a driver whose API >>> implements all of the system-interface functions a cape needs. >> >> It was discussed earlier that capebus isn't actually a bus. It's simply >> a collection of a bunch of pins from the SoC hooked up to connectors. >> I'd agree that it's mis-named. >> > > Nevertheless, to the extent that the set of pins is finite and > well-defined, it should be possible to define a set of software > interfaces to support the functionality represented by those pins. > > It might depend on the underlying SoC, but even so, it would still be > best to encapsulate the interface set. I hear all these use cases that > presuppose a wide variety of user skill sets. If one really wants to > support such users well, it's important to define a coherent single > point of interface. > > That's what capebus is. Too bad there's such a fuss about the name. Check out the thread from the start for the sordid details. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 23:23 ` Stephen Warren 2012-11-09 23:40 ` Grant Likely 2012-11-12 12:10 ` Pantelis Antoniou @ 2012-11-17 22:27 ` Jean-Christophe PLAGNIOL-VILLARD 2012-11-20 17:09 ` Grant Likely 2 siblings, 1 reply; 135+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-17 22:27 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 16:23 Fri 09 Nov , Stephen Warren wrote: > On 11/09/2012 09:28 AM, Grant Likely wrote: > > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > ... > >> I do rather suspect this use-case is quite common. NVIDIA certainly has > >> a bunch of development boards with pluggable > >> PMIC/audio/WiFi/display/..., and I believe there's some ability to > >> re-use the pluggable components with a variety of base-boards. > >> > >> Given people within NVIDIA started talking about this recently, I asked > >> them to enumerate all the boards we have that support pluggable > >> components, and how common it is that some boards support being plugged > >> into different main boards. I don't know when that enumeration will > >> complete (or even start) but hopefully I can provide some feedback on > >> how common the use-case is for us once it's done. > > > > From your perspective, is it important to use the exact same .dtb > > overlays for those add-on boards, or is it okay to have a separate > > build of the overlay for each base tree? > > I certainly think it'd be extremely beneficial to use the exact same > child board .dtb with arbitrary base boards. > > Consider something like the Arduino shield connector format, which I > /believe/ has been re-used across a wide variety of Arduino boards and > other compatible or imitation boards. Now consider a vendor of an > Arduino shield. The shield vendor probably wants to publish a single > .dtb file that works for users irrespective of which board they're using > it with. > > (Well, I'm not sure that Arduino can run Linux; perhaps that's why you > picked BeagleBone capes for your document!) > > I suppose it would be acceptable for the shield vendor to ship the .dts > file rather than the .dtb, and hence need to build the shield .dtb for a > specific base board. > > However, I think the process for an end-user needs to be as simple as > "drop this .dts/.dtb file into some standard directory", and I imagine > it'll be much easier for distros/... to make that process work if > they're dealing with a .dtb that they can just blast into the kernel's > firmware loader interface, rather than having to also locate the > base-board .dts/.dtb file, and run dtc and/or other tools on both .dts > files together. I've exactly the same issue on Calao or the new atmel boards We have lego boards with different cpu-modues running on differetn mother boards with diferrentdaugther boards on atmel we are lucky enough we can identity via 1-wire all of them but on Calao no On Somfy platform we can detect hardware version and need different pinctrl So personally I'll prefer to be able to request dtb from the kernel or push them from the userspace as it will depends where you will detect the hardware present The main concern will which part of the kenel will now handle hw detection? Best Regards, J. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-17 22:27 ` Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-20 17:09 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-20 17:09 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD, Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Sat, 17 Nov 2012 23:27:18 +0100, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > On 16:23 Fri 09 Nov , Stephen Warren wrote: > > On 11/09/2012 09:28 AM, Grant Likely wrote: > > However, I think the process for an end-user needs to be as simple as > > "drop this .dts/.dtb file into some standard directory", and I imagine > > it'll be much easier for distros/... to make that process work if > > they're dealing with a .dtb that they can just blast into the kernel's > > firmware loader interface, rather than having to also locate the > > base-board .dts/.dtb file, and run dtc and/or other tools on both .dts > > files together. > I've exactly the same issue on Calao or the new atmel boards > > We have lego boards > > with different cpu-modues running on differetn mother boards with > diferrentdaugther boards > > on atmel we are lucky enough we can identity via 1-wire all of them but > on Calao no > > On Somfy platform we can detect hardware version and need different pinctrl > > So personally I'll prefer to be able to request dtb from the kernel or push > them from the userspace as it will depends where you will detect the hardware > present > > The main concern will which part of the kenel will now handle hw detection? Along the lines of what you said above, it will depend on the board. If the board /can/ be detected, then the kernel should do so and request the appropriate configuration. If it cannot, then it simply must be left up to either userspace or something explicit in the boot devicetree. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 16:28 ` Grant Likely 2012-11-09 23:23 ` Stephen Warren @ 2012-11-11 20:47 ` Rob Landley 2012-11-12 12:50 ` Pantelis Antoniou 2012-11-12 11:23 ` Pantelis Antoniou 2012-11-12 16:45 ` Stephen Warren 3 siblings, 1 reply; 135+ messages in thread From: Rob Landley @ 2012-11-11 20:47 UTC (permalink / raw) To: Grant Likely Cc: Stephen Warren, Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/09/2012 10:28:59 AM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren > <swarren@wwwdotorg.org> wrote: > > On 11/05/2012 01:40 PM, Grant Likely wrote: > I'm not actually opposed to it, but it needs to be done in an elegant > way. The DT data model already imposes more of a conceptual learning > curve than I wish it did and I don't want to make that worse with a > versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-11 20:47 ` Rob Landley @ 2012-11-12 12:50 ` Pantelis Antoniou 2012-11-12 16:54 ` Stephen Warren 0 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 12:50 UTC (permalink / raw) To: Rob Landley Cc: Grant Likely, Stephen Warren, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Rob. On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: > On 11/09/2012 10:28:59 AM, Grant Likely wrote: >> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> > On 11/05/2012 01:40 PM, Grant Likely wrote: >> I'm not actually opposed to it, but it needs to be done in an elegant >> way. The DT data model already imposes more of a conceptual learning >> curve than I wish it did and I don't want to make that worse with a >> versioning model that is difficult to get ones head around. > > Speaking of which... > > I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. > > I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. > > And I'd like to write up an article on doing it as a learning exercise. > > Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) > > Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) > > Rob It should be possible when the stuff we're talking about is ready. I don't know what you'll find is broken during the exercise, but I guess your article is going to be entertaining at least :) Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 16:54 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-12 16:54 UTC (permalink / raw) To: Pantelis Antoniou Cc: Rob Landley, Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 05:50 AM, Pantelis Antoniou wrote: > Hi Rob. > > On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: > >> On 11/09/2012 10:28:59 AM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> On 11/05/2012 01:40 PM, Grant Likely wrote: >>> I'm not actually opposed to it, but it needs to be done in an elegant >>> way. The DT data model already imposes more of a conceptual learning >>> curve than I wish it did and I don't want to make that worse with a >>> versioning model that is difficult to get ones head around. >> >> Speaking of which... >> >> I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. >> >> I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. >> >> And I'd like to write up an article on doing it as a learning exercise. >> >> Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) >> >> Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) >> >> Rob > > It should be possible when the stuff we're talking about is ready. > > I don't know what you'll find is broken during the exercise, but I guess > your article is going to be entertaining at least :) To be honest, I think Rob's proposal should be possible irrespective of this conversation; if he wants to simply define the HW structure once before running qemu, then none of this overlay discussion is relevant. Perhaps the missing piece is the Documentation/devicetree/bindings/ directory? ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 16:54 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-12 16:54 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/12/2012 05:50 AM, Pantelis Antoniou wrote: > Hi Rob. > > On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: > >> On 11/09/2012 10:28:59 AM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote: >>>> On 11/05/2012 01:40 PM, Grant Likely wrote: >>> I'm not actually opposed to it, but it needs to be done in an elegant >>> way. The DT data model already imposes more of a conceptual learning >>> curve than I wish it did and I don't want to make that worse with a >>> versioning model that is difficult to get ones head around. >> >> Speaking of which... >> >> I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. >> >> I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. >> >> And I'd like to write up an article on doing it as a learning exercise. >> >> Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) >> >> Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) >> >> Rob > > It should be possible when the stuff we're talking about is ready. > > I don't know what you'll find is broken during the exercise, but I guess > your article is going to be entertaining at least :) To be honest, I think Rob's proposal should be possible irrespective of this conversation; if he wants to simply define the HW structure once before running qemu, then none of this overlay discussion is relevant. Perhaps the missing piece is the Documentation/devicetree/bindings/ directory? ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 16:28 ` Grant Likely 2012-11-09 23:23 ` Stephen Warren 2012-11-11 20:47 ` Rob Landley @ 2012-11-12 11:23 ` Pantelis Antoniou 2012-11-12 16:49 ` Stephen Warren 2012-11-12 20:16 ` Russ Dill 2012-11-12 16:45 ` Stephen Warren 3 siblings, 2 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 11:23 UTC (permalink / raw) To: Grant Likely Cc: Stephen Warren, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 11/05/2012 01:40 PM, Grant Likely wrote: >>> Hey folks, >>> >>> As promised, here is my early draft to try and capture what device >>> tree overlays need to do and how to get there. Comments and >>> suggestions greatly appreciated. >> >> Interesting. This just came up internally at NVIDIA within the last >> couple weeks, and was discussed on the U-Boot mailing list very recently >> too: >> >> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >> (it spills into the November archive too) >> >>> For these cases it is proposed to implement an overlay feature for the >>> so that the initial device tree data can be modified by userspace at >> >> I don't know if you're maintaining this as a document and taking patches >> to it, but if so: > > Sure, why not... > > http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary > >> >> "for the so" split across those two lines. > > fixed > >>> - SHOULD reliably handle changes between different underlying overlays >>> (ie. what happens to existing .dtb overly files if the structure of >>> the dtb it is layered over changes. If not possible, then SHALL >>> detect when the base tree doesn't match and refuse to apply the >>> overlay. >> >> Perhaps use (versioned) DT bindings to represent the interface between >> the two .dts files? See the links to the U-Boot mailing list discussions >> below? > > Implementing versioning is conceptually a lot more complex than plain > overlays since it means either the kernel or u-boot needs to start > filtering the data that it's given. This can get really complex in a > hurry. Mitch makes a valid point later in this thread that when it > comes to manipulating the data depending on the board then the data > overlay model alone doesn't handle it well. > > I'm not actually opposed to it, but it needs to be done in an elegant > way. The DT data model already imposes more of a conceptual learning > curve than I wish it did and I don't want to make that worse with a > versioning model that is difficult to get ones head around. > > Suggestions and proposals are definitely welcome here. > I didn't find versioning all that difficult TBH. Making the property access functions work sanely with versioning should cover most (if not all) kernel users. Keep non versioned property access function available to possibly users with a prefix for those that need it. >> >>> - What is the model for overlays? >>> - Can an overlay modify existing properties? >>> - Can an overlay add new properties to existing nodes? >>> - Can an overlay delete existing nodes/properties? >> >> This proposal is very oriented at an overlay-based approach. I'm not >> totally convinced that a pure overlay approach (as in how dtc does >> overlayed DT nodes) will be flexible enough, but would love to be >> persuaded. Again see below. > > The way I'm currently thinking about the overlay approach is as a > discrete set of changes that all can be applied at once.* That > certainly doesn't preclude the change being generated with a script or > other tool in either firmware or userspace. For most changes it works > really well. Of the scenarios that don't work well, I can think of > two. The first is it moving or renaming existing nodes, and the second > is if the structure of the base tree changes (say due to a firmware > update). Although the second limitation is specifically with binary > .dtb overlays. Recompiling the dts overlay against the new tree would > work fine.** > Atomicity should be handled correctly. I can't imagine how hard would be to back out a semi-applied overlay without some kind of core DT tracking support. Leaving it to the driver/user is too difficult to get right. About moving and renaming nodes, I can't think of a user-case today that needs it. Perhaps it can be handled by removal & re-insertion? > *with the caveat that not all types of changes are a good idea and we > may disallow. For example, is changing properties in existing nodes a > good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. > ** all this is based on my current ideas about the .dtb overlay format > which would be trivial to implement, but I'm not committed to that > approach just yet. The above problems could be solved. > >>> It may be sufficient to solve it by making the phandle values less >>> volatile. Right now dtc generates phandles linearly. Generated phandles >>> could be overridden with explicit phandle properties, but it isn't a >>> fantastic solution. Perhaps generating the phandle from a hash of the >>> node name would be sufficient. >> >> Node names don't have to be unique though right; perhaps hash the >> path-name instead of the node-name? But then, why not just reference by >> path name; similar to <{&/path/to/node}> rather than <&label>? > > I was thinking about using the full_name for generating phandles. On > the odd chance there is a collision, one of the nodes will get > something like the hash value +1. Or in that condition we can require > one of the nodes to have the phandle value explicitly set in the > source file. > > Note; this doesn't actually affect anything outside of dtc. Right now > dtc starts at 1 and assigns phandles incrementally. I'm suggesting > using a hash of the full_name to assign the phandle for a node so that > it will not change unless the full_path changes. > >>> This handles many of the use cases, but it assumes that an overlay is >>> board specific. If it ever is required to support multiple base boards >>> with a single overlay file then there is a problem. The .dtb overlays >>> generated in this manor cannot handle different phandles or nodes that >>> are in a different place. On the other hand, the overlay source files >>> should have no problem being compiled for multiple targets. >> >> s/manor/manner/ > > Fixed > >> >> I do rather suspect this use-case is quite common. NVIDIA certainly has >> a bunch of development boards with pluggable >> PMIC/audio/WiFi/display/..., and I believe there's some ability to >> re-use the pluggable components with a variety of base-boards. >> >> Given people within NVIDIA started talking about this recently, I asked >> them to enumerate all the boards we have that support pluggable >> components, and how common it is that some boards support being plugged >> into different main boards. I don't know when that enumeration will >> complete (or even start) but hopefully I can provide some feedback on >> how common the use-case is for us once it's done. > > From your perspective, is it important to use the exact same .dtb > overlays for those add-on boards, or is it okay to have a separate > build of the overlay for each base tree? > > g. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 11:23 ` Pantelis Antoniou @ 2012-11-12 16:49 ` Stephen Warren 2012-11-12 17:00 ` Pantelis Antoniou 2012-11-12 20:16 ` Russ Dill 1 sibling, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-12 16:49 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: > Hi Grant, > > Sorry for the late comments, travelling... > > On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... >> *with the caveat that not all types of changes are a good idea and we >> may disallow. For example, is changing properties in existing nodes a >> good idea? > > Yes, changing properties is something that we need. One such change is > the change of the bus controller 'status' properties to enabled upon > insertion of a child device node, and change back to 'on-demand' when > all the child device nodes are gone. Do we actually need to do that? >From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 16:49 ` Stephen Warren @ 2012-11-12 17:00 ` Pantelis Antoniou 2012-11-12 17:10 ` Stephen Warren 0 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 17:00 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: > On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >> Hi Grant, >> >> Sorry for the late comments, travelling... >> >> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: > ... >>> *with the caveat that not all types of changes are a good idea and we >>> may disallow. For example, is changing properties in existing nodes a >>> good idea? >> >> Yes, changing properties is something that we need. One such change is >> the change of the bus controller 'status' properties to enabled upon >> insertion of a child device node, and change back to 'on-demand' when >> all the child device nodes are gone. > > Do we actually need to do that? > > From the base-board perspective, consider an SoC's I2C channel that is > routed to the child board connector. The routing to the connector is > always present on the base board. Only the presence (or lack thereof) of > devices on that I2C bus is influenced by whether a child board is > connected or not, and the design of the child board. Therefore, wouldn't > it make sense for the base board to always enable the I2C controller? > > That would make it easier for someone to hook up a couple wires to the > I2C pins and use utilities such as i2cget/set to communicate with it, > without going through the whole process of creating a DT to represent > the device. This could speed up simple hacking/prototyping and allow it > to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 17:00 ` Pantelis Antoniou @ 2012-11-12 17:10 ` Stephen Warren 2012-11-12 17:19 ` Pantelis Antoniou 0 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-12 17:10 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: > >> On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >>> Hi Grant, >>> >>> Sorry for the late comments, travelling... >>> >>> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: >> ... >>>> *with the caveat that not all types of changes are a good idea and we >>>> may disallow. For example, is changing properties in existing nodes a >>>> good idea? >>> >>> Yes, changing properties is something that we need. One such change is >>> the change of the bus controller 'status' properties to enabled upon >>> insertion of a child device node, and change back to 'on-demand' when >>> all the child device nodes are gone. >> >> Do we actually need to do that? >> >> From the base-board perspective, consider an SoC's I2C channel that is >> routed to the child board connector. The routing to the connector is >> always present on the base board. Only the presence (or lack thereof) of >> devices on that I2C bus is influenced by whether a child board is >> connected or not, and the design of the child board. Therefore, wouldn't >> it make sense for the base board to always enable the I2C controller? >> >> That would make it easier for someone to hook up a couple wires to the >> I2C pins and use utilities such as i2cget/set to communicate with it, >> without going through the whole process of creating a DT to represent >> the device. This could speed up simple hacking/prototyping and allow it >> to proceed in a less structured way. > > Unfortunately that doesn't work for the beaglebone (am355x) and a large > number of general purpose SoCs. > > What is different between general purpose SoCs and vertical market SoCs > (i.e. OMAP) is that the design of the the latter is for devices where > pretty much all the interfaces are expected to be active at the same time. > > General purpose SoCs put more peripherals in the SoC, but due to packaging > considerations (and price), the peripheral pins are highly muxed. > > So the i2c bus pins are shared with the LCD controller are shared with the > analog input and so on. > > It is impossible (and on top of that really dangerous) to enable peripheral > blocks without knowing what's connected on the other side. > > In a nutshell, for the bone and similar devices, probing with the devices > enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 17:10 ` Stephen Warren @ 2012-11-12 17:19 ` Pantelis Antoniou 2012-11-12 17:29 ` Stephen Warren 0 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 17:19 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: > On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: >> Hi Stephen, >> >> On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: >> >>> On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >>>> Hi Grant, >>>> >>>> Sorry for the late comments, travelling... >>>> >>>> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: >>> ... >>>>> *with the caveat that not all types of changes are a good idea and we >>>>> may disallow. For example, is changing properties in existing nodes a >>>>> good idea? >>>> >>>> Yes, changing properties is something that we need. One such change is >>>> the change of the bus controller 'status' properties to enabled upon >>>> insertion of a child device node, and change back to 'on-demand' when >>>> all the child device nodes are gone. >>> >>> Do we actually need to do that? >>> >>> From the base-board perspective, consider an SoC's I2C channel that is >>> routed to the child board connector. The routing to the connector is >>> always present on the base board. Only the presence (or lack thereof) of >>> devices on that I2C bus is influenced by whether a child board is >>> connected or not, and the design of the child board. Therefore, wouldn't >>> it make sense for the base board to always enable the I2C controller? >>> >>> That would make it easier for someone to hook up a couple wires to the >>> I2C pins and use utilities such as i2cget/set to communicate with it, >>> without going through the whole process of creating a DT to represent >>> the device. This could speed up simple hacking/prototyping and allow it >>> to proceed in a less structured way. >> >> Unfortunately that doesn't work for the beaglebone (am355x) and a large >> number of general purpose SoCs. >> >> What is different between general purpose SoCs and vertical market SoCs >> (i.e. OMAP) is that the design of the the latter is for devices where >> pretty much all the interfaces are expected to be active at the same time. >> >> General purpose SoCs put more peripherals in the SoC, but due to packaging >> considerations (and price), the peripheral pins are highly muxed. >> >> So the i2c bus pins are shared with the LCD controller are shared with the >> analog input and so on. >> >> It is impossible (and on top of that really dangerous) to enable peripheral >> blocks without knowing what's connected on the other side. >> >> In a nutshell, for the bone and similar devices, probing with the devices >> enabled doesn't work. > > I think this can be solved by deferring the pinmux to the .dts for the > child board. Presumably the I2C controller node can be enabled just > fine, but the I2C signals not actually routed out to any pins on the SoC > until the specific pinmux configuration is loaded. > Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. > But your explanation still feels a little odd; is it really true on the > BeagleBone, you can either use LCD for graphics /or/ you can use the I2C > controller to communicate with a cape? I certainly fully understand that > from a SoC's perspective (and soc.dtsi perspective) you can't just > enable everything due to pinmux constraints, but it seems that once you > get to the level of a particular board design, the designer has made > those trade-offs and so you know which specific combination is to be > selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 17:19 ` Pantelis Antoniou @ 2012-11-12 17:29 ` Stephen Warren 2012-11-12 17:38 ` Pantelis Antoniou 0 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-12 17:29 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 10:19 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: > >> On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: >>> Hi Stephen, >>> >>> On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: >>> >>>> On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >>>>> Hi Grant, >>>>> >>>>> Sorry for the late comments, travelling... >>>>> >>>>> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: >>>> ... >>>>>> *with the caveat that not all types of changes are a good idea and we >>>>>> may disallow. For example, is changing properties in existing nodes a >>>>>> good idea? >>>>> >>>>> Yes, changing properties is something that we need. One such change is >>>>> the change of the bus controller 'status' properties to enabled upon >>>>> insertion of a child device node, and change back to 'on-demand' when >>>>> all the child device nodes are gone. >>>> >>>> Do we actually need to do that? >>>> >>>> From the base-board perspective, consider an SoC's I2C channel that is >>>> routed to the child board connector. The routing to the connector is >>>> always present on the base board. Only the presence (or lack thereof) of >>>> devices on that I2C bus is influenced by whether a child board is >>>> connected or not, and the design of the child board. Therefore, wouldn't >>>> it make sense for the base board to always enable the I2C controller? >>>> >>>> That would make it easier for someone to hook up a couple wires to the >>>> I2C pins and use utilities such as i2cget/set to communicate with it, >>>> without going through the whole process of creating a DT to represent >>>> the device. This could speed up simple hacking/prototyping and allow it >>>> to proceed in a less structured way. >>> >>> Unfortunately that doesn't work for the beaglebone (am355x) and a large >>> number of general purpose SoCs. >>> >>> What is different between general purpose SoCs and vertical market SoCs >>> (i.e. OMAP) is that the design of the the latter is for devices where >>> pretty much all the interfaces are expected to be active at the same time. >>> >>> General purpose SoCs put more peripherals in the SoC, but due to packaging >>> considerations (and price), the peripheral pins are highly muxed. >>> >>> So the i2c bus pins are shared with the LCD controller are shared with the >>> analog input and so on. >>> >>> It is impossible (and on top of that really dangerous) to enable peripheral >>> blocks without knowing what's connected on the other side. >>> >>> In a nutshell, for the bone and similar devices, probing with the devices >>> enabled doesn't work. >> >> I think this can be solved by deferring the pinmux to the .dts for the >> child board. Presumably the I2C controller node can be enabled just >> fine, but the I2C signals not actually routed out to any pins on the SoC >> until the specific pinmux configuration is loaded. >> > > Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. > > So you'll end up hacking the device drivers to handle a weird state that > basically means 'don't activate until I tell you to go'. It is simpler > just not to create the device. > >> But your explanation still feels a little odd; is it really true on the >> BeagleBone, you can either use LCD for graphics /or/ you can use the I2C >> controller to communicate with a cape? I certainly fully understand that >> from a SoC's perspective (and soc.dtsi perspective) you can't just >> enable everything due to pinmux constraints, but it seems that once you >> get to the level of a particular board design, the designer has made >> those trade-offs and so you know which specific combination is to be >> selected. > > There are multiple I2C busses, multiple SPI buses, multiple options to > connect something that produces audio, and so on. It is not odd at the least > for the kind of market these chips are for. > > Even TI doesn't know exactly the kind of applications these devices will be > used for. The chip is there to provide connection option at a (cheap) price > point. > > Think of a swiss-army knife with some tools that can be used at the > same time, and some that can't. Yes, I fully understand the flexibility of the SoC; the NVIDIA Tegra SoC I maintain has exactly the same kind of flexibility. However, I'm still thining that presumably the pins that could be used for hypothetical example as any of (a) LCD, (b) I2C controller 2, (c) UART 3 have been routed to the cape-bus connector specifically for the purpose of e.g. I2C controller 2, and hence their usage has been locked in. Is that not the case? Is it instead true that some SoC pins are routed to both an LCD connector /and/ the cape-bus connector so the board itself has a usage conflict, or is it true that the cape-bus connector is in fact just a set of 100 "random" pins each with no specific pre-defined purpose, and it's up to the cape designer to pick the SoC's pinmux configuration rather than the base board designer? That would make the cape-bus pinout specific to the BeagleBone or the specific SoC on the board, which if IIUC is something very different to the Arduino shield pinout design, where each pin on the connector is designated for a specific purpose, and hence arbitrary different SoCs could (and do) host the same connector design without needing the same pinmux HW design, which would obviously be impossible. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 17:29 ` Stephen Warren @ 2012-11-12 17:38 ` Pantelis Antoniou 0 siblings, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 17:38 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 12, 2012, at 7:29 PM, Stephen Warren wrote: > On 11/12/2012 10:19 AM, Pantelis Antoniou wrote: >> Hi Stephen, >> >> On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: >> >>> On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: >>>> Hi Stephen, >>>> >>>> On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: >>>> >>>>> On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >>>>>> Hi Grant, >>>>>> >>>>>> Sorry for the late comments, travelling... >>>>>> >>>>>> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: >>>>> ... >>>>>>> *with the caveat that not all types of changes are a good idea and we >>>>>>> may disallow. For example, is changing properties in existing nodes a >>>>>>> good idea? >>>>>> >>>>>> Yes, changing properties is something that we need. One such change is >>>>>> the change of the bus controller 'status' properties to enabled upon >>>>>> insertion of a child device node, and change back to 'on-demand' when >>>>>> all the child device nodes are gone. >>>>> >>>>> Do we actually need to do that? >>>>> >>>>> From the base-board perspective, consider an SoC's I2C channel that is >>>>> routed to the child board connector. The routing to the connector is >>>>> always present on the base board. Only the presence (or lack thereof) of >>>>> devices on that I2C bus is influenced by whether a child board is >>>>> connected or not, and the design of the child board. Therefore, wouldn't >>>>> it make sense for the base board to always enable the I2C controller? >>>>> >>>>> That would make it easier for someone to hook up a couple wires to the >>>>> I2C pins and use utilities such as i2cget/set to communicate with it, >>>>> without going through the whole process of creating a DT to represent >>>>> the device. This could speed up simple hacking/prototyping and allow it >>>>> to proceed in a less structured way. >>>> >>>> Unfortunately that doesn't work for the beaglebone (am355x) and a large >>>> number of general purpose SoCs. >>>> >>>> What is different between general purpose SoCs and vertical market SoCs >>>> (i.e. OMAP) is that the design of the the latter is for devices where >>>> pretty much all the interfaces are expected to be active at the same time. >>>> >>>> General purpose SoCs put more peripherals in the SoC, but due to packaging >>>> considerations (and price), the peripheral pins are highly muxed. >>>> >>>> So the i2c bus pins are shared with the LCD controller are shared with the >>>> analog input and so on. >>>> >>>> It is impossible (and on top of that really dangerous) to enable peripheral >>>> blocks without knowing what's connected on the other side. >>>> >>>> In a nutshell, for the bone and similar devices, probing with the devices >>>> enabled doesn't work. >>> >>> I think this can be solved by deferring the pinmux to the .dts for the >>> child board. Presumably the I2C controller node can be enabled just >>> fine, but the I2C signals not actually routed out to any pins on the SoC >>> until the specific pinmux configuration is loaded. >>> >> >> Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. >> >> So you'll end up hacking the device drivers to handle a weird state that >> basically means 'don't activate until I tell you to go'. It is simpler >> just not to create the device. >> >>> But your explanation still feels a little odd; is it really true on the >>> BeagleBone, you can either use LCD for graphics /or/ you can use the I2C >>> controller to communicate with a cape? I certainly fully understand that >>> from a SoC's perspective (and soc.dtsi perspective) you can't just >>> enable everything due to pinmux constraints, but it seems that once you >>> get to the level of a particular board design, the designer has made >>> those trade-offs and so you know which specific combination is to be >>> selected. >> >> There are multiple I2C busses, multiple SPI buses, multiple options to >> connect something that produces audio, and so on. It is not odd at the least >> for the kind of market these chips are for. >> >> Even TI doesn't know exactly the kind of applications these devices will be >> used for. The chip is there to provide connection option at a (cheap) price >> point. >> >> Think of a swiss-army knife with some tools that can be used at the >> same time, and some that can't. > > Yes, I fully understand the flexibility of the SoC; the NVIDIA Tegra SoC > I maintain has exactly the same kind of flexibility. > > However, I'm still thining that presumably the pins that could be used > for hypothetical example as any of (a) LCD, (b) I2C controller 2, (c) > UART 3 have been routed to the cape-bus connector specifically for the > purpose of e.g. I2C controller 2, and hence their usage has been locked in. > > Is that not the case? Is it instead true that some SoC pins are routed > to both an LCD connector /and/ the cape-bus connector so the board > itself has a usage conflict, or is it true that the cape-bus connector > is in fact just a set of 100 "random" pins each with no specific > pre-defined purpose, and it's up to the cape designer to pick the SoC's > pinmux configuration rather than the base board designer? That would > make the cape-bus pinout specific to the BeagleBone or the specific SoC > on the board, which if IIUC is something very different to the Arduino > shield pinout design, where each pin on the connector is designated for > a specific purpose, and hence arbitrary different SoCs could (and do) > host the same connector design without needing the same pinmux HW > design, which would obviously be impossible. There is no LCD specific connector, and no preset pin configuration. The only set of pins that are defined to have a set configuration are the pins of the i2c2 bus, on which the EEPROM identifying the cape is located. And of the pins that do connect a standard peripheral, all of them can be reconfigured for basic GPIO for starters. The beaglebone is infinitely more flexible and capable than an arduino. Everything is up to the cape designer. All that the kernel can do is handle conflicts and not enable capes that conflict with each other. Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-12 11:23 ` Pantelis Antoniou 2012-11-12 16:49 ` Stephen Warren @ 2012-11-12 20:16 ` Russ Dill 1 sibling, 0 replies; 135+ messages in thread From: Russ Dill @ 2012-11-12 20:16 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Stephen Warren, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, linux-omap, devicetree-discuss On Mon, Nov 12, 2012 at 3:23 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > Hi Grant, > > Sorry for the late comments, travelling... > > On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: > >> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> On 11/05/2012 01:40 PM, Grant Likely wrote: >>>> Hey folks, >>>> >>>> As promised, here is my early draft to try and capture what device >>>> tree overlays need to do and how to get there. Comments and >>>> suggestions greatly appreciated. >>> >>> Interesting. This just came up internally at NVIDIA within the last >>> couple weeks, and was discussed on the U-Boot mailing list very recently >>> too: >>> >>> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >>> (it spills into the November archive too) >>> >>>> For these cases it is proposed to implement an overlay feature for the >>>> so that the initial device tree data can be modified by userspace at >>> >>> I don't know if you're maintaining this as a document and taking patches >>> to it, but if so: >> >> Sure, why not... >> >> http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary >> >>> >>> "for the so" split across those two lines. >> >> fixed >> >>>> - SHOULD reliably handle changes between different underlying overlays >>>> (ie. what happens to existing .dtb overly files if the structure of >>>> the dtb it is layered over changes. If not possible, then SHALL >>>> detect when the base tree doesn't match and refuse to apply the >>>> overlay. >>> >>> Perhaps use (versioned) DT bindings to represent the interface between >>> the two .dts files? See the links to the U-Boot mailing list discussions >>> below? >> >> Implementing versioning is conceptually a lot more complex than plain >> overlays since it means either the kernel or u-boot needs to start >> filtering the data that it's given. This can get really complex in a >> hurry. Mitch makes a valid point later in this thread that when it >> comes to manipulating the data depending on the board then the data >> overlay model alone doesn't handle it well. >> >> I'm not actually opposed to it, but it needs to be done in an elegant >> way. The DT data model already imposes more of a conceptual learning >> curve than I wish it did and I don't want to make that worse with a >> versioning model that is difficult to get ones head around. >> >> Suggestions and proposals are definitely welcome here. >> > > I didn't find versioning all that difficult TBH. > > Making the property access functions work sanely with versioning > should cover most (if not all) kernel users. > Keep non versioned property access function available to possibly > users with a prefix for those that need it. > >>> >>>> - What is the model for overlays? >>>> - Can an overlay modify existing properties? >>>> - Can an overlay add new properties to existing nodes? >>>> - Can an overlay delete existing nodes/properties? >>> >>> This proposal is very oriented at an overlay-based approach. I'm not >>> totally convinced that a pure overlay approach (as in how dtc does >>> overlayed DT nodes) will be flexible enough, but would love to be >>> persuaded. Again see below. >> >> The way I'm currently thinking about the overlay approach is as a >> discrete set of changes that all can be applied at once.* That >> certainly doesn't preclude the change being generated with a script or >> other tool in either firmware or userspace. For most changes it works >> really well. Of the scenarios that don't work well, I can think of >> two. The first is it moving or renaming existing nodes, and the second >> is if the structure of the base tree changes (say due to a firmware >> update). Although the second limitation is specifically with binary >> .dtb overlays. Recompiling the dts overlay against the new tree would >> work fine.** >> > > Atomicity should be handled correctly. I can't imagine how hard would > be to back out a semi-applied overlay without some kind of core DT > tracking support. Leaving it to the driver/user is too difficult to get > right. > > About moving and renaming nodes, I can't think of a user-case today that > needs it. Perhaps it can be handled by removal & re-insertion? > >> *with the caveat that not all types of changes are a good idea and we >> may disallow. For example, is changing properties in existing nodes a >> good idea? > > Yes, changing properties is something that we need. One such change is > the change of the bus controller 'status' properties to enabled upon > insertion of a child device node, and change back to 'on-demand' when > all the child device nodes are gone. Some devices will probably have to support on the fly changes that they may not have otherwise supported. An example of a driver that needs to modify it's device based on DT would be an I²C bus speed change. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 16:28 ` Grant Likely ` (2 preceding siblings ...) 2012-11-12 11:23 ` Pantelis Antoniou @ 2012-11-12 16:45 ` Stephen Warren 3 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-12 16:45 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/09/2012 09:28 AM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 11/05/2012 01:40 PM, Grant Likely wrote: >>> Hey folks, >>> >>> As promised, here is my early draft to try and capture what device >>> tree overlays need to do and how to get there. Comments and >>> suggestions greatly appreciated. >> >> Interesting. This just came up internally at NVIDIA within the last >> couple weeks, and was discussed on the U-Boot mailing list very recently >> too: >> >> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 >> (it spills into the November archive too) >> >>> For these cases it is proposed to implement an overlay feature for the >>> so that the initial device tree data can be modified by userspace at >> >> I don't know if you're maintaining this as a document and taking patches >> to it, but if so: > > Sure, why not... > > http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary > >> >> "for the so" split across those two lines. > > fixed > >>> - SHOULD reliably handle changes between different underlying overlays >>> (ie. what happens to existing .dtb overly files if the structure of >>> the dtb it is layered over changes. If not possible, then SHALL >>> detect when the base tree doesn't match and refuse to apply the >>> overlay. >> >> Perhaps use (versioned) DT bindings to represent the interface between >> the two .dts files? See the links to the U-Boot mailing list discussions >> below? > > Implementing versioning is conceptually a lot more complex than plain > overlays since it means either the kernel or u-boot needs to start > filtering the data that it's given. This can get really complex in a > hurry. Mitch makes a valid point later in this thread that when it > comes to manipulating the data depending on the board then the data > overlay model alone doesn't handle it well. What I was thinking of sounds a lot simpler than what I think you're responding to. All I was thinking about was that we define some kind of explicit interface between .dts files, e.g. some kind of direct representation of the connector between the boards. The versioning aspect is then: Then, when the connector design changes, we change the naming of that interface representation. This would happen in just the same way that we'd name/represent the connector design of a BeagleBone differently from that of an Arduino. So, perhaps we start out with: ti,beaglebone-cape-connector arduino,shield-connector and later end up with: ti,beaglebone-cape-connector-v2 as far as any code that handled/references the v1/v2 interface definitions, they'd probably be completely unrelated types in the general case, just named very similarly. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 20:40 [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Grant Likely ` (2 preceding siblings ...) 2012-11-06 22:37 ` Stephen Warren @ 2012-11-09 2:26 ` David Gibson 2012-11-09 15:40 ` Pantelis Antoniou ` (4 more replies) 2012-11-09 23:06 ` Stephen Warren 2012-11-12 11:03 ` Koen Kooi 5 siblings, 5 replies; 135+ messages in thread From: David Gibson @ 2012-11-09 2:26 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Mon, Nov 05, 2012 at 08:40:30PM +0000, Grant Likely wrote: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. > > Device Tree Overlay Feature Hrm. So, you may yet convince me otherwise, but I'm really getting a feeling of overengineering from this proposal so far. > Purpose > ======= > Sometimes it is not convenient to describe an entire system with a > single FDT. For example, processor modules that are plugged into one or > more modules (a la the BeagleBone), or systems with an FPGA peripheral > that is programmed after the system is booted. > > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at > runtime by loading additional overlay FDTs that amend the original data. > > User Stories > ============ [snip] The user stories mostly sound reasonable to me, but I don't know enough about the hardware in question to know what they'll mean in terms of what needs to be added to the base device tree. > Summary points: > - Create an FDT overlay data format and usage model > - SHALL reliable resolve or validate of phandles between base and > overlay trees So, I'm not at all clear on what this proposed phandle validation would involve. I'm also not convinced it's as necessary as you think, more on that below. [snip - lots of technical stuff] So, let me take a stab at this from a more bottom-up approach, and see if we meet in the middle somewhere. As I discussed in the other thread with Daniel Mack, I can see two different operationso on the fdt that might be useful in this context. I think of them as "graft" - which takes one fdt and adds it as a new subtree to an existing fdt - and "overlay" where a new fdt adds or overrides arbitrary properties in an existing tree. Overlay is more or less what we do at the source level in dtc already. Overlay is obviously more general - you can add, change and possibly delete any existing node or property. Graft can only add new nodes and properties, not modify existing ones. But that restriction comes with some advantages: reversing the operation is just a matter of deleting the subtree with no extra tracking info required. It's simple to see how to have rules or permissions about where subtrees can be grafted, and if the graft point is identified by a label or id, rather than full path, it automatically adapts to at least some changes in the base tree structure. I think graft is basically a safer operation, particular if we're doing this at runtime with userspace passing in these fdt fragments. In fact I'd go so far as to say if you really need the full overlay functionality, then you really ought to be working at the bootloader or early kernel load level to assemble the correct full device tree. And as Mitch says, an existing programming language (C, OFW Forth or whatever as you please) will serve you better for this sort of general manipulation than a limited template system. I also think graft will handle most of your use cases, although as I said I don't fully understand the implications of some of them, so I could be wrong. So, the actual insertion of the subtree is pretty trivial to implement. phandles are the obvious other matter to be dealt with. I haven't found the right thread where what you've envisaged so far is discussed, so here are things I can see: 1) Avoiding phandle collisions between main tree and subtree (or between subtrees). I'm hopeful that this can be resolved just by establishing some conventions about the ranges of phandles to be used for various components. I'd certainly be happy to add a directive to dtc which enforces allocation of phandles within a specified range. 2) Resolving phandle references within a subtree If we can handle (1) by convention, we don't need anything here, the references are fine as is. (3) Resolving phandle references from the subtree to the main tree. So, I think this can actually be avoided, at least in cases where what physical connections are available to the expansion module is well defined. The main causes to have external references are interrupts and gpios. Interrupts we handle by defining an interrupt specifier space for the interrupts available on the expansion socket/connector/bus/whatever. In the master tree we then have something like: ... expansion-socket@XXXX { expansion-id = "SlotA"; interrupt-map = < /* map expansion irq specs to board interrupt controllers */ >; interrupt-map-mask = < ... >; ranges = < /* map expansion local addresses to global mmio */ >; }; The subtree for the expansion module gets attached as a subnode of this one. It doesn't use explicit interrupt-parents but instead just uses the expansion local irq specifiers, letting the parent be the default which will bubble up to this socket node where the interrupt-map will send them to the right places. I don't recall the gpio bindings off hand, but as I recall we based them off the irq tree bindings so we ought to be able to do the same thing for them. Likewise, if there are several interchangeable expansion sockets that have some address bits hard wired to distinguish them, we can just use socket local mmio addresses within the subtree and the ranges property here will sort that out. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 2:26 ` David Gibson @ 2012-11-09 15:40 ` Pantelis Antoniou 2012-11-13 0:03 ` David Gibson 2012-11-09 21:08 ` Grant Likely ` (3 subsequent siblings) 4 siblings, 1 reply; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-09 15:40 UTC (permalink / raw) To: David Gibson Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss Hi David, On Nov 9, 2012, at 3:26 AM, David Gibson wrote: > On Mon, Nov 05, 2012 at 08:40:30PM +0000, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. >> >> Device Tree Overlay Feature > > Hrm. So, you may yet convince me otherwise, but I'm really getting a > feeling of overengineering from this proposal so far. > >> Purpose >> ======= >> Sometimes it is not convenient to describe an entire system with a >> single FDT. For example, processor modules that are plugged into one or >> more modules (a la the BeagleBone), or systems with an FPGA peripheral >> that is programmed after the system is booted. >> >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at >> runtime by loading additional overlay FDTs that amend the original data. >> >> User Stories >> ============ > > [snip] > > The user stories mostly sound reasonable to me, but I don't know > enough about the hardware in question to know what they'll mean in > terms of what needs to be added to the base device tree. > >> Summary points: >> - Create an FDT overlay data format and usage model >> - SHALL reliable resolve or validate of phandles between base and >> overlay trees > > So, I'm not at all clear on what this proposed phandle validation > would involve. I'm also not convinced it's as necessary as you > think, more on that below. > > [snip - lots of technical stuff] > > So, let me take a stab at this from a more bottom-up approach, and see > if we meet in the middle somewhere. As I discussed in the other > thread with Daniel Mack, I can see two different operationso on the > fdt that might be useful in this context. I think of them as "graft" > - which takes one fdt and adds it as a new subtree to an existing fdt > - and "overlay" where a new fdt adds or overrides arbitrary properties > in an existing tree. Overlay is more or less what we do at the source > level in dtc already. > > Overlay is obviously more general - you can add, change and possibly > delete any existing node or property. > > Graft can only add new nodes and properties, not modify existing ones. > But that restriction comes with some advantages: reversing the > operation is just a matter of deleting the subtree with no extra > tracking info required. It's simple to see how to have rules or > permissions about where subtrees can be grafted, and if the graft > point is identified by a label or id, rather than full path, it > automatically adapts to at least some changes in the base tree > structure. > > I think graft is basically a safer operation, particular if we're > doing this at runtime with userspace passing in these fdt fragments. > In fact I'd go so far as to say if you really need the full overlay > functionality, then you really ought to be working at the bootloader > or early kernel load level to assemble the correct full device tree. > And as Mitch says, an existing programming language (C, OFW Forth or > whatever as you please) will serve you better for this sort of general > manipulation than a limited template system. > > I also think graft will handle most of your use cases, although as I > said I don't fully understand the implications of some of them, so I > could be wrong. So, the actual insertion of the subtree is pretty > trivial to implement. phandles are the obvious other matter to be > dealt with. I haven't found the right thread where what you've > envisaged so far is discussed, so here are things I can see: > An overlay is more generic and can handle more complex cases. For our use case, a graft should work - with a few caveats. Due to the insertion/removal of the DT fragments other node's state change from 'disabled' <-> 'okay' and platform devices created or removed. This can be handled either via overlays, or via special casing it. > 1) Avoiding phandle collisions between main tree and subtree (or > between subtrees). > > I'm hopeful that this can be resolved just by establishing some > conventions about the ranges of phandles to be used for various > components. I'd certainly be happy to add a directive to dtc which > enforces allocation of phandles within a specified range. > Really doubtful IMHO. That will impose yet more structure on the DT syntax, and it will make it even more difficult for users. We're talking about users that do understand the hardware, but can't really grok linux kernel development. DT is used a structured h/w definition and seems to work just fine for these kind of users. > 2) Resolving phandle references within a subtree > > If we can handle (1) by convention, we don't need anything here, the > references are fine as is. > > (3) Resolving phandle references from the subtree to the main tree. > > So, I think this can actually be avoided, at least in cases where what > physical connections are available to the expansion module is well > defined. The main causes to have external references are interrupts > and gpios. Interrupts we handle by defining an interrupt specifier > space for the interrupts available on the expansion > socket/connector/bus/whatever. In the master tree we then have > something like: > > ... > expansion-socket@XXXX { > expansion-id = "SlotA"; > interrupt-map = < /* map expansion irq specs to > board interrupt controllers */ >; > interrupt-map-mask = < ... >; > ranges = < /* map expansion local addresses to global > mmio */ >; > }; > > The subtree for the expansion module gets attached as a subnode of > this one. It doesn't use explicit interrupt-parents but instead just > uses the expansion local irq specifiers, letting the parent be the > default which will bubble up to this socket node where the > interrupt-map will send them to the right places. > > I don't recall the gpio bindings off hand, but as I recall we based > them off the irq tree bindings so we ought to be able to do the same > thing for them. > Please, don't try to do it this way. It is very debatable that we'll identify all the types that will need special handling. For example for our cape use, we already have references that do not follow this example. A generic way to resolve references is what we need. > Likewise, if there are several interchangeable expansion sockets that > have some address bits hard wired to distinguish them, we can just use > socket local mmio addresses within the subtree and the ranges property > here will sort that out. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 0:03 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 0:03 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 09, 2012 at 04:40:15PM +0100, Pantelis Antoniou wrote: > Hi David, [snip] > > I think graft is basically a safer operation, particular if we're > > doing this at runtime with userspace passing in these fdt fragments. > > In fact I'd go so far as to say if you really need the full overlay > > functionality, then you really ought to be working at the bootloader > > or early kernel load level to assemble the correct full device tree. > > And as Mitch says, an existing programming language (C, OFW Forth or > > whatever as you please) will serve you better for this sort of general > > manipulation than a limited template system. > > > > I also think graft will handle most of your use cases, although as I > > said I don't fully understand the implications of some of them, so I > > could be wrong. So, the actual insertion of the subtree is pretty > > trivial to implement. phandles are the obvious other matter to be > > dealt with. I haven't found the right thread where what you've > > envisaged so far is discussed, so here are things I can see: > > > > An overlay is more generic and can handle more complex cases. > For our use case, a graft should work - with a few caveats. Obviously an overlay is more generic. But the ability to arbitrarily modify existing tree nodes, without any obvious way to enforce rules about what can be altered and what can't frankly gives me the heebie-jeebies. > Due to the insertion/removal of the DT fragments other node's state > change from 'disabled' <-> 'okay' and platform devices created or > removed. This can be handled either via overlays, or via special > casing it. Ah, yes, the status transition is a good point. [snip] > > 1) Avoiding phandle collisions between main tree and subtree (or > > between subtrees). > > > > I'm hopeful that this can be resolved just by establishing some > > conventions about the ranges of phandles to be used for various > > components. I'd certainly be happy to add a directive to dtc which > > enforces allocation of phandles within a specified range. > > > > Really doubtful IMHO. That will impose yet more structure on the DT > syntax, and it will make it even more difficult for users. Um.. I really don't see what's so hard about adding an incantation like: /phandle-range/ 1-0xffff; at the top of your base dts. Then /phandle-range/ 0x10000-0x1ffff; to the plugin dts. Especially if we made the most common base range the default. > We're talking about users that do understand the hardware, but can't > really grok linux kernel development. > > DT is used a structured h/w definition and seems to work just > fine for these kind of users. > > > 2) Resolving phandle references within a subtree > > > > If we can handle (1) by convention, we don't need anything here, the > > references are fine as is. > > > > (3) Resolving phandle references from the subtree to the main tree. > > > > So, I think this can actually be avoided, at least in cases where what > > physical connections are available to the expansion module is well > > defined. The main causes to have external references are interrupts > > and gpios. Interrupts we handle by defining an interrupt specifier > > space for the interrupts available on the expansion > > socket/connector/bus/whatever. In the master tree we then have > > something like: > > > > ... > > expansion-socket@XXXX { > > expansion-id = "SlotA"; > > interrupt-map = < /* map expansion irq specs to > > board interrupt controllers */ >; > > interrupt-map-mask = < ... >; > > ranges = < /* map expansion local addresses to global > > mmio */ >; > > }; > > > > The subtree for the expansion module gets attached as a subnode of > > this one. It doesn't use explicit interrupt-parents but instead just > > uses the expansion local irq specifiers, letting the parent be the > > default which will bubble up to this socket node where the > > interrupt-map will send them to the right places. > > > > I don't recall the gpio bindings off hand, but as I recall we based > > them off the irq tree bindings so we ought to be able to do the same > > thing for them. > > Please, don't try to do it this way. It is very debatable that we'll > identify all the types that will need special handling. > For example for our cape use, we already have references that do not > follow this example. > > A generic way to resolve references is what we need. Hrm... *mutters dubiously*. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 0:03 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 0:03 UTC (permalink / raw) To: Pantelis Antoniou Cc: Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Fri, Nov 09, 2012 at 04:40:15PM +0100, Pantelis Antoniou wrote: > Hi David, [snip] > > I think graft is basically a safer operation, particular if we're > > doing this at runtime with userspace passing in these fdt fragments. > > In fact I'd go so far as to say if you really need the full overlay > > functionality, then you really ought to be working at the bootloader > > or early kernel load level to assemble the correct full device tree. > > And as Mitch says, an existing programming language (C, OFW Forth or > > whatever as you please) will serve you better for this sort of general > > manipulation than a limited template system. > > > > I also think graft will handle most of your use cases, although as I > > said I don't fully understand the implications of some of them, so I > > could be wrong. So, the actual insertion of the subtree is pretty > > trivial to implement. phandles are the obvious other matter to be > > dealt with. I haven't found the right thread where what you've > > envisaged so far is discussed, so here are things I can see: > > > > An overlay is more generic and can handle more complex cases. > For our use case, a graft should work - with a few caveats. Obviously an overlay is more generic. But the ability to arbitrarily modify existing tree nodes, without any obvious way to enforce rules about what can be altered and what can't frankly gives me the heebie-jeebies. > Due to the insertion/removal of the DT fragments other node's state > change from 'disabled' <-> 'okay' and platform devices created or > removed. This can be handled either via overlays, or via special > casing it. Ah, yes, the status transition is a good point. [snip] > > 1) Avoiding phandle collisions between main tree and subtree (or > > between subtrees). > > > > I'm hopeful that this can be resolved just by establishing some > > conventions about the ranges of phandles to be used for various > > components. I'd certainly be happy to add a directive to dtc which > > enforces allocation of phandles within a specified range. > > > > Really doubtful IMHO. That will impose yet more structure on the DT > syntax, and it will make it even more difficult for users. Um.. I really don't see what's so hard about adding an incantation like: /phandle-range/ 1-0xffff; at the top of your base dts. Then /phandle-range/ 0x10000-0x1ffff; to the plugin dts. Especially if we made the most common base range the default. > We're talking about users that do understand the hardware, but can't > really grok linux kernel development. > > DT is used a structured h/w definition and seems to work just > fine for these kind of users. > > > 2) Resolving phandle references within a subtree > > > > If we can handle (1) by convention, we don't need anything here, the > > references are fine as is. > > > > (3) Resolving phandle references from the subtree to the main tree. > > > > So, I think this can actually be avoided, at least in cases where what > > physical connections are available to the expansion module is well > > defined. The main causes to have external references are interrupts > > and gpios. Interrupts we handle by defining an interrupt specifier > > space for the interrupts available on the expansion > > socket/connector/bus/whatever. In the master tree we then have > > something like: > > > > ... > > expansion-socket@XXXX { > > expansion-id = "SlotA"; > > interrupt-map = < /* map expansion irq specs to > > board interrupt controllers */ >; > > interrupt-map-mask = < ... >; > > ranges = < /* map expansion local addresses to global > > mmio */ >; > > }; > > > > The subtree for the expansion module gets attached as a subnode of > > this one. It doesn't use explicit interrupt-parents but instead just > > uses the expansion local irq specifiers, letting the parent be the > > default which will bubble up to this socket node where the > > interrupt-map will send them to the right places. > > > > I don't recall the gpio bindings off hand, but as I recall we based > > them off the irq tree bindings so we ought to be able to do the same > > thing for them. > > Please, don't try to do it this way. It is very debatable that we'll > identify all the types that will need special handling. > For example for our cape use, we already have references that do not > follow this example. > > A generic way to resolve references is what we need. Hrm... *mutters dubiously*. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 2:26 ` David Gibson 2012-11-09 15:40 ` Pantelis Antoniou @ 2012-11-09 21:08 ` Grant Likely 2012-11-13 0:05 ` David Gibson 2012-11-09 21:42 ` Grant Likely ` (2 subsequent siblings) 4 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-09 21:08 UTC (permalink / raw) To: David Gibson Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 2:26 AM, David Gibson <david@gibson.dropbear.id.au> wrote: >> Summary points: >> - Create an FDT overlay data format and usage model >> - SHALL reliable resolve or validate of phandles between base and >> overlay trees > > So, I'm not at all clear on what this proposed phandle validation > would involve. I'm also not convinced it's as necessary as you > think, more on that below. Simply this: I'm taking this example from the omap3-beagle-xm.dts. It has the following stanza which is currently rolled into the resulting .dtb when compiled. &i2c1 { clock-frequency = <2600000>; twl: twl@48 { reg = <0x48>; interrupts = <7>; /* SYS_NIRQ cascaded to intc */ interrupt-parent = <&intc>; vsim: regulator-vsim { compatible = "ti,twl4030-vsim"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3000000>; }; twl_audio: audio { compatible = "ti,twl4030-audio"; codec { }; }; }; }; However, if it were compiled into a separate dtb overlay it might look like this: / { .readonly; ocp { .readonly; interrupt-controller@48200000 { phandle = <0x1234>; /* EXPECTED PHANDLE */ .readonly; }; i2c@48070000 { .must-exist; clock-frequency = <2600000>; twl@48 { reg = <0x48>; interrupts = <7>; interrupt-parent = <0x1234>; /* RESOLVED PHANDLE */ vsim: regulator-vsim { compatible = "ti,twl4030-vsim"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3000000>; }; twl_audio: audio { compatible = "ti,twl4030-audio"; codec { }; }; }; }; }; }; Notice I've included the intc node and it's phandle. By phandle validation I merely mean that when applying an overly the firmware or kernel must verify that the phandles in the overlay match the phandle in the base tree. If they don't match, then refuse to apply the overhead. This approach avoids the need to find and fixup phandles in the overlay. And if the phandle is generated from a hash of the full_name, then the resulting phandle will only change if the node moves. Similarly, at application time it should be verified that the nodes with a .readonly or .must-exist property could be verified to actually exist before attempting to apply the overlay. I used two different properties with the idea that only certain nodes would need to be modified... exactly what the policies should be is yet to be determined. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 0:05 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 0:05 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 09, 2012 at 09:08:14PM +0000, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:26 AM, David Gibson > <david@gibson.dropbear.id.au> wrote: > >> Summary points: > >> - Create an FDT overlay data format and usage model > >> - SHALL reliable resolve or validate of phandles between base and > >> overlay trees > > > > So, I'm not at all clear on what this proposed phandle validation > > would involve. I'm also not convinced it's as necessary as you > > think, more on that below. > > Simply this: I'm taking this example from the omap3-beagle-xm.dts. It > has the following stanza which is currently rolled into the resulting > .dtb when compiled. > > &i2c1 { > clock-frequency = <2600000>; > > twl: twl@48 { > reg = <0x48>; > interrupts = <7>; /* SYS_NIRQ cascaded to intc */ > interrupt-parent = <&intc>; > > vsim: regulator-vsim { > compatible = "ti,twl4030-vsim"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3000000>; > }; > > twl_audio: audio { > compatible = "ti,twl4030-audio"; > codec { > }; > }; > }; > }; > > However, if it were compiled into a separate dtb overlay it might look > like this: > > / { > .readonly; > ocp { > .readonly; > interrupt-controller@48200000 { > phandle = <0x1234>; /* EXPECTED PHANDLE */ > .readonly; > }; > i2c@48070000 { > .must-exist; > clock-frequency = <2600000>; > > twl@48 { > reg = <0x48>; > interrupts = <7>; > interrupt-parent = <0x1234>; /* RESOLVED PHANDLE */ > > vsim: regulator-vsim { > compatible = "ti,twl4030-vsim"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3000000>; > }; > > twl_audio: audio { > compatible = "ti,twl4030-audio"; > codec { > }; > }; > }; > }; > }; > }; > > Notice I've included the intc node and it's phandle. By phandle > validation I merely mean that when applying an overly the firmware or > kernel must verify that the phandles in the overlay match the phandle > in the base tree. If they don't match, then refuse to apply the > overhead. This approach avoids the need to find and fixup phandles in > the overlay. And if the phandle is generated from a hash of the > full_name, then the resulting phandle will only change if the node > moves. > > Similarly, at application time it should be verified that the nodes > with a .readonly or .must-exist property could be verified to actually > exist before attempting to apply the overlay. I used two different > properties with the idea that only certain nodes would need to be > modified... exactly what the policies should be is yet to be > determined. Ok, I see. I really don't like it much, but I understand. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 0:05 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 0:05 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Fri, Nov 09, 2012 at 09:08:14PM +0000, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:26 AM, David Gibson > <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote: > >> Summary points: > >> - Create an FDT overlay data format and usage model > >> - SHALL reliable resolve or validate of phandles between base and > >> overlay trees > > > > So, I'm not at all clear on what this proposed phandle validation > > would involve. I'm also not convinced it's as necessary as you > > think, more on that below. > > Simply this: I'm taking this example from the omap3-beagle-xm.dts. It > has the following stanza which is currently rolled into the resulting > .dtb when compiled. > > &i2c1 { > clock-frequency = <2600000>; > > twl: twl@48 { > reg = <0x48>; > interrupts = <7>; /* SYS_NIRQ cascaded to intc */ > interrupt-parent = <&intc>; > > vsim: regulator-vsim { > compatible = "ti,twl4030-vsim"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3000000>; > }; > > twl_audio: audio { > compatible = "ti,twl4030-audio"; > codec { > }; > }; > }; > }; > > However, if it were compiled into a separate dtb overlay it might look > like this: > > / { > .readonly; > ocp { > .readonly; > interrupt-controller@48200000 { > phandle = <0x1234>; /* EXPECTED PHANDLE */ > .readonly; > }; > i2c@48070000 { > .must-exist; > clock-frequency = <2600000>; > > twl@48 { > reg = <0x48>; > interrupts = <7>; > interrupt-parent = <0x1234>; /* RESOLVED PHANDLE */ > > vsim: regulator-vsim { > compatible = "ti,twl4030-vsim"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3000000>; > }; > > twl_audio: audio { > compatible = "ti,twl4030-audio"; > codec { > }; > }; > }; > }; > }; > }; > > Notice I've included the intc node and it's phandle. By phandle > validation I merely mean that when applying an overly the firmware or > kernel must verify that the phandles in the overlay match the phandle > in the base tree. If they don't match, then refuse to apply the > overhead. This approach avoids the need to find and fixup phandles in > the overlay. And if the phandle is generated from a hash of the > full_name, then the resulting phandle will only change if the node > moves. > > Similarly, at application time it should be verified that the nodes > with a .readonly or .must-exist property could be verified to actually > exist before attempting to apply the overlay. I used two different > properties with the idea that only certain nodes would need to be > modified... exactly what the policies should be is yet to be > determined. Ok, I see. I really don't like it much, but I understand. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 2:26 ` David Gibson 2012-11-09 15:40 ` Pantelis Antoniou 2012-11-09 21:08 ` Grant Likely @ 2012-11-09 21:42 ` Grant Likely 2012-11-13 1:05 ` David Gibson 2012-11-09 22:57 ` Stephen Warren 2012-11-09 23:14 ` Stephen Warren 4 siblings, 1 reply; 135+ messages in thread From: Grant Likely @ 2012-11-09 21:42 UTC (permalink / raw) To: David Gibson Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 2:26 AM, David Gibson <david@gibson.dropbear.id.au> wrote: > (3) Resolving phandle references from the subtree to the main tree. > > So, I think this can actually be avoided, at least in cases where what > physical connections are available to the expansion module is well > defined. The main causes to have external references are interrupts > and gpios. Interrupts we handle by defining an interrupt specifier > space for the interrupts available on the expansion > socket/connector/bus/whatever. In the master tree we then have > something like: > > ... > expansion-socket@XXXX { > expansion-id = "SlotA"; > interrupt-map = < /* map expansion irq specs to > board interrupt controllers */ >; > interrupt-map-mask = < ... >; > ranges = < /* map expansion local addresses to global > mmio */ >; > }; > > The subtree for the expansion module gets attached as a subnode of > this one. It doesn't use explicit interrupt-parents but instead just > uses the expansion local irq specifiers, letting the parent be the > default which will bubble up to this socket node where the > interrupt-map will send them to the right places. > > I don't recall the gpio bindings off hand, but as I recall we based > them off the irq tree bindings so we ought to be able to do the same > thing for them. > > Likewise, if there are several interchangeable expansion sockets that > have some address bits hard wired to distinguish them, we can just use > socket local mmio addresses within the subtree and the ranges property > here will sort that out. If I'm reading correctly, the suggestion is that everything be grafted below a single node and all connections route through that node using mapping. Correct? For interrupts that works today For gpios, it isn't currently supported, but we could do it. For SPI it would mean that the new spi devices would not appear below the actual spi bus they are attached to For I2C, MDIO, and one wire, same problem. For memory mapped devices, the expansion node would need to a ranges for all the windows that map through it, and it assumes only one memory mapped bus (or at least it prefers only one memory mapped bus. If there were more than one then the expansion node placement wouldn't have a natural place to sit) The problem is that this is not like a PCI bus where there is only one kind of interface. It is a whole bunch of interfaces that happen to be grouped together loosely (as an expansion connector in the beaglebone case, but expansion isn't the only problem that I'm hearing about). So, with a group of i2c, spi, memory mapped and other devices than are all plugged in together, how does that look? They really should not sit on the same level. An spi device cannot be a peer of an i2c device for instance, the address mapping is entirely different. The kernel really wants i2c devices to be a child of the actual i2c bus which may already have an i2c device or too on the main board. Does the expansion node need to have some kind of redirect node for each of the busses where the children of it need to create devices as children of the master bus? To me that seems to get really complex in a hurry. More complex than the overlay approach. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 1:05 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 1:05 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:26 AM, David Gibson > <david@gibson.dropbear.id.au> wrote: > > (3) Resolving phandle references from the subtree to the main tree. > > > > So, I think this can actually be avoided, at least in cases where what > > physical connections are available to the expansion module is well > > defined. The main causes to have external references are interrupts > > and gpios. Interrupts we handle by defining an interrupt specifier > > space for the interrupts available on the expansion > > socket/connector/bus/whatever. In the master tree we then have > > something like: > > > > ... > > expansion-socket@XXXX { > > expansion-id = "SlotA"; > > interrupt-map = < /* map expansion irq specs to > > board interrupt controllers */ >; > > interrupt-map-mask = < ... >; > > ranges = < /* map expansion local addresses to global > > mmio */ >; > > }; > > > > The subtree for the expansion module gets attached as a subnode of > > this one. It doesn't use explicit interrupt-parents but instead just > > uses the expansion local irq specifiers, letting the parent be the > > default which will bubble up to this socket node where the > > interrupt-map will send them to the right places. > > > > I don't recall the gpio bindings off hand, but as I recall we based > > them off the irq tree bindings so we ought to be able to do the same > > thing for them. > > > > Likewise, if there are several interchangeable expansion sockets that > > have some address bits hard wired to distinguish them, we can just use > > socket local mmio addresses within the subtree and the ranges property > > here will sort that out. > > If I'm reading correctly, the suggestion is that everything be grafted > below a single node and all connections route through that node using > mapping. Correct? > > For interrupts that works today > For gpios, it isn't currently supported, but we could do it. > For SPI it would mean that the new spi devices would not appear below > the actual spi bus they are attached to > For I2C, MDIO, and one wire, same problem. > For memory mapped devices, the expansion node would need to a ranges > for all the windows that map through it, and it assumes only one > memory mapped bus (or at least it prefers only one memory mapped bus. > If there were more than one then the expansion node placement wouldn't > have a natural place to sit) > > The problem is that this is not like a PCI bus where there is only one > kind of interface. It is a whole bunch of interfaces that happen to be > grouped together loosely (as an expansion connector in the beaglebone > case, but expansion isn't the only problem that I'm hearing about). > > So, with a group of i2c, spi, memory mapped and other devices than are > all plugged in together, how does that look? They really should not > sit on the same level. An spi device cannot be a peer of an i2c device > for instance, the address mapping is entirely different. The kernel > really wants i2c devices to be a child of the actual i2c bus which may > already have an i2c device or too on the main board. Does the > expansion node need to have some kind of redirect node for each of the > busses where the children of it need to create devices as children of > the master bus? > > To me that seems to get really complex in a hurry. More complex than > the overlay approach. Ah, yes, I see. Yeah, that's a genuine showstopper for my original proposal. Ok, let me offer a couple of counter-proposals: 1) bus-ranges The notion of bus-reg and bus-ranges properties is something I've toyed with before for other reasons, as a way of augmenting the "normal" DT tree structure with interrupt-tree like DAG sections. bus-reg and bus-ranges would act like the normal reg and ranges properties except that each entry includes a phandle explicitly giving the parent bus. In that case a suitable 'bus-ranges' in the socket node would resurrect my graft proposal. I'm not particularly sold on this idea, but I mention it because it has applications other than this one. In particular it would mean we could avoid having two different nodes for a device which is mostly accessed via MMIO but also has a few sideband registers controlled by i2c (or whatever). 2) graft bundle The base tree has something like this: ... i2c@XXX { ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "i2c"; ranges = < ... >; }; }; ... spi@YYY { ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "spi"; ranges = < ... >; }; }; ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "misc"; interrupt-map = < ... >; interrupt-map-mask = < ... >; gpio-map = < ... >; gpio-map-mask = < ... >; }; Then instead of grafting a single subtree for the socket, we install a "bundle" of subtrees, one each for each of the pieces within the socket. That bundle could either be an actual set of multiple fdts, or they could be placed into one fdt with a dummy root node, something like: / { plugin-bundle; compatible = "vendor,cape-plugin"; version = ...; i2c-piece = { piece-id = "i2c"; ... }; misc-piece = { piece-id = "misc"; ... }; }; That does have the additional advantage of letting us easily expand the metadata in the future by adding more properties to the dummy root node. It's a bit more complex than the overlay proposal, but I think it's safer - because the base tree clearly defines where it can be extended. Plus it has the big advantage that it's no longer dependent on the exact node paths in the base tree, the matching for each component is done by the piece-id or other metadata. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 1:05 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 1:05 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:26 AM, David Gibson > <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote: > > (3) Resolving phandle references from the subtree to the main tree. > > > > So, I think this can actually be avoided, at least in cases where what > > physical connections are available to the expansion module is well > > defined. The main causes to have external references are interrupts > > and gpios. Interrupts we handle by defining an interrupt specifier > > space for the interrupts available on the expansion > > socket/connector/bus/whatever. In the master tree we then have > > something like: > > > > ... > > expansion-socket@XXXX { > > expansion-id = "SlotA"; > > interrupt-map = < /* map expansion irq specs to > > board interrupt controllers */ >; > > interrupt-map-mask = < ... >; > > ranges = < /* map expansion local addresses to global > > mmio */ >; > > }; > > > > The subtree for the expansion module gets attached as a subnode of > > this one. It doesn't use explicit interrupt-parents but instead just > > uses the expansion local irq specifiers, letting the parent be the > > default which will bubble up to this socket node where the > > interrupt-map will send them to the right places. > > > > I don't recall the gpio bindings off hand, but as I recall we based > > them off the irq tree bindings so we ought to be able to do the same > > thing for them. > > > > Likewise, if there are several interchangeable expansion sockets that > > have some address bits hard wired to distinguish them, we can just use > > socket local mmio addresses within the subtree and the ranges property > > here will sort that out. > > If I'm reading correctly, the suggestion is that everything be grafted > below a single node and all connections route through that node using > mapping. Correct? > > For interrupts that works today > For gpios, it isn't currently supported, but we could do it. > For SPI it would mean that the new spi devices would not appear below > the actual spi bus they are attached to > For I2C, MDIO, and one wire, same problem. > For memory mapped devices, the expansion node would need to a ranges > for all the windows that map through it, and it assumes only one > memory mapped bus (or at least it prefers only one memory mapped bus. > If there were more than one then the expansion node placement wouldn't > have a natural place to sit) > > The problem is that this is not like a PCI bus where there is only one > kind of interface. It is a whole bunch of interfaces that happen to be > grouped together loosely (as an expansion connector in the beaglebone > case, but expansion isn't the only problem that I'm hearing about). > > So, with a group of i2c, spi, memory mapped and other devices than are > all plugged in together, how does that look? They really should not > sit on the same level. An spi device cannot be a peer of an i2c device > for instance, the address mapping is entirely different. The kernel > really wants i2c devices to be a child of the actual i2c bus which may > already have an i2c device or too on the main board. Does the > expansion node need to have some kind of redirect node for each of the > busses where the children of it need to create devices as children of > the master bus? > > To me that seems to get really complex in a hurry. More complex than > the overlay approach. Ah, yes, I see. Yeah, that's a genuine showstopper for my original proposal. Ok, let me offer a couple of counter-proposals: 1) bus-ranges The notion of bus-reg and bus-ranges properties is something I've toyed with before for other reasons, as a way of augmenting the "normal" DT tree structure with interrupt-tree like DAG sections. bus-reg and bus-ranges would act like the normal reg and ranges properties except that each entry includes a phandle explicitly giving the parent bus. In that case a suitable 'bus-ranges' in the socket node would resurrect my graft proposal. I'm not particularly sold on this idea, but I mention it because it has applications other than this one. In particular it would mean we could avoid having two different nodes for a device which is mostly accessed via MMIO but also has a few sideband registers controlled by i2c (or whatever). 2) graft bundle The base tree has something like this: ... i2c@XXX { ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "i2c"; ranges = < ... >; }; }; ... spi@YYY { ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "spi"; ranges = < ... >; }; }; ... cape-socket { compatible = "vendor,cape-socket"; id = "Socket-A"; piece-id = "misc"; interrupt-map = < ... >; interrupt-map-mask = < ... >; gpio-map = < ... >; gpio-map-mask = < ... >; }; Then instead of grafting a single subtree for the socket, we install a "bundle" of subtrees, one each for each of the pieces within the socket. That bundle could either be an actual set of multiple fdts, or they could be placed into one fdt with a dummy root node, something like: / { plugin-bundle; compatible = "vendor,cape-plugin"; version = ...; i2c-piece = { piece-id = "i2c"; ... }; misc-piece = { piece-id = "misc"; ... }; }; That does have the additional advantage of letting us easily expand the metadata in the future by adding more properties to the dummy root node. It's a bit more complex than the overlay proposal, but I think it's safer - because the base tree clearly defines where it can be extended. Plus it has the big advantage that it's no longer dependent on the exact node paths in the base tree, the matching for each component is done by the piece-id or other metadata. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-13 1:05 ` David Gibson (?) @ 2012-11-13 5:22 ` Stephen Warren 2012-11-13 6:54 ` David Gibson -1 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-13 5:22 UTC (permalink / raw) To: David Gibson Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/12/2012 06:05 PM, David Gibson wrote: > On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote: ... > 2) graft bundle > > The base tree has something like this: > > ... > i2c@XXX { > ... > cape-socket { > compatible = "vendor,cape-socket"; > id = "Socket-A"; > piece-id = "i2c"; > ranges = < ... >; > }; > }; > ... > spi@YYY { > ... > cape-socket { > compatible = "vendor,cape-socket"; > id = "Socket-A"; > piece-id = "spi"; > ranges = < ... >; > }; > }; > ... > cape-socket { > compatible = "vendor,cape-socket"; > id = "Socket-A"; > piece-id = "misc"; > interrupt-map = < ... >; > interrupt-map-mask = < ... >; > gpio-map = < ... >; > gpio-map-mask = < ... >; > }; > > Then instead of grafting a single subtree for the socket, we install a > "bundle" of subtrees, one each for each of the pieces within the > socket. That bundle could either be an actual set of multiple fdts, > or they could be placed into one fdt with a dummy root node, something like: > > / { > plugin-bundle; > compatible = "vendor,cape-plugin"; > version = ...; > i2c-piece = { > piece-id = "i2c"; > ... > }; > misc-piece = { > piece-id = "misc"; > ... > }; > }; I do like this approach; it's the kind of thing I proposed at: > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html One question though: Perhaps the base board has two instances of the same type of connector vendor,cape-socket, allowing 2 independent capes to be plugged in. When overlaying/grafting the child board's .dts, we'd need some way to specify the socket ID that was being plugged into. Is that the intent of the "id" property in your base board example above? ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 6:54 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 6:54 UTC (permalink / raw) To: Stephen Warren Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Mon, Nov 12, 2012 at 10:22:07PM -0700, Stephen Warren wrote: > On 11/12/2012 06:05 PM, David Gibson wrote: > > On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote: > ... > > 2) graft bundle > > > > The base tree has something like this: > > > > ... > > i2c@XXX { > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "i2c"; > > ranges = < ... >; > > }; > > }; > > ... > > spi@YYY { > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "spi"; > > ranges = < ... >; > > }; > > }; > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "misc"; > > interrupt-map = < ... >; > > interrupt-map-mask = < ... >; > > gpio-map = < ... >; > > gpio-map-mask = < ... >; > > }; > > > > Then instead of grafting a single subtree for the socket, we install a > > "bundle" of subtrees, one each for each of the pieces within the > > socket. That bundle could either be an actual set of multiple fdts, > > or they could be placed into one fdt with a dummy root node, something like: > > > > / { > > plugin-bundle; > > compatible = "vendor,cape-plugin"; > > version = ...; > > i2c-piece = { > > piece-id = "i2c"; > > ... > > }; > > misc-piece = { > > piece-id = "misc"; > > ... > > }; > > }; > > I do like this approach; it's the kind of thing I proposed at: > > > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html Roughly, yes, though a little streamlined from the syntax suggested there. > One question though: Perhaps the base board has two instances of the > same type of connector vendor,cape-socket, allowing 2 independent capes > to be plugged in. When overlaying/grafting the child board's .dts, we'd > need some way to specify the socket ID that was being plugged into. Is > that the intent of the "id" property in your base board example above? Yes, that's exactly what I had in mind for the "id" property. Property names and other details entirely negotiable at this stage, of course. By the by, I think having multiple interchangable sockets could break the convention based approach for avoiding collisions between phandles I suggested, but another mail with some better thoughts on that shortly to be posted. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-13 6:54 ` David Gibson 0 siblings, 0 replies; 135+ messages in thread From: David Gibson @ 2012-11-13 6:54 UTC (permalink / raw) To: Stephen Warren Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On Mon, Nov 12, 2012 at 10:22:07PM -0700, Stephen Warren wrote: > On 11/12/2012 06:05 PM, David Gibson wrote: > > On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote: > ... > > 2) graft bundle > > > > The base tree has something like this: > > > > ... > > i2c@XXX { > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "i2c"; > > ranges = < ... >; > > }; > > }; > > ... > > spi@YYY { > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "spi"; > > ranges = < ... >; > > }; > > }; > > ... > > cape-socket { > > compatible = "vendor,cape-socket"; > > id = "Socket-A"; > > piece-id = "misc"; > > interrupt-map = < ... >; > > interrupt-map-mask = < ... >; > > gpio-map = < ... >; > > gpio-map-mask = < ... >; > > }; > > > > Then instead of grafting a single subtree for the socket, we install a > > "bundle" of subtrees, one each for each of the pieces within the > > socket. That bundle could either be an actual set of multiple fdts, > > or they could be placed into one fdt with a dummy root node, something like: > > > > / { > > plugin-bundle; > > compatible = "vendor,cape-plugin"; > > version = ...; > > i2c-piece = { > > piece-id = "i2c"; > > ... > > }; > > misc-piece = { > > piece-id = "misc"; > > ... > > }; > > }; > > I do like this approach; it's the kind of thing I proposed at: > > > http://www.mail-archive.com/devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org/msg20414.html Roughly, yes, though a little streamlined from the syntax suggested there. > One question though: Perhaps the base board has two instances of the > same type of connector vendor,cape-socket, allowing 2 independent capes > to be plugged in. When overlaying/grafting the child board's .dts, we'd > need some way to specify the socket ID that was being plugged into. Is > that the intent of the "id" property in your base board example above? Yes, that's exactly what I had in mind for the "id" property. Property names and other details entirely negotiable at this stage, of course. By the by, I think having multiple interchangable sockets could break the convention based approach for avoiding collisions between phandles I suggested, but another mail with some better thoughts on that shortly to be posted. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 2:26 ` David Gibson ` (2 preceding siblings ...) 2012-11-09 21:42 ` Grant Likely @ 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 4 siblings, 2 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-09 22:57 UTC (permalink / raw) To: David Gibson Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/08/2012 07:26 PM, David Gibson wrote: ... > I also think graft will handle most of your use cases, although as I > said I don't fully understand the implications of some of them, so I > could be wrong. So, the actual insertion of the subtree is pretty > trivial to implement. phandles are the obvious other matter to be > dealt with. I haven't found the right thread where what you've > envisaged so far is discussed, so here are things I can see: > > 1) Avoiding phandle collisions between main tree and subtree (or > between subtrees). > > I'm hopeful that this can be resolved just by establishing some > conventions about the ranges of phandles to be used for various > components. I'd certainly be happy to add a directive to dtc which > enforces allocation of phandles within a specified range. One case I wonder about is: Base board A that's split into two .dts files e.g. due to there being two versions of the base board which are 90% identical, yet there being a few differences between them. Base board B that's just a single .dts file. We might allocate phandle range 0..999 for the base board. Child board X plugs into either, so the two base boards need to "export" the same set of phandle IDs to the child board to allow it to reference them. If base board A version 2 comes along after the phandle IDs that the child board uses are defined, then how do we handle assigning a specific phandle ID range to each of base board A's two version-specific overlays, when the version-specific changes might affect arbitrary phandle IDs within the range, and require some to be moved into the base board version-specific overlays and some to stay in the common base board .dts? > 2) Resolving phandle references within a subtree > > If we can handle (1) by convention, we don't need anything here, the > references are fine as is. > > (3) Resolving phandle references from the subtree to the main tree. > > So, I think this can actually be avoided, at least in cases where what > physical connections are available to the expansion module is well > defined. The main causes to have external references are interrupts > and gpios. Interrupts we handle by defining an interrupt specifier > space for the interrupts available on the expansion > socket/connector/bus/whatever. In the master tree we then have > something like: > > ... > expansion-socket@XXXX { > expansion-id = "SlotA"; > interrupt-map = < /* map expansion irq specs to > board interrupt controllers */ >; > interrupt-map-mask = < ... >; > ranges = < /* map expansion local addresses to global > mmio */ >; > }; We would end up needing an interrupt-map or ranges type of property for basically any resource type. For example, what about an I2C bus that's routed to the daughter board, and the daughter board contains an I2C bus mux, whose control path isn't through I2C but rather GPIOs? In this case, the I2C bus mux isn't a child of the I2C bus, but a separate entity that indicates its parent I2C bus using a phandle. I presume a similar argument applies to almost any kind of resource. This is probably do-able, but certainly something to consider with the socket approach. I do like the socket approach though. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 22:57 ` Stephen Warren @ 2012-11-09 23:27 ` Grant Likely 2012-11-12 12:05 ` Pantelis Antoniou 1 sibling, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 23:27 UTC (permalink / raw) To: Stephen Warren Cc: David Gibson, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 10:57 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/08/2012 07:26 PM, David Gibson wrote: > ... >> I also think graft will handle most of your use cases, although as I >> said I don't fully understand the implications of some of them, so I >> could be wrong. So, the actual insertion of the subtree is pretty >> trivial to implement. phandles are the obvious other matter to be >> dealt with. I haven't found the right thread where what you've >> envisaged so far is discussed, so here are things I can see: >> >> 1) Avoiding phandle collisions between main tree and subtree (or >> between subtrees). >> >> I'm hopeful that this can be resolved just by establishing some >> conventions about the ranges of phandles to be used for various >> components. I'd certainly be happy to add a directive to dtc which >> enforces allocation of phandles within a specified range. > > One case I wonder about is: > > Base board A that's split into two .dts files e.g. due to there being > two versions of the base board which are 90% identical, yet there being > a few differences between them. > > Base board B that's just a single .dts file. > > We might allocate phandle range 0..999 for the base board. > > Child board X plugs into either, so the two base boards need to "export" > the same set of phandle IDs to the child board to allow it to reference > them. It's more than just that. The boards really need to be equivalent since the irq specifiers and gpio specifiers need to match the gpio and irq controllers provided by the board. So a simple overlay design won't cover the case of a single file that will work generically on any board. > If base board A version 2 comes along after the phandle IDs that the > child board uses are defined, then how do we handle assigning a specific > phandle ID range to each of base board A's two version-specific > overlays, when the version-specific changes might affect arbitrary > phandle IDs within the range, and require some to be moved into the base > board version-specific overlays and some to stay in the common base > board .dts? With the design I'm currently considering, at the dts level the overlay could be compiled against any base boards if the specifiers are equivalent and the labels match up as indicated above. The compiled dtb could also be somewhat portable, but only if care is taken to make sure the phandles match too; possibly by explicitly specifying them instead of letting them be generated by a hash. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 22:57 ` Stephen Warren 2012-11-09 23:27 ` Grant Likely @ 2012-11-12 12:05 ` Pantelis Antoniou 1 sibling, 0 replies; 135+ messages in thread From: Pantelis Antoniou @ 2012-11-12 12:05 UTC (permalink / raw) To: Stephen Warren Cc: David Gibson, Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss Hi Stephen, On Nov 10, 2012, at 12:57 AM, Stephen Warren wrote: > On 11/08/2012 07:26 PM, David Gibson wrote: > ... >> I also think graft will handle most of your use cases, although as I >> said I don't fully understand the implications of some of them, so I >> could be wrong. So, the actual insertion of the subtree is pretty >> trivial to implement. phandles are the obvious other matter to be >> dealt with. I haven't found the right thread where what you've >> envisaged so far is discussed, so here are things I can see: >> >> 1) Avoiding phandle collisions between main tree and subtree (or >> between subtrees). >> >> I'm hopeful that this can be resolved just by establishing some >> conventions about the ranges of phandles to be used for various >> components. I'd certainly be happy to add a directive to dtc which >> enforces allocation of phandles within a specified range. > > One case I wonder about is: > > Base board A that's split into two .dts files e.g. due to there being > two versions of the base board which are 90% identical, yet there being > a few differences between them. > > Base board B that's just a single .dts file. > > We might allocate phandle range 0..999 for the base board. > > Child board X plugs into either, so the two base boards need to "export" > the same set of phandle IDs to the child board to allow it to reference > them. > > If base board A version 2 comes along after the phandle IDs that the > child board uses are defined, then how do we handle assigning a specific > phandle ID range to each of base board A's two version-specific > overlays, when the version-specific changes might affect arbitrary > phandle IDs within the range, and require some to be moved into the base > board version-specific overlays and some to stay in the common base > board .dts? > Static phandle allocation, could work, but not without considerable trouble. Maybe we're over-engineering things. Perhaps having the kernel use the phandle values generated by dtc is not required. What about the following simple scheme: 1) Have dtc create local phandle values the same way, as it is today. Generate the flat tree normally, but keep in a table the locations of all phandle references. Keep track of non resolvable phandle references in a different table. One could use the fixup mechanism I described in a previous email, if you don't care about keeping a big table. 2) Upon loading the base DT or the overlay, the kernel makes sure the phandles don't overlap; simply add a per DT fragment constant offset. 3) Resolve phandle references that were unresolved at compile time. >> 2) Resolving phandle references within a subtree >> >> If we can handle (1) by convention, we don't need anything here, the >> references are fine as is. >> >> (3) Resolving phandle references from the subtree to the main tree. >> >> So, I think this can actually be avoided, at least in cases where what >> physical connections are available to the expansion module is well >> defined. The main causes to have external references are interrupts >> and gpios. Interrupts we handle by defining an interrupt specifier >> space for the interrupts available on the expansion >> socket/connector/bus/whatever. In the master tree we then have >> something like: >> >> ... >> expansion-socket@XXXX { >> expansion-id = "SlotA"; >> interrupt-map = < /* map expansion irq specs to >> board interrupt controllers */ >; >> interrupt-map-mask = < ... >; >> ranges = < /* map expansion local addresses to global >> mmio */ >; >> }; > > We would end up needing an interrupt-map or ranges type of property for > basically any resource type. > > For example, what about an I2C bus that's routed to the daughter board, > and the daughter board contains an I2C bus mux, whose control path isn't > through I2C but rather GPIOs? In this case, the I2C bus mux isn't a > child of the I2C bus, but a separate entity that indicates its parent > I2C bus using a phandle. I presume a similar argument applies to almost > any kind of resource. This is probably do-able, but certainly something > to consider with the socket approach. I do like the socket approach though. Capebus has taken this approach. You see, perhaps from the standpoint of the standard platform devices that a cape provides, a bus is not a very fitting construct. But from a hardware engineer/user perspective, a cape is an expansion board, and virtual slots are used. This is similar to what you're saying with socket approach, right? Regards -- Pantelis ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-09 23:14 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-09 23:14 UTC (permalink / raw) To: David Gibson Cc: Grant Likely, Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap, devicetree-discuss On 11/08/2012 07:26 PM, David Gibson wrote: ... > So, let me take a stab at this from a more bottom-up approach, and see > if we meet in the middle somewhere. As I discussed in the other > thread with Daniel Mack, I can see two different operationso on the > fdt that might be useful in this context. I think of them as "graft" > - which takes one fdt and adds it as a new subtree to an existing fdt > - and "overlay" where a new fdt adds or overrides arbitrary properties > in an existing tree. Overlay is more or less what we do at the source > level in dtc already. One more thought on the differences between overlay and grafting: With overlay, it's possible to make your overlay a complete DT tree rooted at /. In some cases, you might find a lower-level node which all overlaid elements share, and root the overlay process there. With grafting, you're basically guaranteed to want the child/graft file to have different parts of itself grafted into different points in the parent/underlying tree, e.g. to add nodes to an I2C bus, an SPI bus, and perhaps some bus-less devices at the root (e.g. a new gpio-leds device). This will require that a child/graft file to consist of multiple chunks of DT all to be grafted as separate operations, whereas with overlay you may be able to get away with a single chunk to be overlaid (although with some of the use-cases discussed, even the overlay approach might require multiple chunks to be applied). ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-09 23:14 ` Stephen Warren 0 siblings, 0 replies; 135+ messages in thread From: Stephen Warren @ 2012-11-09 23:14 UTC (permalink / raw) To: David Gibson Cc: Kevin Hilman, Matt Porter, Koen Kooi, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Russ Dill, Scott Wood, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ On 11/08/2012 07:26 PM, David Gibson wrote: ... > So, let me take a stab at this from a more bottom-up approach, and see > if we meet in the middle somewhere. As I discussed in the other > thread with Daniel Mack, I can see two different operationso on the > fdt that might be useful in this context. I think of them as "graft" > - which takes one fdt and adds it as a new subtree to an existing fdt > - and "overlay" where a new fdt adds or overrides arbitrary properties > in an existing tree. Overlay is more or less what we do at the source > level in dtc already. One more thought on the differences between overlay and grafting: With overlay, it's possible to make your overlay a complete DT tree rooted at /. In some cases, you might find a lower-level node which all overlaid elements share, and root the overlay process there. With grafting, you're basically guaranteed to want the child/graft file to have different parts of itself grafted into different points in the parent/underlying tree, e.g. to add nodes to an I2C bus, an SPI bus, and perhaps some bus-less devices at the root (e.g. a new gpio-leds device). This will require that a child/graft file to consist of multiple chunks of DT all to be grafted as separate operations, whereas with overlay you may be able to get away with a single chunk to be overlaid (although with some of the use-cases discussed, even the overlay approach might require multiple chunks to be applied). ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-05 20:40 [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Grant Likely ` (3 preceding siblings ...) 2012-11-09 2:26 ` David Gibson @ 2012-11-09 23:06 ` Stephen Warren 2012-11-09 23:32 ` Grant Likely 2012-11-12 11:03 ` Koen Kooi 5 siblings, 1 reply; 135+ messages in thread From: Stephen Warren @ 2012-11-09 23:06 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On 11/05/2012 01:40 PM, Grant Likely wrote: > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. Here's one other requirement I'd like that I don't think I saw explicitly mentioned in your document: Assuming a base file board.dts and a child board file child.dts, the compiled file child.dtb should be usable with a modified board.dtb assuming it exports the same set of attachment-points (hashed phandles, socket objects, whatever). This allows bug-fixes etc. to board.dts without forcing every child.dts to be recompiled. If the attachment points is hashed node names or node content from board.dts, I'm not sure how this is possible? I suppose this is implicit if child.dtb can be used with either board-a.dtb and board-b.dtb though. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) 2012-11-09 23:06 ` Stephen Warren @ 2012-11-09 23:32 ` Grant Likely 0 siblings, 0 replies; 135+ messages in thread From: Grant Likely @ 2012-11-09 23:32 UTC (permalink / raw) To: Stephen Warren Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Kevin Hilman, Matt Porter, Koen Kooi, linux-kernel, Felipe Balbi, Russ Dill, linux-omap, devicetree-discuss On Fri, Nov 9, 2012 at 11:06 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Here's one other requirement I'd like that I don't think I saw > explicitly mentioned in your document: > > Assuming a base file board.dts and a child board file child.dts, the > compiled file child.dtb should be usable with a modified board.dtb > assuming it exports the same set of attachment-points (hashed phandles, > socket objects, whatever). This allows bug-fixes etc. to board.dts > without forcing every child.dts to be recompiled. No, I hadn't explicitly captured that one, but yes it is the intent. > If the attachment points is hashed node names or node content from > board.dts, I'm not sure how this is possible? Ummm, I think there is misunderstanding about the hashed phandles. My thought is merely that using a hash to generate a phandle is 'better' than starting at 1 and counting upwards when dtc compiles the tree. That way, if the path to the node has not changed, then the phandle will not have changed. However, phandles can still be explicitly specified if slightly different trees need to have the same target point. That said, if portability of dtb files is a strong requirement, then it will be difficult to do with simple overlays. Even if the phandles line up, the irq/gpio specifiers probably need to be different. That makes things harder. g. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 11:03 ` Koen Kooi 0 siblings, 0 replies; 135+ messages in thread From: Koen Kooi @ 2012-11-12 11:03 UTC (permalink / raw) To: Grant Likely Cc: Pantelis Antoniou, Rob Herring, Deepak Saxena, Benjamin Herrenschmidt, Scott Wood, Tony Lindgren, Russ Dill, Felipe Balbi, Benoit Cousson, linux-kernel, Matt Porter, linux-omap, Kevin Hilman, Paul Walmsley, devicetree-discuss Op 5 nov. 2012, om 21:40 heeft Grant Likely <grant.likely@secretlab.ca> het volgende geschreven: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. > > Device Tree Overlay Feature > > Purpose > ======= > Sometimes it is not convenient to describe an entire system with a > single FDT. For example, processor modules that are plugged into one or > more modules (a la the BeagleBone), or systems with an FPGA peripheral > that is programmed after the system is booted. > > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at > runtime by loading additional overlay FDTs that amend the original data. > > User Stories > ============ > Note - These are potential use cases, but just because it is listed here > doesn't mean it is important. I just want to thoroughly think through the > implications before making design decisions. I think the beaglebone use cases cover it as well, but it deserves a seperate mention: SOMs. Gumstix is a good example of those, their website has a list of the different expansionboards they sell so we can see if we missed a use case somewhere. Their expansionboards have an EEPROM to ID them, just like the beagleboard classic/xM expansionboards, but I don't know if all 3rd party vendors honour that standard. I know the Ettus USRP E-100 on my desk has it. regards, Koen ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) @ 2012-11-12 11:03 ` Koen Kooi 0 siblings, 0 replies; 135+ messages in thread From: Koen Kooi @ 2012-11-12 11:03 UTC (permalink / raw) To: Grant Likely Cc: Kevin Hilman, Matt Porter, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Pantelis Antoniou, linux-kernel, Felipe Balbi, Deepak Saxena, Scott Wood, Russ Dill, linux-omap-u79uwXL29TY76Z2rM5mHXA Op 5 nov. 2012, om 21:40 heeft Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> het volgende geschreven: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. > > Device Tree Overlay Feature > > Purpose > ======= > Sometimes it is not convenient to describe an entire system with a > single FDT. For example, processor modules that are plugged into one or > more modules (a la the BeagleBone), or systems with an FPGA peripheral > that is programmed after the system is booted. > > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at > runtime by loading additional overlay FDTs that amend the original data. > > User Stories > ============ > Note - These are potential use cases, but just because it is listed here > doesn't mean it is important. I just want to thoroughly think through the > implications before making design decisions. I think the beaglebone use cases cover it as well, but it deserves a seperate mention: SOMs. Gumstix is a good example of those, their website has a list of the different expansionboards they sell so we can see if we missed a use case somewhere. Their expansionboards have an EEPROM to ID them, just like the beagleboard classic/xM expansionboards, but I don't know if all 3rd party vendors honour that standard. I know the Ettus USRP E-100 on my desk has it. regards, Koen ^ permalink raw reply [flat|nested] 135+ messages in thread
end of thread, other threads:[~2012-11-20 17:09 UTC | newest] Thread overview: 135+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.