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

[Barry Song]

2013/9/3 Jassi Brar <jaswinder.singh at linaro.org>:
> On 3 September 2013 15:36, Barry Song <21cnbao at gmail.com> wrote:
>> 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.
>>
> A client is only interested in transferring the total amount data and
> if/when it wants notified. How the dma controller divides the big
> transfer, shouldn't matter to the client. In fact it would be bad for
> a client to care about the working of a dma controller.
> IOW, the 16KB transfer could be divided into 4 parts by the dmac that
> supports max 4KB transfers, into 8 parts if max is 2KB and so on...
> the client shouldn't care.

here my point is that we don't expose dma transferring hardware
details to clients. i actually wanted to hide that in dma driver not
dma client.
the only difference between vinod and me is that Vinod's point is
hiding that in dma core, my way is hiding it in dma driver.

btw, interleaved_dma clients do care about how the interleaved
transfer will happen. but single_dma client doesn't care.

>
> -jassi

-barry