From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933347AbdDGN6p (ORCPT <rfc822;w@1wt.eu>);
        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
        <rfc822;linux-kernel@vger.kernel.org>);
        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 <absahu@codeaurora.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Andy Gross <andy.gross@linaro.org>, 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>
 <c792bb9abd55ff55fde92b38b43a69d6@codeaurora.org>
 <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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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:
>> 
<snip>
>> > 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