Re: [PATCH 2/2] dw_dmac: return proper residue value

[Andy Shevchenko]

On Tue, 2013-01-22 at 15:10 +0530, Viresh Kumar wrote: 
> On 22 January 2013 14:52, Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Tue, 2013-01-22 at 13:41 +0530, Viresh Kumar wrote:
> >> > +       spin_lock_irqsave(&dwc->lock, flags);
> >> > +       if (list_empty(&dwc->active_list)) {
> >>
> >> can this every happen?
> >
> > In the same way as in dwc_scan_descriptors().
> > For example when transfer is done.
> 
> My point was, because scan_descriptor() is just called, if the transfer
> is over by now, we must have returned back, else we reach this place
> and so this may never be true.

Ah, you mean the dma_cookie_status returns DMA_SUCCESS in case
active_list is empty, don't you?

> >> Over that, cyclic case can be handled before taking any locks.
> >
> > Does the user is responsible to follow specific workflow for cyclic API?
> 
> not sure.

I have no test cases against cyclic API, so I may assume that it doesn't
require locking for that bit.

> >> Just before above line got executed, we called dwc_scan_descriptors(), which
> >> also scans through the llis to see where we are.. What about updating
> >> first->residue
> >> there, so that we don't traverse it twice?
> >
> > The dwc_scan_descriptors traverses the chain and returns immediately if
> > it found a match. But to calculate residue we have to traverse from that
> > point to the end of the chain along with current DMA register check.
> 
> Hey, you can start subtracting individual lengths of descriptors from
> total length
> in scan descriptors() and that should give you what you want.

Yesterday I spent in testing of different approaches. First of all, the
calculation of the sent amount is nicer when ctlhi/ctllo is used and it
works fine. But the approach, when we substract length of sent
descriptors, is losing data. Namely, we have no information how big is
the master descriptor (it has total length of the entire chain). So, I'm
thinking how to solve this one. Otherwise it seems simpler than mine
first idea.

-- 
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/