Hi Rob, Thanks for the feedback. > Subject: Re: [PATCH 1/5] dt-bindings: dma: Document RZ/G2L bindings > > On Fri, Jun 11, 2021 at 12:36:38PM +0100, Biju Das wrote: > > Document RZ/G2L DMAC bindings. > > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > --- > > .../bindings/dma/renesas,rz-dmac.yaml | 132 ++++++++++++++++++ > > 1 file changed, 132 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml > > b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml > > new file mode 100644 > > index 000000000000..df54bd6ddfd4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml > > @@ -0,0 +1,132 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > +cetree.org%2Fschemas%2Fdma%2Frenesas%2Crz-dmac.yaml%23&data=04%7C > > +01%7Cbiju.das.jz%40bp.renesas.com%7Ce46660b298b942937fe408d92d109c19% > > +7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637590371623792000%7CUnk > > +nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > > +wiLCJXVCI6Mn0%3D%7C1000&sdata=kirztzPuCmsjeKEivOgQZqP5obsByrSaTnQ > > +bzQbU%2BRM%3D&reserved=0 > > +$schema: > > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cbiju.das. > > +jz%40bp.renesas.com%7Ce46660b298b942937fe408d92d109c19%7C53d82571da19 > > +47e49cb4625a166a4a2a%7C0%7C0%7C637590371623792000%7CUnknown%7CTWFpbGZ > > +sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > > +3D%7C1000&sdata=U2lrBvVVhySXVYHK6Qk41VTGijep8yPaTCMJpSjRsXs%3D&am > > +p;reserved=0 > > + > > +title: Renesas RZ/G2L DMA Controller > > + > > +maintainers: > > + - Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > + > > +allOf: > > + - $ref: "dma-controller.yaml#" > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - renesas,dmac-r9a07g044 # RZ/G2{L,LC} > > + - const: renesas,rz-dmac > > + > > + reg: > > + items: > > + - description: Control and channel register block > > + - description: DMA extension resource selector block > > + > > + interrupts: > > + maxItems: 17 > > + > > + interrupt-names: > > + maxItems: 17 > > + items: > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > + - pattern: "^ch([0-9]|1[0-5])$" > > Is there some reason these need be in undefined order? No. I will make it as defined order in next version. > > > + - const: error > > + > > + clocks: > > + maxItems: 1 > > + > > + '#dma-cells': > > + const: 1 > > + description: > > + The cell specifies the MID/RID of the DMAC port connected to > > + the DMA client. > > + > > + dma-channels: > > + const: 16 > > + > > + power-domains: > > + maxItems: 1 > > + > > + resets: > > + maxItems: 1 > > + > > + renesas,rz-dmac-slavecfg: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: | > > + DMA configuration for a slave channel. Each channel must have an > array of > > + 3 items as below. > > + first item in the array is MID+RID > > + second item in the array is slave src or dst address > > + third item in the array is channel configuration value. > > Why not put all these in the dma-cells? You already have 1 of them. Thanks for the suggestion. I will make use of dma-cells and will remove the above property in next revision. Basically It simplifies the implementation as well. > Though doesn't the client device know what address to use? Indeed. it knows. Cheers, Biju > > > + items: > > + minItems: 3 > > + maxItems: 48 > > + > > +required: > > + - compatible > > + - reg > > + - interrupts > > + - interrupt-names > > + - clocks > > + - '#dma-cells' > > + - dma-channels > > + - power-domains > > + - resets > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include <dt-bindings/interrupt-controller/arm-gic.h> > > + #include <dt-bindings/clock/r9a07g044-cpg.h> > > + > > + dmac: dma-controller@11820000 { > > + compatible = "renesas,dmac-r9a07g044", > > + "renesas,rz-dmac"; > > + reg = <0x11820000 0x10000>, > > + <0x11830000 0x10000>; > > + interrupts = <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, > > + <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>; > > + interrupt-names = "ch0", "ch1", "ch2", "ch3", > > + "ch4", "ch5", "ch6", "ch7", > > + "ch8", "ch9", "ch10", "ch11", > > + "ch12", "ch13", "ch14", "ch15", > > + "error"; > > + clocks = <&cpg CPG_MOD R9A07G044_CLK_DMAC>; > > + power-domains = <&cpg>; > > + resets = <&cpg R9A07G044_CLK_DMAC>; > > + #dma-cells = <1>; > > + dma-channels = <16>; > > + renesas,rz-dmac-slavecfg = <0x255 0x10049C18 0x0011228>; > > + }; > > -- > > 2.17.1