On Thu 08 Sep 19:33 PDT 2016, Rob Herring wrote: > On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna <s-anna@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
