On 02/03/2011 11:36 AM, Kumar Gala wrote:
That's correct, and with the newer FSL controller's we dont have direct control over the CS.
I know. You are probably talking about PowerPC, but it is the same for the i.MX processors.
I'm thinking we need to have the command and response dealt with in a single call to spi_xfer instead of what we seem to do all over the place today:
ret = spi_xfer(spi, 8, &cmd, NULL, flags); if (ret) { debug("SF: Failed to send command %02x: %d\n", cmd, ret); return ret; }
Ok. You are not talking generally about spi, but how to manage spi flash. I saw the same problem with the i.MX51, but then a GPIO was used instead of the internal SS and I forgot this issue. We do not need to change the spi_xfer() call (I mean, in the spi controllers).
if (len) { ret = spi_xfer(spi, len * 8, NULL, response, SPI_XFER_END); if (ret) debug("SF: Failed to read response (%zu bytes): %d\n", len, ret); }
Needs to turn into something like:
ret = spi_xfer(spi, 8 + len * 8, &cmd, response, flags | SPI_XFER_END)
I think it could depend on the SPI flash you use. I checked in stmicro.c, and the mechanism to split the enabling of SS and the transfer of data is really used.
In stmicro_wait_ready(), it is used to poll the status of the flash. The SS is active until the flash has complete the operation. Probably the flash can accept a single call, too, but I am unsure.
Stefano