> 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.fu...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
