From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Thompson Date: Mon, 21 Jun 2010 16:21:47 +0100 Subject: [U-Boot] [PATCH] Davinci: SPI performance enhancements In-Reply-To: <0554BEF07D437848AF01B9C9B5F0BC5D9EAC8806@dlee01.ent.ti.com> References: <4C1F3082.8070108@ge.com> <0554BEF07D437848AF01B9C9B5F0BC5D9EAC8806@dlee01.ent.ti.com> Message-ID: <4C1F838B.7090803@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 21/06/10 15:41, Paulraj, Sandeep wrote: > > >> >> The following restructuring and optimisations increase the SPI >> read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830): >> >> Remove continual revaluation of driver state from the core of the >> copy loop. State can not change during the copy loop, so it is >> possible to move these evaluations to before the copy loop. >> >> Cost is more code space as loop variants are required for each set >> of possible configurations. The loops are simpler however, so the >> extra is only 128bytes on da830 with CONFIG_SPI_HALF_DUPLEX >> defined. >> >> Unrolling the first copy loop iteration allows the TX buffer to be >> pre-loaded reducing SPI clock starvation. >> >> Unrolling the last copy loop iteration removes testing for the >> final loop iteration every time round the loop. >> >> Using the RX buffer empty flag as a transfer throttle allows the >> assumption that it is always safe to write to the TX buffer, so >> polling of TX buffer full flag can be removed. >> >> Signed-off-by: Nick Thompson >> --- >> da850 and da830 are similar devices. The SPI module is common to >> both, but da850 uses DDR and da830 uses SDRAM. The EVM's might >> not actually be comparable, but they appear to be at least similar. >> >> The speed was tested with a 8MiB transfer from SPI FLASH using: >> >> sf read 0xc0008000 0 0x800000 >> >> drivers/spi/davinci_spi.c | 195 +++++++++++++++++++++++++++++----------- > > This patch does not apply against Wolfgang's next. > The patch should be against u-boot/next. It looks like Delio's patch ended up being pulled into main via Tom's tree and yours. On u-boot I see 9268236529161312c877e638a14c011fd3c883e1, but the same commit has id 23911740486c59851df57521c49bfd81ce1865ec on on u-boot-ti. I guess this is the source of the confusion? My patch was against u-boot, not u-boot-ti. Nick.