[U-Boot] spi subystem maintainer?

[Mike Frysinger]

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 ?
> >> 
> >> Regards,
> >> Stefano
> > 
> > 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.
-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/20110215/8c717ebd/attachment.pgp