| Message ID | 20230928155900.3987103-3-tanmay.shah@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | add zynqmp TCM bindings | expand |
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? > 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 >
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. 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. > > > 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 > >
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. > > 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? 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 > > >
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". > 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 > > > >
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"; }; remoteproc_split: remoteproc@... { . . . status = "disabled"; }; And then in board dts enable whatever mode is needed for that board: *zcu102*.dts &remoteproc_split { status = "okay"; }; 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 > > > > >
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 > > > > > >
On 10/3/23 10:31 AM, Mathieu Poirier wrote: > 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. Thanks for the suggestion. Yes I think if we don't include status then both nodes are enabled by default, and people can disable in board dts what they don't want. Instead I keep status disabled, for one of the node, (for split probably as lockstep is already enabled) and people can choose what they wnt. Thanks, Tanmay > > > > > 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 > > > > > > >
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>; }; };
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. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> --- arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 28 ++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-)