On Tuesday, February 15, 2011 18:10:47 Kumar Gala wrote:
On Feb 15, 2011, at 2:36 AM, Mike Frysinger wrote:
On Thursday, February 03, 2011 05:36:38 Kumar Gala wrote:
On Feb 2, 2011, at 3:30 AM, Reinhard Meyer wrote:
Dear Stefano Babic:
On 02/02/2011 08:23 AM, Kumar Gala wrote:
Wanted to see if anyone had input on how to deal with the SPI controller on some of our newer parts. It expects command & data xfer's to happen together. However our current code does not call spi_xfer() that way.
Which is your concrete case ? spi_xfer is responsible to setup the controller and to start the transfer, and everything could be done inside this function. What do you mean exactly with command and data ?
I think he refers to the common "problem" that many SPI devices require CS to stay low during both "phases" of issuing the read/write command and transfering the actual data.
Current u-boot code calls spi_xfer() two times.
Hardware controlled CS often go high between both calls, which requires you to (at least) use GPIO controlled CS, or, even worse, use bitbang SPI (in cases where the SPI pin assignment is in groups, not individually).
That's correct, and with the newer FSL controller's we dont have direct control over the CS. 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; } 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)
this should be easier in my sf branch as i unified a bunch of the functions. but while this will probably work for the main commands, how is this supposed to work for the status polling ? that function is fundamentally based around setting up a transfer/command and then continuously shifting out a single result and checking it before shifting out another. for your controller, the only way to make it work is to do the full transaction every time.
Probably have to do a transaction every time.
looking at the Linux driver, it seems to do just that. i guess if Linux is getting by with a stricter API, then there shouldnt be a problem for U-Boot either. i dont suppose anyone knows of devices that are problematic in Linux or would be broken in U-Boot by this API change in general ?
this assumes of course that the SPI API as used in Linux works for you ?
Do you have a tree for these changes? Do you expect them to be in place for release after v2011.03
the sf branch of my blackfin tree. if no one gives me any feedback (i posted the patches on the list a while ago), i guess i'll see about merging post the next release. -mike