[U-Boot] spi subystem maintainer?

[Stefano Babic <sbabic@denx.de>]

On 02/03/2011 11:36 AM, Kumar Gala wrote:
> That's correct, and with the newer FSL controller's we dont have
> direct control over the CS.

I know. You are probably talking about PowerPC, but it is the same for
the i.MX processors.

>  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; }

Ok. You are not talking generally about spi, but how to manage spi
flash. I saw the same problem with the i.MX51, but then a GPIO was used
instead of the internal SS and I forgot this issue. We do not need to
change the spi_xfer() call (I mean, in the spi controllers).

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

I think it could depend on the SPI flash you use. I checked in
stmicro.c, and the mechanism to split the enabling of SS and the
transfer of data is really used.

In stmicro_wait_ready(), it is used to poll the status of the flash. The
SS is active until the flash has complete the operation. Probably the
flash can accept a single call, too, but I am unsure.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================