-----Original Message----- From: Mike Frysinger [mailto:vapier@gentoo.org] Sent: Thursday, August 27, 2009 3:23 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 Thursday 27 August 2009 02:59:34 Hu Mingkai-B21284 wrote:
From: Mike Frysinger [mailto:vapier@gentoo.org]
On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote:
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.
the length used by the first read covers just the length of the opcode, not any of the data returned by the part
as long as your driver rejects all of these things, it'll be detected at runtime and it should be fine to merge -mike
So the driver combine the opcode length and the data length
together,
then pass to spi_xfer(for eSPI) . When return the read
results, skip
the first opcode length bytes.
you dont get it ... there is no data length. the code does:
spi_write(~3 bytes for opcode, BEGIN flag); while (1) { spi_read(read 1 data byte); check_result(); } end_spi_transaction();
there is no "data length" which means your controller cannot support the SPI flash framework -mike
Sorry for the confusion, "the dirver" in my word refers to this patch that adds eSPI controller support. You're right, the controller can't support the SPI framework, that's the reason why this patch comes here. :-)
Thanks, Mingkai