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.2 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 48EC1C43461 for ; Fri, 23 Apr 2021 11:39:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0D34661425 for ; Fri, 23 Apr 2021 11:39:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231157AbhDWLj6 (ORCPT ); Fri, 23 Apr 2021 07:39:58 -0400 Received: from mx07-00376f01.pphosted.com ([185.132.180.163]:50098 "EHLO mx07-00376f01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230072AbhDWLj5 (ORCPT ); Fri, 23 Apr 2021 07:39:57 -0400 Received: from pps.filterd (m0168889.ppops.net [127.0.0.1]) by mx07-00376f01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 13N7lYbl007463; Fri, 23 Apr 2021 12:39:01 +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=neyO67KHOkdsSRPKA3TCOuGMIaXXeOtfMiT60PTC1ms=; b=q+SXAS1UGkL7XPI1lwrGeEdXk6211cySlbVoecrznyl2ysLSLwN6KSk61ZFkHdGA9xoW z3HFT8fqHbCRE0js36pt1GJEG3IsJgOIB2RmalA4lWpYG1lYz6j/+oI+YvSvyEOfNYTh shTitSayXfuqk4rwv7SQcHKgW/j46fH6A8+q7jEmEc5UM8o/0RpPaY+jDCCwMXR9ihom p/STvOpych+sxR9ivtHtMgTu1umDjdc2qo9ykfV2Q1ZpKyTIzQp/3hzZ/dK+2+cFfc7b k5Q74EfmB0uJYLqSJeY6i76oa4yBiMRQw0K0UygKluVunKgbKavS9cc68iJnwY+89x3n Aw== Received: from hhmail05.hh.imgtec.org ([217.156.249.195]) by mx07-00376f01.pphosted.com with ESMTP id 383r8kr6nf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Apr 2021 12:39:01 +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.2; Fri, 23 Apr 2021 12:39:00 +0100 Date: Fri, 23 Apr 2021 12:38:59 +0100 From: Adrian Larumbe To: Lars-Peter Clausen CC: , , , Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: <20210423113859.tdowrt5nx5bxb225@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: 5NUt_YeRbKCeH2jKf4bTfoK1xEhajsux X-Proofpoint-ORIG-GUID: 5NUt_YeRbKCeH2jKf4bTfoK1xEhajsux Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 23.04.2021 11:17, Lars-Peter Clausen wrote: > The device_config() and device_prep_slave_sg() APIs are meant for > memory-to-device or device-to-memory transfers. This means the device address > is fixed and usually maps to a FIFO in the device. > > What you are implementing is memory-to-memory, which means addresses are > incremented on both sides of transfer. And this works if you know what you are > doing, e.g. you know that you are using a specific dmaengine driver that > implements the dmaengine API in a way that does not comply with the > specification. But it breaks for generic dmaengine API clients that expect > compliant behavior. And it is the reason why we have an API in the first > place, to get consistent behavior. If you have to know about the driver > specific semantics you might as well just bypass the framework and use driver > specific functions. You're absolutely right about this. I think I might've been confused when picking the right DMA Engine API callback to write this new functionality into by the fact that, on our particular configuration, transfers were being done between main system memory and DDR memory on a PCI card. However, from the point of view of the semantics of the API, these are still memory-to-memory transfers, just like you said. > 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. I wasn't aware of the existence of this callback. Grepping the sources reveals a single consumer at the moment, I guess this also might've led me to wrongly conclude device_prep_slave_sg was the right choice. Perhaps I can convert most of the code currently in xilinx_cdma_prep_slave_sg to fit the semantics of this DMAengine API function instead. Any thoughts on this? Cheers, Adrian 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.2 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 A1B6BC433B4 for ; Fri, 23 Apr 2021 11:41:04 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 12C1B61409 for ; Fri, 23 Apr 2021 11:41:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12C1B61409 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=desiato.20200630; 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=BwuRYJgKayMPyGdon5+E2qtVvYAassnfDVzI3Tr482k=; b=a64L8CTaEI5tbyvI1WJFPeGGf fe5HnzazGrfjy8DKgsL6wyBVVu7FpzT4gojfqMyL7XGQjHvuVqMnTmjfrNATELkYqy5OYH0joDEeS ZFI+JKKdGg1yFU8w7xLDOJABlAEQ3PTXLasNIjlGljDJM5sKWnbJEKhZ8A8lI1nY3g73hnyzaO724 WHFcTciqxeYjeaa3IYYGhWzTNHxOHFXgBswOZB0eznpbsLGT2UPKoZ8HE5m6XrC6CQU0eP/Ho7Wz4 h0k/VCXnGBcS5w7bEAjPzk1r3rUMX1SOpB0q2fsw5zsjubcaJfGXT36PW2+vFf33mQF7DiEwsqmXp svuWboy7w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZu9T-001NXU-7I; Fri, 23 Apr 2021 11:39:15 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZu9P-001NX4-Px for linux-arm-kernel@desiato.infradead.org; Fri, 23 Apr 2021 11:39:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:CC:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=neyO67KHOkdsSRPKA3TCOuGMIaXXeOtfMiT60PTC1ms=; b=jVH3n6bi5sr2dZMo35TSM0E/t/ ZM3qpkNRp+zWawx4UJgBq8ZUqD+ixrIjcJqFGdscGMQhC0W2e8vU/bQfKVga8IDm2R7WMQADXSyiR H+6Nrxa2LPDMmU0rPnM9/QHDZTmpmwonUBhPMkrYKTsb2oa9XnAQNP5EvK+3+NufzTMO0jDo7xPLS i82BcMe0T+BrYrKN81j6ZxoJ1uS44RC0IHraPfQhePGwgEZ8/sun69NJwQHXWP82ZtF7VEm7oFTaF rVvlAbZK0H2g+iShu03U3AUFI+2YQflvo8NlQUA36kOhhoIcFX7JNdSqqowWC6PPQSrqdXvmbexdx SB+X95nA==; Received: from mx07-00376f01.pphosted.com ([185.132.180.163]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZu9L-00EMrI-UK for linux-arm-kernel@lists.infradead.org; Fri, 23 Apr 2021 11:39:10 +0000 Received: from pps.filterd (m0168889.ppops.net [127.0.0.1]) by mx07-00376f01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 13N7lYbl007463; Fri, 23 Apr 2021 12:39:01 +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=neyO67KHOkdsSRPKA3TCOuGMIaXXeOtfMiT60PTC1ms=; b=q+SXAS1UGkL7XPI1lwrGeEdXk6211cySlbVoecrznyl2ysLSLwN6KSk61ZFkHdGA9xoW z3HFT8fqHbCRE0js36pt1GJEG3IsJgOIB2RmalA4lWpYG1lYz6j/+oI+YvSvyEOfNYTh shTitSayXfuqk4rwv7SQcHKgW/j46fH6A8+q7jEmEc5UM8o/0RpPaY+jDCCwMXR9ihom p/STvOpych+sxR9ivtHtMgTu1umDjdc2qo9ykfV2Q1ZpKyTIzQp/3hzZ/dK+2+cFfc7b k5Q74EfmB0uJYLqSJeY6i76oa4yBiMRQw0K0UygKluVunKgbKavS9cc68iJnwY+89x3n Aw== Received: from hhmail05.hh.imgtec.org ([217.156.249.195]) by mx07-00376f01.pphosted.com with ESMTP id 383r8kr6nf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Apr 2021 12:39:01 +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.2; Fri, 23 Apr 2021 12:39:00 +0100 Date: Fri, 23 Apr 2021 12:38:59 +0100 From: Adrian Larumbe To: Lars-Peter Clausen CC: , , , Subject: Re: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions Message-ID: <20210423113859.tdowrt5nx5bxb225@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: 5NUt_YeRbKCeH2jKf4bTfoK1xEhajsux X-Proofpoint-ORIG-GUID: 5NUt_YeRbKCeH2jKf4bTfoK1xEhajsux X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210423_043908_298644_89781B08 X-CRM114-Status: GOOD ( 21.57 ) 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 23.04.2021 11:17, Lars-Peter Clausen wrote: > The device_config() and device_prep_slave_sg() APIs are meant for > memory-to-device or device-to-memory transfers. This means the device address > is fixed and usually maps to a FIFO in the device. > > What you are implementing is memory-to-memory, which means addresses are > incremented on both sides of transfer. And this works if you know what you are > doing, e.g. you know that you are using a specific dmaengine driver that > implements the dmaengine API in a way that does not comply with the > specification. But it breaks for generic dmaengine API clients that expect > compliant behavior. And it is the reason why we have an API in the first > place, to get consistent behavior. If you have to know about the driver > specific semantics you might as well just bypass the framework and use driver > specific functions. You're absolutely right about this. I think I might've been confused when picking the right DMA Engine API callback to write this new functionality into by the fact that, on our particular configuration, transfers were being done between main system memory and DDR memory on a PCI card. However, from the point of view of the semantics of the API, these are still memory-to-memory transfers, just like you said. > 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. I wasn't aware of the existence of this callback. Grepping the sources reveals a single consumer at the moment, I guess this also might've led me to wrongly conclude device_prep_slave_sg was the right choice. Perhaps I can convert most of the code currently in xilinx_cdma_prep_slave_sg to fit the semantics of this DMAengine API function instead. Any thoughts on this? Cheers, Adrian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel