| Message ID | 1470850622-29816-1-git-send-email-bjorn.andersson@linaro.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote: > 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? 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. > 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On 09/08/2016 11:50 AM, Rob Herring wrote: > On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote: >> 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? > > 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. > >> 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. regards Suman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna <s-anna@ti.com> wrote: > Hi Rob, > > On 09/08/2016 11:50 AM, Rob Herring wrote: >> On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote: >>> 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? >> >> 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. >>> 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 08 Sep 19:33 PDT 2016, Rob Herring wrote: > On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna <s-anna@ti.com> wrote: > > Hi Rob, > > > > On 09/08/2016 11:50 AM, Rob Herring wrote: > >> On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote: > >>> 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? > >> > >> 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. > For other's reference, we discussed two different cases: 1) The Qualcomm video accelerator; a single-use-case co-processor that when booted provides a video encoder & decoder. 2) The Qualcomm (A)DSP, a multipurpose generic DSP used for audio effects, audio control/routing, sensor offloading and general computational workloads. In #1 Rob's point is that there's only a single piece of hardware, so it should be described in a single node. I think it would be beneficial to represent this as two different nodes, one for the co-processor management and one for the video-related resources, but I need to investigate this a little bit more. In #2 we have the resources related to controlling the DSP and when booted the firmware presents the additional services in a probable manner; some of these services interacts with resources or provides resources and must as such be represented in DT. In either case there's no reason for me to reference a remoteproc instance - so far at least. There is a third case, which I have not researched fully yet, where we need to represent dependencies between remoteprocs; e.g. we must boot the audio DSP before booting the modem and if the DSP crashes we must restart the modem. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On 09/08/2016 09:33 PM, Rob Herring wrote: > On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna <s-anna@ti.com> wrote: >> Hi Rob, >> >> On 09/08/2016 11:50 AM, Rob Herring wrote: >>> On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote: >>>> 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? >>> >>> 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. > >>>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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