| Message ID | 87y0wa9mb2.wl-kuninori.morimoto.gx@renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ASoC: add Renesas MSIOF sound driver | expand |
On 09/04/2025 03:05, Kuninori Morimoto wrote: > Renesas MSIOF (Clock-Synchronized Serial Interface with FIFO) can work as > both SPI and I2S. MSIOF-I2S will use Audio Graph Card/Card2 driver which > uses Of-Graph in DT. > Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. For bindings, the preferred subjects are explained here: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters A nit, subject: drop second/last, redundant "Documentation". The "dt-bindings" prefix is already stating that these are documentation. See also: https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 > MSIOF-SPI/I2S are using same DT compatible properties. > MSIOF-I2S uses Of-Graph for Audio-Graph-Card/Card2, > MSIOF-SPI doesn't use Of-Graph. > > Adds MSIOF-I2S documentation for Sound. > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > --- > .../bindings/sound/renesas,msiof.yaml | 112 ++++++++++++++++++ > 1 file changed, 112 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/renesas,msiof.yaml > > diff --git a/Documentation/devicetree/bindings/sound/renesas,msiof.yaml b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml > new file mode 100644 > index 000000000000..5173e80698fb > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml > @@ -0,0 +1,112 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/sound/renesas,msiof.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas MSIOF I2S controller > + > +maintainers: > + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > + > +# sharing with MSIOF SPI > +# see > +# ${LINUX}/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml > +select: > + properties: > + compatible: > + contains: > + pattern: "renesas,.*-msiof" > + required: > + - compatible > + - port Drop entire select. > + > +properties: > + compatible: > + items: > + - const: renesas,msiof-r8a779g0 # R-Car V4H Use expected format of all soc compatibles. It has been always: SoC-module. > + - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 If you have duplicated compatibles then: 1. It rarely makes sense because you claim that two different devices are using the same compatible. Different device, different compatible. 2. Or if this is really same device, then only one schema. > + > + reg: > + minItems: 1 > + maxItems: 2 Drop these two. > + oneOf: Why is this flexible? > + - items: > + - description: CPU and DMA engine registers > + - items: > + - description: CPU registers > + - description: DMA engine registers > + > + interrupts: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + power-domains: > + maxItems: 1 > + > + resets: > + maxItems: 1 > + > + dmas: > + minItems: 2 > + maxItems: 4 Why flexible? > + > + dma-names: > + minItems: 2 > + maxItems: 4 > + items: > + enum: [ tx, rx ] How would that work? tx rx tx rx? And then driver requests 'tx' (by name) and what is supposed to be returned? > + > + port: > + $ref: audio-graph-port.yaml#/definitions/port-base > + unevaluatedProperties: false > + patternProperties: > + "^endpoint(@[0-9a-f]+)?": > + $ref: audio-graph-port.yaml#/definitions/endpoint-base > + > +required: > + - compatible > + - reg > + - interrupts > + - clocks > + - power-domains > + - port > + > +unevaluatedProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h> > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/power/r8a779g0-sysc.h> > + > + dummy-codec { > + compatible = "test-codec"; > + > + port { > + codec_ep: endpoint { > + remote-endpoint = <&msiof1_snd_ep>; > + }; > + }; > + }; Drop, not related to the binding. > + > + msiof1: serial@e6ea0000 { serial means UART controller. You need name matching the class of the device. Node names should be generic. See also an explanation and list of examples (not exhaustive) in DT specification: https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > + compatible = "renesas,msiof-r8a779g0", > + "renesas,rcar-gen4-msiof"; > + reg = <0 0xe6ea0000 0 0x0064>; > + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 619>; > + dmas = <&dmac0 0x43>, <&dmac0 0x42>, > + <&dmac1 0x43>, <&dmac1 0x42>; > + dma-names = "tx", "rx", "tx", "rx"; So test it now - get DMA by name 'tx'. What do you get? Also schema should fail here. > + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>; > + resets = <&cpg 619>; > + > + port { > + msiof1_snd_ep: endpoint { > + remote-endpoint = <&codec_ep>; > + }; > + }; > + }; Best regards, Krzysztof
Hi Krzysztof, On Wed, 9 Apr 2025 at 08:37, Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 09/04/2025 03:05, Kuninori Morimoto wrote: > > Renesas MSIOF (Clock-Synchronized Serial Interface with FIFO) can work as > > both SPI and I2S. MSIOF-I2S will use Audio Graph Card/Card2 driver which > > uses Of-Graph in DT. > > > MSIOF-SPI/I2S are using same DT compatible properties. > > MSIOF-I2S uses Of-Graph for Audio-Graph-Card/Card2, > > MSIOF-SPI doesn't use Of-Graph. > > > > Adds MSIOF-I2S documentation for Sound. > > > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > > --- > > .../bindings/sound/renesas,msiof.yaml | 112 ++++++++++++++++++ > > 1 file changed, 112 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/renesas,msiof.yaml > > > > diff --git a/Documentation/devicetree/bindings/sound/renesas,msiof.yaml b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml > > new file mode 100644 > > index 000000000000..5173e80698fb > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml > > @@ -0,0 +1,112 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/sound/renesas,msiof.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Renesas MSIOF I2S controller > > + > > +maintainers: > > + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > > + > > +# sharing with MSIOF SPI > > +# see > > +# ${LINUX}/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml http://devicetree.org/schemas/spi/renesas,sh-msiof.yaml > > +select: > > + properties: > > + compatible: > > + contains: > > + pattern: "renesas,.*-msiof" > > + required: > > + - compatible > > + - port > > Drop entire select. This is needed to avoid matching when using the device in SPI mode. > > +properties: > > + compatible: > > + items: > > + - const: renesas,msiof-r8a779g0 # R-Car V4H > > Use expected format of all soc compatibles. It has been always: SoC-module. This is a pre-existing compatible value, so it cannot be changed. > > + - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 > > If you have duplicated compatibles then: > 1. It rarely makes sense because you claim that two different devices > are using the same compatible. Different device, different compatible. > 2. Or if this is really same device, then only one schema. This the same device, but it can be used in two (actually more) different modes: SPI and I2S. Hence it has two separate DT binding documents. If this needs to be merged (the result is gonna be ugly): where to fit it in the DT binding doc hierarchy? > > + reg: > > + minItems: 1 > > + maxItems: 2 > > Drop these two. > > > + oneOf: > > Why is this flexible? I am not sure where this is coming from (an old SH part?). The SPI bindings have the same construct. As this binding supports R-Car Gen4 only, a single reg should be fine. > > > + - items: > > + - description: CPU and DMA engine registers > > + - items: > > + - description: CPU registers > > + - description: DMA engine registers > > + dmas: > > + minItems: 2 > > + maxItems: 4 > > Why flexible? > > > + > > + dma-names: > > + minItems: 2 > > + maxItems: 4 > > + items: > > + enum: [ tx, rx ] > > How would that work? tx rx tx rx? And then driver requests 'tx' (by > name) and what is supposed to be returned? The module may be connected to one or more DMA controllers (see below). > > + > > + msiof1: serial@e6ea0000 { > > serial means UART controller. You need name matching the class of the > device. > Node names should be generic. See also an explanation and list of > examples (not exhaustive) in DT specification: > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation What is the recommend generic node name for a flexible serial device that can operate as (a.o.) either SPI or I2S controller? > > + compatible = "renesas,msiof-r8a779g0", > > + "renesas,rcar-gen4-msiof"; > > + reg = <0 0xe6ea0000 0 0x0064>; > > + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; > > + clocks = <&cpg CPG_MOD 619>; > > + dmas = <&dmac0 0x43>, <&dmac0 0x42>, > > + <&dmac1 0x43>, <&dmac1 0x42>; > > + dma-names = "tx", "rx", "tx", "rx"; > > So test it now - get DMA by name 'tx'. What do you get? A handle to either <&dmac0 0x43> or <&dmac1 0x43>; which one is random. It's been working like that for ages. Gr{oetje,eeting}s, Geert
On Wed, Apr 09, 2025 at 08:37:03AM GMT, Krzysztof Kozlowski wrote: > > + > > +properties: > > + compatible: > > + items: > > + - const: renesas,msiof-r8a779g0 # R-Car V4H > > > Use expected format of all soc compatibles. It has been always: SoC-module. ... unless this is an existing compatible, but then it should be in one schema, not two. Best regards, Krzysztof
On Wed, Apr 09, 2025 at 09:01:22AM GMT, Geert Uytterhoeven wrote: > > > +select: > > > + properties: > > > + compatible: > > > + contains: > > > + pattern: "renesas,.*-msiof" > > > + required: > > > + - compatible > > > + - port > > > > Drop entire select. > > This is needed to avoid matching when using the device in SPI mode. Which you need to avoid, so drop the select. One device, one schema. > > > > +properties: > > > + compatible: > > > + items: > > > + - const: renesas,msiof-r8a779g0 # R-Car V4H > > > > Use expected format of all soc compatibles. It has been always: SoC-module. > > This is a pre-existing compatible value, so it cannot be changed. > > > > + - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 > > > > If you have duplicated compatibles then: > > 1. It rarely makes sense because you claim that two different devices > > are using the same compatible. Different device, different compatible. > > 2. Or if this is really same device, then only one schema. > > This the same device, but it can be used in two (actually more) > different modes: SPI and I2S. Hence it has two separate DT binding > documents. If this needs to be merged (the result is gonna be ugly): ... then next time don't post incomplete bindings. I know we do not have time machine, but any mess is on contributors who posted some limited scope/view of the hardware entirely ignoring the rest of interfaces. > where to fit it in the DT binding doc hierarchy? Does not matter, whatever fits better in overal picture/purpose of this device. > > > > + reg: > > > + minItems: 1 > > > + maxItems: 2 > > > > Drop these two. > > > > > + oneOf: > > > > Why is this flexible? > > I am not sure where this is coming from (an old SH part?). > The SPI bindings have the same construct. As this binding supports > R-Car Gen4 only, a single reg should be fine. > > > > > > + - items: > > > + - description: CPU and DMA engine registers > > > + - items: > > > + - description: CPU registers > > > + - description: DMA engine registers > > > > + dmas: > > > + minItems: 2 > > > + maxItems: 4 > > > > Why flexible? > > > > > + > > > + dma-names: > > > + minItems: 2 > > > + maxItems: 4 > > > + items: > > > + enum: [ tx, rx ] > > > > How would that work? tx rx tx rx? And then driver requests 'tx' (by > > name) and what is supposed to be returned? > > The module may be connected to one or more DMA controllers (see below). Yes, but how the implementation would work? Anyway, this needs to be strictly ordered, not random rx rx tx tx or rx rx rx rx. > > > > + > > > + msiof1: serial@e6ea0000 { > > > > serial means UART controller. You need name matching the class of the > > device. > > Node names should be generic. See also an explanation and list of > > examples (not exhaustive) in DT specification: > > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > > What is the recommend generic node name for a flexible serial device > that can operate as (a.o.) either SPI or I2S controller? i2s or even not so generic msiof, but definitely not serial because that is reserved for UART. > > > > + compatible = "renesas,msiof-r8a779g0", > > > + "renesas,rcar-gen4-msiof"; > > > + reg = <0 0xe6ea0000 0 0x0064>; > > > + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 619>; > > > + dmas = <&dmac0 0x43>, <&dmac0 0x42>, > > > + <&dmac1 0x43>, <&dmac1 0x42>; > > > + dma-names = "tx", "rx", "tx", "rx"; > > > > So test it now - get DMA by name 'tx'. What do you get? > > A handle to either <&dmac0 0x43> or <&dmac1 0x43>; which one is > random. It's been working like that for ages. Interesting. And is this expected behavior? Driver does not care which RX and which TX it gets? Like RX from dmac0 and TX from dmac1? Best regards, Krzysztof
Hi Krzysztof, On Wed, 9 Apr 2025 at 09:52, Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Wed, Apr 09, 2025 at 09:01:22AM GMT, Geert Uytterhoeven wrote: > > > > +select: > > > > + properties: > > > > + compatible: > > > > + contains: > > > > + pattern: "renesas,.*-msiof" > > > > + required: > > > > + - compatible > > > > + - port > > > > > > Drop entire select. > > > > This is needed to avoid matching when using the device in SPI mode. > > Which you need to avoid, so drop the select. One device, one schema. OK... (to be read as "dot dot dot', really! ;-) > > > > +properties: > > > > + compatible: > > > > + items: > > > > + - const: renesas,msiof-r8a779g0 # R-Car V4H > > > > > > Use expected format of all soc compatibles. It has been always: SoC-module. > > > > This is a pre-existing compatible value, so it cannot be changed. > > > > > > + - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 > > > > > > If you have duplicated compatibles then: > > > 1. It rarely makes sense because you claim that two different devices > > > are using the same compatible. Different device, different compatible. > > > 2. Or if this is really same device, then only one schema. > > > > This the same device, but it can be used in two (actually more) > > different modes: SPI and I2S. Hence it has two separate DT binding > > documents. If this needs to be merged (the result is gonna be ugly): > > ... then next time don't post incomplete bindings. I know we do not have :-) > time machine, but any mess is on contributors who posted some limited > scope/view of the hardware entirely ignoring the rest of interfaces. This is the first time someone implemented I2S using MSIOF on a system intended to run Linux. Note that MSIOF is not even limited to SPI and I2S. It can be used as a generic synchronous serial interface, too. So far no one did under Linux, so it is not reflected yet in the bindings. MSIOF is also used to provide a clock signal to a PMIC on some older R-Car boards. As that PMIC has no upstream Linux driver, no one ever implemented support for this mode in Linux. So I guess I should be pro-active, and add #clock-cells to the unified MSIOF DT bindings, too? Note that there are other devices to consider, too. E.g. SCIF can not only be used as a UART, but also as a USART, SPI, or even I2C controller... (currently Linux with DT supports the UART personality only, but drivers/spi/spi-sh-sci.c does exist for SH). > > where to fit it in the DT binding doc hierarchy? > > Does not matter, whatever fits better in overal picture/purpose of this > device. OK, hence the existing SPI bindings.... > > > > + dmas: > > > > + minItems: 2 > > > > + maxItems: 4 > > > > > > Why flexible? > > > > > > > + > > > > + dma-names: > > > > + minItems: 2 > > > > + maxItems: 4 > > > > + items: > > > > + enum: [ tx, rx ] > > > > > > How would that work? tx rx tx rx? And then driver requests 'tx' (by > > > name) and what is supposed to be returned? > > > > The module may be connected to one or more DMA controllers (see below). > > Yes, but how the implementation would work? > > Anyway, this needs to be strictly ordered, not random rx rx tx tx or rx > rx rx rx. Why? > > > > + > > > > + msiof1: serial@e6ea0000 { > > > > > > serial means UART controller. You need name matching the class of the > > > device. > > > Node names should be generic. See also an explanation and list of > > > examples (not exhaustive) in DT specification: > > > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > > > > What is the recommend generic node name for a flexible serial device > > that can operate as (a.o.) either SPI or I2S controller? > > i2s > or even not so generic msiof, but definitely not serial because that is > reserved for UART. The MSIOF device node lives in the SoC-specific .dtsi file. Its use case is not known in that file, and specified only in the board .dts file. > > > > + compatible = "renesas,msiof-r8a779g0", > > > > + "renesas,rcar-gen4-msiof"; > > > > + reg = <0 0xe6ea0000 0 0x0064>; > > > > + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 619>; > > > > + dmas = <&dmac0 0x43>, <&dmac0 0x42>, > > > > + <&dmac1 0x43>, <&dmac1 0x42>; > > > > + dma-names = "tx", "rx", "tx", "rx"; > > > > > > So test it now - get DMA by name 'tx'. What do you get? > > > > A handle to either <&dmac0 0x43> or <&dmac1 0x43>; which one is > > random. It's been working like that for ages. > > Interesting. And is this expected behavior? Driver does not care which > RX and which TX it gets? Like RX from dmac0 and TX from dmac1? Exactly. This use case was one of the requirements when DMA support was DTified. Gr{oetje,eeting}s, Geert
On 09/04/2025 10:09, Geert Uytterhoeven wrote: >>>> >>>> If you have duplicated compatibles then: >>>> 1. It rarely makes sense because you claim that two different devices >>>> are using the same compatible. Different device, different compatible. >>>> 2. Or if this is really same device, then only one schema. >>> >>> This the same device, but it can be used in two (actually more) >>> different modes: SPI and I2S. Hence it has two separate DT binding >>> documents. If this needs to be merged (the result is gonna be ugly): >> >> ... then next time don't post incomplete bindings. I know we do not have > > :-) > >> time machine, but any mess is on contributors who posted some limited >> scope/view of the hardware entirely ignoring the rest of interfaces. > > This is the first time someone implemented I2S using MSIOF on a system > intended to run Linux. Note that MSIOF is not even limited to SPI and > I2S. It can be used as a generic synchronous serial interface, too. So So like a serial engine for UART/I2C/SPI? I think all or most of new SoCs since few years switched to these. > far no one did under Linux, so it is not reflected yet in the bindings. > MSIOF is also used to provide a clock signal to a PMIC on some older > R-Car boards. As that PMIC has no upstream Linux driver, no one ever > implemented support for this mode in Linux. So I guess I should be > pro-active, and add #clock-cells to the unified MSIOF DT bindings, too? Yes, probably. Although missing cells is easy to change but missing protocol, like this patchset here, is quite more challenging. > > Note that there are other devices to consider, too. E.g. SCIF can > not only be used as a UART, but also as a USART, SPI, or even I2C > controller... (currently Linux with DT supports the UART personality only, > but drivers/spi/spi-sh-sci.c does exist for SH). Just like all serial engines for all other SoCs and there are no problems with them... Why is this somehow different? > >>> where to fit it in the DT binding doc hierarchy? >> >> Does not matter, whatever fits better in overal picture/purpose of this >> device. > > OK, hence the existing SPI bindings.... > >>>>> + dmas: >>>>> + minItems: 2 >>>>> + maxItems: 4 >>>> >>>> Why flexible? >>>> >>>>> + >>>>> + dma-names: >>>>> + minItems: 2 >>>>> + maxItems: 4 >>>>> + items: >>>>> + enum: [ tx, rx ] >>>> >>>> How would that work? tx rx tx rx? And then driver requests 'tx' (by >>>> name) and what is supposed to be returned? >>> >>> The module may be connected to one or more DMA controllers (see below). >> >> Yes, but how the implementation would work? >> >> Anyway, this needs to be strictly ordered, not random rx rx tx tx or rx >> rx rx rx. > > Why? Because that's the standard DT rule, so unless, you come with a need to bypass the rule, standard applies. Why? Because implementations can use one of two ABIs - name or index - and binding should allow it. The names are for cases where entries are optional in the middle, so you cannot use index. Only for that. You cannot use that exception and make a standard case "now I want flexibility everywhere". No. Flexibility is only for special cases. > >>>>> + >>>>> + msiof1: serial@e6ea0000 { >>>> >>>> serial means UART controller. You need name matching the class of the >>>> device. >>>> Node names should be generic. See also an explanation and list of >>>> examples (not exhaustive) in DT specification: >>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation >>> >>> What is the recommend generic node name for a flexible serial device >>> that can operate as (a.o.) either SPI or I2S controller? >> >> i2s >> or even not so generic msiof, but definitely not serial because that is >> reserved for UART. > > The MSIOF device node lives in the SoC-specific .dtsi file. Its use > case is not known in that file, and specified only in the board > .dts file. sure, so call it serial-engine. or msiof. Not serial. Why? well, I said twice - it is reserved by dtschema for serial. Best regards, Krzysztof
Hi Krzysztof > Yes, probably. Although missing cells is easy to change but missing > protocol, like this patchset here, is quite more challenging. MSIOF-I2S is using MSIOF-SPI's property, these are compatible. The diff is I2S is using Of-Graph, SPI is not. Not so challenging ? > > > +properties: > > > + compatible: > > > + items: > > > + - const: renesas,msiof-r8a779g0 # R-Car V4H > > > > > > Use expected format of all soc compatibles. It has been always: SoC-module. > > ... unless this is an existing compatible, but then it should be in one > schema, not two. If I merged MSIOF-I2S/SPI into one, Of-Graph part will be option ? >> where to fit it in the DT binding doc hierarchy? > > Does not matter, whatever fits better in overal picture/purpose of this > device. Can I put info like linux/Documentation/devicetree/bindings/sound/renesas,msiof.txt --- renesas,msiof.txt --- MSIOF-I2S and MSIOF-SPI are using same DT schema. See linux/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml ------------------------- Thank you for your help !! Best regards --- Kuninori Morimoto
On 10/04/2025 02:49, Kuninori Morimoto wrote: > > Hi Krzysztof > >> Yes, probably. Although missing cells is easy to change but missing >> protocol, like this patchset here, is quite more challenging. > > MSIOF-I2S is using MSIOF-SPI's property, these are compatible. > The diff is I2S is using Of-Graph, SPI is not. Not so challenging ? Not challenging? Then I don't see the point why we are discussing and just implement the feedback. > >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - const: renesas,msiof-r8a779g0 # R-Car V4H >>> >>> >>> Use expected format of all soc compatibles. It has been always: SoC-module. >> >> ... unless this is an existing compatible, but then it should be in one >> schema, not two. > > If I merged MSIOF-I2S/SPI into one, Of-Graph part will be option ? > >>> where to fit it in the DT binding doc hierarchy? >> >> Does not matter, whatever fits better in overal picture/purpose of this >> device. > > Can I put info like > linux/Documentation/devicetree/bindings/sound/renesas,msiof.txt No. TXT bindings are not accepted. There is no benefit in this. Best regards, Krzysztof
Hi Krzysztof > >>> where to fit it in the DT binding doc hierarchy? > >> > >> Does not matter, whatever fits better in overal picture/purpose of this > >> device. > > > > Can I put info like > > linux/Documentation/devicetree/bindings/sound/renesas,msiof.txt > > No. TXT bindings are not accepted. There is no benefit in this. So, no MSIOF I2S info is allowed under linux/Documentation/devicetree/bindings/sound/ ?? Thank you for your help !! Best regards --- Kuninori Morimoto
diff --git a/Documentation/devicetree/bindings/sound/renesas,msiof.yaml b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml new file mode 100644 index 000000000000..5173e80698fb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/renesas,msiof.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/renesas,msiof.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas MSIOF I2S controller + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +# sharing with MSIOF SPI +# see +# ${LINUX}/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +select: + properties: + compatible: + contains: + pattern: "renesas,.*-msiof" + required: + - compatible + - port + +properties: + compatible: + items: + - const: renesas,msiof-r8a779g0 # R-Car V4H + - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 + + reg: + minItems: 1 + maxItems: 2 + oneOf: + - items: + - description: CPU and DMA engine registers + - items: + - description: CPU registers + - description: DMA engine registers + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: [ tx, rx ] + + port: + $ref: audio-graph-port.yaml#/definitions/port-base + unevaluatedProperties: false + patternProperties: + "^endpoint(@[0-9a-f]+)?": + $ref: audio-graph-port.yaml#/definitions/endpoint-base + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a779g0-sysc.h> + + dummy-codec { + compatible = "test-codec"; + + port { + codec_ep: endpoint { + remote-endpoint = <&msiof1_snd_ep>; + }; + }; + }; + + msiof1: serial@e6ea0000 { + compatible = "renesas,msiof-r8a779g0", + "renesas,rcar-gen4-msiof"; + reg = <0 0xe6ea0000 0 0x0064>; + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 619>; + dmas = <&dmac0 0x43>, <&dmac0 0x42>, + <&dmac1 0x43>, <&dmac1 0x42>; + dma-names = "tx", "rx", "tx", "rx"; + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>; + resets = <&cpg 619>; + + port { + msiof1_snd_ep: endpoint { + remote-endpoint = <&codec_ep>; + }; + }; + };
Renesas MSIOF (Clock-Synchronized Serial Interface with FIFO) can work as both SPI and I2S. MSIOF-I2S will use Audio Graph Card/Card2 driver which uses Of-Graph in DT. MSIOF-SPI/I2S are using same DT compatible properties. MSIOF-I2S uses Of-Graph for Audio-Graph-Card/Card2, MSIOF-SPI doesn't use Of-Graph. Adds MSIOF-I2S documentation for Sound. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> --- .../bindings/sound/renesas,msiof.yaml | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/renesas,msiof.yaml