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: [v9,1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support From: Long Cheng Message-Id: <1547116431.3831.43.camel@mhfsdcap03> Date: Thu, 10 Jan 2019 18:33:51 +0800 To: Vinod Koul Cc: Randy Dunlap , Rob Herring , Mark Rutland , Ryder Lee , Sean Wang , Nicolas Boichat , Matthias Brugger , Dan Williams , Greg Kroah-Hartman , Jiri Slaby , Sean Wang , dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Yingjoe Chen , YT Shen , Zhenbao Liu List-ID: T24gRnJpLCAyMDE5LTAxLTA0IGF0IDIyOjQ5ICswNTMwLCBWaW5vZCBLb3VsIHdyb3RlOgo+IE9u IDAyLTAxLTE5LCAxMDoxMiwgTG9uZyBDaGVuZyB3cm90ZToKPiA+IEluIERNQSBlbmdpbmUgZnJh bWV3b3JrLCBhZGQgODI1MCB1YXJ0IGRtYSB0byBzdXBwb3J0IE1lZGlhVGVrIHVhcnQuCj4gPiBJ ZiBNZWRpYVRlayB1YXJ0IGVuYWJsZWQoU0VSSUFMXzgyNTBfTVQ2NTc3KSwgYW5kIHdhbnQgdG8g aW1wcm92ZQo+ID4gdGhlIHBlcmZvcm1hbmNlLCBjYW4gZW5hYmxlIHRoZSBmdW5jdGlvbi4KPiAK PiBJcyB0aGUgRE1BIGNvbnRyb2xsZXIgVUFSVCBzcGVjaWZpYywgY2FuIGl0IHdvcmsgd2l0aCBv dGhlciBjb250cm9sbGVycwo+IGFzIHdlbGwsIGlmIHNvIHlvdSBzaG91bGQgZ2V0IHJpZCBvZiB1 YXJ0IG5hbWUgaW4gcGF0Y2gKPiAKCkkgZG9uJ3Qga25vdyB0aGF0IGl0IGNhbiB3b3JrIG9yIG5v dCBvbiBvdGhlciBjb250cm9sbGVyLiBidXQgaXQncyBmb3IKTWVkaWFUZWsgU09DCgo+ID4gKyNk ZWZpbmUgTVRLX1VBUlRfQVBETUFfQ0hBTk5FTFMJCShDT05GSUdfU0VSSUFMXzgyNTBfTlJfVUFS VFMgKiAyKQo+IAo+IFdoeSBhcmUgdGhlIGNoYW5uZWxzIG5vdCBjb21pbmcgZnJvbSBEVD8KPiAK Cmkgd2lsbCB1c2luZyBkbWEtcmVxdWVzdHMgaW5zdGFsbCBvZiBpdC4KCj4gPiArCj4gPiArI2Rl ZmluZSBWRkZfRU5fQgkJQklUKDApCj4gPiArI2RlZmluZSBWRkZfU1RPUF9CCQlCSVQoMCkKPiA+ ICsjZGVmaW5lIFZGRl9GTFVTSF9CCQlCSVQoMCkKPiA+ICsjZGVmaW5lIFZGRl80R19TVVBQT1JU X0IJQklUKDApCj4gPiArI2RlZmluZSBWRkZfUlhfSU5UX0VOMF9CCUJJVCgwKQkvKnJ4IHZhbGlk IHNpemUgPj0gIHZmZiB0aHJlKi8KPiA+ICsjZGVmaW5lIFZGRl9SWF9JTlRfRU4xX0IJQklUKDEp Cj4gPiArI2RlZmluZSBWRkZfVFhfSU5UX0VOX0IJCUJJVCgwKQkvKnR4IGxlZnQgc2l6ZSA+PSB2 ZmYgdGhyZSovCj4gCj4gc3BhY2UgYXJvdW5kIC8qIHNwYWNlICovIGFsc28gcnVuIGNoZWNrcGF0 Y2ggdG8gY2hlY2sgZm9yIHN0eWxlIGVycm9ycwo+IAoKb2suCgo+ID4gK3N0YXRpYyB2b2lkIG10 a191YXJ0X2FwZG1hX3N0YXJ0X3R4KHN0cnVjdCBtdGtfY2hhbiAqYykKPiA+ICt7Cj4gPiArCXVu c2lnbmVkIGludCBsZW4sIHNlbmQsIGxlZnQsIHdwdCwgZF93cHQsIHRtcDsKPiA+ICsJaW50IHJl dDsKPiA+ICsKPiA+ICsJbGVmdCA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xFRlRfU0la RSk7Cj4gPiArCWlmICghbGVmdCkgewo+ID4gKwkJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZG X0lOVF9FTiwgVkZGX1RYX0lOVF9FTl9CKTsKPiA+ICsJCXJldHVybjsKPiA+ICsJfQo+ID4gKwo+ ID4gKwkvKiBXYWl0IDFzZWMgZm9yIGZsdXNoLCAgY2FuJ3Qgc2xlZXAqLwo+ID4gKwlyZXQgPSBy ZWFkeF9wb2xsX3RpbWVvdXQocmVhZGwsIGMtPmJhc2UgKyBWRkZfRkxVU0gsIHRtcCwKPiA+ICsJ CQl0bXAgIT0gVkZGX0ZMVVNIX0IsIDAsIDEwMDAwMDApOwo+ID4gKwlpZiAocmV0KQo+ID4gKwkJ ZGV2X3dhcm4oYy0+dmMuY2hhbi5kZXZpY2UtPmRldiwgInR4OiBmYWlsLCBkZWJ1Zz0weCV4XG4i LAo+ID4gKwkJCW10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0RFQlVHX1NUQVRVUykpOwo+ID4g Kwo+ID4gKwlzZW5kID0gbWluX3QodW5zaWduZWQgaW50LCBsZWZ0LCBjLT5kZXNjLT5hdmFpbF9s ZW4pOwo+ID4gKwl3cHQgPSBtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9XUFQpOwo+ID4gKwls ZW4gPSBtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9MRU4pOwo+ID4gKwo+ID4gKwlkX3dwdCA9 IHdwdCArIHNlbmQ7Cj4gPiArCWlmICgoZF93cHQgJiBWRkZfUklOR19TSVpFKSA+PSBsZW4pIHsK PiA+ICsJCWRfd3B0ID0gZF93cHQgLSBsZW47Cj4gPiArCQlkX3dwdCA9IGRfd3B0IF4gVkZGX1JJ TkdfV1JBUDsKPiA+ICsJfQo+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfV1BULCBk X3dwdCk7Cj4gPiArCj4gPiArCWMtPmRlc2MtPmF2YWlsX2xlbiAtPSBzZW5kOwo+ID4gKwo+ID4g KwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfSU5UX0VOLCBWRkZfVFhfSU5UX0VOX0IpOwo+ ID4gKwlpZiAobXRrX3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfRkxVU0gpID09IDBVKQo+ID4gKwkJ bXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0ZMVVNILCBWRkZfRkxVU0hfQik7Cj4gPiArfQo+ ID4gKwo+ID4gK3N0YXRpYyB2b2lkIG10a191YXJ0X2FwZG1hX3N0YXJ0X3J4KHN0cnVjdCBtdGtf Y2hhbiAqYykKPiA+ICt7Cj4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRtYV9kZXNjICpkID0gYy0+ ZGVzYzsKPiA+ICsJdW5zaWduZWQgaW50IGxlbiwgd2csIHJnLCBjbnQ7Cj4gPiArCj4gPiArCWlm ICgobXRrX3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfVkFMSURfU0laRSkgPT0gMFUpIHx8Cj4gPiAr CQkhZCB8fCAhdmNoYW5fbmV4dF9kZXNjKCZjLT52YykpCj4gPiArCQlyZXR1cm47Cj4gPiArCj4g PiArCWxlbiA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xFTik7Cj4gPiArCXJnID0gbXRr X3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfUlBUKTsKPiA+ICsJd2cgPSBtdGtfdWFydF9hcGRtYV9y ZWFkKGMsIFZGRl9XUFQpOwo+ID4gKwlpZiAoKHJnIF4gd2cpICYgVkZGX1JJTkdfV1JBUCkKPiA+ ICsJCWNudCA9ICh3ZyAmIFZGRl9SSU5HX1NJWkUpICsgbGVuIC0gKHJnICYgVkZGX1JJTkdfU0la RSk7Cj4gPiArCWVsc2UKPiA+ICsJCWNudCA9ICh3ZyAmIFZGRl9SSU5HX1NJWkUpIC0gKHJnICYg VkZGX1JJTkdfU0laRSk7Cj4gPiArCj4gPiArCWMtPnJ4X3N0YXR1cyA9IGNudDsKPiA+ICsJbXRr X3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX1JQVCwgd2cpOwo+ID4gKwo+ID4gKwlsaXN0X2RlbCgm ZC0+dmQubm9kZSk7Cj4gPiArCXZjaGFuX2Nvb2tpZV9jb21wbGV0ZSgmZC0+dmQpOwo+ID4gK30K PiAKPiB0aGlzIGxvb2tzIG9kZCwgd2h5IGRvIHlvdSBoYXZlIGRpZmZlcmVudCByeCBhbmQgdHgg c3RhcnQgcm91dGluZXM/Cj4gCgpXb3VsZCB5b3UgbGlrZSBleHBsYWluIGl0IGluIG1vcmUgZGV0 YWlsPyB0aGFua3MuCkluIHR4IGZ1bmN0aW9uLCB3aWxsIHdhaXQgdGhlIGxhc3QgZGF0YSBmbHVz aCBkb25lLiBhbmQgdGhlIGNvdW50IHRoZQpzaXplIHRoYXQgc2VuZC4KSW4gUnggZnVuY3Rpb24s IHdpbGwgY291bnQgdGhlIHNpemUgdGhhdCByZWNlaXZlLgpBbnkgd2F5LCBpbiByeCAvIHR4LCBu ZWVkIGFuZGxlIFdQVCBvciBSUFQuCgo+ID4gK3N0YXRpYyBpbnQgbXRrX3VhcnRfYXBkbWFfYWxs b2NfY2hhbl9yZXNvdXJjZXMoc3RydWN0IGRtYV9jaGFuICpjaGFuKQo+ID4gK3sKPiA+ICsJc3Ry dWN0IG10a191YXJ0X2FwZG1hZGV2ICptdGtkID0gdG9fbXRrX3VhcnRfYXBkbWFfZGV2KGNoYW4t PmRldmljZSk7Cj4gPiArCXN0cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2FwZG1hX2No YW4oY2hhbik7Cj4gPiArCXUzMiB0bXA7Cj4gPiArCWludCByZXQ7Cj4gPiArCj4gPiArCXBtX3J1 bnRpbWVfZ2V0X3N5bmMobXRrZC0+ZGRldi5kZXYpOwo+ID4gKwo+ID4gKwltdGtfdWFydF9hcGRt YV93cml0ZShjLCBWRkZfQUREUiwgMCk7Cj4gPiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZG Rl9USFJFLCAwKTsKPiA+ICsJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0xFTiwgMCk7Cj4g PiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9SU1QsIFZGRl9XQVJNX1JTVF9CKTsKPiA+ ICsKPiA+ICsJcmV0ID0gcmVhZHhfcG9sbF90aW1lb3V0KHJlYWRsLCBjLT5iYXNlICsgVkZGX0VO LCB0bXAsCj4gPiArCQkJdG1wID09IDAsIDEwLCAxMDApOwo+ID4gKwlpZiAocmV0KSB7Cj4gPiAr CQlkZXZfZXJyKGNoYW4tPmRldmljZS0+ZGV2LCAiZG1hIHJlc2V0OiBmYWlsLCB0aW1lb3V0XG4i KTsKPiA+ICsJCXJldHVybiByZXQ7Cj4gPiArCX0KPiAKPiByZWdpc3RlciByZWFkIGRvZXMgcmVz ZXQ/Cj4gCgonbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX1JTVCwgVkZGX1dBUk1fUlNUX0Ip OycgaXMgcmVzZXQuIHJlc2QganVzdApwb2xsIHJlc2V0IGRvbmUuCgo+ID4gKwo+ID4gKwlpZiAo IWMtPnJlcXVlc3RlZCkgewo+ID4gKwkJYy0+cmVxdWVzdGVkID0gdHJ1ZTsKPiA+ICsJCXJldCA9 IHJlcXVlc3RfaXJxKG10a2QtPmRtYV9pcnFbY2hhbi0+Y2hhbl9pZF0sCj4gPiArCQkJCSAgbXRr X3VhcnRfYXBkbWFfaXJxX2hhbmRsZXIsIElSUUZfVFJJR0dFUl9OT05FLAo+ID4gKwkJCQkgIEtC VUlMRF9NT0ROQU1FLCBjaGFuKTsKPiAKPiB3aHkgaXMgdGhlIGlycSBub3QgcmVxdWVzdGVkIGlu IGRyaXZlciBwcm9iZT8KPiAKCkkgaGF2ZSBleHBsYWluZWQgaW4gYmVsb3csCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL3BpcGVybWFpbC9saW51eC1tZWRpYXRlay8yMDE4LURlY2VtYmVyLzAx NjQxOC5odG1sCgo+ID4gK3N0YXRpYyBlbnVtIGRtYV9zdGF0dXMgbXRrX3VhcnRfYXBkbWFfdHhf c3RhdHVzKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwKPiA+ICsJCQkJCSBkbWFfY29va2llX3QgY29v a2llLAo+ID4gKwkJCQkJIHN0cnVjdCBkbWFfdHhfc3RhdGUgKnR4c3RhdGUpCj4gPiArewo+ID4g KwlzdHJ1Y3QgbXRrX2NoYW4gKmMgPSB0b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4pOwo+ID4g KwllbnVtIGRtYV9zdGF0dXMgcmV0Owo+ID4gKwl1bnNpZ25lZCBsb25nIGZsYWdzOwo+ID4gKwo+ ID4gKwlpZiAoIXR4c3RhdGUpCj4gPiArCQlyZXR1cm4gRE1BX0VSUk9SOwo+ID4gKwo+ID4gKwly ZXQgPSBkbWFfY29va2llX3N0YXR1cyhjaGFuLCBjb29raWUsIHR4c3RhdGUpOwo+ID4gKwlzcGlu X2xvY2tfaXJxc2F2ZSgmYy0+dmMubG9jaywgZmxhZ3MpOwo+ID4gKwlpZiAocmV0ID09IERNQV9J Tl9QUk9HUkVTUykgewo+ID4gKwkJYy0+cnhfc3RhdHVzID0gbXRrX3VhcnRfYXBkbWFfcmVhZChj LCBWRkZfUlBUKSAmIFZGRl9SSU5HX1NJWkU7Cj4gPiArCQlkbWFfc2V0X3Jlc2lkdWUodHhzdGF0 ZSwgYy0+cnhfc3RhdHVzKTsKPiA+ICsJfSBlbHNlIGlmIChyZXQgPT0gRE1BX0NPTVBMRVRFICYm IGMtPmNmZy5kaXJlY3Rpb24gPT0gRE1BX0RFVl9UT19NRU0pIHsKPiAKPiB3aHkgc2V0IHJlc2lk ZSB3aGVuIGl0IGlzIGNvbXBsZXRlPyBhbHNvIHJlc2lkZSBjYW4gYmUgbnVsbCwgdGhhdCBzaG91 bGQKPiBiZSBjaGVja2VkIGFzIHdlbGwKPiAKSW4gZGlmZmVyZW50IHN0YXR1cywgc2V0IGRpZmZl cmVudCByZXNpZGUuCgo+ID4gK3N0YXRpYyBzdHJ1Y3QgZG1hX2FzeW5jX3R4X2Rlc2NyaXB0b3Ig Km10a191YXJ0X2FwZG1hX3ByZXBfc2xhdmVfc2cKPiA+ICsJKHN0cnVjdCBkbWFfY2hhbiAqY2hh biwgc3RydWN0IHNjYXR0ZXJsaXN0ICpzZ2wsCj4gPiArCXVuc2lnbmVkIGludCBzZ2xlbiwgZW51 bSBkbWFfdHJhbnNmZXJfZGlyZWN0aW9uIGRpciwKPiA+ICsJdW5zaWduZWQgbG9uZyB0eF9mbGFn cywgdm9pZCAqY29udGV4dCkKPiA+ICt7Cj4gPiArCXN0cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210 a191YXJ0X2FwZG1hX2NoYW4oY2hhbik7Cj4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRtYV9kZXNj ICpkOwo+ID4gKwo+ID4gKwlpZiAoKGRpciAhPSBETUFfREVWX1RPX01FTSkgJiYKPiA+ICsJCShk aXIgIT0gRE1BX01FTV9UT19ERVYpKSB7Cj4gPiArCQlkZXZfZXJyKGNoYW4tPmRldmljZS0+ZGV2 LCAiYmFkIGRpcmVjdGlvblxuIik7Cj4gPiArCQlyZXR1cm4gTlVMTDsKPiA+ICsJfQo+IAo+IHdl IGhhdmUgYSBtYWNybyBmb3IgdGhpcwoKVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIGkgd2ls bCBtb2RpZnkgaXQuCj4gCj4gPiArCj4gPiArCS8qIE5vdyBhbGxvY2F0ZSBhbmQgc2V0dXAgdGhl IGRlc2NyaXB0b3IgKi8KPiA+ICsJZCA9IGt6YWxsb2Moc2l6ZW9mKCpkKSwgR0ZQX0FUT01JQyk7 Cj4gPiArCWlmICghZCkKPiA+ICsJCXJldHVybiBOVUxMOwo+ID4gKwo+ID4gKwkvKiBzZ2xlbiBp cyAxICovCj4gCj4gPwo+IAo+ID4gK3N0YXRpYyBpbnQgbXRrX3VhcnRfYXBkbWFfc2xhdmVfY29u ZmlnKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwKPiA+ICsJCQkJc3RydWN0IGRtYV9zbGF2ZV9jb25m aWcgKmNmZykKPiA+ICt7Cj4gPiArCXN0cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2Fw ZG1hX2NoYW4oY2hhbik7Cj4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRtYWRldiAqbXRrZCA9Cj4g PiArCQkJCXRvX210a191YXJ0X2FwZG1hX2RldihjLT52Yy5jaGFuLmRldmljZSk7Cj4gPiArCj4g PiArCWMtPmNmZyA9ICpjZmc7Cj4gPiArCj4gPiArCWlmIChjZmctPmRpcmVjdGlvbiA9PSBETUFf REVWX1RPX01FTSkgewo+IAo+IGZnLT5kaXJlY3Rpb24gaXMgZGVwcmVjYXRlZCwgaW4gZmFjdCBJ IGhhdmUgcmVtb3ZlZCBhbGwgdXNlcnMgcmVjZW50bHksCj4gcGxlYXNlIGRvIG5vdCB1c2UgdGhp cwoKWW91IHdpbGwgcmVtb3ZlICdkaXJlY3Rpb24nIGluICdzdHJ1Y3QgZG1hX3NsYXZlX2NvbmZp Zyc/IGlmIHJlbW92ZSwgaG93CmRvIGNvbmZpcm0gZGlyZWN0aW9uPwoKPiAKPiA+ICsJCXVuc2ln bmVkIGludCByeF9sZW4gPSBjZmctPnNyY19hZGRyX3dpZHRoICogMTAyNDsKPiA+ICsKPiA+ICsJ CW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9BRERSLCBjZmctPnNyY19hZGRyKTsKPiA+ICsJ CW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9MRU4sIHJ4X2xlbik7Cj4gPiArCQltdGtfdWFy dF9hcGRtYV93cml0ZShjLCBWRkZfVEhSRSwgVkZGX1JYX1RIUkUocnhfbGVuKSk7Cj4gPiArCQlt dGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfSU5UX0VOLAo+ID4gKwkJCQlWRkZfUlhfSU5UX0VO MF9CIHwgVkZGX1JYX0lOVF9FTjFfQik7Cj4gPiArCQltdGtfdWFydF9hcGRtYV93cml0ZShjLCBW RkZfUlBULCAwKTsKPiA+ICsJCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9JTlRfRkxBRywg VkZGX1JYX0lOVF9GTEFHX0NMUl9CKTsKPiA+ICsJCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZG Rl9FTiwgVkZGX0VOX0IpOwo+IAo+IHdoeSBhcmUgd2Ugd3JpdGluZyB0aGlzIGhlcmUsIHdlIGFy ZSBzdXBwb3NlZCB0byBkbyB0aGF0IHdoZW4gdHhuCj4gc3RhcnRzIQo+IAoKYWxzbyB5b3UgY2Fu IHJldmlldyB0aGUgbGluawpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1haWwvbGlu dXgtbWVkaWF0ZWsvMjAxOC1EZWNlbWJlci8wMTY0MTguaHRtbAoKPiA+ICtzdGF0aWMgaW50IG10 a191YXJ0X2FwZG1hX2RldmljZV9yZXN1bWUoc3RydWN0IGRtYV9jaGFuICpjaGFuKQo+ID4gK3sK PiA+ICsJLyoganVzdCBmb3IgY2hlY2sgY2FwcyBwYXNzICovCj4gPiArCXJldHVybiAwOwo+ID4g K30KPiAKPiBpZiB5b3UgZG8gbm90IHN1cHBvcnQgdGhpcyBwbGVhc2UgcmVtb3ZlIHRoaXMhCj4g Cj4gPiArc3RhdGljIHZvaWQgbXRrX3VhcnRfYXBkbWFfZnJlZShzdHJ1Y3QgbXRrX3VhcnRfYXBk bWFkZXYgKm10a2QpCj4gPiArewo+ID4gKwl3aGlsZSAobGlzdF9lbXB0eSgmbXRrZC0+ZGRldi5j aGFubmVscykgPT0gMCkgewo+ID4gKwkJc3RydWN0IG10a19jaGFuICpjID0gbGlzdF9maXJzdF9l bnRyeSgmbXRrZC0+ZGRldi5jaGFubmVscywKPiA+ICsJCQlzdHJ1Y3QgbXRrX2NoYW4sIHZjLmNo YW4uZGV2aWNlX25vZGUpOwo+ID4gKwo+ID4gKwkJbGlzdF9kZWwoJmMtPnZjLmNoYW4uZGV2aWNl X25vZGUpOwo+ID4gKwkJdGFza2xldF9raWxsKCZjLT52Yy50YXNrKTsKPiA+ICsJfQo+ID4gK30K PiA+ICsKPiA+ICtzdGF0aWMgY29uc3Qgc3RydWN0IG9mX2RldmljZV9pZCBtdGtfdWFydF9hcGRt YV9tYXRjaFtdID0gewo+ID4gKwl7IC5jb21wYXRpYmxlID0gIm1lZGlhdGVrLG10NjU3Ny11YXJ0 LWRtYSIsIH0sCj4gCj4gd2hlcmUgaXMgdGhlIGJpbmRpbmcgZG9jdW1lbnQgZm9yIGVkaWF0ZWss bXQ2NTc3LXVhcnQtZG1hID8/Cj4gCgpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1h aWwvbGludXgtbWVkaWF0ZWsvMjAxOC1EZWNlbWJlci8wMTYxNTQuaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Long Cheng Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support Date: Thu, 10 Jan 2019 18:33:51 +0800 Message-ID: <1547116431.3831.43.camel@mhfsdcap03> References: <1546395178-8880-1-git-send-email-long.cheng@mediatek.com> <1546395178-8880-2-git-send-email-long.cheng@mediatek.com> <20190104171953.GQ13372@vkoul-mobl.Dlink> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190104171953.GQ13372@vkoul-mobl.Dlink> Sender: linux-kernel-owner@vger.kernel.org To: Vinod Koul Cc: Randy Dunlap , Rob Herring , Mark Rutland , Ryder Lee , Sean Wang , Nicolas Boichat , Matthias Brugger , Dan Williams , Greg Kroah-Hartman , Jiri Slaby , Sean Wang , dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Yingjoe Chen , YT Shen , Zhenbao Liu List-Id: linux-mediatek@lists.infradead.org On Fri, 2019-01-04 at 22:49 +0530, Vinod Koul wrote: > On 02-01-19, 10:12, Long Cheng wrote: > > In DMA engine framework, add 8250 uart dma to support MediaTek uart. > > If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve > > the performance, can enable the function. > > Is the DMA controller UART specific, can it work with other controllers > as well, if so you should get rid of uart name in patch > I don't know that it can work or not on other controller. but it's for MediaTek SOC > > +#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2) > > Why are the channels not coming from DT? > i will using dma-requests install of it. > > + > > +#define VFF_EN_B BIT(0) > > +#define VFF_STOP_B BIT(0) > > +#define VFF_FLUSH_B BIT(0) > > +#define VFF_4G_SUPPORT_B BIT(0) > > +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/ > > +#define VFF_RX_INT_EN1_B BIT(1) > > +#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/ > > space around /* space */ also run checkpatch to check for style errors > ok. > > +static void mtk_uart_apdma_start_tx(struct mtk_chan *c) > > +{ > > + unsigned int len, send, left, wpt, d_wpt, tmp; > > + int ret; > > + > > + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE); > > + if (!left) { > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + return; > > + } > > + > > + /* Wait 1sec for flush, can't sleep*/ > > + ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp, > > + tmp != VFF_FLUSH_B, 0, 1000000); > > + if (ret) > > + dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n", > > + mtk_uart_apdma_read(c, VFF_DEBUG_STATUS)); > > + > > + send = min_t(unsigned int, left, c->desc->avail_len); > > + wpt = mtk_uart_apdma_read(c, VFF_WPT); > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + > > + d_wpt = wpt + send; > > + if ((d_wpt & VFF_RING_SIZE) >= len) { > > + d_wpt = d_wpt - len; > > + d_wpt = d_wpt ^ VFF_RING_WRAP; > > + } > > + mtk_uart_apdma_write(c, VFF_WPT, d_wpt); > > + > > + c->desc->avail_len -= send; > > + > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + if (mtk_uart_apdma_read(c, VFF_FLUSH) == 0U) > > + mtk_uart_apdma_write(c, VFF_FLUSH, VFF_FLUSH_B); > > +} > > + > > +static void mtk_uart_apdma_start_rx(struct mtk_chan *c) > > +{ > > + struct mtk_uart_apdma_desc *d = c->desc; > > + unsigned int len, wg, rg, cnt; > > + > > + if ((mtk_uart_apdma_read(c, VFF_VALID_SIZE) == 0U) || > > + !d || !vchan_next_desc(&c->vc)) > > + return; > > + > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + rg = mtk_uart_apdma_read(c, VFF_RPT); > > + wg = mtk_uart_apdma_read(c, VFF_WPT); > > + if ((rg ^ wg) & VFF_RING_WRAP) > > + cnt = (wg & VFF_RING_SIZE) + len - (rg & VFF_RING_SIZE); > > + else > > + cnt = (wg & VFF_RING_SIZE) - (rg & VFF_RING_SIZE); > > + > > + c->rx_status = cnt; > > + mtk_uart_apdma_write(c, VFF_RPT, wg); > > + > > + list_del(&d->vd.node); > > + vchan_cookie_complete(&d->vd); > > +} > > this looks odd, why do you have different rx and tx start routines? > Would you like explain it in more detail? thanks. In tx function, will wait the last data flush done. and the count the size that send. In Rx function, will count the size that receive. Any way, in rx / tx, need andle WPT or RPT. > > +static int mtk_uart_apdma_alloc_chan_resources(struct dma_chan *chan) > > +{ > > + struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device); > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + u32 tmp; > > + int ret; > > + > > + pm_runtime_get_sync(mtkd->ddev.dev); > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, 0); > > + mtk_uart_apdma_write(c, VFF_THRE, 0); > > + mtk_uart_apdma_write(c, VFF_LEN, 0); > > + mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B); > > + > > + ret = readx_poll_timeout(readl, c->base + VFF_EN, tmp, > > + tmp == 0, 10, 100); > > + if (ret) { > > + dev_err(chan->device->dev, "dma reset: fail, timeout\n"); > > + return ret; > > + } > > register read does reset? > 'mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B);' is reset. resd just poll reset done. > > + > > + if (!c->requested) { > > + c->requested = true; > > + ret = request_irq(mtkd->dma_irq[chan->chan_id], > > + mtk_uart_apdma_irq_handler, IRQF_TRIGGER_NONE, > > + KBUILD_MODNAME, chan); > > why is the irq not requested in driver probe? > I have explained in below, http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan, > > + dma_cookie_t cookie, > > + struct dma_tx_state *txstate) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + enum dma_status ret; > > + unsigned long flags; > > + > > + if (!txstate) > > + return DMA_ERROR; > > + > > + ret = dma_cookie_status(chan, cookie, txstate); > > + spin_lock_irqsave(&c->vc.lock, flags); > > + if (ret == DMA_IN_PROGRESS) { > > + c->rx_status = mtk_uart_apdma_read(c, VFF_RPT) & VFF_RING_SIZE; > > + dma_set_residue(txstate, c->rx_status); > > + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) { > > why set reside when it is complete? also reside can be null, that should > be checked as well > In different status, set different reside. > > +static struct dma_async_tx_descriptor *mtk_uart_apdma_prep_slave_sg > > + (struct dma_chan *chan, struct scatterlist *sgl, > > + unsigned int sglen, enum dma_transfer_direction dir, > > + unsigned long tx_flags, void *context) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdma_desc *d; > > + > > + if ((dir != DMA_DEV_TO_MEM) && > > + (dir != DMA_MEM_TO_DEV)) { > > + dev_err(chan->device->dev, "bad direction\n"); > > + return NULL; > > + } > > we have a macro for this Thanks for your suggestion. i will modify it. > > > + > > + /* Now allocate and setup the descriptor */ > > + d = kzalloc(sizeof(*d), GFP_ATOMIC); > > + if (!d) > > + return NULL; > > + > > + /* sglen is 1 */ > > ? > > > +static int mtk_uart_apdma_slave_config(struct dma_chan *chan, > > + struct dma_slave_config *cfg) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdmadev *mtkd = > > + to_mtk_uart_apdma_dev(c->vc.chan.device); > > + > > + c->cfg = *cfg; > > + > > + if (cfg->direction == DMA_DEV_TO_MEM) { > > fg->direction is deprecated, in fact I have removed all users recently, > please do not use this You will remove 'direction' in 'struct dma_slave_config'? if remove, how do confirm direction? > > > + unsigned int rx_len = cfg->src_addr_width * 1024; > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, cfg->src_addr); > > + mtk_uart_apdma_write(c, VFF_LEN, rx_len); > > + mtk_uart_apdma_write(c, VFF_THRE, VFF_RX_THRE(rx_len)); > > + mtk_uart_apdma_write(c, VFF_INT_EN, > > + VFF_RX_INT_EN0_B | VFF_RX_INT_EN1_B); > > + mtk_uart_apdma_write(c, VFF_RPT, 0); > > + mtk_uart_apdma_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B); > > + mtk_uart_apdma_write(c, VFF_EN, VFF_EN_B); > > why are we writing this here, we are supposed to do that when txn > starts! > also you can review the link http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static int mtk_uart_apdma_device_resume(struct dma_chan *chan) > > +{ > > + /* just for check caps pass */ > > + return 0; > > +} > > if you do not support this please remove this! > > > +static void mtk_uart_apdma_free(struct mtk_uart_apdmadev *mtkd) > > +{ > > + while (list_empty(&mtkd->ddev.channels) == 0) { > > + struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels, > > + struct mtk_chan, vc.chan.device_node); > > + > > + list_del(&c->vc.chan.device_node); > > + tasklet_kill(&c->vc.task); > > + } > > +} > > + > > +static const struct of_device_id mtk_uart_apdma_match[] = { > > + { .compatible = "mediatek,mt6577-uart-dma", }, > > where is the binding document for ediatek,mt6577-uart-dma ?? > http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016154.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable 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 23AF8C43387 for ; Thu, 10 Jan 2019 10:34:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D39BA214C6 for ; Thu, 10 Jan 2019 10:34:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DZMAdHQC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D39BA214C6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Li28f3IYYQYz4AYmJUyz0K4VFTnlWLuTMplWlm4e8es=; b=DZMAdHQCCr76Qb luxNtxYHj+f5B7+LUlqRn/NfK3hBfWEezl8PtlN/m34ZyRtqahj0vsJUg+UBKNyVz17vq15wGYwmk 3KIPfcRRZmiWqg3CqGlPIDwD2mRIDge0RCckGugen5VVEx5q2QRgua8G14PepV6I0Ajy+8PmzqmoO 9YjqrBIYqNF8fF+m68dIZnw2tunxkX9Xf3lyw/t8GRRhwIXIQmgvaZgFX61+pwPWXEsShrzVY2UFp StYoLjj3qxtk8AZpZ5B+FGti6XkDpD8DqCUHir4YnT+qlVjw4ClCkk/Zuco9ASCVEnipHLEhzZ3Az lU5qNfvDFoEGVnISlFOQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghXfL-0006ke-Fi; Thu, 10 Jan 2019 10:34:23 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghXfH-0006kE-Js; Thu, 10 Jan 2019 10:34:21 +0000 X-UUID: b9586fe0a219428d9ffa92fd2aab3dbe-20190110 X-UUID: b9586fe0a219428d9ffa92fd2aab3dbe-20190110 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 224303398; Thu, 10 Jan 2019 02:34:03 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Jan 2019 02:34:02 -0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Jan 2019 18:33:53 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 10 Jan 2019 18:33:51 +0800 Message-ID: <1547116431.3831.43.camel@mhfsdcap03> Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support From: Long Cheng To: Vinod Koul Date: Thu, 10 Jan 2019 18:33:51 +0800 In-Reply-To: <20190104171953.GQ13372@vkoul-mobl.Dlink> References: <1546395178-8880-1-git-send-email-long.cheng@mediatek.com> <1546395178-8880-2-git-send-email-long.cheng@mediatek.com> <20190104171953.GQ13372@vkoul-mobl.Dlink> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190110_023419_661974_6B9E3CC6 X-CRM114-Status: GOOD ( 23.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Nicolas Boichat , Zhenbao Liu , linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Greg Kroah-Hartman , Randy Dunlap , linux-kernel@vger.kernel.org, Rob Herring , Sean Wang , YT Shen , dmaengine@vger.kernel.org, Ryder Lee , linux-mediatek@lists.infradead.org, Sean Wang , Jiri Slaby , Matthias Brugger , Yingjoe Chen , Dan Williams , linux-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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 2019-01-04 at 22:49 +0530, Vinod Koul wrote: > On 02-01-19, 10:12, Long Cheng wrote: > > In DMA engine framework, add 8250 uart dma to support MediaTek uart. > > If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve > > the performance, can enable the function. > > Is the DMA controller UART specific, can it work with other controllers > as well, if so you should get rid of uart name in patch > I don't know that it can work or not on other controller. but it's for MediaTek SOC > > +#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2) > > Why are the channels not coming from DT? > i will using dma-requests install of it. > > + > > +#define VFF_EN_B BIT(0) > > +#define VFF_STOP_B BIT(0) > > +#define VFF_FLUSH_B BIT(0) > > +#define VFF_4G_SUPPORT_B BIT(0) > > +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/ > > +#define VFF_RX_INT_EN1_B BIT(1) > > +#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/ > > space around /* space */ also run checkpatch to check for style errors > ok. > > +static void mtk_uart_apdma_start_tx(struct mtk_chan *c) > > +{ > > + unsigned int len, send, left, wpt, d_wpt, tmp; > > + int ret; > > + > > + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE); > > + if (!left) { > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + return; > > + } > > + > > + /* Wait 1sec for flush, can't sleep*/ > > + ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp, > > + tmp != VFF_FLUSH_B, 0, 1000000); > > + if (ret) > > + dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n", > > + mtk_uart_apdma_read(c, VFF_DEBUG_STATUS)); > > + > > + send = min_t(unsigned int, left, c->desc->avail_len); > > + wpt = mtk_uart_apdma_read(c, VFF_WPT); > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + > > + d_wpt = wpt + send; > > + if ((d_wpt & VFF_RING_SIZE) >= len) { > > + d_wpt = d_wpt - len; > > + d_wpt = d_wpt ^ VFF_RING_WRAP; > > + } > > + mtk_uart_apdma_write(c, VFF_WPT, d_wpt); > > + > > + c->desc->avail_len -= send; > > + > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + if (mtk_uart_apdma_read(c, VFF_FLUSH) == 0U) > > + mtk_uart_apdma_write(c, VFF_FLUSH, VFF_FLUSH_B); > > +} > > + > > +static void mtk_uart_apdma_start_rx(struct mtk_chan *c) > > +{ > > + struct mtk_uart_apdma_desc *d = c->desc; > > + unsigned int len, wg, rg, cnt; > > + > > + if ((mtk_uart_apdma_read(c, VFF_VALID_SIZE) == 0U) || > > + !d || !vchan_next_desc(&c->vc)) > > + return; > > + > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + rg = mtk_uart_apdma_read(c, VFF_RPT); > > + wg = mtk_uart_apdma_read(c, VFF_WPT); > > + if ((rg ^ wg) & VFF_RING_WRAP) > > + cnt = (wg & VFF_RING_SIZE) + len - (rg & VFF_RING_SIZE); > > + else > > + cnt = (wg & VFF_RING_SIZE) - (rg & VFF_RING_SIZE); > > + > > + c->rx_status = cnt; > > + mtk_uart_apdma_write(c, VFF_RPT, wg); > > + > > + list_del(&d->vd.node); > > + vchan_cookie_complete(&d->vd); > > +} > > this looks odd, why do you have different rx and tx start routines? > Would you like explain it in more detail? thanks. In tx function, will wait the last data flush done. and the count the size that send. In Rx function, will count the size that receive. Any way, in rx / tx, need andle WPT or RPT. > > +static int mtk_uart_apdma_alloc_chan_resources(struct dma_chan *chan) > > +{ > > + struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device); > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + u32 tmp; > > + int ret; > > + > > + pm_runtime_get_sync(mtkd->ddev.dev); > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, 0); > > + mtk_uart_apdma_write(c, VFF_THRE, 0); > > + mtk_uart_apdma_write(c, VFF_LEN, 0); > > + mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B); > > + > > + ret = readx_poll_timeout(readl, c->base + VFF_EN, tmp, > > + tmp == 0, 10, 100); > > + if (ret) { > > + dev_err(chan->device->dev, "dma reset: fail, timeout\n"); > > + return ret; > > + } > > register read does reset? > 'mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B);' is reset. resd just poll reset done. > > + > > + if (!c->requested) { > > + c->requested = true; > > + ret = request_irq(mtkd->dma_irq[chan->chan_id], > > + mtk_uart_apdma_irq_handler, IRQF_TRIGGER_NONE, > > + KBUILD_MODNAME, chan); > > why is the irq not requested in driver probe? > I have explained in below, http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan, > > + dma_cookie_t cookie, > > + struct dma_tx_state *txstate) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + enum dma_status ret; > > + unsigned long flags; > > + > > + if (!txstate) > > + return DMA_ERROR; > > + > > + ret = dma_cookie_status(chan, cookie, txstate); > > + spin_lock_irqsave(&c->vc.lock, flags); > > + if (ret == DMA_IN_PROGRESS) { > > + c->rx_status = mtk_uart_apdma_read(c, VFF_RPT) & VFF_RING_SIZE; > > + dma_set_residue(txstate, c->rx_status); > > + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) { > > why set reside when it is complete? also reside can be null, that should > be checked as well > In different status, set different reside. > > +static struct dma_async_tx_descriptor *mtk_uart_apdma_prep_slave_sg > > + (struct dma_chan *chan, struct scatterlist *sgl, > > + unsigned int sglen, enum dma_transfer_direction dir, > > + unsigned long tx_flags, void *context) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdma_desc *d; > > + > > + if ((dir != DMA_DEV_TO_MEM) && > > + (dir != DMA_MEM_TO_DEV)) { > > + dev_err(chan->device->dev, "bad direction\n"); > > + return NULL; > > + } > > we have a macro for this Thanks for your suggestion. i will modify it. > > > + > > + /* Now allocate and setup the descriptor */ > > + d = kzalloc(sizeof(*d), GFP_ATOMIC); > > + if (!d) > > + return NULL; > > + > > + /* sglen is 1 */ > > ? > > > +static int mtk_uart_apdma_slave_config(struct dma_chan *chan, > > + struct dma_slave_config *cfg) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdmadev *mtkd = > > + to_mtk_uart_apdma_dev(c->vc.chan.device); > > + > > + c->cfg = *cfg; > > + > > + if (cfg->direction == DMA_DEV_TO_MEM) { > > fg->direction is deprecated, in fact I have removed all users recently, > please do not use this You will remove 'direction' in 'struct dma_slave_config'? if remove, how do confirm direction? > > > + unsigned int rx_len = cfg->src_addr_width * 1024; > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, cfg->src_addr); > > + mtk_uart_apdma_write(c, VFF_LEN, rx_len); > > + mtk_uart_apdma_write(c, VFF_THRE, VFF_RX_THRE(rx_len)); > > + mtk_uart_apdma_write(c, VFF_INT_EN, > > + VFF_RX_INT_EN0_B | VFF_RX_INT_EN1_B); > > + mtk_uart_apdma_write(c, VFF_RPT, 0); > > + mtk_uart_apdma_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B); > > + mtk_uart_apdma_write(c, VFF_EN, VFF_EN_B); > > why are we writing this here, we are supposed to do that when txn > starts! > also you can review the link http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static int mtk_uart_apdma_device_resume(struct dma_chan *chan) > > +{ > > + /* just for check caps pass */ > > + return 0; > > +} > > if you do not support this please remove this! > > > +static void mtk_uart_apdma_free(struct mtk_uart_apdmadev *mtkd) > > +{ > > + while (list_empty(&mtkd->ddev.channels) == 0) { > > + struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels, > > + struct mtk_chan, vc.chan.device_node); > > + > > + list_del(&c->vc.chan.device_node); > > + tasklet_kill(&c->vc.task); > > + } > > +} > > + > > +static const struct of_device_id mtk_uart_apdma_match[] = { > > + { .compatible = "mediatek,mt6577-uart-dma", }, > > where is the binding document for ediatek,mt6577-uart-dma ?? > http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016154.html _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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,UNPARSEABLE_RELAY,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 67478C43387 for ; Thu, 10 Jan 2019 10:34:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37494214C6 for ; Thu, 10 Jan 2019 10:34:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728247AbfAJKeD (ORCPT ); Thu, 10 Jan 2019 05:34:03 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:28554 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728020AbfAJKeC (ORCPT ); Thu, 10 Jan 2019 05:34:02 -0500 X-UUID: 1290c1a8242e4a2f9b4b354ceb789b37-20190110 X-UUID: 1290c1a8242e4a2f9b4b354ceb789b37-20190110 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 176831677; Thu, 10 Jan 2019 18:33:55 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Jan 2019 18:33:53 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 10 Jan 2019 18:33:51 +0800 Message-ID: <1547116431.3831.43.camel@mhfsdcap03> Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support From: Long Cheng To: Vinod Koul CC: Randy Dunlap , Rob Herring , Mark Rutland , Ryder Lee , Sean Wang , Nicolas Boichat , Matthias Brugger , Dan Williams , Greg Kroah-Hartman , Jiri Slaby , Sean Wang , , , , , , , , Yingjoe Chen , YT Shen , Zhenbao Liu Date: Thu, 10 Jan 2019 18:33:51 +0800 In-Reply-To: <20190104171953.GQ13372@vkoul-mobl.Dlink> References: <1546395178-8880-1-git-send-email-long.cheng@mediatek.com> <1546395178-8880-2-git-send-email-long.cheng@mediatek.com> <20190104171953.GQ13372@vkoul-mobl.Dlink> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2019-01-04 at 22:49 +0530, Vinod Koul wrote: > On 02-01-19, 10:12, Long Cheng wrote: > > In DMA engine framework, add 8250 uart dma to support MediaTek uart. > > If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve > > the performance, can enable the function. > > Is the DMA controller UART specific, can it work with other controllers > as well, if so you should get rid of uart name in patch > I don't know that it can work or not on other controller. but it's for MediaTek SOC > > +#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2) > > Why are the channels not coming from DT? > i will using dma-requests install of it. > > + > > +#define VFF_EN_B BIT(0) > > +#define VFF_STOP_B BIT(0) > > +#define VFF_FLUSH_B BIT(0) > > +#define VFF_4G_SUPPORT_B BIT(0) > > +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/ > > +#define VFF_RX_INT_EN1_B BIT(1) > > +#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/ > > space around /* space */ also run checkpatch to check for style errors > ok. > > +static void mtk_uart_apdma_start_tx(struct mtk_chan *c) > > +{ > > + unsigned int len, send, left, wpt, d_wpt, tmp; > > + int ret; > > + > > + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE); > > + if (!left) { > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + return; > > + } > > + > > + /* Wait 1sec for flush, can't sleep*/ > > + ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp, > > + tmp != VFF_FLUSH_B, 0, 1000000); > > + if (ret) > > + dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n", > > + mtk_uart_apdma_read(c, VFF_DEBUG_STATUS)); > > + > > + send = min_t(unsigned int, left, c->desc->avail_len); > > + wpt = mtk_uart_apdma_read(c, VFF_WPT); > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + > > + d_wpt = wpt + send; > > + if ((d_wpt & VFF_RING_SIZE) >= len) { > > + d_wpt = d_wpt - len; > > + d_wpt = d_wpt ^ VFF_RING_WRAP; > > + } > > + mtk_uart_apdma_write(c, VFF_WPT, d_wpt); > > + > > + c->desc->avail_len -= send; > > + > > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > > + if (mtk_uart_apdma_read(c, VFF_FLUSH) == 0U) > > + mtk_uart_apdma_write(c, VFF_FLUSH, VFF_FLUSH_B); > > +} > > + > > +static void mtk_uart_apdma_start_rx(struct mtk_chan *c) > > +{ > > + struct mtk_uart_apdma_desc *d = c->desc; > > + unsigned int len, wg, rg, cnt; > > + > > + if ((mtk_uart_apdma_read(c, VFF_VALID_SIZE) == 0U) || > > + !d || !vchan_next_desc(&c->vc)) > > + return; > > + > > + len = mtk_uart_apdma_read(c, VFF_LEN); > > + rg = mtk_uart_apdma_read(c, VFF_RPT); > > + wg = mtk_uart_apdma_read(c, VFF_WPT); > > + if ((rg ^ wg) & VFF_RING_WRAP) > > + cnt = (wg & VFF_RING_SIZE) + len - (rg & VFF_RING_SIZE); > > + else > > + cnt = (wg & VFF_RING_SIZE) - (rg & VFF_RING_SIZE); > > + > > + c->rx_status = cnt; > > + mtk_uart_apdma_write(c, VFF_RPT, wg); > > + > > + list_del(&d->vd.node); > > + vchan_cookie_complete(&d->vd); > > +} > > this looks odd, why do you have different rx and tx start routines? > Would you like explain it in more detail? thanks. In tx function, will wait the last data flush done. and the count the size that send. In Rx function, will count the size that receive. Any way, in rx / tx, need andle WPT or RPT. > > +static int mtk_uart_apdma_alloc_chan_resources(struct dma_chan *chan) > > +{ > > + struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device); > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + u32 tmp; > > + int ret; > > + > > + pm_runtime_get_sync(mtkd->ddev.dev); > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, 0); > > + mtk_uart_apdma_write(c, VFF_THRE, 0); > > + mtk_uart_apdma_write(c, VFF_LEN, 0); > > + mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B); > > + > > + ret = readx_poll_timeout(readl, c->base + VFF_EN, tmp, > > + tmp == 0, 10, 100); > > + if (ret) { > > + dev_err(chan->device->dev, "dma reset: fail, timeout\n"); > > + return ret; > > + } > > register read does reset? > 'mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B);' is reset. resd just poll reset done. > > + > > + if (!c->requested) { > > + c->requested = true; > > + ret = request_irq(mtkd->dma_irq[chan->chan_id], > > + mtk_uart_apdma_irq_handler, IRQF_TRIGGER_NONE, > > + KBUILD_MODNAME, chan); > > why is the irq not requested in driver probe? > I have explained in below, http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan, > > + dma_cookie_t cookie, > > + struct dma_tx_state *txstate) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + enum dma_status ret; > > + unsigned long flags; > > + > > + if (!txstate) > > + return DMA_ERROR; > > + > > + ret = dma_cookie_status(chan, cookie, txstate); > > + spin_lock_irqsave(&c->vc.lock, flags); > > + if (ret == DMA_IN_PROGRESS) { > > + c->rx_status = mtk_uart_apdma_read(c, VFF_RPT) & VFF_RING_SIZE; > > + dma_set_residue(txstate, c->rx_status); > > + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) { > > why set reside when it is complete? also reside can be null, that should > be checked as well > In different status, set different reside. > > +static struct dma_async_tx_descriptor *mtk_uart_apdma_prep_slave_sg > > + (struct dma_chan *chan, struct scatterlist *sgl, > > + unsigned int sglen, enum dma_transfer_direction dir, > > + unsigned long tx_flags, void *context) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdma_desc *d; > > + > > + if ((dir != DMA_DEV_TO_MEM) && > > + (dir != DMA_MEM_TO_DEV)) { > > + dev_err(chan->device->dev, "bad direction\n"); > > + return NULL; > > + } > > we have a macro for this Thanks for your suggestion. i will modify it. > > > + > > + /* Now allocate and setup the descriptor */ > > + d = kzalloc(sizeof(*d), GFP_ATOMIC); > > + if (!d) > > + return NULL; > > + > > + /* sglen is 1 */ > > ? > > > +static int mtk_uart_apdma_slave_config(struct dma_chan *chan, > > + struct dma_slave_config *cfg) > > +{ > > + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan); > > + struct mtk_uart_apdmadev *mtkd = > > + to_mtk_uart_apdma_dev(c->vc.chan.device); > > + > > + c->cfg = *cfg; > > + > > + if (cfg->direction == DMA_DEV_TO_MEM) { > > fg->direction is deprecated, in fact I have removed all users recently, > please do not use this You will remove 'direction' in 'struct dma_slave_config'? if remove, how do confirm direction? > > > + unsigned int rx_len = cfg->src_addr_width * 1024; > > + > > + mtk_uart_apdma_write(c, VFF_ADDR, cfg->src_addr); > > + mtk_uart_apdma_write(c, VFF_LEN, rx_len); > > + mtk_uart_apdma_write(c, VFF_THRE, VFF_RX_THRE(rx_len)); > > + mtk_uart_apdma_write(c, VFF_INT_EN, > > + VFF_RX_INT_EN0_B | VFF_RX_INT_EN1_B); > > + mtk_uart_apdma_write(c, VFF_RPT, 0); > > + mtk_uart_apdma_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B); > > + mtk_uart_apdma_write(c, VFF_EN, VFF_EN_B); > > why are we writing this here, we are supposed to do that when txn > starts! > also you can review the link http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016418.html > > +static int mtk_uart_apdma_device_resume(struct dma_chan *chan) > > +{ > > + /* just for check caps pass */ > > + return 0; > > +} > > if you do not support this please remove this! > > > +static void mtk_uart_apdma_free(struct mtk_uart_apdmadev *mtkd) > > +{ > > + while (list_empty(&mtkd->ddev.channels) == 0) { > > + struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels, > > + struct mtk_chan, vc.chan.device_node); > > + > > + list_del(&c->vc.chan.device_node); > > + tasklet_kill(&c->vc.task); > > + } > > +} > > + > > +static const struct of_device_id mtk_uart_apdma_match[] = { > > + { .compatible = "mediatek,mt6577-uart-dma", }, > > where is the binding document for ediatek,mt6577-uart-dma ?? > http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016154.html