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

[Daniel Baluta <daniel.baluta@gmail.com>]

On Sat, Sep 11, 2021 at 12:45 AM Rob Herring <robh@kernel.org> 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.
>
> > 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@nxp.com>
> > ---
> >  .../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@nxp.com>
> > +  - Shengjiu Wang <shengjiu.wang@nxp.com>
> >
> >  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?
>
> >
> >    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?
>
> >
> >    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?

Hi Rob,

Should be the same story. Here is the PR sent for review with Sound
Open Firmware (SOF):

https://github.com/thesofproject/linux/pull/3156

The only difference is that SOF uses:
syscon_regmap_lookup_by_compatible while remoteproc driver uses
syscon_regmap_lookup_by_phandle.

thanks,
Daniel.