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 v3.5] dw_dmac: return proper residue value
Date: Fri, 25 Jan 2013 10:56:44 +0200 [thread overview]
Message-ID: <1359104204.12502.101.camel@smile> (raw)
In-Reply-To: <CAOh2x=nnrEo69W7sBES85KgF0+WUy8Ouoq+SG1XiB54e7QLiow@mail.gmail.com>
On Fri, 2013-01-25 at 09:43 +0530, Viresh Kumar wrote:
> On Thu, Jan 24, 2013 at 6:37 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > Currently the driver returns full length of the active descriptor which is
> > wrong. We have to go throught the active descriptor and substract the length of
> > each sent children in the chain from the total length along with the actual
> > data in the DMA channel registers.
> >
> > The cyclic case is not handled by this patch due to len field in the descriptor
> > structure is left untouched by the original code.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Firstly the issue i raised earlier about not updating residue from
> tasklet or interrupt
> handler was wrong. As i had an older version of code in my mind. This got solved
> with following patch:
>
> commit 77bcc497c60ec62dbb84abc809a6e218d53409e9
> Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Date: Fri Jan 18 14:14:15 2013 +0200
>
> dw_dmac: move soft LLP code from tasklet to dwc_scan_descriptors
>
>
> > ---
> > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> > +static inline u32 dwc_get_residue(struct dw_dma_chan *dwc)
> > +{
> > + unsigned long flags;
> > + u32 residue;
> > +
> > + spin_lock_irqsave(&dwc->lock, flags);
> > +
> > + residue = dwc->residue;
>
> you need to release the lock just here.
>
> > + if (test_bit(DW_DMA_IS_SOFT_LLP, &dwc->flags) && residue)
> > + residue -= dwc_get_sent(dwc);
>
> why do you need lock while reading the control registers? It looks you didn't
> get what i wanted to say earlier. We are using locks to protect some part for
> shared data or critical sections. these are playing with dwc transfer
> lists, etc..
>
> Probably we don't need a lock to read the control register as nobody can
> guarantee that another access is not happening currently. As hardware is
> changing this register continuously for the transfer.
>
> Let me know if i am missing something.
I'm trying to find a proof of any of our opinions.
My intuitive understanding that we have to avoid a concurrency during hw
access.
>
> > + spin_unlock_irqrestore(&dwc->lock, flags);
> > + return residue;
> > +}
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2013-01-25 8:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-24 10:34 [PATCH v3 0/4] dw_dmac: return actual residue value Andy Shevchenko
2013-01-24 10:34 ` [PATCH v3 1/4] dw_dmac: remove unnecessary tx_list field in dw_dma_chan Andy Shevchenko
2013-01-24 10:34 ` [PATCH v3 2/4] dw_dmac: introduce total_len field in struct dw_desc Andy Shevchenko
2013-01-24 10:34 ` [PATCH v3 3/4] dw_dmac: fill individual length of descriptor Andy Shevchenko
2013-01-24 10:34 ` [PATCH v3 4/4] dw_dmac: return proper residue value Andy Shevchenko
2013-01-24 10:45 ` Viresh Kumar
2013-01-24 10:48 ` Andy Shevchenko
2013-01-24 13:07 ` [PATCH v3.5] " Andy Shevchenko
2013-01-25 4:13 ` Viresh Kumar
2013-01-25 8:56 ` Andy Shevchenko [this message]
2013-01-25 9:04 ` Andy Shevchenko
2013-01-25 9:07 ` Viresh Kumar
2013-01-25 9:19 ` Andy Shevchenko
2013-01-25 9:30 ` Viresh Kumar
2013-01-25 9:37 ` Andy Shevchenko
2013-01-25 9:39 ` Viresh Kumar
2013-01-25 9:42 ` Andy Shevchenko
2013-01-24 10:50 ` [PATCH v3 0/4] dw_dmac: return actual " Viresh Kumar
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=1359104204.12502.101.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.