Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

[Stephen Warren]

On 09/27/2017 02:34 AM, Jon Hunter wrote:
> On 27/09/17 02:57, Dmitry Osipenko wrote:
> > On 26.09.2017 17:50, Jon Hunter wrote:
> > > On 26/09/17 00:22, Dmitry Osipenko wrote:
> > > > Document DT bindings for NVIDIA Tegra AHB DMA controller that presents
> > > > on Tegra20/30 SoC's.
> > > >
> > > > Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
> > > > ---
> > > >   .../bindings/dma/nvidia,tegra20-ahbdma.txt         | 23 ++++++++++++++++++++++
> > > >   1 file changed, 23 insertions(+)
> > > >   create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
> > > > new file mode 100644
> > > > index 000000000000..2af9aa76ae11
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
> > > > @@ -0,0 +1,23 @@
> > > > +* NVIDIA Tegra AHB DMA controller
> > > > +
> > > > +Required properties:
> > > > +- compatible:	Must be "nvidia,tegra20-ahbdma"
> > > > +- reg:		Should contain registers base address and length.
> > > > +- interrupts:	Should contain one entry, DMA controller interrupt.
> > > > +- clocks:	Should contain one entry, DMA controller clock.
> > > > +- resets :	Should contain one entry, DMA controller reset.
> > > > +- #dma-cells:	Should be <1>. The cell represents DMA request select value
> > > > +		for the peripheral. For more details consult the Tegra TRM's
> > > > +		documentation, in particular AHB DMA channel control register
> > > > +		REQ_SEL field.
> > >
> > > What about the TRIG_SEL field? Do we need to handle this here as well?
> >
> > Actually, DMA transfer trigger isn't related a hardware description. It's up to
> > software to decide what trigger to select. So it shouldn't be in the binding.
>
> I think it could be, if say a board wanted a GPIO to trigger a transfer.
>
> > And I think the same applies to requester... any objections?
>
> Well, the REQ_SEL should definitely be in the binding.
>
> Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks
> like we never bothered with it for the APB DMA and so maybe no ones uses
> this.

I don't think TRIG_SEL should be in the binding, at least at present. 
While TRIG_SEL certainly is something used to configure the transfer, I 
believe the semantics of the current DMA binding only cover DMA 
transfers that are initiated when SW desires, rather than being a 
combination of after SW programs the transfer plus some other HW event. 
So, we always use a default/hard-coded TRIG_SEL value. As such, there's 
no need for a TRIG_SEL value in DT. There's certainly no known use-case 
that requires a non-default TRIG_SEL value at present. We could add an 
extra #dma-cells value later if we find a use for it, and the semantics 
of that use-case make sense to add it to the DMA specifier, rather than 
some other separate higher-level property/driver/...