Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752827AbaBEQZK (ORCPT ); Wed, 5 Feb 2014 11:25:10 -0500 Received: from mail-lb0-f177.google.com ([209.85.217.177]:49565 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752399AbaBEQZH (ORCPT ); Wed, 5 Feb 2014 11:25:07 -0500 MIME-Version: 1.0 In-Reply-To: References: <1390409565-4200-1-git-send-email-sthokal@xilinx.com> <1390409565-4200-2-git-send-email-sthokal@xilinx.com> <52E0FC22.8060903@metafoo.de> <52E2698B.6070001@metafoo.de> <20140126135933.GD10628@intel.com> <52E54849.2000208@metafoo.de> <20140128031324.GH10628@intel.com> Date: Wed, 5 Feb 2014 21:55:02 +0530 X-Google-Sender-Auth: frdinwp4DeoQGV_pRewYndSZWaE Message-ID: Subject: Re: [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support From: Srikanth Thokala To: Srikanth Thokala Cc: Vinod Koul , Lars-Peter Clausen , dan.j.williams@intel.com, michal.simek@xilinx.com, Grant Likely , robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org, dmaengine@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala wrote: > Hi Vinod, > > On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul wrote: >> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote: >>> Hi Lars/Vinod, >>> >> The question here i think would be waht this device supports? Is the hardware >>> >> capable of doing interleaved transfers, then would make sense. >>> > >>> > The hardware does 2D transfers. The parameters for a transfer are height, >>> > width and stride. That's only a subset of what interleaved transfers can be >>> > (xt->num_frames must be one for 2d transfers). But if I remember correctly >>> > there has been some discussion on this in the past and the result of that >>> > discussion was that using interleaved transfers for 2D transfers is >>> > preferred over adding a custom API for 2D transfers. >>> >>> I went through the prep_interleaved_dma API and I see only one descriptor >>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame >>> buffers (can be more in future), isn't it less efficient compared to the >>> prep_slave_sg where we get a single sg list and can prepare all the descriptors >>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me >>> know your opinions. >> Well the descriptor maybe one, but that can represent multiple frames, for >> example 16 as in your case. Can you read up the documentation of how multiple >> frames are passed. Pls see include/linux/dmaengine.h >> >> /** >> * Interleaved Transfer Request >> * ---------------------------- >> * A chunk is collection of contiguous bytes to be transfered. >> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG). >> * ICGs may or maynot change between chunks. >> * A FRAME is the smallest series of contiguous {chunk,icg} pairs, >> * that when repeated an integral number of times, specifies the transfer. >> * A transfer template is specification of a Frame, the number of times >> * it is to be repeated and other per-transfer attributes. >> * >> * Practically, a client driver would have ready a template for each >> * type of transfer it is going to need during its lifetime and >> * set only 'src_start' and 'dst_start' before submitting the requests. >> * >> * >> * | Frame-1 | Frame-2 | ~ | Frame-'numf' | >> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...| >> * >> * == Chunk size >> * ... ICG >> */ > > Yes, it can handle multiple frames specified by 'numf' each of size > 'frame_size * sgl[0].size'. > But, I see it only works if all the frames' memory is contiguous and > in this case we > can just increment 'src_start' by the total frame size 'numf' number > of times to fill in > for each HW descriptor (each frame is one HW descriptor). So, there > is no issue when the > memory is contiguous. If the frames are non contiguous, we have to > call this API for each > frame (hence for each descriptor), as the src_start for each frame is > different. Is it correct? > > FYI: This hardware has an inbuilt Scatter-Gather engine. > Ping? > Srikanth > >> >> -- >> ~Vinod >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/