[U-Boot] spi subystem maintainer?

[Kumar Gala]

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

Probably have to do a transaction every time.

Do you have a tree for these changes?  Do you expect them to be in place for release after v2011.03

- k