On Wednesday 26 August 2009 23:01:52 Hu Mingkai-B21284 wrote: > From: Mike Frysinger [mailto:vap...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
