[U-Boot] spi subystem maintainer?

[Kumar Gala]

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)

- k