From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [v3,3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer From: Lucas Stach Message-Id: <1532424136.32306.3.camel@pengutronix.de> Date: Tue, 24 Jul 2018 11:22:16 +0200 To: Robin Gong , "vkoul@kernel.org" , "dan.j.williams@intel.com" , "s.hauer@pengutronix.de" , "linux@armlinux.org.uk" Cc: "dmaengine@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" List-ID: QW0gTW9udGFnLCBkZW4gMjMuMDcuMjAxOCwgMTM6NTUgKzAwMDAgc2NocmllYiBSb2JpbiBHb25n Ogo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+IEZyb206IEx1Y2FzIFN0YWNoIFtt YWlsdG86bC5zdGFjaEBwZW5ndXRyb25peC5kZV0KPiA+IFNlbnQ6IDIwMTjlubQ35pyIMjPml6Ug MTg6NTQKPiA+IFRvOiBSb2JpbiBHb25nIDx5aWJpbi5nb25nQG54cC5jb20+OyB2a291bEBrZXJu ZWwub3JnOwo+ID4gZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tOyBzLmhhdWVyQHBlbmd1dHJvbml4 LmRlOyBsaW51eEBhcm1saW51eC5vcgo+ID4gZy51awo+ID4gQ2M6IGRtYWVuZ2luZUB2Z2VyLmtl cm5lbC5vcmc7IGRsLWxpbnV4LWlteCA8bGludXgtaW14QG54cC5jb20+Owo+ID4ga2VybmVsQHBl bmd1dHJvbml4LmRlOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7Cj4gPiBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnCj4gPiBTdWJqZWN0OiBSZTogW1BBVENIIHYzIDMv M10gZG1hZW5naW5lOiBpbXgtc2RtYTogYWxsb2NhdGUgbWF4IDIwCj4gPiBiZHMgZm9yIG9uZQo+ ID4gdHJhbnNmZXIKPiA+IAo+ID4gQW0gRGllbnN0YWcsIGRlbiAyNC4wNy4yMDE4LCAwMTo0NiAr MDgwMCBzY2hyaWViIFJvYmluIEdvbmc6Cj4gPiA+IElmIG11bHRpLWJkcyB1c2VkIGluIG9uZSB0 cmFuc2ZlciwgYWxsIGJkcyBzaG91bGQgYmUgY29uc2lzdGVuCj4gPiA+IG1lbW9yeS5UbyBlYXNp bHkgZm9sbG93IGl0LCBlbmxhcmdlIHRoZSBkbWEgcG9vbCBzaXplIGludG8gMjAKPiA+ID4gYmRz LCBhbmQKPiA+ID4gaXQgd2lsbCByZXBvcnQgZXJyb3IgaWYgdGhlIG51bWJlciBvZiBiZHMgaXMg b3ZlciB0aGFuIDIwLiBGb3IKPiA+ID4gZG1hdGVzdCwgdGhlIG1heCBjb3VudCBmb3Igc2luZ2xl IHRyYW5zZmVyIGlzIE5VTV9CRCAqCj4gPiAKPiA+IFNETUFfQkRfTUFYX0NOVAo+ID4gPiA9IDIw ICogNjU1MzUgPSB+MS4yOE1CLgo+ID4gCj4gPiBCb3RoIHRoZSBjb21taXQgbWVzc2FnZSBhbmQg dGhlIGNvbW1lbnQgbmVlZCBhIGxvdCBtb3JlIGNhcmUgdG8KPiA+IGFjdHVhbGx5Cj4gPiB0ZWxs IHdoYXQgdGhpcyBjb21taXQgaXMgdHJ5aW5nIHRvIGFjaGlldmUuIEN1cnJlbnRseSBJIGRvbid0 Cj4gPiBmb2xsb3cgYXQgYWxsLiBXaGF0Cj4gPiBkb2VzICJjb25zaXN0ZW4iIG1lYW4/IERvIHlv dSBtZWFuIEJEcyBzaG91bGQgYmUgY29udGlndW91cyBpbgo+ID4gbWVtb3J5Pwo+IAo+IFllcywg QkRzIHNob3VsZCBiZSBjb250aWd1b3VzwqDCoG9uZSBieSBvbmUgaW4gbWVtb3J5LgoKT2theSwg YnV0IHRoaXMgaXNuJ3Qgd2hhdCB0aGUgY29kZSBjaGFuZ2UgZG9lcy4gQnkgaW5jcmVhc2luZyB0 aGUgc2l6ZQpwYXJhbWV0ZXIgb2YgdGhlIGRtYSBwb29sIHlvdSBqdXN0IGFsbG9jYXRlIDIwIHRp bWVzIGFzIG11Y2ggbWVtb3J5IGFzCm5lZWRlZCBmb3IgZWFjaCBCRC4gU28gYWN0dWFsbHkgdGhl IEJEcyBlbmQgdXAgYmVpbmcgdmVyeSBub24tCmNvbnRpZ3VvdXMgaW4gbWVtb3J5IGFzIHRoZXJl IGFyZSBub3cgaG9sZXMgb2YgMTkgQkQgc2l6ZXMgYmV0d2VlbiB0aGUKc3RhcnQgb2YgZWFjaCBC RC4KClNvIHNvbWV0aGluZyBpc24ndCByaWdodCB3aXRoIHRoaXMgY2hhbmdlLgoKUmVnYXJkcywK THVjYXMKCj4gPiAKPiA+IFdoYXQgZG8geW91IGdhaW4gYnkgb3Zlci1hbGxvY2F0aW5nIGVhY2gg QkQgYnkgYSBmYWN0b3Igb2YgMjA/Cj4gCj4gSSBndWVzcyBkbWFfcG9vbF9hbGxvYyB3aWxsIHJl dHVybiBlcnJvciBpbiBzdWNoIGNhc2UsIGFuZCB0aGVuIGNhdXNlCj4gZG1hIHNldHVwCj4gdHJh bnNmZXIgZmFpbHVyZS4KPiA+IAo+ID4gUmVnYXJkcywKPiA+IEx1Y2FzCj4gPiAKPiA+ID4gU2ln bmVkLW9mZi1ieTogUm9iaW4gR29uZyA8eWliaW4uZ29uZ0BueHAuY29tPgo+ID4gPiAtLS0KPiA+ ID4gwqBkcml2ZXJzL2RtYS9pbXgtc2RtYS5jIHwgMTcgKysrKysrKysrKysrKysrKy0KPiA+ID4g wqAxIGZpbGUgY2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQo+ID4gPiAK PiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZG1hL2lteC1zZG1hLmMgYi9kcml2ZXJzL2RtYS9p bXgtc2RtYS5jCj4gPiA+IGluZGV4Cj4gPiA+IGI0ZWMyZDIuLjU5NzM0ODkgMTAwNjQ0Cj4gPiA+ IC0tLSBhL2RyaXZlcnMvZG1hL2lteC1zZG1hLmMKPiA+ID4gKysrIGIvZHJpdmVycy9kbWEvaW14 LXNkbWEuYwo+ID4gPiBAQCAtMjk4LDYgKzI5OCwxNSBAQCBzdHJ1Y3Qgc2RtYV9jb250ZXh0X2Rh dGEgewo+ID4gPiA+IMKgCXUzMsKgwqBzY3JhdGNoNzsKPiA+ID4gCj4gPiA+IMKgfSBfX2F0dHJp YnV0ZV9fICgocGFja2VkKSk7Cj4gPiA+IAo+ID4gPiArLyoKPiA+ID4gKyAqIEFsbCBiZHMgaW4g b25lIHRyYW5zZmVyIHNob3VsZCBiZSBjb25zaXRlbnQgb24gU0RNQS4gVG8KPiA+ID4gZWFzaWx5 Cj4gPiA+ICtmb2xsb3cgaXQsanVzdAo+ID4gPiArICogc2V0IHRoZSBkbWEgcG9vbCBzaXplIGFz IHRoZSBlbm91Z2ggYmRzLiBGb3IgZXhhbXBsZSwgaW4KPiA+ID4gZG1hdGVzdAo+ID4gPiArY2Fz ZSwgdGhlCj4gPiA+ICsgKiBtYXggMjAgYmRzIG1lYW5zIHRoZSBtYXggZm9yIHNpbmdsZSB0cmFu c2ZlciBpcyBOVU1fQkQgKgo+ID4gPiArU0RNQV9CRF9NQVhfQ05UID0gMjAKPiA+ID4gKyAqICog NjU1MzUgPSB+MS4yOE1CLiAyMCBiZHMgc3VwcG9zZWQgdG8gYmUgZW5vdWdoIGJhc2ljYWxseS5J Zgo+ID4gPiBpdCdzCj4gPiA+ICtzdGlsbCBub3QKPiA+ID4gKyAqIGVub3VnaCBpbiBzb21lIHNw ZWNpZmljIGNhc2VzLCBlbmxhcmdlIGl0IGhlcmUuV2FybmluZwo+ID4gPiBtZXNzYWdlCj4gPiA+ ICt3b3VsZCBhbHNvCj4gPiA+ICsgKiBhcHBlYXIgaWYgdGhlIGJkIG51bWJlcnMgaXMgb3ZlciB0 aGFuIDIwLgo+ID4gPiArICovCj4gPiA+ICsjZGVmaW5lIE5VTV9CRCAyMAo+ID4gPiAKPiA+ID4g wqBzdHJ1Y3Qgc2RtYV9lbmdpbmU7Cj4gPiA+IAo+ID4gPiBAQCAtMTI3Myw3ICsxMjgyLDcgQEAg c3RhdGljIGludCBzZG1hX2FsbG9jX2NoYW5fcmVzb3VyY2VzKHN0cnVjdAo+ID4gPiBkbWFfY2hh biAqY2hhbikKPiA+ID4gPiDCoAkJZ290byBkaXNhYmxlX2Nsa19haGI7Cj4gPiA+ID4gwqAJc2Rt YWMtPmJkX3Bvb2wgPSBkbWFfcG9vbF9jcmVhdGUoImJkX3Bvb2wiLCBjaGFuLQo+ID4gPiA+ID5k ZXZpY2UtPmRldiwKPiA+ID4gPiAtCQkJCXNpemVvZihzdHJ1Y3QKPiA+ID4gPiBzZG1hX2J1ZmZl cl9kZXNjcmlwdG9yKSwKPiA+ID4gPiArCQkJCU5VTV9CRCAqIHNpemVvZihzdHJ1Y3QKPiA+ID4g PiBzZG1hX2J1ZmZlcl9kZXNjcmlwdG9yKSwKPiA+ID4gPiDCoAkJCQkzMiwgMCk7Cj4gPiA+ID4g wqAJcmV0dXJuIDA7Cj4gPiA+IAo+ID4gPiBAQCAtMTMxNCw2ICsxMzIzLDEyIEBAIHN0YXRpYyBz dHJ1Y3Qgc2RtYV9kZXNjCj4gPiA+ICpzZG1hX3RyYW5zZmVyX2luaXQoc3RydWN0IHNkbWFfY2hh bm5lbCAqc2RtYWMsCj4gPiA+IMKgewo+ID4gPiA+IMKgCXN0cnVjdCBzZG1hX2Rlc2MgKmRlc2M7 Cj4gPiA+ID4gKwlpZiAoYmRzID4gTlVNX0JEKSB7Cj4gPiA+ID4gKwkJZGV2X2VycihzZG1hYy0+ c2RtYS0+ZGV2LCAiJWQgYmRzIGV4Y2VlZCB0aGUKPiA+ID4gPiBtYXggJWRcbiIsCj4gPiA+ID4g KwkJCWJkcywgTlVNX0JEKTsKPiA+ID4gPiArCQlnb3RvIGVycl9vdXQ7Cj4gPiA+ID4gKwl9Cj4g PiA+IAo+ID4gPiArCj4gPiA+ID4gwqAJZGVzYyA9IGt6YWxsb2MoKHNpemVvZigqZGVzYykpLCBH RlBfTk9XQUlUKTsKPiA+ID4gPiDCoAlpZiAoIWRlc2MpCj4gPiA+ID4gwqAJCWdvdG8gZXJyX291 dDsKLS0tClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1 YnNjcmliZSBkbWFlbmdpbmUiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9A dmdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5l bC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: l.stach@pengutronix.de (Lucas Stach) Date: Tue, 24 Jul 2018 11:22:16 +0200 Subject: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer In-Reply-To: References: <1532367972-29707-1-git-send-email-yibin.gong@nxp.com> <1532367972-29707-4-git-send-email-yibin.gong@nxp.com> <1532343252.3163.99.camel@pengutronix.de> Message-ID: <1532424136.32306.3.camel@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Am Montag, den 23.07.2018, 13:55 +0000 schrieb Robin Gong: > > -----Original Message----- > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > Sent: 2018?7?23? 18:54 > > To: Robin Gong ; vkoul at kernel.org; > > dan.j.williams at intel.com; s.hauer at pengutronix.de; linux at armlinux.or > > g.uk > > Cc: dmaengine at vger.kernel.org; dl-linux-imx ; > > kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org; > > linux-kernel at vger.kernel.org > > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 > > bds for one > > transfer > > > > Am Dienstag, den 24.07.2018, 01:46 +0800 schrieb Robin Gong: > > > If multi-bds used in one transfer, all bds should be consisten > > > memory.To easily follow it, enlarge the dma pool size into 20 > > > bds, and > > > it will report error if the number of bds is over than 20. For > > > dmatest, the max count for single transfer is NUM_BD * > > > > SDMA_BD_MAX_CNT > > > = 20 * 65535 = ~1.28MB. > > > > Both the commit message and the comment need a lot more care to > > actually > > tell what this commit is trying to achieve. Currently I don't > > follow at all. What > > does "consisten" mean? Do you mean BDs should be contiguous in > > memory? > > Yes, BDs should be contiguous??one by one in memory. Okay, but this isn't what the code change does. By increasing the size parameter of the dma pool you just allocate 20 times as much memory as needed for each BD. So actually the BDs end up being very non- contiguous in memory as there are now holes of 19 BD sizes between the start of each BD. So something isn't right with this change. Regards, Lucas > > > > What do you gain by over-allocating each BD by a factor of 20? > > I guess dma_pool_alloc will return error in such case, and then cause > dma setup > transfer failure. > > > > Regards, > > Lucas > > > > > Signed-off-by: Robin Gong > > > --- > > > ?drivers/dma/imx-sdma.c | 17 ++++++++++++++++- > > > ?1 file changed, 16 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c > > > index > > > b4ec2d2..5973489 100644 > > > --- a/drivers/dma/imx-sdma.c > > > +++ b/drivers/dma/imx-sdma.c > > > @@ -298,6 +298,15 @@ struct sdma_context_data { > > > > ? u32??scratch7; > > > > > > ?} __attribute__ ((packed)); > > > > > > +/* > > > + * All bds in one transfer should be consitent on SDMA. To > > > easily > > > +follow it,just > > > + * set the dma pool size as the enough bds. For example, in > > > dmatest > > > +case, the > > > + * max 20 bds means the max for single transfer is NUM_BD * > > > +SDMA_BD_MAX_CNT = 20 > > > + * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If > > > it's > > > +still not > > > + * enough in some specific cases, enlarge it here.Warning > > > message > > > +would also > > > + * appear if the bd numbers is over than 20. > > > + */ > > > +#define NUM_BD 20 > > > > > > ?struct sdma_engine; > > > > > > @@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct > > > dma_chan *chan) > > > > ? goto disable_clk_ahb; > > > > ? sdmac->bd_pool = dma_pool_create("bd_pool", chan- > > > > >device->dev, > > > > - sizeof(struct > > > > sdma_buffer_descriptor), > > > > + NUM_BD * sizeof(struct > > > > sdma_buffer_descriptor), > > > > ? 32, 0); > > > > ? return 0; > > > > > > @@ -1314,6 +1323,12 @@ static struct sdma_desc > > > *sdma_transfer_init(struct sdma_channel *sdmac, > > > ?{ > > > > ? struct sdma_desc *desc; > > > > + if (bds > NUM_BD) { > > > > + dev_err(sdmac->sdma->dev, "%d bds exceed the > > > > max %d\n", > > > > + bds, NUM_BD); > > > > + goto err_out; > > > > + } > > > > > > + > > > > ? desc = kzalloc((sizeof(*desc)), GFP_NOWAIT); > > > > ? if (!desc) > > > > ? goto err_out; 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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 20BF7C6778A for ; Tue, 24 Jul 2018 09:22:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D4D9620852 for ; Tue, 24 Jul 2018 09:22:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4D9620852 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388412AbeGXK2L (ORCPT ); Tue, 24 Jul 2018 06:28:11 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:53973 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388251AbeGXK2L (ORCPT ); Tue, 24 Jul 2018 06:28:11 -0400 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1fhtWN-00016p-4p; Tue, 24 Jul 2018 11:22:19 +0200 Message-ID: <1532424136.32306.3.camel@pengutronix.de> Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer From: Lucas Stach To: Robin Gong , "vkoul@kernel.org" , "dan.j.williams@intel.com" , "s.hauer@pengutronix.de" , "linux@armlinux.org.uk" Cc: "dmaengine@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Date: Tue, 24 Jul 2018 11:22:16 +0200 In-Reply-To: References: <1532367972-29707-1-git-send-email-yibin.gong@nxp.com> <1532367972-29707-4-git-send-email-yibin.gong@nxp.com> <1532343252.3163.99.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, den 23.07.2018, 13:55 +0000 schrieb Robin Gong: > > -----Original Message----- > > From: Lucas Stach [mailto:l.stach@pengutronix.de] > > Sent: 2018年7月23日 18:54 > > To: Robin Gong ; vkoul@kernel.org; > > dan.j.williams@intel.com; s.hauer@pengutronix.de; linux@armlinux.or > > g.uk > > Cc: dmaengine@vger.kernel.org; dl-linux-imx ; > > kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org; > > linux-kernel@vger.kernel.org > > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 > > bds for one > > transfer > > > > Am Dienstag, den 24.07.2018, 01:46 +0800 schrieb Robin Gong: > > > If multi-bds used in one transfer, all bds should be consisten > > > memory.To easily follow it, enlarge the dma pool size into 20 > > > bds, and > > > it will report error if the number of bds is over than 20. For > > > dmatest, the max count for single transfer is NUM_BD * > > > > SDMA_BD_MAX_CNT > > > = 20 * 65535 = ~1.28MB. > > > > Both the commit message and the comment need a lot more care to > > actually > > tell what this commit is trying to achieve. Currently I don't > > follow at all. What > > does "consisten" mean? Do you mean BDs should be contiguous in > > memory? > > Yes, BDs should be contiguous  one by one in memory. Okay, but this isn't what the code change does. By increasing the size parameter of the dma pool you just allocate 20 times as much memory as needed for each BD. So actually the BDs end up being very non- contiguous in memory as there are now holes of 19 BD sizes between the start of each BD. So something isn't right with this change. Regards, Lucas > > > > What do you gain by over-allocating each BD by a factor of 20? > > I guess dma_pool_alloc will return error in such case, and then cause > dma setup > transfer failure. > > > > Regards, > > Lucas > > > > > Signed-off-by: Robin Gong > > > --- > > >  drivers/dma/imx-sdma.c | 17 ++++++++++++++++- > > >  1 file changed, 16 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c > > > index > > > b4ec2d2..5973489 100644 > > > --- a/drivers/dma/imx-sdma.c > > > +++ b/drivers/dma/imx-sdma.c > > > @@ -298,6 +298,15 @@ struct sdma_context_data { > > > >   u32  scratch7; > > > > > >  } __attribute__ ((packed)); > > > > > > +/* > > > + * All bds in one transfer should be consitent on SDMA. To > > > easily > > > +follow it,just > > > + * set the dma pool size as the enough bds. For example, in > > > dmatest > > > +case, the > > > + * max 20 bds means the max for single transfer is NUM_BD * > > > +SDMA_BD_MAX_CNT = 20 > > > + * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If > > > it's > > > +still not > > > + * enough in some specific cases, enlarge it here.Warning > > > message > > > +would also > > > + * appear if the bd numbers is over than 20. > > > + */ > > > +#define NUM_BD 20 > > > > > >  struct sdma_engine; > > > > > > @@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct > > > dma_chan *chan) > > > >   goto disable_clk_ahb; > > > >   sdmac->bd_pool = dma_pool_create("bd_pool", chan- > > > > >device->dev, > > > > - sizeof(struct > > > > sdma_buffer_descriptor), > > > > + NUM_BD * sizeof(struct > > > > sdma_buffer_descriptor), > > > >   32, 0); > > > >   return 0; > > > > > > @@ -1314,6 +1323,12 @@ static struct sdma_desc > > > *sdma_transfer_init(struct sdma_channel *sdmac, > > >  { > > > >   struct sdma_desc *desc; > > > > + if (bds > NUM_BD) { > > > > + dev_err(sdmac->sdma->dev, "%d bds exceed the > > > > max %d\n", > > > > + bds, NUM_BD); > > > > + goto err_out; > > > > + } > > > > > > + > > > >   desc = kzalloc((sizeof(*desc)), GFP_NOWAIT); > > > >   if (!desc) > > > >   goto err_out;