; linux-arm-ker...@lists.infradead.org
Subject: RE: [RFC] dmaengine: add new api for preparing simple slave transfer
On Tue, 2011-06-14 at 12:12 +0530, Raju, Sundaram wrote:
snip
Okay now things are more clear on what you are trying to do...
Vinod,
Sorry for the delayed response. I was OOO
2011/7/7 Raju, Sundaram sunda...@ti.com:
| Just put some enumerator in enum dma_ctrl_cmd in
| dmaengine.h such as SDMA_TEXAS_STRIDE_CONFIG and call
| like this:
|
| /* However that config struct needs to look, basically */
| static struct sdma_ti_stride_cgf = {
| take = M,
|
On Tue, 2011-06-14 at 12:12 +0530, Raju, Sundaram wrote:
snip
The overall conclusion which I'm coming to is that we already support
what you're asking for, but the problem is that we're using different
(and I'd argue standard) terminology to describe what we have.
The only issue
2011/6/14 Raju, Sundaram sunda...@ti.com:
Yes, the hardware can skip over sequences like that.
I also thought about your suggestion, at first before submitting the RFC.
But I dint pursue this because, this ioctl() call has to be made before
every single prepare call.
It's not an ioctl(),
Russell,
Thanks for all the quick pointers and the summary of how
memory-to-peripheral transfers are expected to operate.
Ok, what I'm envisioning is that your term chunk size means register
width, and you view that as one dimension. We already describe this.
A frame is a collection of
On Fri, Jun 10, 2011 at 3:33 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jun 10, 2011 at 05:18:46PM +0530, Raju, Sundaram wrote:
Now DMACs capable of 3D transfer, do transfer of the whole 1D
buffer per sync received or even whole 2D buffer per sync received
(based on the
@vger.kernel.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC] dmaengine: add new api for preparing simple slave transfer
On Fri, Jun 10, 2011 at 3:33 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jun 10, 2011 at 05:18:46PM +0530, Raju
;
davinci-linux-open-sou...@linux.davincidsp.com; linux-omap@vger.kernel.org
Subject: Re: [RFC] dmaengine: add new api for preparing simple slave transfer
Can you please re-post with sensible wrapping at or before column 72.
I'm not manually reformatting your entire message just so I can find
On Thu, 2011-06-09 at 17:32 +0100, Russell King - ARM Linux wrote:
On Thu, Jun 09, 2011 at 09:31:56PM +0530, Raju, Sundaram wrote:
Here it is, with proper line wrapping;
Thanks. This is much easier to reply to.
I believe that even though the dmaengine framework addresses and
supports
I think I should have tried to explain my case with a specific example.
I tried to generalize it and it has confused and misled every one.
I have tried again now. :)
snip
A simple single buffer transfer (i.e. non sg transfer) can be done only
as a trivial case of the device_prep_slave_sg
On Fri, Jun 10, 2011 at 03:51:41PM +0530, Raju, Sundaram wrote:
Consider a simple video use case of de-interlacing a video buffer.
Odd lines have to be transferred first, and then the even lines are
transferred separately. This can be done by programming the
inter frame gap as the line size
-ker...@lists.infradead.org
Subject: RE: [RFC] dmaengine: add new api for preparing simple slave transfer
snip
The above 2 APIs in the dmaengine framework expect all the
peripheral/slave related attributes to be filled in the
dma_slave_config data structure.
struct dma_slave_config
-arm-
ker...@lists.infradead.org
Subject: Re: [RFC] dmaengine: add new api for preparing simple slave transfer
On Fri, Jun 10, 2011 at 03:51:41PM +0530, Raju, Sundaram wrote:
Consider a simple video use case of de-interlacing a video buffer.
Odd lines have to be transferred first
On Fri, Jun 10, 2011 at 05:18:46PM +0530, Raju, Sundaram wrote:
Russell,
How do you handle the situation where a driver uses your new proposed
API, but it doesn't support that in hardware.
It should be handled the same way how a sg buffer is handled,
if LLI chaining feature is not
On Fri, 2011-06-10 at 16:43 +0530, Raju, Sundaram wrote:
Vinod,
...
Now coming to the buffer related attributes, sg list is a nice way to
represent a disjoint buffer; all the offload engines in drivers/dma
create a descriptor for each of the contiguous chunk in the sg list
buffer
Can you please re-post with sensible wrapping at or before column 72.
I'm not manually reformatting your entire message just so I can find
the relevant bits to reply to.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, June 09, 2011 6:17 PM
To: Raju, Sundaram
Cc: linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
davinci-linux-open-sou...@linux.davincidsp.com; linux-omap@vger.kernel.org
Subject: Re: [RFC] dmaengine: add new api
On Thu, Jun 09, 2011 at 09:31:56PM +0530, Raju, Sundaram wrote:
Here it is, with proper line wrapping;
Thanks. This is much easier to reply to.
I believe that even though the dmaengine framework addresses and
supports most of the required use cases of a client driver to a DMA
controller,
On Thu, Jun 9, 2011 at 6:09 PM, Raju, Sundaram sunda...@ti.com wrote:
Generic buffer description:
A generic buffer can be split into number of frames which contain number of
chunks inside them. The frames need not be contiguous, nor do the chunks
inside a frame.
19 matches
Mail list logo
