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: Revert "dmaengine: pl330: add DMA_PAUSE feature" From: Marek Szyprowski Message-Id: Date: Tue, 15 May 2018 14:24:28 +0200 To: Vinod Cc: Frank Mori Hess , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Dan Williams , r.baldyga@hackerion.com, Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Linux Samsung SOC List-ID: SGkgVmlub2QsCgpPbiAyMDE4LTA1LTE1IDA4OjIxLCBWaW5vZCB3cm90ZToKPiBPbiAxMS0wNS0x OCwgMTQ6NTcsIE1hcmVrIFN6eXByb3dza2kgd3JvdGU6Cj4+IE9uIDIwMTgtMDUtMTAgMTg6MDQs IEZyYW5rIE1vcmkgSGVzcyB3cm90ZToKPj4+IE9uIFRodSwgTWF5IDEwLCAyMDE4IGF0IDQ6MzEg QU0sIE1hcmVrIFN6eXByb3dza2kKPj4+IDxtLnN6eXByb3dza2lAc2Ftc3VuZy5jb20+IHdyb3Rl Ogo+Pj4+IE9uIDIwMTgtMDUtMDkgMTk6NDgsIEZyYW5rIE1vcmkgSGVzcyB3cm90ZToKPj4+Pj4g T24gV2VkLCBNYXkgOSwgMjAxOCBhdCA5OjE5IEFNLCBNYXJlayBTenlwcm93c2tpCj4+Pj4+IDxt LnN6eXByb3dza2lAc2Ftc3VuZy5jb20+IHdyb3RlOgo+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQg cGwzMzAgZG9lc24ndCBzdXBwb3J0IHJlYWwgUEFVU0UsIGJ1dCBhcyBpdCBoYXMgYmVlbgo+Pj4+ Pj4gaW1wbGVtZW50ZWQgc2luY2UgMjAxNSB0aGUgbGltaXRlZCBzdXBwb3J0IGlzIHBlcmZlY3Rs eSBwb3NzaWJsZSAtIGp1c3QKPj4+Pj4+IHRvIGxldCBzZXJpYWwgZHJpdmVyIHRvIHJlYWQgdGhl IGFtb3VudCBvZiBkYXRhIHRyYW5zZmVycmVkLgo+Pj4+Pj4KPj4+Pj4+IFBsZWFzZSBub3RlIHRo YXQgRE1BIGVuZ2luZSBkb2N1bWVudGF0aW9uIGNsZWFybHkgc3RhdGVzIHRoYXQgdGhlIGJlc3QK Pj4+Pj4+IHJlc2lkdWUgZ3JhbnVsYXJpdHkgdGhlIGRyaXZlciBtaWdodCBleHBlY3QgaXMgQlVS U1QgZ3JhbnVsYXJpdHkuIFRoZXJlCj4+Pj4+PiBpcyBubyB3YXkgdG8gZ2V0IHRoZSBpbmZvcm1h dGlvbiBhYm91dCB0aGUgZGF0YSB3aGljaCBzdGlsbCBzaXRzIGluIHRoZQo+Pj4+Pj4gRE1BIGVu Z2luZSBmaWZvIHdoZW4gdHJhbnNmZXIgaXMgcGF1c2VkL3Rlcm1pbmF0ZWQuIFRoaXMgbWVhbnMg dGhhdAo+Pj4+Pj4gdGhlIHNlcmlhbCBkcml2ZXIgc2hvdWxkIHNldCBtYXhidXJzdCA9IDEgaWYg aXQgaXMgaW50ZXJlc3RlZCBpbgo+Pj4+Pj4gZ2V0dGluZyBleGFjdCBudW1iZXIgb2YgYnl0ZXMg cmVjZWl2ZWQvc2VudC4gV2l0aCBtYXhidXJzdCA9IDEgdGhlcmUKPj4+Pj4+IGlzIG5vIHN1Y2gg dGhpbmcgYXMgZGF0YSBsb29zZSBpbiB0aGUgRE1BIGVuZ2luZSBmaWZvLgo+Pj4+PiBUaGF0IGlz IG5vdCBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkbWFlbmdpbmUgcGF1c2UgcmVxdWlyZW1lbnRz LCBidXQKPj4+Pj4gb2YgY291cnNlIFZpbm9kIGNhbiBzcGVhayBhdXRob3JpdGF0aXZlbHkgb24g dGhpcy4KPj4+PiBCYXNpbmcgb24gdGhlIGNvbW1lbnRzIGluIGRtYV9yZXNpZHVlX2dyYW51bGFy aXR5IGVudW0gZG9jdW1lbnRhdGlvbiAoc2VlCj4+Pj4gaW5jbHVkZS9saW51eC9kbWFlbmdpbmUu aCkgdGhlcmUgaXMgbm8gYmV0dGVyIGdyYW51bGFyaXR5IG9mIHJlc2lkdWUKPj4+PiByZXBvcnRp bmcgdGhhbiBCVVJTVCB1bml0cy4gSWYgZHJpdmVyIG5lZWRzIGJ5dGUgYWNjdXJhY3ksIHRoZW4g aXQgc2hvdWxkCj4+Pj4gdXNlIE1BWEJVUlNUPTEgYW5kIERNQV9TTEFWRV9CVVNXSURUSF8xX0JZ VEUgY29uZmlndXJhdGlvbi4KPj4+IFRoYXQncyBhbiBpbnRlcmVzdGluZyBsaW5lIG9mIHRob3Vn aHQuICBUaGUgODI1MCBzZXJpYWwgZHJpdmVyIGNsZWFybHkKPj4+IGFzc3VtZXMgaXQgY2FuIGRv IHRoZSBzZXF1ZW5jZQo+Pj4KPj4+IGRtYSBwYXVzZQo+Pj4gcmVhZCByZXNpZHVlCj4+PiBkbWEg dGVybWluYXRlCj4+Pgo+Pj4gd2l0aG91dCBkYXRhIGxvc3MuCj4+IFJpZ2h0LiBGcm9tIERNQSBl bmdpbmUgQVBJIHBlcnNwZWN0aXZlIHRoaXMgaXMgdGhlIG9ubHkgdmFsaWQgd2F5IHRvCj4+IHJl YWQgdGhlCj4+IHJlc2lkdWUgd2hlbiB5b3UgdGVybWluYXRlIHRoZSB0cmFuc2Zlci4KPiBOb3Qg cmVhbGx5LCBBUEkgYWxsb3dzIHlvdSB0byByZWFkIGFueSBwb2ludCBvZiB0aW1lLCB5b3UgbWF5 IHN1cHBvcnQgaXQgb3Igbm90Cj4gaXMgZGlmZmVyZW50IG1hdHRlci4gR3JhbnVsYXJpdHkgb2Yg cmVwb3J0aW5nIGlzIGFsc28gYSBkaWZmZXJlbnQgcG9pbnQuCgpJIG1lYW4gdG8gcmVhZCB0aGUg cmVzaWR1ZSBpbiBzdGFibGUgY29uZGl0aW9ucyAodGhlIGluY29taW5nIGJ5dGVzIGhhcyAKYmVl biBlaXRoZXIKcmVhZCBieSBkbWEgb3Igc3RpbGwgc2l0cyBpbiB0aGUgdWFydCBmaWZvKS4gVG9v IGJhZCB0aGF0IGl0IGlzIG5vdCAKcG9zc2libGUgdG8gcmVhZApyZXNpZHVlIGFmdGVyIHRlcm1p bmF0aW5nIHRoZSB0cmFuc2Zlci4gVGhpcyB3b3VsZCByZW1vdmUgdGhlIG5lZWQgZm9yIAp0aGlz IGZha2UKcGF1c2Ugc3VwcG9ydC4KCj4+PiAgICAgSXQgY2hlY2tzIGZvciB0aGUgY2FwYWJpbGl0 aWVzCj4+Pgo+Pj4gY21kX3BhdXNlCj4+PiBjbWRfdGVybWluYXRlCj4+PiByZXNpZHVlX2dyYW51 bGFyaXR5ICE9IERNQV9SRVNJRFVFX0dSQU5VTEFSSVRZX0RFU0NSSVBUT1IKPj4gQ2hlY2tpbmcg Zm9yIGNtZF9wYXVzZSBpcyBhIGJpdCB0b28gc3RyaWN0LCBiZWNhdXNlIGNtZF9wYXVzZSBtZWFu cyAnZHJpdmVyCj4+IHN1cHBvcnRzIGJvdGggcGF1c2UgYW5kIHJlc3VtZScsIGJ1dCB0aGUgc2Vy aWFsIGRyaXZlciBkb2Vzbid0IHVzZSByZXN1bWUgYXQKPj4gYWxsLiBBIGNoZWNrIGZvciByZXNp ZHVlX2dyYW51bGFyaXR5ICE9IERNQV9SRVNJRFVFX0dSQU5VTEFSSVRZX0RFU0NSSVBUT1IKPj4g aXMgb24gdGhlIG90aGVyIGhhbmQgYSBiaXQgdG9vIGxvb3NlLgo+IHRoYXRzIHRydWUgYW5kIGl0 IHdhcyBhZGRlZCBmb3IgYXVkaW8gd2hpY2ggZG9lcyBwYXVzZS9yZXN1bWUuIElmIHlvdSBmZWVs IGl0Cj4gaGVscHMgaW4gc2VyaWFsIHRvIGdldCBwYXVzZSAmIHJlc3VtZSBjYXBhYmlsaXRpZXMg aW5kZXBlbmRlbnRseSB3ZSBjYW4gc3BsaXQKPiB0aGVtIHVwLCBmZWVsIGZyZWUgdG8gc2VuZCBh IHBhdGNoCgpPa2F5LCBJIHdpbGwgcHJlcGFyZSBhIHBhdGNoIGZvciB0aGlzLgoKPiBGb3IgUGF1 c2UvcmVzdW1lIGRhdGEgbG9zcyBpcyBfbm90XyBleHBlY3RlZC4KPgo+Pj4gYW5kIHNvbWUgb2Yg dGhlIDgyNTAgZHJpdmVycyBsaWtlIDgyNTBfZHcuYyBzZXQgYSBtYXhidXJzdCA+IDEuICBJZiBp dAo+Pj4gY2FuJ3QgY291bnQgb24gdGhlIHBhdXNlL3Jlc2lkdWUvdGVybWluYXRlIHdvcmtpbmcg d2l0aG91dCBkYXRhIGxvc3MKPj4+IHRoZW4gaXQgaXMganVzdCBicm9rZW4uICBBcyBpcyB0aGUg ODI1MF9vbWFwLmMgZHJpdmVyLiAgSXMgdGhlCj4+PiBkZXNjcmlwdGlvbiBvZiBkbWFlbmdpbmVf cGF1c2UgaW4gdGhlIGRvY3VtZW50YXRpb24gb2YgIlRoaXMgcGF1c2VzCj4+PiBhY3Rpdml0eSBv biB0aGUgRE1BIGNoYW5uZWwgd2l0aG91dCBkYXRhIGxvc3MiIHRvIGJlIGludGVycHJldGVkIGFz Cj4+PiAiYXMgbG9uZyBhcyB5b3UgcmVzdW1lIGFmdGVyd2FyZHMiPwo+PiBJIGFzc3VtZSB0aGF0 IHRoaXMgcmVxdWlyZW1lbnQgaXMgZm9yIGJvdGggLSByZXN1bWluZyBhbmQgdGVybWluYXRpbmcu Cj4gVGVybWluYXRlIGlzIGFib3J0LCBkYXRhIGxvc3MgbWF5IGhhcHBlbiBoZXJlLgoKT2theS4g VGhlbiBpdCBpcyB1cCB0byB0aGUgZHJpdmVycyB0byByZWx5IG9uIHRoaXMgb3Igbm90LgoKPj4+ Pj4gSSBhbHNvIGRvbid0IGFncmVlCj4+Pj4+IHRoYXQgZGF0YSBsb3NzIGNhbm5vdCBoYXBwZW4g Zm9yIHNpbmdsZSB0cmFuc2ZlcnMuICBJdCBvbmx5IGJlY29tZXMKPj4+Pj4gbGVzcyBsaWtlbHkg c2luY2UgdGhlcmUgYXJlIGZld2VyIGJ5dGVzIGluIHRoZSBkbWEgY29udHJvbGxlciBmaWZvIGFu ZAo+Pj4+PiB0aGV5IHN0YXkgdGhlcmUgZm9yIGEgc2hvcnRlciBwZXJpb2Qgb2YgdGltZS4gIEJ1 dCBldmVuIHNvLCB0aGVyZSBpcwo+Pj4+PiBub3RoaW5nIHN0b3BwaW5nIHRoZSBETUFLSUxMIGZy b20ga2lsbGluZyB0aGUgdHJhbnNmZXIgdGhyZWFkIGFmdGVyIGl0Cj4+Pj4+IGRvZXMgYSBzaW5n bGUgYnl0ZSBsb2FkIGJ1dCBiZWZvcmUgaXQgZG9lcyB0aGUgYXNzb2NpYXRlZCBzaW5nbGUgYnl0 ZQo+Pj4+PiBzdG9yZSwgYXMgdGhleSBhcmUgcGVyZm9ybWVkIGJ5IHNlcGFyYXRlIGluc3RydWN0 aW9ucy4gIEFzIGZhciBhcyB5b3VyCj4+Pj4+IHNlcmlhbCBwb3J0IGdvZXMsIHRoZSBieXRlIGhh cyBiZWVuIHJlYWQgYnkgdGhlIGhvc3QsIGV2ZW4gdGhvdWdoIGl0Cj4+Pj4+IG5ldmVyIG1hZGUg aXQgdG8gbWVtb3J5LCBzbyBpdCBpcyBnb25lIGZvcmV2ZXIuICBUaGUgZG1hLTMzMCBkb2VzIGhh dmUKPj4+Pj4gYSBsb2FkIGxvY2sgd2hpY2ggcHJldmVudHMgc29tZSBvcGVyYXRpb25zIGZyb20g aW50ZXJydXB0aW5nIGEKPj4+Pj4gbG9hZC9zdG9yZSBjb21iaW5hdGlvbiwgYnV0IGluIG15IG9i c2VydmF0aW9ucyBETUFLSUxMIGRvZXMgbm90Cj4+Pj4+IHJlc3BlY3QgdGhlIGxvYWQgbG9jay4K Pj4+PiBGb3IgdGhlIGxhc3QgMyB5ZWFycyBubyBvbmUgb2JzZXJ2ZWQgYW55IGlzc3VlIHdpdGgg dGhlIGN1cnJlbnQgZGVzaWduCj4+Pj4gKHNpbmdsZSB0cmFuc2ZlcnMgd2l0aCBETUFfU0xBVkVf QlVTV0lEVEhfMV9CWVRFKS4gQnkgcmVtb3ZpbmcgdGhpcwo+Pj4+IGZlYXR1cmUgd2Ugd2lsbCBs b29zZSBhYmlsaXR5IHRvIHVzZSBETUEgaW4gdGhlIHNlcmlhbCBkcml2ZXJzLCB3aGF0IGlzCj4+ Pj4gbWFpbmx5IHVzZWZ1bCBmb3IgbG93LXBvd2VyIGJsdWV0b290aCBvcGVyYXRpb24gKHNlcmlh bCBjb25zb2xlIGlzIHJlYWxseQo+Pj4+IG5lZ2xpZ2libGUgY2FzZSkuCj4+PiBJdCdzIG5vdCBz dXJwcmlzaW5nIGl0IGhhc24ndCBiZWVuIHJlcG9ydGVkLiAgSXQgaXMgYSByYWNlIHRoYXQKPj4+ IHJlcXVpcmVzIGEgRE1BS0lMTCB0byBiZSBpc3N1ZWQganVzdCBhcyBhIGJ5dGUgaXMgaW4tZmxp Z2h0IHRocm91Z2gKPj4+IHRoZSBkbWEgY29udHJvbGxlci4gIFRoZSBvbmx5IHJlYXNvbiBhIGRy aXZlciB3b3VsZCBwYXVzZSB0aGUKPj4+IHVuLXJlc3VtZWFibGUgcGwzMzAgd291bGQgYmUgYmVj YXVzZSB0aGUgZHJpdmVyIGVpdGhlciBrbm93cyBvcgo+Pj4gc3VzcGVjdHMgbm8gbW9yZSBkYXRh IHdpbGwgYmUgYXJyaXZpbmcgYW5kIGl0IGdpdmVzIHVwIG9uIHRoZQo+Pj4gdHJhbnNmZXIuICBU aGUgb25seSByZWFzb24gSSBub3RpY2VkIGlzIHdlIGhhZCBhIHRlc3Qgd2hpY2ggc2VudCBkYXRh Cj4+PiB0byBhIHNlcmlhbCBwb3J0LCB3YWl0ZWQganVzdCBsb25nIGVub3VnaCBmb3IgdGhlIHNl cmlhbCBwb3J0IHJ4IHRvCj4+PiB0aW1lb3V0LCB0aGVuIHNlbnQgbW9yZSBkYXRhIGp1c3QgYXMg dGhlIHBhdXNlIHdhcyBpc3N1aW5nIERNQUtJTEwuCj4+PiBBbmQgdGhlbiB0aGUgdGVzdCBkaWQg dGhpcyBhIGZldyBodW5kcmVkIHRob3VzYW5kIHRpbWVzIHVudGlsIGl0Cj4+PiBub3RpY2VkIGJh ZCBkYXRhLiAgQWxzbywgZ2l2ZW4gdGhlIHdheSA4MjUwIHJ4IHRpbWVvdXRzIHdvcmssIGEgcGVy c29uCj4+PiB0eXBpbmcgaW50byBhIHNlcmlhbCBjb25zb2xlIHdvdWxkbid0IHR5cGUgZmFzdCBl bm91Z2ggdG8gdHJpZ2dlciB0aGUKPj4+IGJ1ZyB1bmxlc3MgdGhlIGJhdWQgcmF0ZSB3YXMgc2V0 IGV4dHJlbWVseSBsb3cuICBBbmQgaWYgc29tZW9uZSBsb3N0IGEKPj4+IGtleXN0cm9rZSBldmVy eSAxMF41IGJ5dGVzLCB3aG8gd291bGQgYmxhbWUgdGhlIGRtYSBjb250cm9sbGVyPwo+PiBMaWtl IEkgYWxyZWFkeSBzYWlkLCBjb25zb2xlIGlzIG5vdCBhIHByb3BlciB1c2UgY2FzZSBmb3Igc2Vy aWFsIGRtYS4KPj4gVGhlIG1vcmUgYXBwcm9wcmlhdGUgaXMgYmx1ZXRvb3RoIGFuZCBzdGlsbCwg SSdtIG5vdCBhd2FyZSBvZiB0aGUgaXNzdWUKPj4gd2l0aCB0aGUgY3VycmVudCBjb2RlLgo+IFdo eSBkbyB5b3Ugc2F5IHNlcmlhbCBpcyBub3QgaW1wb3J0YW50PwoKSSBtZWFuIHRoYXQgdXNpbmcg RE1BIGVuZ2luZSBmb3IgdWFydC9zZXJpYWwgZGV2aWNlIGZvciBpbXBsZW1lbnRpbmcgb25seSBh CmNvbnNvbGUgc3VwcG9ydCBpcyBhIGJpdCBwb2ludGxlc3MsIGJlY2F1c2UgdHlwaWNhbGx5IGNv bnNvbGUgZG9lc24ndCAKdHJhbnNmZXIKbXVjaCBkYXRhIGFuZCBvdmVyaGVhZCBvZiB1c2luZyBE TUEgbW9kZSAoc2V0dGluZyB1cCBkbWEgZW5naW5lKSBpcyBiaWdnZXIKdGhhbiBkb2luZyBhbGwg dGhlIHRyYW5zZmVycyBpbiBQSU8gbW9kZS4KCj4+PiBJIGRvIGFkbWl0IEkgZGlkbid0IGRvIHRo aXMgdGVzdCB1c2luZyBzaW5nbGUgdHJhbnNmZXJzLCBiZWNhdXNlIG91cgo+Pj4gZ29hbCB3YXMg Z2V0dGluZyBidXJzdHMgdG8gd29yay4gIFVuZm9ydHVuYXRlbHksIHRoZSB0ZXN0IHByb2dyYW0K Pj4+IHJlbGllcyBvbiBzb21lIGN1c3RvbSBoYXJkd2FyZSBJIG5vIGxvbmdlciBoYXZlIGFjY2Vz cyB0byBzbyBJIGNhbid0Cj4+PiBlYXNpbHkgcmUtcnVuIHRoZSB0ZXN0IG5vdy4gIEhvd2V2ZXIs IHNpbmNlIHRoZSBETUEtMzMwIG1hbnVhbAo+Pj4gZG9jdW1lbnRzIHRoZSBETUFLSUxMIGluc3Ry dWN0aW9uIHRvOgo+Pj4KPj4+ICJSZW1vdmUgYWxsIGVudHJpZXMgaW4gdGhlIE1GSUZPIGZvciB0 aGUgRE1BIGNoYW5uZWwuIgo+Pj4gIlJlbW92ZSBhbGwgZW50cmllcyBpbiB0aGUgcmVhZCBidWZm ZXIgcXVldWUgYW5kIHdyaXRlIGJ1ZmZlciBxdWV1ZQo+Pj4gZm9yIHRoZSBETUEgY2hhbm5lbC4i Cj4+Pgo+Pj4gUmVseWluZyBvbiBpdCB0byB3b3JrIGFzIGEgc2FmZSBwYXVzZSBmb3Igc2luZ2xl IHRyYW5zZmVycyBzZWVtcyBsaWtlCj4+PiB3aXNoZnVsIHRoaW5raW5nLiAgSSBzdXJlIGRpZG4n dCB3YW50IHRvIGJlbGlldmUgdGhlIERNQS0zMzAgY291bGRuJ3QKPj4+IGJlIHNhZmVseSBwYXVz ZWQsIGJ1dCBJIGV2ZW50dWFsbHkgaGFkIHRvIHJlc2lnbiBteXNlbGYgdG8gaXQuCj4+IE9rYXks IHNvIHlvdSBkb24ndCBoYXZlIGFueSBldmlkZW5jZSB0aGF0IERNQSB0cmFuc2ZlcnMgZG9uZSBp biBzaW5nbGUKPj4gcmVhZHMvd3JpdGVzIGlzIGJyb2tlbiB3aXRoIHRoZSBjdXJyZW50IGNtZF9w YXVzZSBpbXBsZW1lbnRhdGlvbi4KPj4KPj4gVGhpcyByZXZlcnQgaW4gZmFjdCBhdCBiZXN0IGRp c2FibGVzIERNQSBtb2RlIGluIHRoZSBzZXJpYWwgZHJpdmVycyAob3IKPj4gaW4gd29yc2UgY2Fz ZSwgaS5lLiBFeHlub3MsIGNhdXNlcyBjdXJyZW50IGRyaXZlcnMgdG8gZG8gdHJhc2hlZAo+PiB0 cmFuc2ZlcnMgZHVlIHRvIGxhY2sgb2YgY2hlY2tpbmcgZm9yIHRoZSBuZWVkZWQgZG1hIGVuZ2lu ZQo+PiBjYXBhYmlsaXRpZXMpLgo+Pgo+PiBNYXliZSBpbnN0ZWFkIG9mIHJldmVydGluZyBzdXBw b3J0IGZvciBpdCwgdGhlcmUgc2hvdWxkIGJlIGEgY2hlY2sgZm9yCj4+IEJVUlNUIHZzLiBTSU5H TEUgbW9kZSBhbmQgd2Ugd291bGQga2VlcCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBmb3IK Pj4gU0lOR0xFIHRyYW5zZmVycz8KPj4KPj4gVmlub2QsIGNvdWxkIHlvdSBjb21tZW50IGEgYml0 IHRoaXMgZGlzY3Vzc2lvbiBmcm9tIHRoZSBETUEgZW5naW5lCj4+IG1haW50YWluZXIgcGVyc3Bl Y3RpdmU/Cj4gU28gSSB3aWxsIHRyeSB0byBzdW1tYXJpc2UgaGVyZToKPgo+IC0gUGF1c2UvcmVz dW1lIGRvZXMgbm90IGV4cGVjdCBkYXRhIGxvc3MKPiAtIFN0YXR1cyBjYW4gYmUgcXVlcmllZCBh bnkgcG9pbnQgb2YgdGltZQo+IC0gR3JhbnVsYXJpdHkgcmVwb3J0aW5nIGlzIHVwdG8gZGV2aWNl Cj4gLSBUbyBzdXBwb3J0IGEgdXNlIGNhc2UgYW5kIGRldmljZSBsaW1pdGF0aW9ucyBpdCBpcyBv a2F5IHRvIHN1cHBvcnQgb25seQo+ICAgIHNpbmdsZXMuCgpXaGF0IGFib3V0IHRoZSByZXZlcnQg dGhpcyB0aHJlYWQgaXMgYWJvdXQ/IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gaGF2ZSBzb21lCmV2 aWRlbmNlIG9mIGJyb2tlbiBkYXRhIGluIHNpbmdsZSB0cmFuc2ZlciBtb2RlcyBiZWZvcmUgcmVt b3ZpbmcgCmZ1bmN0aW9uYWxpdHkKdGhhdCB3YXMgcHJlc2VudCBmb3IgeWVhcnMuCgpUaGUgZGlz Y3Vzc2VkIHVzZSBjYXNlIChwYXVzZSt0ZXJtaW5hdGUpIGlzIGNydWNpYWwgZm9yIHNlcmlhbCBk ZXZpY2VzIGF0CmxlYXN0IG9uIFNhbXN1bmcgU29DcyBhbmQgdGhpcyByZXZlcnQgYnJlYWsgdGhl bS4KClF1aWNrIGdyZXAgc2hvd3MgdGhhdCBQTDMzMCBpcyBiZWluZyB1c2VkIGJ5IGEgZmV3IG90 aGVyIFNvQyBmYW1pbGllcyB0b28sCmJ1dCBJIGRpZG4ndCBjaGVjayBpZiBhbnkgb2YgdGhlbSB1 c2UgaXQgZm9yIHNlcmlhbCBkZXZpY2UuCgpCZXN0IHJlZ2FyZHMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753327AbeEOMYo (ORCPT ); Tue, 15 May 2018 08:24:44 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:49600 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753169AbeEOMYk (ORCPT ); Tue, 15 May 2018 08:24:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20180515122438euoutp01f8310a6c00c6d590df00d40a259aaa77~u0PXrLWNb0056300563euoutp017 X-AuditID: cbfec7f5-b45ff700000028a9-d6-5afad1812a5e Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature" To: Vinod Cc: Frank Mori Hess , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Dan Williams , r.baldyga@hackerion.com, Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Linux Samsung SOC From: Marek Szyprowski Message-ID: Date: Tue, 15 May 2018 14:24:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180515062144.GC13271@vkoul-mobl> Content-Transfer-Encoding: 7bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsWy7djP87qNF39FGZw9ImKxccZ6VovpUy8w Wqye+pfVYv7juWwW589vYLe4vGsOm8WM8/uYLO7++8RosfPOCWYHTo+ds+6yexzZeYzNY/Ge l0wem1Z1snn0bVnF6PF5k1wAWxSXTUpqTmZZapG+XQJXxt/2K+wF9x0r3t/4yN7A+Mqki5GT Q0LARKJj3nGmLkYuDiGBFYwSh49eh3K+MEpMOH2EDcL5zCixcE8fI0zLlo2zoKqWM0o0Ll8E VfWeUWJHzxNWkCphAVuJ9i2ngBIcHCICMhLn9kWD1DAL7GWSOHjtFTNIDZuAoUTX2y6wGl4B O4l9DzhAwiwCqhKd+2cygdiiAjES0+ZdB7N5BQQlTs58wgJicwoYSFy9spQNxGYWkJfY/nYO M4QtLnHryXyw4yQEzrFLzN5+mRXiaheJ+28OsUPYwhKvjm+BsmUkTk/uYYGw6yX6vh+Bau5h lNjbMpUJImEtcfj4RVaQQ5kFNCXW79KHCNtKXN7ZxQwSlhDgk7jxVhDiBj6JSdumQ4V5JTra hCCq1SRmHV8Ht/XghUvMExiVZyH5bBaSb2Yh+WYWwt4FjCyrGMVTS4tz01OLjfNSy/WKE3OL S/PS9ZLzczcxAhPU6X/Hv+5g3Pcn6RCjAAejEg/vjhk/o4RYE8uKK3MPMUpwMCuJ8O42Agrx piRWVqUW5ccXleakFh9ilOZgURLnjdOoixISSE8sSc1OTS1ILYLJMnFwSjUwXtnwMpH3g9yj W18rqsx7TMxlfxeueNPqLfGCrekf2weJifcO/3f8EjCTvbLq0Q6uMOYPXnEidzen5s897vJ3 HT+v4UO5XVP+rdUr1f79tqGA4bS6XERB8sPFSStq11zQmrjsnMS5ha6KFbERmh+djXvuxbo7 rL12+XH/0eKfgrWBs/66S6wXUWIpzkg01GIuKk4EADrp5e9MAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsVy+t/xe7p1F39FGbRekLTYOGM9q8X0qRcY LVZP/ctqMf/xXDaL8+c3sFtc3jWHzWLG+X1MFnf/fWK02HnnBLMDp8fOWXfZPY7sPMbmsXjP SyaPTas62Tz6tqxi9Pi8SS6ALUrPpii/tCRVISO/uMRWKdrQwkjP0NJCz8jEUs/Q2DzWyshU Sd/OJiU1J7MstUjfLkEv42/7FfaC+44V7298ZG9gfGXSxcjJISFgIrFl4yymLkYuDiGBpYwS X25eZ4dIyEicnNbACmELS/y51sUGUfSWUaLjegszSEJYwFaifcspoAQHhwhQw7l90SA1zAJ7 mSTuLb3LCNFwjEXi4rd2RpAGNgFDia63XWANvAJ2EvsecICEWQRUJTr3z2QCsUUFYiR+HO1i AbF5BQQlTs58AmZzChhIXL2ylA3EZhYwk5i3+SEzhC0vsf3tHChbXOLWk/lMExiFZiFpn4Wk ZRaSlllIWhYwsqxiFEktLc5Nzy020itOzC0uzUvXS87P3cQIjMltx35u2cHY9S74EKMAB6MS D++OGT+jhFgTy4orcw8xSnAwK4nw7jYCCvGmJFZWpRblxxeV5qQWH2I0BXpuIrOUaHI+MF3k lcQbmhqaW1gamhubG5tZKInznjeojBISSE8sSc1OTS1ILYLpY+LglGpgdHk14cKUmeXn/y91 fRu949U6x2NbN+mbfJpy6+vc3Tv3V217qjl51x/3Yy8vbFyw0vfzpritv9rmzH21/Uyj4901 Ww8qlGyc/aXSdl/ih0Z5l9B/HXY2mmH3Hjv4tq385/dQtKrm42u18l79OyortjS+0vhUW79i 0Y41G40bMkuTt2uw3nvSHbhSiaU4I9FQi7moOBEAAtuwOd8CAAA= X-CMS-MailID: 20180515122431eucas1p13d52747049f0d72ffc8e072f5f4b8759 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-MTR: 20180515122431eucas1p13d52747049f0d72ffc8e072f5f4b8759 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180508090407eucas1p13713284c2d3f5aa5c66f8d136be683c1 X-RootMTR: 20180508090407eucas1p13713284c2d3f5aa5c66f8d136be683c1 References: <2484918.HKVQc3yJkt@bear> <53b13d76-16a1-0e0a-09e1-c917e5d49326@samsung.com> <182f50b9-55b6-c9ce-07fb-718a1d22e9c8@samsung.com> <06f54061-c537-b399-e493-ec2cdf4def5d@samsung.com> <20180515062144.GC13271@vkoul-mobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vinod, On 2018-05-15 08:21, Vinod wrote: > On 11-05-18, 14:57, Marek Szyprowski wrote: >> On 2018-05-10 18:04, Frank Mori Hess wrote: >>> On Thu, May 10, 2018 at 4:31 AM, Marek Szyprowski >>> wrote: >>>> On 2018-05-09 19:48, Frank Mori Hess wrote: >>>>> On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski >>>>> wrote: >>>>>> I understand that pl330 doesn't support real PAUSE, but as it has been >>>>>> implemented since 2015 the limited support is perfectly possible - just >>>>>> to let serial driver to read the amount of data transferred. >>>>>> >>>>>> Please note that DMA engine documentation clearly states that the best >>>>>> residue granularity the driver might expect is BURST granularity. There >>>>>> is no way to get the information about the data which still sits in the >>>>>> DMA engine fifo when transfer is paused/terminated. This means that >>>>>> the serial driver should set maxburst = 1 if it is interested in >>>>>> getting exact number of bytes received/sent. With maxburst = 1 there >>>>>> is no such thing as data loose in the DMA engine fifo. >>>>> That is not my understanding of the dmaengine pause requirements, but >>>>> of course Vinod can speak authoritatively on this. >>>> Basing on the comments in dma_residue_granularity enum documentation (see >>>> include/linux/dmaengine.h) there is no better granularity of residue >>>> reporting than BURST units. If driver needs byte accuracy, then it should >>>> use MAXBURST=1 and DMA_SLAVE_BUSWIDTH_1_BYTE configuration. >>> That's an interesting line of thought. The 8250 serial driver clearly >>> assumes it can do the sequence >>> >>> dma pause >>> read residue >>> dma terminate >>> >>> without data loss. >> Right. From DMA engine API perspective this is the only valid way to >> read the >> residue when you terminate the transfer. > Not really, API allows you to read any point of time, you may support it or not > is different matter. Granularity of reporting is also a different point. I mean to read the residue in stable conditions (the incoming bytes has been either read by dma or still sits in the uart fifo). Too bad that it is not possible to read residue after terminating the transfer. This would remove the need for this fake pause support. >>> It checks for the capabilities >>> >>> cmd_pause >>> cmd_terminate >>> residue_granularity != DMA_RESIDUE_GRANULARITY_DESCRIPTOR >> Checking for cmd_pause is a bit too strict, because cmd_pause means 'driver >> supports both pause and resume', but the serial driver doesn't use resume at >> all. A check for residue_granularity != DMA_RESIDUE_GRANULARITY_DESCRIPTOR >> is on the other hand a bit too loose. > thats true and it was added for audio which does pause/resume. If you feel it > helps in serial to get pause & resume capabilities independently we can split > them up, feel free to send a patch Okay, I will prepare a patch for this. > For Pause/resume data loss is _not_ expected. > >>> and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it >>> can't count on the pause/residue/terminate working without data loss >>> then it is just broken. As is the 8250_omap.c driver. Is the >>> description of dmaengine_pause in the documentation of "This pauses >>> activity on the DMA channel without data loss" to be interpreted as >>> "as long as you resume afterwards"? >> I assume that this requirement is for both - resuming and terminating. > Terminate is abort, data loss may happen here. Okay. Then it is up to the drivers to rely on this or not. >>>>> I also don't agree >>>>> that data loss cannot happen for single transfers. It only becomes >>>>> less likely since there are fewer bytes in the dma controller fifo and >>>>> they stay there for a shorter period of time. But even so, there is >>>>> nothing stopping the DMAKILL from killing the transfer thread after it >>>>> does a single byte load but before it does the associated single byte >>>>> store, as they are performed by separate instructions. As far as your >>>>> serial port goes, the byte has been read by the host, even though it >>>>> never made it to memory, so it is gone forever. The dma-330 does have >>>>> a load lock which prevents some operations from interrupting a >>>>> load/store combination, but in my observations DMAKILL does not >>>>> respect the load lock. >>>> For the last 3 years no one observed any issue with the current design >>>> (single transfers with DMA_SLAVE_BUSWIDTH_1_BYTE). By removing this >>>> feature we will loose ability to use DMA in the serial drivers, what is >>>> mainly useful for low-power bluetooth operation (serial console is really >>>> negligible case). >>> It's not surprising it hasn't been reported. It is a race that >>> requires a DMAKILL to be issued just as a byte is in-flight through >>> the dma controller. The only reason a driver would pause the >>> un-resumeable pl330 would be because the driver either knows or >>> suspects no more data will be arriving and it gives up on the >>> transfer. The only reason I noticed is we had a test which sent data >>> to a serial port, waited just long enough for the serial port rx to >>> timeout, then sent more data just as the pause was issuing DMAKILL. >>> And then the test did this a few hundred thousand times until it >>> noticed bad data. Also, given the way 8250 rx timeouts work, a person >>> typing into a serial console wouldn't type fast enough to trigger the >>> bug unless the baud rate was set extremely low. And if someone lost a >>> keystroke every 10^5 bytes, who would blame the dma controller? >> Like I already said, console is not a proper use case for serial dma. >> The more appropriate is bluetooth and still, I'm not aware of the issue >> with the current code. > Why do you say serial is not important? I mean that using DMA engine for uart/serial device for implementing only a console support is a bit pointless, because typically console doesn't transfer much data and overhead of using DMA mode (setting up dma engine) is bigger than doing all the transfers in PIO mode. >>> I do admit I didn't do this test using single transfers, because our >>> goal was getting bursts to work. Unfortunately, the test program >>> relies on some custom hardware I no longer have access to so I can't >>> easily re-run the test now. However, since the DMA-330 manual >>> documents the DMAKILL instruction to: >>> >>> "Remove all entries in the MFIFO for the DMA channel." >>> "Remove all entries in the read buffer queue and write buffer queue >>> for the DMA channel." >>> >>> Relying on it to work as a safe pause for single transfers seems like >>> wishful thinking. I sure didn't want to believe the DMA-330 couldn't >>> be safely paused, but I eventually had to resign myself to it. >> Okay, so you don't have any evidence that DMA transfers done in single >> reads/writes is broken with the current cmd_pause implementation. >> >> This revert in fact at best disables DMA mode in the serial drivers (or >> in worse case, i.e. Exynos, causes current drivers to do trashed >> transfers due to lack of checking for the needed dma engine >> capabilities). >> >> Maybe instead of reverting support for it, there should be a check for >> BURST vs. SINGLE mode and we would keep the current implementation for >> SINGLE transfers? >> >> Vinod, could you comment a bit this discussion from the DMA engine >> maintainer perspective? > So I will try to summarise here: > > - Pause/resume does not expect data loss > - Status can be queried any point of time > - Granularity reporting is upto device > - To support a use case and device limitations it is okay to support only > singles. What about the revert this thread is about? I would really like to have some evidence of broken data in single transfer modes before removing functionality that was present for years. The discussed use case (pause+terminate) is crucial for serial devices at least on Samsung SoCs and this revert break them. Quick grep shows that PL330 is being used by a few other SoC families too, but I didn't check if any of them use it for serial device. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland