Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933174Ab3GRRKa (ORCPT ); Thu, 18 Jul 2013 13:10:30 -0400 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:37477 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933016Ab3GRRK1 (ORCPT ); Thu, 18 Jul 2013 13:10:27 -0400 Date: Thu, 18 Jul 2013 18:08:25 +0100 From: Russell King - ARM Linux To: Joel Fernandes Cc: Tony Lindgren , Sekhar Nori , Matt Porter , Grant Likely , Rob Herring , Vinod Koul , Mark Brown , Benoit Cousson , Balaji TK , Gururaja Hebbar , Chris Ball , Jason Kridner , Mark Jackson , Devicetree Discuss , Linux OMAP List , Linux ARM Kernel List , Linux DaVinci Kernel List , Linux Kernel Mailing List , Linux Documentation List , Linux MMC List , Linux SPI Devel List , Arnd Bergmann Subject: Re: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits() Message-ID: <20130718170825.GZ21614@n2100.arm.linux.org.uk> References: <1374166001-31340-1-git-send-email-joelf@ti.com> <1374166001-31340-2-git-send-email-joelf@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1374166001-31340-2-git-send-email-joelf@ti.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2616 Lines: 65 On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote: > The API is optionally implemented by dmaengine drivers and when > unimplemented will return a NULL pointer. A client driver using > this API provides the required dma channel, address width, and > burst size of the transfer. dma_get_slave_sg_limits() returns an > SG limits structure with the maximum number and size of SG segments > that the given channel can handle. Please look at what's already in struct device: struct device { ... struct device_dma_parameters *dma_parms; ... }; This provides: struct device_dma_parameters { /* * a low level driver may set these to teach IOMMU code about * sg limitations. */ unsigned int max_segment_size; unsigned long segment_boundary_mask; }; Now, these are helpfully accessed via: dma_get_max_seg_size(dev) dma_set_max_seg_size(dev) dma_get_seg_boundary(dev) dma_set_seg_boundary(dev, mask) Drivers already use these to work out how to construct the scatterlist before passing it to the DMA API, which means that they should also be used when creating a scatterlist for the DMA engine (think about it - you have to use the DMA API to map the buffers for the DMA engine too.) So, we already have two properties defined on a per-device basis: the maximum size of a scatterlist segment, and the boundary over which any segment must not cross. The former ties up with your max_seg_len() property, though arguably it may depend on the DMA engine access size. The problem with implementing this new API though is that the subsystems (such as SCSI) which already use dma_get_max_seg_size() will be at odds with what is possible via the DMA engine. I strongly suggest using the infrastructure at device level and not implementing some private DMA engine API to convey this information. As for the maximum number of scatterlist entries, really that's a bug in the DMA engine implementations if they can't accept arbitary lengths. I've created DMA engine drivers for implementations where you have to program each segment individually, ones which can have the current and next segments, as well as those which can walk a list. Provided you get informed of a transfer being completed, there really is no reason for a DMA engine driver to limit the number of scatterlist entries that it will accept. -- 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/