From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cam-admin0.cambridge.arm.com (cam-admin0.cambridge.arm.com [217.140.96.50]) by lists.ozlabs.org (Postfix) with ESMTP id 8D6561A000A for ; Sat, 5 Jul 2014 03:05:12 +1000 (EST) Date: Fri, 4 Jul 2014 18:04:44 +0100 From: Mark Rutland To: Alexander Popov Subject: Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document Message-ID: <20140704170444.GE7106@leverpostej> References: <1403088492-15241-1-git-send-email-a13xp0p0v88@gmail.com> <1403088492-15241-2-git-send-email-a13xp0p0v88@gmail.com> <20140618133730.GB11895@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: "devicetree@vger.kernel.org" , Lars-Peter Clausen , Arnd Bergmann , Vinod Koul , Gerhard Sittig , Andy Shevchenko , "dmaengine@vger.kernel.org" , Dan Williams , Anatolij Gustschin , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Alexander, Apologies for the late reply. DT-related email is somewhat a firehose and unfortunately I lose track of things. On Thu, Jun 19, 2014 at 02:59:19PM +0100, Alexander Popov wrote: > 2014-06-18 18:56 GMT+04:00 Alexander Popov : > > 2014-06-18 17:37 GMT+04:00 Mark Rutland : > >> On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote: > >>> Introduce a device tree binding document for the MPC512x DMA controller > >>> +Optional properties: > >>> +- #dma-cells: the length of the DMA specifier, must be <1>. > >>> + Each channel of this DMA controller has a peripheral request line, > >>> + the assignment is fixed in hardware. This one cell > >>> + in dmas property of a client device represents the channel number. > >> > >> Surely this is required to be able to refer to DMA channels on the > >> device? > > > > Excuse me, I didn't understand your question. > > Do you inquire about the reason of making #dma-cells an optional property? > > It's optional because device tree based lookup support is made > > optional (part 3/3). > > Mark, did I answer your question? > Should I fix anything in this patch series? I would move it under required properties even if we happen to not use it in certain edge cases. Moving forwards everything should be DT-driven, so it'll be necessary. Thanks, Mark.