[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA8EJpqn-s=o2D0CcFg3ZMQUQWGW6UiAs+hZK2gM1A5YciS9MA@mail.gmail.com>
Date: Tue, 2 Apr 2024 18:58:48 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>, Sibi Sankar <quic_sibis@...cinc.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH 3/3] arm64: dts: msm8996: add fastrpc nodes
On Tue, 2 Apr 2024 at 17:47, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>
> On 31.03.2024 11:10 PM, Dmitry Baryshkov wrote:
> > From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
> >
> > The ADSP provides fastrpc/compute capabilities. Enable support for the
> > fastrpc on this DSP.
> >
> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > ---
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 57 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index 7ae499fa7d91..cf7ab01f3af6 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -3545,6 +3545,63 @@ q6routing: routing {
> > };
> > };
> > };
> > +
> > + fastrpc {
> > + compatible = "qcom,fastrpc";
> > + qcom,smd-channels = "fastrpcsmd-apps-dsp";
> > + label = "adsp";
> > + qcom,non-secure-domain;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cb@8 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <8>;
> > + iommus = <&lpass_q6_smmu 8>;
> > + };
> > +
> > + cb@9 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <9>;
> > + iommus = <&lpass_q6_smmu 9>;
> > + };
> > +
> > + cb@10 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <10>;
> > + iommus = <&lpass_q6_smmu 10>;
> > + };
> > +
> > + cb@11 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <11>;
> > + iommus = <&lpass_q6_smmu 11>;
> > + };
> > +
> > + cb@12 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <12>;
> > + iommus = <&lpass_q6_smmu 12>;
> > + };
> > +
> > + cb@5 {
> > + compatible = "qcom,fastrpc-compute-cb";
> > + reg = <5>;
>
> No need to copy downstream's creative alphabetical-but-not-numerical
> sorting..
Ack, I'll fix the order.
> The entries look OK though.. although, any reason we have
> such a weird binding including faux child nodes and not just an array
> of iommus? Is the only way to discover the fastrpc nodes' properties
> such as qcom,non-secure-domain or vmid belonging through hardcoding?
No idea here. This is how fastrpc nodes are defined on all existing
platforms. Maybe Srini knows the story and the reason behind the
bindings??
--
With best wishes
Dmitry
Powered by blists - more mailing lists