mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Ohad Ben-Cohen <ohad@wizery.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>
Subject: Re: [PATCH] dt-binding: remoteproc: Document generic properties
Date: Fri, 2 Sep 2016 16:45:45 -0500	[thread overview]
Message-ID: <46d4d351-336c-6d4f-b1b0-243cf3c5d68b@ti.com> (raw)
In-Reply-To: <20160812224223.GJ26240@tuxbot>

On 08/12/2016 05:42 PM, Bjorn Andersson wrote:
> On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote:
> 
>> On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote:
>>> This documents the generic properties "rprocs" and "rproc-names", used
>>> for consumer drivers to reference a remoteproc node.
>>
>> How do you intend to use this? I wonder if it would not be better to 
>> expose a remote proc with existing bindings for a particular purpose 
>> (e.g. clocks, resets, etc.) rather than a generic connection. The client 
>> side would have to have specific knowledge as to what functions the 
>> remote proc provides.
>>
> 
> The remoteproc node represents the mechanism and resources needed to
> control the life cycle a co-processor, e.g. loading, booting, shutting
> gown a video encoder/decoder.
> 
> The proposed reference allows a separate thingie to assert control of
> the life cycle of that co-processor.
> 
> 
> I acknowledge that in some cases there is a fine line between what is
> the life cycle management and what is the actual functionality
> implemented by that remote processor. But as the remoteproc mechanism is
> reusable between various use cases I think it makes sense to not describe
> them as one unit.

What's the current state of this patch, not officially acked yet right?

While we are at this, can we agree upon an alias stem name as well, we
can stick to "rproc". Otherwise, I can submit an incremental patch on
top of this along with the code that adds an API to retrieve it for
client users.

regards
Suman

  reply	other threads:[~2016-09-02 21:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10 17:37 Bjorn Andersson
2016-08-12 18:34 ` Rob Herring
2016-08-12 22:42   ` Bjorn Andersson
2016-09-02 21:45     ` Suman Anna [this message]
2016-09-08 16:50       ` Rob Herring
2016-09-08 18:32         ` Suman Anna
2016-09-09  2:33           ` Rob Herring
2016-09-09  3:36             ` Bjorn Andersson
2016-09-16 22:12             ` Suman Anna

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=46d4d351-336c-6d4f-b1b0-243cf3c5d68b@ti.com \
    --to=s-anna@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    --cc=robh@kernel.org \
    /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

all inboxes | Powered by JetHome®