All of lore.kernel.org
 help / color / mirror / Atom feed
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.)

  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: link
Be 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.