[U-Boot] [PATCH] mx28: fix i.MX28 spi driver
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu --- drivers/spi/mxs_spi.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c index 4c27fef..adb9ca8 100644 --- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -129,9 +129,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, int len = bitlen / 8; const char *tx = dout; char *rx = din; - - if (bitlen == 0) - return 0; + char dummy; + + if (bitlen == 0) { + if (flags & SPI_XFER_END) { + rx = &dummy; + len = 1; + } else + return 0; + }
if (!rx && !tx) return 0;
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
This seems good, but it doesn't look too correct either (is there really no other way to deassert CS than doing dummy read?). Do you see an issue with current implementation on some board please?
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
drivers/spi/mxs_spi.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c index 4c27fef..adb9ca8 100644 --- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -129,9 +129,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, int len = bitlen / 8; const char *tx = dout; char *rx = din;
- if (bitlen == 0)
return 0;
char dummy;
if (bitlen == 0) {
if (flags & SPI_XFER_END) {rx = &dummy;len = 1;} elsereturn 0;}
if (!rx && !tx) return 0;
On 01/14/2012 03:10 PM, Marek Vasut wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
This seems good, but it doesn't look too correct either (is there really no other way to deassert CS than doing dummy read?).
Not that I am aware of. Did you wrote that mxs_spi driver? How did you interpret the chips reference manual. I understood it this way: you need to tell the controller to deassert chip select before the final transfer.
I could be possible to change the driver implementation and use GPIOs for chip select. But I think that's not the philisophy of this controller.
Do you see an issue with current implementation on some board please?
Yes, I installed an SST25VF032B SPI on the MX28EVK in preparation of our own board. The chip was detected correctly after power on, but erasing (that's one place where the status register polling is used) more than one page does not work and then after reset the device is not correctly detected.
I would expect problems on the M28EVK (Denx) also. You might want to turn SPI + spi_flash debugging to see it. Also I found a posting from Alexander Keller on the u-boot list from 12/13/2011. Perhaps the can check if this patch fixes his problems also.
Matthias
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
drivers/spi/mxs_spi.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c index 4c27fef..adb9ca8 100644 --- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -129,9 +129,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, int len = bitlen / 8; const char *tx = dout; char *rx = din;
- if (bitlen == 0)
return 0;
char dummy;
if (bitlen == 0) {
if (flags & SPI_XFER_END) {rx = &dummy;len = 1;} elsereturn 0;}
if (!rx && !tx) return 0;
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 01/14/2012 03:10 PM, Marek Vasut wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
This seems good, but it doesn't look too correct either (is there really
no
other way to deassert CS than doing dummy read?).
Not that I am aware of. Did you wrote that mxs_spi driver? How did you interpret the chips reference manual. I understood it this way: you need to tell the controller to deassert chip select before the final transfer.
I could be possible to change the driver implementation and use GPIOs for chip select. But I think that's not the philisophy of this controller.
Do you see an issue with current implementation on some board please?
Yes, I installed an SST25VF032B SPI on the MX28EVK in preparation of our own board. The chip was detected correctly after power on, but erasing (that's one place where the status register polling is used) more than one page does not work and then after reset the device is not correctly detected.
I would expect problems on the M28EVK (Denx) also. You might want to turn SPI + spi_flash debugging to see it. Also I found a posting from Alexander Keller on the u-boot list from 12/13/2011. Perhaps the can check
I just want to confirm and thanks to Matthias for this patch. I already stated my problems by writing the SPI flash ...
So, I use the IMX28EVK with a Winbond W25Q64CV SPI flash chip and it's working great now.
Thanks for the great work.
Alexander
if this patch fixes his problems also.
Matthias
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
drivers/spi/mxs_spi.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c index 4c27fef..adb9ca8 100644 --- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -129,9 +129,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, int len = bitlen / 8; const char *tx = dout; char *rx = din;
- if (bitlen == 0)
return 0;
char dummy;
if (bitlen == 0) {
if (flags & SPI_XFER_END) {rx = &dummy;len = 1;} elsereturn 0;}
if (!rx && !tx) return 0;
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
--
Dipl.-Ing. Matthias Fuchs Head of System Design
esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany
Geschäftsführer: Klaus Detering Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
On 1/16/12, Alexander Keller alexander.keller.85@gmx.de wrote:
I just want to confirm and thanks to Matthias for this patch. I already stated my problems by writing the SPI flash ...
So, I use the IMX28EVK with a Winbond W25Q64CV SPI flash chip and it's working great now.
Thanks for the great work.
Ok, great. Can you or Matthias post a patch adding SPI flash support to mx28evk?
I have just soldered one SPI flash on my board and would be glad to try it.
Regards,
Fabio Estevam
Hi Matthias,
On Sat, Jan 14, 2012 at 10:25 AM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
What about the approach bellow (untested)?
--- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -126,17 +126,14 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, { struct mxs_spi_slave *mxs_slave = to_mxs_slave(slave); struct mx28_ssp_regs *ssp_regs = mxs_slave->regs; - int len = bitlen / 8; + unsigned int len = bitlen / 8; const char *tx = dout; char *rx = din;
- if (bitlen == 0) - return 0; - if (!rx && !tx) return 0;
- if (flags & SPI_XFER_BEGIN) + if ((flags & SPI_XFER_BEGIN) && !len) mxs_spi_start_xfer(ssp_regs);
while (len--) {
On Sat, Jan 14, 2012 at 4:46 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Matthias,
On Sat, Jan 14, 2012 at 10:25 AM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
What about the approach bellow (untested)?
Actually I meant this:
--- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -136,7 +136,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, if (!rx && !tx) return 0;
- if (flags & SPI_XFER_BEGIN) + if ((flags & SPI_XFER_BEGIN) && len) mxs_spi_start_xfer(ssp_regs);
while (len--) {
On Sat, Jan 14, 2012 at 4:53 PM, Fabio Estevam festevam@gmail.com wrote:
Actually I meant this:
One more time ;-)
--- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -130,13 +130,10 @@ 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) + if ((flags & SPI_XFER_BEGIN) && len) mxs_spi_start_xfer(ssp_regs);
while (len--) {
This cannot work. I do not understand what you are trying to achieve with this.
Matthias
On 01/14/2012 07:54 PM, Fabio Estevam wrote:
On Sat, Jan 14, 2012 at 4:53 PM, Fabio Estevam festevam@gmail.com wrote:
Actually I meant this:
One more time ;-)
--- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -130,13 +130,10 @@ 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)
if ((flags & SPI_XFER_BEGIN) && len) mxs_spi_start_xfer(ssp_regs); while (len--) {
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Sat, Jan 14, 2012 at 6:09 PM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
This cannot work. I do not understand what you are trying to achieve with this.
I would like to avoid the extra dummy read that your patch proposes.
On 01/14/2012 09:14 PM, Fabio Estevam wrote:
On Sat, Jan 14, 2012 at 6:09 PM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
This cannot work. I do not understand what you are trying to achieve with this.
I would like to avoid the extra dummy read that your patch proposes.
That's what I also tried. But from the ref manual I got no idea. When we do not find a hy to deassert the chip select manually, we cannot avoid this read.
It seems that the mainline linux only implements a GPIO based SPI driver. So we cannot take it for reference.
I'm wonderng how this works on the Denx' M28EVK.
Matthias
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Sun, Jan 15, 2012 at 10:10 AM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
That's what I also tried. But from the ref manual I got no idea. When we do not find a hy to deassert the chip select manually, we cannot avoid this read.
I was assuming that the chip select deassertion was correctly being handled by the mxs_spi_end_xfer function.
This function handles the LOCK_CS and IGNORE_CRC bits that are responsible for chip select assertion/deassertion.
From the MX28 Reference Manual:
"IGNORE_CRC bit: In SPI/SSI modes: When set to 1, deassert the chip select (SSn) pin after the command is executed."
Then I tought that mxs_spi_end_xfer should be also called in the case where bitlen==0. In current code this does not happen.
It seems that the mainline linux only implements a GPIO based SPI driver. So we cannot take it for reference.
There is no mxs spi driver in the mainline kernel yet.
On 01/15/2012 04:28 PM, Fabio Estevam wrote:
On Sun, Jan 15, 2012 at 10:10 AM, Matthias Fuchs matthias.fuchs@esd.eu wrote:
That's what I also tried. But from the ref manual I got no idea. When we do not find a hy to deassert the chip select manually, we cannot avoid this read.
I was assuming that the chip select deassertion was correctly being handled by the mxs_spi_end_xfer function.
This function handles the LOCK_CS and IGNORE_CRC bits that are responsible for chip select assertion/deassertion.
From the MX28 Reference Manual:
"IGNORE_CRC bit: In SPI/SSI modes: When set to 1, deassert the chip select (SSn) pin after the command is executed."
Exactly. That's the point. It says "... after the command ...". So you need a transfer after calling mxs_spi_end_xfer(). That's why the current code calls it before transferring the final byte.
Matthias
Then I tought that mxs_spi_end_xfer should be also called in the case where bitlen==0. In current code this does not happen.
It seems that the mainline linux only implements a GPIO based SPI driver. So we cannot take it for reference.
There is no mxs spi driver in the mainline kernel yet. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 1/14/12, Matthias Fuchs matthias.fuchs@esd.eu wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
Tested-by: Fabio Estevam fabio.estevam@freescale.com
Soldered a SST25VF016B on a mx28evk (and also the SPI pullups) and verified that the flash can be erased succesfully now.
I suggest that this patch gets applied as it fixes a real issue.
Thanks,
Fabio Estevam
On 1/14/12, Matthias Fuchs matthias.fuchs@esd.eu wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
Tested-by: Fabio Estevam fabio.estevam@freescale.com
Soldered a SST25VF016B on a mx28evk (and also the SPI pullups) and verified that the flash can be erased succesfully now.
I suggest that this patch gets applied as it fixes a real issue.
Thanks,
Fabio Estevam
I'm all for it.
M
On 14/01/2012 13:25, Matthias Fuchs wrote:
The generic spi flash driver (drivers/mtd/spi/spi_flash.c) uses the spi low level driver's spi_xfer() function with len=0 to deassert the SPI flash' chip select. But the i.MX28 spi driver rejects this call due to len=0.
This patch implements an exception for len=0 with the SPI_XFER_END flag set. This results in an extra read with the chip select being deasserted afterwards. There seems to be no way to deassert the signal by hand.
Signed-off-by: Matthias Fuchs matthias.fuchs@esd.eu
Applied to u-boot-imx, thanks.
Best regards, Stefano Babic
Hi Stefano,
On Tue, Jan 24, 2012 at 6:40 AM, Stefano Babic sbabic@denx.de wrote:
Applied to u-boot-imx, thanks.
Which branch, please?
I am not able to find it.
Regards,
Fabio Estevam
On 28/01/2012 23:08, Fabio Estevam wrote:
Hi Stefano,
On Tue, Jan 24, 2012 at 6:40 AM, Stefano Babic sbabic@denx.de wrote:
Applied to u-boot-imx, thanks.
Hi Fabio,
Which branch, please?
I am not able to find it.
Sorry, I have not yet pushed to the server - done now.
Best regards, Stefano Babic
participants (5)
-
Alexander Keller -
Fabio Estevam -
Marek Vasut -
Matthias Fuchs -
Stefano Babic