[U-Boot] SPI Test

[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@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

[U-Boot] SPI Test

[Matthias Fuchs]

On 16.01.2012 12:23, Marek Vasut wrote:
>> 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?
Fabio wanted to stop the list being flood with this discussion.
But you are right. Let's stop this thread an return to the list.

Matthias

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

[U-Boot] SPI Test

[Marek Vasut]

> On 16.01.2012 12:23, Marek Vasut wrote:
> >> 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?
> 
> Fabio wanted to stop the list being flood with this discussion.

No, please flood ... that's what the mailing list is for in there.

> But you are right. Let's stop this thread an return to the list.

We can safely continue here.

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