From: Suman Anna <s-anna@ti.com> To: Rob Herring <robh@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Lokesh Vutla <lokeshvutla@ti.com>, <linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 0/4] TI K3 R5F remoteproc support Date: Tue, 22 Sep 2020 15:26:05 -0500 [thread overview] Message-ID: <f5c8b7f1-1ac6-2134-89da-d1b91d4643bf@ti.com> (raw) In-Reply-To: <20200922194753.GA3105316@bogus> Hi Rob, On 9/22/20 2:47 PM, Rob Herring wrote: > On Tue, Sep 08, 2020 at 12:45:52PM -0500, Suman Anna wrote: >> Hi All, >> >> The following is v4 of the TI K3 R5F remoteproc driver series supporting all >> the R5F processor clusters/subsystems on TI AM65x and J721E SoCs. Please >> see the v1 cover-letter [1] for the features supported on these R5F processors. >> >> This series is a rebased version on top of the latest v5.9-rc baseline and >> includes very minor fixes w.r.t v3. The previous K3 DSP dependencies are now >> available in mainline kernel. Please see the individual patches for the delta >> differences (Only patches 1 and 2 updated). >> >> Bjorn, >> This series is only waiting on bindings ack and the conclusion on the bindings >> discussion from v2 [4] on which I haven't seen any forward progress on this >> despite all the clarifications. I do not expect any changes even w.r.t System DT, >> and we can't really have a common binding between TI and Xilinx R5Fs. > First of all, thank you for reviewing this and your response. > Why not? I'm pretty sure lockstep or not is a thing for both and TCMs > seem to be a common thing. The cluster mode is a common theme, and if you have a preference for a common property-name, both I and Ben can use that. The values though might vary between different vendor SoCs. I have given out all the differences and reasons on a v2 thread, the SoC and clock and reset integration aspects make it look very different. Please see the discussion here, https://patchwork.kernel.org/comment/23560321/ There was only one open comment/question I had regarding Core identification w.r.t my binding. Do you prefer a node-name index difference or a separate core-id/cpu-id property identifying which is Core0 and Core1. > > And I don't really think System DT will not impact it. Though it's not > well enough defined to say either way IMO. Yeah agreed. But the current architecture in System DT does allow you to add plugins to generate the proper compliant dts node. In anycase, I doubt TI will ever be using it in general, because we do not have a concept of DT on our firmwares. I have given all these inputs again on v2, but haven't seen any responses on it. So, I do appreciate your feedback. > > But if Bjorn wants to take this, fine. I'm not acking it though nor > worrying about it for any compatibility with system DT. Any specific reasons? For the most part, I am using all standard properties. regards Suman
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com> To: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org, Mathieu Poirier <mathieu.poirier@linaro.org>, Lokesh Vutla <lokeshvutla@ti.com>, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson <bjorn.andersson@linaro.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 0/4] TI K3 R5F remoteproc support Date: Tue, 22 Sep 2020 15:26:05 -0500 [thread overview] Message-ID: <f5c8b7f1-1ac6-2134-89da-d1b91d4643bf@ti.com> (raw) In-Reply-To: <20200922194753.GA3105316@bogus> Hi Rob, On 9/22/20 2:47 PM, Rob Herring wrote: > On Tue, Sep 08, 2020 at 12:45:52PM -0500, Suman Anna wrote: >> Hi All, >> >> The following is v4 of the TI K3 R5F remoteproc driver series supporting all >> the R5F processor clusters/subsystems on TI AM65x and J721E SoCs. Please >> see the v1 cover-letter [1] for the features supported on these R5F processors. >> >> This series is a rebased version on top of the latest v5.9-rc baseline and >> includes very minor fixes w.r.t v3. The previous K3 DSP dependencies are now >> available in mainline kernel. Please see the individual patches for the delta >> differences (Only patches 1 and 2 updated). >> >> Bjorn, >> This series is only waiting on bindings ack and the conclusion on the bindings >> discussion from v2 [4] on which I haven't seen any forward progress on this >> despite all the clarifications. I do not expect any changes even w.r.t System DT, >> and we can't really have a common binding between TI and Xilinx R5Fs. > First of all, thank you for reviewing this and your response. > Why not? I'm pretty sure lockstep or not is a thing for both and TCMs > seem to be a common thing. The cluster mode is a common theme, and if you have a preference for a common property-name, both I and Ben can use that. The values though might vary between different vendor SoCs. I have given out all the differences and reasons on a v2 thread, the SoC and clock and reset integration aspects make it look very different. Please see the discussion here, https://patchwork.kernel.org/comment/23560321/ There was only one open comment/question I had regarding Core identification w.r.t my binding. Do you prefer a node-name index difference or a separate core-id/cpu-id property identifying which is Core0 and Core1. > > And I don't really think System DT will not impact it. Though it's not > well enough defined to say either way IMO. Yeah agreed. But the current architecture in System DT does allow you to add plugins to generate the proper compliant dts node. In anycase, I doubt TI will ever be using it in general, because we do not have a concept of DT on our firmwares. I have given all these inputs again on v2, but haven't seen any responses on it. So, I do appreciate your feedback. > > But if Bjorn wants to take this, fine. I'm not acking it though nor > worrying about it for any compatibility with system DT. Any specific reasons? For the most part, I am using all standard properties. regards Suman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-22 22:14 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-08 17:45 [PATCH v4 0/4] TI K3 R5F remoteproc support Suman Anna 2020-09-08 17:45 ` Suman Anna 2020-09-08 17:45 ` [PATCH v4 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna 2020-09-08 17:45 ` Suman Anna 2020-09-08 17:45 ` [PATCH v4 2/4] remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna 2020-09-08 17:45 ` Suman Anna 2020-09-08 17:45 ` [PATCH v4 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Suman Anna 2020-09-08 17:45 ` Suman Anna 2020-09-08 17:45 ` [PATCH v4 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Suman Anna 2020-09-08 17:45 ` Suman Anna 2020-09-22 19:47 ` [PATCH v4 0/4] TI K3 R5F remoteproc support Rob Herring 2020-09-22 19:47 ` Rob Herring 2020-09-22 20:26 ` Suman Anna [this message] 2020-09-22 20:26 ` Suman Anna
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=f5c8b7f1-1ac6-2134-89da-d1b91d4643bf@ti.com \ --to=s-anna@ti.com \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=mathieu.poirier@linaro.org \ --cc=robh@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: linkBe 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.