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: dmaengine: stm32-dma: fix residue calculation in stm32-dma From: Arnaud Pouliquen Message-Id: <26fa7710-76cb-e202-a367-c2e2408b6808@st.com> Date: Mon, 29 Apr 2019 16:52:50 +0200 To: Vinod Koul Cc: Dan Williams , Pierre-Yves MORDRET , linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org List-ID: T24gNC8yOS8xOSA3OjEzIEFNLCBWaW5vZCBLb3VsIHdyb3RlOgo+IE9uIDI2LTA0LTE5LCAxNTo0 MSwgQXJuYXVkIFBvdWxpcXVlbiB3cm90ZToKPj4+PiBEdXJpbmcgcmVzaWR1ZSBjYWxjdWxhdGlv bi4gdGhlIERNQSBjYW4gc3dpdGNoIHRvIHRoZSBuZXh0IHNnLiBXaGVuCj4+Pj4gdGhpcyByYWNl IGNvbmRpdGlvbiBvY2N1cnMsIHRoZSByZXNpZHVlIHJldHVybmVkIHZhbHVlIGlzIG5vdCB2YWxp ZC4KPj4+PiBJbmRlZWQgdGhlIHBvc2l0aW9uIGluIHRoZSBzZyByZXR1cm5lZCBieSB0aGUgaGFy ZHdhcmUgaXMgdGhlIHBvc2l0aW9uCj4+Pj4gb2YgdGhlIG5leHQgc2csIG5vdCB0aGUgY3VycmVu dCBzZy4KPj4+PiBTb2x1dGlvbiBpcyB0byBjaGVjayB0aGUgc2cgYWZ0ZXIgdGhlIGNhbGN1bGF0 aW9uIHRvIHZlcmlmeSBpdC4KPj4+PiBJZiBhIHRyYW5zaXRpb24gaXMgZGV0ZWN0ZWQgd2UgY29u c2lkZXIgdGhhdCB0aGUgRE1BIGhhcyBzd2l0Y2hlZCB0bwo+Pj4+IHRoZSBiZWdpbm5pbmcgb2Yg bmV4dCBzZy4KPj4+Cj4+PiBOb3csIHRoYXQgc291bmRzIGxpa2UgZHVjdCB0YXBlLiBXaHkgc2hv dWxkIHdlIGJvdGhlciBkb2luZyB0aGF0Lgo+Pj4KPj4+IEFsc28gbG9va2luZyBiYWNrIGF0IHRo ZSBzdG0zMl9kbWFfZGVzY19yZXNpZHVlKCkgYW5kIGNhbGxzIHRvIGl0IGZyb20KPj4+IHN0bTMy X2RtYV90eF9zdGF0dXMoKSBhbSBub3Qgc3VyZSB3ZSBhcmUgZG9pbmcgdGhlIHJpZ2h0IHRoaW5n Cj4+IFBsZWFzZSwgY291bGQgeW91IGV4cGxhaW4gd2hhdCB5b3UgaGF2ZSBpbiBtaW5kIGhlcmU/ Cj4gCj4gU28gd2hlbiB3ZSBjYWxsIHZjaGFuX2ZpbmRfZGVzYygpIHRoYXQgdGVsbHMgdXMgaWYg dGhlIGRlc2NyaXB0b3IgaXMgaW4KPiB0aGUgaXNzdWVkIHF1ZXVlIG9yIG5vdC4uICBJZGVhbGx5 IGl0IHNob3VsZCBub3QgbWF0dGVyIGlmIHdlIGhhdmUgb25lCj4gb3IgTiBkZXNjcmlwdG9ycyBp c3N1ZWQgdG8gaGFyZHdhcmUuCj4gCj4gU28gd2h5IHNob3VsZCB5b3UgYm90aGVyIGNoZWNraW5n IGZvciBuZXh0X3NnLgo+IAo+Pj4gd2h5IGFyZSB3ZSBsb29raW5nIGF0IG5leHRfc2cgaGVyZSwg Y2FuIHlvdSBleHBsYWluIG1lIHRoYXQgcGxlYXNlCj4+Cj4+IFRoaXMgc29sdXRpb24gaXMgc2lt aWxhciB0byBvbmUgaW1wbGVtZW50ZWQgaW4gdGhlIGF0X2hkbWFjLmMgZHJpdmVyCj4+IChhdGNf Z2V0X2J5dGVzX2xlZnQgZnVuY3Rpb24pLgo+Pgo+PiBZZXMgY291bGQgYmUgY29uc2lkZXIgYXMg YSB3b3JrYXJvdW5kIGZvciBhIGhhcmR3YXJlIGlzc3VlLi4uCj4+Cj4+IEluIHN0bTMyIERNQSBQ ZXJpcGhlcmFsLCB3ZSBjYW4gcmVnaXN0ZXIgdXAgdG8gMiBzZyBkZXNjcmlwdG9ycyAoc2cxICYK Pj4gc2cyKWluIERNQSByZWdpc3RlcnMsIGFuZCB1c2UgaXQgaW4gYSBjeWNsaWMgbW9kZSAoYXV0 byByZWxvYWQpLiBUaGlzCj4+IG1vZGUgaXMgbWFpbmx5IHVzZSBmb3IgYXVkaW8gdHJhbnNmZXIg aW5pdGlhdGVkIGJ5IGFuIEFMU0EgZHJpdmVyLgo+Pgo+PiA+RnJvbSBoYXJkd2FyZSBwb2ludCBv ZiB2aWV3IHRoZSBETUEgdHJhbnNmZXJzIGZpcnN0IGJsb2NrIGJhc2VkIG9uIHNnMSwKPj4gdGhl biBpdCB1cGRhdGVzIHJlZ2lzdGVycyB0byBwcmVwYXJlIHNnMiB0cmFuc2ZlciwgYW5kIHRoZW4g Z2VuZXJhdGVzIGFuCj4+IElSUSB0byBpbmZvcm0gdGhhdCBpdCBpc3N1ZXMgdGhlIG5leHQgdHJh bnNmZXIgKHNnMikuCj4+Cj4+IFRoZW4gZHJpdmVyIGNhbiB1cGRhdGUgc2cxIHRvIHByZXBhcmUg dGhlIHRoaXJkIHRyYW5zZmVyLi4uCj4+Cj4+IEluIHBhcmFsbGVsIHRoZSBjbGllbnQgZHJpdmVy IGNhbiByZXF1ZXN0cyBzdGF0dXMgdG8gZ2V0IHRoZSByZXNpZHVlIHRvCj4+IHVwZGF0ZSBpbnRl cm5hbCBwb2ludGVyLgo+PiBUaGUgaXNzdWUgaXMgaW4gdGhlIHJhY2UgY29uZGl0aW9uIGJldHdl ZW4gdGhlIGNhbGwgb2YgdGhlCj4+IGRldmljZV90eF9zdGF0dXMgb3BzIGFuZCB0aGUgdXBkYXRl IG9mIHRoZSBETUEgcmVnaXN0ZXIgb24gc2cgc3dpdGNoLgo+IAo+IFNvcnJ5IEkgZG8gbm90IGFn cmVlISBZb3UgYXJlIGluIHN0bTMyX2RtYV90eF9zdGF0dXMoKSBob2xkIHRoZSBsb2NrIGFuZAo+ IElSUXMgYXJlIGRpc2FibGVkLCBzbyBldmVuIGlmIHNnMiB3YXMgbG9hZGVkLCB5b3Ugd2lsbCBu b3QgZ2V0IGFuCj4gaW50ZXJydXB0IGFuZCB3b250IGtub3cuIEJ5IGxvb2tpbmcgYXQgc2cxIHJl Z2lzdGVyIHlvdSB3aWxsIHNlZSB0aGF0Cj4gc2cxIGlzIHRlbGxpbmcgeW91IHRoYXQgaXQgaGFz IGZpbmlzaGVkIGFuZCByZXNpZHVlIGNhbiBiZSB6ZXJvLiBUaGF0IGlzCj4gZmluZSBhbmQgY29y cmVjdCB0byByZXBvcnQuCj4gCj4gTW9zdCBpbXBvcnRhbnQgdGhpbmcgaGVyZSBpcyB0aGF0IHJl c2lkZSBpcyBmb3IgX3JlcXVlc3RlZF8gZGVzY3JpcHRvcgo+IGFuZCBub3QgX2N1cnJlbnRfIGRl c2NyaXB0b3IsIHNvIGxvb2tpbmcgaW50byBzZzIgZG9lc250IG5vdCBmaXQuCj4gCj4+IER1cmlu ZyBhIHNob3J0IHRpbWUgdGhlIGhhcmR3YXJlIHVwZGF0ZWQgdGhlIHJlZ2lzdGVycyBjb250YWlu aW5nIHRoZQo+PiBzZyBJRCBidXQgbm90IHRoZSB0cmFuc2ZlciBjb3VudGVyKFN4TkRUUikuIElu IHRoaXMgY2FzZSB0aGVyZSBpcyBhCj4+IG1pc21hdGNoIGJldHdlZW4gdGhlIFNnIElEIGFuZCB0 aGUgYXNzb2NpYXRlZCB0cmFuc2ZlciBjb3VudGVyLgo+PiBTbyByZXNpZHVlIGNhbGN1bGF0aW9u IGlzIHdyb25nLgo+PiBJZGVhIG9mIHRoaXMgcGF0Y2ggaXMgdG8gcGVyZm9ybSB0aGUgY2FsY3Vs YXRpb24gYW5kIHRoZW4gdG8gY3Jvc3NjaGVjawo+PiB0aGF0IHRoZSBoYXJkd2FyZSBoYXMgbm90 IHN3aXRjaGVkIHRvIHRoZSBuZXh0IHNnIGR1cmluZyB0aGUKPj4gY2FsY3VsYXRpb24uIFRoZSB3 YXkgdG8gY3Jvc3NjaGVjayBpcyB0byBjb21wYXJlIHRoZSB0aGUgc2cgSUQgYmVmb3JlCj4+IGFu ZCBhZnRlciB0aGUgY2FsY3VsYXRpb24uCj4+Cj4+IEkgdGVzdGVkIHRoZSBzb2x1dGlvbiB0byBm b3JjZSBhIG5ldyByZWNhbGN1bGF0aW9uIGJ1dCBubyByZWFsIHNvbHV0aW9uCj4+IHRvIHRydXN0 IHRoZSByZWdpc3RlcnMgZHVyaW5nIHRoaXMgcGhhc2UuIEluIHRoaXMgY2FzZSBhbiBhcHByb3hp bWF0aW9uCj4+IGlzIHRvIGNvbnNpZGVyIHRoYXQgdGhlIERNQSBpcyB0cmFuc2ZlcnJpbmcgdGhl IGZpcnN0IGJ5dGVzIG9mIHRoZSBuZXh0IHNnLgo+PiBTbyB3ZSByZXR1cm4gdGhlIHJlc2lkdWUg Y29ycmVzcG9uZGluZyB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBuZXh0IGJ1ZmZlci4KPiAKPiBB bmQgdGhhdCBpcyB3cm9uZyEuIFRoZSBhcmd1bWVudCBpcyAnY29va2llJyBhbmQgeW91IHJldHVy biByZXNpZHVlIGZvcgo+IHRoYXQgY29va2llLgo+IAo+IEZvciBleGFtcGxlLCBpZiB5b3UgaGF2 ZSBkbWEgdHhuIHdpdGggY29va2llIDEsIDIsIDMsIDQgc3VibWl0dGVkLCB0aGVuIGN1cnJlbnRs eSBIVwo+IGlzIHByb2Nlc3NpbmcgY29va2llIDIsIHRoZW4gZm9yIHR4X3N0YXR1cyBvbjoKPiBj b29raWUgMTogcmV0dXJuIERNQV9DT01QTEVURSwgcmVzaWR1ZSAwCj4gY29va2llIDI6IHJldHVy biBETUFfSU5fUFJPR1JFU1MsIHJlc2lkdWUgKHJlYWQgZnJvbSBIVykKPiBjb29raWUgMzogcmV0 dXJuIERNQV9JTl9QUk9HUkVTUywgcmVzaWR1ZSB0eG4gbGVuZ3RoCj4gY29va2llIDQ6IHJldHVy biBETUFfSU5fUFJPR1JFU1MsIHJlc2lkdWUgdHhuIGxlbmd0aAo+IAo+IFRoYW5rcwo+IApJIHRo aW5rIGkgbWlzcyBzb21ldGhpbmcgaW4gbXkgZXhwbGFuYXRpb24sIGFzIGZyb20gbXkgaHVtYmxl IFBPViAobm90CmVub3VnaCBleHBlcnQgaW4gRE1BIGZyYW1ld29yay4uLikgd2Ugb25seSBvbmUg Y29va2llIGhlcmUgYXMgb25seSBvbmUKY3ljbGljIHRyYW5zZmVyLi4uCgpSZWdhcmRpbmcgeW91 ciBhbnN3ZXJzIGl0IGxvb2tzIGxpa2UgbXkgc2cgZXhwbGFuYXRpb24gYXJlIG5vdCBjbGVhciBh bmQKaW50cm9kdWNlIGNvbmZ1c2lvbnMuLi4gU29ycnkgZm9yIHRoaXMsIGkgd2FzIHVzZWQgc2cg Zm9yIGludGVybmFsIFNUTTMyCkRNQSBkcml2ZXIsIG5vdCBmb3IgdGhlIGZyYW1ld29yayBBUEkg aXRzZWxmLgoKTGV0IHRyeSByZXRyeSB0byByZS1leHBsYWluIHlvdSB0aGUgc3RtMzIgRE1BIGN5 Y2xpYyBtb2RlIG1hbmFnZW1lbnQuCgpTVE0zMiBTVE0zMiBoYXJkd2FyZToKLS0tLS0tLS0tLS0t LS0tLS0tLQoocmVmIG1hbnVhbDoKaHR0cHM6Ly93d3cuc3QuY29tL2NvbnRlbnQvY2NjL3Jlc291 cmNlL3RlY2huaWNhbC9kb2N1bWVudC9yZWZlcmVuY2VfbWFudWFsL2dyb3VwMC81MS9iYS85ZS81 ZS83OC81Yi80Yi9kZC9ETTAwMzI3NjU5L2ZpbGVzL0RNMDAzMjc2NTkucGRmL2pjcjpjb250ZW50 L3RyYW5zbGF0aW9ucy9lbi5ETTAwMzI3NjU5LnBkZikKClRoZSBzdG0zMiBETUEgc3VwcG9ydHMg Y3ljbGljIG1vZGUgdXNpbmcgYSBoYXJkd2FyZSBkb3VibGUKYnVmZmVyIG1vZGUuCkluIHRoaXMg ZG91YmxlIGJ1ZmZlciwgd2UgY2FuIHByb2dyYW0gdXAgdG8gMiB0cmFuc2ZlcnMuIFdoZW4gb25l IGlzCmNvbXBsZXRlZCwgdGhlIERNQSBhdXRvbWF0aWNhbGx5IHN3aXRjaCBvbiB0aGUgb3RoZXIu IFRoaXMgY291bGQgYmUgc2VlCmFzIGEgaGFyZHdhcmUgTExJIHdpdGggb25seSAyIHRyYW5zZmVy IGRlc2NyaXB0b3JzLgpBIGhhcmR3YXJlIGJpdCBDVCAoY3VycmVudCB0YXJnZXQpIGlzIHVzZWQg dG8gZGV0ZXJtaW5lIHRoZQpjdXJyZW50IHRyYW5zZmVyIChDVCA9IDAgb3IgMSkuCkEgaGFyZHdh cmUgTkRUIChudW0gb2YgZGF0YSB0byB0cmFuc2ZlcikgY291bnRlciBjYW4gYmUgcmVhZCB0bwpk ZXRlcm1pbmUgRE1BIHBvc2l0aW9uIGluIGN1cnJlbnQgdHJhbnNmZXIuCkFuIElSUSBpcyBnZW5l cmF0ZWQgd2hlbiB0aGlzIENUIGJpdCBpcyB1cGRhdGVkIHRvIGFsbG93cyBkcml2ZXIgdG8KdXBk YXRlIHRoZSBkb3VibGUgYnVmZmVyIGZvciB0aGUgbmV4dCB0cmFuc2Zlci4KCk9uIGNsaWVudCBz aWRlIChhLmUgYXVkaW8pOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoZSBjbGllbnQgcmVx dWVzdHMgYSBjeWNsaWMgdHJhbnNmZXIgYnkgY2FsbGluZwpzdG0zMl9kbWFfcHJlcF9kbWFfY3lj bGljLiBGb3IgaW5zdGFuY2UgaXQgY2FuIHJlcXVlc3QgdGhlIHRyYW5zZmVyIG9mIGEKYnVmZmVy IGRpdmlkZWQgaW4gMTAgcGVyaW9kcy4gSW4gdGhpcyBjYXNlIG9ubHkgb25lIGNvb2tpZSBzdWJt aXR0ZWQKKHJpZ2h0PykuCgpBdCBzdG0zMmRtYSBkcml2ZXIgbGV2ZWwgdGhlc2UgMTAgcGVyaW9k cyBhcmUgcmVnaXN0ZXJlZCBpbiBhbiBpbnRlcm5hbApzb2Z0d2FyZSB0YWJsZSAoZGVzYy0+c2df cmVxW10pLkFzIGN5Y2xpYywgdGhlIGxhc3Qgc2dfcmVxIHBvaW50IHRvIHRoZQpmaXJzdCBvbmUu CgpTbyB0byBiZSBhYmxlIHRvIHRyYW5zZmVyIHRoZSB3aG9sZSBzb2Z0d2FyZSB0YWJsZSwgd2Ug aGF2ZSB0byB1cGRhdGUKdGhlIFNUTTMyIERNQSBkb3VibGUgYnVmZmVyIGF0IGVhY2ggZW5kIG9m IHRyYW5zZmVyIHBlcmlvZC4KVGhlIGZpbGVkIGNoYW4tPm5leHRfc2cgcG9pbnRzIHRvIHRoZSBu ZXh0IHNnX3JlcSBpbiB0aGUgc29mdHdhcmUgdGFibGUuCnRoYXQgc2hvdWxkIGJlIHdyaXRlIGlu IHRoZSBTVE0zMiBETUEgZG91YmxlIGJ1ZmZlci4KClJlc2lkdWUgY2FsY3VsYXRpb246Ci0tLS0t LS0tLS0tLS0tLS0tLS0KRHVyaW5nIGEgdHJhbnNmZXIgd2UgY2FuIGdldCB0aGUgcG9zaXRpb24g aW4gYSBwZXJpb2QgdGhhbmtzIHRvIHRoZQpORFQobnVtIG9mIGRhdGEgdG8gdHJhbnNmZXIpIGJp dC1maWVsZC4KClNvIHRoZSBjYWxjdWxhdGlvbiBpcyA6CjEpIEdldCB0aGUgTkRUIGZpZWxkIHZh bHVlCjMpIGFkZCB0aGUgcGVyaW9kcyByZW1haW5pbmcgaW4gdGhlIGRlc2MtPnNnX3JlcVtdIHRh YmxlLgoKSW4gcGFyYWxsZWwgdGhlIFNUTTMyIERNQSBoYXJkd2FyZSB1cGRhdGVzIHRoZSB0cmFu c2ZlciBidWZmZXIgaW4gMyBzdGVwczoKMSkgdXBkYXRlIENUIHJlZ2lzdGVyIGZpZWxkLgoyKSBV cGRhdGUgTkRUIHJlZ2lzdGVyIGZpZWxkLgozKSBnZW5lcmF0ZSB0aGUgSVJRIChBcyB5b3UgbWVu dGlvbiB0aGUgSVJRIGlzIG5vdCB0cmVhdGVkIGR1cmluZyB0aGUKZGV2aWNlX3R4X3N0YXR1cyBh cyBwcm90ZWN0ZWQgZnJvbSBpbnRlcnJ1cHRzKS4KCldlIGFyZSBmYWNpbmcgaXNzdWUgd2hlbiBj b21wdXRpbmcgdGhlIHJlc2lkdWUgZHVyaW5nIHRoZSB1cGRhdGUgb2YgdGhlCkNUIGFuZCB0aGUg TkRULiBUaGUgQ1QgYW5kIE5EVCBjYW4gYXMgYmVlbiB1cGRhdGVkICggYm90aCBvciBvbmx5IENU Li4uKQp3aXRob3V0IGRyaXZlciBjb250ZXh0IHVwZGF0ZSAoSVJRIGRpc2FibGVkKS4KSW4gdGhp cyBjYXNlIHdlIGNhbiBwb2ludCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBjdXJyZW50IHRyYW5z ZmVyKApjb21wbGV0ZWQpIGluc3RlYWQgb2YgdGhlIG5leHRfdHJhbnNmZXIuIFRoaXMgZ2VuZXJh dGVzIGEgcmVzaWR1ZSBlcnJvcgphbmQgZm9yIGF1ZGlvIGEgdGltZS1zdGFtcCByZWdyZXNzaW9u IChzbyB2aWRlbyBmcmVlemUgb3IgYXVkaW8gcGxvcCkuCgpTbyB0aGUgcGF0Y2ggcHJvcG9zZWQg Y29uc2lzdHMgaW46CjEpIGdldHRpbmcgdGhlIGN1cnJlbnQgTkRUIHZhbHVlCjIpIHJlYWRpbmcg Q1QgYW5kIGNoZWNrIHRoYXQgdGhlIGhhcmR3YXJlIGRvZXMgbm90IHBvaW50IHRvIHRoZSBuZXh0 X3NnLgoJaWYgeWVzOgoJLSBDVCBoYXMgYmVlbiB1cGRhdGVkIGJ5IGhhcmR3YXJlIGJ1dCBJUlEg c3RpbGwgbm90IHRyZWF0ZWQuCgktIEJ5IGRlZmF1bHQgd2UgY29uc2lkZXIgdGhlIGN1cnJlbnRf c2cgYXMgY29tcGxldGVkLCBzbyB3ZQoJICBwb2ludCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBu ZXh0X3NnIGJ1ZmZlci4KCkhvcGUgdGhhdCB3aWxsIGhlbHAgdG8gY2xhcmlmeS4KVGhhbmtzCmFy bmF1ZAo= 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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, 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 95416C43219 for ; Mon, 29 Apr 2019 14:53:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50B4720656 for ; Mon, 29 Apr 2019 14:53:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=st.com header.i=@st.com header.b="eElTUTRN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728376AbfD2OxC (ORCPT ); Mon, 29 Apr 2019 10:53:02 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:43814 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728339AbfD2OxC (ORCPT ); Mon, 29 Apr 2019 10:53:02 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3TEkhZ8010167; Mon, 29 Apr 2019 16:52:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=TyPRd72EOTNxUHmCFP26ytz0WAo+pQKVeLQsjdaqgnk=; b=eElTUTRNNmM5K+IXe/iJ9+ne/67zKFY0vPqXABt8HzZ0tAM8KhSpDCvnu+HDdyf15AP1 X+tv3g03fJgAzFSn4d8JrI7fJnYh05t3cjqS9JGv4nZFnCegbJtA6u6bZ0Ll4weypwhY K7180Q169y3lc8bSuRYkfLlPO8ceQq2F+MsAl4hIExqFH3ecnEqcF+Xm1tNIoVvpRVKz zLUI7GXiZGLwC8bflVL3jw/fYFc6OLn7FVxIy/ovxq9VRlLNYj1c1utPnnbsyvKoyL1h XYZTkLvF040jy2s6uiBjtKWKPz1eJGS0sNVODGQUSBtkHkfX1A4uvQAbAOwDCn4XBFLB CA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 2s61r08hhu-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Apr 2019 16:52:52 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 252FB31; Mon, 29 Apr 2019 14:52:52 +0000 (GMT) Received: from Webmail-eu.st.com (sfhdag3node1.st.com [10.75.127.7]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id ED593272F; Mon, 29 Apr 2019 14:52:51 +0000 (GMT) Received: from [10.48.0.131] (10.75.127.50) by SFHDAG3NODE1.st.com (10.75.127.7) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 29 Apr 2019 16:52:51 +0200 Subject: Re: [PATCH] dmaengine: stm32-dma: fix residue calculation in stm32-dma To: Vinod Koul CC: Dan Williams , Pierre-Yves MORDRET , , , References: <1553689316-6231-1-git-send-email-arnaud.pouliquen@st.com> <20190426121751.GC28103@vkoul-mobl> <6894b54e-651f-1caf-d363-79d1ef0eee14@st.com> <20190429051310.GC3845@vkoul-mobl.Dlink> From: Arnaud Pouliquen Openpgp: preference=signencrypt Autocrypt: addr=arnaud.pouliquen@st.com; prefer-encrypt=mutual; keydata= xsFNBFZu+HIBEAC/bt4pnj18oKkUw40q1IXSPeDFOuuznWgFbjFS6Mrb8axwtnxeYicv0WAL rWhlhQ6W2TfKDJtkDygkfaZw7Nlsj57zXrzjVXuy4Vkezxtg7kvSLYItQAE8YFSOrBTL58Yd d5cAFz/9WbWGRf0o9MxFavvGQ9zkfHVd+Ytw6dJNP4DUys9260BoxKZZMaevxobh5Hnram6M gVBYGMuJf5tmkXD/FhxjWEZ5q8pCfqZTlN9IZn7S8d0tyFL7+nkeYldA2DdVplfXXieEEURQ aBjcZ7ZTrzu1X/1RrH1tIQE7dclxk5pr2xY8osNePmxSoi+4DJzpZeQ32U4wAyZ8Hs0i50rS VxZuT2xW7tlNcw147w+kR9+xugXrECo0v1uX7/ysgFnZ/YasN8E+osM2sfa7OYUloVX5KeUK yT58KAVkjUfo0OdtSmGkEkILWQLACFEFVJPz7/I8PisoqzLS4Jb8aXbrwgIg7d4NDgW2FddV X9jd1odJK5N68SZqRF+I8ndttRGK0o7NZHH4hxJg9jvyEELdgQAmjR9Vf0eZGNfowLCnVcLq s+8q3nQ1RrW5cRBgB8YT2kC8wwY5as8fhfp4846pe2b8Akh0+Vba5pXaTvtmdOMRrcS7CtF6 Ogf9zKAxPZxTp0qGUOLE3PmSc3P3FQBLYa6Y+uS2v2iZTXljqQARAQABzSpBcm5hdWQgUG91 bGlxdWVuIDxhcm5hdWQucG91bGlxdWVuQHN0LmNvbT7CwX4EEwECACgFAlZu+HICGyMFCQlm AYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEP0ZQ+DAfqbfdXgP/RN0bU0gq3Pm1uAO 4LejmGbYeTi5OSKh7niuFthrlgUvzR4UxMbUBk30utQAd/FwYPHR81mE9N4PYEWKWMW0T3u0 5ASOBLpQeWj+edSE50jLggclVa4qDMl0pTfyLKOodt8USNB8aF0aDg5ITkt0euaGFaPn2kOZ QWVN+9a5O2MzNR3Sm61ojM2WPuB1HobbrCFzCT+VQDy4FLU0rsTjTanf6zpZdOeabt0LfWxF M69io06vzNSHYH91RJVl9mkIz7bYEZTBQR23KjLCsRXWfZ+54x6d6ITYZ2hp965PWuAhwWQr DdTJ3gPxmXJ7xK9+O15+DdUAbxF9FJXvvt9U5pTk3taTM3FIp/qaw77uxI/wniYA0dnIJRX0 o51sjR6cCO6hwLciO7+Q0OCDCbtStuKCCCTZY5bF6fuEqgybDwvLGAokYIdoMagJu1DLKu4p seKgPqGZ4vouTmEp6cWMzSyRz4pf3xIJc5McsdrUTN2LtcX63E45xKaj/n0Neft/Ce7OuyLB rr0ujOrVlWsLwyzpU5w5dX7bzkEW1Hp4mv44EDxH9zRiyI5dNPpLf57I83Vs/qP4bpy7/Hm1 fqbuM0wMbOquPGFI8fcYTkghntAAXMqNE6IvETzYqsPZwT0URpOzM9mho8u5+daFWWAuUXGA qRbo7qRs8Ev5jDsKBvGhzsFNBFZu+HIBEACrw5wF7Uf1h71YD5Jk7BG+57rpvnrLGk2s+YVW zmKsZPHT68SlMOy8/3gptJWgddHaM5xRLFsERswASmnJjIdPTOkSkVizfAjrFekZUr+dDZi2 3PrISz8AQBd+uJ29jRpeqViLiV+PrtCHnAKM0pxQ1BOv8TVlkfO7tZVduLJl5mVoz1sq3/C7 hT5ZICc2REWrfS24/Gk8mmtvMybiTMyM0QLFZvWyvNCvcGUS8s2a8PIcr+Xb3R9H0hMnYc2E 7bc5/e39f8oTbKI6xLLFLa5yJEVfTiVksyCkzpJSHo2eoVdW0lOtIlcUz1ICgZ7vVJg7chmQ nPmubeBMw73EyvagdzVeLm8Y/6Zux8SRab+ZcU/ZQWNPKoW5clUvagFBQYJ6I2qEoh2PqBI4 Wx0g1ca7ZIwjsIfWS7L3e310GITBsDmIeUJqMkfIAregf8KADPs4+L71sLeOXvjmdgTsHA8P lK8kUxpbIaTrGgHoviJ1IYwOvJBWrZRhdjfXTPl+ZFrJiB2E55XXogAAF4w/XHpEQNGkAXdQ u0o6tFkJutsJoU75aHPA4q/OvRlEiU6/8LNJeqRAR7oAvTexpO70f0Jns9GHzoy8sWbnp/LD BSH5iRCwq6Q0hJiEzrVTnO3bBp0WXfgowjXqR+YR86JPrzw2zjgr1e2zCZ1gHBTOyJZiDwAR AQABwsFlBBgBAgAPBQJWbvhyAhsMBQkJZgGAAAoJEP0ZQ+DAfqbfs5AQAJKIr2+j+U3JaMs3 px9bbxcuxRLtVP5gR3FiPR0onalO0QEOLKkXb1DeJaeHHxDdJnVV7rCJX/Fz5CzkymUJ7GIO gpUGstSpJETi2sxvYvxfmTvE78D76rM5duvnGy8lob6wR2W3IqIRwmd4X0Cy1Gtgo+i2plh2 ttVOM3OoigkCPY3AGD0ts+FbTn1LBVeivaOorezSGpKXy3cTKrEY9H5PC+DRJ1j3nbodC3o6 peWAlfCXVtErSQ17QzNydFDOysL1GIVn0+XY7X4Bq+KpVmhQOloEX5/At4FlhOpsv9AQ30rZ 3F5lo6FG1EqLIvg4FnMJldDmszZRv0bR0RM9Ag71J9bgwHEn8uS2vafuL1hOazZ0eAo7Oyup 2VNRC7Inbc+irY1qXSjmq3ZrD3SSZVa+LhYfijFYuEgKjs4s+Dvk/xVL0JYWbKkpGWRz5M82 Pj7co6u8pTEReGBYSVUBHx7GF1e3L/IMZZMquggEsixD8CYMOzahCEZ7UUwD5LKxRfmBWBgK 36tfTyducLyZtGB3mbJYfWeI7aiFgYsd5ehov6OIBlOz5iOshd97+wbbmziYEp6jWMIMX+Em zqSvS5ETZydayO5JBbw7fFBd1nGVYk1WL6Ll72g+iEnqgIckMtxey1TgfT7GhPkR7hl54ZAe 8mOik8I/F6EW8XyQAA2P Message-ID: <26fa7710-76cb-e202-a367-c2e2408b6808@st.com> Date: Mon, 29 Apr 2019 16:52:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190429051310.GC3845@vkoul-mobl.Dlink> Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG8NODE3.st.com (10.75.127.24) To SFHDAG3NODE1.st.com (10.75.127.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-29_08:,, signatures=0 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Message-ID: <20190429145250.3XUyZBDv5I6mGLwcrMDuhn32kLXluKzKF4E_pF-Yfjk@z> On 4/29/19 7:13 AM, Vinod Koul wrote: > On 26-04-19, 15:41, Arnaud Pouliquen wrote: >>>> During residue calculation. the DMA can switch to the next sg. When >>>> this race condition occurs, the residue returned value is not valid. >>>> Indeed the position in the sg returned by the hardware is the position >>>> of the next sg, not the current sg. >>>> Solution is to check the sg after the calculation to verify it. >>>> If a transition is detected we consider that the DMA has switched to >>>> the beginning of next sg. >>> >>> Now, that sounds like duct tape. Why should we bother doing that. >>> >>> Also looking back at the stm32_dma_desc_residue() and calls to it from >>> stm32_dma_tx_status() am not sure we are doing the right thing >> Please, could you explain what you have in mind here? > > So when we call vchan_find_desc() that tells us if the descriptor is in > the issued queue or not.. Ideally it should not matter if we have one > or N descriptors issued to hardware. > > So why should you bother checking for next_sg. > >>> why are we looking at next_sg here, can you explain me that please >> >> This solution is similar to one implemented in the at_hdmac.c driver >> (atc_get_bytes_left function). >> >> Yes could be consider as a workaround for a hardware issue... >> >> In stm32 DMA Peripheral, we can register up to 2 sg descriptors (sg1 & >> sg2)in DMA registers, and use it in a cyclic mode (auto reload). This >> mode is mainly use for audio transfer initiated by an ALSA driver. >> >> >From hardware point of view the DMA transfers first block based on sg1, >> then it updates registers to prepare sg2 transfer, and then generates an >> IRQ to inform that it issues the next transfer (sg2). >> >> Then driver can update sg1 to prepare the third transfer... >> >> In parallel the client driver can requests status to get the residue to >> update internal pointer. >> The issue is in the race condition between the call of the >> device_tx_status ops and the update of the DMA register on sg switch. > > Sorry I do not agree! You are in stm32_dma_tx_status() hold the lock and > IRQs are disabled, so even if sg2 was loaded, you will not get an > interrupt and wont know. By looking at sg1 register you will see that > sg1 is telling you that it has finished and residue can be zero. That is > fine and correct to report. > > Most important thing here is that reside is for _requested_ descriptor > and not _current_ descriptor, so looking into sg2 doesnt not fit. > >> During a short time the hardware updated the registers containing the >> sg ID but not the transfer counter(SxNDTR). In this case there is a >> mismatch between the Sg ID and the associated transfer counter. >> So residue calculation is wrong. >> Idea of this patch is to perform the calculation and then to crosscheck >> that the hardware has not switched to the next sg during the >> calculation. The way to crosscheck is to compare the the sg ID before >> and after the calculation. >> >> I tested the solution to force a new recalculation but no real solution >> to trust the registers during this phase. In this case an approximation >> is to consider that the DMA is transferring the first bytes of the next sg. >> So we return the residue corresponding to the beginning of the next buffer. > > And that is wrong!. The argument is 'cookie' and you return residue for > that cookie. > > For example, if you have dma txn with cookie 1, 2, 3, 4 submitted, then currently HW > is processing cookie 2, then for tx_status on: > cookie 1: return DMA_COMPLETE, residue 0 > cookie 2: return DMA_IN_PROGRESS, residue (read from HW) > cookie 3: return DMA_IN_PROGRESS, residue txn length > cookie 4: return DMA_IN_PROGRESS, residue txn length > > Thanks > I think i miss something in my explanation, as from my humble POV (not enough expert in DMA framework...) we only one cookie here as only one cyclic transfer... Regarding your answers it looks like my sg explanation are not clear and introduce confusions... Sorry for this, i was used sg for internal STM32 DMA driver, not for the framework API itself. Let try retry to re-explain you the stm32 DMA cyclic mode management. STM32 STM32 hardware: ------------------- (ref manual: https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/51/ba/9e/5e/78/5b/4b/dd/DM00327659/files/DM00327659.pdf/jcr:content/translations/en.DM00327659.pdf) The stm32 DMA supports cyclic mode using a hardware double buffer mode. In this double buffer, we can program up to 2 transfers. When one is completed, the DMA automatically switch on the other. This could be see as a hardware LLI with only 2 transfer descriptors. A hardware bit CT (current target) is used to determine the current transfer (CT = 0 or 1). A hardware NDT (num of data to transfer) counter can be read to determine DMA position in current transfer. An IRQ is generated when this CT bit is updated to allows driver to update the double buffer for the next transfer. On client side (a.e audio): ------------------------- The client requests a cyclic transfer by calling stm32_dma_prep_dma_cyclic. For instance it can request the transfer of a buffer divided in 10 periods. In this case only one cookie submitted (right?). At stm32dma driver level these 10 periods are registered in an internal software table (desc->sg_req[]).As cyclic, the last sg_req point to the first one. So to be able to transfer the whole software table, we have to update the STM32 DMA double buffer at each end of transfer period. The filed chan->next_sg points to the next sg_req in the software table. that should be write in the STM32 DMA double buffer. Residue calculation: ------------------- During a transfer we can get the position in a period thanks to the NDT(num of data to transfer) bit-field. So the calculation is : 1) Get the NDT field value 3) add the periods remaining in the desc->sg_req[] table. In parallel the STM32 DMA hardware updates the transfer buffer in 3 steps: 1) update CT register field. 2) Update NDT register field. 3) generate the IRQ (As you mention the IRQ is not treated during the device_tx_status as protected from interrupts). We are facing issue when computing the residue during the update of the CT and the NDT. The CT and NDT can as been updated ( both or only CT...) without driver context update (IRQ disabled). In this case we can point to the beginning of the current transfer( completed) instead of the next_transfer. This generates a residue error and for audio a time-stamp regression (so video freeze or audio plop). So the patch proposed consists in: 1) getting the current NDT value 2) reading CT and check that the hardware does not point to the next_sg. if yes: - CT has been updated by hardware but IRQ still not treated. - By default we consider the current_sg as completed, so we point to the beginning of the next_sg buffer. Hope that will help to clarify. Thanks arnaud