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

Hi Rob,

On 09/08/2016 09:33 PM, Rob Herring wrote:

On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna [off-list ref] wrote:

quoted

Hi Rob,

On 09/08/2016 11:50 AM, Rob Herring wrote:

quoted

On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote:

quoted

On 08/12/2016 05:42 PM, Bjorn Andersson wrote:

quoted

On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote:

quoted

On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote:

quoted

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?

Bjorn and I have discussed some, but probably needs more discussion.
This binding alone is simple enough, but I want to understand better how
it will be used and digesting all the QCom h/w is not simple.

OK, thanks. The binding has no bearing on Qcom h/w though.

Doesn't have to be QCom, I just want to see some user and understand the use.

quoted

quoted

quoted

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.

Any alias for this will be NAKed. My position on aliases is well
documented.

Hmm, I don't have the complete background/history on your stance. I do
have a need for identifying an exact remoteproc instance. How do you
propose I do that without aliases, and without adding a non-hw related
property to the DTS node? Like for example, we have 8 identical DSPs on
Keystone 2 Hawking SoCs, and I need to construct a firmware name based
on the instance id, and I cannot do this based on probe order.

If they are identical, then why do you care which firmware goes to
which DSP? Linux can decide the numbering. There must be some feature
that is different, and you should describe that.

The IPs are identical, but that doesn't imply that firmwares can be
dynamically allocated to any of those DSPs. The IPs integration on the
SoC will obviously be at different addresses, and can have different
I/Os. There will also be other system integration usage aspects
depending on what type of functionality is being provided by a DSP.  We
can have different peripherals being managed by different DSPs, and
different applications needing to communicate to a specific DSP based on
the functionality implemented within a firmware image etc.

regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html