Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756268AbcLSPtu (ORCPT ); Mon, 19 Dec 2016 10:49:50 -0500 Received: from mga14.intel.com ([192.55.52.115]:16950 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756146AbcLSPtt (ORCPT ); Mon, 19 Dec 2016 10:49:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,374,1477983600"; d="scan'208";a="914027524" Date: Mon, 19 Dec 2016 21:19:23 +0530 From: Vinod Koul To: Andy Gross Cc: Abhishek Sahu , 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 Message-ID: <20161219154923.GT25795@localhost> References: <1481795755-15302-1-git-send-email-absahu@codeaurora.org> <1481795755-15302-3-git-send-email-absahu@codeaurora.org> <20161218162602.GR25795@localhost> <20161219050642.GA3047@hector.attlocal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161219050642.GA3047@hector.attlocal.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4507 Lines: 93 On Sun, Dec 18, 2016 at 11:06:42PM -0600, Andy Gross wrote: > On Sun, Dec 18, 2016 at 09:56:02PM +0530, Vinod Koul wrote: > > On Thu, Dec 15, 2016 at 03:25:52PM +0530, Abhishek Sahu wrote: > > > The current DMA APIs only support SGL or data in generic format. > > > The QCA BAM DMA engine data cannot be mapped with already > > > available APIs due to following reasons. > > > > > > 1. The QCA BAM DMA engine uses custom flags which cannot be > > > mapped with generic DMA engine flags. > > > 2. Some peripheral driver like QCA QPIC NAND/LCD requires to > > > set specific flags (Like NWD, EOT) for some of the descriptors > > > in scatter gather list. The already available mapping APIs take > > > flags parameter in API itself and there is no support for > > > passing DMA specific flags for each SGL entry. > > > > > > Now this patch adds the support for making the DMA descriptor from > > > custom data with new DMA mapping function prep_dma_custom_mapping. > > > 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. > > > > > > Signed-off-by: Abhishek Sahu > > > --- > > > include/linux/dmaengine.h | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h > > > index cc535a4..6324c1f 100644 > > > --- a/include/linux/dmaengine.h > > > +++ b/include/linux/dmaengine.h > > > @@ -692,6 +692,8 @@ struct dma_filter { > > > * be called after period_len bytes have been transferred. > > > * @device_prep_interleaved_dma: Transfer expression in a generic way. > > > * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address > > > + * @device_prep_dma_custom_mapping: prepares a dma operation from dma driver > > > + * specific custom data > > > * @device_config: Pushes a new configuration to a channel, return 0 or an error > > > * code > > > * @device_pause: Pauses any transfer happening on a channel. Returns > > > @@ -783,6 +785,9 @@ struct dma_device { > > > struct dma_async_tx_descriptor *(*device_prep_dma_imm_data)( > > > struct dma_chan *chan, dma_addr_t dst, u64 data, > > > unsigned long flags); > > > + struct dma_async_tx_descriptor *(*device_prep_dma_custom_mapping)( > > > + struct dma_chan *chan, void *data, > > > + unsigned long flags); > > > > This needs a discussion. Why do you need to add a new API for framework. > > > > What are NWD and EOT flags, cna you details out the flags? > > These are the notify when done and end of transaction flags. I believe the last > time we talked about this, we (Vinod and I) agreed to just expose a QCOM only interface to set > the special transaction flags. You'd then have to have some other API to fixup > the descriptor with the right qcom flags. Okay, do you have pointer on that one, will avoid asking the same questions again. > Ahbishek, correct me where i am wrong on the following: > So two main differences between a normal descriptor and a command descriptor: > 1) size of the descriptor > 2) the flag setting > 3) data sent in is a modified scatter gather that includes flags , vs a normal > scatter gather > > So the CMD descriptors in a given sgl can all have varying flags set? I'd assume > they all have CMD flag set. Do the current users of the command descriptors > coalesce all of their requests into a big list? > > So a couple of thoughts on how to deal with this: > > 1) Define a virtual channel for the command descriptors vs a normal DMA > transaction. This lets you use the same hardware channel, but lets you discern > which descriptor format you need to use. The only issue I see with this is the > required change in device tree binding to target the right type of channel (cmd > vs normal). Or mark the descriptor is cmd and write accordingly... > > 2) Provide an API to set flags for the descriptor on a whole descriptor basis. > > 3) If you have a set of transactions described by an sgl that has disparate use > of flags, you split the list and use a separate transaction. In other words, we > need to enforce that the flag set API will be applied to all descriptors > described by an sgl. This means that the whole transaction may be comprised of > multiple async TX descriptors. -- ~Vinod