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: <1548058349.3831.71.camel@mhfsdcap03> Date: Mon, 21 Jan 2019 16:12:29 +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 , Long Cheng List-ID: T24gU3VuLCAyMDE5LTAxLTIwIGF0IDEwOjU3ICswNTMwLCBWaW5vZCBLb3VsIHdyb3RlOgo+IE9u IDEwLTAxLTE5LCAxODozMywgTG9uZyBDaGVuZyB3cm90ZToKPiA+IE9uIEZyaSwgMjAxOS0wMS0w NCBhdCAyMjo0OSArMDUzMCwgVmlub2QgS291bCB3cm90ZToKPiA+ID4gT24gMDItMDEtMTksIDEw OjEyLCBMb25nIENoZW5nIHdyb3RlOgo+ID4gPiA+IEluIERNQSBlbmdpbmUgZnJhbWV3b3JrLCBh ZGQgODI1MCB1YXJ0IGRtYSB0byBzdXBwb3J0IE1lZGlhVGVrIHVhcnQuCj4gPiA+ID4gSWYgTWVk aWFUZWsgdWFydCBlbmFibGVkKFNFUklBTF84MjUwX01UNjU3NyksIGFuZCB3YW50IHRvIGltcHJv dmUKPiA+ID4gPiB0aGUgcGVyZm9ybWFuY2UsIGNhbiBlbmFibGUgdGhlIGZ1bmN0aW9uLgo+ID4g PiAKPiA+ID4gSXMgdGhlIERNQSBjb250cm9sbGVyIFVBUlQgc3BlY2lmaWMsIGNhbiBpdCB3b3Jr IHdpdGggb3RoZXIgY29udHJvbGxlcnMKPiA+ID4gYXMgd2VsbCwgaWYgc28geW91IHNob3VsZCBn ZXQgcmlkIG9mIHVhcnQgbmFtZSBpbiBwYXRjaAo+ID4gCj4gPiBJIGRvbid0IGtub3cgdGhhdCBp dCBjYW4gd29yayBvciBub3Qgb24gb3RoZXIgY29udHJvbGxlci4gYnV0IGl0J3MgZm9yCj4gPiBN ZWRpYVRlayBTT0MKPiAKPiBXaGF0IEkgbWVhbnQgd2FzIHRoYXQgaWYgY2FuIHdvcmsgd2l0aCBv dGhlciBjb250cm9sbGVycyAodXNlcnMpIGFwYXJ0Cj4gZnJvbSBVQVJULCBob3cgYWJvdXQgc2F5 IGF1ZGlvLCBzcGkgZXRjISEKPiAKCml0J3MganVzdCBmb3IgVUFSVCBBUERNQS4gY2FuJ3Qgd29y ayBvbiBzcGkgLi4uCgo+ID4gCj4gPiA+ID4gKyNkZWZpbmUgTVRLX1VBUlRfQVBETUFfQ0hBTk5F TFMJCShDT05GSUdfU0VSSUFMXzgyNTBfTlJfVUFSVFMgKiAyKQo+ID4gPiAKPiA+ID4gV2h5IGFy ZSB0aGUgY2hhbm5lbHMgbm90IGNvbWluZyBmcm9tIERUPwo+ID4gPiAKPiA+IAo+ID4gaSB3aWxs IHVzaW5nIGRtYS1yZXF1ZXN0cyBpbnN0YWxsIG9mIGl0Lgo+ID4gCj4gPiA+ID4gKwo+ID4gPiA+ ICsjZGVmaW5lIFZGRl9FTl9CCQlCSVQoMCkKPiA+ID4gPiArI2RlZmluZSBWRkZfU1RPUF9CCQlC SVQoMCkKPiA+ID4gPiArI2RlZmluZSBWRkZfRkxVU0hfQgkJQklUKDApCj4gPiA+ID4gKyNkZWZp bmUgVkZGXzRHX1NVUFBPUlRfQglCSVQoMCkKPiA+ID4gPiArI2RlZmluZSBWRkZfUlhfSU5UX0VO MF9CCUJJVCgwKQkvKnJ4IHZhbGlkIHNpemUgPj0gIHZmZiB0aHJlKi8KPiA+ID4gPiArI2RlZmlu ZSBWRkZfUlhfSU5UX0VOMV9CCUJJVCgxKQo+ID4gPiA+ICsjZGVmaW5lIFZGRl9UWF9JTlRfRU5f QgkJQklUKDApCS8qdHggbGVmdCBzaXplID49IHZmZiB0aHJlKi8KPiA+ID4gCj4gPiA+IHNwYWNl IGFyb3VuZCAvKiBzcGFjZSAqLyBhbHNvIHJ1biBjaGVja3BhdGNoIHRvIGNoZWNrIGZvciBzdHls ZSBlcnJvcnMKPiA+ID4gCj4gPiAKPiA+IG9rLgo+ID4gCj4gPiA+ID4gK3N0YXRpYyB2b2lkIG10 a191YXJ0X2FwZG1hX3N0YXJ0X3R4KHN0cnVjdCBtdGtfY2hhbiAqYykKPiA+ID4gPiArewo+ID4g PiA+ICsJdW5zaWduZWQgaW50IGxlbiwgc2VuZCwgbGVmdCwgd3B0LCBkX3dwdCwgdG1wOwo+ID4g PiA+ICsJaW50IHJldDsKPiA+ID4gPiArCj4gPiA+ID4gKwlsZWZ0ID0gbXRrX3VhcnRfYXBkbWFf cmVhZChjLCBWRkZfTEVGVF9TSVpFKTsKPiA+ID4gPiArCWlmICghbGVmdCkgewo+ID4gPiA+ICsJ CW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9JTlRfRU4sIFZGRl9UWF9JTlRfRU5fQik7Cj4g PiA+ID4gKwkJcmV0dXJuOwo+ID4gPiA+ICsJfQo+ID4gPiA+ICsKPiA+ID4gPiArCS8qIFdhaXQg MXNlYyBmb3IgZmx1c2gsICBjYW4ndCBzbGVlcCovCj4gPiA+ID4gKwlyZXQgPSByZWFkeF9wb2xs X3RpbWVvdXQocmVhZGwsIGMtPmJhc2UgKyBWRkZfRkxVU0gsIHRtcCwKPiA+ID4gPiArCQkJdG1w ICE9IFZGRl9GTFVTSF9CLCAwLCAxMDAwMDAwKTsKPiA+ID4gPiArCWlmIChyZXQpCj4gPiA+ID4g KwkJZGV2X3dhcm4oYy0+dmMuY2hhbi5kZXZpY2UtPmRldiwgInR4OiBmYWlsLCBkZWJ1Zz0weCV4 XG4iLAo+ID4gPiA+ICsJCQltdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9ERUJVR19TVEFUVVMp KTsKPiA+ID4gPiArCj4gPiA+ID4gKwlzZW5kID0gbWluX3QodW5zaWduZWQgaW50LCBsZWZ0LCBj LT5kZXNjLT5hdmFpbF9sZW4pOwo+ID4gPiA+ICsJd3B0ID0gbXRrX3VhcnRfYXBkbWFfcmVhZChj LCBWRkZfV1BUKTsKPiA+ID4gPiArCWxlbiA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xF Tik7Cj4gPiA+ID4gKwo+ID4gPiA+ICsJZF93cHQgPSB3cHQgKyBzZW5kOwo+ID4gPiA+ICsJaWYg KChkX3dwdCAmIFZGRl9SSU5HX1NJWkUpID49IGxlbikgewo+ID4gPiA+ICsJCWRfd3B0ID0gZF93 cHQgLSBsZW47Cj4gPiA+ID4gKwkJZF93cHQgPSBkX3dwdCBeIFZGRl9SSU5HX1dSQVA7Cj4gPiA+ ID4gKwl9Cj4gPiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfV1BULCBkX3dwdCk7 Cj4gPiA+ID4gKwo+ID4gPiA+ICsJYy0+ZGVzYy0+YXZhaWxfbGVuIC09IHNlbmQ7Cj4gPiA+ID4g Kwo+ID4gPiA+ICsJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0lOVF9FTiwgVkZGX1RYX0lO VF9FTl9CKTsKPiA+ID4gPiArCWlmIChtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9GTFVTSCkg PT0gMFUpCj4gPiA+ID4gKwkJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0ZMVVNILCBWRkZf RkxVU0hfQik7Cj4gPiA+ID4gK30KPiA+ID4gPiArCj4gPiA+ID4gK3N0YXRpYyB2b2lkIG10a191 YXJ0X2FwZG1hX3N0YXJ0X3J4KHN0cnVjdCBtdGtfY2hhbiAqYykKPiA+ID4gPiArewo+ID4gPiA+ ICsJc3RydWN0IG10a191YXJ0X2FwZG1hX2Rlc2MgKmQgPSBjLT5kZXNjOwo+ID4gPiA+ICsJdW5z aWduZWQgaW50IGxlbiwgd2csIHJnLCBjbnQ7Cj4gPiA+ID4gKwo+ID4gPiA+ICsJaWYgKChtdGtf dWFydF9hcGRtYV9yZWFkKGMsIFZGRl9WQUxJRF9TSVpFKSA9PSAwVSkgfHwKPiA+ID4gPiArCQkh ZCB8fCAhdmNoYW5fbmV4dF9kZXNjKCZjLT52YykpCj4gPiA+ID4gKwkJcmV0dXJuOwo+ID4gPiA+ ICsKPiA+ID4gPiArCWxlbiA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xFTik7Cj4gPiA+ ID4gKwlyZyA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX1JQVCk7Cj4gPiA+ID4gKwl3ZyA9 IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX1dQVCk7Cj4gPiA+ID4gKwlpZiAoKHJnIF4gd2cp ICYgVkZGX1JJTkdfV1JBUCkKPiA+ID4gPiArCQljbnQgPSAod2cgJiBWRkZfUklOR19TSVpFKSAr IGxlbiAtIChyZyAmIFZGRl9SSU5HX1NJWkUpOwo+ID4gPiA+ICsJZWxzZQo+ID4gPiA+ICsJCWNu dCA9ICh3ZyAmIFZGRl9SSU5HX1NJWkUpIC0gKHJnICYgVkZGX1JJTkdfU0laRSk7Cj4gPiA+ID4g Kwo+ID4gPiA+ICsJYy0+cnhfc3RhdHVzID0gY250Owo+ID4gPiA+ICsJbXRrX3VhcnRfYXBkbWFf d3JpdGUoYywgVkZGX1JQVCwgd2cpOwo+ID4gPiA+ICsKPiA+ID4gPiArCWxpc3RfZGVsKCZkLT52 ZC5ub2RlKTsKPiA+ID4gPiArCXZjaGFuX2Nvb2tpZV9jb21wbGV0ZSgmZC0+dmQpOwo+ID4gPiA+ ICt9Cj4gPiA+IAo+ID4gPiB0aGlzIGxvb2tzIG9kZCwgd2h5IGRvIHlvdSBoYXZlIGRpZmZlcmVu dCByeCBhbmQgdHggc3RhcnQgcm91dGluZXM/Cj4gPiA+IAo+ID4gCj4gPiBXb3VsZCB5b3UgbGlr ZSBleHBsYWluIGl0IGluIG1vcmUgZGV0YWlsPyB0aGFua3MuCj4gPiBJbiB0eCBmdW5jdGlvbiwg d2lsbCB3YWl0IHRoZSBsYXN0IGRhdGEgZmx1c2ggZG9uZS4gYW5kIHRoZSBjb3VudCB0aGUKPiA+ IHNpemUgdGhhdCBzZW5kLgo+ID4gSW4gUnggZnVuY3Rpb24sIHdpbGwgY291bnQgdGhlIHNpemUg dGhhdCByZWNlaXZlLgo+ID4gQW55IHdheSwgaW4gcnggLyB0eCwgbmVlZCBhbmRsZSBXUFQgb3Ig UlBULgo+ID4gCj4gPiA+ID4gK3N0YXRpYyBpbnQgbXRrX3VhcnRfYXBkbWFfYWxsb2NfY2hhbl9y ZXNvdXJjZXMoc3RydWN0IGRtYV9jaGFuICpjaGFuKQo+ID4gPiA+ICt7Cj4gPiA+ID4gKwlzdHJ1 Y3QgbXRrX3VhcnRfYXBkbWFkZXYgKm10a2QgPSB0b19tdGtfdWFydF9hcGRtYV9kZXYoY2hhbi0+ ZGV2aWNlKTsKPiA+ID4gPiArCXN0cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2FwZG1h X2NoYW4oY2hhbik7Cj4gPiA+ID4gKwl1MzIgdG1wOwo+ID4gPiA+ICsJaW50IHJldDsKPiA+ID4g PiArCj4gPiA+ID4gKwlwbV9ydW50aW1lX2dldF9zeW5jKG10a2QtPmRkZXYuZGV2KTsKPiA+ID4g PiArCj4gPiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfQUREUiwgMCk7Cj4gPiA+ ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfVEhSRSwgMCk7Cj4gPiA+ID4gKwltdGtf dWFydF9hcGRtYV93cml0ZShjLCBWRkZfTEVOLCAwKTsKPiA+ID4gPiArCW10a191YXJ0X2FwZG1h X3dyaXRlKGMsIFZGRl9SU1QsIFZGRl9XQVJNX1JTVF9CKTsKPiA+ID4gPiArCj4gPiA+ID4gKwly ZXQgPSByZWFkeF9wb2xsX3RpbWVvdXQocmVhZGwsIGMtPmJhc2UgKyBWRkZfRU4sIHRtcCwKPiA+ ID4gPiArCQkJdG1wID09IDAsIDEwLCAxMDApOwo+ID4gPiA+ICsJaWYgKHJldCkgewo+ID4gPiA+ ICsJCWRldl9lcnIoY2hhbi0+ZGV2aWNlLT5kZXYsICJkbWEgcmVzZXQ6IGZhaWwsIHRpbWVvdXRc biIpOwo+ID4gPiA+ICsJCXJldHVybiByZXQ7Cj4gPiA+ID4gKwl9Cj4gPiA+IAo+ID4gPiByZWdp c3RlciByZWFkIGRvZXMgcmVzZXQ/Cj4gPiA+IAo+ID4gCj4gPiAnbXRrX3VhcnRfYXBkbWFfd3Jp dGUoYywgVkZGX1JTVCwgVkZGX1dBUk1fUlNUX0IpOycgaXMgcmVzZXQuIHJlc2QganVzdAo+ID4g cG9sbCByZXNldCBkb25lLgo+ID4gCj4gPiA+ID4gKwo+ID4gPiA+ICsJaWYgKCFjLT5yZXF1ZXN0 ZWQpIHsKPiA+ID4gPiArCQljLT5yZXF1ZXN0ZWQgPSB0cnVlOwo+ID4gPiA+ICsJCXJldCA9IHJl cXVlc3RfaXJxKG10a2QtPmRtYV9pcnFbY2hhbi0+Y2hhbl9pZF0sCj4gPiA+ID4gKwkJCQkgIG10 a191YXJ0X2FwZG1hX2lycV9oYW5kbGVyLCBJUlFGX1RSSUdHRVJfTk9ORSwKPiA+ID4gPiArCQkJ CSAgS0JVSUxEX01PRE5BTUUsIGNoYW4pOwo+ID4gPiAKPiA+ID4gd2h5IGlzIHRoZSBpcnEgbm90 IHJlcXVlc3RlZCBpbiBkcml2ZXIgcHJvYmU/Cj4gPiA+IAo+ID4gCj4gPiBJIGhhdmUgZXhwbGFp bmVkIGluIGJlbG93LAo+ID4gaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvcGlwZXJtYWlsL2xp bnV4LW1lZGlhdGVrLzIwMTgtRGVjZW1iZXIvMDE2NDE4Lmh0bWwKPiA+IAo+ID4gPiA+ICtzdGF0 aWMgZW51bSBkbWFfc3RhdHVzIG10a191YXJ0X2FwZG1hX3R4X3N0YXR1cyhzdHJ1Y3QgZG1hX2No YW4gKmNoYW4sCj4gPiA+ID4gKwkJCQkJIGRtYV9jb29raWVfdCBjb29raWUsCj4gPiA+ID4gKwkJ CQkJIHN0cnVjdCBkbWFfdHhfc3RhdGUgKnR4c3RhdGUpCj4gPiA+ID4gK3sKPiA+ID4gPiArCXN0 cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2FwZG1hX2NoYW4oY2hhbik7Cj4gPiA+ID4g KwllbnVtIGRtYV9zdGF0dXMgcmV0Owo+ID4gPiA+ICsJdW5zaWduZWQgbG9uZyBmbGFnczsKPiA+ ID4gPiArCj4gPiA+ID4gKwlpZiAoIXR4c3RhdGUpCj4gPiA+ID4gKwkJcmV0dXJuIERNQV9FUlJP UjsKPiA+ID4gPiArCj4gPiA+ID4gKwlyZXQgPSBkbWFfY29va2llX3N0YXR1cyhjaGFuLCBjb29r aWUsIHR4c3RhdGUpOwo+ID4gPiA+ICsJc3Bpbl9sb2NrX2lycXNhdmUoJmMtPnZjLmxvY2ssIGZs YWdzKTsKPiA+ID4gPiArCWlmIChyZXQgPT0gRE1BX0lOX1BST0dSRVNTKSB7Cj4gPiA+ID4gKwkJ Yy0+cnhfc3RhdHVzID0gbXRrX3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfUlBUKSAmIFZGRl9SSU5H X1NJWkU7Cj4gPiA+ID4gKwkJZG1hX3NldF9yZXNpZHVlKHR4c3RhdGUsIGMtPnJ4X3N0YXR1cyk7 Cj4gPiA+ID4gKwl9IGVsc2UgaWYgKHJldCA9PSBETUFfQ09NUExFVEUgJiYgYy0+Y2ZnLmRpcmVj dGlvbiA9PSBETUFfREVWX1RPX01FTSkgewo+ID4gPiAKPiA+ID4gd2h5IHNldCByZXNpZGUgd2hl biBpdCBpcyBjb21wbGV0ZT8gYWxzbyByZXNpZGUgY2FuIGJlIG51bGwsIHRoYXQgc2hvdWxkCj4g PiA+IGJlIGNoZWNrZWQgYXMgd2VsbAo+ID4gPiAKPiA+IEluIGRpZmZlcmVudCBzdGF0dXMsIHNl dCBkaWZmZXJlbnQgcmVzaWRlLgo+IAo+IENhbiB5b3UgZXhwbGFpbiB0aGF0Li4KPiAKClJQVCBp cyBkaWZmZXJlbnQgZXZlcnkgdGltZS4gV2hlbiBSWCBpbnRlcnJ1cHQgY29taW5nLCB1cGRhdGUg dGhlCnJ4X3N0YXR1cyBhbmQgbm90aWZ5IHVhcnQgdGhhdCB0aGVyZSBoYXZlIGRhdGEuIE9uZSB0 cmFuc2ZlciBpcwpjb21wbGV0ZS4gVWFydCB3aWxsIGNhbGwgdHhfc3RhdHVzIHRvIGdldCB0aGUg bGVuZ3RoIGF0IHRoZSB0aW1lIG9mCmludGVycnVwdGlvbi4gT3RoZXIgY2FzZSwgaWYgd2FudCB0 byBnZXQgdGhlIHR4X3N0YXR1cywgZGlyZWN0bHkgcmVhZApyZWdpc3Rlci4KCj4gPiAKPiA+ID4g PiArc3RhdGljIHN0cnVjdCBkbWFfYXN5bmNfdHhfZGVzY3JpcHRvciAqbXRrX3VhcnRfYXBkbWFf cHJlcF9zbGF2ZV9zZwo+ID4gPiA+ICsJKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwgc3RydWN0IHNj YXR0ZXJsaXN0ICpzZ2wsCj4gPiA+ID4gKwl1bnNpZ25lZCBpbnQgc2dsZW4sIGVudW0gZG1hX3Ry YW5zZmVyX2RpcmVjdGlvbiBkaXIsCj4gPiA+ID4gKwl1bnNpZ25lZCBsb25nIHR4X2ZsYWdzLCB2 b2lkICpjb250ZXh0KQo+ID4gPiA+ICt7Cj4gPiA+ID4gKwlzdHJ1Y3QgbXRrX2NoYW4gKmMgPSB0 b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4pOwo+ID4gPiA+ICsJc3RydWN0IG10a191YXJ0X2Fw ZG1hX2Rlc2MgKmQ7Cj4gPiA+ID4gKwo+ID4gPiA+ICsJaWYgKChkaXIgIT0gRE1BX0RFVl9UT19N RU0pICYmCj4gPiA+ID4gKwkJKGRpciAhPSBETUFfTUVNX1RPX0RFVikpIHsKPiA+ID4gPiArCQlk ZXZfZXJyKGNoYW4tPmRldmljZS0+ZGV2LCAiYmFkIGRpcmVjdGlvblxuIik7Cj4gPiA+ID4gKwkJ cmV0dXJuIE5VTEw7Cj4gPiA+ID4gKwl9Cj4gPiA+IAo+ID4gPiB3ZSBoYXZlIGEgbWFjcm8gZm9y IHRoaXMKPiA+IAo+ID4gVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIGkgd2lsbCBtb2RpZnkg aXQuCj4gPiA+IAo+ID4gPiA+ICsKPiA+ID4gPiArCS8qIE5vdyBhbGxvY2F0ZSBhbmQgc2V0dXAg dGhlIGRlc2NyaXB0b3IgKi8KPiA+ID4gPiArCWQgPSBremFsbG9jKHNpemVvZigqZCksIEdGUF9B VE9NSUMpOwo+ID4gPiA+ICsJaWYgKCFkKQo+ID4gPiA+ICsJCXJldHVybiBOVUxMOwo+ID4gPiA+ ICsKPiA+ID4gPiArCS8qIHNnbGVuIGlzIDEgKi8KPiA+ID4gCj4gPiA+ID8KCmRtYWVuZ2luZV9w cmVwX3NsYXZlX3NpbmdsZSBpcyBjYWxsZWQuIHRoZSBwYXJhbWV0ZXIgJ3NnbGVuJyBpcyAxLgpB ZGQgYW5ub3RhdGlvbiB0byBpbmRpY2F0ZSB0aGF0IHRoZSB0b3RhbCBsZW5ndGggaXMgc2dfZG1h X2xlbihzZ2wpLCBubwptb3JlLgoKPiA+ID4gCj4gPiA+ID4gK3N0YXRpYyBpbnQgbXRrX3VhcnRf YXBkbWFfc2xhdmVfY29uZmlnKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwKPiA+ID4gPiArCQkJCXN0 cnVjdCBkbWFfc2xhdmVfY29uZmlnICpjZmcpCj4gPiA+ID4gK3sKPiA+ID4gPiArCXN0cnVjdCBt dGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2FwZG1hX2NoYW4oY2hhbik7Cj4gPiA+ID4gKwlzdHJ1 Y3QgbXRrX3VhcnRfYXBkbWFkZXYgKm10a2QgPQo+ID4gPiA+ICsJCQkJdG9fbXRrX3VhcnRfYXBk bWFfZGV2KGMtPnZjLmNoYW4uZGV2aWNlKTsKPiA+ID4gPiArCj4gPiA+ID4gKwljLT5jZmcgPSAq Y2ZnOwo+ID4gPiA+ICsKPiA+ID4gPiArCWlmIChjZmctPmRpcmVjdGlvbiA9PSBETUFfREVWX1RP X01FTSkgewo+ID4gPiAKPiA+ID4gZmctPmRpcmVjdGlvbiBpcyBkZXByZWNhdGVkLCBpbiBmYWN0 IEkgaGF2ZSByZW1vdmVkIGFsbCB1c2VycyByZWNlbnRseSwKPiA+ID4gcGxlYXNlIGRvIG5vdCB1 c2UgdGhpcwo+ID4gCj4gPiBZb3Ugd2lsbCByZW1vdmUgJ2RpcmVjdGlvbicgaW4gJ3N0cnVjdCBk bWFfc2xhdmVfY29uZmlnJz8gaWYgcmVtb3ZlLCBob3cKPiA+IGRvIGNvbmZpcm0gZGlyZWN0aW9u Pwo+IAo+IFllcyBwbGVhc2UgdXNlIHRoZSBkaXJlY3Rpb24gYXJndW1lbnQgaW4gcHJlcF94eCBj YWxscwoKSSBoYWQgbW9kaWZpZWQgb24gdjEwLiB0aGFua3MuCg== 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: Mon, 21 Jan 2019 16:12:29 +0800 Message-ID: <1548058349.3831.71.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> <1547116431.3831.43.camel@mhfsdcap03> <20190120052750.GN4635@vkoul-mobl> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190120052750.GN4635@vkoul-mobl> 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 Sun, 2019-01-20 at 10:57 +0530, Vinod Koul wrote: > On 10-01-19, 18:33, Long Cheng wrote: > > 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 > > What I meant was that if can work with other controllers (users) apart > from UART, how about say audio, spi etc!! > it's just for UART APDMA. can't work on spi ... > > > > > > +#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. > > Can you explain that.. > RPT is different every time. When RX interrupt coming, update the rx_status and notify uart that there have data. One transfer is complete. Uart will call tx_status to get the length at the time of interruption. Other case, if want to get the tx_status, directly read register. > > > > > > +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 */ > > > > > > ? dmaengine_prep_slave_single is called. the parameter 'sglen' is 1. Add annotation to indicate that the total length is sg_dma_len(sgl), no more. > > > > > > > +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? > > Yes please use the direction argument in prep_xx calls I had modified on v10. thanks. 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=-2.1 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 1095CC282E9 for ; Mon, 21 Jan 2019 08:13:02 +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 C83A220855 for ; Mon, 21 Jan 2019 08:13:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UOU8+Fae" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C83A220855 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=JmSx4hE+7yyUpu5sxce9fgB47CM/46xdqBnDFywaThM=; b=UOU8+FaecSyN2L RGralGTZljho6cYTbA8m4o5qTVbMe7CqcORVLlsPgdTkzt3O1Y0NaNkhaxjQSIw7w+WZ24eVUmDGG j5XLK8aqV16JxJr+5CktUO09jmd5O7qzvFDj9b2MJe682LL7fXrFRWeiiLiRFg+Cl/yE1avApg6tT 4ltjlMwV5Wmdir0coHMuG7Ytw9apklFxjt4N0YVWtuVDtGUnLWypgQVTHmRYfDMwZ9Hx9qCx7cNk7 KW+QsUfQUBiZsuFLIkxbOfNvsBN0lXW2FXFIOjEb51ZSldiXpF/hXXtoud6xdzwsJL6Kzl2+Jtzp4 8U5uWwLDxzH46KYXGvoQ==; 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 1glUhW-0003V1-8k; Mon, 21 Jan 2019 08:12:58 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1glUhS-0003Tw-4p; Mon, 21 Jan 2019 08:12:56 +0000 X-UUID: 7a8b5582f8714b6abab29494fa305824-20190121 X-UUID: 7a8b5582f8714b6abab29494fa305824-20190121 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1444038887; Mon, 21 Jan 2019 00:12:46 -0800 Received: from mtkmbs08n1.mediatek.inc (172.21.101.55) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 21 Jan 2019 00:12:44 -0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 21 Jan 2019 16:12:30 +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; Mon, 21 Jan 2019 16:12:29 +0800 Message-ID: <1548058349.3831.71.camel@mhfsdcap03> Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support From: Long Cheng To: Vinod Koul Date: Mon, 21 Jan 2019 16:12:29 +0800 In-Reply-To: <20190120052750.GN4635@vkoul-mobl> 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> <1547116431.3831.43.camel@mhfsdcap03> <20190120052750.GN4635@vkoul-mobl> 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-20190121_001254_202644_7CB7E5E1 X-CRM114-Status: GOOD ( 28.48 ) 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 , Sean Wang , Ryder Lee , Zhenbao Liu , Nicolas Boichat , Long Cheng , linux-serial@vger.kernel.org, Jiri Slaby , YT Shen , Yingjoe Chen , devicetree@vger.kernel.org, Sean Wang , Rob Herring , linux-mediatek@lists.infradead.org, Matthias Brugger , Dan Williams , linux-arm-kernel@lists.infradead.org, srv_heupstream@mediatek.com, Greg Kroah-Hartman , Randy Dunlap , linux-kernel@vger.kernel.org, dmaengine@vger.kernel.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 Sun, 2019-01-20 at 10:57 +0530, Vinod Koul wrote: > On 10-01-19, 18:33, Long Cheng wrote: > > 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 > > What I meant was that if can work with other controllers (users) apart > from UART, how about say audio, spi etc!! > it's just for UART APDMA. can't work on spi ... > > > > > > +#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. > > Can you explain that.. > RPT is different every time. When RX interrupt coming, update the rx_status and notify uart that there have data. One transfer is complete. Uart will call tx_status to get the length at the time of interruption. Other case, if want to get the tx_status, directly read register. > > > > > > +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 */ > > > > > > ? dmaengine_prep_slave_single is called. the parameter 'sglen' is 1. Add annotation to indicate that the total length is sg_dma_len(sgl), no more. > > > > > > > +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? > > Yes please use the direction argument in prep_xx calls I had modified on v10. thanks. _______________________________________________ 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 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 095D9C282E9 for ; Mon, 21 Jan 2019 08:12:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C051020855 for ; Mon, 21 Jan 2019 08:12:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728984AbfAUIMj (ORCPT ); Mon, 21 Jan 2019 03:12:39 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:6480 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727586AbfAUIMj (ORCPT ); Mon, 21 Jan 2019 03:12:39 -0500 X-UUID: f9acef22d8db4c23a214033ce0dabd5c-20190121 X-UUID: f9acef22d8db4c23a214033ce0dabd5c-20190121 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1284884868; Mon, 21 Jan 2019 16:12:32 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 21 Jan 2019 16:12:30 +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; Mon, 21 Jan 2019 16:12:29 +0800 Message-ID: <1548058349.3831.71.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 , Long Cheng Date: Mon, 21 Jan 2019 16:12:29 +0800 In-Reply-To: <20190120052750.GN4635@vkoul-mobl> 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> <1547116431.3831.43.camel@mhfsdcap03> <20190120052750.GN4635@vkoul-mobl> 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 Sun, 2019-01-20 at 10:57 +0530, Vinod Koul wrote: > On 10-01-19, 18:33, Long Cheng wrote: > > 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 > > What I meant was that if can work with other controllers (users) apart > from UART, how about say audio, spi etc!! > it's just for UART APDMA. can't work on spi ... > > > > > > +#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. > > Can you explain that.. > RPT is different every time. When RX interrupt coming, update the rx_status and notify uart that there have data. One transfer is complete. Uart will call tx_status to get the length at the time of interruption. Other case, if want to get the tx_status, directly read register. > > > > > > +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 */ > > > > > > ? dmaengine_prep_slave_single is called. the parameter 'sglen' is 1. Add annotation to indicate that the total length is sg_dma_len(sgl), no more. > > > > > > > +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? > > Yes please use the direction argument in prep_xx calls I had modified on v10. thanks.