From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B39EAC4338F for ; Thu, 29 Jul 2021 04:20:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 749ED6103B for ; Thu, 29 Jul 2021 04:20:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 749ED6103B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=In1Qk1MeHSZtkgvlQzhUSONdnOahw55ydOcMJON7dKU=; b=025ZTw/oOgQpDG NU9iRQmYnkc/Qed2+j2TSOFAecLLdPn9W9Qumjbm4xRsAn9J8FDV2NQzOBGbFopPTlrVuz+XXfwnu Lg233rO2BpCJU2EYf+t80qtZJ+R1ugclBQIWP1snGtl4fJgvNvKnPSp3/bEB1SpixfCwFzeB96H/o q35TOxuBAS+9L4Owi81BDMoHmtIIqgf1fSxqKGPrl96/DAxZQ3i6cc1Ynscz8pIYqt7wRy4sJqtId TdpMafzJy3fRPJdo46y4yPkZSDFTOBtVSp3qtcVV8ZlU2+AhprhNdwQ3pPayK2tmyb/H9YB4uPJcg 72mUo62MaFeNUsFYi7gQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8xVu-00330X-LL; Thu, 29 Jul 2021 04:19:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8xVq-0032zo-Ic for linux-arm-kernel@lists.infradead.org; Thu, 29 Jul 2021 04:19:16 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E04056103B; Thu, 29 Jul 2021 04:19:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627532353; bh=p8SBuZAJ6O+BJYgXJaAwIZI6ZZrm6vAYzJw2y8GigdQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fAfCwh0oVVfZCn3gmmS6VRDS8xNr4F03NxSvNPLI/vxHrqFH+8ANkQv27Cy6fwgqI Mq7WjpM7vbTQMONFufOWoHpqXU709sUU56zIGQfE+1zEEldVx9APx/xYrFchAsr7zw 5ryIM6Z0K3zZxp8SVtIBuM6GNoUO6WF1W8IRGuoYaf849hdwuWd91yRBSeklAd4C21 FV5awmwXiXP4Y0ZWwgXUhXntH34ACUrcSdiVfvNj9e6bMVwFsRyFOVF0wUh9nwc4gl y2CeCaYI795pPQFmhHw7+M8FFTSPwrtN3PifFB5rV0+YtbaJxrxA0kPZBvlatCIJed X/RC6kJxypd4A== Date: Thu, 29 Jul 2021 09:49:09 +0530 From: Vinod Koul To: Adrian Larumbe Cc: Adrian Larumbe , dmaengine@vger.kernel.org, michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/2] dmaengine: xilinx_dma: Restore support for memcpy SG transfers Message-ID: References: <20210706234338.7696-1-adrian.martinezlarumbe@imgtec.com> <20210706234338.7696-2-adrian.martinezlarumbe@imgtec.com> <20210726221423.5q6b5cwruznzqfxr@worklaptop.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210726221423.5q6b5cwruznzqfxr@worklaptop.localdomain> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210728_211914_698745_F3D34924 X-CRM114-Status: GOOD ( 38.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26-07-21, 23:14, Adrian Larumbe wrote: > Hi Vinod, I'm the same person who authored this patch. I left my previous > employer so no longer have access to their company email address. However I've > signed this email with the same GPG key to confirm my identity. > > On 14.07.2021 10:28, Vinod Koul wrote: > > On 07-07-21, 00:43, Adrian Larumbe wrote: > > > This is the old DMA_SG interface that was removed in commit > > > c678fa66341c ("dmaengine: remove DMA_SG as it is dead code in kernel"). It > > > has been renamed to DMA_MEMCPY_SG to better match the MEMSET and MEMSET_SG > > > naming convention. > > > > > > It should only be used for mem2mem copies, either main system memory or > > > CPU-addressable device memory (like video memory on a PCI graphics card). > > > > > > Bringing back this interface was prompted by the need to use the Xilinx > > > CDMA device for mem2mem SG transfers. The current CDMA binding for > > > device_prep_dma_memcpy_sg was partially borrowed from xlnx kernel tree, and > > > expanded with extended address space support when linking descriptor > > > segments and checking for incorrect zero transfer size. > > > > > > Signed-off-by: Adrian Larumbe > > > --- > > > .../driver-api/dmaengine/provider.rst | 11 ++ > > > drivers/dma/dmaengine.c | 7 + > > > drivers/dma/xilinx/xilinx_dma.c | 122 ++++++++++++++++++ > > > > Can you make this split... documentation patch, core change and then > > driver > > I understand you'd like these in three different patches, is that right? Or Correct > maybe one patch for the core change and its associated documentation, and doc and core should be different > another one for the consumer. > > > > include/linux/dmaengine.h | 20 +++ > > > 4 files changed, 160 insertions(+) > > > > > > diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst > > > index ddb0a81a796c..9f0efe9e9952 100644 > > > --- a/Documentation/driver-api/dmaengine/provider.rst > > > +++ b/Documentation/driver-api/dmaengine/provider.rst > > > @@ -162,6 +162,17 @@ Currently, the types available are: > > > > > > - The device is able to do memory to memory copies > > > > > > +- - DMA_MEMCPY_SG > > > + > > > + - The device supports memory to memory scatter-gather transfers. > > > + > > > + - Even though a plain memcpy can look like a particular case of a > > > + scatter-gather transfer, with a single chunk to transfer, it's a > > > + distinct transaction type in the mem2mem transfer case. This is > > > + because some very simple devices might be able to do contiguous > > > + single-chunk memory copies, but have no support for more > > > + complex SG transfers. > > > > How does one deal with cases where > > - src_sg_len and dstn_sg_len are different? > > Then only as many bytes as the smallest of the scattered buffers will be copied. Is that not a restriction and that needs to be documented with examples! > > > > - src_sg and dstn_sg are different lists (maybe different number of > > > entries with different lengths..) > > > > > > I think we need to document these cases or limitations.. > > I don't think we should place any restrictions on the number of scatterlist > entries or their length, and the consumer driver should ensure that these get > translated into a device-specific descriptor chain. However the previous > semantic should always be observed, which effectively turns the operation into > sort of a strncpy. That sounds right, but someone needs to know how to handle such cases with this API, that needs to be explained in detail on expected behaviour when src_sg_len & dstn_sg_len and same, less or more! -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel