Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case

2013-10-28 Thread Daniel Mack
On 10/18/2013 11:03 AM, Daniel Mack wrote: > Hi Sebastian, > > On 10/17/2013 04:36 PM, Sebastian Andrzej Siewior wrote: >> On 10/17/2013 04:23 PM, Daniel Mack wrote: Daniel, could please look if this solves your suspend / resume warnings? > > Looking very good :) > >> dma: cppi41: add suppo

Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case

2013-10-17 Thread Sebastian Andrzej Siewior
On 10/17/2013 04:23 PM, Daniel Mack wrote: >> Daniel, could please look if this solves your suspend / resume warnings? > > Will do (hopefully) tomorrow. So this is a replacement for my "dma: > cppi41: move -EAGAIN in tear_down" patch, or does it go on top of it? I applied your three patches and m

Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case

2013-10-17 Thread Daniel Mack
On 10/17/2013 04:20 PM, Sebastian Andrzej Siewior wrote: > On 10/17/2013 04:19 PM, Sebastian Andrzej Siewior wrote: >> This patch changes the logic here to look on both queues for the >> descriptor. > > Daniel, could please look if this solves your suspend / resume warnings? Will do (hopefully) t

Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case

2013-10-17 Thread Sebastian Andrzej Siewior
On 10/17/2013 04:19 PM, Sebastian Andrzej Siewior wrote: > This patch changes the logic here to look on both queues for the > descriptor. Daniel, could please look if this solves your suspend / resume warnings? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

[PATCH 1/2] dma: cppi41: redo descriptor collection in abort case

2013-10-17 Thread Sebastian Andrzej Siewior
Most of the logic here is try and error since what actually happens does not match the trm or I miss read it. My first assumption was that the queue on which the tear-down descriptor completes (their own complete queue vs "active descriptor" complete queue) depends on the transfer direction. This s