[U-Boot] spi subystem maintainer?

[Mike Frysinger <vapier@gentoo.org>]

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
-------------- 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/20110217/67e718d7/attachment.pgp