[PATCH] dmaengine: sirf: add dmaengine_prep_slave_single/sg support

[Barry Song]

2013/9/2 Vinod Koul <vinod.koul at intel.com>:
> On Sun, Sep 01, 2013 at 09:02:01PM +0800, Barry Song wrote:
>> 2013/8/26 Vinod Koul <vinod.koul at intel.com>:
>> > On Sun, Aug 25, 2013 at 08:57:13PM +0800, Barry Song wrote:
>> >> the dma engine of sirfsoc supports interleaved mode, but if we set
>> >> xlen=width instead xlen<width, it will work as non-interleaved. as
>> >> most clients of sirf dma driver still don't need interleaved mode,
>> >> so here we still need to implement prep_slave_sg entry so that users
>> >> like uart, spi can use these APIs instead of interleaved API.
>> > Well in that case why dont you just create a wrapper on top of interleaved API
>> > to make this work without driver changes
>>
>> Vinod, do you mean using interleaved API to provide sg/single API if
>> specific drivers implement interleaved_dma but not implement sg_dma?
>>
>> the problem is that is difficult to set right legal sgl[i].size,
>> sgl[i].icg and numf for all dmaengines as that depends on specific dma
>> hardware limitation.
> The whole premise of doing the generic interleaved api was to ensure we can use
> any of the usuages as a case of interleaved api. Can you explain how it would be
> difficult?

for example, if someone wants to do a 16Kbytes single transfer. how
will interleaved dma set transfer length and interval between every
row?
if it sets the transfer length to 16KB directly, the dma hardware
might not support such long a transfer at all.
so it might want to set as two 8KB transfer without interval between them.
0~8KB                empty interval
8KB-16KB          empty interval
or four 4KB transfer as
0~4KB                empty interval
4KB-8KB          empty interval
8KB-12KB          empty interval
12KB-16KB          empty interval

the problem is we don't know the hardware limitation of every dma
controllers for transferring length of each row.

>
>> >> +     spin_lock_irqsave(&schan->lock, iflags);
>> >> +     list_for_each(l, &schan->free)
>> >> +             desc_cnt++;
>> > why dont you allocate descriptors here. That will remove this limitation..
>>
>> i understand. here sirf user scenerios will never be over the
>> limitation of SIRFSOC_DMA_DESCRIPTORS = 16. so i don't want to make it
>> too complex.
> I think you can make code simler by dynamically allocating and freeing
> descriptors...

when do you think is the right time to free? while the whole sg
finished? i always think the code will be ugly.

>
> ~Vinod
> --

-barry