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

On Tue 23 Aug 11:31 PDT 2016, Rob Herring wrote:

quoted

On Mon, Aug 22, 2016 at 10:57:43PM -0700, Bjorn Andersson wrote:

quoted

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 <redacted>
---

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.

quoted

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.

quoted

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