From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Andy Gross <agross@kernel.org>, Rob Herring <robh+dt@kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
Date: Tue, 9 Feb 2021 17:36:32 -0600 [thread overview]
Message-ID: <YCMcgHfJDeGAMlVp@builder.lan> (raw)
In-Reply-To: <CAD=FV=UnYd5w83xkf0D+ND0nsVfX+RVnr=f=hyLg0j=ERDsXKQ@mail.gmail.com>
On Tue 09 Feb 17:25 CST 2021, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 9, 2021 at 8:09 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > index 216a74f0057c..2f44785d1af0 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
> > * all modifications to the memory map (from sdm845.dtsi) in one place.
> > */
> >
> > -/*
> > - * Our mpss_region is 8MB bigger than the default one and that conflicts
> > - * with venus_mem and cdsp_mem.
> > - *
> > - * For venus_mem we'll delete and re-create at a different address.
> > - *
> > - * cdsp_mem isn't used on cheza right now so we won't bother re-creating it; but
> > - * that also means we need to delete cdsp_pas.
> > - */
> > -/delete-node/ &venus_mem;
> > -/delete-node/ &cdsp_mem;
> > -/delete-node/ &cdsp_pas;
>
> Note to self: on cheza we'll end up with "cdsp_pas" existing now, but
> that _should_ be OK since it's disabled
>
That was not intentional, but as you say it shouldn't make a difference.
>
> > @@ -1321,6 +1359,7 @@ config {
> > };
> >
> > &venus {
> > + memory-region = <&venus_mem>;
> > video-firmware {
> > iommus = <&apps_smmu 0x10b2 0x0>;
> > };
>
> slight nit: I think it looks ugly not to have a blank line between the
> property and the sub-node. ;-)
>
I agree, will go over and adjust this in v2.
>
> > @@ -766,8 +697,6 @@ adsp_pas: remoteproc-adsp {
> > clocks = <&rpmhcc RPMH_CXO_CLK>;
> > clock-names = "xo";
> >
> > - memory-region = <&adsp_mem>;
> > -
>
> Note to self: we're losing the above on cheza, but that _should_ be OK
> since the node is disabled anyway.
>
> Probably not critical at this point, but it makes me wonder whether we
> could remove adsp_mem on cheza...
>
I noticed this too, but figured that this is an actual change, so it
would be better to do in a separate commit - if that's desired.
> ---
>
> So I only looked at the cheza and sdm845 changes and they look fine to
> me and this seems like a good change overall. I'm assuming that folks
> who focus on the other boards will double-check your work there if
> they care or just trust that everything is great. ;-)
>
> OK, I lied. I took a quick glance. In "sdm845-db845c" you maybe miss
> adding the "memory-region" back to the WiFi? Have you tried running
> something like this before/after:
>
> for f in sdm845*.dtb; do dtc -I dtb -O dts --sort $f > $f.dts; done
>
I was not aware of the --sort, so I did this by chaining together some
more things in the shell to confirm that I didn't actually change any
reserved-memory regions...
> You've gotta ignore phandle ID differences but otherwise it'll point
> out things like this.
>
But as the phandles changed all over the place I looked only at the
reserved-memory, will fix up the db845c wifi node and double check the
rest of the nodes. Thanks for spotting this!
Regards,
Bjorn
prev parent reply other threads:[~2021-02-10 0:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 16:09 [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices Bjorn Andersson
2021-02-09 16:09 ` [PATCH 2/2] arm64: dts: qcom: sdm850-yoga: Enable IPA Bjorn Andersson
2021-02-09 23:25 ` [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices Doug Anderson
2021-02-09 23:36 ` Bjorn Andersson [this message]
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=YCMcgHfJDeGAMlVp@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=agross@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.