linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Tanmay Shah <tanmay.shah@amd.com>
Cc: andersson@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, michal.simek@amd.com,
	radhey.shyam.pandey@amd.com, ben.levinsky@amd.com,
	linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 2/4] dts: zynqmp: add properties for TCM in remoteproc
Date: Tue, 3 Oct 2023 09:31:53 -0600	[thread overview]
Message-ID: <ZRwz6cEqnnwoVhTD@p14s> (raw)
In-Reply-To: <ad25d019-b2c9-4de9-ac5f-428c5e44f212@amd.com>

On Mon, Oct 02, 2023 at 03:54:30PM -0500, Tanmay Shah wrote:
> 
> On 10/2/23 3:17 PM, Mathieu Poirier wrote:
> > On Mon, 2 Oct 2023 at 11:12, Tanmay Shah <tanmay.shah@amd.com> wrote:
> > >
> > >
> > > On 10/2/23 11:25 AM, Tanmay Shah wrote:
> > > > Hi Mathieu,
> > > >
> > > > Thanks for the reviews. Please find my comments below.
> > > >
> > > > On 10/2/23 10:55 AM, Mathieu Poirier wrote:
> > > > > On Thu, Sep 28, 2023 at 08:58:58AM -0700, Tanmay Shah wrote:
> > > > > > Add properties as per new bindings in zynqmp remoteproc node
> > > > > > to represent TCM address and size. This patch configures
> > > > > > RPU in split mode and adds TCM information accordingly.
> > > > > >
> > > > >
> > > > > Why is this changed from lockstep to split mode?  What about all the people out
> > > > > there that are expecting a lockstep mode?
> > > >
> > > > I agree, this should have been in split mode in the first place as we would like to demonstrate use of both
> > > >
> > > > RPUs with two separate demo firmwares which is the best use of the
> > > >
> > > > hardware and the most preferred use of zynqmp platform by people. That motivates to change
> > > >
> > > > this to split mode.
> > > >
> > > >
> > > > Now changing this may not be problem for lot of people with following reasons.
> > > >
> > > > The firmwares that are only using first 64KB of TCM memory, they can easily run in split mode as well.
> > > >
> > > > Also rpmsg vring information isn't available in device-tree yet, so I am hoping that firmware that
> > > >
> > > > are using upstream device-tree are not that big yet.
> > > >
> > > > If we change this to split mode before introducing rpmsg related nodes, I bet it will affect very less number of people.
> > > >
> > > >
> > > > For lockstep mode the example is available in dt-bindings document.
> > > >
> >
> > I could use the same argument for the split mode, i.e default is
> > lockstep and there is an example in the dt-bindings document for split
> > mode.
> >
> > > > So, if people need lockstep mode for any reason, all they need to change is xlnx,cluster-mode property from 0 to 1 and TCM nodes
> > > >
> > > > from bindings document.
> > > >
> > > >
> > > > If you think it's crucial to mention all above, I can send new patch with all above info in commit message.
> > >
> > > Something to add to this. So, let's say if we don't change it now, what would be good time to change it?
> > >
> >
> > The best way to go about this is to introduce another DT that is
> > tailored for split mode.  That way people can choose to boot their
> > device in a specific mode using the DT.  If you decide to go this way,
> > look at how ST has split their DT for different boards - search for
> > "m4_rproc" under " arch/arm/boot/dts/st".
> 
> Thanks for the suggestion. I looked at the example and I think it will work.
> 
> I have following idea.
> 
> So, if I understand this correctly, we introduce two separate nodes in device-tree.
> 
> SOC dtsi file: zynqmp.dtsi
> 
> remoteproc_lockstep: remoteproc@... {
> 
> . . .
> 
> status = "disabled";

I don't think you need the "status"

> 
> };
> 
> 
> remoteproc_split: remoteproc@... {
> 
>  . . .
> 
> status = "disabled";
> 
> };
> 
> 
> And then in board dts enable whatever mode is needed for that board:
> 
> *zcu102*.dts
> 
> &remoteproc_split {
> 
> status = "okay";
> 
> };

Exactly.  Again, I don't think the "status" is needed.

