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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Madhusudhan <madhu.cr@xxxxxx> wrote:
>> -----Original Message-----
>> From: svenkatr@xxxxxxxxx [mailto:svenkatr@xxxxxxxxx] On Behalf Of
>> Venkatraman S
>> Sent: Thursday, March 11, 2010 4:52 AM
>> To: Madhusudhan
>> Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
>> linux-omap@xxxxxxxxxxxxxxx
>> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> Madhusudhan <madhu.cr@xxxxxx> wrote:
>> >> -----Original Message-----
>> >> From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc-
>> >> owner@xxxxxxxxxxxxxxx] On Behalf Of Venkatraman S
>> >> Sent: Monday, March 01, 2010 5:27 AM
>> >> To: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
>> >> linux-omap@xxxxxxxxxxxxxxx
>> >> 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@xxxxxx>
>> >
>> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux