mbox series

[v4,0/4] TI K3 R5F remoteproc support

Message ID 20200908174556.21277-1-s-anna@ti.com (mailing list archive)
Headers show
Series TI K3 R5F remoteproc support | expand

Message

Suman Anna Sept. 8, 2020, 5:45 p.m. UTC
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. How can we
take this series forward? It is blocking us to get the various usecases that
leverage the remoteprocs upstream.

regards
Suman

[1] R5F v1: https://patchwork.kernel.org/cover/11456367/
[2] R5F v2: https://patchwork.kernel.org/cover/11632993/
[3] R5F v3: https://patchwork.kernel.org/cover/11679327/
[4] https://patchwork.kernel.org/patch/11632997/

Suman Anna (4):
  dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
  remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem
  remoteproc: k3-r5: Initialize TCM memories for ECC
  remoteproc: k3-r5: Add loading support for on-chip SRAM regions

 .../bindings/remoteproc/ti,k3-r5f-rproc.yaml  |  281 ++++
 drivers/remoteproc/Kconfig                    |   13 +
 drivers/remoteproc/Makefile                   |    1 +
 drivers/remoteproc/ti_k3_r5_remoteproc.c      | 1395 +++++++++++++++++
 4 files changed, 1690 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
 create mode 100644 drivers/remoteproc/ti_k3_r5_remoteproc.c

Comments

Rob Herring (Arm) Sept. 22, 2020, 7:47 p.m. UTC | #1
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. 

Why not? I'm pretty sure lockstep or not is a thing for both and TCMs 
seem to be a common thing.

And I don't really think System DT will not impact it. Though it's not 
well enough defined to say either way IMO.

But if Bjorn wants to take this, fine. I'm not acking it though nor 
worrying about it for any compatibility with system DT.

Rob
Suman Anna Sept. 22, 2020, 8:26 p.m. UTC | #2
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