Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 16 Jan 2023 17:29:02 +0100
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Sumit Gupta <sumitg@nvidia.com>
Cc:     treding@nvidia.com, krzysztof.kozlowski@linaro.org,
        dmitry.osipenko@collabora.com, viresh.kumar@linaro.org,
        rafael@kernel.org, jonathanh@nvidia.com, robh+dt@kernel.org,
        linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
        linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
        sanjayc@nvidia.com, ksitaraman@nvidia.com, ishah@nvidia.com,
        bbasu@nvidia.com
Subject: Re: [Patch v1 06/10] arm64: tegra: Add cpu OPP tables and
 interconnects property
Message-ID: <Y8V7TkAiEWizF70l@orome>
References: <20221220160240.27494-1-sumitg@nvidia.com>
 <20221220160240.27494-7-sumitg@nvidia.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="ZMip0bUSH42JeHsT"
Content-Disposition: inline
In-Reply-To: <20221220160240.27494-7-sumitg@nvidia.com>
User-Agent: Mutt/2.2.9 (2022-11-12)
Precedence: bulk


--ZMip0bUSH42JeHsT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 20, 2022 at 09:32:36PM +0530, Sumit Gupta wrote:
> Add OPP table and interconnects property required to scale DDR
> frequency for better performance. The OPP table has CPU frequency
> to per MC channel bandwidth mapping in each operating point entry.
> One table is added for each cluster even though the table data is
> same because the bandwidth request is per cluster. OPP framework
> is creating a single icc path if the table is marked 'opp-shared'
> and shared among all clusters. For us the OPP table is same but
> the MC client ID argument to interconnects property is different
> for each cluster which makes different icc path for all.
>=20
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra234.dtsi | 276 +++++++++++++++++++++++
>  1 file changed, 276 insertions(+)
>=20
> diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/d=
ts/nvidia/tegra234.dtsi
> index eaf05ee9acd1..ed7d0f7da431 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> @@ -2840,6 +2840,9 @@
> =20
>  			enable-method =3D "psci";
> =20
> +			operating-points-v2 =3D <&cl0_opp_tbl>;
> +			interconnects =3D <&mc TEGRA_ICC_MC_CPU_CLUSTER0 &emc>;

I dislike how this muddies the water between hardware and software
description. We don't have a hardware client ID for the CPU clusters, so
there's no good way to describe this in a hardware-centric way. We used
to have MPCORE read and write clients for this, but as far as I know
they used to be for the entire CCPLEX rather than per-cluster. It'd be
interesting to know what the BPMP does underneath, perhaps that could
give some indication as to what would be a better hardware value to use
for this.

Failing that, I wonder if a combination of icc_node_create() and
icc_get() can be used for this type of "virtual node" special case.

Thierry

--ZMip0bUSH42JeHsT
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmPFe0wACgkQ3SOs138+
s6F2yBAAjowmxzjVq6aVzA6zhSk3nbCgl0QL/OEp6PY0OzH2xVKJUuu4zOttfnbe
Yp1JqpDpVvueEBIRSRWV2bwEwtJ6W5vYrcW2TkNfM5biG3c1uYRCVcADJPwSO4gL
Obyy7iew33hS30m/9uynImJVGAh/WuVIZJ/2JTkFGzjP7K7nvhASuyABnVE4+CvJ
uIgl1XUxTdgD/hS6BmVlKv5S6M9bU7UkWTCWqX2xS/t51K+iv7nBc9NeeVrJZdwF
sChYSmFEmKMPyZF15al5UK//xakf3l9M1Q3p7QEo/VK6Ee5D8nAvGRzMYWD2uSvv
rfhT9hZNaLYaHUQkdGJP7hcIspsR3CucHasz6UqDgsWSJkL9b4QlDYLFK9StTEyV
LrrYjQHe6jTYSGegIBqwzANd3Kp/Enbzdz0Rb9d7fXelYuEkPdxc4xMjw22qe7Er
9DuaDmkeh1218GaEWeepVrQvDKDiaK2KrhQGd8uu2iXGXe9xOG2TtT0lvQENZpLX
WkEpDjrh+ZJrSrd8A06oRFmRzHP/Y8W4QUH7dUFujcfip+JQjMlq+K1+EMyRwapR
yrWPyYqk/2NxS+vlfAwyX+K+DkB/xlvPNRRsdof93MKdbGUgFQ9pbGtzCddzyAOK
sPo4xnV+1yI+JBT9/OafTN0UMaSLCArvPLubL+7mfrjqaBrPQ54=
=eSEA
-----END PGP SIGNATURE-----

--ZMip0bUSH42JeHsT--