Linux Tegra architecture development
 help / color / mirror / Atom feed
From: Johnny Liu <johnliu@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>
Subject: [PATCH v2 0/4] Add Tegra238 BPMP support and fix stale EMC clock rate
Date: Wed, 28 Oct 2026 15:49:56 +0000	[thread overview]
Message-ID: <20261028155000.1205739-1-johnliu@nvidia.com> (raw)

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 dedicated SoC
data for Tegra234, Tegra238 and Tegra264, selected by their specific
compatibles, and builds the BPMP driver for CONFIG_ARCH_TEGRA_238_SOC.
Patch 3 adds an emc_clk_id field to struct tegra_bpmp_soc and sets it
using the TEGRA*_CLK_EMC clock ID macros. Patch 4 then sets
CLK_GET_RATE_NOCACHE on the clock matching that ID.

The series touches both the clock and the firmware code. Patch 4 depends
on patch 3, which in turn depends on patch 1, so I would suggest taking
the whole series through the Tegra tree with an Acked-by from the clock
maintainers.

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.

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 Tegra238 support
  firmware: tegra: bpmp: Add per-SoC EMC clock ID
  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


             reply	other threads:[~2026-10-28 15:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 15:49 Johnny Liu [this message]
2026-10-28 15:49 ` [PATCH v2 1/4] dt-bindings: firmware: tegra186-bpmp: Add Tegra238 BPMP Johnny Liu
2026-10-29  8:56   ` Krzysztof Kozlowski
2026-10-28 15:49 ` [PATCH v2 2/4] firmware: tegra: bpmp: Add Tegra238 support Johnny Liu
2026-10-28 15:49 ` [PATCH v2 3/4] firmware: tegra: bpmp: Add per-SoC EMC clock ID Johnny Liu
2026-10-28 15:50 ` [PATCH v2 4/4] clk: tegra: bpmp: Do not cache the EMC clock rate Johnny Liu

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=20261028155000.1205739-1-johnliu@nvidia.com \
    --to=johnliu@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=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