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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 14A04C07E98 for ; Mon, 5 Jul 2021 03:53:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0573613CE for ; Mon, 5 Jul 2021 03:53:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229713AbhGEDz6 (ORCPT ); Sun, 4 Jul 2021 23:55:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:36870 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229700AbhGEDz4 (ORCPT ); Sun, 4 Jul 2021 23:55:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 99AA9613C9; Mon, 5 Jul 2021 03:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625457200; bh=elIXYsjFhQt/v0BxThJcD8RjLjjJbHU5/6nS2Y86KBc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fk7/noQtv7/ZZ8ImltTRPViDaejolf2pAgPD0NWkVDYXoLWXyaosGT88Z1OYEoG6l JXEGT2QfRi1+DTcqpmkPFamn3GgK91pM3TQ0tqpNFPvRv/+VqAsOqx+/S6YuxOph07 SfSstNs2KWVxMEwNom8nzVd/aM3eFW79dnUsRCYxfAeRGr6yhryyBO5Bq2Z0B9oGC9 dwyYIM+YbV2F1dRhdYkjXntCS3uncp8+EZp3DJCXeWK1l8i8EvqDKdz4hiwiCMvwE+ pig89d9eE0LFylFmb+RLZ3hcZl9uRLyWGU+wRrDT7vEyB2GmtBDW0Jwf6jQ6G2AStI RE6d5Be1MM+hA== Date: Mon, 5 Jul 2021 09:23:16 +0530 From: Vinod Koul To: Adrian Larumbe Cc: radhey pandey , Lars-Peter Clausen , dmaengine@vger.kernel.org, michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org, radheys@xilinx.com Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com> <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 02-07-21, 15:23, Adrian Larumbe wrote: > 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. I guess I should start putting this regularly now! Yes it is okay to bring dma sg support, provided 1. We have a user 2. the sematics of how that api works is well defined. Esp in the case where is src_sg and dstn_sg are different Also, I would not accept patches which implement this in guise of a different API. Thanks -- ~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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 73A0CC07E98 for ; Mon, 5 Jul 2021 03:58:29 +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 45D7E611AC for ; Mon, 5 Jul 2021 03:58:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 45D7E611AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=usjC/sbBK+ABIVCuEEJadWeWrUrHamYFPF3ODEj10DY=; b=0hB0NpvW2OqRWw //CwPW7Vcw8FUHORIIcLGrgZU4LOTgA/cUhpI4TOsh9y7fC9u9q0xf02EOr1Srqdf/J3SMPNrlMU4 msl8W2VXXM2YcNhGE6meShu8jzmqMwXsyiOcg7Tz4RoTt71QQEP7uZJ+jJWJsh/7pqaAyTcS0/2DK qEwfFwX19sB+KJSEtUjA8msBlrvLdd5QZTsPYORRGSCOtlZ8UllUGpo9W7KMIKkGp/nAXCbxw0Gs5 a5Gn7M0NgywlIQ6rb2l5/IE/ympIRJgIvXfD1B1T5icKtmrtdI/2jNYpn1FW0klVkaa1ggcJqWN7b KQX/aK5uSNBThCbX+h5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m0Fj6-007iJC-1K; Mon, 05 Jul 2021 03:56:56 +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 1m0Ffd-007gbX-C1 for linux-arm-kernel@lists.infradead.org; Mon, 05 Jul 2021 03:53:22 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 99AA9613C9; Mon, 5 Jul 2021 03:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625457200; bh=elIXYsjFhQt/v0BxThJcD8RjLjjJbHU5/6nS2Y86KBc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fk7/noQtv7/ZZ8ImltTRPViDaejolf2pAgPD0NWkVDYXoLWXyaosGT88Z1OYEoG6l JXEGT2QfRi1+DTcqpmkPFamn3GgK91pM3TQ0tqpNFPvRv/+VqAsOqx+/S6YuxOph07 SfSstNs2KWVxMEwNom8nzVd/aM3eFW79dnUsRCYxfAeRGr6yhryyBO5Bq2Z0B9oGC9 dwyYIM+YbV2F1dRhdYkjXntCS3uncp8+EZp3DJCXeWK1l8i8EvqDKdz4hiwiCMvwE+ pig89d9eE0LFylFmb+RLZ3hcZl9uRLyWGU+wRrDT7vEyB2GmtBDW0Jwf6jQ6G2AStI RE6d5Be1MM+hA== Date: Mon, 5 Jul 2021 09:23:16 +0530 From: Vinod Koul To: Adrian Larumbe Cc: radhey pandey , Lars-Peter Clausen , dmaengine@vger.kernel.org, michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org, radheys@xilinx.com Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com> <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210702142310.vowvjanfwfivu45a@adrianlarumbe-HP-Elite-7500-Series-MT> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210704_205321_518925_07705C1F X-CRM114-Status: GOOD ( 25.87 ) 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 02-07-21, 15:23, Adrian Larumbe wrote: > 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. I guess I should start putting this regularly now! Yes it is okay to bring dma sg support, provided 1. We have a user 2. the sematics of how that api works is well defined. Esp in the case where is src_sg and dstn_sg are different Also, I would not accept patches which implement this in guise of a different API. Thanks -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel