RE: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

[Ben Levinsky]

> -----Original Message-----
> From: Suman Anna <s-anna@xxxxxx>
> Sent: Thursday, August 20, 2020 2:54 PM
> To: Stefano Stabellini <stefanos@xxxxxxxxxx>; Mathieu Poirier
> <mathieu.poirier@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Stefano
> Stabellini <stefanos@xxxxxxxxxx>; Ben Levinsky <BLEVINSK@xxxxxxxxxx>
> Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>; Lokesh Vutla
> <lokeshvutla@xxxxxx>; linux-remoteproc@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; Tomas Evensen <tomase@xxxxxxxxxx>
> Subject: Re: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F
> subsystem on TI K3 SoCs
> 
> Hi Rob,
> 
> On 8/10/20 11:52 AM, Suman Anna wrote:
> > Hi Rob,
> >
> > On 7/27/20 5:39 PM, Suman Anna wrote:
> >> Hi Rob,
> >>
> >> On 7/16/20 2:43 PM, Stefano Stabellini wrote:
> >>> On Thu, 16 Jul 2020, Mathieu Poirier wrote:
> >>>> Hi Rob,
> >>>>
> >>>> On Tue, Jul 14, 2020 at 11:15:53AM -0600, Rob Herring wrote:
> >>>>> On Mon, Jun 29, 2020 at 09:49:19PM -0500, Suman Anna wrote:
> >>>>>> The Texas Instruments K3 family of SoCs have one or more dual-core
> >>>>>> Arm Cortex R5F processor subsystems/clusters (R5FSS). The clusters
> >>>>>> can be split between multiple voltage domains as well. Add the device
> >>>>>> tree bindings document for these R5F subsystem devices. These R5F
> >>>>>> processors do not have an MMU, and so require fixed memory
> carveout
> >>>>>> regions matching the firmware image addresses. The nodes require
> more
> >>>>>> than one memory region, with the first memory region used for DMA
> >>>>>> allocations at runtime. The remaining memory regions are reserved
> >>>>>> and are used for the loading and running of the R5F remote
> processors.
> >>>>>> The R5F processors can also optionally use any internal on-chip SRAM
> >>>>>> memories either for executing code or using it as fast-access data.
> >>>>>>
> >>>>>> The added example illustrates the DT nodes for the single R5FSS
> device
> >>>>>> present on K3 AM65x family of SoCs.
> >>>>>>
> >>>>>> Signed-off-by: Suman Anna <s-anna@xxxxxx>
> >>>>>> ---
> >>>>>> v2:
> >>>>>>   - Renamed "lockstep-mode" property to "ti,cluster-mode"
> >>>>>
> >>>>> I don't think that's a move in the right direction given this is at
> >>>>> least partially a standard feature.
> >>>>>
> >>>>> As I said before, I'm very hesistant to accept anything here given I
> >>>>> know the desires and activity to define 'system Devicetrees' of which
> >>>>> TI is participating. While maybe an rproc node is sufficient for a
> >>>>> DSP, it seems multiple vendors have R cores and want to define them
> in
> >>>>> system DT.
> >>
> >> Ping on this discussion. TI is participating on the System DT evolution in
> general, but we don't have any plans to use DTS on our remote cores. We
> have our own auto-generated Chip-Support-Library (CSL) code that gets used
> on our firmwares.
> >>
> >> Also, most of the properties I defined are rather standard properties. I
> have posted a revised v3 [1] after the common ti,sci properties refactoring.
> This series is only waiting on the bindings. I am happy to change any ti,
> prefixed properties. I had one open question [2] that I am waiting for a
> response from you for identifying the R5F Core.
> >
> > Ping on this.
> 
> Any comments on this? This discussion is what's holding up this series from
> getting merged.
> 
> Also, FWIW, I spent a bit of time looking at the R5s (called RPU) in the Xilinx
> ZynqMP, and the integration aspects are very different between the TI and
> Xilinx
> SoCs, so I do not think even a single binding is possible between the two
> SoCs.
> A few of them to cite:
> 
> 1. TI SoCs require the power/resets to be released for both the Cores in
> LockStep-mode, while it was enough to just release the Core0 resets on
> ZynqMP.
> So, our binding requires that both CPUs be defined for sure as the reset
> controls are defined per core, while you don't see them on the RPU.
> 
> 2. There are specific core reset sequences on TI SoCs in LockStep and
> Split-modes on TI SoCs, I am not sure if there are any with Xilinx SoCs.
> 
> 3. The TCMs are embedded within the R5F sub-system on TI SoCs, and are
> controlled by the same power and clock as the R5Fs. There is an additional
> CPU
> halt line that controls the core execution, and allows us to enable the access
> to these. The ZynqMP looks to have completely independent control to the
> TCMs.
> This is the reason why they are represented as individual mmio-sram nodes in
> the
> Xilinx binding.
> 
> 4. The TCMs and which one appears at the R5 address 0 are programmable on
> TI
> SoCs, I couldn't tell if this is the case with Xilinx SoCs.
> 
> Ben and Stefano,
> Please do clarify, if I am off on any of the above differences.
> 
[Ben Levinsky] Hi Suman, 

what you said is correct. 

Thanks
> regards
> Suman
> 
> 
> >
> > regards
> > Suman
> >
> >>
> >> regards
> >> Suman
> >>
> >> [1] https://patchwork.kernel.org/patch/11679331/
> >> [2] https://patchwork.kernel.org/comment/23273441/
> >>
> >>>>>
> >>>>> Though the system DT effort has not yet given any thought to what is
> the
> >>>>> view of one processor or instance to another instance (which is what
> >>>>> this binding is). We'll still need something defined for that, but I'd
> >>>>> expect that to be dependent on what is defined for system DT.
> >>>>
> >>>> Efforts related to the definition of the system DT are under way,
> something I
> >>>> expect to keep going on for some time to come.  I agree with the need to
> use the
> >>>> system DT to define remote processors and I look forward to the time
> we can do
> >>>> so.
> >>>
> >>> I'll take this opportunity to add that I should be able to publicly
> >>> present a System Device Tree proposal for this during the next call (the
> >>> next one after the call early next week that has already a full agenda.)
> >>>
> >>>
> >>>> That being said we need to find a concensus on how to move forward
> with patches
> >>>> that are ready to be merged.  What is your opinion on that?
> >>>
> >>> In my opinion we don't have to necessarily wait for System Device Tree
> >>> to make progress with those if they look OK.
> >>>
> >>
> >