[PATCH v2 1/4] dt-binding: remoteproc: Introduce ADSP loader binding

[Bjorn Andersson]

On Tue 23 Aug 11:57 PDT 2016, Bjorn Andersson wrote:

> On Tue 23 Aug 11:31 PDT 2016, Rob Herring wrote:
> 
> > On Mon, Aug 22, 2016 at 10:57:43PM -0700, Bjorn Andersson wrote:
> > > This document defines the binding for a component that loads firmware
> > > and control the life cycle of the Qualcomm ADSP core.
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> > > ---
> > > 
> > > Changes since v1:
> > > - Added platform names to compatibility
> > > 
> > >  .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 70 ++++++++++++++++++++++
> > >  1 file changed, 70 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > new file mode 100644
> > > index 000000000000..3820151ce3e9
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > @@ -0,0 +1,70 @@
> > > +Qualcomm ADSP Peripheral Image Loader
> > > +
> > > +This document defines the binding for a component that loads and boots firmware
> > > +on the Qualcomm ADSP core.
> > 
> > ADSP is for Audio DSP? So there is another driver for the audio 
> > functions? Why doesn't it do the firmware loading? I'm still confused 
> > why this binding is separate? If you had one common interface (a rproc) 
> > to load and boot various other blocks like ADSP and Venus, then this 
> > would make sense.

> > Or does every accel block have some separate control 
> > uC associated with it?

Sorry for the lengthy explanation below, in case you rather want a
TL;DR:

This is not an accel block, it's a general purpose CPU exposing among
other thing audio related services.

> > 
> 
> The ADSP is a general purpose CPU [1] mainly running services related to
> audio handling - including controlling audio paths, driving the audio
> blocks, audio effects, audio codec decoding.
> 
> On some platforms it also sports services for sensor batch offloading
> (or whatever Google calls it) and video decoding for certain codecs.
> 
> All these services show up in a semi-probable fashion on other buses;
> often on SMD, APR, QRTR.
> 
> 
> There are a few blocks that share mechanism with the remoteproc, that
> does not have a separate uC - with a destinct life cycle - I'm still
> investigating how to describe these, but most likely those cases will
> not show up in DT at all.
> 
> On msm8916 you have the following additional uCs; RPM, Hexagon, Wireless
> and Venus; the RPM is always-on.
> 
> On msm8960 we have the following uCs; RPM, Hexagon for audio, DSPS (ARM
> for sensor processing), two(?) Hexagons for modem, WCNSS (ARM core for
> wireless), Venus (seems to be another ARM core) and an optional ARM core
> for GPS if you don't have the modem Hexagons.
> 
> So, we have between 4 and 8 extra uCs in these SoCs; most are controlled
> in a very similar fashion, but requires different resources and some
> tweaks to the steps of bringing them up, down and handling crashes.
> 
> Downstream this is handled by having a "rproc" driver that's completely
> generic, DT provides lists of resources controlling each step and a
> callback mechanism is used to extend the rproc drivers with specific
> functionality - it took me months to figure out how to boot the WCNSS
> because the logic and resources are scattered throughout.
> 
> [1] https://en.wikipedia.org/wiki/Qualcomm_Hexagon
> 

Rob, did this answer your questions, do you find this acceptable or do
you have any suggestion to how I should model this?

Regards,
Bjorn