Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752664AbdGaQgw (ORCPT ); Mon, 31 Jul 2017 12:36:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:63124 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbdGaQgi (ORCPT ); Mon, 31 Jul 2017 12:36:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,304,1498546800"; d="scan'208";a="1178232327" Subject: Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors. To: Vinod Koul , Abhishek Sahu Cc: "andy.gross@linaro.org" , "david.brown@linaro.org" , "Williams, Dan J" , "linux-arm-msm@vger.kernel.org" , "linux-soc@vger.kernel.org" , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <1498481369-29497-1-git-send-email-absahu@codeaurora.org> <1498481369-29497-2-git-send-email-absahu@codeaurora.org> <20170719100753.GF3053@localhost> <2060be251cdc87fba73a891425caa7a3@codeaurora.org> <4a4a5956cff8c5f49f4f44dfbfd0589e@codeaurora.org> <20170731123405.GK3053@localhost> From: Dave Jiang Message-ID: <790ee7c8-a011-431f-e878-636c1e8832fb@intel.com> Date: Mon, 31 Jul 2017 09:35:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170731123405.GK3053@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3109 Lines: 88 On 07/31/2017 05:34 AM, Vinod Koul wrote: > On Fri, Jul 28, 2017 at 09:38:56PM +0530, Abhishek Sahu wrote: >> On 2017-07-19 17:48, Abhishek Sahu wrote: >>> On 2017-07-19 15:37, Vinod Koul wrote: >>>> On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote: >>>>> Some of the DMA controllers are capable of issuing the commands >>>>> to peripheral by the DMA. These commands can be list of register >>>>> reads/writes and its different from normal data reads/writes. >>>>> This patch adds new flag DMA_PREP_CMD in DMA API which tells >>>>> the driver that the data passed to DMA API is in command format >>>>> and DMA driver will form descriptor in the required format. >>>>> >>>>> This flag can be used by any DMA controller driver which requires >>>>> special handling for non-Data descriptors. >>>> >>>> Please add Documentation for this new flag in >>>> Documentation/dmaengine/provider.txt >>>> >>> >>> Sure. I will add update the documentation in v3. >>> >>>>> >>>>> Signed-off-by: Abhishek Sahu >>>>> --- >>>>> include/linux/dmaengine.h | 3 +++ >>>>> 1 file changed, 3 insertions(+) >>>>> >>>>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h >>>>> index 5336808..bbc297e 100644 >>>>> --- a/include/linux/dmaengine.h >>>>> +++ b/include/linux/dmaengine.h >>>>> @@ -186,6 +186,8 @@ struct dma_interleaved_template { >>>>> * on the result of this operation >>>>> * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again >>>>> till >>>>> * cleared or freed >>>>> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is >>>>> in command >>>>> + * format and it will be used for configuring the peripheral >>>>> registers. >>>> >>>> Can you explain what is command format..? >>>> >>> >>> The command format is not generic and its format will be dependent >>> upon DMA engine. The client drivers will give data in its own >>> command formats and this flag will be passed to DMA API’s to do >>> the parsing according to its own command format. >>> >>> Currently this flag description and name is inclined towards >>> Qualcomm BAM DMA command flag. We want to make this flag as >>> generic one so require your suggestion regarding this. >>> Will renaming this flag as DMA_PREP_NON_DATA or >>> DMA_PREP_CUSTOM make it more generic? >>> >> >> can we use same flag name DMA_PREP_CMD or should we >> go for some other name? > > Are you asking for using DMA_PREP_CMD, for that I think should be ok > > If you asking about adding a new flag with DMA_PREP_CMD, then it would no Vinod, I wonder if we should introduce a DMA_PREP_CUSTOM flag and then reserve X number of upper flag bits to vendor specified that only they care about. That way they can define whatever they want in the upper bits if they need it. > >> >>>>> */ >>>>> enum dma_ctrl_flags { >>>>> DMA_PREP_INTERRUPT = (1 << 0), >>>>> @@ -195,6 +197,7 @@ enum dma_ctrl_flags { >>>>> DMA_PREP_CONTINUE = (1 << 4), >>>>> DMA_PREP_FENCE = (1 << 5), >>>>> DMA_CTRL_REUSE = (1 << 6), >>>>> + DMA_PREP_CMD = (1 << 7), >>>>> }; >>>>> >> >> >> -- >> Abhishek Sahu >