[PATCH v4 3/4] dma: mmp_pdma: add support for residue reporting

Daniel Mack zonque at gmail.com
Wed Aug 21 08:03:12 EDT 2013


Hi Andy,

On 21.08.2013 13:52, Andy Shevchenko wrote:
> On Wed, Aug 21, 2013 at 2:35 PM, Xiang Wang <wangx at marvell.com> wrote:
>> On 08/17/2013 01:05 AM, 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.
>>>
>>> Signed-off-by: Daniel Mack <zonque at gmail.com>
> 
>> One thing I want to check with you and all:
>> If we have these descriptors in the running chain:
>> D1T1 -> D2T1 -> D3T1 => D1T2 -> D2T2 -> D3T2
>> |    Transaction 1    | Transaction 2      |
>>
>> And DMA currently running to D2T1, if we provide the cookie of D3T2, what
>> the residual value we should get? All unfinished bytes in T1+T2 or only
>> unfinished bytes in T2 (seems not easy to implement)?
> 
> You have a really good question. Different drivers do different things.

I think the idea of how things should work is pretty clear, but I'd like
Vinod to ack my understanding here :)

The user is free to submit multiple transactions per channel, and
dmaengine_submit() will submit a new cookie for each one.

When the engine is asked about the residue of a specific cookie, it
should of course only return the value for the related transaction. If
that transaction is not yet processed, the residue value should be the
complete length, regardless of the transaction that is currently processed.

> In dw_dmac, for example, we return the T1 (means 'active') residue always.

I'd say that's a bug.

> I don't think you have different cookies per descriptors in chain of
> one transaction.

Currently, the pdma driver does in fact assign a cookie to each
descriptor, but the external user will only get so see the cookie for
the last descriptor in the transaction. I don't think that's a problem,
but we have to maintain an understanding of which descriptors belong to
one transaction.


Thanks,
Daniel




More information about the linux-arm-kernel mailing list