linux-remoteproc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Rob Herring <robh@kernel.org>
Cc: 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>, <tomase@xilinx.com>
Subject: Re: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
Date: Mon, 27 Jul 2020 17:39:11 -0500	[thread overview]
Message-ID: <b7415d48-a354-5610-a657-08cdefc482a6@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2007161232400.3886@sstabellini-ThinkPad-T480s>

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

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.

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


  reply	other threads:[~2020-07-27 22:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30  2:49 [PATCH v2 0/4] TI K3 R5F remoteproc support Suman Anna
2020-06-30  2:49 ` [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna
2020-07-14 17:15   ` Rob Herring
2020-07-16 17:19     ` Mathieu Poirier
2020-07-16 19:43       ` Stefano Stabellini
2020-07-27 22:39         ` Suman Anna [this message]
2020-08-10 16:52           ` Suman Anna
2020-08-20 21:53             ` Suman Anna
2020-08-24 20:42               ` Ben Levinsky
2020-06-30  2:49 ` [PATCH v2 2/4] remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna
2020-07-09 18:10   ` Mathieu Poirier
2020-07-09 22:02     ` Suman Anna
2020-06-30  2:49 ` [PATCH v2 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Suman Anna
2020-07-09 19:29   ` Mathieu Poirier
2020-06-30  2:49 ` [PATCH v2 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Suman Anna
2020-07-09 19:51   ` Mathieu Poirier

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=b7415d48-a354-5610-a657-08cdefc482a6@ti.com \
    --to=s-anna@ti.com \
    --cc=BLEVINSK@xilinx.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 \
    --cc=stefano.stabellini@xilinx.com \
    --cc=stefanos@xilinx.com \
    --cc=tomase@xilinx.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).