Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1459502 > unrolled thread

[PATCH] dt-binding: remoteproc: Document generic properties

Started byBjorn Andersson <bjorn.andersson@linaro.org>
First post2016-08-10 20:50 +0200
Last post2016-08-13 00:50 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] dt-binding: remoteproc: Document generic properties Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-08-10 20:50 +0200
    Re: [PATCH] dt-binding: remoteproc: Document generic properties Rob Herring <robh@kernel.org> - 2016-08-12 20:40 +0200
      Re: [PATCH] dt-binding: remoteproc: Document generic properties Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-08-13 00:50 +0200

#1459502 — [PATCH] dt-binding: remoteproc: Document generic properties

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2016-08-10 20:50 +0200
Subject[PATCH] dt-binding: remoteproc: Document generic properties
Message-ID<s4GJI-j6-41@gated-at.bofh.it>
This documents the generic properties "rprocs" and "rproc-names", used
for consumer drivers to reference a remoteproc node.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 .../devicetree/bindings/remoteproc/remoteproc.txt   | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/remoteproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/remoteproc.txt
new file mode 100644
index 000000000000..0b1d8183be87
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/remoteproc.txt
@@ -0,0 +1,21 @@
+Common remoteproc properties
+
+A remoteproc node represents the mechanism and resources needed for controlling
+a co-processor's life cycle; including loading firmware, booting, shutting down
+and handling exceptions.
+
+
+= Consumer properties
+A consumer node referencing a remoteproc node, so that it can requests life
+cycle transitions can use the following properties:
+
+- rprocs:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: a list of phandle references to remoteproc nodes
+
+- rproc-names:
+	Usage: optional
+	Value type: <stringlist>
+	Definition: a list of strings naming each entry in "rprocs", allowing
+		    consumer drivers to look up remoteprocs by name
-- 
2.5.0

[toc] | [next] | [standalone]


#1461377

FromRob Herring <robh@kernel.org>
Date2016-08-12 20:40 +0200
Message-ID<s5px8-5jJ-21@gated-at.bofh.it>
In reply to#1459502
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.

Rob

[toc] | [prev] | [next] | [standalone]


#1461503

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2016-08-13 00:50 +0200
Message-ID<s5tr3-7Vp-7@gated-at.bofh.it>
In reply to#1461377
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.

Regards,
Bjorn

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web