Received: by 10.192.165.156 with SMTP id m28csp1737286imm; Thu, 12 Apr 2018 02:36:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx48twlHm0hqbcmmiKNejnLSCIL6qdcT85kApmobmG0MnQq7T9obokcW3SyiOlgzVnEe6DBXP X-Received: by 2002:a17:902:7c0f:: with SMTP id x15-v6mr182547pll.369.1523525795075; Thu, 12 Apr 2018 02:36:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523525795; cv=none; d=google.com; s=arc-20160816; b=CbfMB3MoNq3DCjbNgcF4/kHrJml14uz1RKCnSEUMf3gOYWgAmfSf46D8K/ZrHAGlXn /4lqiBswDwd/WxZ9rt05kwiJMISXVH5A11+iVqbgtFlwdYwsdw9BK8Sn2BA9Hdy2st2s oxefVxauP1LvUjcTHULuEGctijlz32RZh4T6TbWgqG6FCVAgSj+HC/o1R0UVVCapxX/r JoGybb+WWCUgmkeaxljdsFXPINH4LT0/vEBEKUyS0nGbbZPtaMSup3Hoz9E0uxpV3wdQ G0/FtAab9TSsrnKATYxu5DQQLDI+ucQqvG/Q5XHxN7kV22z4ArfxP2DBQIRPjFAWrUBT sUjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=xmCFb/CBvmkmj8x0NoygX6/Z1z7REwvYl1ymTU22NO8=; b=ZI4HVKu8feDs2VCibRweuMsjNx7VvBUTGECGQmI4+jDDiAdXEVvhsFqTZG5Ll+rcNg KxJSKaO3AhwsNaS9S/jEQyE0SBZ7wzWhn3qE5rJ9ivausJC7KoOMpzoUHSrtC0IJRbkE FfOAFnkj1bRKn8OJWsZrTwI6V+eLxnR7wifBnY7tQOJe6Nv+gynXR9og0oTF/E59l9Ff kAYoh2sJhXQhSCrFA1F8OVF/VAshTcvPm1okI4vUN8/rIH8YAfIQiWH+Mc5oQqwWOmEY z5swGz4Kl9awgHueQzQqJJrVzwzqKffv+nTvzG6WtuymHM0jrZXQxqkFtC8l9Q2ZXST1 bCaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4-v6si2977147plb.522.2018.04.12.02.35.57; Thu, 12 Apr 2018 02:36:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752095AbeDLJdJ (ORCPT + 99 others); Thu, 12 Apr 2018 05:33:09 -0400 Received: from mga01.intel.com ([192.55.52.88]:34730 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbeDLJdI (ORCPT ); Thu, 12 Apr 2018 05:33:08 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 02:33:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,441,1517904000"; d="scan'208";a="31502075" Received: from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143]) by fmsmga007.fm.intel.com with ESMTP; 12 Apr 2018 02:33:05 -0700 Date: Thu, 12 Apr 2018 15:07:36 +0530 From: Vinod Koul To: Baolin Wang Cc: Dan Williams , Eric Long , Mark Brown , dmaengine@vger.kernel.org, LKML Subject: Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration Message-ID: <20180412093735.GF6014@localhost> References: <0c2b76aba6a49e583f920ae582d6815fa9cc4361.1523346135.git.baolin.wang@linaro.org> <20180411093634.GC6014@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 11, 2018 at 08:13:28PM +0800, Baolin Wang wrote: > Hi Vinod, > > On 11 April 2018 at 17:36, Vinod Koul wrote: > > On Tue, Apr 10, 2018 at 03:46:06PM +0800, Baolin Wang wrote: > > > >> +/* > >> + * struct sprd_dma_config - DMA configuration structure > >> + * @config: dma slave channel config > >> + * @fragment_len: specify one fragment transfer length > >> + * @block_len: specify one block transfer length > >> + * @transcation_len: specify one transcation transfer length > >> + * @wrap_ptr: wrap pointer address, once the transfer address reaches the > >> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to' address. > >> + * @wrap_to: wrap jump to address > >> + * @req_mode: specify the DMA request mode > >> + * @int_mode: specify the DMA interrupt type > >> + */ > >> +struct sprd_dma_config { > >> + struct dma_slave_config config; > >> + u32 fragment_len; > > > > why not use _maxburst? > > Yes, I can use maxburst. > > > > >> + u32 block_len; > >> + u32 transcation_len; > > > > what does block and transaction len refer to here > > Our DMA has 3 transfer mode: transaction transfer, block transfer and > fragment transfer. One transaction transfer can contain several blocks > transfer, and each block can be set proper block step. One block can > contain several fragments transfer with proper fragment step. It can > generate interrupts when one transaction transfer or block transfer or > fragment transfer is completed if user set the interrupt type. So here > we should set the length for transaction transfer, block transfer and > fragment transfer. what are the max size these types support? > > > > >> + phys_addr_t wrap_ptr; > >> + phys_addr_t wrap_to; > > > > this sound sg_list to me, why are we not using that here > > It is similar to sg list, but it is not one software action, we have > hardware registers to help to jump one specified address. > > > > >> + enum sprd_dma_req_mode req_mode; > > > > Looking at definition of request mode we have frag, block, transaction list > > etc.. That should depend upon dma request. If you have been asked to > > transfer a list, you shall configure list mode. if it is a single > > transaction then it should be transaction mode! > > If I understand your points correctly, you mean we can specify the > request mode when requesting one slave channel by > 'dma_request_slave_channel()'. But we need change the request mode > dynamically following different transfer task for this channel, so I > am afraid we can not specify the request mode of this channel at > requesting time. Nope a channel has nothing to do with request type. You request and grab a channel. Then you prepare a descriptor for a dma transaction. Based on transaction requested you should intelligently break it down and create a descriptor which uses transaction/block/fragment so that DMA throughput is efficient. If prepare has sg list then you should use link list mode. Further if you support max length, say 16KB and request is for 20KB you may break it down for link list with two segments. Each prep call has flags associated, that can help you configure interrupt behaviour. Btw other dma controllers have similar capabilities and driver manages these :) -- ~Vinod