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: Vinod Koul Message-Id: <20190120052750.GN4635@vkoul-mobl> Date: Sun, 20 Jan 2019 10:57:50 +0530 To: Long Cheng 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: T24gMTAtMDEtMTksIDE4OjMzLCBMb25nIENoZW5nIHdyb3RlOgo+IE9uIEZyaSwgMjAxOS0wMS0w NCBhdCAyMjo0OSArMDUzMCwgVmlub2QgS291bCB3cm90ZToKPiA+IE9uIDAyLTAxLTE5LCAxMDox MiwgTG9uZyBDaGVuZyB3cm90ZToKPiA+ID4gSW4gRE1BIGVuZ2luZSBmcmFtZXdvcmssIGFkZCA4 MjUwIHVhcnQgZG1hIHRvIHN1cHBvcnQgTWVkaWFUZWsgdWFydC4KPiA+ID4gSWYgTWVkaWFUZWsg dWFydCBlbmFibGVkKFNFUklBTF84MjUwX01UNjU3NyksIGFuZCB3YW50IHRvIGltcHJvdmUKPiA+ ID4gdGhlIHBlcmZvcm1hbmNlLCBjYW4gZW5hYmxlIHRoZSBmdW5jdGlvbi4KPiA+IAo+ID4gSXMg dGhlIERNQSBjb250cm9sbGVyIFVBUlQgc3BlY2lmaWMsIGNhbiBpdCB3b3JrIHdpdGggb3RoZXIg Y29udHJvbGxlcnMKPiA+IGFzIHdlbGwsIGlmIHNvIHlvdSBzaG91bGQgZ2V0IHJpZCBvZiB1YXJ0 IG5hbWUgaW4gcGF0Y2gKPiAKPiBJIGRvbid0IGtub3cgdGhhdCBpdCBjYW4gd29yayBvciBub3Qg b24gb3RoZXIgY29udHJvbGxlci4gYnV0IGl0J3MgZm9yCj4gTWVkaWFUZWsgU09DCgpXaGF0IEkg bWVhbnQgd2FzIHRoYXQgaWYgY2FuIHdvcmsgd2l0aCBvdGhlciBjb250cm9sbGVycyAodXNlcnMp IGFwYXJ0CmZyb20gVUFSVCwgaG93IGFib3V0IHNheSBhdWRpbywgc3BpIGV0YyEhCgo+IAo+ID4g PiArI2RlZmluZSBNVEtfVUFSVF9BUERNQV9DSEFOTkVMUwkJKENPTkZJR19TRVJJQUxfODI1MF9O Ul9VQVJUUyAqIDIpCj4gPiAKPiA+IFdoeSBhcmUgdGhlIGNoYW5uZWxzIG5vdCBjb21pbmcgZnJv bSBEVD8KPiA+IAo+IAo+IGkgd2lsbCB1c2luZyBkbWEtcmVxdWVzdHMgaW5zdGFsbCBvZiBpdC4K PiAKPiA+ID4gKwo+ID4gPiArI2RlZmluZSBWRkZfRU5fQgkJQklUKDApCj4gPiA+ICsjZGVmaW5l IFZGRl9TVE9QX0IJCUJJVCgwKQo+ID4gPiArI2RlZmluZSBWRkZfRkxVU0hfQgkJQklUKDApCj4g PiA+ICsjZGVmaW5lIFZGRl80R19TVVBQT1JUX0IJQklUKDApCj4gPiA+ICsjZGVmaW5lIFZGRl9S WF9JTlRfRU4wX0IJQklUKDApCS8qcnggdmFsaWQgc2l6ZSA+PSAgdmZmIHRocmUqLwo+ID4gPiAr I2RlZmluZSBWRkZfUlhfSU5UX0VOMV9CCUJJVCgxKQo+ID4gPiArI2RlZmluZSBWRkZfVFhfSU5U X0VOX0IJCUJJVCgwKQkvKnR4IGxlZnQgc2l6ZSA+PSB2ZmYgdGhyZSovCj4gPiAKPiA+IHNwYWNl IGFyb3VuZCAvKiBzcGFjZSAqLyBhbHNvIHJ1biBjaGVja3BhdGNoIHRvIGNoZWNrIGZvciBzdHls ZSBlcnJvcnMKPiA+IAo+IAo+IG9rLgo+IAo+ID4gPiArc3RhdGljIHZvaWQgbXRrX3VhcnRfYXBk bWFfc3RhcnRfdHgoc3RydWN0IG10a19jaGFuICpjKQo+ID4gPiArewo+ID4gPiArCXVuc2lnbmVk IGludCBsZW4sIHNlbmQsIGxlZnQsIHdwdCwgZF93cHQsIHRtcDsKPiA+ID4gKwlpbnQgcmV0Owo+ ID4gPiArCj4gPiA+ICsJbGVmdCA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX0xFRlRfU0la RSk7Cj4gPiA+ICsJaWYgKCFsZWZ0KSB7Cj4gPiA+ICsJCW10a191YXJ0X2FwZG1hX3dyaXRlKGMs IFZGRl9JTlRfRU4sIFZGRl9UWF9JTlRfRU5fQik7Cj4gPiA+ICsJCXJldHVybjsKPiA+ID4gKwl9 Cj4gPiA+ICsKPiA+ID4gKwkvKiBXYWl0IDFzZWMgZm9yIGZsdXNoLCAgY2FuJ3Qgc2xlZXAqLwo+ ID4gPiArCXJldCA9IHJlYWR4X3BvbGxfdGltZW91dChyZWFkbCwgYy0+YmFzZSArIFZGRl9GTFVT SCwgdG1wLAo+ID4gPiArCQkJdG1wICE9IFZGRl9GTFVTSF9CLCAwLCAxMDAwMDAwKTsKPiA+ID4g KwlpZiAocmV0KQo+ID4gPiArCQlkZXZfd2FybihjLT52Yy5jaGFuLmRldmljZS0+ZGV2LCAidHg6 IGZhaWwsIGRlYnVnPTB4JXhcbiIsCj4gPiA+ICsJCQltdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZG Rl9ERUJVR19TVEFUVVMpKTsKPiA+ID4gKwo+ID4gPiArCXNlbmQgPSBtaW5fdCh1bnNpZ25lZCBp bnQsIGxlZnQsIGMtPmRlc2MtPmF2YWlsX2xlbik7Cj4gPiA+ICsJd3B0ID0gbXRrX3VhcnRfYXBk bWFfcmVhZChjLCBWRkZfV1BUKTsKPiA+ID4gKwlsZW4gPSBtdGtfdWFydF9hcGRtYV9yZWFkKGMs IFZGRl9MRU4pOwo+ID4gPiArCj4gPiA+ICsJZF93cHQgPSB3cHQgKyBzZW5kOwo+ID4gPiArCWlm ICgoZF93cHQgJiBWRkZfUklOR19TSVpFKSA+PSBsZW4pIHsKPiA+ID4gKwkJZF93cHQgPSBkX3dw dCAtIGxlbjsKPiA+ID4gKwkJZF93cHQgPSBkX3dwdCBeIFZGRl9SSU5HX1dSQVA7Cj4gPiA+ICsJ fQo+ID4gPiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9XUFQsIGRfd3B0KTsKPiA+ID4g Kwo+ID4gPiArCWMtPmRlc2MtPmF2YWlsX2xlbiAtPSBzZW5kOwo+ID4gPiArCj4gPiA+ICsJbXRr X3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0lOVF9FTiwgVkZGX1RYX0lOVF9FTl9CKTsKPiA+ID4g KwlpZiAobXRrX3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfRkxVU0gpID09IDBVKQo+ID4gPiArCQlt dGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfRkxVU0gsIFZGRl9GTFVTSF9CKTsKPiA+ID4gK30K PiA+ID4gKwo+ID4gPiArc3RhdGljIHZvaWQgbXRrX3VhcnRfYXBkbWFfc3RhcnRfcngoc3RydWN0 IG10a19jaGFuICpjKQo+ID4gPiArewo+ID4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRtYV9kZXNj ICpkID0gYy0+ZGVzYzsKPiA+ID4gKwl1bnNpZ25lZCBpbnQgbGVuLCB3ZywgcmcsIGNudDsKPiA+ ID4gKwo+ID4gPiArCWlmICgobXRrX3VhcnRfYXBkbWFfcmVhZChjLCBWRkZfVkFMSURfU0laRSkg PT0gMFUpIHx8Cj4gPiA+ICsJCSFkIHx8ICF2Y2hhbl9uZXh0X2Rlc2MoJmMtPnZjKSkKPiA+ID4g KwkJcmV0dXJuOwo+ID4gPiArCj4gPiA+ICsJbGVuID0gbXRrX3VhcnRfYXBkbWFfcmVhZChjLCBW RkZfTEVOKTsKPiA+ID4gKwlyZyA9IG10a191YXJ0X2FwZG1hX3JlYWQoYywgVkZGX1JQVCk7Cj4g PiA+ICsJd2cgPSBtdGtfdWFydF9hcGRtYV9yZWFkKGMsIFZGRl9XUFQpOwo+ID4gPiArCWlmICgo cmcgXiB3ZykgJiBWRkZfUklOR19XUkFQKQo+ID4gPiArCQljbnQgPSAod2cgJiBWRkZfUklOR19T SVpFKSArIGxlbiAtIChyZyAmIFZGRl9SSU5HX1NJWkUpOwo+ID4gPiArCWVsc2UKPiA+ID4gKwkJ Y250ID0gKHdnICYgVkZGX1JJTkdfU0laRSkgLSAocmcgJiBWRkZfUklOR19TSVpFKTsKPiA+ID4g Kwo+ID4gPiArCWMtPnJ4X3N0YXR1cyA9IGNudDsKPiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0 ZShjLCBWRkZfUlBULCB3Zyk7Cj4gPiA+ICsKPiA+ID4gKwlsaXN0X2RlbCgmZC0+dmQubm9kZSk7 Cj4gPiA+ICsJdmNoYW5fY29va2llX2NvbXBsZXRlKCZkLT52ZCk7Cj4gPiA+ICt9Cj4gPiAKPiA+ IHRoaXMgbG9va3Mgb2RkLCB3aHkgZG8geW91IGhhdmUgZGlmZmVyZW50IHJ4IGFuZCB0eCBzdGFy dCByb3V0aW5lcz8KPiA+IAo+IAo+IFdvdWxkIHlvdSBsaWtlIGV4cGxhaW4gaXQgaW4gbW9yZSBk ZXRhaWw/IHRoYW5rcy4KPiBJbiB0eCBmdW5jdGlvbiwgd2lsbCB3YWl0IHRoZSBsYXN0IGRhdGEg Zmx1c2ggZG9uZS4gYW5kIHRoZSBjb3VudCB0aGUKPiBzaXplIHRoYXQgc2VuZC4KPiBJbiBSeCBm dW5jdGlvbiwgd2lsbCBjb3VudCB0aGUgc2l6ZSB0aGF0IHJlY2VpdmUuCj4gQW55IHdheSwgaW4g cnggLyB0eCwgbmVlZCBhbmRsZSBXUFQgb3IgUlBULgo+IAo+ID4gPiArc3RhdGljIGludCBtdGtf dWFydF9hcGRtYV9hbGxvY19jaGFuX3Jlc291cmNlcyhzdHJ1Y3QgZG1hX2NoYW4gKmNoYW4pCj4g PiA+ICt7Cj4gPiA+ICsJc3RydWN0IG10a191YXJ0X2FwZG1hZGV2ICptdGtkID0gdG9fbXRrX3Vh cnRfYXBkbWFfZGV2KGNoYW4tPmRldmljZSk7Cj4gPiA+ICsJc3RydWN0IG10a19jaGFuICpjID0g dG9fbXRrX3VhcnRfYXBkbWFfY2hhbihjaGFuKTsKPiA+ID4gKwl1MzIgdG1wOwo+ID4gPiArCWlu dCByZXQ7Cj4gPiA+ICsKPiA+ID4gKwlwbV9ydW50aW1lX2dldF9zeW5jKG10a2QtPmRkZXYuZGV2 KTsKPiA+ID4gKwo+ID4gPiArCW10a191YXJ0X2FwZG1hX3dyaXRlKGMsIFZGRl9BRERSLCAwKTsK PiA+ID4gKwltdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfVEhSRSwgMCk7Cj4gPiA+ICsJbXRr X3VhcnRfYXBkbWFfd3JpdGUoYywgVkZGX0xFTiwgMCk7Cj4gPiA+ICsJbXRrX3VhcnRfYXBkbWFf d3JpdGUoYywgVkZGX1JTVCwgVkZGX1dBUk1fUlNUX0IpOwo+ID4gPiArCj4gPiA+ICsJcmV0ID0g cmVhZHhfcG9sbF90aW1lb3V0KHJlYWRsLCBjLT5iYXNlICsgVkZGX0VOLCB0bXAsCj4gPiA+ICsJ CQl0bXAgPT0gMCwgMTAsIDEwMCk7Cj4gPiA+ICsJaWYgKHJldCkgewo+ID4gPiArCQlkZXZfZXJy KGNoYW4tPmRldmljZS0+ZGV2LCAiZG1hIHJlc2V0OiBmYWlsLCB0aW1lb3V0XG4iKTsKPiA+ID4g KwkJcmV0dXJuIHJldDsKPiA+ID4gKwl9Cj4gPiAKPiA+IHJlZ2lzdGVyIHJlYWQgZG9lcyByZXNl dD8KPiA+IAo+IAo+ICdtdGtfdWFydF9hcGRtYV93cml0ZShjLCBWRkZfUlNULCBWRkZfV0FSTV9S U1RfQik7JyBpcyByZXNldC4gcmVzZCBqdXN0Cj4gcG9sbCByZXNldCBkb25lLgo+IAo+ID4gPiAr Cj4gPiA+ICsJaWYgKCFjLT5yZXF1ZXN0ZWQpIHsKPiA+ID4gKwkJYy0+cmVxdWVzdGVkID0gdHJ1 ZTsKPiA+ID4gKwkJcmV0ID0gcmVxdWVzdF9pcnEobXRrZC0+ZG1hX2lycVtjaGFuLT5jaGFuX2lk XSwKPiA+ID4gKwkJCQkgIG10a191YXJ0X2FwZG1hX2lycV9oYW5kbGVyLCBJUlFGX1RSSUdHRVJf Tk9ORSwKPiA+ID4gKwkJCQkgIEtCVUlMRF9NT0ROQU1FLCBjaGFuKTsKPiA+IAo+ID4gd2h5IGlz IHRoZSBpcnEgbm90IHJlcXVlc3RlZCBpbiBkcml2ZXIgcHJvYmU/Cj4gPiAKPiAKPiBJIGhhdmUg ZXhwbGFpbmVkIGluIGJlbG93LAo+IGh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL3BpcGVybWFp bC9saW51eC1tZWRpYXRlay8yMDE4LURlY2VtYmVyLzAxNjQxOC5odG1sCj4gCj4gPiA+ICtzdGF0 aWMgZW51bSBkbWFfc3RhdHVzIG10a191YXJ0X2FwZG1hX3R4X3N0YXR1cyhzdHJ1Y3QgZG1hX2No YW4gKmNoYW4sCj4gPiA+ICsJCQkJCSBkbWFfY29va2llX3QgY29va2llLAo+ID4gPiArCQkJCQkg c3RydWN0IGRtYV90eF9zdGF0ZSAqdHhzdGF0ZSkKPiA+ID4gK3sKPiA+ID4gKwlzdHJ1Y3QgbXRr X2NoYW4gKmMgPSB0b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4pOwo+ID4gPiArCWVudW0gZG1h X3N0YXR1cyByZXQ7Cj4gPiA+ICsJdW5zaWduZWQgbG9uZyBmbGFnczsKPiA+ID4gKwo+ID4gPiAr CWlmICghdHhzdGF0ZSkKPiA+ID4gKwkJcmV0dXJuIERNQV9FUlJPUjsKPiA+ID4gKwo+ID4gPiAr CXJldCA9IGRtYV9jb29raWVfc3RhdHVzKGNoYW4sIGNvb2tpZSwgdHhzdGF0ZSk7Cj4gPiA+ICsJ c3Bpbl9sb2NrX2lycXNhdmUoJmMtPnZjLmxvY2ssIGZsYWdzKTsKPiA+ID4gKwlpZiAocmV0ID09 IERNQV9JTl9QUk9HUkVTUykgewo+ID4gPiArCQljLT5yeF9zdGF0dXMgPSBtdGtfdWFydF9hcGRt YV9yZWFkKGMsIFZGRl9SUFQpICYgVkZGX1JJTkdfU0laRTsKPiA+ID4gKwkJZG1hX3NldF9yZXNp ZHVlKHR4c3RhdGUsIGMtPnJ4X3N0YXR1cyk7Cj4gPiA+ICsJfSBlbHNlIGlmIChyZXQgPT0gRE1B X0NPTVBMRVRFICYmIGMtPmNmZy5kaXJlY3Rpb24gPT0gRE1BX0RFVl9UT19NRU0pIHsKPiA+IAo+ ID4gd2h5IHNldCByZXNpZGUgd2hlbiBpdCBpcyBjb21wbGV0ZT8gYWxzbyByZXNpZGUgY2FuIGJl IG51bGwsIHRoYXQgc2hvdWxkCj4gPiBiZSBjaGVja2VkIGFzIHdlbGwKPiA+IAo+IEluIGRpZmZl cmVudCBzdGF0dXMsIHNldCBkaWZmZXJlbnQgcmVzaWRlLgoKQ2FuIHlvdSBleHBsYWluIHRoYXQu LgoKPiAKPiA+ID4gK3N0YXRpYyBzdHJ1Y3QgZG1hX2FzeW5jX3R4X2Rlc2NyaXB0b3IgKm10a191 YXJ0X2FwZG1hX3ByZXBfc2xhdmVfc2cKPiA+ID4gKwkoc3RydWN0IGRtYV9jaGFuICpjaGFuLCBz dHJ1Y3Qgc2NhdHRlcmxpc3QgKnNnbCwKPiA+ID4gKwl1bnNpZ25lZCBpbnQgc2dsZW4sIGVudW0g ZG1hX3RyYW5zZmVyX2RpcmVjdGlvbiBkaXIsCj4gPiA+ICsJdW5zaWduZWQgbG9uZyB0eF9mbGFn cywgdm9pZCAqY29udGV4dCkKPiA+ID4gK3sKPiA+ID4gKwlzdHJ1Y3QgbXRrX2NoYW4gKmMgPSB0 b19tdGtfdWFydF9hcGRtYV9jaGFuKGNoYW4pOwo+ID4gPiArCXN0cnVjdCBtdGtfdWFydF9hcGRt YV9kZXNjICpkOwo+ID4gPiArCj4gPiA+ICsJaWYgKChkaXIgIT0gRE1BX0RFVl9UT19NRU0pICYm Cj4gPiA+ICsJCShkaXIgIT0gRE1BX01FTV9UT19ERVYpKSB7Cj4gPiA+ICsJCWRldl9lcnIoY2hh bi0+ZGV2aWNlLT5kZXYsICJiYWQgZGlyZWN0aW9uXG4iKTsKPiA+ID4gKwkJcmV0dXJuIE5VTEw7 Cj4gPiA+ICsJfQo+ID4gCj4gPiB3ZSBoYXZlIGEgbWFjcm8gZm9yIHRoaXMKPiAKPiBUaGFua3Mg Zm9yIHlvdXIgc3VnZ2VzdGlvbi4gaSB3aWxsIG1vZGlmeSBpdC4KPiA+IAo+ID4gPiArCj4gPiA+ ICsJLyogTm93IGFsbG9jYXRlIGFuZCBzZXR1cCB0aGUgZGVzY3JpcHRvciAqLwo+ID4gPiArCWQg PSBremFsbG9jKHNpemVvZigqZCksIEdGUF9BVE9NSUMpOwo+ID4gPiArCWlmICghZCkKPiA+ID4g KwkJcmV0dXJuIE5VTEw7Cj4gPiA+ICsKPiA+ID4gKwkvKiBzZ2xlbiBpcyAxICovCj4gPiAKPiA+ ID8KPiA+IAo+ID4gPiArc3RhdGljIGludCBtdGtfdWFydF9hcGRtYV9zbGF2ZV9jb25maWcoc3Ry dWN0IGRtYV9jaGFuICpjaGFuLAo+ID4gPiArCQkJCXN0cnVjdCBkbWFfc2xhdmVfY29uZmlnICpj ZmcpCj4gPiA+ICt7Cj4gPiA+ICsJc3RydWN0IG10a19jaGFuICpjID0gdG9fbXRrX3VhcnRfYXBk bWFfY2hhbihjaGFuKTsKPiA+ID4gKwlzdHJ1Y3QgbXRrX3VhcnRfYXBkbWFkZXYgKm10a2QgPQo+ ID4gPiArCQkJCXRvX210a191YXJ0X2FwZG1hX2RldihjLT52Yy5jaGFuLmRldmljZSk7Cj4gPiA+ ICsKPiA+ID4gKwljLT5jZmcgPSAqY2ZnOwo+ID4gPiArCj4gPiA+ICsJaWYgKGNmZy0+ZGlyZWN0 aW9uID09IERNQV9ERVZfVE9fTUVNKSB7Cj4gPiAKPiA+IGZnLT5kaXJlY3Rpb24gaXMgZGVwcmVj YXRlZCwgaW4gZmFjdCBJIGhhdmUgcmVtb3ZlZCBhbGwgdXNlcnMgcmVjZW50bHksCj4gPiBwbGVh c2UgZG8gbm90IHVzZSB0aGlzCj4gCj4gWW91IHdpbGwgcmVtb3ZlICdkaXJlY3Rpb24nIGluICdz dHJ1Y3QgZG1hX3NsYXZlX2NvbmZpZyc/IGlmIHJlbW92ZSwgaG93Cj4gZG8gY29uZmlybSBkaXJl Y3Rpb24/CgpZZXMgcGxlYXNlIHVzZSB0aGUgZGlyZWN0aW9uIGFyZ3VtZW50IGluIHByZXBfeHgg Y2FsbHMK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support Date: Sun, 20 Jan 2019 10:57:50 +0530 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1547116431.3831.43.camel@mhfsdcap03> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Long Cheng Cc: Mark Rutland , devicetree@vger.kernel.org, Nicolas Boichat , Zhenbao Liu , linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Greg Kroah-Hartman , Randy Dunlap , linux-kernel@vger.kernel.org, Rob Herring , Sean Wang , YT Shen , dmaengine@vger.kernel.org, Ryder Lee , linux-mediatek@lists.infradead.org, Sean Wang , Jiri Slaby , Matthias Brugger , Yingjoe Chen , Dan Williams , linux-arm-kernel@lists.infradead.org List-Id: linux-mediatek@lists.infradead.org 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!! > > > > +#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.. > > > > +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? Yes please use the direction argument in prep_xx calls -- ~Vinod 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=-3.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 CA9CDC61CE4 for ; Sun, 20 Jan 2019 05:29:35 +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 9264A20880 for ; Sun, 20 Jan 2019 05:29:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fdQnHXRN"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="1yZZAXwx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9264A20880 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=b9cVAbzaKHe7X88vkD9hgpSU9YoAEPxuyBa2FWiSq50=; b=fdQnHXRN9/qBX1 7CvrCLuDakw+QO/aEzfXbFDNdnB/j8KGaOMol1etd7ehtjWwLz6ALNAOJf0SPWBPy+P2J3C9a0Rl7 EpuUT/cxRenYL/y13bbs0y9oQ8R4O/T+UVkcuBpLKphWjtuBtYMosJ3I/ze8CQnAGbwOFvDfEHiC9 PHce0+NS4Sez788aPWX6F03I8HMrpzXA1byNeDO4v02Z/Ui/RZit/5mIFj/fTNvGynjqNPyv25p4i bsfNa3Sv3U/brGn7VkniiFMEp0Hq28QV9AX1p80CN+i0lXvzRkt3MIByocuYqeuJoUJ8J24DjkZNz T9ZG2Z/TksymnwaQp1TA==; 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 1gl5fp-0001sY-I1; Sun, 20 Jan 2019 05:29:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gl5fm-0001s9-13; Sun, 20 Jan 2019 05:29:31 +0000 Received: from localhost (unknown [122.178.235.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5D6ED2084C; Sun, 20 Jan 2019 05:29:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547962169; bh=UHKWDlIfapoOd6CK6rgHfqbocnOPirpeKm1gH8X4Np0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1yZZAXwx9jVsGbNoNQAnrYijeDW3lT77XhfmBF3LCEGb2cfg6wG5ZXoFaXawVwtOq oST+VI/GRcmrYG+SBndFT1EGuYlXMmfiR+h1I6+H0GKaLa2MCIBwOY1jfd2nnRK+RB 3X6g9OpilUg7VypfLkhmDgccTT8QbXlXI5RnKHKY= Date: Sun, 20 Jan 2019 10:57:50 +0530 From: Vinod Koul To: Long Cheng Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support Message-ID: <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1547116431.3831.43.camel@mhfsdcap03> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190119_212930_106873_36CD99A5 X-CRM114-Status: GOOD ( 26.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Nicolas Boichat , Zhenbao Liu , linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Greg Kroah-Hartman , Randy Dunlap , linux-kernel@vger.kernel.org, Rob Herring , Sean Wang , YT Shen , dmaengine@vger.kernel.org, Ryder Lee , linux-mediatek@lists.infradead.org, Sean Wang , Jiri Slaby , Matthias Brugger , Yingjoe Chen , Dan Williams , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 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!! > > > > +#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.. > > > > +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? Yes please use the direction argument in prep_xx calls -- ~Vinod _______________________________________________ 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=-3.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT 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 DAD3FC61CE4 for ; Sun, 20 Jan 2019 05:29:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FB992084C for ; Sun, 20 Jan 2019 05:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547962180; bh=UHKWDlIfapoOd6CK6rgHfqbocnOPirpeKm1gH8X4Np0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=E+KpIPBIX//VerhZw4duqr14/B9fI8biuZo3Kv9vb52m6m1bCl9S5Z0ycArA7vblh 3UkNWWKukzXfD4VIj/3pBrSxqtqxcfMKSUyjxjF/ioccGZIKOnEs9cER+4o2mfZQKS OT0YMgo2/PAYzfDj6BFjuZxUCoXWVwdJu2QrdIuw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727152AbfATF3b (ORCPT ); Sun, 20 Jan 2019 00:29:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:55632 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbfATF3b (ORCPT ); Sun, 20 Jan 2019 00:29:31 -0500 Received: from localhost (unknown [122.178.235.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5D6ED2084C; Sun, 20 Jan 2019 05:29:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547962169; bh=UHKWDlIfapoOd6CK6rgHfqbocnOPirpeKm1gH8X4Np0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1yZZAXwx9jVsGbNoNQAnrYijeDW3lT77XhfmBF3LCEGb2cfg6wG5ZXoFaXawVwtOq oST+VI/GRcmrYG+SBndFT1EGuYlXMmfiR+h1I6+H0GKaLa2MCIBwOY1jfd2nnRK+RB 3X6g9OpilUg7VypfLkhmDgccTT8QbXlXI5RnKHKY= Date: Sun, 20 Jan 2019 10:57:50 +0530 From: Vinod Koul To: Long Cheng 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 Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1547116431.3831.43.camel@mhfsdcap03> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!! > > > > +#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.. > > > > +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? Yes please use the direction argument in prep_xx calls -- ~Vinod