public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Matthias Fuchs <matthias.fuchs@esd.eu>
To: u-boot@lists.denx.de
Subject: [U-Boot] mx28: bug in mxs_spi driver
Date: Fri, 13 Jan 2012 20:07:19 +0100	[thread overview]
Message-ID: <4F1080E7.2090809@esd.eu> (raw)

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

                 reply	other threads:[~2012-01-13 19:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F1080E7.2090809@esd.eu \
    --to=matthias.fuchs@esd.eu \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox