On Wednesday 26 August 2009 23:01:52 Hu Mingkai-B21284 wrote:
From: Mike Frysinger [mailto:vapier@gentoo.org]
On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote:
But the eSPI controller integrate the chip select into the controller itself, it use the transfer length to control the duration of the chip select signal.
so you must tell the controller ahead of time how many bytes are going to be transferred ? this sounds like a retarded hardware implementation to me. how exactly do you support arbitrary transfer lengths ?
IIRC every transaction byte length control every transaction.
but what if you dont know the length of the transaction ahead of time ? if you look at the spi flash framework, it'll write a few bytes (like the opcode to read the status register) and then it'll just keep reading 1 byte at a time (polling the status register). there is no way of knowing the length ahead of time. most of the SPI code in u-boot operates this way.
The spi_flash_cmd_* function split the transfer into two steps: first the command transfer and then the data transfer. At the first step, the transfer length is set to the command length, and when transferred the command, the chip select will be negated, so the eSPI controller thinks the transfer is cancelled and doesn't transfer the data again.
the transfer state is passed in via the flags parameter. this way the SPI controller knows when a transfer starts (SPI_XFER_BEGIN) and when it ends (SPI_XFER_END).
As above, we can't use the start/end flags parameter.
then your controller wont be able to work with most (any?) of the code in u- boot. you need to reject every transfer that isnt done with both BEGIN and END flags set. -mike