From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BF82A208F7AD4 for ; Thu, 3 Aug 2017 07:33:57 -0700 (PDT) From: "Jiang, Dave" Subject: Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq Date: Thu, 3 Aug 2017 14:36:07 +0000 Message-ID: <6B9F6DC1-F9BC-4DF5-A09D-DA74B4953E57@intel.com> References: <150169902310.59677.18062301799811367806.stgit@djiang5-desk3.ch.intel.com> <150169928551.59677.14690799553760064519.stgit@djiang5-desk3.ch.intel.com> <245fbb9a-d841-2c70-481b-19a0483c3872@intel.com> <220335ff-808c-e71a-7f8e-c62d698dadca@codeaurora.org> <5a5c415a-e354-20a7-c762-89dcf47032bb@intel.com> <20170803050154.GE3053@localhost> <423B07FD-31B3-424B-849E-FAC5C0AD8FAE@intel.com> <20170803052817.GF3053@localhost> <542773BA-C532-4125-BCE9-6E8889EBF272@intel.com>, <20170803085941.GG3053@localhost> In-Reply-To: <20170803085941.GG3053@localhost> Content-Language: en-US MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Koul, Vinod" Cc: Sinan Kaya , "dmaengine@vger.kernel.org" , "linux-nvdimm@lists.01.org" List-ID: > On Aug 3, 2017, at 1:56 AM, Koul, Vinod wrote: > >> On Thu, Aug 03, 2017 at 11:06:13AM +0530, Jiang, Dave wrote: >> >> >>>> On Aug 2, 2017, at 10:25 PM, Koul, Vinod wrote: >>>> >>>> On Thu, Aug 03, 2017 at 10:41:51AM +0530, Jiang, Dave wrote: >>>> >>>> >>>>>> On Aug 2, 2017, at 9:58 PM, Koul, Vinod wrote: >>>>>> >>>>>> On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote: >>>>>> >>>>>> >>>>>>> On 08/02/2017 02:10 PM, Sinan Kaya wrote: >>>>>>> On 8/2/2017 4:52 PM, Dave Jiang wrote: >>>>>>>>> Do we need a new API / new function, or new capability? >>>>>>>> Hmmm...you are right. I wonder if we need something like DMA_SG cap.... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Unfortunately, DMA_SG means something else. Maybe, we need DMA_MEMCPY_SG >>>>>>> to be similar with DMA_MEMSET_SG. >>>>>> >>>>>> I'm ok with that if Vinod is. >>>>> >>>>> So what exactly is the ask here, are you trying to do MEMCPY or SG or MEMSET >>>>> or all :). We should have done bitfields for this though... >>>> >>>> Add DMA_MEMCPY_SG to transaction type. >>> >>> Not MEMSET right, then why not use DMA_SG, DMA_SG is supposed for >>> scatterlist to scatterlist copy which is used to check for >>> device_prep_dma_sg() calls >>> >> Right. But we are doing flat buffer to/from scatterlist, not sg to sg. So >> we need something separate than what DMA_SG is used for. > > Hmm, its SG-buffer and its memcpy, so should we call it DMA_SG_BUFFER, > since it is not memset (or is it) I would not call it memset, or maybe we > should also change DMA_SG to DMA_SG_SG to make it terribly clear :D I can create patches for both. > > -- > ~Vinod _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm