Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752743AbdI3DLQ (ORCPT ); Fri, 29 Sep 2017 23:11:16 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:33339 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752653AbdI3DLM (ORCPT ); Fri, 29 Sep 2017 23:11:12 -0400 X-Google-Smtp-Source: AOwi7QDF3yJnCigR4hRlBdvOobKbAup0j2FHq3mvrpRcPhXhg+wk6Mj6tps77/sUTII+YE4dbhYPZw== Subject: Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller To: Stephen Warren , Jon Hunter , Thierry Reding , Laxman Dewangan , Peter De Schrijver , Prashant Gaikwad , Michael Turquette , Stephen Boyd , Rob Herring , Vinod Koul Cc: linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, dmaengine@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org References: <604d92036e0936443290e68a2226f935fb348113.1506380746.git.digetx@gmail.com> <96bfdacb-3d2d-66b6-70f7-a87664b1afc7@gmail.com> <0fd316e9-3584-e9bd-2a8b-e73eaa6a9a48@nvidia.com> <9e4e3dc1-85cd-2096-118c-7d0c929b9246@wwwdotorg.org> From: Dmitry Osipenko Message-ID: <5a5ce745-750f-9c8f-5129-c9b0f7aee614@gmail.com> Date: Sat, 30 Sep 2017 06:11:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9e4e3dc1-85cd-2096-118c-7d0c929b9246@wwwdotorg.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3516 Lines: 73 On 29.09.2017 22:30, Stephen Warren wrote: > 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 >>>>> --- >>>>>   .../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/... Thank you for the comment. If we'd want to extend the binding further with the trigger, how to differentiate trigger from the requester in a case of a single #data-cell? Of course realistically a chance that the further extension would be needed is very-very low, so we may defer the efforts to solve that question and for now make driver aware of the potential #dma-cells extension.