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

From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: Suman Anna <s-anna@ti.com>,
	Bjorn Andersson <bjorn.andersson@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, stefanos@xilinx.com,
	BLEVINSK@xilinx.com
Subject: Re: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
Date: Thu, 16 Jul 2020 11:19:03 -0600	[thread overview]
Message-ID: <20200716171903.GA3286345@xps15> (raw)
In-Reply-To: <20200714171553.GA2522956@bogus>

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