-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Mike Frysinger Sent: Thursday, August 27, 2009 1:54 PM To: Hu Mingkai-B21284 Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING Subject: Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support
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.
So the driver use the length passed by SPI flash read function. If the length is greater than the max value that is limited by the transaction length register's bitfiled, the driver couldn't read anything. We'll dig into this issue for the furture.
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 snt done with both BEGIN and END flags set.
Looks like now.
-mike
Thanks, Mingkai