[U-Boot] spi subystem maintainer?

[Mike Frysinger <vapier@gentoo.org>]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110818/8c3ec1bf/attachment.pgp