From: Mikko Perttunen <mperttunen@nvidia.com>
To: thierry.reding@kernel.org, jonathanh@nvidia.com,
Austin Schuh <austin.linux@gmail.com>
Cc: anrao@nvidia.com, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org,
Austin Schuh <austin.linux@gmail.com>
Subject: Re: [PATCH] firmware: tegra: bpmp: populate debugfs in the background
Date: Fri, 23 Oct 2026 17:16:26 +0900 [thread overview]
Message-ID: <n59f1S6wQICe5ZxgcNxb3w@nvidia.com> (raw)
In-Reply-To: <20261017065012.3063980-1-austin.linux@gmail.com>
On Saturday, October 17, 2026 3:50 PM Austin Schuh wrote:
> Populating the BPMP debugfs mirror takes a series of synchronous BPMP
> requests, several per directory. On an Orin Nano (Tegra234) the tree has
> about 10,800 entries, and the BPMP probe doesn't return for over five
> seconds. Every device that gets its clocks, resets or power domains from
> the BPMP waits for it, which on Tegra234 is nearly all of them, so PCIe,
> NVMe and the root filesystem all come up five seconds late.
>
> Commit c7fc690da6f1 ("firmware: tegra: bpmp: Allow BPMP debugfs population
> to be skipped") lets a system that doesn't need the mirror turn it off with
> tegra_bpmp.debugfs=0. A system that does use it, for instance to set
> clocks from userspace at boot, still pays the full cost.
>
> Nothing in the kernel uses the mirror, and the probe already only logs an
> error from it, so populate it from a workqueue instead. It isn't an
> async_schedule() job, since kernel_init() waits for all of those before it
> starts init. Userspace that reads the mirror right after boot may find it
> still being filled in.
>
> Measured with initcall_debug on an Orin Nano running 6.18.39 with
> NVIDIA's patches: the BPMP probe returns after 1.2 seconds instead of
> 6.36 seconds.
>
> Assisted-by: LLM
> Signed-off-by: Austin Schuh <austin.linux@gmail.com>
> ---
Sashiko reports some hard to trigger but worth checking concurrency
issues.
This does seem a good idea, but I am a bit concerned about the change to
what userspace sees. Ideally we'd be able to have userspace stall if the
debugfs population was still in progress. If that's not possible, at the
very least userspace should have a way to voluntarily wait for the full
debugfs to be available.
>
> Notes:
> Based on tegra/for-7.4/firmware (1bbcf4a19f14). Built for arm64, W=1,
> no new warnings. The timing is from the same change on 6.18.39 with
> NVIDIA's patches (where the probe also has the VDK check), which is what
> our board runs; I haven't booted this branch on it.
>
> drivers/firmware/tegra/bpmp.c | 35 ++++++++++++++++++++++++++++++++---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
> index d3508e98e338..535ebbd55a6f 100644
> --- a/drivers/firmware/tegra/bpmp.c
> +++ b/drivers/firmware/tegra/bpmp.c
> @@ -16,6 +16,7 @@
> #include <linux/semaphore.h>
> #include <linux/sched/clock.h>
> #include <linux/slab.h>
> +#include <linux/workqueue.h>
>
> #include <soc/tegra/bpmp.h>
> #include <soc/tegra/bpmp-abi.h>
> @@ -1052,8 +1053,26 @@ int tegra_bpmp_init_dt_providers(struct tegra_bpmp *bpmp)
> return 0;
> }
>
> +struct tegra_bpmp_debugfs_work {
> + struct work_struct work;
> + struct tegra_bpmp *bpmp;
> +};
Just inline the work_struct inside tegra_bpmp. In any case the work
should be synchronously cancelled if the bpmp driver instance is going
to go away (not that that will happen, but good practice).
Thanks
Mikko
> +
> +static void tegra_bpmp_debugfs_work_fn(struct work_struct *work)
> +{
> + struct tegra_bpmp_debugfs_work *dw =
> + container_of(work, struct tegra_bpmp_debugfs_work, work);
> + int err;
> +
> + err = tegra_bpmp_init_debugfs(dw->bpmp);
> + if (err < 0)
> + dev_err(dw->bpmp->dev, "debugfs initialization failed: %d\n",
> + err);
> +}
> +
> static int tegra_bpmp_probe(struct platform_device *pdev)
> {
> + struct tegra_bpmp_debugfs_work *debugfs_work;
> struct tegra_bpmp *bpmp;
> char tag[TAG_SZ];
> int err;
> @@ -1089,9 +1108,19 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
> if (err < 0)
> dev_err(&pdev->dev, "failed to initialize sysfs: %d\n", err);
>
> - err = tegra_bpmp_init_debugfs(bpmp);
> - if (err < 0)
> - dev_err(&pdev->dev, "debugfs initialization failed: %d\n", err);
> + /*
> + * Mirroring the BPMP's debugfs tree takes several requests per
> + * directory, which on Tegra234 adds up to seconds. Nothing else
> + * waits for it, so do it in the background rather than hold up every
> + * device that depends on the BPMP.
> + */
> + debugfs_work = devm_kzalloc(&pdev->dev, sizeof(*debugfs_work),
> + GFP_KERNEL);
> + if (debugfs_work) {
> + debugfs_work->bpmp = bpmp;
> + INIT_WORK(&debugfs_work->work, tegra_bpmp_debugfs_work_fn);
> + queue_work(system_dfl_long_wq, &debugfs_work->work);
> + }
>
> return 0;
>
>
> base-commit: 1bbcf4a19f1495f769b69e9569d8c1e81df074f5
> --
> 2.47.3
>
>
prev parent reply other threads:[~2026-10-23 8:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 6:50 Austin Schuh
2026-10-23 8:16 ` Mikko Perttunen [this message]
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=n59f1S6wQICe5ZxgcNxb3w@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=anrao@nvidia.com \
--cc=austin.linux@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@kernel.org \
/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
all inboxes | Powered by JetHome®