U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: Moteen Shah <m-shah@ti.com>, u-boot@lists.denx.de
Cc: trini@konsulko.com, sjg@chromium.org, m-chawdhry@ti.com,
	n-francis@ti.com, vigneshr@ti.com, u-kumar1@ti.com,
	a-chavda@ti.com
Subject: Re: [RFC PATCH 0/2 v1] Propagate bootph* property to all parent nodes
Date: Mon, 17 Feb 2025 16:02:18 +0100	[thread overview]
Message-ID: <445f7dd4-d445-41a2-ad0b-f0c2002f3f1a@cherry.de> (raw)
In-Reply-To: <20250212091820.213895-1-m-shah@ti.com>

Hi Moteen,

On 2/12/25 10:18 AM, Moteen Shah wrote:
> [You don't often get email from m-shah@ti.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> In the U-Boot pre-relocation stage, if the parent node lacks bootph*
> property and the driver lacks a pre-reloc flag, all of its subsequent
> subnodes gets skipped over from driver binding—even if they have a
> bootph* property.
> 
> This series addresses the issue by scanning through all the subnodes
> of the current node for the bootph* property and propagate it to all
> of its supernodes, ensuring that all of the applicable drivers are
> bound and probed prior to relocation. This series implements one of
> the solutions mentioned in [0].
> 
> Since, all the nodes which are not having any bootph* property will
> also be traversed, we will have to incur some overheads in boot time,
> hence protecting the feature under a config.
> 
> Boot time overheads:
>      Baseline: Upstream u-boot
> 
>      Patch test: Baseline + remove all bootph-all properties from
>      *-u-boot.dtsi except the ones which are supposed to be probed
>      but have no bootph in any of its subnode.
> 
>      J7200 delta from baseline  : ~100ms
>      J784S4 delta from baseline : ~350ms
> 

Pfew, that's a lot of time. Can you tell us what's the delta in 
percentage from baseline? Because if your system is usually booting in 
one minute, 100ms isn't too bad :)

FYI, I believe we've been hit by this issue on Rockchip but cannot find 
the thread or patch right now.

For TPL and SPL, the Device Tree is parsed and looked for appropriate 
bootph properties. Any node which doesn't have a bootph property and 
doesn't have any children with a bootph property is removed from the 
tree. However, the bootph property (if only present in a children node) 
isn't propagated (meaning the node doesn't get the property). This is 
done by fdtgrep.

The issue is that for U-Boot proper pre-relocation, the whole DT is 
taken and only nodes with the appropriate bootph property is probed and 
children nodes do NOT count as opposed to the TPL/SPL case.

My idea was that maybe we should rather propagate the property, at the 
very least in U-Boot proper pre-relocation. This does mean we will 
increase (by which amount?) the size of the DT in U-Boot proper because 
we would add this property recursively up the tree from a node that has 
the bootph property for U-Boot proper pre-relocation. This **could** be 
an issue as the DT could be passed between stages and we would then hit 
the size limit. Sadly, I didn't take the time to look into adding 
support for that in fdtgrep nor will I have the time to do it, so take 
this as me sharing my wish list with you.

I would really like to avoid having it guarded by a knob though because 
I really think this is an issue that should simply be fixed 
unconditionally for every platform with DT support.

Cheers,
Quentin

  parent reply	other threads:[~2025-02-17 15:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-12  9:18 [RFC PATCH 0/2 v1] Propagate bootph* property to all parent nodes Moteen Shah
2025-02-12  9:18 ` [RFC PATCH 1/2 v1] arch: arm: Kconfig: Add config to use subnode's bootph property for binding drivers Moteen Shah
2025-02-12 14:49   ` Kumar, Udit
2025-02-13  4:48     ` Moteen Shah
2025-02-13 14:01   ` Simon Glass
2025-02-14  5:05     ` [EXTERNAL] " Moteen Shah
2025-02-25 21:27       ` Simon Glass
2025-03-07  4:55         ` Moteen Shah
2025-03-27  6:58           ` Moteen Shah
2025-02-12  9:18 ` [RFC PATCH 2/2 v1] drivers: core: lists.c: Bind drivers using bootph* property in subnodes Moteen Shah
2025-02-12 13:37   ` Simon Glass
2025-02-13 13:01     ` [EXTERNAL] " Moteen Shah
2025-02-12 14:59   ` Kumar, Udit
2025-02-17 15:02 ` Quentin Schulz [this message]
2025-02-26  5:57   ` [RFC PATCH 0/2 v1] Propagate bootph* property to all parent nodes Moteen Shah
2025-02-26 10:53     ` Quentin Schulz
2025-02-27 16:24       ` Simon Glass
2025-02-28 11:03         ` Quentin Schulz
2025-03-05 14:15           ` Simon Glass

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=445f7dd4-d445-41a2-ad0b-f0c2002f3f1a@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=a-chavda@ti.com \
    --cc=m-chawdhry@ti.com \
    --cc=m-shah@ti.com \
    --cc=n-francis@ti.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox