Hi Niklas, Thanks for the explanation. > Subject: [PATCH 0/4] Residue patches for rcar-dmac from renesas-drivers > > Hi all, > > I have looked over the DMA residue branches in renesas-drivers tree > (topic/rcar-dmac-hamza-v3 and topic/rcar-dmac-residue-v1) hoping to bring > them to upstream. The original author for the bulk of the patches Hamza > Farooq have not shown any activity since autumn 2015. > > In this cover letter I talk about all the patches in the above branches > but for obvious reasons only patches I think should be forwarded to > upstream are included in the series. All patches are based ontop of > v4.7-rc1 and are tested on Koelsch using Geerts sertest tool to generate > DMA traffic. The highest baud I could get to work at was 921600 bps. > From reading the original mail threads my conclusion is that this is good > enough since all errors reported by Hamza Farooq where related to the > serial sh-sci driver. > > * Patches from topic/rcar-dmac-hamza-v3 > > - dma: rcar-dma: add wait after stopping dma engine > In a perfect world one should check that RCAR_DMACHCR_DE is read > back as 0 after it have been cleared. The documentation clearly > states that one should do so. > > In the real world the worst case time for this register to be > cleared as Morimoto-san checked with HW is 700us. Laurent later > pointed out this is too long to busy loop over since this is done > from both interrupt context and user context with a spinlock hold. > > Also in the real world the rcar-dmac driver WARN_ON_ONCE() that > RCAR_DMACHCR_DE is not set before it attempts to start an transferee > in rcar_dmac_chan_start_xfer(). So if this ever becomes a problem we > will know about it. At least I have never seen this warning while > using DMA. Whit this in mind I have not tried to implement a fix for > this and I think the original patch can be dropped. As you mentioned, we cannot busy loop for longer but I think this patch was still useful with a check & WARN_ON print when it fails. It tries to comes close to the dmaengine_terminate_sync api description & it can add to the rcar_dmac_chan_start_xfer() check you already implemented. I hit this case once when I used four SYS-DMAC channels in parallel with DRIF doing cyclic DMA under full load & ethernet traffic (r8a7795 SoC). ---<snip>--- [ 375.108441] WARNING: CPU: 3 PID: 2074 at /home/ramesh/tmp/renesas-drivers-2/renesas-drivers/drivers/dma/sh/rcar-dmac.c:773 rcar_dmac_chan_halt+0xa4/0xd4 [ 375.122083] Modules linked in: rcar_drif [ 375.127512] CPU: 3 PID: 2074 Comm: drif-capture-es Not tainted 4.6.0-rc1+ #21 [ 375.134641] Hardware name: Renesas Salvator-X board based on r8a7795 (DT) [ 375.141424] task: ffffffc039320c80 ti: ffffffc038b7c000 task.ti: ffffffc038b7c000 [ 375.148903] PC is at rcar_dmac_chan_halt+0xa4/0xd4 [ 375.153689] LR is at rcar_dmac_chan_halt+0x8c/0xd4 [ 375.158474] pc : [<ffffff8008471194>] lr : [<ffffff800847117c>] pstate: 600001c5 [ 375.165862] sp : ffffffc038b7fcd0 [ 375.169169] x29: ffffffc038b7fcd0 x28: ffffffc038b7c000 [ 375.174489] x27: ffffff80088ac000 x26: 000000000000001d [ 375.179809] x25: ffffffc0371d4018 x24: 0000000000000000 [ 375.185127] x23: 0000000000000000 x22: ffffff8008b533d8 [ 375.190446] x21: ffffffc038f72118 x20: ffffff8008e551b0 [ 375.195765] x19: 0000000000000000 x18: 0000000000000001 [ 375.201084] x17: 0000007f8c4b5400 x16: ffffff8008215900 [ 375.206402] x15: 0000007f8c3f9c94 x14: 0000007f8c56e000 [ 375.211720] x13: 0000007f8c408828 x12: ffffffffffffffff [ 375.217039] x11: 0000007fd7967560 x10: 0000000000000870 [ 375.222357] x9 : ffffffc038b7c000 x8 : ffffffc039321550 [ 375.227676] x7 : 0000000000000001 x6 : ffffffc038f720f8 [ 375.232994] x5 : ffffffc0381fa010 x4 : ffffffc0381fafd8 [ 375.238312] x3 : 0000000000000000 x2 : ffffff8008b53000 [ 375.243630] x1 : 000000000000000c x0 : 0000000000000000 [ 375.250433] ---[ end trace df725ea508513372 ]--- ---<snip>--- Thanks, Ramesh
