From: Frank Rowand <frowand.list@gmail.com> To: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: mark.rutland@arm.com, Rob Herring <robh@kernel.org>, devicetree@vger.kernel.org, Tony Lindgren <tony@atomide.com>, Tero Kristo <t-kristo@ti.com>, trini@konsulko.com, wmills@ti.com, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Date: Tue, 29 May 2018 15:45:12 -0700 [thread overview] Message-ID: <a43ce521-ed7f-6126-4ebf-5e0e303d00a3@gmail.com> (raw) In-Reply-To: <20180529173314.GN17671@n2100.armlinux.org.uk> On 05/29/18 10:33, Russell King - ARM Linux wrote: > On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote: >> On 05/22/18 13:01, Rob Herring wrote: >>> I'll tell you up front, I'm not a fan of FIT image (nor uImage, >>> Android boot image, $bootloader image). If you want a collection of >>> files and some configuration data, use a filesystem and a text file. > > Me neither. > >> My gut feel is that using a filesystem and a text file is the easier way >> to create the boot info. But that also makes applying the overlay(s) >> during early Linux boot (at the point of FDT unflattening) impractical >> (can't access the file system without a driver, the driver depends on >> the devicetree, the devicetree depends upon the overlay). > > Why do you want to apply overlays during the kernel boot? The boot > loader should be providing the kernel with the merged DT to describe > the system that the kernel is running on - it's not the kernel's > job to put that together. I would much prefer that overlays get applied before the unflattened devicetree is made available to the kernel instead of applying overlays late in the boot (after many susbsystems and drivers are initialized) or after boot. If overlays are applied before the unflattened devicetree is made available to the kernel then subsystems and drivers do not have to be aware of the possibility of the data in the devicetree changing instead of being invariant. (I will call this "apply early overlays" later in this email.) There are use cases of overlays where the overlay is not available until late in the boot, or after the boot completes. I am not suggesting that those use cases be ignored. That is a completely different conversation. If overlays are applied before the unflattened devicetree is made available to the kernel, there are at least two obvious methods (and I can think of at least one more) -- either the kernel does it or the bootloader does it. I do not see either of the two as being the obvious and only correct choice. If the kernel does it, then there is no need for multiple bootloaders to implement the same code. If the bootloaders do it, then there is no need for multiple kernels (Linux, BSD, etc) to implement the same code. I do not have a strong opinion about whether the bootloaders or the kernels are a better place to apply early overlays. > The whole point of DT is to make the kernel _less_ tied to the hardware > and more generic. If we're going to introduce an entirely new set of > drivers into the kernel to "probe" the hardware to determine which > overlays are required, then that's really defeating the purpose of DT. If you read my circular dependency sentence carefully, I said a kernel driver is impractical for the task of getting the overlay. So I agree. If the kernel applies the overlay, an alternative to drivers is that the kernel could receive the overlay(s) in a similar manner as the method it currently receives the base devicetree. (The overlay(s) could be appended to the base devicetree, a wrapper could be placed around the base devicetree and the overlay(s), or some other implementation. There are multiple ways to achieve the same result.)
WARNING: multiple messages have this Message-ID (diff)
From: frowand.list@gmail.com (Frank Rowand) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Date: Tue, 29 May 2018 15:45:12 -0700 [thread overview] Message-ID: <a43ce521-ed7f-6126-4ebf-5e0e303d00a3@gmail.com> (raw) In-Reply-To: <20180529173314.GN17671@n2100.armlinux.org.uk> On 05/29/18 10:33, Russell King - ARM Linux wrote: > On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote: >> On 05/22/18 13:01, Rob Herring wrote: >>> I'll tell you up front, I'm not a fan of FIT image (nor uImage, >>> Android boot image, $bootloader image). If you want a collection of >>> files and some configuration data, use a filesystem and a text file. > > Me neither. > >> My gut feel is that using a filesystem and a text file is the easier way >> to create the boot info. But that also makes applying the overlay(s) >> during early Linux boot (at the point of FDT unflattening) impractical >> (can't access the file system without a driver, the driver depends on >> the devicetree, the devicetree depends upon the overlay). > > Why do you want to apply overlays during the kernel boot? The boot > loader should be providing the kernel with the merged DT to describe > the system that the kernel is running on - it's not the kernel's > job to put that together. I would much prefer that overlays get applied before the unflattened devicetree is made available to the kernel instead of applying overlays late in the boot (after many susbsystems and drivers are initialized) or after boot. If overlays are applied before the unflattened devicetree is made available to the kernel then subsystems and drivers do not have to be aware of the possibility of the data in the devicetree changing instead of being invariant. (I will call this "apply early overlays" later in this email.) There are use cases of overlays where the overlay is not available until late in the boot, or after the boot completes. I am not suggesting that those use cases be ignored. That is a completely different conversation. If overlays are applied before the unflattened devicetree is made available to the kernel, there are at least two obvious methods (and I can think of at least one more) -- either the kernel does it or the bootloader does it. I do not see either of the two as being the obvious and only correct choice. If the kernel does it, then there is no need for multiple bootloaders to implement the same code. If the bootloaders do it, then there is no need for multiple kernels (Linux, BSD, etc) to implement the same code. I do not have a strong opinion about whether the bootloaders or the kernels are a better place to apply early overlays. > The whole point of DT is to make the kernel _less_ tied to the hardware > and more generic. If we're going to introduce an entirely new set of > drivers into the kernel to "probe" the hardware to determine which > overlays are required, then that's really defeating the purpose of DT. If you read my circular dependency sentence carefully, I said a kernel driver is impractical for the task of getting the overlay. So I agree. If the kernel applies the overlay, an alternative to drivers is that the kernel could receive the overlay(s) in a similar manner as the method it currently receives the base devicetree. (The overlay(s) could be appended to the base devicetree, a wrapper could be placed around the base devicetree and the overlay(s), or some other implementation. There are multiple ways to achieve the same result.)
next prev parent reply other threads:[~2018-05-29 22:45 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-17 9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo 2018-04-17 9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo 2018-04-19 0:02 ` Rob Herring 2018-04-17 9:10 ` [RFC 02/13] ARM: dts: add support for building DT overlays Tero Kristo 2018-04-17 9:10 ` [RFC 03/13] ARM: dts: add subdir for TI SoC DT files Tero Kristo 2018-04-17 9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo 2018-04-18 14:16 ` Geert Uytterhoeven 2018-04-17 9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo 2018-04-18 14:20 ` Geert Uytterhoeven 2018-04-18 19:07 ` Tero Kristo 2018-04-18 22:43 ` Rob Herring 2018-04-19 6:36 ` Tero Kristo 2018-04-19 15:26 ` Rob Herring 2018-04-19 18:00 ` Tero Kristo 2018-04-17 9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo 2018-04-18 14:36 ` Geert Uytterhoeven 2018-04-18 19:12 ` Tero Kristo 2018-04-18 19:15 ` Russell King 2018-04-20 13:27 ` Geert Uytterhoeven 2018-04-18 22:40 ` Rob Herring 2018-04-19 0:19 ` Rob Herring 2018-04-19 6:49 ` Tero Kristo 2018-04-20 1:31 ` Rob Herring 2018-04-17 9:10 ` [RFC 07/13] ARM: dts: ti: add camera overlays Tero Kristo 2018-04-17 9:10 ` [RFC 08/13] ARM: dts: ti: add dra71-evm overlays Tero Kristo 2018-04-17 9:10 ` [RFC 09/13] kbuild: add support for generating FIT images Tero Kristo 2018-04-17 9:10 ` [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture Tero Kristo 2018-04-17 9:10 ` [RFC 11/13] ARM: dts: ti: add FIT image dependencies Tero Kristo 2018-04-17 9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo 2018-04-17 9:29 ` Russell King 2018-04-17 9:34 ` Tero Kristo 2018-04-17 14:49 ` Tony Lindgren 2018-05-21 6:57 ` Tero Kristo 2018-05-21 6:57 ` Tero Kristo 2018-05-22 20:01 ` Rob Herring 2018-05-22 20:01 ` Rob Herring 2018-05-23 5:55 ` Tero Kristo 2018-05-23 5:55 ` Tero Kristo 2018-05-23 14:13 ` Rob Herring 2018-05-23 14:13 ` Rob Herring 2018-05-23 18:37 ` Tony Lindgren 2018-05-23 18:37 ` Tony Lindgren 2018-05-29 17:05 ` Frank Rowand 2018-05-29 17:05 ` Frank Rowand 2018-05-29 17:33 ` Russell King - ARM Linux 2018-05-29 17:33 ` Russell King - ARM Linux 2018-05-29 22:45 ` Frank Rowand [this message] 2018-05-29 22:45 ` Frank Rowand 2018-05-29 22:51 ` Russell King - ARM Linux 2018-05-29 22:51 ` Russell King - ARM Linux 2018-04-17 9:10 ` [RFC 13/13] ARM: dts: ti: add am57xx-evm " Tero Kristo 2018-04-17 9:18 ` [RFC 00/13] ARM: dts: DT overlay support infra + some data Russell King
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a43ce521-ed7f-6126-4ebf-5e0e303d00a3@gmail.com \ --to=frowand.list@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=mark.rutland@arm.com \ --cc=robh@kernel.org \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ --cc=trini@konsulko.com \ --cc=wmills@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.