From: zonque@gmail.com (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 4/5] dma: mmp_pdma: add support for residue reporting
Date: Mon, 09 Dec 2013 20:00:51 +0100 [thread overview]
Message-ID: <52A61363.7060500@gmail.com> (raw)
In-Reply-To: <20130913045135.GI17188@intel.com>
Hi Vinod,
Very sorry for such a long delay. I only get to pick up on this topic
now. Hope you can remember the context of the discussion :)
On 09/13/2013 06:51 AM, Vinod Koul wrote:
> On Tue, Sep 10, 2013 at 05:46:19PM +0200, Daniel Mack wrote:
>> Hi Vinod,
>>
>> Sorry for the late response, I've been on vacations.
>>
>> On 25.08.2013 18:33, Vinod Koul wrote:
>>> On Wed, Aug 21, 2013 at 02:08:57PM +0200, Daniel Mack wrote:
>>>> In order to report the channel's residue, we walk the list of running
>>>> descriptors, look for those which match the cookie, and then try to find
>>>> the descriptor which defines upper and lower boundaries that embrace the
>>>> current transport pointer.
>>>
>>>>
>>>> + /*
>>>> + * 'passed' will be latched once we found the descriptor which
>>>> + * lies inside the boundaries of the curr pointer. All
>>>> + * descriptors that occur in the list _after_ we found that
>>>> + * partially handled descriptor are still to be processed and
>>>> + * are hence added to the residual bytes counter.
>>>> + */
>>> do you have multiple descriptors for one transaction? Should be No.
>>
>> Sure, that can be the case. One transaction could span across multiple
>> descriptors, especially if its overall length exceeds the maximum length
>> of one descriptor.
> Yes and these addiional descriptor for a transacation should be child
> descriptors.
> The child descriptors should have ->parent point to parent descriptor and ->next
> to next in the chain of children.
I looked into your idea and implemented it, but I really feel having an
explicit chain pointer for each descriptor is redundant information.
Hence, let me summarize again how the driver currently works:
* Any of the prep_* function will allocate a number of descriptors to
accommodate the payload, and link them all together via the 'node'
list_head, forming a transaction.
* The last descriptor in a transaction has the DCMD_ENDIRQEN flag set.
* When tx_submit() is called, each descriptor in the linked list will be
assigned a cookie, and then entire list of the transaction is appended
to the chain_pending list. At this point, the information of where a
transaction ends is no longer visible in the 'node' list head.
* start_pending_queue() moves the chain_pending entries to chain_running.
When determining the channel's residue, we need to find the transaction
currently in progress, and then count upwards until we reach the end of
the transaction chain.
So, while I could add a ->next pointer to the descriptors, and only use
that to link up descriptors of one transaction in the prep_*()
functions, that extra information doesn't actually buy us anything, as
the same information is already stored in the DCMD_ENDIRQEN flag.
I rebased the residue patch on top of Joe's cleanup work, and I can
resubmit if you want me to. Maybe that serves as a better foundation for
the ongoing discussion :)
Many thanks,
Daniel
next prev parent reply other threads:[~2013-12-09 19:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 12:08 [PATCH v5 0/5] dma: pdma: cyclic, residue, DMA_PRIVATE Daniel Mack
2013-08-21 12:08 ` [PATCH v5 1/5] dma: mmp_pdma: only complete one transaction from dma_do_tasklet() Daniel Mack
2013-08-21 12:08 ` [PATCH v5 2/5] dma: mmp_pdma: don't clear DCMD_ENDIRQEN at end of pending chain Daniel Mack
2013-08-21 12:08 ` [PATCH v5 3/5] dma: mmp_pdma: add support for cyclic DMA descriptors Daniel Mack
2013-08-21 12:08 ` [PATCH v5 4/5] dma: mmp_pdma: add support for residue reporting Daniel Mack
2013-08-25 16:33 ` Vinod Koul
2013-09-10 15:46 ` Daniel Mack
2013-09-13 4:51 ` Vinod Koul
2013-12-09 19:00 ` Daniel Mack [this message]
2013-12-10 16:11 ` Vinod Koul
2013-12-11 15:09 ` Daniel Mack
2013-08-25 18:08 ` Russell King - ARM Linux
2013-09-10 15:46 ` Daniel Mack
2013-08-21 12:08 ` [PATCH v5 5/5] dma: mmp_pdma: set DMA_PRIVATE Daniel Mack
2013-08-25 16:35 ` [PATCH v5 0/5] dma: pdma: cyclic, residue, DMA_PRIVATE Vinod Koul
2013-08-26 9:22 ` 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=52A61363.7060500@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.