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
��.n��������+%������w��{.n��������)�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
