lkml.org 
[lkml]   [2016]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/4] dt-binding: remoteproc: Introduce ADSP loader binding
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@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

\
 
 \ /
  Last update: 2016-09-17 09:58    [W:0.059 / U:1.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site