From: Mikko Perttunen <mperttunen@nvidia.com>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Thierry Reding <thierry.reding@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Prashant Gaikwad <pgaikwad@nvidia.com>,
Stephen Boyd <sboyd@kernel.org>,
Brian Masney <bmasney+clk@redhat.com>,
Jerome Brunet <jbrunet+clk@baylibre.com>,
Douglas Anderson <dianders@chromium.org>,
Aniruddha Rao <anrao@nvidia.com>,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
Cc: Johnny Liu <johnliu@nvidia.com>, Johnny Liu <johnliu@nvidia.com>
Subject: Re: [PATCH v3 0/4] Add Tegra238 BPMP support and fix stale EMC clock rate
Date: Tue, 03 Nov 2026 15:25:51 +0900 [thread overview]
Message-ID: <8Vvs2CcoQRmp5w8swuUfpw@nvidia.com> (raw)
In-Reply-To: <20261102121202.2431928-1-johnliu@nvidia.com>
On Monday, November 2, 2026 9:11 PM Johnny Liu wrote:
> EMC clock scaling is handled by the BPMP firmware without kernel
> involvement, so clk_get_rate() on the EMC clock can return a stale value
> cached by the common clock framework. This series makes the EMC clock
> rate uncached on Tegra234, Tegra238 and Tegra264, and adds the pieces
> needed to identify the EMC clock on each of these chips.
>
> The EMC clock ID differs per chip (TEGRA234_CLK_EMC=31,
> TEGRA238_CLK_EMC=43, TEGRA264_CLK_EMC=290), while the
> "nvidia,tegra186-bpmp" fallback compatible and the tegra186_soc data are
> shared across several chips. To avoid detecting the chip at runtime, the
> EMC clock ID is carried in per-SoC BPMP data selected by the device tree
> compatible.
>
> Patch 1 adds the "nvidia,tegra238-bpmp" compatible to the binding,
> together with the Tegra238 clock ID header. Patch 2 adds an emc_clk_id
> field to struct tegra_bpmp_soc, together with dedicated SoC data for
> Tegra234 and Tegra264 built on a common TEGRA186_BPMP_SOC_COMMON
> initializer. Patch 3 adds Tegra238 support to the BPMP driver, including
> its own SoC data and EMC clock ID. Patch 4 then sets
> CLK_GET_RATE_NOCACHE on the clock matching that ID, so that the common
> clock framework forwards rate queries to the BPMP instead of returning a
> stale cached rate.
>
> The series touches both the clock and the firmware code. Patch 4 depends
> on patch 2, and patch 3 depends on patches 1 and 2, so I would suggest
> taking the whole series through the Tegra tree with an Acked-by from the
> clock maintainers.
>
> Changes in v3:
> - Move the TEGRA186_BPMP_SOC_COMMON refactoring out of the Tegra238
> support patch and into the "Add per-SoC EMC clock ID" patch, as the
> refactoring only makes sense together with the per-SoC emc_clk_id.
> - Keep all Tegra238 specific changes (Makefile, CONFIG_ARCH_TEGRA_238_SOC
> guards, clock ID header include, tegra238_soc data and compatible match)
> in a single "Add Tegra238 support" patch, and reorder it after the
> per-SoC EMC clock ID patch.
> - Reword the "Add per-SoC EMC clock ID" commit message to describe the
> intended use of emc_clk_id: the BPMP clock provider sets
> CLK_GET_RATE_NOCACHE on that clock, as it is completely managed by the
> firmware and the common clock framework must pass rate queries through
> to get the latest rate.
> - No changes to patches 1 and 4 apart from the patch numbering.
>
> Changes in v2:
> - Squash "dt-bindings: clock: Add Tegra238 BPMP clock IDs" into
> "dt-bindings: firmware: tegra186-bpmp: Add Tegra238 compatible".
> - Reword the binding commit message to state that the Tegra238 SoC is
> fully compatible with the Tegra186 BPMP.
>
> v2: https://lore.kernel.org/all/20261028155000.1205739-1-johnliu@nvidia.com/
> v1: https://lore.kernel.org/all/20261028084900.1047287-1-johnliu@nvidia.com/
>
> Johnny Liu (4):
> dt-bindings: firmware: tegra186-bpmp: Add Tegra238 BPMP
> firmware: tegra: bpmp: Add per-SoC EMC clock ID
> firmware: tegra: bpmp: Add Tegra238 support
> clk: tegra: bpmp: Do not cache the EMC clock rate
>
> .../firmware/nvidia,tegra186-bpmp.yaml | 1 +
> drivers/clk/tegra/clk-bpmp.c | 3 +
> drivers/firmware/tegra/Makefile | 1 +
> drivers/firmware/tegra/bpmp.c | 61 ++--
> include/dt-bindings/clock/nvidia,tegra238.h | 279 ++++++++++++++++++
> include/soc/tegra/bpmp.h | 1 +
> 6 files changed, 329 insertions(+), 17 deletions(-)
> create mode 100644 include/dt-bindings/clock/nvidia,tegra238.h
>
> --
> 2.43.0
>
>
Thank you!
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
prev parent reply other threads:[~2026-11-03 6:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 12:11 Johnny Liu
2026-11-02 12:11 ` [PATCH v3 1/4] dt-bindings: firmware: tegra186-bpmp: Add Tegra238 BPMP Johnny Liu
2026-11-02 13:12 ` Johnny Liu
2026-11-02 12:12 ` [PATCH v3 2/4] firmware: tegra: bpmp: Add per-SoC EMC clock ID Johnny Liu
2026-11-02 12:12 ` [PATCH v3 3/4] firmware: tegra: bpmp: Add Tegra238 support Johnny Liu
2026-11-02 12:12 ` [PATCH v3 4/4] clk: tegra: bpmp: Do not cache the EMC clock rate Johnny Liu
2026-11-03 6:25 ` 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=8Vvs2CcoQRmp5w8swuUfpw@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=anrao@nvidia.com \
--cc=bmasney+clk@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=jbrunet+clk@baylibre.com \
--cc=johnliu@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pgaikwad@nvidia.com \
--cc=robh@kernel.org \
--cc=sboyd@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®