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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 3D4A7C11F68 for ; Fri, 2 Jul 2021 14:32:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 21C0261427 for ; Fri, 2 Jul 2021 14:32:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232875AbhGBOfL (ORCPT ); Fri, 2 Jul 2021 10:35:11 -0400 Received: from mx08-00376f01.pphosted.com ([91.207.212.86]:9762 "EHLO mx08-00376f01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232749AbhGBOfL (ORCPT ); Fri, 2 Jul 2021 10:35:11 -0400 X-Greylist: delayed 542 seconds by postgrey-1.27 at vger.kernel.org; Fri, 02 Jul 2021 10:35:11 EDT Received: from pps.filterd (m0168888.ppops.net [127.0.0.1]) by mx08-00376f01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 162CRYvS008923; Fri, 2 Jul 2021 15:23:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imgtec.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=dk201812; bh=hdrlkyt4i9VXpMEFo4pxkhE0lKEee8hSaxmMPrbCxqY=; b=HDuCnWekpgpLNtos2ehSalV3aMEiw6qbvq2FXd2fKbIijq1ssrHhtXvD2JRq340dXpNx 86UUPeL8pdTLVfttlVmZm8OdJ+sj2jlhijTFUDj08dpu73doCoIXFDeZu05FRdXBti/w h1eW3APbzlQGG0NyZAfBE0EqXSpigFOsA+dfpoYg1bw3c2d3qkctMwBjHewJKswjjfty 5tp+h9uq56Lh6q6yWXUros+UJelKinQKSighCc0JKku9MbamTtFZ2CIm0kTWojUqAjsK nbfEMuOUaXWjdUJejywvMvifNdWLBmO1DK3O3CoGEiY705ukoxD/yRk9Bd+srUxfePnh rA== Received: from hhmail05.hh.imgtec.org ([217.156.249.195]) by mx08-00376f01.pphosted.com with ESMTP id 39j23h02xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 02 Jul 2021 15:23:12 +0100 Received: from localhost (10.100.70.86) by HHMAIL05.hh.imgtec.org (10.100.10.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 2 Jul 2021 15:23:11 +0100 Date: Fri, 2 Jul 2021 15:23:10 +0100 From: Adrian Larumbe To: radhey pandey CC: Vinod Koul , Lars-Peter Clausen , , , , Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-Originating-IP: [10.100.70.86] X-ClientProxiedBy: HHMAIL05.hh.imgtec.org (10.100.10.120) To HHMAIL05.hh.imgtec.org (10.100.10.120) X-EXCLAIMER-MD-CONFIG: 15a78312-3e47-46eb-9010-2e54d84a9631 X-Proofpoint-GUID: fORXzKQOe-SJx2OrNF-VGnC-szgr9k1f X-Proofpoint-ORIG-GUID: fORXzKQOe-SJx2OrNF-VGnC-szgr9k1f Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 01.06.2021 15:59, radhey pandey wrote: > On Fri, Apr 23, 2021 at 10:51 PM Vinod Koul wrote: > > > > On 23-04-21, 15:51, Lars-Peter Clausen wrote: > > > On 4/23/21 3:24 PM, Vinod Koul wrote: > > > > On 23-04-21, 11:17, Lars-Peter Clausen wrote: > > > > > It seems to me what we are missing from the DMAengine API is the equivalent > > > > > of device_prep_dma_memcpy() that is able to take SG lists. There is already > > > > > a memset_sg, it should be possible to add something similar for memcpy. > > > > You mean something like dmaengine_prep_dma_sg() which was removed? > > > > > > > Ah, that's why I could have sworn we already had this! > > > > Even at that time we had the premise that we can bring the API back if > > we had users. I think many have asked for it, but I havent seen a patch > > with user yet :) > Right. Back then we had also discussed bringing the dma_sg API > but the idea was dropped as we didn't had a xilinx/any consumer > client driver for it in the mainline kernel. > > I think it's the same state now. Would it be alright if I brought back the old DMA_SG interface that was removed in commit c678fa66341c? It seems that what I've effectively done is implementing the semantics of that API call under the guise of dma_prep_slave. However I still need mem2mem SG transfer support on CDMA, which seems long gone from the driver, even though the HW does offer it. If people are fine with it I can restore that interface and CDMA as the sole consumer. > > > > static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg( > > > struct dma_chan *chan, > > > struct scatterlist *dst_sg, unsigned int dst_nents, > > > struct scatterlist *src_sg, unsigned int src_nents, > > > unsigned long flags) > > > > > > The problem with this API is that it would work only when src_sg and > > > dst_sg is of similar nature, if not then how should one go about > > > copying...should we fill without a care for dst_sg being different than > > > src_sg as long as total data to be copied has enough space in dst... > > At least for the CDMA the only requirement is that both buffers have the > > same total size. > > I will merge if with a user but semantics need to be absolutely clear on > what is allowed and not, do I hear a volunteer ? > -- > ~Vinod 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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 5D932C11F68 for ; Fri, 2 Jul 2021 14:25:10 +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 78F48613CB for ; Fri, 2 Jul 2021 14:25:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78F48613CB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=imgtec.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@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=9zcwd/XX5R3g8keRXTI19MFdbWQ9ZFP6kw6f9/TtFvo=; b=ksy5un8OjurNZ1 eYdglroqvAzySnAhOS7vtxlmsUM8ohBMguSkUzpN17FEUR37pCJZpf69aAF2Yy2K+suGrYOvso+ZG gmT4eMrhvi5TYGwUWXHZ7S625sIWZ1urGjvoCb8zH3n3m1xdAkHwgLr08f3q1rlSq+Vl3ex1cHG1Z vLT9I5FlqjkGX0KLsULvyp4SC7FmXxiSzwFJkR1UgMrcTYoaZSYRYrv6AU/LVxi+uCV6qioFr0xQb HqJF4rLbC3h4U2wxsXhA5WB7ZRU4YoL/Scau8L+q1wakCgKRNx+lGidPTgqKZ1YsxsvbBEkeSimJu KTuBQB1wsBbJPQInyytQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lzK4k-003FXB-3W; Fri, 02 Jul 2021 14:23:26 +0000 Received: from mx08-00376f01.pphosted.com ([91.207.212.86]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lzK4f-003FWp-OC for linux-arm-kernel@lists.infradead.org; Fri, 02 Jul 2021 14:23:23 +0000 Received: from pps.filterd (m0168888.ppops.net [127.0.0.1]) by mx08-00376f01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 162CRYvS008923; Fri, 2 Jul 2021 15:23:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imgtec.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=dk201812; bh=hdrlkyt4i9VXpMEFo4pxkhE0lKEee8hSaxmMPrbCxqY=; b=HDuCnWekpgpLNtos2ehSalV3aMEiw6qbvq2FXd2fKbIijq1ssrHhtXvD2JRq340dXpNx 86UUPeL8pdTLVfttlVmZm8OdJ+sj2jlhijTFUDj08dpu73doCoIXFDeZu05FRdXBti/w h1eW3APbzlQGG0NyZAfBE0EqXSpigFOsA+dfpoYg1bw3c2d3qkctMwBjHewJKswjjfty 5tp+h9uq56Lh6q6yWXUros+UJelKinQKSighCc0JKku9MbamTtFZ2CIm0kTWojUqAjsK nbfEMuOUaXWjdUJejywvMvifNdWLBmO1DK3O3CoGEiY705ukoxD/yRk9Bd+srUxfePnh rA== Received: from hhmail05.hh.imgtec.org ([217.156.249.195]) by mx08-00376f01.pphosted.com with ESMTP id 39j23h02xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 02 Jul 2021 15:23:12 +0100 Received: from localhost (10.100.70.86) by HHMAIL05.hh.imgtec.org (10.100.10.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 2 Jul 2021 15:23:11 +0100 Date: Fri, 2 Jul 2021 15:23:10 +0100 From: Adrian Larumbe To: radhey pandey CC: Vinod Koul , Lars-Peter Clausen , , , , Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-Originating-IP: [10.100.70.86] X-ClientProxiedBy: HHMAIL05.hh.imgtec.org (10.100.10.120) To HHMAIL05.hh.imgtec.org (10.100.10.120) X-EXCLAIMER-MD-CONFIG: 15a78312-3e47-46eb-9010-2e54d84a9631 X-Proofpoint-GUID: fORXzKQOe-SJx2OrNF-VGnC-szgr9k1f X-Proofpoint-ORIG-GUID: fORXzKQOe-SJx2OrNF-VGnC-szgr9k1f X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210702_072322_150288_66056223 X-CRM114-Status: GOOD ( 32.30 ) 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 01.06.2021 15:59, radhey pandey wrote: > On Fri, Apr 23, 2021 at 10:51 PM Vinod Koul wrote: > > > > On 23-04-21, 15:51, Lars-Peter Clausen wrote: > > > On 4/23/21 3:24 PM, Vinod Koul wrote: > > > > On 23-04-21, 11:17, Lars-Peter Clausen wrote: > > > > > It seems to me what we are missing from the DMAengine API is the equivalent > > > > > of device_prep_dma_memcpy() that is able to take SG lists. There is already > > > > > a memset_sg, it should be possible to add something similar for memcpy. > > > > You mean something like dmaengine_prep_dma_sg() which was removed? > > > > > > > Ah, that's why I could have sworn we already had this! > > > > Even at that time we had the premise that we can bring the API back if > > we had users. I think many have asked for it, but I havent seen a patch > > with user yet :) > Right. Back then we had also discussed bringing the dma_sg API > but the idea was dropped as we didn't had a xilinx/any consumer > client driver for it in the mainline kernel. > > I think it's the same state now. Would it be alright if I brought back the old DMA_SG interface that was removed in commit c678fa66341c? It seems that what I've effectively done is implementing the semantics of that API call under the guise of dma_prep_slave. However I still need mem2mem SG transfer support on CDMA, which seems long gone from the driver, even though the HW does offer it. If people are fine with it I can restore that interface and CDMA as the sole consumer. > > > > static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg( > > > struct dma_chan *chan, > > > struct scatterlist *dst_sg, unsigned int dst_nents, > > > struct scatterlist *src_sg, unsigned int src_nents, > > > unsigned long flags) > > > > > > The problem with this API is that it would work only when src_sg and > > > dst_sg is of similar nature, if not then how should one go about > > > copying...should we fill without a care for dst_sg being different than > > > src_sg as long as total data to be copied has enough space in dst... > > At least for the CDMA the only requirement is that both buffers have the > > same total size. > > I will merge if with a user but semantics need to be absolutely clear on > what is allowed and not, do I hear a volunteer ? > -- > ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel