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: <1547169522.3831.47.camel@mhfsdcap03> Date: Fri, 11 Jan 2019 09:18:42 +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: T24gVGh1LCAyMDE5LTAxLTEwIGF0IDE4OjMzICswODAwLCBMb25nIENoZW5nIHdyb3RlOgpmaXgg c3BlbGwgZXJyb3IKCj4gT24gRnJpLCAyMDE5LTAxLTA0IGF0IDIyOjQ5ICswNTMwLCBWaW5vZCBL b3VsIHdyb3RlOgo+ID4gT24gMDItMDEtMTksIDEwOjEyLCBMb25nIENoZW5nIHdyb3RlOgo+ID4g PiBJbiBETUEgZW5naW5lIGZyYW1ld29yaywgYWRkIDgyNTAgdWFydCBkbWEgdG8gc3VwcG9ydCBN ZWRpYVRlayB1YXJ0Lgo+ID4gPiBJZiBNZWRpYVRlayB1YXJ0IGVuYWJsZWQoU0VSSUFMXzgyNTBf TVQ2NTc3KSwgYW5kIHdhbnQgdG8gaW1wcm92ZQo+ID4gPiB0aGUgcGVyZm9ybWFuY2UsIGNhbiBl bmFibGUgdGhlIGZ1bmN0aW9uLgo+ID4gCj4gPiBJcyB0aGUgRE1BIGNvbnRyb2xsZXIgVUFSVCBz cGVjaWZpYywgY2FuIGl0IHdvcmsgd2l0aCBvdGhlciBjb250cm9sbGVycwo+ID4gYXMgd2VsbCwg aWYgc28geW91IHNob3VsZCBnZXQgcmlkIG9mIHVhcnQgbmFtZSBpbiBwYXRjaAo+ID4gCj4gCj4g SSBkb24ndCBrbm93IHRoYXQgaXQgY2FuIHdvcmsgb3Igbm90IG9uIG90aGVyIGNvbnRyb2xsZXIu IGJ1dCBpdCdzIGZvcgo+IE1lZGlhVGVrIFNPQwo+IAo+ID4gPiArI2RlZmluZSBNVEtfVUFSVF9B UERNQV9DSEFOTkVMUwkJKENPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUyAqIDIpCj4gPiAKPiA+ IFdoeSBhcmUgdGhlIGNoYW5uZWxzIG5vdCBjb21pbmcgZnJvbSBEVD8KPiA+IAo+IAo+IGkgd2ls bCB1c2luZyBkbWEtcmVxdWVzdHMgaW5zdGFsbCBvZiBpdC4KPiAKaSB3aWxsIHVzaW5nICdkbWEt cmVxdWVzdHMnIGluc3RlYWQgb2YgaXQuCgo+ID4gPiArCj4gPiA+ICsjZGVmaW5lIFZGRl9FTl9C CQlCSVQoMCkKPiA+ID4gKyNkZWZpbmUgVkZGX1NUT1BfQgkJQklUKDApCj4gPiA+ICsjZGVmaW5l IFZGRl9GTFVTSF9CCQlCSVQoMCkKPiA+ID4gKyNkZWZpbmUgVkZGXzRHX1NVUFBPUlRfQglCSVQo MCkKPiA+ID4gKyNkZWZpbmUgVkZGX1JYX0lOVF9FTjBfQglCSVQoMCkJLypyeCB2YWxpZCBzaXpl ID49ICB2ZmYgdGhyZSovCj4gPiA+ICsjZGVmaW5lIFZGRl9SWF9JTlRfRU4xX0IJQklUKDEpCj4g PiA+ICsjZGVmaW5lIFZGRl9UWF9JTlRfRU5fQgkJQklUKDApCS8qdHggbGVmdCBzaXplID49IHZm ZiB0aHJlKi8KPiA+IAo+ID4gc3BhY2UgYXJvdW5kIC8qIHNwYWNlICovIGFsc28gcnVuIGNoZWNr cGF0Y2ggdG8gY2hlY2sgZm9yIHN0eWxlIGVycm9ycwo+ID4gCj4gCj4gb2suCj4gCj4gPiA+ICtz dGF0aWMgdm9pZCBtdGtfdWFydF9hcGRtYV9zdGFydF90eChzdHJ1Y3QgbXRrX2NoYW4gKmMpCj4g PiA+ICt7Cj4gPiA+ICsJdW5zaWduZWQgaW50IGxlbiwgc2VuZCwgbGVmdCwgd3B0LCBkX3dwdCwg dG1wOwo+ID4gPiArCWludCByZXQ7Cj4gPiA+ICsKPiA+ID4gKwlsZWZ0ID0gbXRrX3VhcnRfYXBk bWFfcmVhZChjLCBWRkZfTEVGVF9TSVpFKTsKPiA+ID4gKwlpZiAoIWxlZnQpIHsKPiA+ID4gKwkJ bXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0lOVF9FTiwgVkZGX1RYX0lOVF9FTl9CKTsKPiA+ ID4gKwkJcmV0dXJuOwo+ID4gPiArCX0KPiA+ID4gKwo+ID4gPiArCS8qIFdhaXQgMXNlYyBmb3Ig Zmx1c2gsICBjYW4ndCBzbGVlcCovCj4gPiA+ICsJcmV0ID0gcmVhZHhfcG9sbF90aW1lb3V0KHJl YWRsLCBjLT5iYXNlICsgVkZGX0ZMVVNILCB0bXAsCj4gPiA+ICsJCQl0bXAgIT0gVkZGX0ZMVVNI X0IsIDAsIDEwMDAwMDApOwo+ID4gPiArCWlmIChyZXQpCj4gPiA+ICsJCWRldl93YXJuKGMtPnZj LmNoYW4uZGV2aWNlLT5kZXYsICJ0eDogZmFpbCwgZGVidWc9MHgleFxuIiwKPiA+ID4gKwkJCW10 a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0RFQlVHX1NUQVRVUykpOwo+ID4gPiArCj4gPiA+ICsJ c2VuZCA9IG1pbl90KHVuc2lnbmVkIGludCwgbGVmdCwgYy0+ZGVzYy0+YXZhaWxfbGVuKTsKPiA+ ID4gKwl3cHQgPSBtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9XUFQpOwo+ID4gPiArCWxlbiA9 IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xFTik7Cj4gPiA+ICsKPiA+ID4gKwlkX3dwdCA9 IHdwdCArIHNlbmQ7Cj4gPiA+ICsJaWYgKChkX3dwdCAmIFZGRl9SSU5HX1NJWkUpID49IGxlbikg ewo+ID4gPiArCQlkX3dwdCA9IGRfd3B0IC0gbGVuOwo+ID4gPiArCQlkX3dwdCA9IGRfd3B0IF4g VkZGX1JJTkdfV1JBUDsKPiA+ID4gKwl9Cj4gPiA+ICsJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywg VkZGX1dQVCwgZF93cHQpOwo+ID4gPiArCj4gPiA+ICsJYy0+ZGVzYy0+YXZhaWxfbGVuIC09IHNl bmQ7Cj4gPiA+ICsKPiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfSU5UX0VOLCBW RkZfVFhfSU5UX0VOX0IpOwo+ID4gPiArCWlmIChtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9G TFVTSCkgPT0gMFUpCj4gPiA+ICsJCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9GTFVTSCwg VkZGX0ZMVVNIX0IpOwo+ID4gPiArfQo+ID4gPiArCj4gPiA+ICtzdGF0aWMgdm9pZCBtdGtfdWFy dF9hcGRtYV9zdGFydF9yeChzdHJ1Y3QgbXRrX2NoYW4gKmMpCj4gPiA+ICt7Cj4gPiA+ICsJc3Ry dWN0IG10a191YXJ0X2FwZG1hX2Rlc2MgKmQgPSBjLT5kZXNjOwo+ID4gPiArCXVuc2lnbmVkIGlu dCBsZW4sIHdnLCByZywgY250Owo+ID4gPiArCj4gPiA+ICsJaWYgKChtdGtfdWFydF9hcGRtYV9y ZWFkKGMsIFZGRl9WQUxJRF9TSVpFKSA9PSAwVSkgfHwKPiA+ID4gKwkJIWQgfHwgIXZjaGFuX25l eHRfZGVzYygmYy0+dmMpKQo+ID4gPiArCQlyZXR1cm47Cj4gPiA+ICsKPiA+ID4gKwlsZW4gPSBt dGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9MRU4pOwo+ID4gPiArCXJnID0gbXRrX3VhcnRfYXBk bWFfcmVhZChjLCBWRkZfUlBUKTsKPiA+ID4gKwl3ZyA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywg VkZGX1dQVCk7Cj4gPiA+ICsJaWYgKChyZyBeIHdnKSAmIFZGRl9SSU5HX1dSQVApCj4gPiA+ICsJ CWNudCA9ICh3ZyAmIFZGRl9SSU5HX1NJWkUpICsgbGVuIC0gKHJnICYgVkZGX1JJTkdfU0laRSk7 Cj4gPiA+ICsJZWxzZQo+ID4gPiArCQljbnQgPSAod2cgJiBWRkZfUklOR19TSVpFKSAtIChyZyAm IFZGRl9SSU5HX1NJWkUpOwo+ID4gPiArCj4gPiA+ICsJYy0+cnhfc3RhdHVzID0gY250Owo+ID4g PiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9SUFQsIHdnKTsKPiA+ID4gKwo+ID4gPiAr CWxpc3RfZGVsKCZkLT52ZC5ub2RlKTsKPiA+ID4gKwl2Y2hhbl9jb29raWVfY29tcGxldGUoJmQt PnZkKTsKPiA+ID4gK30KPiA+IAo+ID4gdGhpcyBsb29rcyBvZGQsIHdoeSBkbyB5b3UgaGF2ZSBk aWZmZXJlbnQgcnggYW5kIHR4IHN0YXJ0IHJvdXRpbmVzPwo+ID4gCj4gCj4gV291bGQgeW91IGxp a2UgZXhwbGFpbiBpdCBpbiBtb3JlIGRldGFpbD8gdGhhbmtzLgo+IEluIHR4IGZ1bmN0aW9uLCB3 aWxsIHdhaXQgdGhlIGxhc3QgZGF0YSBmbHVzaCBkb25lLiBhbmQgdGhlIGNvdW50IHRoZQo+IHNp emUgdGhhdCBzZW5kLgo+IEluIFJ4IGZ1bmN0aW9uLCB3aWxsIGNvdW50IHRoZSBzaXplIHRoYXQg cmVjZWl2ZS4KPiBBbnkgd2F5LCBpbiByeCAvIHR4LCBuZWVkIGFuZGxlIFdQVCBvciBSUFQuCj4g CkFueSB3YXksIGluIHJ4IC8gdHgsIG5lZWQgaGFuZGxlIFdQVCBvciBSUFQuCgo+ID4gPiArc3Rh dGljIGludCBtdGtfdWFydF9hcGRtYV9hbGxvY19jaGFuX3Jlc291cmNlcyhzdHJ1Y3QgZG1hX2No YW4gKmNoYW4pCj4gPiA+ICt7Cj4gPiA+ICsJc3RydWN0IG10a191YXJ0X2FwZG1hZGV2ICptdGtk ID0gdG9fbXRrX3VhcnRfYXBkbWFfZGV2KGNoYW4tPmRldmljZSk7Cj4gPiA+ICsJc3RydWN0IG10 a19jaGFuICpjID0gdG9fbXRrX3VhcnRfYXBkbWFfY2hhbihjaGFuKTsKPiA+ID4gKwl1MzIgdG1w Owo+ID4gPiArCWludCByZXQ7Cj4gPiA+ICsKPiA+ID4gKwlwbV9ydW50aW1lX2dldF9zeW5jKG10 a2QtPmRkZXYuZGV2KTsKPiA+ID4gKwo+ID4gPiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZG Rl9BRERSLCAwKTsKPiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfVEhSRSwgMCk7 Cj4gPiA+ICsJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0xFTiwgMCk7Cj4gPiA+ICsJbXRr X3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX1JTVCwgVkZGX1dBUk1fUlNUX0IpOwo+ID4gPiArCj4g PiA+ICsJcmV0ID0gcmVhZHhfcG9sbF90aW1lb3V0KHJlYWRsLCBjLT5iYXNlICsgVkZGX0VOLCB0 bXAsCj4gPiA+ICsJCQl0bXAgPT0gMCwgMTAsIDEwMCk7Cj4gPiA+ICsJaWYgKHJldCkgewo+ID4g PiArCQlkZXZfZXJyKGNoYW4tPmRldmljZS0+ZGV2LCAiZG1hIHJlc2V0OiBmYWlsLCB0aW1lb3V0 XG4iKTsKPiA+ID4gKwkJcmV0dXJuIHJldDsKPiA+ID4gKwl9Cj4gPiAKPiA+IHJlZ2lzdGVyIHJl YWQgZG9lcyByZXNldD8KPiA+IAo+IAo+ICdtdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfUlNU LCBWRkZfV0FSTV9SU1RfQik7JyBpcyByZXNldC4gcmVzZCBqdXN0Cj4gcG9sbCByZXNldCBkb25l Lgo+IAo+ID4gPiArCj4gPiA+ICsJaWYgKCFjLT5yZXF1ZXN0ZWQpIHsKPiA+ID4gKwkJYy0+cmVx dWVzdGVkID0gdHJ1ZTsKPiA+ID4gKwkJcmV0ID0gcmVxdWVzdF9pcnEobXRrZC0+ZG1hX2lycVtj aGFuLT5jaGFuX2lkXSwKPiA+ID4gKwkJCQkgIG10a191YXJ0X2FwZG1hX2lycV9oYW5kbGVyLCBJ UlFGX1RSSUdHRVJfTk9ORSwKPiA+ID4gKwkJCQkgIEtCVUlMRF9NT0ROQU1FLCBjaGFuKTsKPiA+ IAo+ID4gd2h5IGlzIHRoZSBpcnEgbm90IHJlcXVlc3RlZCBpbiBkcml2ZXIgcHJvYmU/Cj4gPiAK PiAKPiBJIGhhdmUgZXhwbGFpbmVkIGluIGJlbG93LAo+IGh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL3BpcGVybWFpbC9saW51eC1tZWRpYXRlay8yMDE4LURlY2VtYmVyLzAxNjQxOC5odG1sCj4g Cj4gPiA+ICtzdGF0aWMgZW51bSBkbWFfc3RhdHVzIG10a191YXJ0X2FwZG1hX3R4X3N0YXR1cyhz dHJ1Y3QgZG1hX2NoYW4gKmNoYW4sCj4gPiA+ICsJCQkJCSBkbWFfY29va2llX3QgY29va2llLAo+ ID4gPiArCQkJCQkgc3RydWN0IGRtYV90eF9zdGF0ZSAqdHhzdGF0ZSkKPiA+ID4gK3sKPiA+ID4g KwlzdHJ1Y3QgbXRrX2NoYW4gKmMgPSB0b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4pOwo+ID4g PiArCWVudW0gZG1hX3N0YXR1cyByZXQ7Cj4gPiA+ICsJdW5zaWduZWQgbG9uZyBmbGFnczsKPiA+ ID4gKwo+ID4gPiArCWlmICghdHhzdGF0ZSkKPiA+ID4gKwkJcmV0dXJuIERNQV9FUlJPUjsKPiA+ ID4gKwo+ID4gPiArCXJldCA9IGRtYV9jb29raWVfc3RhdHVzKGNoYW4sIGNvb2tpZSwgdHhzdGF0 ZSk7Cj4gPiA+ICsJc3Bpbl9sb2NrX2lycXNhdmUoJmMtPnZjLmxvY2ssIGZsYWdzKTsKPiA+ID4g KwlpZiAocmV0ID09IERNQV9JTl9QUk9HUkVTUykgewo+ID4gPiArCQljLT5yeF9zdGF0dXMgPSBt dGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9SUFQpICYgVkZGX1JJTkdfU0laRTsKPiA+ID4gKwkJ ZG1hX3NldF9yZXNpZHVlKHR4c3RhdGUsIGMtPnJ4X3N0YXR1cyk7Cj4gPiA+ICsJfSBlbHNlIGlm IChyZXQgPT0gRE1BX0NPTVBMRVRFICYmIGMtPmNmZy5kaXJlY3Rpb24gPT0gRE1BX0RFVl9UT19N RU0pIHsKPiA+IAo+ID4gd2h5IHNldCByZXNpZGUgd2hlbiBpdCBpcyBjb21wbGV0ZT8gYWxzbyBy ZXNpZGUgY2FuIGJlIG51bGwsIHRoYXQgc2hvdWxkCj4gPiBiZSBjaGVja2VkIGFzIHdlbGwKPiA+ IAo+IEluIGRpZmZlcmVudCBzdGF0dXMsIHNldCBkaWZmZXJlbnQgcmVzaWRlLgo+IAo+ID4gPiAr c3RhdGljIHN0cnVjdCBkbWFfYXN5bmNfdHhfZGVzY3JpcHRvciAqbXRrX3VhcnRfYXBkbWFfcHJl cF9zbGF2ZV9zZwo+ID4gPiArCShzdHJ1Y3QgZG1hX2NoYW4gKmNoYW4sIHN0cnVjdCBzY2F0dGVy bGlzdCAqc2dsLAo+ID4gPiArCXVuc2lnbmVkIGludCBzZ2xlbiwgZW51bSBkbWFfdHJhbnNmZXJf ZGlyZWN0aW9uIGRpciwKPiA+ID4gKwl1bnNpZ25lZCBsb25nIHR4X2ZsYWdzLCB2b2lkICpjb250 ZXh0KQo+ID4gPiArewo+ID4gPiArCXN0cnVjdCBtdGtfY2hhbiAqYyA9IHRvX210a191YXJ0X2Fw ZG1hX2NoYW4oY2hhbik7Cj4gPiA+ICsJc3RydWN0IG10a191YXJ0X2FwZG1hX2Rlc2MgKmQ7Cj4g PiA+ICsKPiA+ID4gKwlpZiAoKGRpciAhPSBETUFfREVWX1RPX01FTSkgJiYKPiA+ID4gKwkJKGRp ciAhPSBETUFfTUVNX1RPX0RFVikpIHsKPiA+ID4gKwkJZGV2X2VycihjaGFuLT5kZXZpY2UtPmRl diwgImJhZCBkaXJlY3Rpb25cbiIpOwo+ID4gPiArCQlyZXR1cm4gTlVMTDsKPiA+ID4gKwl9Cj4g PiAKPiA+IHdlIGhhdmUgYSBtYWNybyBmb3IgdGhpcwo+IAo+IFRoYW5rcyBmb3IgeW91ciBzdWdn ZXN0aW9uLiBpIHdpbGwgbW9kaWZ5IGl0Lgo+ID4gCj4gPiA+ICsKPiA+ID4gKwkvKiBOb3cgYWxs b2NhdGUgYW5kIHNldHVwIHRoZSBkZXNjcmlwdG9yICovCj4gPiA+ICsJZCA9IGt6YWxsb2Moc2l6 ZW9mKCpkKSwgR0ZQX0FUT01JQyk7Cj4gPiA+ICsJaWYgKCFkKQo+ID4gPiArCQlyZXR1cm4gTlVM TDsKPiA+ID4gKwo+ID4gPiArCS8qIHNnbGVuIGlzIDEgKi8KPiA+IAo+ID4gPwo+ID4gCj4gPiA+ ICtzdGF0aWMgaW50IG10a191YXJ0X2FwZG1hX3NsYXZlX2NvbmZpZyhzdHJ1Y3QgZG1hX2NoYW4g KmNoYW4sCj4gPiA+ICsJCQkJc3RydWN0IGRtYV9zbGF2ZV9jb25maWcgKmNmZykKPiA+ID4gK3sK PiA+ID4gKwlzdHJ1Y3QgbXRrX2NoYW4gKmMgPSB0b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4p Owo+ID4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRtYWRldiAqbXRrZCA9Cj4gPiA+ICsJCQkJdG9f bXRrX3VhcnRfYXBkbWFfZGV2KGMtPnZjLmNoYW4uZGV2aWNlKTsKPiA+ID4gKwo+ID4gPiArCWMt PmNmZyA9ICpjZmc7Cj4gPiA+ICsKPiA+ID4gKwlpZiAoY2ZnLT5kaXJlY3Rpb24gPT0gRE1BX0RF Vl9UT19NRU0pIHsKPiA+IAo+ID4gZmctPmRpcmVjdGlvbiBpcyBkZXByZWNhdGVkLCBpbiBmYWN0 IEkgaGF2ZSByZW1vdmVkIGFsbCB1c2VycyByZWNlbnRseSwKPiA+IHBsZWFzZSBkbyBub3QgdXNl IHRoaXMKPiAKPiBZb3Ugd2lsbCByZW1vdmUgJ2RpcmVjdGlvbicgaW4gJ3N0cnVjdCBkbWFfc2xh dmVfY29uZmlnJz8gaWYgcmVtb3ZlLCBob3cKPiBkbyBjb25maXJtIGRpcmVjdGlvbj8KPiAKPiA+ IAo+ID4gPiArCQl1bnNpZ25lZCBpbnQgcnhfbGVuID0gY2ZnLT5zcmNfYWRkcl93aWR0aCAqIDEw MjQ7Cj4gPiA+ICsKPiA+ID4gKwkJbXRrX3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0FERFIsIGNm Zy0+c3JjX2FkZHIpOwo+ID4gPiArCQltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfTEVOLCBy eF9sZW4pOwo+ID4gPiArCQltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfVEhSRSwgVkZGX1JY X1RIUkUocnhfbGVuKSk7Cj4gPiA+ICsJCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9JTlRf RU4sCj4gPiA+ICsJCQkJVkZGX1JYX0lOVF9FTjBfQiB8IFZGRl9SWF9JTlRfRU4xX0IpOwo+ID4g PiArCQltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfUlBULCAwKTsKPiA+ID4gKwkJbXRrX3Vh cnRfYXBkbWFfd3JpdGUoYywgVkZGX0lOVF9GTEFHLCBWRkZfUlhfSU5UX0ZMQUdfQ0xSX0IpOwo+ ID4gPiArCQltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfRU4sIFZGRl9FTl9CKTsKPiA+IAo+ ID4gd2h5IGFyZSB3ZSB3cml0aW5nIHRoaXMgaGVyZSwgd2UgYXJlIHN1cHBvc2VkIHRvIGRvIHRo YXQgd2hlbiB0eG4KPiA+IHN0YXJ0cyEKPiA+IAo+IAo+IGFsc28geW91IGNhbiByZXZpZXcgdGhl IGxpbmsKPiBodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1haWwvbGludXgtbWVkaWF0 ZWsvMjAxOC1EZWNlbWJlci8wMTY0MTguaHRtbAo+IAo+ID4gPiArc3RhdGljIGludCBtdGtfdWFy dF9hcGRtYV9kZXZpY2VfcmVzdW1lKHN0cnVjdCBkbWFfY2hhbiAqY2hhbikKPiA+ID4gK3sKPiA+ ID4gKwkvKiBqdXN0IGZvciBjaGVjayBjYXBzIHBhc3MgKi8KPiA+ID4gKwlyZXR1cm4gMDsKPiA+ ID4gK30KPiA+IAo+ID4gaWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoaXMgcGxlYXNlIHJlbW92ZSB0 aGlzIQo+ID4gCj4gPiA+ICtzdGF0aWMgdm9pZCBtdGtfdWFydF9hcGRtYV9mcmVlKHN0cnVjdCBt dGtfdWFydF9hcGRtYWRldiAqbXRrZCkKPiA+ID4gK3sKPiA+ID4gKwl3aGlsZSAobGlzdF9lbXB0 eSgmbXRrZC0+ZGRldi5jaGFubmVscykgPT0gMCkgewo+ID4gPiArCQlzdHJ1Y3QgbXRrX2NoYW4g KmMgPSBsaXN0X2ZpcnN0X2VudHJ5KCZtdGtkLT5kZGV2LmNoYW5uZWxzLAo+ID4gPiArCQkJc3Ry dWN0IG10a19jaGFuLCB2Yy5jaGFuLmRldmljZV9ub2RlKTsKPiA+ID4gKwo+ID4gPiArCQlsaXN0 X2RlbCgmYy0+dmMuY2hhbi5kZXZpY2Vfbm9kZSk7Cj4gPiA+ICsJCXRhc2tsZXRfa2lsbCgmYy0+ dmMudGFzayk7Cj4gPiA+ICsJfQo+ID4gPiArfQo+ID4gPiArCj4gPiA+ICtzdGF0aWMgY29uc3Qg c3RydWN0IG9mX2RldmljZV9pZCBtdGtfdWFydF9hcGRtYV9tYXRjaFtdID0gewo+ID4gPiArCXsg LmNvbXBhdGlibGUgPSAibWVkaWF0ZWssbXQ2NTc3LXVhcnQtZG1hIiwgfSwKPiA+IAo+ID4gd2hl cmUgaXMgdGhlIGJpbmRpbmcgZG9jdW1lbnQgZm9yIGVkaWF0ZWssbXQ2NTc3LXVhcnQtZG1hID8/ Cj4gPiAKPiAKPiBodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1haWwvbGludXgtbWVk aWF0ZWsvMjAxOC1EZWNlbWJlci8wMTYxNTQuaHRtbAo+Cg== 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: Fri, 11 Jan 2019 09:18:42 +0800 Message-ID: <1547169522.3831.47.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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1547116431.3831.43.camel@mhfsdcap03> 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 Thu, 2019-01-10 at 18:33 +0800, Long Cheng wrote: fix spell error > 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. > i will using 'dma-requests' instead 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. > Any way, in rx / tx, need handle 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 205FFC43387 for ; Fri, 11 Jan 2019 01:19:20 +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 D710B20872 for ; Fri, 11 Jan 2019 01:19:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BzJBNOJq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D710B20872 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=RzFvzZlq4RlY3UI0MY66uwGOzh+LBmMfB02i1/NabDw=; b=BzJBNOJqCjtkwz iSe6xIE/YFK/62lJBVWJTFaMoqCIMmbV3LtPhq4xXAg3sCyhNfGur1SNd9mchHxUY0zPOLaqsE+Iv zFxgF1lBGkt5kEW6map92Zr39G43N9DKnZryaT4V952MbSFD8gTWCY5gD+WsNZjqKTF1VAmiIe9ho /U5tNjtjCrwyxpNKgDmsMkWmmGSD8nndT1aBFJg8TmoSM5FOyzc9NRyMIwokTQxYOBlRg4LZFJuJA tlJC9+hJXhPGIYFv8KOq7T+yc+N70A1K4G5+ntqVzuu6D2eqSouLRQzbvlo5POMMVCVSyOhWf3/1O QNz+zpK9USe8BmOQnXSg==; 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 1ghlTi-0005gm-Ov; Fri, 11 Jan 2019 01:19:18 +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 1ghlTW-0005X0-3K; Fri, 11 Jan 2019 01:19:16 +0000 X-UUID: d9b1fb2c8d434ce38448e143387a3341-20190110 X-UUID: d9b1fb2c8d434ce38448e143387a3341-20190110 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 2064551275; Thu, 10 Jan 2019 17:18:48 -0800 Received: from MTKMBS06N1.mediatek.inc (172.21.101.129) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Jan 2019 17:18:46 -0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs06n1.mediatek.inc (172.21.101.129) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 11 Jan 2019 09:18:44 +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; Fri, 11 Jan 2019 09:18:43 +0800 Message-ID: <1547169522.3831.47.camel@mhfsdcap03> Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support From: Long Cheng To: Vinod Koul Date: Fri, 11 Jan 2019 09:18:42 +0800 In-Reply-To: <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> <1547116431.3831.43.camel@mhfsdcap03> 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_171907_011091_B64B961B X-CRM114-Status: GOOD ( 27.73 ) 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 Thu, 2019-01-10 at 18:33 +0800, Long Cheng wrote: fix spell error > 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. > i will using 'dma-requests' instead 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. > Any way, in rx / tx, need handle 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 86CDCC43444 for ; Fri, 11 Jan 2019 01:18:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 51D4320872 for ; Fri, 11 Jan 2019 01:18:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729289AbfAKBSw (ORCPT ); Thu, 10 Jan 2019 20:18:52 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:46734 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726369AbfAKBSv (ORCPT ); Thu, 10 Jan 2019 20:18:51 -0500 X-UUID: a40104ff98954846a198be59a53b4740-20190111 X-UUID: a40104ff98954846a198be59a53b4740-20190111 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1260820821; Fri, 11 Jan 2019 09:18:46 +0800 Received: from MTKMBS06N1.mediatek.inc (172.21.101.129) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 11 Jan 2019 09:18:45 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs06n1.mediatek.inc (172.21.101.129) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 11 Jan 2019 09:18:44 +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; Fri, 11 Jan 2019 09:18:43 +0800 Message-ID: <1547169522.3831.47.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: Fri, 11 Jan 2019 09:18:42 +0800 In-Reply-To: <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> <1547116431.3831.43.camel@mhfsdcap03> 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 Thu, 2019-01-10 at 18:33 +0800, Long Cheng wrote: fix spell error > 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. > i will using 'dma-requests' instead 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. > Any way, in rx / tx, need handle 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 >