From: zonque@gmail.com (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: [v3 1/2] dma: mmp_pdma: add support for residue reporting
Date: Thu, 15 Aug 2013 20:12:05 +0200 [thread overview]
Message-ID: <520D19F5.7050406@gmail.com> (raw)
In-Reply-To: <CADApbejtvXvgF8jpQAyrbY3Yr=XkBech5D6fCEM+yMj8DRRY9w@mail.gmail.com>
On 15.08.2013 10:08, Chao Xie wrote:
> In the function mmp_pdma_tx_submit
> It will assign cookie for every descriptors by
> list_for_each_entry(child, &desc->tx_list, node) {
> cookie = dma_cookie_assign(&child->async_tx);
> }
> So not all the descriptors in same transaction will share same cookie.
Hmm, yes. You're right. However, I see quite some more issues with the
driver as it stands, especially due to assumptions that are made for
multiple transactions on one channel.
For example, let's think about two transactions with multiple
descriptors each, and both transactions are present in the chain_running
list. Each transaction has the ENDIRQEN bit set on the last descriptor only.
Currently, when an interrupt is caught, the code will only look at the
very last entry in the running list and complete its cookie, and then
dispose the entire running chain. Hence, the other transaction's cookie
will never complete. Even worse: as an interrupt will always be for the
first descriptor in the chain with the ENDIRQEN bit set, we complete the
second transaction that is in fact still running (and call the
completion handler for it), while we don't do exactly that for the first
one.
Am I right with the above or do I make faulty assumptions? I'll think
about how the driver can be changed in order to fix this, but it will be
more invasive than I thought.
Thanks for sharing your ideas,
Daniel
next prev parent reply other threads:[~2013-08-15 18:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 16:19 [v3 1/2] dma: mmp_pdma: add support for residue reporting Daniel Mack
2013-08-14 16:23 ` Russell King - ARM Linux
2013-08-15 1:57 ` Chao Xie
2013-08-15 3:44 ` Daniel Mack
2013-08-15 8:08 ` Chao Xie
2013-08-15 18:12 ` Daniel Mack [this message]
2013-08-16 2:21 ` Chao Xie
2013-08-16 7:57 ` Xiang Wang
2013-08-16 15:40 ` Daniel Mack
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=520D19F5.7050406@gmail.com \
--to=zonque@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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.