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
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
