Re: [PATCH 0/4] Residue patches for rcar-dmac from renesas-drivers
On Wed, Jun 15, 2016 at 01:13:04PM +0200, Niklas Söderlund wrote: > Hi all, > > Laurent Pinchart (1): > dmaengine: rcar-dmac: Fix residue reporting for pending descriptors > > Muhammad Hamza Farooq (2): > dma: rcar-dma: use result of updated get_residue in tx_status > dma: rcar-dma: Fixed active descriptor initializing > > Niklas Söderlund (1): > dmaengine: rcar-dmac: warn if transfer cannot start as TE = 1 At least maintain consistency in patch title, 2 are dma and two dmaengine. Correct one is latter.. > > drivers/dma/sh/rcar-dmac.c | 40 +--- > 1 file changed, 37 insertions(+), 3 deletions(-) > > -- > 2.8.3 > -- ~Vinod
RE: [PATCH 0/4] Residue patches for rcar-dmac from renesas-drivers
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). -- [ 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: ffc039320c80 ti: ffc038b7c000 task.ti: ffc038b7c000 [ 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 : [] lr : [] pstate: 61c5 [ 375.165862] sp : ffc038b7fcd0 [ 375.169169] x29: ffc038b7fcd0 x28: ffc038b7c000 [ 375.174489] x27: ff80088ac000 x26: 001d [ 375.179809] x25: ffc0371d4018 x24: [ 375.185127] x23: x22: ff8008b533d8 [ 375.190446] x21: ffc038f72118 x20: ff8008e551b0 [ 375.195765] x19: x18: 0001 [ 375.201084] x17: 007f8c4b5400 x16: ff8008215900 [ 375.206402] x15: 007f8c3f9c94 x14: 007f8c56e000 [ 375.211720] x13: 007f8c408828 x12: [ 375.217039] x11: 007fd7967560 x10: 0870 [ 375.222357] x9 : ffc038b7c000 x8 : ffc039321550 [ 375.227676] x7 : 0001 x6 : ffc038f720f8 [ 375.232994] x5 : ffc0381fa010 x4 : ffc0381fafd8 [ 375.238312] x3 : x2 : ff8008b53000 [ 375.243630] x1 : 000c x0 : [ 375.250433] ---[ end trace df725ea508513372 ]--- -- Thanks, Ramesh
