[U-Boot] mx28: bug in mxs_spi driver

[U-Boot] mx28: bug in mxs_spi driver

[Matthias Fuchs]

Hi,

I ran into trouble when trying to extend MX28EVK board support for a SPI
flash (SST24VF032B).

Some code finally runs into spi_flash_cmd_poll_bit() (spi_flash.c).
This function is then used to poll the flash's status register:

int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
                           u8 cmd, u8 poll_bit)
{
        struct spi_slave *spi = flash->spi;
        unsigned long timebase;
        int ret;
        u8 status;

        ret = spi_xfer(spi, 8, &cmd, NULL, SPI_XFER_BEGIN);
        if (ret) {
                debug("SF: Failed to send command %02x: %d\n", cmd, ret);
                return ret;
        }

        timebase = get_timer(0);
        do {
                WATCHDOG_RESET();

                ret = spi_xfer(spi, 8, NULL, &status, 0);
                if (ret)
                        return -1;

                if ((status & poll_bit) == 0)
                        break;

        } while (get_timer(timebase) < timeout);

        spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);

        if ((status & poll_bit) == 0)
                return 0;

        /* Timed out */
        debug("SF: time out!\n");
        return -1;
}

It first asserts the flash's chip select transmits the command (first call to 
spi_xfer - e.g. read status register) and then reads a single byte in a loop
until e.g. the BUSY bit is cleared. Finally it calls  spi_xfer(spi, 0, 
NULL, NULL, SPI_XFER_END) to deassert the SPI flash chip select.

But this last spi_xfer() call does not work with the mxs_spi. You must tell the
controller to deassert the select line before the final read cycle! I don't see
a way to fix this inside mxs_spi.c:spi_xfer(). These seems to be no way to manually
deassert the chip select. Or did I miss something?

Well, with the current code spi_flash_cmd_poll_bit() ends up with an asserted 
chip select. For SPI flashes this will make the chip behave unexpected on
the next command!.

A dirty way would be to change the last call to xpi_xfer (see above)
into:
        spi_xfer(spi, 8, NULL, &status, SPI_XFER_END);

This will result in an additional byte transfer with the select being 
deasserted finally.

Any better ideas to fix this?
I am wondering how SPI flash on the Denx' M28EVK can work.

Matthias