From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755332AbbJGQUE (ORCPT ); Wed, 7 Oct 2015 12:20:04 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:9126 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755316AbbJGQUA (ORCPT ); Wed, 7 Oct 2015 12:20:00 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Wed, 07 Oct 2015 09:18:59 -0700 Subject: Re: [PATCH V2 1/2] Documentation: DT: Add binding documentation for NVIDIA ADMA To: Stephen Warren References: <1444047007-30494-1-git-send-email-jonathanh@nvidia.com> <1444047007-30494-2-git-send-email-jonathanh@nvidia.com> <56145369.7040404@wwwdotorg.org> <5614DB41.5080907@nvidia.com> <561543A2.2090402@wwwdotorg.org> CC: Laxman Dewangan , Vinod Koul , Thierry Reding , Alexandre Courbot , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "Arnd Bergmann" , , , From: Jon Hunter Message-ID: <56154629.8080205@nvidia.com> Date: Wed, 7 Oct 2015 17:19:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561543A2.2090402@wwwdotorg.org> X-Originating-IP: [10.21.132.159] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/10/15 17:09, Stephen Warren wrote: > On 10/07/2015 02:43 AM, Jon Hunter wrote: >> >> On 07/10/15 00:04, Stephen Warren wrote: >>> On 10/05/2015 06:10 AM, Jon Hunter wrote: >>>> Add device-tree binding documentation for the Tegra210 Audio DMA >>>> controller. >>> >>>> diff --git a/Documentation/devicetree/bindings/dma/tegra210-adma.txt >>>> b/Documentation/devicetree/bindings/dma/tegra210-adma.txt >>> >>>> +- #dma-cells : Must be <2>. The first cell denotes the transmit or >>>> + receive request number and should be between 1 and the maximum >>>> number >>>> + of requests supported (see properties "dma-rx-requests" and >>>> + "dma-tx-requests"). This value corresponds to the >>>> RX/TX_REQUEST_SELECT >>>> + fields in the ADMA_CHn_CTRL register. The second cell denotes >>>> whether >>>> + the channel is a receive or transmit channel and must be either 2 >>>> for >>>> + a receive channel and 4 for a transmit channel. These values >>>> correspond >>>> + to the TRANSFER_DIRECTION field of the ADMA_CHn_CTRL register. >>> >>> Is it typical to encode the direction into the dma cells? I would have >>> thought the client would provide that information at run-time when >>> requesting a DMA channel. >> >> I have seen other dma bindings that do [0]. If we don't put the >> direction in the client binding, then it would appear as ... >> >> tegra_admaif: admaif@0x702d0000 { >> ... >> dmas = <&adma 1>, <&adma 1>, <&adma 2>, <&adma 2>, >> <&adma 3>, <&adma 3>, <&adma 4>, <&adma 4>, >> <&adma 5>, <&adma 5>, <&adma 6>, <&adma 6>, >> <&adma 7>, <&adma 7>, <&adma 8>, <&adma 8>, >> <&adma 9>, <&adma 9>, <&adma 10>, <&adma 10>; >> dma-names = "rx1", "tx1", "rx2", "tx2", "rx3", "tx3", >> "rx4", "tx4", "rx5", "tx5", "rx6", "tx6", >> "rx7", "tx7", "rx8", "tx8", "rx9", "tx9", >> "rx10", "tx10"; >> ... >> }; >> >> ... where "rxN" and "txN" appear to use the same request, but the >> reality is that "rxN" is using rx-request-N and "txN" is using >> tx-request-N. Arnd questioned this before. Obviously I can explain this >> in the binding document if the above is preferred. However, given that >> they are named "rx1", "rx2", etc, why not put the direction in the >> binding? > > Why would we need to duplicate the request IDs? I'd expect to have the > following property content: > > dmas = <&adma 1>, <&adma 2>, <&adma 3>, ...; > dma-names = "1", "2", "3"...; > > *and* not have a cell to represent the direction in DT. After all, the > direction of the channel is 100% implied by the use-case (and hence > defined by the DMA client's own DT binding); it is known by the client > driver and can be supplied at run-time. Right, but what does the 1, 2, 3, etc in the specifier represent? If it is the request signal then I don't see how this would work because there are 10 rx request signals and 10 tx requests signal and both are 1-10. If you look at the ADMA_CH_CTRL_0 register you will see there are a fields for the TX_REQUEST_SELECT, RX_REQUEST_SELECT and TRANSFER_DIRECTION. It seems a bit silly to have both TX_REQUEST_SELECT and RX_REQUEST_SELECT as the channel can only work with one direction at any given time. > Perhaps the core DMA DT bindings are not designed that way though, in > which case I suppose the patch you sent makes sense. If so though, that > seems like a bug in the core DMA DT bindings. I think it is more of a nuance in how this DMA controller is configured. Jon