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
