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@xxxxxxxxxx> > > --- > > > > 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? > 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 Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
