On Sat, 2014-03-29 at 15:18 +0100, Gerhard Sittig wrote: > > On Thu, 2014-03-27 at 18:20 +0000, Mark Brown wrote: > > > > Can you try turning the > > tracepoints on and see if they show where the delays are? Both the > > message pump and transfer loops have a reasonable number of tracepoints > > in them. > > I did a 'dd if=/dev/mtd6 bs=1K' on an m25p80 chip. Gathered > traces suggest that each 1KB block leads to two transfers. The > second (the data part) takes several milliseconds (saw some > 3-10ms for 1024 bytes :-O ). But I fail to see what might take > this long. Will need to dig deeper. No progress here. Eyeballing the code reveals that there is a 50 times 10-100us retry loop at the end of a transfer, waiting for RX to complete after TX has drained. Instrumenting the code shows that the loop is run one or two times at most (longer timeouts are required for lower SPI wire speeds). So I still can't see what might take several milliseconds. Fixing a potential completion race, and early detection of the desired CS status after transmission (both changes that should preceed the switch to the common routine in the MPC512x case) won't change the situation either. I'm running out of ideas. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html