public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* dmaengine: DMA_CTRL_ACK flag signification
@ 2008-09-24 11:59 Nicolas Ferre
  2008-10-07  9:09 ` Sosnowski, Maciej
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Ferre @ 2008-09-24 11:59 UTC (permalink / raw)
  To: maciej.sosnowski, Linux Kernel list; +Cc: dan.j.williams, Haavard Skinnemoen

Hi all,

I am in the process of writing a driver for an on-chip Atmel DMA engine.

I am a little confused about the use of the flag DMA_CTRL_ACK : It seems 
that it is set in most of the descriptors in use except the first or 
last of a descriptor chain. So, I cannot find where this flag is cleared.
In short, I do not see what it is used for : how must I take it into 
account in my driver (in device_prep_dma_memcpy() for instance) ?

Can you enlighten me ?

Regards,
-- 
Nicolas Ferre


^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: dmaengine: DMA_CTRL_ACK flag signification
  2008-09-24 11:59 dmaengine: DMA_CTRL_ACK flag signification Nicolas Ferre
@ 2008-10-07  9:09 ` Sosnowski, Maciej
  2008-10-13 18:51   ` Dan Williams
  0 siblings, 1 reply; 3+ messages in thread
From: Sosnowski, Maciej @ 2008-10-07  9:09 UTC (permalink / raw)
  To: Nicolas Ferre, Williams, Dan J, Linux Kernel list; +Cc: Haavard Skinnemoen

Nicolas Ferre wrote:
> Hi all,
> 
> I am in the process of writing a driver for an on-chip Atmel DMA
> engine. 
> 
> I am a little confused about the use of the flag DMA_CTRL_ACK : It
> seems that it is set in most of the descriptors in use except the
> first or last of a descriptor chain. So, I cannot find where this
> flag is cleared. In short, I do not see what it is used for : how
> must I take it into account in my driver (in device_prep_dma_memcpy()
> for instance) ? 
> 
> Can you enlighten me ?
> 
> Regards,

Hi Nicolas,

Sorry for the delay in response.
Generally the idea behind DMA_CTRL_ACK is to let an application 
safely set a chain of dependent operations.
What a DMA driver needs to do is to check 
if a given descriptor has been already acked (using async_tx_test_ack())
before it recycles or releases it.
You are right that there is no place where DMA_CTRL_ACK 
is cleared at the moment. I would say it is the offload engine driver 
responsibility to clear the flag when it recycles the descriptor.
Dan, could you confirm?

Regards,
Maciej

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: dmaengine: DMA_CTRL_ACK flag signification
  2008-10-07  9:09 ` Sosnowski, Maciej
@ 2008-10-13 18:51   ` Dan Williams
  0 siblings, 0 replies; 3+ messages in thread
From: Dan Williams @ 2008-10-13 18:51 UTC (permalink / raw)
  To: Sosnowski, Maciej; +Cc: Nicolas Ferre, Linux Kernel list, Haavard Skinnemoen

On Tue, Oct 7, 2008 at 2:09 AM, Sosnowski, Maciej
<maciej.sosnowski@intel.com> wrote:
> Nicolas Ferre wrote:
>> Hi all,
>>
>> I am in the process of writing a driver for an on-chip Atmel DMA
>> engine.
>>
>> I am a little confused about the use of the flag DMA_CTRL_ACK : It
>> seems that it is set in most of the descriptors in use except the
>> first or last of a descriptor chain. So, I cannot find where this
>> flag is cleared. In short, I do not see what it is used for : how
>> must I take it into account in my driver (in device_prep_dma_memcpy()
>> for instance) ?
>>
>> Can you enlighten me ?
>>
>> Regards,
>
> Hi Nicolas,
>
> Sorry for the delay in response.
> Generally the idea behind DMA_CTRL_ACK is to let an application
> safely set a chain of dependent operations.
> What a DMA driver needs to do is to check
> if a given descriptor has been already acked (using async_tx_test_ack())
> before it recycles or releases it.
> You are right that there is no place where DMA_CTRL_ACK
> is cleared at the moment. I would say it is the offload engine driver
> responsibility to clear the flag when it recycles the descriptor.
> Dan, could you confirm?

It may be better to call this the 'ownership' bit as while it is clear
client code owns the descriptor and can add dependent operations, once
it is set the dmaengine driver is free to recycle the descriptor for
use in another operation.  The driver's only responsibility* is to
read the bit in its cleanup routine.

--
Dan

*Note that if the driver decides to support transfer sizes larger than
its hardware maximum then it needs to set the ack bit on any internal
descriptors.  I.e. if the hardware can only do 4KB per descriptor it
would allocate two descriptors for an 8KB transfer and set the ack bit
on the first, leaving the second up to the caller.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-13 18:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-24 11:59 dmaengine: DMA_CTRL_ACK flag signification Nicolas Ferre
2008-10-07  9:09 ` Sosnowski, Maciej
2008-10-13 18:51   ` Dan Williams

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox