[U-Boot] SPI Test

[Marek Vasut]

> On 15.01.2012 19:49, Marek Vasut wrote:
> >> On 01/15/2012 05:08 PM, Fabio Estevam wrote:
> >>> On Sun, Jan 15, 2012 at 10:31 AM, Matthias Fuchs
> >>> <matthias.fuchs at esd.eu>
> > 
> > wrote:
> >>>> -> finally we only need to deassert chip select. But the mxs_spi
> >>>> driver -> does not support this operation without doing a byte
> >>>> transfer.
> >>>> 
> >>>>        spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
> >>> 
> >>> Ok, so this is the point we need to fix in the mxs spi driver then.
> >>> 
> >>> How about:
> >>> 
> >>> diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
> >>> index 4c27fef..bb1804e 100644
> >>> --- a/drivers/spi/mxs_spi.c
> >>> +++ b/drivers/spi/mxs_spi.c
> >>> @@ -130,12 +130,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> >>> bitlen,
> >>> 
> >>>         const char *tx = dout;
> >>>         char *rx = din;
> >>> 
> >>> -       if (bitlen == 0)
> >>> -               return 0;
> >>> -
> >>> -       if (!rx && !tx)
> >>> -               return 0;
> >>> -
> >>> 
> >>>         if (flags & SPI_XFER_BEGIN)
> >>>         
> >>>                 mxs_spi_start_xfer(ssp_regs);
> >>> 
> >>> @@ -143,9 +137,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> >>> bitlen,
> >>> 
> >>>                 /* We transfer 1 byte */
> >>>                 writel(1, &ssp_regs->hw_ssp_xfer_size);
> >>> 
> >>> -               if ((flags & SPI_XFER_END) && !len)
> >>> -                       mxs_spi_end_xfer(ssp_regs);
> >>> -
> >>> 
> >>>                 if (tx)
> >>>                 
> >>>                         writel(SSP_CTRL0_READ,
> >>>                         &ssp_regs->hw_ssp_ctrl0_clr);
> >>>                 
> >>>                 else
> >>> 
> >>> @@ -181,6 +172,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> >>> bitlen,
> >>> 
> >>>                         return -1;
> >>>                 
> >>>                 }
> >>>         
> >>>         }
> >>> 
> >>> +
> >>> +               if (flags & SPI_XFER_END)
> >>> +                       mxs_spi_end_xfer(ssp_regs);
> >>> 
> >>>         return 0;
> >>>  
> >>>  }
> >>> 
> >>> This makes sure that mxs_spi_end_xfer will be also called in the case
> >>> where bitlen==0 and tx and rx== NULL, which is the case for
> >>> spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
> >>> 
> >>>> So I think we need to ask someone from Freescale for a manual abort or
> >>>> stay with my patch. Again, I agree, that it is not a shiny solution.
> >>>> But it works.
> >>> 
> >>> I think that  mxs_spi_end_xfer does the chip select deassertion
> >>> correctly based on the reference manual.
> >> 
> >> I don't think so! There must be a transfer after calling it.
> >> 
> >>> The issue I see with current implementation is that mxs_spi_end_xfer
> >>> is not called in the case where bitlen==0 and tx/rx == NULL.
> >> 
> >> That's true. But it's now the main problem :-)
> >> 
> >>> The suggestion I sent above tries to address this problem.
> >>> 
> >>> I will try to populate a SPI NOR on my mx28evk next week and try to
> >>> take a look at this issue.
> >> 
> >> Yes give it a try.
> >> 
> >> Marek, did you made the M28EVK port? Did you really test t with an
> >> SPI flash?
> > 
> > Yes, I did test it. But I only have one device on the SPI bus so it
> > doesn't matter if the CS remained asserted.
> 
> Hmm,
> 
> can you tell me what type of SPI flash you have installed?
> Typically the read-status-register operation requires a low to high
> transition to get terminated. This is from my flash' datasheet:
> 
> Read-Status-Register (RDSR)
> The Read-Status-Register (RDSR) instruction allows reading of the status
> register. The status register
> may be read at any time even during a Write (Program/Erase) operation.
> When a Write operation is in
> progress, the Busy bit may be checked before sending any new commands to
> assure that the new
> commands are properly received by the device. CE# must be driven low
> before the RDSR instruction is
> entered and remain low until the status data is read.
> Read-Status-Register is continuous with ongoing
> clock cycles until it is terminated by a low to high transition of the
> CE#. See Figure 16 for the RDSR instruction sequence...
> It's a SST part.

I just noticed ... Matthias, why don't you CC the mailing list?

Also, I can't really remember now what part there is.
> 
> Matthias