On Thursday, February 17, 2011 00:04:35 Mike Frysinger wrote:
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:
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 ?
seems this stalled because you guys instead took a queue+flush approach in your spi bus. but ive come across another hardware bus which (sounds like it) has the same limitations -- the ICH SPI controller from intel. you have to program into its hardware registers the command, the optional address, and whether you're going to be reading/writing afterwards. they needed to drop the SPI_XFER_{START,END} flags just like you in order to make things work.
further, while talking to people, it isnt as big of a deal as i had originally thought. the overhead from polling the SPI flash does go up slightly, but really only like by one byte on the bus (and the overhead to setup/bring down the transfer, but that's fairly minuscule).
so what i'm thinking is that since no other flags have materialized, we punt the SPI_XFER_{BEGIN,END} and make the API more Linux like. when i looked through the source, i couldnt find any other consumers that'd be adversely affected.
any other thoughts on the matter ? -mike