From: daniel@zonque•org (Daniel Mack)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RESEND] dma: mmp_pdma: add support for residue reporting
Date: Wed, 16 Apr 2014 10:38:10 +0200 [thread overview]
Message-ID: <534E4172.8030401@zonque.org> (raw)
In-Reply-To: <20140416082326.GM32284@intel.com>
On 04/16/2014 10:23 AM, Vinod Koul wrote:
> On Wed, Apr 16, 2014 at 10:28:45AM +0200, Daniel Mack wrote:
>> Hi Vinod,
>>
>> On 04/16/2014 08:45 AM, Vinod Koul wrote:
>>> On Wed, Apr 09, 2014 at 06:35:15PM +0200, Daniel Mack wrote:
>>
>>>> 5. The cookie comparison in the end simply exists to address the fact
>>>> that we might have operated on an unreleated descriptor, and we have
>>>> to start over.
>>>>
>>>> So in short, the logic will return the bytes that are not yet processed
>>>> for a specific transaction, which is the expected thing to do, right?
>>> Looks fine then BUT I have another questions.
>>>
>>> Assuming that you have two txn submitted and driver split them to 3 descriptors
>>> each, then in that case the driver would walk over all 6 descriptors and sum up
>>> the value, which would lead to incorrect residue. It will work for single
>>> pending txn only, right?
>>
>> No, because each of the two txn would have a different cookie set, and
>> the residue function is called for one specific cookie so we know which
>> one we're looking for. That's the reason why we start over if at the end
>> of an iterated transaction chain, if we recognize that the cookie
>> doesn't match, we start over.
>>
>>> While at it and looking at the code again, I think right solution maybe to
>>> update the parent child in the descriptors. So on query you simply walk the
>>> list for all child descriptors and continue. But the parent and child are
>>> defined under CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH.
>>
>> That's another solution, but it's redundant information after all.
>> Ultimately, it makes the driver more complicated and introduces one more
>> area of potentially inconsistent pointers.
>>
>>> So adding Dan (his updated email id), would it be okay if we make these as
>>> generic in descriptor and use them to manage larger length transactions in
>>> drivers?
>>
>> It might add to the readability of the drivers, but for the current
>> case, I don't think it's really necessary.
> That is because you are maintaining the current descriptors in chain_running. If
> we use above method then you dont need to use this, right?
Jup, but that would result in a rewrite of larger parts of the code. The
concept of hot-linking the two list so there's only one resulting list
of currently active descriptors is built-in deeply into the driver's
concept.
Thanks,
Daniel
next prev parent reply other threads:[~2014-04-16 8:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 11:29 [PATCH RESEND] dma: mmp_pdma: add support for residue reporting Daniel Mack
2014-03-19 15:13 ` Vinod Koul
2014-04-09 16:35 ` Daniel Mack
2014-04-16 6:45 ` Vinod Koul
2014-04-16 8:28 ` Daniel Mack
2014-04-16 8:23 ` Vinod Koul
2014-04-16 8:38 ` Daniel Mack [this message]
2014-04-16 9:09 ` Vinod Koul
2014-04-16 14:59 ` Daniel Mack
2014-04-16 16:01 ` Vinod Koul
2014-04-16 16:40 ` Daniel Mack
2014-05-02 22:29 ` Daniel Mack
2014-05-07 7:04 ` Vinod Koul
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=534E4172.8030401@zonque.org \
--to=daniel@zonque$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox