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:   Tue, 28 Mar 2023 14:48:09 +0200
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Sumit Gupta <sumitg@nvidia.com>
Cc:     treding@nvidia.com, dmitry.osipenko@collabora.com,
        viresh.kumar@linaro.org, rafael@kernel.org, jonathanh@nvidia.com,
        robh+dt@kernel.org, lpieralisi@kernel.org,
        linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
        linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-pci@vger.kernel.org, mmaddireddy@nvidia.com, kw@linux.com,
        bhelgaas@google.com, vidyas@nvidia.com, sanjayc@nvidia.com,
        ksitaraman@nvidia.com, ishah@nvidia.com, bbasu@nvidia.com
Subject: Re: [Patch v4 01/10] dt-bindings: memory: tegra: add bpmp ref in
 tegra234-mc node
Message-ID: <ZCLiCWRYbO98qwCn@orome>
References: <20230327161426.32639-1-sumitg@nvidia.com>
 <20230327161426.32639-2-sumitg@nvidia.com>
 <787f656a-223d-5eed-e311-9cc7a6c46452@linaro.org>
 <ZCLF6ZRH528pu/r3@orome>
 <79d8044f-ce68-463e-66f7-8755e253bc99@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="SOqUr+gSHmGMXo04"
Content-Disposition: inline
In-Reply-To: <79d8044f-ce68-463e-66f7-8755e253bc99@linaro.org>
User-Agent: Mutt/2.2.9 (2022-11-12)
Precedence: bulk


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

On Tue, Mar 28, 2023 at 01:22:26PM +0200, Krzysztof Kozlowski wrote:
> On 28/03/2023 12:48, Thierry Reding wrote:
> > On Tue, Mar 28, 2023 at 09:23:04AM +0200, Krzysztof Kozlowski wrote:
> >> On 27/03/2023 18:14, Sumit Gupta wrote:
> >>> For Tegra234, add the "nvidia,bpmp" property within the Memory
> >>> Controller (MC) node to reference BPMP node. This is needed in
> >>> the MC driver to pass the client info to the BPMP-FW when memory
> >>> interconnect support is available.
> >>>
> >>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> >>> ---
> >>>  .../bindings/memory-controllers/nvidia,tegra186-mc.yaml    | 7 +++++=
++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvi=
dia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers=
/nvidia,tegra186-mc.yaml
> >>> index 935d63d181d9..398d27bb2373 100644
> >>> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,teg=
ra186-mc.yaml
> >>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,teg=
ra186-mc.yaml
> >>> @@ -58,6 +58,10 @@ properties:
> >>>    "#interconnect-cells":
> >>>      const: 1
> >>> =20
> >>> +  nvidia,bpmp:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle of the node representing the BPMP
> >>
> >> Why do you need this multiple times? Both in parent and all external-mc
> >> children?
> >=20
> > We've had nvidia,bpmp in the external memory controller node since
> > basically the beginning because we've always needed it there. For newer
> > chips we now also need it for the memory controller.
> >=20
> > Ideally I think we would only have this in the MC and have the EMC
> > driver reference it via the EMC's parent (i.e. MC), but that would break
> > backwards-compatibility. Reaching into the EMC's DT node from the MC was
> > another option that we discussed internally, but it didn't look right
> > given how this is also needed by the MC.
> >=20
> > One thing we could potentially do is deprecate the nvidia,bpmp phandle
> > in the EMC and only keep it as a fallback in the drivers in case the
> > parent MC doesn't find it's own in the DT.
>=20
> Yes, deprecation would answer to my question.

Okay, great. Sumit, you can resolve this by adding a "deprecated: true"
to the EMC's nvidia,bpmp property schema. In the driver we can then try
to look at the MC's ->bpmp and if it exists reuse that. If it doesn't
exist, we can keep the existing lookup as a fallback for device trees
that haven't been updated yet.

--SOqUr+gSHmGMXo04
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmQi4gkACgkQ3SOs138+
s6G2ZxAAwuGkypHqrXA4QgRFLPxekiFsfb7hu4WNZB/Jrz4Lmvpay4dmkKjHSLA9
cKJUd3WIGmWES3R9F8xKMFS75/novPJukcYSS9a4X3t3xxYlq7hLgNd9fOcbDkOX
v2nxKJ616/Ay3Ili6JlD845nmvnBxd1MWkjsF/i6khyJ7k48x1mD5GIJT/J3CXE/
ikuC7FqzWV2hllEJlqdGu0Y6xzo+84w3sf5BfIvWT4Wvi+LjqJvDfeA7l4nEh9h9
xRjimc2eqsJ8YXF4Lpwcw30raeYvkBqd7N+dtAa5emU61hi8po1OH+VEmhB2qISw
UdciYir/o51oDPboXtMguc3Ei13eYNOrYqjwbPXsewCaWF99jR5nQrNDB/It1Kq7
KJ3P44Qv4x1RMMbWX+cSOtyH+kb9XXJZV1saTu/ns9U+3x54OMM+JGWKCi4ifbJh
QQk2F0tqdGLmxuCtBL0+AowthUOoK13Zw3jAjsRS1F7suOcqV1kyyl+cmQmCu+sl
keKQpdLGxlrPRN/mzsLGM3nNLFW0bRtiKO3SLZLp6G3IGE55Ec9qotGN20kUyQVy
5C0hrICmnEXI4aHt4FCJkiOp55TS9xHO4Nf59oKXJICR8xMHmjQDFf27VaYXKTXR
FrRHds32doXBh0bnV2S4+7m0/QCjPGQHoXXG/xsFkYnv5TPFOgg=
=B8Lm
-----END PGP SIGNATURE-----

--SOqUr+gSHmGMXo04--