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: Vinod Koul Message-Id: <20190430082255.GP3845@vkoul-mobl.Dlink> Date: Tue, 30 Apr 2019 13:52:55 +0530 To: Arnaud Pouliquen Cc: Dan Williams , Pierre-Yves MORDRET , linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org List-ID: T24gMjktMDQtMTksIDE2OjUyLCBBcm5hdWQgUG91bGlxdWVuIHdyb3RlOgo+IAo+IAo+IE9uIDQv MjkvMTkgNzoxMyBBTSwgVmlub2QgS291bCB3cm90ZToKPiA+IE9uIDI2LTA0LTE5LCAxNTo0MSwg QXJuYXVkIFBvdWxpcXVlbiB3cm90ZToKPiA+Pj4+IER1cmluZyByZXNpZHVlIGNhbGN1bGF0aW9u LiB0aGUgRE1BIGNhbiBzd2l0Y2ggdG8gdGhlIG5leHQgc2cuIFdoZW4KPiA+Pj4+IHRoaXMgcmFj ZSBjb25kaXRpb24gb2NjdXJzLCB0aGUgcmVzaWR1ZSByZXR1cm5lZCB2YWx1ZSBpcyBub3QgdmFs aWQuCj4gPj4+PiBJbmRlZWQgdGhlIHBvc2l0aW9uIGluIHRoZSBzZyByZXR1cm5lZCBieSB0aGUg aGFyZHdhcmUgaXMgdGhlIHBvc2l0aW9uCj4gPj4+PiBvZiB0aGUgbmV4dCBzZywgbm90IHRoZSBj dXJyZW50IHNnLgo+ID4+Pj4gU29sdXRpb24gaXMgdG8gY2hlY2sgdGhlIHNnIGFmdGVyIHRoZSBj YWxjdWxhdGlvbiB0byB2ZXJpZnkgaXQuCj4gPj4+PiBJZiBhIHRyYW5zaXRpb24gaXMgZGV0ZWN0 ZWQgd2UgY29uc2lkZXIgdGhhdCB0aGUgRE1BIGhhcyBzd2l0Y2hlZCB0bwo+ID4+Pj4gdGhlIGJl Z2lubmluZyBvZiBuZXh0IHNnLgo+ID4+Pgo+ID4+PiBOb3csIHRoYXQgc291bmRzIGxpa2UgZHVj dCB0YXBlLiBXaHkgc2hvdWxkIHdlIGJvdGhlciBkb2luZyB0aGF0Lgo+ID4+Pgo+ID4+PiBBbHNv IGxvb2tpbmcgYmFjayBhdCB0aGUgc3RtMzJfZG1hX2Rlc2NfcmVzaWR1ZSgpIGFuZCBjYWxscyB0 byBpdCBmcm9tCj4gPj4+IHN0bTMyX2RtYV90eF9zdGF0dXMoKSBhbSBub3Qgc3VyZSB3ZSBhcmUg ZG9pbmcgdGhlIHJpZ2h0IHRoaW5nCj4gPj4gUGxlYXNlLCBjb3VsZCB5b3UgZXhwbGFpbiB3aGF0 IHlvdSBoYXZlIGluIG1pbmQgaGVyZT8KPiA+IAo+ID4gU28gd2hlbiB3ZSBjYWxsIHZjaGFuX2Zp bmRfZGVzYygpIHRoYXQgdGVsbHMgdXMgaWYgdGhlIGRlc2NyaXB0b3IgaXMgaW4KPiA+IHRoZSBp c3N1ZWQgcXVldWUgb3Igbm90Li4gIElkZWFsbHkgaXQgc2hvdWxkIG5vdCBtYXR0ZXIgaWYgd2Ug aGF2ZSBvbmUKPiA+IG9yIE4gZGVzY3JpcHRvcnMgaXNzdWVkIHRvIGhhcmR3YXJlLgo+ID4gCj4g PiBTbyB3aHkgc2hvdWxkIHlvdSBib3RoZXIgY2hlY2tpbmcgZm9yIG5leHRfc2cuCj4gPiAKPiA+ Pj4gd2h5IGFyZSB3ZSBsb29raW5nIGF0IG5leHRfc2cgaGVyZSwgY2FuIHlvdSBleHBsYWluIG1l IHRoYXQgcGxlYXNlCj4gPj4KPiA+PiBUaGlzIHNvbHV0aW9uIGlzIHNpbWlsYXIgdG8gb25lIGlt cGxlbWVudGVkIGluIHRoZSBhdF9oZG1hYy5jIGRyaXZlcgo+ID4+IChhdGNfZ2V0X2J5dGVzX2xl ZnQgZnVuY3Rpb24pLgo+ID4+Cj4gPj4gWWVzIGNvdWxkIGJlIGNvbnNpZGVyIGFzIGEgd29ya2Fy b3VuZCBmb3IgYSBoYXJkd2FyZSBpc3N1ZS4uLgo+ID4+Cj4gPj4gSW4gc3RtMzIgRE1BIFBlcmlw aGVyYWwsIHdlIGNhbiByZWdpc3RlciB1cCB0byAyIHNnIGRlc2NyaXB0b3JzIChzZzEgJgo+ID4+ IHNnMilpbiBETUEgcmVnaXN0ZXJzLCBhbmQgdXNlIGl0IGluIGEgY3ljbGljIG1vZGUgKGF1dG8g cmVsb2FkKS4gVGhpcwo+ID4+IG1vZGUgaXMgbWFpbmx5IHVzZSBmb3IgYXVkaW8gdHJhbnNmZXIg aW5pdGlhdGVkIGJ5IGFuIEFMU0EgZHJpdmVyLgo+ID4+Cj4gPj4gPkZyb20gaGFyZHdhcmUgcG9p bnQgb2YgdmlldyB0aGUgRE1BIHRyYW5zZmVycyBmaXJzdCBibG9jayBiYXNlZCBvbiBzZzEsCj4g Pj4gdGhlbiBpdCB1cGRhdGVzIHJlZ2lzdGVycyB0byBwcmVwYXJlIHNnMiB0cmFuc2ZlciwgYW5k IHRoZW4gZ2VuZXJhdGVzIGFuCj4gPj4gSVJRIHRvIGluZm9ybSB0aGF0IGl0IGlzc3VlcyB0aGUg bmV4dCB0cmFuc2ZlciAoc2cyKS4KPiA+Pgo+ID4+IFRoZW4gZHJpdmVyIGNhbiB1cGRhdGUgc2cx IHRvIHByZXBhcmUgdGhlIHRoaXJkIHRyYW5zZmVyLi4uCj4gPj4KPiA+PiBJbiBwYXJhbGxlbCB0 aGUgY2xpZW50IGRyaXZlciBjYW4gcmVxdWVzdHMgc3RhdHVzIHRvIGdldCB0aGUgcmVzaWR1ZSB0 bwo+ID4+IHVwZGF0ZSBpbnRlcm5hbCBwb2ludGVyLgo+ID4+IFRoZSBpc3N1ZSBpcyBpbiB0aGUg cmFjZSBjb25kaXRpb24gYmV0d2VlbiB0aGUgY2FsbCBvZiB0aGUKPiA+PiBkZXZpY2VfdHhfc3Rh dHVzIG9wcyBhbmQgdGhlIHVwZGF0ZSBvZiB0aGUgRE1BIHJlZ2lzdGVyIG9uIHNnIHN3aXRjaC4K PiA+IAo+ID4gU29ycnkgSSBkbyBub3QgYWdyZWUhIFlvdSBhcmUgaW4gc3RtMzJfZG1hX3R4X3N0 YXR1cygpIGhvbGQgdGhlIGxvY2sgYW5kCj4gPiBJUlFzIGFyZSBkaXNhYmxlZCwgc28gZXZlbiBp ZiBzZzIgd2FzIGxvYWRlZCwgeW91IHdpbGwgbm90IGdldCBhbgo+ID4gaW50ZXJydXB0IGFuZCB3 b250IGtub3cuIEJ5IGxvb2tpbmcgYXQgc2cxIHJlZ2lzdGVyIHlvdSB3aWxsIHNlZSB0aGF0Cj4g PiBzZzEgaXMgdGVsbGluZyB5b3UgdGhhdCBpdCBoYXMgZmluaXNoZWQgYW5kIHJlc2lkdWUgY2Fu IGJlIHplcm8uIFRoYXQgaXMKPiA+IGZpbmUgYW5kIGNvcnJlY3QgdG8gcmVwb3J0Lgo+ID4gCj4g PiBNb3N0IGltcG9ydGFudCB0aGluZyBoZXJlIGlzIHRoYXQgcmVzaWRlIGlzIGZvciBfcmVxdWVz dGVkXyBkZXNjcmlwdG9yCj4gPiBhbmQgbm90IF9jdXJyZW50XyBkZXNjcmlwdG9yLCBzbyBsb29r aW5nIGludG8gc2cyIGRvZXNudCBub3QgZml0Lgo+ID4gCj4gPj4gRHVyaW5nIGEgc2hvcnQgdGlt ZSB0aGUgaGFyZHdhcmUgdXBkYXRlZCB0aGUgcmVnaXN0ZXJzIGNvbnRhaW5pbmcgdGhlCj4gPj4g c2cgSUQgYnV0IG5vdCB0aGUgdHJhbnNmZXIgY291bnRlcihTeE5EVFIpLiBJbiB0aGlzIGNhc2Ug dGhlcmUgaXMgYQo+ID4+IG1pc21hdGNoIGJldHdlZW4gdGhlIFNnIElEIGFuZCB0aGUgYXNzb2Np YXRlZCB0cmFuc2ZlciBjb3VudGVyLgo+ID4+IFNvIHJlc2lkdWUgY2FsY3VsYXRpb24gaXMgd3Jv bmcuCj4gPj4gSWRlYSBvZiB0aGlzIHBhdGNoIGlzIHRvIHBlcmZvcm0gdGhlIGNhbGN1bGF0aW9u IGFuZCB0aGVuIHRvIGNyb3NzY2hlY2sKPiA+PiB0aGF0IHRoZSBoYXJkd2FyZSBoYXMgbm90IHN3 aXRjaGVkIHRvIHRoZSBuZXh0IHNnIGR1cmluZyB0aGUKPiA+PiBjYWxjdWxhdGlvbi4gVGhlIHdh eSB0byBjcm9zc2NoZWNrIGlzIHRvIGNvbXBhcmUgdGhlIHRoZSBzZyBJRCBiZWZvcmUKPiA+PiBh bmQgYWZ0ZXIgdGhlIGNhbGN1bGF0aW9uLgo+ID4+Cj4gPj4gSSB0ZXN0ZWQgdGhlIHNvbHV0aW9u IHRvIGZvcmNlIGEgbmV3IHJlY2FsY3VsYXRpb24gYnV0IG5vIHJlYWwgc29sdXRpb24KPiA+PiB0 byB0cnVzdCB0aGUgcmVnaXN0ZXJzIGR1cmluZyB0aGlzIHBoYXNlLiBJbiB0aGlzIGNhc2UgYW4g YXBwcm94aW1hdGlvbgo+ID4+IGlzIHRvIGNvbnNpZGVyIHRoYXQgdGhlIERNQSBpcyB0cmFuc2Zl cnJpbmcgdGhlIGZpcnN0IGJ5dGVzIG9mIHRoZSBuZXh0IHNnLgo+ID4+IFNvIHdlIHJldHVybiB0 aGUgcmVzaWR1ZSBjb3JyZXNwb25kaW5nIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIG5leHQgYnVm ZmVyLgo+ID4gCj4gPiBBbmQgdGhhdCBpcyB3cm9uZyEuIFRoZSBhcmd1bWVudCBpcyAnY29va2ll JyBhbmQgeW91IHJldHVybiByZXNpZHVlIGZvcgo+ID4gdGhhdCBjb29raWUuCj4gPiAKPiA+IEZv ciBleGFtcGxlLCBpZiB5b3UgaGF2ZSBkbWEgdHhuIHdpdGggY29va2llIDEsIDIsIDMsIDQgc3Vi bWl0dGVkLCB0aGVuIGN1cnJlbnRseSBIVwo+ID4gaXMgcHJvY2Vzc2luZyBjb29raWUgMiwgdGhl biBmb3IgdHhfc3RhdHVzIG9uOgo+ID4gY29va2llIDE6IHJldHVybiBETUFfQ09NUExFVEUsIHJl c2lkdWUgMAo+ID4gY29va2llIDI6IHJldHVybiBETUFfSU5fUFJPR1JFU1MsIHJlc2lkdWUgKHJl YWQgZnJvbSBIVykKPiA+IGNvb2tpZSAzOiByZXR1cm4gRE1BX0lOX1BST0dSRVNTLCByZXNpZHVl IHR4biBsZW5ndGgKPiA+IGNvb2tpZSA0OiByZXR1cm4gRE1BX0lOX1BST0dSRVNTLCByZXNpZHVl IHR4biBsZW5ndGgKPiA+IAo+ID4gVGhhbmtzCj4gPiAKPiBJIHRoaW5rIGkgbWlzcyBzb21ldGhp bmcgaW4gbXkgZXhwbGFuYXRpb24sIGFzIGZyb20gbXkgaHVtYmxlIFBPViAobm90Cj4gZW5vdWdo IGV4cGVydCBpbiBETUEgZnJhbWV3b3JrLi4uKSB3ZSBvbmx5IG9uZSBjb29raWUgaGVyZSBhcyBv bmx5IG9uZQo+IGN5Y2xpYyB0cmFuc2Zlci4uLgoKPiBSZWdhcmRpbmcgeW91ciBhbnN3ZXJzIGl0 IGxvb2tzIGxpa2UgbXkgc2cgZXhwbGFuYXRpb24gYXJlIG5vdCBjbGVhciBhbmQKPiBpbnRyb2R1 Y2UgY29uZnVzaW9ucy4uLiBTb3JyeSBmb3IgdGhpcywgaSB3YXMgdXNlZCBzZyBmb3IgaW50ZXJu YWwgU1RNMzIKPiBETUEgZHJpdmVyLCBub3QgZm9yIHRoZSBmcmFtZXdvcmsgQVBJIGl0c2VsZi4K PiAKPiBMZXQgdHJ5IHJldHJ5IHRvIHJlLWV4cGxhaW4geW91IHRoZSBzdG0zMiBETUEgY3ljbGlj IG1vZGUgbWFuYWdlbWVudC4KPiAKPiBTVE0zMiBTVE0zMiBoYXJkd2FyZToKPiAtLS0tLS0tLS0t LS0tLS0tLS0tCj4gKHJlZiBtYW51YWw6Cj4gaHR0cHM6Ly93d3cuc3QuY29tL2NvbnRlbnQvY2Nj L3Jlc291cmNlL3RlY2huaWNhbC9kb2N1bWVudC9yZWZlcmVuY2VfbWFudWFsL2dyb3VwMC81MS9i YS85ZS81ZS83OC81Yi80Yi9kZC9ETTAwMzI3NjU5L2ZpbGVzL0RNMDAzMjc2NTkucGRmL2pjcjpj b250ZW50L3RyYW5zbGF0aW9ucy9lbi5ETTAwMzI3NjU5LnBkZikKPiAKPiBUaGUgc3RtMzIgRE1B IHN1cHBvcnRzIGN5Y2xpYyBtb2RlIHVzaW5nIGEgaGFyZHdhcmUgZG91YmxlCj4gYnVmZmVyIG1v ZGUuCj4gSW4gdGhpcyBkb3VibGUgYnVmZmVyLCB3ZSBjYW4gcHJvZ3JhbSB1cCB0byAyIHRyYW5z ZmVycy4gV2hlbiBvbmUgaXMKPiBjb21wbGV0ZWQsIHRoZSBETUEgYXV0b21hdGljYWxseSBzd2l0 Y2ggb24gdGhlIG90aGVyLiBUaGlzIGNvdWxkIGJlIHNlZQo+IGFzIGEgaGFyZHdhcmUgTExJIHdp dGggb25seSAyIHRyYW5zZmVyIGRlc2NyaXB0b3JzLgo+IEEgaGFyZHdhcmUgYml0IENUIChjdXJy ZW50IHRhcmdldCkgaXMgdXNlZCB0byBkZXRlcm1pbmUgdGhlCj4gY3VycmVudCB0cmFuc2ZlciAo Q1QgPSAwIG9yIDEpLgo+IEEgaGFyZHdhcmUgTkRUIChudW0gb2YgZGF0YSB0byB0cmFuc2Zlcikg Y291bnRlciBjYW4gYmUgcmVhZCB0bwo+IGRldGVybWluZSBETUEgcG9zaXRpb24gaW4gY3VycmVu dCB0cmFuc2Zlci4KPiBBbiBJUlEgaXMgZ2VuZXJhdGVkIHdoZW4gdGhpcyBDVCBiaXQgaXMgdXBk YXRlZCB0byBhbGxvd3MgZHJpdmVyIHRvCj4gdXBkYXRlIHRoZSBkb3VibGUgYnVmZmVyIGZvciB0 aGUgbmV4dCB0cmFuc2Zlci4KPiAKPiBPbiBjbGllbnQgc2lkZSAoYS5lIGF1ZGlvKToKPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhlIGNsaWVudCByZXF1ZXN0cyBhIGN5Y2xpYyB0cmFu c2ZlciBieSBjYWxsaW5nCj4gc3RtMzJfZG1hX3ByZXBfZG1hX2N5Y2xpYy4gRm9yIGluc3RhbmNl IGl0IGNhbiByZXF1ZXN0IHRoZSB0cmFuc2ZlciBvZiBhCj4gYnVmZmVyIGRpdmlkZWQgaW4gMTAg cGVyaW9kcy4gSW4gdGhpcyBjYXNlIG9ubHkgb25lIGNvb2tpZSBzdWJtaXR0ZWQKPiAocmlnaHQ/ KS4KPiAKPiBBdCBzdG0zMmRtYSBkcml2ZXIgbGV2ZWwgdGhlc2UgMTAgcGVyaW9kcyBhcmUgcmVn aXN0ZXJlZCBpbiBhbiBpbnRlcm5hbAo+IHNvZnR3YXJlIHRhYmxlIChkZXNjLT5zZ19yZXFbXSku QXMgY3ljbGljLCB0aGUgbGFzdCBzZ19yZXEgcG9pbnQgdG8gdGhlCj4gZmlyc3Qgb25lLgo+IAo+ IFNvIHRvIGJlIGFibGUgdG8gdHJhbnNmZXIgdGhlIHdob2xlIHNvZnR3YXJlIHRhYmxlLCB3ZSBo YXZlIHRvIHVwZGF0ZQo+IHRoZSBTVE0zMiBETUEgZG91YmxlIGJ1ZmZlciBhdCBlYWNoIGVuZCBv ZiB0cmFuc2ZlciBwZXJpb2QuCj4gVGhlIGZpbGVkIGNoYW4tPm5leHRfc2cgcG9pbnRzIHRvIHRo ZSBuZXh0IHNnX3JlcSBpbiB0aGUgc29mdHdhcmUgdGFibGUuCj4gdGhhdCBzaG91bGQgYmUgd3Jp dGUgaW4gdGhlIFNUTTMyIERNQSBkb3VibGUgYnVmZmVyLgo+IAo+IFJlc2lkdWUgY2FsY3VsYXRp b246Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLQo+IER1cmluZyBhIHRyYW5zZmVyIHdlIGNhbiBnZXQg dGhlIHBvc2l0aW9uIGluIGEgcGVyaW9kIHRoYW5rcyB0byB0aGUKPiBORFQobnVtIG9mIGRhdGEg dG8gdHJhbnNmZXIpIGJpdC1maWVsZC4KPiAKPiBTbyB0aGUgY2FsY3VsYXRpb24gaXMgOgo+IDEp IEdldCB0aGUgTkRUIGZpZWxkIHZhbHVlCj4gMykgYWRkIHRoZSBwZXJpb2RzIHJlbWFpbmluZyBp biB0aGUgZGVzYy0+c2dfcmVxW10gdGFibGUuCj4gCj4gSW4gcGFyYWxsZWwgdGhlIFNUTTMyIERN QSBoYXJkd2FyZSB1cGRhdGVzIHRoZSB0cmFuc2ZlciBidWZmZXIgaW4gMyBzdGVwczoKPiAxKSB1 cGRhdGUgQ1QgcmVnaXN0ZXIgZmllbGQuCj4gMikgVXBkYXRlIE5EVCByZWdpc3RlciBmaWVsZC4K PiAzKSBnZW5lcmF0ZSB0aGUgSVJRIChBcyB5b3UgbWVudGlvbiB0aGUgSVJRIGlzIG5vdCB0cmVh dGVkIGR1cmluZyB0aGUKPiBkZXZpY2VfdHhfc3RhdHVzIGFzIHByb3RlY3RlZCBmcm9tIGludGVy cnVwdHMpLgo+IAo+IFdlIGFyZSBmYWNpbmcgaXNzdWUgd2hlbiBjb21wdXRpbmcgdGhlIHJlc2lk dWUgZHVyaW5nIHRoZSB1cGRhdGUgb2YgdGhlCj4gQ1QgYW5kIHRoZSBORFQuIFRoZSBDVCBhbmQg TkRUIGNhbiBhcyBiZWVuIHVwZGF0ZWQgKCBib3RoIG9yIG9ubHkgQ1QuLi4pCj4gd2l0aG91dCBk cml2ZXIgY29udGV4dCB1cGRhdGUgKElSUSBkaXNhYmxlZCkuCj4gSW4gdGhpcyBjYXNlIHdlIGNh biBwb2ludCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBjdXJyZW50IHRyYW5zZmVyKAo+IGNvbXBs ZXRlZCkgaW5zdGVhZCBvZiB0aGUgbmV4dF90cmFuc2Zlci4gVGhpcyBnZW5lcmF0ZXMgYSByZXNp ZHVlIGVycm9yCj4gYW5kIGZvciBhdWRpbyBhIHRpbWUtc3RhbXAgcmVncmVzc2lvbiAoc28gdmlk ZW8gZnJlZXplIG9yIGF1ZGlvIHBsb3ApLgo+IAo+IFNvIHRoZSBwYXRjaCBwcm9wb3NlZCBjb25z aXN0cyBpbjoKPiAxKSBnZXR0aW5nIHRoZSBjdXJyZW50IE5EVCB2YWx1ZQo+IDIpIHJlYWRpbmcg Q1QgYW5kIGNoZWNrIHRoYXQgdGhlIGhhcmR3YXJlIGRvZXMgbm90IHBvaW50IHRvIHRoZSBuZXh0 X3NnLgo+IAlpZiB5ZXM6Cj4gCS0gQ1QgaGFzIGJlZW4gdXBkYXRlZCBieSBoYXJkd2FyZSBidXQg SVJRIHN0aWxsIG5vdCB0cmVhdGVkLgo+IAktIEJ5IGRlZmF1bHQgd2UgY29uc2lkZXIgdGhlIGN1 cnJlbnRfc2cgYXMgY29tcGxldGVkLCBzbyB3ZQo+IAkgIHBvaW50IHRvIHRoZSBiZWdpbm5pbmcg b2YgdGhlIG5leHRfc2cgYnVmZmVyLgo+IAo+IEhvcGUgdGhhdCB3aWxsIGhlbHAgdG8gY2xhcmlm eS4KClllcyB0aGF0IGhlbHBzLCBtYXliZSB3ZSBzaG91bGQgYWRkIHRoZXNlIGJpdHMgaW4gY29k ZSBhbmQgY2hhbmdlbG9nLi4KOikKCkFuZCBob3cgZG9lcyB0aGlzIGltcGFjdCBub24gY3ljbGlj IGNhc2Ugd2hlcmUgTiBkZXNjcmlwdG9ycyBtYXliZQppc3N1ZWQuIFRoZSBkcml2ZXIgc2VlbXMg dG8gc3VwcG9ydCBub24gY3ljbGljIHRvby4uLgoKVGhhbmtzCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,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 40C93C43219 for ; Tue, 30 Apr 2019 08:23:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EF379216FD for ; Tue, 30 Apr 2019 08:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556612589; bh=Ax7kPNajmahK5/UstcB84x/WDLbOavAFjZ0njaK2UbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=cZ140L4lAgyxY6LgILXkmLjYzjfXfzJqhVnpofnilB9kEr1OEAZ8kOAo8HM+/e9Dj uRhmPfdGNm+F6JK80f9G0tG6s2AoEg3er9fYLfD61vdOOwBIY420/v3tJ88SblQbQv Fdi7auoern4SoGqRFraZeUMDn2OOPEdhAqfx0skE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726165AbfD3IXI (ORCPT ); Tue, 30 Apr 2019 04:23:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:50648 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725769AbfD3IXI (ORCPT ); Tue, 30 Apr 2019 04:23:08 -0400 Received: from localhost (unknown [171.76.113.243]) (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 1F94E20835; Tue, 30 Apr 2019 08:23:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556612586; bh=Ax7kPNajmahK5/UstcB84x/WDLbOavAFjZ0njaK2UbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QHND4OReBGyxKTLOodkLnfdc/7gyGeTctWO8VahlGw2wBkG0/RYaktPVgY+GDlR67 LevTswToLl9bLpXZE3eEI1DoOkp0bgGzbMT/iFG6+rQyV76LBBX7yrKuBG9HtoKRcC SjmWZ6U8A++1UyV1W9jK++jSUeZMSQo+aZH+vJnk= Date: Tue, 30 Apr 2019 13:52:55 +0530 From: Vinod Koul To: Arnaud Pouliquen Cc: Dan Williams , Pierre-Yves MORDRET , linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org Subject: Re: [PATCH] dmaengine: stm32-dma: fix residue calculation in stm32-dma Message-ID: <20190430082255.GP3845@vkoul-mobl.Dlink> 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> <26fa7710-76cb-e202-a367-c2e2408b6808@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <26fa7710-76cb-e202-a367-c2e2408b6808@st.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Message-ID: <20190430082255.l7kxN3OReQMYJTJun4TmSrP3S2-a4SgL36lAMdTAnZo@z> On 29-04-19, 16:52, Arnaud Pouliquen wrote: > > > 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. Yes that helps, maybe we should add these bits in code and changelog.. :) And how does this impact non cyclic case where N descriptors maybe issued. The driver seems to support non cyclic too... Thanks -- ~Vinod