Re: [PATCH V1] dmaengine: tegra: add dma driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi Vinod,

On Monday 23 April 2012 06:47 PM, Laxman Dewangan wrote:
On Monday 23 April 2012 06:36 PM, Russell King - ARM Linux wrote:
On Mon, Apr 23, 2012 at 05:47:03PM +0530, Laxman Dewangan wrote:
Hi Russell,
On Monday 23 April 2012 02:11 PM, Vinod Koul wrote:
On Fri, 2012-04-20 at 17:46 +0530, Laxman Dewangan wrote:
Thanks Vinod for quick review.
Since I was on vacation, I hadn't noticed Russell has already sent the
patches for omap dma support.
http://permalink.gmane.org/gmane.linux.ports.arm.omap/75034

It would be nice if both the efforts are coordinated.

Btw I like the virtual channel support introduced by Russell

Can you please point me the virtual channel related change? I am not
able to locate this like search for function vchan_* ().
My driver is also on same line but not used vchan_* and also having
support for cyclic transfer.
It's only been posted in RFC form on linux-arm-kernel and linux-omap
lists.  The specific patch is:

http://lists.arm.linux.org.uk/lurker/message/20120418.101116.082b350f.en.html

I wouldn't call it perfected yet, but usable.  It doesn't have any
knowledge about cyclic transfers either.
For simple dma, it is straight to use the virt_chan and it reduce lots
of code from tegra_dma as most of it moved to the virt_dma.

Some points which I am looking are:
1. Extending this for cyclic support:
In cyclic mode, we need to call callback after period_len but do not
want to free descriptors. So either I need to add flag on the desctiptor
to no delet and so when vc->desc_free(vd); is called from callback, it
will not delete the descriptor.

2. With very prep call, we are allocating descriptor. Is it is possible
to allocate some desc in advance and then keep using them. The
complexity is that if we allocate the desc in advance, we need to
allocate the desc and sq_req list and maintain the two different lists
as we dont know the sg_len in advance.

3. vchan_cookie_complete()  is not possible in the cyclic mode as we
dont want to call dma_cookie_complete() but just want to do following
two thing:

list_add_tail(&vd->node,&vc->desc_completed);
tasklet_schedule(&vc->task);

if we extend this function to bypass dma_cookie_complete(&vd->tx); or
rather than calling this api, directly call the above apis.



I had a communication with Russell on another change thread and understand that some more work need to be done in virt_chan to support cyclic one.

I want to have the cyclic dma support in my driver so I want to go on following steps: 1. I will post the patch for tegra dma which will not use the virt_dma so that my driver will be independent of Russel's change. 2. Once the tegra dma is part of tree, I can move all my dma client to use the dmaengine based driver and remove old style dma. 3. Till that time Russell's will have already virt_dma support for cyclic one and so I will change tegra_dma.c to use virt_dma.


Let me know your opinion so that I can plan my patch/change accordingly.

Thanks,
Laxman

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[ARM Kernel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]     [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux