Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933347AbdDGN6p (ORCPT ); Fri, 7 Apr 2017 09:58:45 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:34552 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754029AbdDGN6i (ORCPT ); Fri, 7 Apr 2017 09:58:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 07 Apr 2017 19:28:37 +0530 From: Abhishek Sahu To: Vinod Koul Cc: Andy Gross , dan.j.williams@intel.com, stanimir.varbanov@linaro.org, mcgrof@suse.com, okaya@codeaurora.org, pramod.gurav@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH 2/5] dmaengine: Add support for custom data mapping In-Reply-To: <20170120165647.GM3573@localhost> References: <20161219154923.GT25795@localhost> <20161219175210.GB3047@hector.attlocal.net> <20161220202511.GD3047@hector.attlocal.net> <61cb961a6f448cfc48b983329e329b34@codeaurora.org> <20161229175450.GB17770@hector.attlocal.net> <8055fa20b35139e7d13831583ebf4f4f@codeaurora.org> <20170102161233.GC17770@hector.attlocal.net> <20170119050150.GI3573@localhost> <20170119141317.GA9631@hector.attlocal.net> <20170120165647.GM3573@localhost> Message-ID: <34d31475d7aac26dba748f520e1a6639@codeaurora.org> User-Agent: Roundcube Webmail/1.2.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2899 Lines: 76 On 2017-01-20 22:26, Vinod Koul wrote: > On Thu, Jan 19, 2017 at 08:13:17AM -0600, Andy Gross wrote: >> On Thu, Jan 19, 2017 at 10:31:50AM +0530, Vinod Koul wrote: >> >> > This makes it bam specific and causes issues if we want to use this code in >> > generic libs, but yes this is an option but should be last resort. >> >> If adding flags is a possibility (which it didn't seem to be in the >> past), that >> would make things much easier. > > Yes if we can describe them generically then yes. So with this and > resuing > existing flags without overriding, how many flags do we need.. Extremely Sorry for delayed response. I couldn't get time to work on this. Summarizing the original issue and suggestion mentioned in this mail thread. ISSUE 1: Using the BAM specific command flag CMD (Command) - allows the SW to create descriptors of type Command which does not generate any data transmissions but configures registers in the Peripheral (write operations, and read registers operations). If we are going to add this as a part of new flag then we require 1 new flags (DMA_PREP_CMD). ISSUE 2: Setting per SG flag Currently peripheral driver calls dmaengine_prep_slave_sg with flag as parameter. Some of the peripherals (like NAND) requires different flag to be set in for each SG. SOLUTION 1: The original patch adds prep_dma_custom_mapping in the generic DMA engine. The peripheral driver will pass the custom data in this function and DMA engine driver will form the descriptor according to its own logic. In future, this API can be used by any other DMA engine drivers also which are unable to do DMA mapping with already available API’s. Drawback: Requires adding additional API in DMA framework which uses void pointer. SOLUTION 2: Define and export BAM specific custom API that allows for the flag munging for the descriptors instead of overriding the prep_slave_sg. The API should take a structure that has a 1:1 mapping of the flags to the descriptors and this API will be called before submitting the descriptors. Drawback: This makes it BAM specific and causes issues if we want to use this code in generic libs. SOLUTION 3: Add CMD flags in generic DMA engine, split the list and call prep_slave_sg multiple times. Drawback: This flag is BAM specific and it can’t be used in other drivers without overriding. Also, each prep_slave_sg will generate the BAM hardware interrupt and impact the performance. I did some experiments and here are the results with linux mtd_speedtest: - With solution 1 and 2, - 2 interrupts will be generated per NAND page read/write for 2K page - The mtd read speed obtained is 8685 KiB/s - With solution 3, - 8 interrupts will be generated per NAND page read/write for 2K page - The mtd read speed 7419 KiB/s which increases boot time and decrease the File System KPI's -- Abhishek Sahu