Hi Dan,

On Thu, Apr 15, 2010 at 6:00 AM, Dan Williams <dan.j.williams@intel.com> wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/