All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Vinod Koul <vinod.koul@intel.com>,
	linux-kernel@vger.kernel.org,
	spear-devel <spear-devel@list.st.com>
Subject: Re: [PATCH 2/2] dw_dmac: return proper residue value
Date: Wed, 23 Jan 2013 11:12:35 +0200	[thread overview]
Message-ID: <1358932355.12502.68.camel@smile> (raw)
In-Reply-To: <CAKohpo=m-s4+q+4v2v+8nzC32FRzJAb58no2hZLV_5QqTj4wig@mail.gmail.com>

On Tue, 2013-01-22 at 15:10 +0530, Viresh Kumar wrote: 
> On 22 January 2013 14:52, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> 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@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2013-01-23  9:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21  9:00 [PATCH 1/2] dw_dmac: fill len field of the descriptor Andy Shevchenko
2013-01-21  9:00 ` [PATCH 2/2] dw_dmac: return proper residue value Andy Shevchenko
2013-01-21  8:49   ` Vinod Koul
2013-01-21  9:45     ` Andy Shevchenko
2013-01-21 14:22       ` Vinod Koul
2013-01-22  7:24         ` Andy Shevchenko
2013-01-22  8:11   ` Viresh Kumar
2013-01-22  9:22     ` Andy Shevchenko
2013-01-22  9:40       ` Viresh Kumar
2013-01-23  9:12         ` Andy Shevchenko [this message]
2013-01-23  9:22           ` Viresh Kumar
2013-01-23  9:36             ` Andy Shevchenko
2013-01-23  9:51               ` Viresh Kumar
2013-01-23 10:20                 ` Andy Shevchenko
2013-01-23 10:24                   ` Viresh Kumar
2013-01-23 10:33                     ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1358932355.12502.68.camel@smile \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spear-devel@list.st.com \
    --cc=vinod.koul@intel.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.