RE: [PATCH 2/2] dt-bindings: dma: renesas,usb-dmac: convert bindings to json-schema

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert-san,

Thank you for your review!

> From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 10:56 PM
<snip>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
> > @@ -0,0 +1,99 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/dma/renesas,usb-dmac.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas USB DMA Controller
> > +
> > +maintainers:
> > +  - Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>
> > +
> > +allOf:
> > +  - $ref: "dma-controller.yaml#"
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - renesas,r8a7743-usb-dmac  # RZ/G1M
> > +          - renesas,r8a7744-usb-dmac  # RZ/G1N
> > +          - renesas,r8a7745-usb-dmac  # RZ/G1E
> > +          - renesas,r8a77470-usb-dmac # RZ/G1C
> > +          - renesas,r8a774a1-usb-dmac # RZ/G2M
> > +          - renesas,r8a774b1-usb-dmac # RZ/G2N
> > +          - renesas,r8a774c0-usb-dmac # RZ/G2E
> > +          - renesas,r8a7790-usb-dmac  # R-Car H2
> > +          - renesas,r8a7791-usb-dmac  # R-Car M2-W
> > +          - renesas,r8a7793-usb-dmac  # R-Car M2-N
> > +          - renesas,r8a7794-usb-dmac  # R-Car E2
> > +          - renesas,r8a7795-usb-dmac  # R-Car H3
> > +          - renesas,r8a7796-usb-dmac  # R-Car M3-W
> > +          - renesas,r8a77961-usb-dmac # R-Car M3-W+
> > +          - renesas,r8a77965-usb-dmac # R-Car M3-N
> > +          - renesas,r8a77990-usb-dmac # R-Car E3
> > +          - renesas,r8a77995-usb-dmac # R-Car D3
> > +      - const: renesas,usb-dmac
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 2
> 
> Is there a use case for specifying a single interrupt?

No. All USB-DMAC of R-Car Gen2/3 and RZ/Gn has 2 channels.
In case of R-Car Gen3, please refer to the Figure 75.1 USB-DMAC Block Diagram.
These USB-DMACn have CH0 and CH1

> > +
> > +  interrupt-names:
> > +    maxItems: 2
> > +    items:
> > +      - pattern: "^ch[0-1]$"
> > +      - pattern: "^ch[0-1]$"
> 
> Would it make sense to list the (two) actual channel names instead?

I agree. Just using ch0 and ch1 is simpler.

> > +
> > +  clocks:
> > +    maxItems: 1
> > +
> > +  '#dma-cells':
> > +    const: 1
> > +    description:
> > +      The cell specifies the channel number of the DMAC port connected to
> > +      the DMA client.
> > +
> > +  dma-channels:
> > +    maximum: 2
> 
> Is there a use case for specifying a single channel?
> 
> > +
> > +  iommus:
> > +    maxItems: 2
> 
> Likewise?

As I mentioned above, there is not a use case for specifying a single channel.

> > +
> > +  power-domains:
> > +    maxItems: 1
> > +
> > +  resets:
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - interrupt-names
> > +  - clocks
> > +  - '#dma-cells'
> > +  - dma-channels
> 
> Shouldn't "power-domains" and "resets" be mandatory, too?
> All covered SoCS have them.

Oops. I'll add these properties as required.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds




[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux