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: <1533558590.2809.1.camel@pengutronix.de> Date: Mon, 06 Aug 2018 14:29:50 +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" , "linux-kernel@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "linux-arm-kernel@lists.infradead.org" List-ID: SGkgUm9iaW4sCgpBbSBNb250YWcsIGRlbiAwNi4wOC4yMDE4LCAwODowNCArMDAwMCBzY2hyaWVi IFJvYmluIEdvbmc6Cj4gSGVsbG8gTHVjYXMsCj4gCUFueSBjb21tZW50IGZvciBteSByZXBseT8K ClNvIEkndmUgbG9va2VkIGF0IHRoaXMgYWdhaW4gYW5kIHNhZGx5IEkgbmVlZCB0byBOQUNLIHRo aXMgcGF0Y2guIEl0IGlzCmEgdG90YWwgQVBJIGFidXNlIG9mIHRoZSBkbWFfcG9vbCBBUEkgYW5k IGV2ZW4gdGhlIHBhdGNoIGludHJvZHVjaW5nCnRoZSBkbWFfcG9vbCB1c2FnZSBpbiB0aGlzIGRy aXZlciBpcyB3cm9uZyBhbmQgc2hvdWxkIGJlIHJldmVydGVkLgoKVGhlIFNETUEgbmVlZCBjb250 aWd1b3VzIGJ1ZmZlciBkZXNjcmlwdG9ycyBmb3IgZWFjaCBjaGFubmVsLCBzb21ldGhpbmcKdGhl IGRtYV9wb29sIGFic3RyYWN0aW9uIGlzbid0IGFibGUgdG8gcHJvdmlkZS4gU28gZWl0aGVyIHRo ZSBkbWFfcG9vbAppbXBsZW1lbnRhdGlvbiBuZWVkcyB0byBiZSBleHRlbmRlZCB0byBzdXBwb3J0 IHRoaXMgdXNlLWNhc2UsIG9yIHlvdQpjYW4ndCB1c2UgdGhpcyBhdCBhbGwgaW4gdGhlIHNkbWEg ZHJpdmVyLiBBZGRpbmcgaGFja3MsIHdoaWNoIGFyZQphYnVzaW5nIHRoZSBBUEksIHRvIGNyYW0g YSBkbWFfcG9vbCBpbnRvIHRoZSBzZG1hIGRyaXZlciBpcyBub3QgYSB2YWxpZAp3YXkgdG8gaW1w bGVtZW50IHRoaW5ncyBmb3IgdXBzdHJlYW0uCgpSZWdhcmRzLApMdWNhcwoKPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tCj4gPiBGcm9tOiBSb2JpbiBHb25nCj4gPiBTZW50OiAyMDE45bm0 N+aciDI15pelIDk6MjUKPiA+IFRvOiAnTHVjYXMgU3RhY2gnIDxsLnN0YWNoQHBlbmd1dHJvbml4 LmRlPjsgdmtvdWxAa2VybmVsLm9yZzsKPiA+IGRhbi5qLndpbGxpYW1zQGludGVsLmNvbTsgcy5o YXVlckBwZW5ndXRyb25peC5kZTsgbGludXhAYXJtbGludXgub3IKPiA+IGcudWsKPiA+IENjOiBk bWFlbmdpbmVAdmdlci5rZXJuZWwub3JnOyBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY29t PjsKPiA+IGtlcm5lbEBwZW5ndXRyb25peC5kZTsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZy YWRlYWQub3JnOwo+ID4gbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwo+ID4gU3ViamVjdDog UkU6IFtQQVRDSCB2MyAzLzNdIGRtYWVuZ2luZTogaW14LXNkbWE6IGFsbG9jYXRlIG1heCAyMAo+ ID4gYmRzIGZvciBvbmUKPiA+IHRyYW5zZmVyCj4gPiAKPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0KPiA+ID4gRnJvbTogTHVjYXMgU3RhY2ggW21haWx0bzpsLnN0YWNoQHBlbmd1dHJv bml4LmRlXQo+ID4gPiBTZW50OiAyMDE45bm0N+aciDI05pelIDE3OjIyCj4gPiA+IFRvOiBSb2Jp biBHb25nIDx5aWJpbi5nb25nQG54cC5jb20+OyB2a291bEBrZXJuZWwub3JnOwo+ID4gPiBkYW4u ai53aWxsaWFtc0BpbnRlbC5jb207IHMuaGF1ZXJAcGVuZ3V0cm9uaXguZGU7Cj4gPiA+IGxpbnV4 QGFybWxpbnV4Lm9yZy51awo+ID4gPiBDYzogZG1hZW5naW5lQHZnZXIua2VybmVsLm9yZzsgZGwt bGludXgtaW14IDxsaW51eC1pbXhAbnhwLmNvbT47Cj4gPiA+IGtlcm5lbEBwZW5ndXRyb25peC5k ZTsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOwo+ID4gPiBsaW51eC1rZXJu ZWxAdmdlci5rZXJuZWwub3JnCj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMy8zXSBkbWFl bmdpbmU6IGlteC1zZG1hOiBhbGxvY2F0ZSBtYXggMjAKPiA+ID4gYmRzCj4gPiA+IGZvciBvbmUg dHJhbnNmZXIKPiA+ID4gCj4gPiA+IEFtIE1vbnRhZywgZGVuIDIzLjA3LjIwMTgsIDEzOjU1ICsw MDAwIHNjaHJpZWIgUm9iaW4gR29uZzoKPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCj4gPiA+ID4gPiBGcm9tOiBMdWNhcyBTdGFjaCBbbWFpbHRvOmwuc3RhY2hAcGVuZ3V0cm9u aXguZGVdCj4gPiA+ID4gPiBTZW50OiAyMDE45bm0N+aciDIz5pelIDE4OjU0Cj4gPiA+ID4gPiBU bzogUm9iaW4gR29uZyA8eWliaW4uZ29uZ0BueHAuY29tPjsgdmtvdWxAa2VybmVsLm9yZzsKPiA+ ID4gPiA+IGRhbi5qLndpbGxpYW1zQGludGVsLmNvbTsgcy5oYXVlckBwZW5ndXRyb25peC5kZTsK PiA+ID4gPiA+IGxpbnV4QGFybWxpbnV4Lm9yIGcudWsKPiA+ID4gPiA+IENjOiBkbWFlbmdpbmVA dmdlci5rZXJuZWwub3JnOyBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY28KPiA+ID4gPiA+ IG0+Owo+ID4gPiA+ID4ga2VybmVsQHBlbmd1dHJvbml4LmRlOyBsaW51eC1hcm0ta2VybmVsQGxp c3RzLmluZnJhZGVhZC5vcmc7Cj4gPiA+ID4gPiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3Jn Cj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIHYzIDMvM10gZG1hZW5naW5lOiBpbXgtc2Rt YTogYWxsb2NhdGUgbWF4Cj4gPiA+ID4gPiAyMAo+ID4gPiA+ID4gYmRzIGZvciBvbmUgdHJhbnNm ZXIKPiA+ID4gPiA+IAo+ID4gPiA+ID4gQW0gRGllbnN0YWcsIGRlbiAyNC4wNy4yMDE4LCAwMTo0 NiArMDgwMCBzY2hyaWViIFJvYmluIEdvbmc6Cj4gPiA+ID4gPiA+IElmIG11bHRpLWJkcyB1c2Vk IGluIG9uZSB0cmFuc2ZlciwgYWxsIGJkcyBzaG91bGQgYmUKPiA+ID4gPiA+ID4gY29uc2lzdGVu Cj4gPiA+ID4gPiA+IG1lbW9yeS5UbyBlYXNpbHkgZm9sbG93IGl0LCBlbmxhcmdlIHRoZSBkbWEg cG9vbCBzaXplIGludG8KPiA+ID4gPiA+ID4gMjAKPiA+ID4gPiA+ID4gYmRzLCBhbmQgaXQgd2ls bCByZXBvcnQgZXJyb3IgaWYgdGhlIG51bWJlciBvZiBiZHMgaXMgb3Zlcgo+ID4gPiA+ID4gPiB0 aGFuCj4gPiA+ID4gPiA+IDIwLiBGb3IgZG1hdGVzdCwgdGhlIG1heCBjb3VudCBmb3Igc2luZ2xl IHRyYW5zZmVyIGlzCj4gPiA+ID4gPiA+IE5VTV9CRCAqCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFNE TUFfQkRfTUFYX0NOVAo+ID4gPiA+ID4gPiA9IDIwICogNjU1MzUgPSB+MS4yOE1CLgo+ID4gPiA+ ID4gCj4gPiA+ID4gPiBCb3RoIHRoZSBjb21taXQgbWVzc2FnZSBhbmQgdGhlIGNvbW1lbnQgbmVl ZCBhIGxvdCBtb3JlIGNhcmUKPiA+ID4gPiA+IHRvCj4gPiA+ID4gPiBhY3R1YWxseSB0ZWxsIHdo YXQgdGhpcyBjb21taXQgaXMgdHJ5aW5nIHRvIGFjaGlldmUuCj4gPiA+ID4gPiBDdXJyZW50bHkg SQo+ID4gPiA+ID4gZG9uJ3QgZm9sbG93IGF0IGFsbC4gV2hhdCBkb2VzICJjb25zaXN0ZW4iIG1l YW4/IERvIHlvdSBtZWFuCj4gPiA+ID4gPiBCRHMKPiA+ID4gPiA+IHNob3VsZCBiZSBjb250aWd1 b3VzIGluIG1lbW9yeT8KPiA+ID4gPiAKPiA+ID4gPiBZZXMsIEJEcyBzaG91bGQgYmUgY29udGln dW91c8KgwqBvbmUgYnkgb25lIGluIG1lbW9yeS4KPiA+ID4gCj4gPiA+IE9rYXksIGJ1dCB0aGlz IGlzbid0IHdoYXQgdGhlIGNvZGUgY2hhbmdlIGRvZXMuIEJ5IGluY3JlYXNpbmcgdGhlCj4gPiA+ IHNpemUKPiA+ID4gcGFyYW1ldGVyIG9mIHRoZSBkbWEgcG9vbCB5b3UganVzdCBhbGxvY2F0ZSAy MCB0aW1lcyBhcyBtdWNoCj4gPiA+IG1lbW9yeSBhcwo+ID4gPiBuZWVkZWQgZm9yIGVhY2ggQkQu IFNvIGFjdHVhbGx5IHRoZSBCRHMgZW5kIHVwIGJlaW5nIHZlcnkgbm9uLQo+ID4gPiBjb250aWd1 b3VzIGluIG1lbW9yeSBhcyB0aGVyZSBhcmUgbm93IGhvbGVzIG9mIDE5IEJEIHNpemVzCj4gPiA+ IGJldHdlZW4gdGhlCj4gPiAKPiA+IHN0YXJ0IG9mIGVhY2ggQkQuCj4gPiBQbGVhc2Ugbm90aWNl IG9ubHkgYWxsb2NhdGUgYmRzIG1lbW9yeSBmcm9tIGRtYSBwb29sIG9uZSB0aW1lIGV2ZW4KPiA+ IGluIG11bHRpCj4gPiBiZHMuCj4gPiBUaGF0J3MgZGlmZmVyZW50IHdpdGggdGhlIGNvbW1vbiB1 c2UgY2FzZSB0aGF0IGFsbG9jYXRlIG1lbW9yeSBmcm9tCj4gPiBkbWEKPiA+IHBvb2wgZXZlcnl0 aW1lIGZvciBldmVyeSBiZC4gV2h5IGRvIHRoaXMgaXMgdG8gbWFrZSBzdXJlIGFsbCBiZAo+ID4g bWVtb3J5IGlzCj4gPiBjb250aWd1b3VzIGZvciBzaW5nbGUgdHJhbnNmZXIgd2hhdGV2ZXIgc2lu Z2xlIGJkIG9yIG11bHRpLWJkcywKPiA+IHNpbmNlIHR3byBjYWxsCj4gPiBkbWFfcG9vbF9hbGxv YygpIGNhbid0IHByb21pc2UgdGhlIGFkZHJlc3MgaXMgY29udGlndW91cyBlc3BlY2lhbGx5Cj4g PiBmb3IgbXVsdGkKPiA+IHRocmVhZCBjYXNlIHN1Y2ggYXMgZG1hdGVzdCAndGhyZWFkc19wZXJf Y2hhbiA9IDUnLiBZb3UgY2FuIGNoYW5nZQo+ID4gdG8gJwo+ID4gbm9yYW5kb209dHJ1ZSAnIGFu ZCAnIHRlc3RfYnVmX3NpemUgPSAxNjM4NDAnIGluIGRtYXRlc3QuYyB0byBsb29rCj4gPiB3aGF0 IGlzc3VlCj4gPiBjb21pbmcgd2l0aG91dCB0aGlzIHBhdGNoLgo+ID4gPiAKPiA+ID4gU28gc29t ZXRoaW5nIGlzbid0IHJpZ2h0IHdpdGggdGhpcyBjaGFuZ2UuCj4gPiAKPiA+IEkgdGhpbmsgdGhp cyBwYXRjaCBpcyB0aGUgZWFzeSB3YXkgdG8gcmVzb2x2ZSB0aGUgYmQgY29udGlndW91cwo+ID4g aXNzdWUsIGJ1dCB0aGUKPiA+IGNvc3QgaXMgdG8gYWxsb2NhdGUgbW9yZSBkbWEgcG9vbCBtZW1v cnkgd2hpY2ggbWF5IG5vdCB1c2VkLgo+ID4gPiAKPiA+ID4gUmVnYXJkcywKPiA+ID4gTHVjYXMK PiA+ID4gCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFdoYXQgZG8geW91IGdhaW4gYnkgb3Zlci1hbGxv Y2F0aW5nIGVhY2ggQkQgYnkgYSBmYWN0b3Igb2YKPiA+ID4gPiA+IDIwPwo+ID4gPiA+IAo+ID4g PiA+IEkgZ3Vlc3MgZG1hX3Bvb2xfYWxsb2Mgd2lsbCByZXR1cm4gZXJyb3IgaW4gc3VjaCBjYXNl LCBhbmQgdGhlbgo+ID4gPiA+IGNhdXNlIGRtYSBzZXR1cCB0cmFuc2ZlciBmYWlsdXJlLgo+ID4g PiA+ID4gCj4gPiA+ID4gPiBSZWdhcmRzLAo+ID4gPiA+ID4gTHVjYXMKPiA+ID4gPiA+IAo+ID4g PiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBSb2JpbiBHb25nIDx5aWJpbi5nb25nQG54cC5jb20+Cj4g PiA+ID4gPiA+IC0tLQo+ID4gPiA+ID4gPiDCoGRyaXZlcnMvZG1hL2lteC1zZG1hLmMgfCAxNyAr KysrKysrKysrKysrKysrLQo+ID4gPiA+ID4gPiDCoDEgZmlsZSBjaGFuZ2VkLCAxNiBpbnNlcnRp b25zKCspLCAxIGRlbGV0aW9uKC0pCj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBkaWZmIC0tZ2l0 IGEvZHJpdmVycy9kbWEvaW14LXNkbWEuYyBiL2RyaXZlcnMvZG1hL2lteC0KPiA+ID4gPiA+ID4g c2RtYS5jCj4gPiA+ID4gPiA+IGluZGV4Cj4gPiA+ID4gPiA+IGI0ZWMyZDIuLjU5NzM0ODkgMTAw NjQ0Cj4gPiA+ID4gPiA+IC0tLSBhL2RyaXZlcnMvZG1hL2lteC1zZG1hLmMKPiA+ID4gPiA+ID4g KysrIGIvZHJpdmVycy9kbWEvaW14LXNkbWEuYwo+ID4gPiA+ID4gPiBAQCAtMjk4LDYgKzI5OCwx NSBAQCBzdHJ1Y3Qgc2RtYV9jb250ZXh0X2RhdGEgewo+ID4gPiA+ID4gPiA+IMKgCXUzMsKgwqBz Y3JhdGNoNzsKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IMKgfSBfX2F0dHJpYnV0ZV9fICgocGFj a2VkKSk7Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiArLyoKPiA+ID4gPiA+ID4gKyAqIEFsbCBi ZHMgaW4gb25lIHRyYW5zZmVyIHNob3VsZCBiZSBjb25zaXRlbnQgb24gU0RNQS4gVG8KPiA+ID4g PiA+ID4gZWFzaWx5Cj4gPiA+ID4gPiA+ICtmb2xsb3cgaXQsanVzdAo+ID4gPiA+ID4gPiArICog c2V0IHRoZSBkbWEgcG9vbCBzaXplIGFzIHRoZSBlbm91Z2ggYmRzLiBGb3IgZXhhbXBsZSwKPiA+ ID4gPiA+ID4gaW4KPiA+ID4gPiA+ID4gZG1hdGVzdAo+ID4gPiA+ID4gPiArY2FzZSwgdGhlCj4g PiA+ID4gPiA+ICsgKiBtYXggMjAgYmRzIG1lYW5zIHRoZSBtYXggZm9yIHNpbmdsZSB0cmFuc2Zl ciBpcyBOVU1fQkQKPiA+ID4gPiA+ID4gKgo+ID4gPiA+ID4gPiArU0RNQV9CRF9NQVhfQ05UID0g MjAKPiA+ID4gPiA+ID4gKyAqICogNjU1MzUgPSB+MS4yOE1CLiAyMCBiZHMgc3VwcG9zZWQgdG8g YmUgZW5vdWdoCj4gPiA+ID4gPiA+IGJhc2ljYWxseS5JZgo+ID4gPiA+ID4gPiBpdCdzCj4gPiA+ ID4gPiA+ICtzdGlsbCBub3QKPiA+ID4gPiA+ID4gKyAqIGVub3VnaCBpbiBzb21lIHNwZWNpZmlj IGNhc2VzLCBlbmxhcmdlIGl0IGhlcmUuV2FybmluZwo+ID4gPiA+ID4gPiBtZXNzYWdlCj4gPiA+ ID4gPiA+ICt3b3VsZCBhbHNvCj4gPiA+ID4gPiA+ICsgKiBhcHBlYXIgaWYgdGhlIGJkIG51bWJl cnMgaXMgb3ZlciB0aGFuIDIwLgo+ID4gPiA+ID4gPiArICovCj4gPiA+ID4gPiA+ICsjZGVmaW5l IE5VTV9CRCAyMAo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gwqBzdHJ1Y3Qgc2RtYV9lbmdpbmU7 Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBAQCAtMTI3Myw3ICsxMjgyLDcgQEAgc3RhdGljIGlu dAo+ID4gPiA+ID4gPiBzZG1hX2FsbG9jX2NoYW5fcmVzb3VyY2VzKHN0cnVjdCBkbWFfY2hhbiAq Y2hhbikKPiA+ID4gPiA+ID4gPiDCoAkJZ290byBkaXNhYmxlX2Nsa19haGI7Cj4gPiA+ID4gPiA+ ID4gwqAJc2RtYWMtPmJkX3Bvb2wgPSBkbWFfcG9vbF9jcmVhdGUoImJkX3Bvb2wiLAo+ID4gPiA+ ID4gPiA+IGNoYW4tCj4gPiA+ID4gPiA+ID4gPiBkZXZpY2UtPmRldiwKPiA+ID4gPiA+ID4gPiAK PiA+ID4gPiA+ID4gPiAtCQkJCXNpemVvZihzdHJ1Y3QKPiA+ID4gPiA+ID4gPiBzZG1hX2J1ZmZl cl9kZXNjcmlwdG9yKSwKPiA+ID4gPiA+ID4gPiArCQkJCU5VTV9CRCAqIHNpemVvZihzdHJ1Y3QK PiA+ID4gPiA+ID4gPiBzZG1hX2J1ZmZlcl9kZXNjcmlwdG9yKSwKPiA+ID4gPiA+ID4gPiDCoAkJ CQkzMiwgMCk7Cj4gPiA+ID4gPiA+ID4gwqAJcmV0dXJuIDA7Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ ID4gPiBAQCAtMTMxNCw2ICsxMzIzLDEyIEBAIHN0YXRpYyBzdHJ1Y3Qgc2RtYV9kZXNjCj4gPiA+ ID4gPiA+ICpzZG1hX3RyYW5zZmVyX2luaXQoc3RydWN0IHNkbWFfY2hhbm5lbCAqc2RtYWMsCj4g PiA+ID4gPiA+IMKgewo+ID4gPiA+ID4gPiA+IMKgCXN0cnVjdCBzZG1hX2Rlc2MgKmRlc2M7Cj4g PiA+ID4gPiA+ID4gKwlpZiAoYmRzID4gTlVNX0JEKSB7Cj4gPiA+ID4gPiA+ID4gKwkJZGV2X2Vy cihzZG1hYy0+c2RtYS0+ZGV2LCAiJWQgYmRzIGV4Y2VlZAo+ID4gPiA+ID4gPiA+IHRoZQo+ID4g PiA+ID4gPiA+IG1heCAlZFxuIiwKPiA+ID4gPiA+ID4gPiArCQkJYmRzLCBOVU1fQkQpOwo+ID4g PiA+ID4gPiA+ICsJCWdvdG8gZXJyX291dDsKPiA+ID4gPiA+ID4gPiArCX0KPiA+ID4gPiA+ID4g Cj4gPiA+ID4gPiA+ICsKPiA+ID4gPiA+ID4gPiDCoAlkZXNjID0ga3phbGxvYygoc2l6ZW9mKCpk ZXNjKSksIEdGUF9OT1dBSVQpOwo+ID4gPiA+ID4gPiA+IMKgCWlmICghZGVzYykKPiA+ID4gPiA+ ID4gPiDCoAkJZ290byBlcnJfb3V0OwotLS0KVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6 IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGRtYWVuZ2luZSIgaW4KdGhlIGJvZHkgb2YgYSBt ZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKTW9yZSBtYWpvcmRvbW8gaW5mbyBh dCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: l.stach@pengutronix.de (Lucas Stach) Date: Mon, 06 Aug 2018 14:29:50 +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> <1532424136.32306.3.camel@pengutronix.de> Message-ID: <1533558590.2809.1.camel@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Robin, Am Montag, den 06.08.2018, 08:04 +0000 schrieb Robin Gong: > Hello Lucas, > Any comment for my reply? So I've looked at this again and sadly I need to NACK this patch. It is a total API abuse of the dma_pool API and even the patch introducing the dma_pool usage in this driver is wrong and should be reverted. The SDMA need contiguous buffer descriptors for each channel, something the dma_pool abstraction isn't able to provide. So either the dma_pool implementation needs to be extended to support this use-case, or you can't use this at all in the sdma driver. Adding hacks, which are abusing the API, to cram a dma_pool into the sdma driver is not a valid way to implement things for upstream. Regards, Lucas > > -----Original Message----- > > From: Robin Gong > > Sent: 2018?7?25? 9:25 > > To: 'Lucas Stach' ; 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 > > > > > -----Original Message----- > > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > > Sent: 2018?7?24? 17:22 > > > To: Robin Gong ; vkoul at kernel.org; > > > dan.j.williams at intel.com; s.hauer at pengutronix.de; > > > linux at armlinux.org.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 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 > > > > m>; > > > > > 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. > > Please notice only allocate bds memory from dma pool one time even > > in multi > > bds. > > That's different with the common use case that allocate memory from > > dma > > pool everytime for every bd. Why do this is to make sure all bd > > memory is > > contiguous for single transfer whatever single bd or multi-bds, > > since two call > > dma_pool_alloc() can't promise the address is contiguous especially > > for multi > > thread case such as dmatest 'threads_per_chan = 5'. You can change > > to ' > > norandom=true ' and ' test_buf_size = 163840' in dmatest.c to look > > what issue > > coming without this patch. > > > > > > So something isn't right with this change. > > > > I think this patch is the easy way to resolve the bd contiguous > > issue, but the > > cost is to allocate more dma pool memory which may not used. > > > > > > 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=-1.0 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 1CE0FC4646D for ; Mon, 6 Aug 2018 12:30:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C570521945 for ; Mon, 6 Aug 2018 12:30:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C570521945 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 S1731969AbeHFOiz (ORCPT ); Mon, 6 Aug 2018 10:38:55 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:43649 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730822AbeHFOiz (ORCPT ); Mon, 6 Aug 2018 10:38:55 -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 1fmee1-0000E4-Hw; Mon, 06 Aug 2018 14:29:53 +0200 Message-ID: <1533558590.2809.1.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" , "linux-kernel@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "linux-arm-kernel@lists.infradead.org" Date: Mon, 06 Aug 2018 14:29:50 +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> <1532424136.32306.3.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 Hi Robin, Am Montag, den 06.08.2018, 08:04 +0000 schrieb Robin Gong: > Hello Lucas, > Any comment for my reply? So I've looked at this again and sadly I need to NACK this patch. It is a total API abuse of the dma_pool API and even the patch introducing the dma_pool usage in this driver is wrong and should be reverted. The SDMA need contiguous buffer descriptors for each channel, something the dma_pool abstraction isn't able to provide. So either the dma_pool implementation needs to be extended to support this use-case, or you can't use this at all in the sdma driver. Adding hacks, which are abusing the API, to cram a dma_pool into the sdma driver is not a valid way to implement things for upstream. Regards, Lucas > > -----Original Message----- > > From: Robin Gong > > Sent: 2018年7月25日 9:25 > > To: 'Lucas Stach' ; 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 > > > > > -----Original Message----- > > > From: Lucas Stach [mailto:l.stach@pengutronix.de] > > > Sent: 2018年7月24日 17:22 > > > 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 > > > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 > > > bds > > > for one transfer > > > > > > 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 > > > > m>; > > > > > 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. > > Please notice only allocate bds memory from dma pool one time even > > in multi > > bds. > > That's different with the common use case that allocate memory from > > dma > > pool everytime for every bd. Why do this is to make sure all bd > > memory is > > contiguous for single transfer whatever single bd or multi-bds, > > since two call > > dma_pool_alloc() can't promise the address is contiguous especially > > for multi > > thread case such as dmatest 'threads_per_chan = 5'. You can change > > to ' > > norandom=true ' and ' test_buf_size = 163840' in dmatest.c to look > > what issue > > coming without this patch. > > > > > > So something isn't right with this change. > > > > I think this patch is the easy way to resolve the bd contiguous > > issue, but the > > cost is to allocate more dma pool memory which may not used. > > > > > > 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;