2011/7/7 Raju, Sundaram :
> | 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,
> | skip = N,
>
.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 Tue, 2011-06-14 at 12:12 +0530, Raju, Sundaram wrote:
> Okay now things are more clear on what you are trying to do...
Vinod,
Sorr
On Tue, 2011-06-14 at 12:12 +0530, Raju, Sundaram wrote:
>
> >
> > 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 i
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 collectio
2011/6/14 Raju, Sundaram :
> 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(), ioctl()s would
sp.com; linux-omap@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
> wrote:
> > On Fri, Jun 10, 2011 at
On Fri, Jun 10, 2011 at 3:33 PM, Russell King - ARM Linux
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 sync rate progr
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
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
..@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 03:51:41PM +0530, Raju, Sundaram wrote:
> > Consider a simple video use case of de-interlacing a video buffer.
> &
er...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [RFC] dmaengine: add new api for preparing simple slave transfer
>
> >
> > The above 2 APIs in the dmaengine framework expect all the
> > peripheral/slave related attributes to be filled in the
&g
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 si
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. :)
> > > A simple single buffer transfer (i.e. non sg transfer) can be done only
> > > as a trivial case of the device_prep_slave_sg A
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
> >
p_dma_cyclic)(
> struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> size_t period_len, enum dma_data_direction direction);
>
> The number of frames (n_frames) can always be determined using all
> other values in the dma_buffer_config alon
On Thu, Jun 9, 2011 at 6:09 PM, Raju, Sundaram 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.
>
> -
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
> controlle
From: 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 ne
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 majord...@vger.kern
19 matches
Mail list logo