> 
> This sounds like good idea, I hope this is what you mean.
> 
> Please let me know if I am missing something.
> 
> 
> >
> > > As I am hopping to use RPU1 as well with upstream device-tree. Please let me know some suggestion to work this.
> > >
> > > Thanks and again as always appreciate complete reviews,
> > >
> > > Tanmay
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > > Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> > > > > > ---
> > > > > >  arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 28 ++++++++++++++++++++------
> > > > > >  1 file changed, 22 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > > > > index b61fc99cd911..01e12894c88e 100644
> > > > > > --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > > > > @@ -247,19 +247,35 @@ fpga_full: fpga-full {
> > > > > >           ranges;
> > > > > >   };
> > > > > >
> > > > > > - remoteproc {
> > > > > > + remoteproc@ffe00000 {
> > > > > >           compatible = "xlnx,zynqmp-r5fss";
> > > > > > -         xlnx,cluster-mode = <1>;
> > > > > > +         xlnx,cluster-mode = <0>;
> > > > > >
> > > > > > -         r5f-0 {
> > > > > > +         #address-cells = <2>;
> > > > > > +         #size-cells = <2>;
> > > > > > +
> > > > > > +         ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
> > > > > > +                  <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
> > > > > > +                  <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> > > > > > +                  <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> > > > > > +
> > > > > > +         r5f@0 {
> > > > > >                   compatible = "xlnx,zynqmp-r5f";
> > > > > > -                 power-domains = <&zynqmp_firmware PD_RPU_0>;
> > > > > > +                 reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
> > > > > > +                 reg-names = "atcm", "btcm";
> > > > > > +                 power-domains = <&zynqmp_firmware PD_RPU_0>,
> > > > > > +                                 <&zynqmp_firmware PD_R5_0_ATCM>,
> > > > > > +                                 <&zynqmp_firmware PD_R5_0_BTCM>;
> > > > > >                   memory-region = <&rproc_0_fw_image>;
> > > > > >           };
> > > > > >
> > > > > > -         r5f-1 {
> > > > > > +         r5f@1 {
> > > > > >                   compatible = "xlnx,zynqmp-r5f";
> > > > > > -                 power-domains = <&zynqmp_firmware PD_RPU_1>;
> > > > > > +                 reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> > > > > > +                 reg-names = "atcm", "btcm";
> > > > > > +                 power-domains = <&zynqmp_firmware PD_RPU_1>,
> > > > > > +                                 <&zynqmp_firmware PD_R5_1_ATCM>,
> > > > > > +                                 <&zynqmp_firmware PD_R5_1_BTCM>;
> > > > > >                   memory-region = <&rproc_1_fw_image>;
> > > > > >           };
> > > > > >   };
> > > > > > --
> > > > > > 2.25.1
> > > > > >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-10-03 15:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 15:58 [PATCH v5 0/4] add zynqmp TCM bindings Tanmay Shah
2023-09-28 15:58 ` [PATCH v5 1/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings Tanmay Shah
2023-09-28 15:58 ` [PATCH v5 2/4] dts: zynqmp: add properties for TCM in remoteproc Tanmay Shah
2023-10-02 15:55   ` Mathieu Poirier
2023-10-02 16:25     ` Tanmay Shah
2023-10-02 17:12       ` Tanmay Shah
2023-10-02 20:17         ` Mathieu Poirier
2023-10-02 20:54           ` Tanmay Shah
2023-10-03 15:31             ` Mathieu Poirier [this message]
2023-10-03 16:32               ` Tanmay Shah
2023-09-28 15:58 ` [PATCH v5 3/4] remoteproc: zynqmp: add pm domains support Tanmay Shah
2023-10-02 17:11   ` Mathieu Poirier
2023-10-02 20:39     ` Tanmay Shah
2023-09-28 15:59 ` [PATCH v5 4/4] remoteproc: zynqmp: parse TCM from device tree Tanmay Shah
2023-10-02 17:39   ` Mathieu Poirier

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=ZRwz6cEqnnwoVhTD@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=andersson@kernel.org \
    --cc=ben.levinsky@amd.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=robh+dt@kernel.org \
    --cc=tanmay.shah@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).