public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luca Weiss" <luca.weiss@fairphone.com>
To: "Doug Anderson" <dianders@chromium.org>
Cc: "Mukesh Ojha" <quic_mojha@quicinc.com>,
	"Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Mathieu Poirier" <mathieu.poirier@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	cros-qcom-dts-watchers@chromium.org,
	~postmarketos/upstreaming@lists.sr.ht,
	phone-devel@vger.kernel.org,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Matti Lehtimäki" <matti.lehtimaki@gmail.com>,
	linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/9] arm64: dts: qcom: sc7280: Add CDSP node
Date: Mon, 30 Oct 2023 15:43:37 +0100	[thread overview]
Message-ID: <CWLUQWPZNAS5.3F4Y5W13OD08M@fairphone.com> (raw)
In-Reply-To: <CAD=FV=U6mi0h0MBFMC+ba4oq-te6_+WR6fj1XjAq7tmUu64bUA@mail.gmail.com>

On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote:
> Hi,
>
> On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote:
> >
> > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote:
> > >
> > >
> > > On 10/27/2023 7:50 PM, Luca Weiss wrote:
> > > > Add the node for the ADSP found on the SC7280 SoC, using standard
> > > > Qualcomm firmware.
> > > >
> > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4
> > > > yupik.dtsi since the other areas also seem to match that file there,
> > > > though I cannot be sure there.
> > > >
> > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > > > ---
> > > >   arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi |   5 +
> > > >   arch/arm64/boot/dts/qcom/sc7280.dtsi               | 138 +++++++++++++++++++++
> > > >   2 files changed, 143 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > > > index eb55616e0892..6e5a9d4c1fda 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 {
> > > >                     no-map;
> > > >             };
> > > >
> > > > +           cdsp_mem: memory@88f00000 {
> > > > +                   reg = <0x0 0x88f00000 0x0 0x1e00000>;
> > > > +                   no-map;
> > > > +           };
> > > > +
> > >
> > > Just a question, why to do it here, if chrome does not use this ?
> >
> > Other memory regions in sc7280.dtsi also get referenced but not actually
> > defined in that file, like mpss_mem and wpss_mem. Alternatively we can
> > also try and solve this differently, but then we should probably also
> > adjust mpss and wpss to be consistent.
> >
> > Apart from either declaring cdsp_mem in sc7280.dtsi or
> > "/delete-property/ memory-region;" for CDSP I don't really have better
> > ideas though.
> >
> > I also imagine these ChromeOS devices will want to enable cdsp at some
> > point but I don't know any plans there.
>
> Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it
> feels like the dtsi shouldn't be reserving memory. I guess maybe
> memory regions can't be status "disabled"?

Hi Doug,

That's how it works in really any qcom dtsi though. I think in most/all
cases normally the reserved-memory is already declared in the SoC dtsi
file and also used with the memory-region property.

I wouldn't be against adjusting sc7280.dtsi to match the way it's done
in the other dtsi files though, so to have all the required labels
already defined in the dtsi so it doesn't rely on these labels being
defined in the device dts.

In other words, currently if you include sc7280.dtsi and try to build,
you first have to define the labels mpss_mem and wpss_mem (after this
patch series also cdsp_mem and adsp_mem) for it to build.

I'm quite neutral either way, let me know :)

Regards
Luca

>
> -Doug


  reply	other threads:[~2023-10-30 14:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20231027-sc7280-remoteprocs-v1-0-05ce95d9315a@fairphone.com>
     [not found] ` <20231027-sc7280-remoteprocs-v1-1-05ce95d9315a@fairphone.com>
2023-10-28  8:01   ` [PATCH 1/9] dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names Krzysztof Kozlowski
     [not found] ` <20231027-sc7280-remoteprocs-v1-2-05ce95d9315a@fairphone.com>
2023-10-28  8:04   ` [PATCH 2/9] arm64: dts: qcom: sc7280: Remove unused second MPSS reg Krzysztof Kozlowski
     [not found] ` <20231027-sc7280-remoteprocs-v1-3-05ce95d9315a@fairphone.com>
2023-10-28  8:05   ` [PATCH 3/9] dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles Krzysztof Kozlowski
     [not found] ` <20231027-sc7280-remoteprocs-v1-6-05ce95d9315a@fairphone.com>
2023-10-28  8:05   ` [PATCH 6/9] arm64: dts: qcom: sc7280: Add ADSP node Krzysztof Kozlowski
     [not found] ` <20231027-sc7280-remoteprocs-v1-7-05ce95d9315a@fairphone.com>
2023-10-28  8:06   ` [PATCH 7/9] arm64: dts: qcom: sc7280: Add CDSP node Krzysztof Kozlowski
2023-10-30  9:04   ` Mukesh Ojha
2023-10-30  9:12     ` Luca Weiss
2023-10-30 14:11       ` Doug Anderson
2023-10-30 14:43         ` Luca Weiss [this message]
2023-10-30 15:03           ` Doug Anderson
2023-10-31  6:44             ` Mukesh Ojha
2023-10-31  6:51               ` Luca Weiss
     [not found] ` <20231027-sc7280-remoteprocs-v1-8-05ce95d9315a@fairphone.com>
2023-10-30 19:26   ` [PATCH 8/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs Konrad Dybcio
2023-10-31 10:32     ` Luca Weiss
     [not found] ` <20231027-sc7280-remoteprocs-v1-9-05ce95d9315a@fairphone.com>
2023-10-30 19:26   ` [PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi Konrad Dybcio
2023-10-31 10:31     ` Luca Weiss
2023-10-31 10:32       ` Konrad Dybcio
2023-11-04 13:23       ` Dmitry Baryshkov
2023-11-13 12:22         ` Kalle Valo
2023-11-13 12:50           ` Luca Weiss
2023-11-13 14:10             ` Kalle Valo

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=CWLUQWPZNAS5.3F4Y5W13OD08M@fairphone.com \
    --to=luca.weiss@fairphone.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cros-qcom-dts-watchers@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=matti.lehtimaki@gmail.com \
    --cc=phone-devel@vger.kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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