> -----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? > Regards, > Venkat. -- 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
