From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B6A28E7AD72 for ; Tue, 3 Oct 2023 15:32:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DyYNp7AD2inWtVn2ZnhUnrJTQYUwJsUXLHk/WK6PNVc=; b=f02E2GyMOl865w JsaBYsccVQ3juY1H1wwtFVjgYBLuzT59NscVLl4LT+WmBqGEUXA+uoBY0VhJCYFf5AFHpZSsAm6x6 bXQ1eBmtCjwa2AJ15/lmDvQ07EG0S8nimGJDATPOBYTX1I8MEE97T+2rZ2fG7IL1xJKx+0hGOe2il T7NVUFRnXfXq8NFG5zhu/r9/D/QZDGHXPGfpadg/+16saL+EGqCZf/hZLWwIZmkTzOW4fYRD1uRxc TgY3UdJTOtbS5vn4hLXCs8Kzye48lxoN8EsErHWK0Mw0uLGvGqKCbwlVTKvtOKMTUiDgNZvaGV7tw Y+o/W8gRE7usc2DapJGg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qnhNU-00Esr7-1O; Tue, 03 Oct 2023 15:32:04 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qnhNR-00Esq9-0W for linux-arm-kernel@lists.infradead.org; Tue, 03 Oct 2023 15:32:03 +0000 Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1c737d61a00so8010565ad.3 for ; Tue, 03 Oct 2023 08:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696347116; x=1696951916; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=JgFH5NwUbK2OgByiHoMyi+OT+Yz0b1HGMb3DRsXt+P8=; b=NU2aKaqEFe1uT0pIdonF4CiXAKbQ3/3juhXQh6p9RVT3EpPyaYfT8iT6kCiIQWfGO+ OJXNRDCE9PRLgwNxhAY1lTRKpQAyXRFGiTpzP1yWk5z5U+0801jqt5YanhuiURNz8I51 3ncZpeSCZjEb6TJc5XdKT/BBKmnfUQqHd10xmNTbESEFRhjaBgv1YbqOyv+RNNzF6Qwe 7NofI69f7y+Fc+xNN+wkmIXij6iYYXFMjbLcXxi/2ObpEfJTEWoO0ZXbFeyIG2J5z0hl 0ByfkYFGuL7ZdR7TPRc77x0jHOFCvaqWSUrdqIUa55R4s9BeP/Z/A+2Gq8FR92rc7YSL LLhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696347116; x=1696951916; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JgFH5NwUbK2OgByiHoMyi+OT+Yz0b1HGMb3DRsXt+P8=; b=NThgGirIo+TfBO5Xmiv3cpNh2LKGn1JUTVVI8foGo8sI7pN9xN+VZR3aSEAWzvRlMW KSolY0cJyxp/pnFN/X0CnOrncWc+MccgdCy/KPhua9kc+F8gadPAdRS7M1FgtTLTLRqO 4UGoMlvjBcbk0OmjFEzfiL9wk5QsF9zSu5rTckQygrn/QmhCqpTNX6FmYp66Uwmk+mW0 F+SfwR5SfM9a3QmHgaq7A5hV8qIivRZp/dwZGpwLFUv2ZAL7hnQoXHBMWR8vCpZspEb1 ugFIwlaciR0qWAQUdCcBHpJmtn5O1grpFUhFqKpCmFWXNSTQGSbbx3hQlGYYqZDAZS+O 39lA== X-Gm-Message-State: AOJu0YzLoCvAPG1/Rlwt4rnp/nbMnKMV4z+aWVORb3XyB+WV0uuqplR8 /7GQhqpiWD9BKs78zsODWn7C+w== X-Google-Smtp-Source: AGHT+IGRMumZcYP3SEvpyIBqb+ovY7V32/oSPiJp/UAs9NUXij2bg+Ae3yZfLAYx5xIqISFrS7vg1A== X-Received: by 2002:a17:902:7246:b0:1c5:df3f:89e5 with SMTP id c6-20020a170902724600b001c5df3f89e5mr14987462pll.62.1696347115702; Tue, 03 Oct 2023 08:31:55 -0700 (PDT) Received: from p14s ([2604:3d09:148c:c800:9379:e1e1:dd3c:a271]) by smtp.gmail.com with ESMTPSA id h11-20020a170902680b00b001c3e732b8dbsm1736267plk.168.2023.10.03.08.31.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 08:31:55 -0700 (PDT) Date: Tue, 3 Oct 2023 09:31:53 -0600 From: Mathieu Poirier To: Tanmay Shah 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 Message-ID: References: <20230928155900.3987103-1-tanmay.shah@amd.com> <20230928155900.3987103-3-tanmay.shah@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231003_083201_204776_23487AF1 X-CRM114-Status: GOOD ( 51.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 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. T= hat motivates to change > > > > > > > > this to split mode. > > > > > > > > > > > > Now changing this may not be problem for lot of people with followi= ng reasons. > > > > > > > > The firmwares that are only using first 64KB of TCM memory, they ca= n 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 no= des, 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 c= hange 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 patc= h with all above info in commit message. > > > > > > Something to add to this. So, let's say if we don't change it now, wh= at 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 wo= rk. > = > I have following idea. > = > So, if I understand this correctly, we introduce two separate nodes in de= vice-tree. > = > SOC dtsi file: zynqmp.dtsi > = > remoteproc_lockstep: remoteproc@... { > = > . . . > = > status =3D "disabled"; I don't think you need the "status" > = > }; > = > = > remoteproc_split: remoteproc@... { > = > =A0. . . > = > status =3D "disabled"; > = > }; > = > = > And then in board dts enable whatever mode is needed for that board: > = > *zcu102*.dts > = > &remoteproc_split { > = > status =3D "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 > > > > > > --- > > > > > > 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/arm6= 4/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 =3D "xlnx,zynqmp-r5fss"; > > > > > > - xlnx,cluster-mode =3D <1>; > > > > > > + xlnx,cluster-mode =3D <0>; > > > > > > > > > > > > - r5f-0 { > > > > > > + #address-cells =3D <2>; > > > > > > + #size-cells =3D <2>; > > > > > > + > > > > > > + ranges =3D <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 =3D "xlnx,zynqmp-r5f"; > > > > > > - power-domains =3D <&zynqmp_firmware PD_RPU_0>; > > > > > > + reg =3D <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0= x0 0x10000>; > > > > > > + reg-names =3D "atcm", "btcm"; > > > > > > + power-domains =3D <&zynqmp_firmware PD_RPU_0>, > > > > > > + <&zynqmp_firmware PD_R5_0_ATC= M>, > > > > > > + <&zynqmp_firmware PD_R5_0_BTC= M>; > > > > > > memory-region =3D <&rproc_0_fw_image>; > > > > > > }; > > > > > > > > > > > > - r5f-1 { > > > > > > + r5f@1 { > > > > > > compatible =3D "xlnx,zynqmp-r5f"; > > > > > > - power-domains =3D <&zynqmp_firmware PD_RPU_1>; > > > > > > + reg =3D <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0= x0 0x10000>; > > > > > > + reg-names =3D "atcm", "btcm"; > > > > > > + power-domains =3D <&zynqmp_firmware PD_RPU_1>, > > > > > > + <&zynqmp_firmware PD_R5_1_ATC= M>, > > > > > > + <&zynqmp_firmware PD_R5_1_BTC= M>; > > > > > > memory-region =3D <&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