Dmaengine query

Dmaengine query

[rd bairva]

Hi Dan,

	I am currently writing dmaengine compatible DMA driver for our ARM
based architecture, But I am facing some performance issues doing
that.

1. dmaengine says callback should run in tasklet, and next transfer
cannot be scheduled from the callback.

Due to these restrictions I am getting some performance issue while
playing sound in our architecture.


Can callback call in DMA driver be placed out of spin_lock to submit
new operations from callback? (only in asynchronous case)

is this Ok? please comment.


Thanks and regards,
Ramdayal

Re: Dmaengine query

[Dan Williams]

On Tue, Apr 13, 2010 at 11:26 PM, rd bairva <rbairva@gmail.com> wrote:
> Hi Dan,
>
>        I am currently writing dmaengine compatible DMA driver for our ARM
> based architecture, But I am facing some performance issues doing
> that.
>
> 1. dmaengine says callback should run in tasklet, and next transfer
> cannot be scheduled from the callback.
>
> Due to these restrictions I am getting some performance issue while
> playing sound in our architecture.
>
>
> Can callback call in DMA driver be placed out of spin_lock to submit
> new operations from callback? (only in asynchronous case)
>
> is this Ok? please comment.

Other dma driver authors are dropping the lock across the call to the
callback in the mem-to-io case.  The compliance points in the
documentation are primarily targeted at the expectations of the
async_tx api.  In the mem-to-io (slave dma) model you are not using
the async_tx api.

--
Dan

Re: Dmaengine query

[rd bairva]

Hi Dan,

On Thu, Apr 15, 2010 at 6:00 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Apr 13, 2010 at 11:26 PM, rd bairva <rbairva@gmail.com> wrote:
>> Hi Dan,
>>
>>        I am currently writing dmaengine compatible DMA driver for our ARM
>> based architecture, But I am facing some performance issues doing
>> that.
>>
>> 1. dmaengine says callback should run in tasklet, and next transfer
>> cannot be scheduled from the callback.
>>
>> Due to these restrictions I am getting some performance issue while
>> playing sound in our architecture.
>>
>>
>> Can callback call in DMA driver be placed out of spin_lock to submit
>> new operations from callback? (only in asynchronous case)
>>
>> is this Ok? please comment.
>
> Other dma driver authors are dropping the lock across the call to the
> callback in the mem-to-io case.  The compliance points in the
> documentation are primarily targeted at the expectations of the
> async_tx api.  In the mem-to-io (slave dma) model you are not using
> the async_tx api.
>
> --
> Dan
>

    My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Fwd: Dmaengine query

[rd bairva]

Hi Dan,

On Thu, Apr 15, 2010 at 6:00 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Apr 13, 2010 at 11:26 PM, rd bairva <rbairva@gmail.com> wrote:
>> Hi Dan,
>>
>> ? ? ? ?I am currently writing dmaengine compatible DMA driver for our ARM
>> based architecture, But I am facing some performance issues doing
>> that.
>>
>> 1. dmaengine says callback should run in tasklet, and next transfer
>> cannot be scheduled from the callback.
>>
>> Due to these restrictions I am getting some performance issue while
>> playing sound in our architecture.
>>
>>
>> Can callback call in DMA driver be placed out of spin_lock to submit
>> new operations from callback? (only in asynchronous case)
>>
>> is this Ok? please comment.
>
> Other dma driver authors are dropping the lock across the call to the
> callback in the mem-to-io case. ?The compliance points in the
> documentation are primarily targeted at the expectations of the
> async_tx api. ?In the mem-to-io (slave dma) model you are not using
> the async_tx api.
>
> --
> Dan
>

? ?My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Dmaengine query

My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Dmaengine query

[rd bairva]

My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Dmaengine query

[rd bairva]

Hi Dan,

   My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Dmaengine query

[rd bairva]

Hi Dan,

? ?My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?


Regards
Ramdayal

Re: Dmaengine query

[Linus Walleij]

2010/4/19 rd bairva <rbairva@gmail.com>:

>    My DMA controller supports device to device DMA transfers and we
> need it in some of our drivers. Existing DMA engine framework doesn't
> have support for device to device transfers.
>
> Do you have any plans for device to device support in DMA engine?
>
> Can you suggest me some other suggestion for doing this?

Extend the DMA engine with the stuff you need and propose nice
patches, provide them along with a driver that make use of this
feature.

What about a signature like this:

struct dma_async_tx_descriptor *(*device_prep_slave2slave)(
                struct dma_chan *chan1, struct dma_chan *chan2,
                enum dma_data_direction direction,
                unsigned long flags);

You'd have to add some semantics comment saying that
DMA_TO_DEVICE means chan1->chan2 and
DMA_FROM_DEVICE means chan1<-chan2.

Could be a bit of hacking but how hard can it be?

Yours,
Linus Walleij