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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200716171903.GA3286345@xps15>
Date:   Thu, 16 Jul 2020 11:19:03 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Suman Anna <s-anna@...com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Lokesh Vutla <lokeshvutla@...com>,
        linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        stefanos@...inx.com, BLEVINSK@...inx.com
Subject: Re: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F
 subsystem on TI K3 SoCs

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@...com>
> > ---
> > 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.
> 
> 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.

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?

Thanks,
Mathieu 

> 
> Rob