From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: pl330: Set residue in tx_status callback
Date: Thu, 04 Dec 2014 21:15:09 +0100 [thread overview]
Message-ID: <5480C0CD.8050207@metafoo.de> (raw)
In-Reply-To: <CAAgF-BfPyaOhhrA5L8vm2WDnhBYDexJFkGxqL1GsL2TMB8z=Rw@mail.gmail.com>
On 12/03/2014 05:47 AM, Padma Venkat wrote:
> Hi Lars,
>
> [snip]
>>>> +
>>>> + ret = dma_cookie_status(chan, cookie, txstate);
>>>> + if (ret == DMA_COMPLETE || !txstate)
>>>> + return ret;
>>>> +
>>>> + used = txstate->used;
>>>> +
>>>> + spin_lock_irqsave(&pch->lock, flags);
>>>> + sar = readl(regs + SA(thrd->id));
>>>> + dar = readl(regs + DA(thrd->id));
>>>> +
>>>> + list_for_each_entry(desc, &pch->work_list, node) {
>>>> + if (desc->status == BUSY) {
>>>> + current_c = desc->txd.cookie;
>>>> + if (first) {
>>>> + first_c = desc->txd.cookie;
>>>> + first = false;
>>>> + }
>>>> +
>>>> + if (first_c < current_c)
>>>> + residue += desc->px.bytes;
>>>> + else {
>>>> + if (desc->rqcfg.src_inc && pl330_src_addr_in_desc(desc, sar)) {
>>>> + residue += desc->px.bytes;
>>>> + residue -= sar - desc->px.src_addr;
>>>> + } else if (desc->rqcfg.dst_inc && pl330_dst_addr_in_desc(desc, dar))
>>>> {
>>>> + residue += desc->px.bytes;
>>>> + residue -= dar - desc->px.dst_addr;
>>>> + }
>>>> + }
>>>> + } else if (desc->status == PREP)
>>>> + residue += desc->px.bytes;
>>>> +
>>>> + if (desc->txd.cookie == used)
>>>> + break;
>>>> + }
>>>> + spin_unlock_irqrestore(&pch->lock, flags);
>>>> + dma_set_residue(txstate, residue);
>>>> + return ret;
>>>> }
> [snip]
>>>
>>> Any comment on this patch?
>>
>> Well it doesn't break audio, but I don't think it has the correct haviour
>> for all cases yet.
>
> OK. Any way of testing other cases like scatter-gather and memcopy. I
> verified memcopy in dmatest but it seems not doing anything with
> residue bytes.
E.g. I think your current patch fails if more than one transfer has been
submitted. In that case you'll count the bytes for all of them rather than
just the one requested.
>
>>
>> Again, the semantics are that it should return the progress of the transfer
>>
>> for which the allocation function returned the cookie that is passe to this
>
> May be my understanding is wrong. For clarification..In the
> snd_dmaengine_pcm_pointer it is subtracting the residue bytes from the
> total buffer bytes not from period bytes. So how it expects
> the progress of the transfer of the passed cookie which just holds period bytes?
The issue that makes implementing this correctly for the pl330 driver
complicated is that the driver allocates one cookie per segment/period, but
the external API works with one cookie per transfer. All those cookies that
are assigned to the segments/periods that are not the first in a transfer
are not externally visible.
dmaengine_prep_slave_sg() and friends create a transfer and return
descriptor for this transfer with a single cookie. If that cookie is passed
to dmaengine_tx_status() the function is supposed to report the progress on
that one transfer that was previously allocated and returned that cookie
number. residue is the total number of bytes that are still left to to be
processed for that transfer.
I've started reworking the pl330 driver to only have a single cookie per
transfer, instead of one per period/segment. This makes implementing the
residue reporting a lot easier. I never finished that work though, but I can
try to see if I can revive it next week.
- Lars
next prev parent reply other threads:[~2014-12-04 20:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 9:44 [PATCH] dmaengine: pl330: Set residue in tx_status callback Padmavathi Venna
2014-12-02 5:38 ` Padma Venkat
2014-12-02 17:25 ` Lars-Peter Clausen
2014-12-03 4:47 ` Padma Venkat
2014-12-03 7:51 ` Jassi Brar
2014-12-05 15:15 ` Vinod Koul
2014-12-05 15:18 ` Russell King - ARM Linux
2014-12-06 7:01 ` Jassi Brar
2014-12-08 13:07 ` Vinod Koul
2014-12-08 14:23 ` Russell King - ARM Linux
2014-12-09 6:10 ` Vinod Koul
2014-12-09 15:18 ` Jassi Brar
2014-12-11 4:47 ` Vinod Koul
2014-12-11 6:12 ` Jassi Brar
2015-03-12 8:47 ` Jassi Brar
2014-12-04 20:15 ` Lars-Peter Clausen [this message]
2014-12-05 15:10 ` 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=5480C0CD.8050207@metafoo.de \
--to=lars@metafoo.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).