RE: [PATCH v11 1/4] dt-bindings: dmaengine: Add doc for tegra gpcdma

[Akhil R <akhilrajeev@nvidia.com>]

> On Thu, Oct 28, 2021 at 06:53:36PM +0530, Akhil R wrote:
> > Add DT binding document for Nvidia Tegra GPCDMA controller.
> >
> > Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> > ---
> >  .../bindings/dma/nvidia,tegra186-gpc-dma.yaml      | 115
> +++++++++++++++++++++
> >  1 file changed, 115 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
> > b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
> > new file mode 100644
> > index 0000000..bc97efc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.ya
> > +++ ml
> > @@ -0,0 +1,115 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/dma/nvidia,tegra186-gpc-dma.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVIDIA Tegra GPC DMA Controller Device Tree Bindings
> > +
> > +description: |
> > +  The Tegra General Purpose Central (GPC) DMA controller is used for
> > +faster
> > +  data transfers between memory to memory, memory to device and
> > +device to
> > +  memory.
> > +
> > +maintainers:
> > +  - Jon Hunter <jonathanh@nvidia.com>
> > +  - Rajesh Gumasta <rgumasta@nvidia.com>
> > +
> > +allOf:
> > +  - $ref: "dma-controller.yaml#"
> > +
> > +properties:
> > +  compatible:
> > +    oneOf:
> > +      - enum:
> > +          - nvidia,tegra186-gpcdma
> > +          - nvidia,tegra194-gpcdma
> > +      - items:
> > +          - const: nvidia,tegra186-gpcdma
> > +          - const: nvidia,tegra194-gpcdma
> 
> One of these is wrong. Either 186 has a fallback to 194 or it doesn't.
Not sure if I understood this correctly. Tegra186 and 194 have different chip data
inside driver based on the compatible. I guess, it then needs to be one of these.
Or is the mistake something related to formatting?

Agreed with other comments.

--
nvpublic