[PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[svenkatr@ti.com (Venkatraman S)]

Madhusudhan <madhu.cr@ti.com> wrote:
>> -----Original Message-----
>> From: svenkatr at gmail.com [mailto:svenkatr at gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Thursday, March 11, 2010 4:52 AM
>> To: Madhusudhan
>> Cc: linux-mmc at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> linux-omap at vger.kernel.org
>> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> Madhusudhan <madhu.cr@ti.com> wrote:
>> >> -----Original Message-----
>> >> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
>> >> owner at vger.kernel.org] On Behalf Of Venkatraman S
>> >> Sent: Monday, March 01, 2010 5:27 AM
>> >> To: linux-mmc at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> >> linux-omap at vger.kernel.org
>> >> Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> >> autoloading feature
>> >>
>> >> Start to use the sDMA descriptor autoloading feature.
>> >> For large datablocks, the MMC driver has to repeatedly setup, program
>> >> and teardown the
>> >> dma channel for each element of the sglist received in
>> omap_hsmmc_request.
>> >>
>> >> By using descriptor autoloading, transfers from / to each element of
>> >> the sglist is pre programmed
>> >> into a linked list. The sDMA driver completes the entire transaction
>> >> and provides a single interrupt.
>> >>
>> >> Due to this, number of dma interrupts for a typical 100MB transfer on
>> the
>> >> MMC is
>> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
>> >> improved by ~5%
>> >> (Though it varies on the size of read / write & improves on huge
>> >> transfers)
>> >>
>> >> Descriptor autoloading is available only in 3630 and 4430 (as of now).
>> >> Hence normal DMA
>> >> mode is also retained.
>> >>
>> >> Tested on omap4430 sdp.
>> >>
>> >> Signed-off-by: Venkatraman S <svenkatr@ti.com>
>> >
>> > I don't see any issues with this patch except the concern I had on the
>> first
>> > patch in the series. Why is that change linked to this series?
>> >
>> ? Thanks. The problem was seen only in the context of using descriptor
>> load. Would
>> you prefer that I post it as a separate patch ?
>
> My point is why that change is needed for this feature to work?
>
> When DMA is completed and a callback is received the ch can be freed. Once
> TC is received the core is notified of the same.
>
> Can the first patch be dropped? Or do you see issues?
Yes there are issues without this patch when the scatterlist is large
(300+ blocks), where the dma completion interrupt is received but the
mmc driver hangs waiting for TC. I don't see the issue if I delay the
execution of omap_free_dma inside the dma callback.