On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala <sthokal@xxxxxxxxxx> wrote:
> Hi Vinod,
>
> On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
>> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
>>> Hi Lars/Vinod,
>>> >> The question here i think would be waht this device supports? Is the hardware
>>> >> capable of doing interleaved transfers, then would make sense.
>>> >
>>> > The hardware does 2D transfers. The parameters for a transfer are height,
>>> > width and stride. That's only a subset of what interleaved transfers can be
>>> > (xt->num_frames must be one for 2d transfers). But if I remember correctly
>>> > there has been some discussion on this in the past and the result of that
>>> > discussion was that using interleaved transfers for 2D transfers is
>>> > preferred over adding a custom API for 2D transfers.
>>>
>>> I went through the prep_interleaved_dma API and I see only one descriptor
>>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
>>> buffers (can be more in future), isn't it less efficient compared to the
>>> prep_slave_sg where we get a single sg list and can prepare all the descriptors
>>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
>>> know your opinions.
>> Well the descriptor maybe one, but that can represent multiple frames, for
>> example 16 as in your case. Can you read up the documentation of how multiple
>> frames are passed. Pls see include/linux/dmaengine.h
>>
>> /**
>> * Interleaved Transfer Request
>> * ----------------------------
>> * A chunk is collection of contiguous bytes to be transfered.
>> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>> * ICGs may or maynot change between chunks.
>> * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>> * that when repeated an integral number of times, specifies the transfer.
>> * A transfer template is specification of a Frame, the number of times
>> * it is to be repeated and other per-transfer attributes.
>> *
>> * Practically, a client driver would have ready a template for each
>> * type of transfer it is going to need during its lifetime and
>> * set only 'src_start' and 'dst_start' before submitting the requests.
>> *
>> *
>> * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>> *
>> * == Chunk size
>> * ... ICG
>> */
>
> Yes, it can handle multiple frames specified by 'numf' each of size
> 'frame_size * sgl[0].size'.
> But, I see it only works if all the frames' memory is contiguous and
> in this case we
> can just increment 'src_start' by the total frame size 'numf' number
> of times to fill in
> for each HW descriptor (each frame is one HW descriptor). So, there
> is no issue when the
> memory is contiguous. If the frames are non contiguous, we have to
> call this API for each
> frame (hence for each descriptor), as the src_start for each frame is
> different. Is it correct?
>
> FYI: This hardware has an inbuilt Scatter-Gather engine.
>
Ping?
> Srikanth
>
>>
>> --
>> ~Vinod
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
