[{"id":1773004,"web_url":"http://patchwork.ozlabs.org/comment/1773004/","msgid":"<20170921171451.GG30097@localhost>","list_archive_url":null,"date":"2017-09-21T17:14:51","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":8232,"url":"http://patchwork.ozlabs.org/api/people/8232/","name":"Vinod Koul","email":"vinod.koul@intel.com"},"content":"On Tue, Sep 12, 2017 at 01:44:22PM +0300, Peter Ujfalusi wrote:\n> Certain DMA engines have limitation on the maximum size of a transfer they\n> can support. This size limitation is per SG element or for period length in\n> cyclic transfers.\n> In TI's eDMA and sDMA this limitation is not really a length limit, but it\n> is the number of bursts that we can support in one transfer.\n> \n> With this callback the DMA drivers can provide hints to clients on how they\n> should set up their buffers (sglist, cyclic buffer). Without this the\n> clients must have open coded workarounds in place for each and every DMA\n> engine they might be interfacing with to have correct length for the\n> transfers.\n> \n> Signed-off-by: Peter Ujfalusi \n> ---\n> include/linux/dmaengine.h | 14 ++++++++++++++\n> 1 file changed, 14 insertions(+)\n> \n> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h\n> index 8319101170fc..739824b94c1b 100644\n> --- a/include/linux/dmaengine.h\n> +++ b/include/linux/dmaengine.h\n> @@ -705,6 +705,9 @@ struct dma_filter {\n> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address\n> * @device_config: Pushes a new configuration to a channel, return 0 or an error\n> *\tcode\n> + * @device_get_max_len: Get the maximum supported length in bytes of a slave\n> + *\ttransfer based on the set dma_slave_config. The length limitation\n> + *\tapplies to each SG element's length.\n> * @device_pause: Pauses any transfer happening on a channel. Returns\n> *\t0 or an error code\n> * @device_resume: Resumes any transfer on a channel previously\n> @@ -792,6 +795,8 @@ struct dma_device {\n> \n> \tint (*device_config)(struct dma_chan *chan,\n> \t\t\t struct dma_slave_config *config);\n> +\tu32 (*device_get_max_len)(struct dma_chan *chan,\n> +\t\t\t\t enum dma_transfer_direction dir);\n> \tint (*device_pause)(struct dma_chan *chan);\n> \tint (*device_resume)(struct dma_chan *chan);\n> \tint (*device_terminate_all)(struct dma_chan *chan);\n> @@ -812,6 +817,15 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,\n> \treturn -ENOSYS;\n> }\n> \n> +static inline u32 dmaengine_slave_get_max_len(struct dma_chan *chan,\n> +\t\t\t\t\t enum dma_transfer_direction dir)\n> +{\n> +\tif (chan->device->device_get_max_len)\n> +\t\treturn chan->device->device_get_max_len(chan, dir);\n\nnot another callback :)\n\non a serious note, why shouldn't this be one more capability in\ndma_slave_caps. looking at next patch it seems static","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"TMT0LMn0\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyjnY5Xhxz9t4Z\n\tfor ;\n\tFri, 22 Sep 2017 03:11:29 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dv50Y-00031I-AD; Thu, 21 Sep 2017 17:11:26 +0000","from mga05.intel.com ([192.55.52.43])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dv50T-0002wd-Jr for linux-arm-kernel@lists.infradead.org;\n\tThu, 21 Sep 2017 17:11:23 +0000","from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby fmsmga105.fm.intel.com with ESMTP; 21 Sep 2017 10:11:01 -0700","from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143])\n\tby fmsmga005.fm.intel.com with ESMTP; 21 Sep 2017 10:10:59 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=2y9FcuCAfiWaycrthv1Ed9z23koa/9tbtsHXTLupwuA=;\n\tb=TMT0LMn0LZ7dAv\n\t6XDwRRCCATXMXRSrvMMxj7/rDFskOG95/2YBRrA3c67LMn35cP7ItiFPxVoFfSy/mthPGoRxAPeb2\n\t/WD3Q3HR3mZG6YF+53fNzeyJVetBxQJeuNKMok7lzTefNGQFZUeDhHkZB1/UknebzSA+TH+4HcFGZ\n\t//DaCsJxTjg4G+jR56QJ+e/BBFL8NfD3YjYAdKERGmdeROPJCt29FeQ7R6mcf9Ga21sBV3b64+dUz\n\ta1lbEk+rER1MNeMwyU3dTwKNgRo4RlfNccALjMxmzRv97Rgurl7sCBZqgLm1lTBX0lY6V1qbqFX0a\n\tnTgBcSshSTP7ivxxzVgw==;","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,425,1500966000\"; d=\"scan'208\";a=\"154024784\"","Date":"Thu, 21 Sep 2017 22:44:51 +0530","From":"Vinod Koul ","To":"Peter Ujfalusi ","Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","Message-ID":"<20170921171451.GG30097@localhost>","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170912104424.18495-4-peter.ujfalusi@ti.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170921_101121_757198_D6A386D5 ","X-CRM114-Status":"GOOD ( 17.42 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [192.55.52.43 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773394,"web_url":"http://patchwork.ozlabs.org/comment/1773394/","msgid":"<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>","list_archive_url":null,"date":"2017-09-22T09:39:38","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":9142,"url":"http://patchwork.ozlabs.org/api/people/9142/","name":"Peter Ujfalusi","email":"peter.ujfalusi@ti.com"},"content":"\nTexas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n\nOn 2017-09-21 20:14, Vinod Koul wrote:\n> On Tue, Sep 12, 2017 at 01:44:22PM +0300, Peter Ujfalusi wrote:\n>> Certain DMA engines have limitation on the maximum size of a transfer they\n>> can support. This size limitation is per SG element or for period length in\n>> cyclic transfers.\n>> In TI's eDMA and sDMA this limitation is not really a length limit, but it\n>> is the number of bursts that we can support in one transfer.\n>>\n>> With this callback the DMA drivers can provide hints to clients on how they\n>> should set up their buffers (sglist, cyclic buffer). Without this the\n>> clients must have open coded workarounds in place for each and every DMA\n>> engine they might be interfacing with to have correct length for the\n>> transfers.\n>>\n>> Signed-off-by: Peter Ujfalusi \n>> ---\n>> include/linux/dmaengine.h | 14 ++++++++++++++\n>> 1 file changed, 14 insertions(+)\n>>\n>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h\n>> index 8319101170fc..739824b94c1b 100644\n>> --- a/include/linux/dmaengine.h\n>> +++ b/include/linux/dmaengine.h\n>> @@ -705,6 +705,9 @@ struct dma_filter {\n>> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address\n>> * @device_config: Pushes a new configuration to a channel, return 0 or an error\n>> *\tcode\n>> + * @device_get_max_len: Get the maximum supported length in bytes of a slave\n>> + *\ttransfer based on the set dma_slave_config. The length limitation\n>> + *\tapplies to each SG element's length.\n>> * @device_pause: Pauses any transfer happening on a channel. Returns\n>> *\t0 or an error code\n>> * @device_resume: Resumes any transfer on a channel previously\n>> @@ -792,6 +795,8 @@ struct dma_device {\n>> \n>> \tint (*device_config)(struct dma_chan *chan,\n>> \t\t\t struct dma_slave_config *config);\n>> +\tu32 (*device_get_max_len)(struct dma_chan *chan,\n>> +\t\t\t\t enum dma_transfer_direction dir);\n>> \tint (*device_pause)(struct dma_chan *chan);\n>> \tint (*device_resume)(struct dma_chan *chan);\n>> \tint (*device_terminate_all)(struct dma_chan *chan);\n>> @@ -812,6 +817,15 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,\n>> \treturn -ENOSYS;\n>> }\n>> \n>> +static inline u32 dmaengine_slave_get_max_len(struct dma_chan *chan,\n>> +\t\t\t\t\t enum dma_transfer_direction dir)\n>> +{\n>> +\tif (chan->device->device_get_max_len)\n>> +\t\treturn chan->device->device_get_max_len(chan, dir);\n> \n> not another callback :)\n> \n> on a serious note, why shouldn't this be one more capability in\n> dma_slave_caps. looking at next patch it seems static\n\nIt is not really static, the size in bytes depends on the dev_width and\nthe maxburst:\ndev_width * burst * (SZ_64K - 1);\n\nThe number of (dev_width * burst) is static, yes. Other DMA engines\nmight have similar interpretation, but returning the maximum length in\nbytes sounded more generic for other engines to be able to adopt.\n\nInitially I had maxburst_cnt in struct dma_device for maximum burst\ncount within one SG, but it felt clumsy and not too intuitive either.\n\n- Péter","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"TpYpc3+Q\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"jeMos4CS\"; \n\tdkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz7kG2bLqz9sP1\n\tfor ;\n\tFri, 22 Sep 2017 19:40:06 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvKRE-0007LE-K4; Fri, 22 Sep 2017 09:40:00 +0000","from lelnx194.ext.ti.com ([198.47.27.80])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvKRA-0007Ge-Eo for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 09:39:58 +0000","from dflxv15.itg.ti.com ([128.247.5.124])\n\tby lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id v8M9dXTQ031821; \n\tFri, 22 Sep 2017 04:39:33 -0500","from DFLE100.ent.ti.com (dfle100.ent.ti.com [10.64.6.21])\n\tby dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v8M9dX9w015931;\n\tFri, 22 Sep 2017 04:39:33 -0500","from DFLE110.ent.ti.com (10.64.6.31) by DFLE100.ent.ti.com\n\t(10.64.6.21) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tFri, 22 Sep 2017 04:39:33 -0500","from dlep33.itg.ti.com (157.170.170.75) by DFLE110.ent.ti.com\n\t(10.64.6.31) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Fri, 22 Sep 2017 04:39:33 -0500","from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id v8M9dVgS010349;\n\tFri, 22 Sep 2017 04:39:31 -0500"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=cGnQXRBez7S5Q916o6c/kQZuiGQXuBfTjzWzClUlJ4M=;\n\tb=TpYpc3+QDT5mcY\n\txaRTegqO86P4rHnyOxohMLiQZA+kdjALiQederRTbA9WkUtHyRSkzNgIa563NaAqUljCzPYXg+TgV\n\tf+OPyHQJNjPspdZLjcTjOyzvE7sckKNKaA6bHcB5tr40UjA4sfCNYSYY7KWv94AgcL5d5+Q60syvX\n\t/i0wwn7236E4nr/XTBo7pUdQaj5C+SVOnWIvZ8PXsIoNyLbNfAZ21Z1Uwp8J1Pg5v6uzwOehr/d3F\n\tEbRDJ+Uvu9RVm07izIjqGDoLVWKz+aZ2NGuJLOK0ngPI2OqXlxYCKMwS4x6le6Av3fepjj0P/pVuf\n\tE0V5J8m1XUxGerzJ3sgw==;","v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1506073173;\n\tbh=8NtF9KG0588mTZKEbkg8i1Zw8ViLZUzkeFEpYoL+qSg=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=jeMos4CSSQK5P0Qxl69xcDtILiLZrn63Em2uQG9QToKr5ueRI9KoNZJWcKZwAqKhA\n\tdN4H/yyl7XGxARikaIlrMrBMo3UACH3jHobWukS0XSijK7Tin6QTofKq6GilZjp+FO\n\tUC5ItEzG/mey3JKRkEDcrUchsd/2yMK8EyJtsT8Q="],"Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","To":"Vinod Koul ","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>","From":"Peter Ujfalusi ","Message-ID":"<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>","Date":"Fri, 22 Sep 2017 12:39:38 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170921171451.GG30097@localhost>","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_023956_616648_5981ABAF ","X-CRM114-Status":"GOOD ( 13.55 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno trust [198.47.27.80 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1775681,"web_url":"http://patchwork.ozlabs.org/comment/1775681/","msgid":"<20170926165413.GQ30097@localhost>","list_archive_url":null,"date":"2017-09-26T16:54:13","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":8232,"url":"http://patchwork.ozlabs.org/api/people/8232/","name":"Vinod Koul","email":"vinod.koul@intel.com"},"content":"On Fri, Sep 22, 2017 at 12:39:38PM +0300, Peter Ujfalusi wrote:\n> \n> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n> \n> On 2017-09-21 20:14, Vinod Koul wrote:\n> > On Tue, Sep 12, 2017 at 01:44:22PM +0300, Peter Ujfalusi wrote:\n> >> Certain DMA engines have limitation on the maximum size of a transfer they\n> >> can support. This size limitation is per SG element or for period length in\n> >> cyclic transfers.\n> >> In TI's eDMA and sDMA this limitation is not really a length limit, but it\n> >> is the number of bursts that we can support in one transfer.\n> >>\n> >> With this callback the DMA drivers can provide hints to clients on how they\n> >> should set up their buffers (sglist, cyclic buffer). Without this the\n> >> clients must have open coded workarounds in place for each and every DMA\n> >> engine they might be interfacing with to have correct length for the\n> >> transfers.\n> >>\n> >> Signed-off-by: Peter Ujfalusi \n> >> ---\n> >> include/linux/dmaengine.h | 14 ++++++++++++++\n> >> 1 file changed, 14 insertions(+)\n> >>\n> >> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h\n> >> index 8319101170fc..739824b94c1b 100644\n> >> --- a/include/linux/dmaengine.h\n> >> +++ b/include/linux/dmaengine.h\n> >> @@ -705,6 +705,9 @@ struct dma_filter {\n> >> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address\n> >> * @device_config: Pushes a new configuration to a channel, return 0 or an error\n> >> *\tcode\n> >> + * @device_get_max_len: Get the maximum supported length in bytes of a slave\n> >> + *\ttransfer based on the set dma_slave_config. The length limitation\n> >> + *\tapplies to each SG element's length.\n> >> * @device_pause: Pauses any transfer happening on a channel. Returns\n> >> *\t0 or an error code\n> >> * @device_resume: Resumes any transfer on a channel previously\n> >> @@ -792,6 +795,8 @@ struct dma_device {\n> >> \n> >> \tint (*device_config)(struct dma_chan *chan,\n> >> \t\t\t struct dma_slave_config *config);\n> >> +\tu32 (*device_get_max_len)(struct dma_chan *chan,\n> >> +\t\t\t\t enum dma_transfer_direction dir);\n> >> \tint (*device_pause)(struct dma_chan *chan);\n> >> \tint (*device_resume)(struct dma_chan *chan);\n> >> \tint (*device_terminate_all)(struct dma_chan *chan);\n> >> @@ -812,6 +817,15 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,\n> >> \treturn -ENOSYS;\n> >> }\n> >> \n> >> +static inline u32 dmaengine_slave_get_max_len(struct dma_chan *chan,\n> >> +\t\t\t\t\t enum dma_transfer_direction dir)\n> >> +{\n> >> +\tif (chan->device->device_get_max_len)\n> >> +\t\treturn chan->device->device_get_max_len(chan, dir);\n> > \n> > not another callback :)\n> > \n> > on a serious note, why shouldn't this be one more capability in\n> > dma_slave_caps. looking at next patch it seems static\n> \n> It is not really static, the size in bytes depends on the dev_width and\n> the maxburst:\n> dev_width * burst * (SZ_64K - 1);\n\nwell DMAengines work on FIFOs, in above you are giving length as SZ_64K - 1\n'items' which IIUC in DMAengine terms for bytes would always refer wrt width\nused and burst applied.\n\nReturn length in bytes does make sense (from user PoV), but then you need to\n\"know\" the applied width and burst. How do you decide those?\n\n> \n> The number of (dev_width * burst) is static, yes. Other DMA engines\n> might have similar interpretation, but returning the maximum length in\n> bytes sounded more generic for other engines to be able to adopt.\n> \n> Initially I had maxburst_cnt in struct dma_device for maximum burst\n> count within one SG, but it felt clumsy and not too intuitive either.\n\n> \n> - Péter\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Ocgorflv\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1n5w0Pn3z9s7f\n\tfor ;\n\tWed, 27 Sep 2017 02:51:12 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwt4d-0005aT-Lw; Tue, 26 Sep 2017 16:51:07 +0000","from mga04.intel.com ([192.55.52.120])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwt4F-0005Um-2V for linux-arm-kernel@lists.infradead.org;\n\tTue, 26 Sep 2017 16:50:44 +0000","from orsmga002.jf.intel.com ([10.7.209.21])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t26 Sep 2017 09:50:18 -0700","from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143])\n\tby orsmga002.jf.intel.com with ESMTP; 26 Sep 2017 09:50:15 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=OLkv89sCjunv1jNmNbpPZYWGly+T4Ucs4VqkpUvkM0U=;\n\tb=OcgorflvMVNyUf\n\tl9i/6fkUoeJdjw9ZoK2NN2F/I/NOK5iqd4+O3OqD/6buxYe/rEeQOi9nHB9fcpAWT66JG1gYBADWk\n\twb+P+qKoWnl3W5ovKrcQ35RMAs21CLNMyIinKwqEV/tyB88N+OvqvBbZ1QbU6XH8dWrWisP6Fl7iJ\n\tZF57lmNr7kNsCd/jR75A3dq1Yf2fcjs5vR+5NuAVfrZJGwRwizukIk/esCcJtZTC0Qq66yL19JEkY\n\tHvLSzCvNiHSIfVP9SdrEIDaLh7uNSGHGHJcbTtkjQLvIZNYFkVXggOYXe3ToQz+ikSKc8GJa7aGC5\n\tv648VgUV8YHCGnH8A/zQ==;","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,441,1500966000\"; d=\"scan'208\";a=\"139655806\"","Date":"Tue, 26 Sep 2017 22:24:13 +0530","From":"Vinod Koul ","To":"Peter Ujfalusi ","Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","Message-ID":"<20170926165413.GQ30097@localhost>","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>\n\t<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170926_095043_141658_F70B6E82 ","X-CRM114-Status":"GOOD ( 22.73 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [192.55.52.120 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1778267,"web_url":"http://patchwork.ozlabs.org/comment/1778267/","msgid":"<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>","list_archive_url":null,"date":"2017-10-02T11:24:12","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":9142,"url":"http://patchwork.ozlabs.org/api/people/9142/","name":"Peter Ujfalusi","email":"peter.ujfalusi@ti.com"},"content":"\n\n\nTexas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n\nOn 2017-09-26 19:54, Vinod Koul wrote:\n>>>\n>>> not another callback :)\n>>>\n>>> on a serious note, why shouldn't this be one more capability in\n>>> dma_slave_caps. looking at next patch it seems static\n>>\n>> It is not really static, the size in bytes depends on the dev_width and\n>> the maxburst:\n>> dev_width * burst * (SZ_64K - 1);\n> \n> well DMAengines work on FIFOs, in above you are giving length as SZ_64K - 1\n> 'items' which IIUC in DMAengine terms for bytes would always refer wrt width\n> used and burst applied.\n\nI think we can live with this and let the user to figure out what to do\nwith this information.\n\nBut I'm having hard time to figure out a good name for this. It is not\nthe number of SGs we can support, but the number of 'items' within one\nSG that we have the limit. It could be:\nu32 max_bursts_per_sg;\n\nwhich would also apply to period length (for cyclic) in a similar way.\n\n> Return length in bytes does make sense (from user PoV), but then you need to\n> \"know\" the applied width and burst. How do you decide those?\n\nThe number of items works eDMA and sDMA, but we also have the cpp41. It\nis a packet DMA and it has no understanding of bursts, address widths or\nany of the 'traditional' things. It only cares about the number of bytes\nwe want to transfer and it has limitation of 4194303 bytes (21bits for\nlength). This is again per SG. How this could report the\n'max_bursts_per_sg' ?\n\nThis was one of the reasons that I have settled with the callback.\n\nWhat we can also do is to code this within the DMA drivers itself.\n\nWhen setting up the transfer and we realize that one of the SG will not\ngoing to fit, we destroy what we have done so far, pass the sg list\nalong with length/sg limit to create a new sg list where all sg item's\nlength is under the limit. Then using this new sg list we can set up the\ntransfer.\n\nI'm not sure how hard is to do the sg list optimization, I see that\nsg_split() is not what we want so we might need to code this in\ndmaengine or in the scatterlist code.\n\nWe certainly don't want to verify all slave_sg transfers proactively to\navoid adding latency when it is not necessary.\n\n\n>>\n>> The number of (dev_width * burst) is static, yes. Other DMA engines\n>> might have similar interpretation, but returning the maximum length in\n>> bytes sounded more generic for other engines to be able to adopt.\n>>\n>> Initially I had maxburst_cnt in struct dma_device for maximum burst\n>> count within one SG, but it felt clumsy and not too intuitive either.\n> \n>>\n>> - Péter\n>>\n> \n\n- Péter","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"p840Y4MJ\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"qVn2JH6Y\"; \n\tdkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y5KbG0HQBz9t4X\n\tfor ;\n\tMon, 2 Oct 2017 22:25:30 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dyyqh-00025F-O2; Mon, 02 Oct 2017 11:25:23 +0000","from fllnx209.ext.ti.com ([198.47.19.16])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dyyqK-0000wb-1L for linux-arm-kernel@lists.infradead.org;\n\tMon, 02 Oct 2017 11:25:02 +0000","from dflxv15.itg.ti.com ([128.247.5.124])\n\tby fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id v92BO89O029443; \n\tMon, 2 Oct 2017 06:24:08 -0500","from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23])\n\tby dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v92BO2Y1013901;\n\tMon, 2 Oct 2017 06:24:03 -0500","from DFLE111.ent.ti.com (10.64.6.32) by DFLE102.ent.ti.com\n\t(10.64.6.23) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tMon, 2 Oct 2017 06:24:02 -0500","from dlep32.itg.ti.com (157.170.170.100) by DFLE111.ent.ti.com\n\t(10.64.6.32) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Mon, 2 Oct 2017 06:24:02 -0500","from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id v92BO0MS026353;\n\tMon, 2 Oct 2017 06:24:00 -0500"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=6qjmeD8Tm4LfPv0dShvYGB7Ad8WwqQHCDgdUPDEKxPY=;\n\tb=p840Y4MJJqNRRw\n\tAUg+uiyBt1NHvmkWGh6mPHMBDS1SwJ4n/52+AYfzXCkvqNGgtNxahWKWx4XvCPtH07wowbztNKN6i\n\tthrmOvwAx4YjTDAKqjNN+YkGKzJeN9XDk1VMFlQd0Br1XYxnpFrotv74r1JJSwu4gZjkq3Us+9YlE\n\tF75eU1ANvZ60HucNVKlIIL3M7i1tgYzT1KjplcvlTfgWgvS7+IhdT+iOJ4DsuZHQmA91j5JOTm1Ms\n\tB3gpA2PO3sLHEg/U22V5SRhjoEDxjt6N7cZVqH9EFAewygojAk3JFEleci6OyiGtQkefq3xp5SKMF\n\tc7BULG21K85+o8N/GkfQ==;","v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1506943448;\n\tbh=YDjydJ07NI/Cl/AO5UVR2qLooUGhyW6IFg1kPUD4+KI=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=qVn2JH6Y13bRMJwHI/X8sEUc2bmE8pYwEyqDGi07bafHBaPEqJHI6IjbXWm6R7zO6\n\t3u0OuPeWjS2tqbJO4QL5r9TkbFCKMomx64gtBiQzwP++zIX2pJ7Jb1sRBpiGac81W0\n\tdEAwnChcZemjy+tHpCFvz9f1Z1AE5iACWEyEw3yY="],"Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","To":"Vinod Koul ","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>\n\t<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>\n\t<20170926165413.GQ30097@localhost>","From":"Peter Ujfalusi ","Message-ID":"<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>","Date":"Mon, 2 Oct 2017 14:24:12 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170926165413.GQ30097@localhost>","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171002_042500_219745_5D5B3F51 ","X-CRM114-Status":"GOOD ( 15.09 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno trust [198.47.19.16 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1782202,"web_url":"http://patchwork.ozlabs.org/comment/1782202/","msgid":"<20171008052514.GG30097@localhost>","list_archive_url":null,"date":"2017-10-08T05:25:15","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":8232,"url":"http://patchwork.ozlabs.org/api/people/8232/","name":"Vinod Koul","email":"vinod.koul@intel.com"},"content":"On Mon, Oct 02, 2017 at 02:24:12PM +0300, Peter Ujfalusi wrote:\n> \n> \n> \n> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n> \n> On 2017-09-26 19:54, Vinod Koul wrote:\n> >>>\n> >>> not another callback :)\n> >>>\n> >>> on a serious note, why shouldn't this be one more capability in\n> >>> dma_slave_caps. looking at next patch it seems static\n> >>\n> >> It is not really static, the size in bytes depends on the dev_width and\n> >> the maxburst:\n> >> dev_width * burst * (SZ_64K - 1);\n> > \n> > well DMAengines work on FIFOs, in above you are giving length as SZ_64K - 1\n> > 'items' which IIUC in DMAengine terms for bytes would always refer wrt width\n> > used and burst applied.\n> \n> I think we can live with this and let the user to figure out what to do\n> with this information.\n\nRight, plus a macro for conversion :) SO that users dont code buggy\nconversions all over the place\n\n> But I'm having hard time to figure out a good name for this. It is not\n> the number of SGs we can support, but the number of 'items' within one\n> SG that we have the limit. It could be:\n> u32 max_bursts_per_sg;\n\nthis looks fine, another candidate I would use is words_per_sg and while at\nit why tie it to sg? should we make it words_per_txn but then people should not\nconfuse with txn represented by a descriptor which can have multiple ....\n\n> \n> which would also apply to period length (for cyclic) in a similar way.\n> \n> > Return length in bytes does make sense (from user PoV), but then you need to\n> > \"know\" the applied width and burst. How do you decide those?\n> \n> The number of items works eDMA and sDMA, but we also have the cpp41. It\n> is a packet DMA and it has no understanding of bursts, address widths or\n> any of the 'traditional' things. It only cares about the number of bytes\n> we want to transfer and it has limitation of 4194303 bytes (21bits for\n> length). This is again per SG. How this could report the\n> 'max_bursts_per_sg' ?\n\nhmmm that is intresting case, is this number coming from USB side?\n\n> This was one of the reasons that I have settled with the callback.\n> \n> What we can also do is to code this within the DMA drivers itself.\n> \n> When setting up the transfer and we realize that one of the SG will not\n> going to fit, we destroy what we have done so far, pass the sg list\n> along with length/sg limit to create a new sg list where all sg item's\n> length is under the limit. Then using this new sg list we can set up the\n> transfer.\n> \n> I'm not sure how hard is to do the sg list optimization, I see that\n> sg_split() is not what we want so we might need to code this in\n> dmaengine or in the scatterlist code.\n> \n> We certainly don't want to verify all slave_sg transfers proactively to\n> avoid adding latency when it is not necessary.\n\nlatency would be added at prepare, not when submitting..","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"sj7Ui9sX\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y8sDj165Sz9t3t\n\tfor ;\n\tSun, 8 Oct 2017 16:21:41 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e141w-0005Mf-By; Sun, 08 Oct 2017 05:21:36 +0000","from mga06.intel.com ([134.134.136.31])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e141s-0005Ij-CC for linux-arm-kernel@lists.infradead.org;\n\tSun, 08 Oct 2017 05:21:34 +0000","from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby orsmga104.jf.intel.com with ESMTP; 07 Oct 2017 22:21:08 -0700","from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143])\n\tby fmsmga005.fm.intel.com with ESMTP; 07 Oct 2017 22:21:06 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=xXK0j2II1Bne/hCG7tOXvDAoUYfFtpt8X76NTEzTP/I=;\n\tb=sj7Ui9sX3sVnaA\n\tYzBj6Vaa33Zcg9AL7YL03u4jO0M/nRzkUAtSjo5pNB/qGC+dQr6Q3bNUk/2vJpGZHojxOJ4bw0sA7\n\tpwnchroST7TGjBPcrfInWHWkUSneROjFYwdG8P8BCVgPPVhlnP37CyuZ/KbOMWA3ouBP2H/ccvxir\n\tDje1CQrWFDgL9yn60mZMM4Kn6lttT35rIuJ082yRPtbInqcKaRpJRog7lnBW3yi58Lh8JN66Nxys1\n\tB9BtI88Fwwf6m+Ys0TcpXHH6dy2L0oYQPNnaUjORMslRwYceEoIUXmBPIKmS2xT75DScHAO2tvlgz\n\t4jGRJJMcdPTZXePBbCjQ==;","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,493,1500966000\"; d=\"scan'208\";a=\"160102787\"","Date":"Sun, 8 Oct 2017 10:55:15 +0530","From":"Vinod Koul ","To":"Peter Ujfalusi ","Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","Message-ID":"<20171008052514.GG30097@localhost>","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>\n\t<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>\n\t<20170926165413.GQ30097@localhost>\n\t<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171007_222132_464335_AF0858A7 ","X-CRM114-Status":"GOOD ( 23.54 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [134.134.136.31 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1784753,"web_url":"http://patchwork.ozlabs.org/comment/1784753/","msgid":"","list_archive_url":null,"date":"2017-10-11T15:47:18","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":9142,"url":"http://patchwork.ozlabs.org/api/people/9142/","name":"Peter Ujfalusi","email":"peter.ujfalusi@ti.com"},"content":"\nTexas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n\nOn 10/08/2017 08:25 AM, Vinod Koul wrote:\n>>>> It is not really static, the size in bytes depends on the dev_width and\n>>>> the maxburst:\n>>>> dev_width * burst * (SZ_64K - 1);\n>>>\n>>> well DMAengines work on FIFOs, in above you are giving length as SZ_64K - 1\n>>> 'items' which IIUC in DMAengine terms for bytes would always refer wrt width\n>>> used and burst applied.\n>>\n>> I think we can live with this and let the user to figure out what to do\n>> with this information.\n> \n> Right, plus a macro for conversion :) SO that users dont code buggy\n> conversions all over the place\n\nOK, but still the naming... ;)\n\n>> But I'm having hard time to figure out a good name for this. It is not\n>> the number of SGs we can support, but the number of 'items' within one\n>> SG that we have the limit. It could be:\n>> u32 max_bursts_per_sg;\n> \n> this looks fine, another candidate I would use is words_per_sg and while at\n> it why tie it to sg? should we make it words_per_txn but then people should not\n> confuse with txn represented by a descriptor which can have multiple ....\n\nYes, this limit is not only per SG as the same limit actually applies to\ncyclic's period_len in a same way.\n\nwords_per_txn does not sound right as for me the words would refer to\ndev_width number of bytes and I'm seeking on limit on the number of (dev_width\n* bursts) sub-chunks.\n\nbursts_per_chunk? With a long comment?\n\nWhich would apply to sg_dma_len in slave_sg(), period_len in cyclic() and len\nin slave_single().\n\n>>\n>> which would also apply to period length (for cyclic) in a similar way.\n>>\n>>> Return length in bytes does make sense (from user PoV), but then you need to\n>>> \"know\" the applied width and burst. How do you decide those?\n>>\n>> The number of items works eDMA and sDMA, but we also have the cpp41. It\n>> is a packet DMA and it has no understanding of bursts, address widths or\n>> any of the 'traditional' things. It only cares about the number of bytes\n>> we want to transfer and it has limitation of 4194303 bytes (21bits for\n>> length). This is again per SG. How this could report the\n>> 'max_bursts_per_sg' ?\n> \n> hmmm that is intresting case, is this number coming from USB side?\n\nNo, it is coming from cppi4.1's descriptor. The maximum length of a packet is\nstored in 21bits.\n\nBut this is a bit more complicated ;) The whole packet have 21bits size limit,\nbut at the same time the whole sg_dma_len() also have this as we can link a\nseveral host buffer descriptors to one host packet descriptor. Each have\n21bits for length, but at the same time the sum of the hpd and the linked hbd\nlength can not be more than what we can store in 21bits...\n\n> \n>> This was one of the reasons that I have settled with the callback.\n>>\n>> What we can also do is to code this within the DMA drivers itself.\n>>\n>> When setting up the transfer and we realize that one of the SG will not\n>> going to fit, we destroy what we have done so far, pass the sg list\n>> along with length/sg limit to create a new sg list where all sg item's\n>> length is under the limit. Then using this new sg list we can set up the\n>> transfer.\n>>\n>> I'm not sure how hard is to do the sg list optimization, I see that\n>> sg_split() is not what we want so we might need to code this in\n>> dmaengine or in the scatterlist code.\n>>\n>> We certainly don't want to verify all slave_sg transfers proactively to\n>> avoid adding latency when it is not necessary.\n> \n> latency would be added at prepare, not when submitting..\n\nYes, but you submit transfers all the time, and added latency would be crucial.\n\nBut this could be done with a DMAengine internal helper, I think.\nIf a DMA driver figures out that one of the SG length is over the supported\nlimit, then it could clean up everything and call something like:\n\nstruct dma_async_tx_descriptor *dmaengine_fixup_and_prep_slave_sg(\n\tstruct dma_chan *chan, struct scatterlist *sgl,\n\tunsigned int sg_len, enum dma_transfer_direction dir,\n\tunsigned long flags, size_t max_sg_dma_len)\n\nand this would split up the original SG list to a temp one meeting the\nmax_sg_dma_len and call chan->device->device_prep_slave_sg()\n\nIn this round the setup would succeed and the caller and I would be happy.\n\nBut if the caller already aware of the sg_dma_len limit it can prepare the SG\nlist correctly and we save time to recreate the list.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"OGxRJ5D3\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"riI/m1Lr\"; \n\tdkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yBz111FDWz9s7F\n\tfor ;\n\tThu, 12 Oct 2017 02:48:53 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e2JFV-0000uv-B3; Wed, 11 Oct 2017 15:48:45 +0000","from lelnx193.ext.ti.com ([198.47.27.77])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e2JFJ-0000ZA-11 for linux-arm-kernel@lists.infradead.org;\n\tWed, 11 Oct 2017 15:48:36 +0000","from dflxv15.itg.ti.com ([128.247.5.124])\n\tby lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id v9BFm9BQ016825; \n\tWed, 11 Oct 2017 10:48:09 -0500","from DLEE101.ent.ti.com (dlee101.ent.ti.com [157.170.170.31])\n\tby dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v9BFm9pp016432;\n\tWed, 11 Oct 2017 10:48:09 -0500","from DLEE105.ent.ti.com (157.170.170.35) by DLEE101.ent.ti.com\n\t(157.170.170.31) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tWed, 11 Oct 2017 10:48:09 -0500","from dflp32.itg.ti.com (10.64.6.15) by DLEE105.ent.ti.com\n\t(157.170.170.35) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Wed, 11 Oct 2017 10:48:09 -0500","from [172.22.5.0] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id v9BFm12h015370;\n\tWed, 11 Oct 2017 10:48:03 -0500"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=ON8J1oKM0BQbk6zyAJ9FYw8loL0hyebgCULGaync8oE=;\n\tb=OGxRJ5D3pyBrgS\n\tajYAjMICHitmkuPTTEBX0uzcLPTcJ19Uq2ROnDKquVQjqBQt0nh1zeB2AZhHfIVQ9OERVu0cWGSXO\n\tmCApSCXPLCM9VMqAtkk5yrBxtMkL5WRzqOxCZyrgaSCUTkgI1jWOF9N5InxMX3n0lYb5HROAthTTT\n\thy5qflwHylR9zNv5Fv3qqXznMHZyu5qmsJ6X+cTaN2huqu43QaZZ9n1OREHsLxyMIBUGCoo4TyKlG\n\tCckiZPyzxMBBl7vHb01jgRWEqv2GW/8HYmUjbnDPPQ3Sp08DQCK5wbCvhUSOyBJgz9TvMs3tUckAh\n\tOcHfI9PfEVMJ5giHwCoA==;","v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1507736889;\n\tbh=lsLWFGBbW8XMxmZ+X5cFvpw7gN3P061kTurPze6FqoE=;\n\th=Subject:To:CC:References:From:Date:In-Reply-To;\n\tb=riI/m1LrjDt14KmuWlwW2RkrwKShUCtFx73/qOFK/e1Vr1Di5LxCnSgJPzyd883a8\n\t7WQn5cFFH3b3ZqloZpdc0ISg3k/NmZnOk8ja1RhyV2LAaaSdw0cmsgpXDW+A86zCaF\n\tDKGf7W4VU98PIYH8NZ7hlILISh7ChZvk103yhXnU="],"Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","To":"Vinod Koul ","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>\n\t<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>\n\t<20170926165413.GQ30097@localhost>\n\t<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>\n\t<20171008052514.GG30097@localhost>","From":"Peter Ujfalusi ","Message-ID":"","Date":"Wed, 11 Oct 2017 18:47:18 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20171008052514.GG30097@localhost>","Content-Language":"en-GB","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171011_084833_425167_4283FACF ","X-CRM114-Status":"GOOD ( 20.33 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno trust [198.47.27.77 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1785484,"web_url":"http://patchwork.ozlabs.org/comment/1785484/","msgid":"<20171012135717.GN30097@localhost>","list_archive_url":null,"date":"2017-10-12T13:57:17","subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","submitter":{"id":8232,"url":"http://patchwork.ozlabs.org/api/people/8232/","name":"Vinod Koul","email":"vinod.koul@intel.com"},"content":"On Wed, Oct 11, 2017 at 06:47:18PM +0300, Peter Ujfalusi wrote:\n> \n> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki\n> \n> On 10/08/2017 08:25 AM, Vinod Koul wrote:\n> >>>> It is not really static, the size in bytes depends on the dev_width and\n> >>>> the maxburst:\n> >>>> dev_width * burst * (SZ_64K - 1);\n> >>>\n> >>> well DMAengines work on FIFOs, in above you are giving length as SZ_64K - 1\n> >>> 'items' which IIUC in DMAengine terms for bytes would always refer wrt width\n> >>> used and burst applied.\n> >>\n> >> I think we can live with this and let the user to figure out what to do\n> >> with this information.\n> > \n> > Right, plus a macro for conversion :) SO that users dont code buggy\n> > conversions all over the place\n> \n> OK, but still the naming... ;)\n> \n> >> But I'm having hard time to figure out a good name for this. It is not\n> >> the number of SGs we can support, but the number of 'items' within one\n> >> SG that we have the limit. It could be:\n> >> u32 max_bursts_per_sg;\n> > \n> > this looks fine, another candidate I would use is words_per_sg and while at\n> > it why tie it to sg? should we make it words_per_txn but then people should not\n> > confuse with txn represented by a descriptor which can have multiple ....\n> \n> Yes, this limit is not only per SG as the same limit actually applies to\n> cyclic's period_len in a same way.\n> \n> words_per_txn does not sound right as for me the words would refer to\n> dev_width number of bytes and I'm seeking on limit on the number of (dev_width\n> * bursts) sub-chunks.\n> \n> bursts_per_chunk? With a long comment?\n> \n> Which would apply to sg_dma_len in slave_sg(), period_len in cyclic() and len\n> in slave_single().\n\nSounds much better to me :)\n\n> \n> >>\n> >> which would also apply to period length (for cyclic) in a similar way.\n> >>\n> >>> Return length in bytes does make sense (from user PoV), but then you need to\n> >>> \"know\" the applied width and burst. How do you decide those?\n> >>\n> >> The number of items works eDMA and sDMA, but we also have the cpp41. It\n> >> is a packet DMA and it has no understanding of bursts, address widths or\n> >> any of the 'traditional' things. It only cares about the number of bytes\n> >> we want to transfer and it has limitation of 4194303 bytes (21bits for\n> >> length). This is again per SG. How this could report the\n> >> 'max_bursts_per_sg' ?\n> > \n> > hmmm that is intresting case, is this number coming from USB side?\n> \n> No, it is coming from cppi4.1's descriptor. The maximum length of a packet is\n> stored in 21bits.\n> \n> But this is a bit more complicated ;) The whole packet have 21bits size limit,\n> but at the same time the whole sg_dma_len() also have this as we can link a\n> several host buffer descriptors to one host packet descriptor. Each have\n> 21bits for length, but at the same time the sum of the hpd and the linked hbd\n> length can not be more than what we can store in 21bits...\n> \n> > \n> >> This was one of the reasons that I have settled with the callback.\n> >>\n> >> What we can also do is to code this within the DMA drivers itself.\n> >>\n> >> When setting up the transfer and we realize that one of the SG will not\n> >> going to fit, we destroy what we have done so far, pass the sg list\n> >> along with length/sg limit to create a new sg list where all sg item's\n> >> length is under the limit. Then using this new sg list we can set up the\n> >> transfer.\n> >>\n> >> I'm not sure how hard is to do the sg list optimization, I see that\n> >> sg_split() is not what we want so we might need to code this in\n> >> dmaengine or in the scatterlist code.\n> >>\n> >> We certainly don't want to verify all slave_sg transfers proactively to\n> >> avoid adding latency when it is not necessary.\n> > \n> > latency would be added at prepare, not when submitting..\n> \n> Yes, but you submit transfers all the time, and added latency would be crucial.\n> \n> But this could be done with a DMAengine internal helper, I think.\n> If a DMA driver figures out that one of the SG length is over the supported\n> limit, then it could clean up everything and call something like:\n> \n> struct dma_async_tx_descriptor *dmaengine_fixup_and_prep_slave_sg(\n> \tstruct dma_chan *chan, struct scatterlist *sgl,\n> \tunsigned int sg_len, enum dma_transfer_direction dir,\n> \tunsigned long flags, size_t max_sg_dma_len)\n> \n> and this would split up the original SG list to a temp one meeting the\n> max_sg_dma_len and call chan->device->device_prep_slave_sg()\n> \n> In this round the setup would succeed and the caller and I would be happy.\n> \n> But if the caller already aware of the sg_dma_len limit it can prepare the SG\n> list correctly and we save time to recreate the list.\n\nrather than driver figure out, why don't we add the in prep_ call. Since we\nwould know the capability of the device we can do that split, that way we\nhave common split code in middle in the framework and drivers get sg list\nwhich is supported by them. It can also split a list to multipe prep_ calls\nbased on controller support.\n\nYes that is a big ask, we can split up and do in stages :)","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"LJ9016X1\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yCXPX1k6lz9s7p\n\tfor ;\n\tFri, 13 Oct 2017 00:53:36 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e2dvY-0006Fi-K7; Thu, 12 Oct 2017 13:53:32 +0000","from mga02.intel.com ([134.134.136.20])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e2dvT-0006DD-VJ for linux-arm-kernel@lists.infradead.org;\n\tThu, 12 Oct 2017 13:53:29 +0000","from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t12 Oct 2017 06:53:06 -0700","from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143])\n\tby orsmga002.jf.intel.com with ESMTP; 12 Oct 2017 06:53:04 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=LyXBAguKRsj5zi5QBsNXeN+vliT5UgsX5BdSOfQIGhM=;\n\tb=LJ9016X1j6kfLU\n\tDn9hRwywnWv/5Y2Af1aANHpyF/xHEDatYhJz59HKXj8ZbH2IrDtqPWuBJSCe5QQVCCuBSSGhwEPIj\n\thISg7jjNoLkGjc+LleF5texol1xQh3sZTQ9yiaCpBZdlhtf+tLrekGCpGQ1kAbwQP3MfNhah8qYYo\n\tTyZQBu5iEGykLRZRW+Idzk6pwQgsE8I6x3MBvvCXTzsJJSzZWpT/reJqJlOkz0ZCYVqv8dqJAFGWx\n\to3fP28rsGnXX4P5vHNGyucXeHUgjxCWwNcfioBD7WaAYExwev6O59uhYbovyh0Cfax/FQWp9B2oXb\n\tB6JM7TgCbo1oz4nyDu0w==;","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.43,366,1503385200\"; d=\"scan'208\";a=\"145718573\"","Date":"Thu, 12 Oct 2017 19:27:17 +0530","From":"Vinod Koul ","To":"Peter Ujfalusi ","Subject":"Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer\n\tlength (of an SG element)","Message-ID":"<20171012135717.GN30097@localhost>","References":"<20170912104424.18495-1-peter.ujfalusi@ti.com>\n\t<20170912104424.18495-4-peter.ujfalusi@ti.com>\n\t<20170921171451.GG30097@localhost>\n\t<02509904-4ae8-c6f8-3514-5f77d665c9a6@ti.com>\n\t<20170926165413.GQ30097@localhost>\n\t<11471508-b61c-7842-2080-7f5c2f292c2b@ti.com>\n\t<20171008052514.GG30097@localhost>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171012_065328_200282_2D8F2342 ","X-CRM114-Status":"GOOD ( 35.42 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [134.134.136.20 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, t-kristo@ti.com, dmaengine@vger.kernel.org,\n\tdan.j.williams@intel.com, linux-omap@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]