[PATCH] dmaengine: sirf: add dmaengine_prep_slave_single/sg support
Barry Song
21cnbao at gmail.com
Tue Sep 3 08:42:36 EDT 2013
2013/9/3 Vinod Koul <vinod.koul at intel.com>:
> On Tue, Sep 03, 2013 at 06:06:44PM +0800, Barry Song 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.
> Why not:
>
> Okay there are two ways to this
> 1. Advertize your capablity and let client use that to break. You cna do so
> using dma_set/get_max_seg_size().
>
this way is ok. does max_seg also match with interleaved mode?
> 2. in DMAC, nothing stops you from breaking the given sg_list into smaller
> chunks. So if you get a buffer exceeding what you do, you cna internally split
> to multiple descriptors and chain those to parent one.
this way still need hacking in dmac driver.
>
>>
>> >
>> >> >> + 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.
> when the descriptor has been completed. You allocate in prepare. Bunch of driver
> already do so... I dont think its so complicated
here sirf dmac alloc all 16 desc in alloc_resoures and free all in
free_resources. if we can move the way you said, it is fine.
but it seems it means another separate patch for that.
>
> ~Vinod
> --
-barry
More information about the linux-arm-kernel
mailing list