Re: [PATCHv5] DMAEngine: Define interleaved transfer request api

[Jassi Brar]

On 14 October 2011 22:34, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> On Fri, 2011-10-14 at 22:05 +0530, Jassi Brar wrote:
>> >> and some hardwares need two seperate dma channels to tranfer left
>> and
>> >> right audio channel.
>> >>
>> >> For 1st and 2nd dma channel, they want dma address increases 4bytes
>> >> and transfer 2bytes every line.
>> >> so it looks to me like a cyclic interleaved dma.
>> > Hmmm, do we have sound cards which use this?
>> > Nevertheless for this kind of transfers we would need interleaved
>> cyclic
>> > DMA as well, Do you have such usage? Can you tell me which codec
>> > requires this?
>> >
>> My proposed 'frm_irq' and 'cyclic' flags are for such requirements.
>>
>> Consider a 5.1chan I2S controller that employs 3 dma-channels
>> each transferring 2 audio-channels to 3 three FIFOs. And the
>> pcm-dma driver supports SNDRV_PCM_INFO_INTERLEAVED.
>> While I worked with simple single fifo 5.1chan I2S controllers, I
>> don't
>> think such 3-fifo controllers can't exist.
> I am not against cyclic, and yes 3 fifos can exist but one would
> question why we need 3 controller, 3 sets of ports and pins and
> associated analog stuff when one can do with one :)
>
No, 1 controller with 3 fifos. And that doesn't necessarily mean
pin count higher than the controller with single fifo.
Anyways, if you accepted interleaved Slave operation you should
not need such specific examples.
Cyclic transfers are not necessary for audio, but sure is the
preferred mechanism if supported.

> Nevertheless, cyclic should be supported for all dmaengine APIs (but not
> adding new APIs for cyclic) and in consistent manner by having a generic
> cyclic flag and caps.
>
You are already merging Cyclic into Slave_sg. And Slave_sg could be
merged into this api. So overall we would get rid one parameter passed
outside of the parameter structure - dmaxfer_template. (Yes I want to
reduce dependence on 'flags' argument as much as possible).
--
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/