Re: [PATCH v4 4/4] dt-bindings: dsp: fsl: update binding document for remote proc driver

From: Shengjiu Wang
Date: Sun Sep 12 2021 - 22:50:17 EST


Hi Rob

On Sat, Sep 11, 2021 at 5:43 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Sep 08, 2021 at 05:10:55PM +0800, Shengjiu Wang wrote:
> > As there are two drivers for DSP on i.MX, one is for sound open
> > firmware, another is for remote processor framework. In order to
> > distinguish two kinds of driver, defining different compatible strings.
>
> What determines which firmware is used? Is it tied to the board? Or for
> a given board, users could want different firmware? In the latter case,
> this configuration should not be in DT.

The compatible string determines which firmware is used.
For a given board, users could want different firmware, then need
to reboot the kernel and switch to another DTB.

>
> > For remote proc driver, the properties firmware-name and fsl,dsp-ctrl
> > are needed and the mailbox channel is different with SOF.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> > ---
> > .../devicetree/bindings/dsp/fsl,dsp.yaml | 81 +++++++++++++++++--
> > 1 file changed, 75 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
> > index 7afc9f2be13a..51ea657f6d42 100644
> > --- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
> > +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
> > @@ -8,6 +8,7 @@ title: NXP i.MX8 DSP core
> >
> > maintainers:
> > - Daniel Baluta <daniel.baluta@xxxxxxx>
> > + - Shengjiu Wang <shengjiu.wang@xxxxxxx>
> >
> > description: |
> > Some boards from i.MX8 family contain a DSP core used for
> > @@ -19,6 +20,10 @@ properties:
> > - fsl,imx8qxp-dsp
> > - fsl,imx8qm-dsp
> > - fsl,imx8mp-dsp
> > + - fsl,imx8qxp-hifi4
> > + - fsl,imx8qm-hifi4
> > + - fsl,imx8mp-hifi4
> > + - fsl,imx8ulp-hifi4
> >
> > reg:
> > maxItems: 1
> > @@ -28,37 +33,63 @@ properties:
> > - description: ipg clock
> > - description: ocram clock
> > - description: core clock
> > + - description: debug interface clock
> > + - description: message unit clock
> > + minItems: 3
> > + maxItems: 5
> >
> > clock-names:
> > items:
> > - const: ipg
> > - const: ocram
> > - const: core
> > + - const: debug
> > + - const: mu
> > + minItems: 3
> > + maxItems: 5
> >
> > power-domains:
> > description:
> > List of phandle and PM domain specifier as documented in
> > Documentation/devicetree/bindings/power/power_domain.txt
> > + minItems: 1
> > maxItems: 4
>
> How does the same h/w have different number of power domains?

For different SoC, the integration is different, on i.MX8QM/8QXP, there are
4 power-domains for DSP, but on i.MX8MP, there are 1 power-domain.

>
> >
> > mboxes:
> > description:
> > List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
> > + or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
> > (see mailbox/fsl,mu.txt)
> > + minItems: 3
> > maxItems: 4
> >
> > mbox-names:
> > - items:
> > - - const: txdb0
> > - - const: txdb1
> > - - const: rxdb0
> > - - const: rxdb1
> > + oneOf:
> > + - items:
> > + - const: txdb0
> > + - const: txdb1
> > + - const: rxdb0
> > + - const: rxdb1
> > + - items:
> > + - const: tx
> > + - const: rx
> > + - const: rxdb
>
> These are completely different mailboxes?

It is the same mailbox, for this mailbox, there are 16 channels
(4 for tx, 4 for rx, 4 for txdb, 4 for rxdb).
For sound open firmware and remoteproc firmware, they
use different mailbox channels.

>
> >
> > memory-region:
> > description:
> > phandle to a node describing reserved memory (System RAM memory)
> > used by DSP (see bindings/reserved-memory/reserved-memory.txt)
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 4
> > +
> > + firmware-name:
> > + description: |
> > + Default name of the firmware to load to the remote processor.
> > +
> > + fsl,dsp-ctrl:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Phandle to syscon block which provide access for processor enablement
>
> Curious, how is this done with the open sound f/w?

Currently the code for this in sound open firmware is not upsteamed,
I think this phandle is also applied for sound open firmware.

By the way, Should I separate the change of this file from this
patch series? Does it belong to your linux tree?


Best Regards
Wang Shengjiu