[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Matthias Fuchs]

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;

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Marek Vasut]

> 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;
> +		} else
> +			return 0;
> +	}
> 
>  	if (!rx && !tx)
>  		return 0;

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Matthias Fuchs]

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;
>> +		} else
>> +			return 0;
>> +	}
>>
>>  	if (!rx && !tx)
>>  		return 0;
> _______________________________________________
> U-Boot mailing list
> U-Boot at 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
-------------------------------------------------------------------------

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Alexander Keller]

> 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;
> >> +		} else
> >> +			return 0;
> >> +	}
> >>
> >>  	if (!rx && !tx)
> >>  		return 0;
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at 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
> -------------------------------------------------------------------------

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[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--) {

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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--) {

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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] [PATCH] mx28: fix i.MX28 spi driver

[Matthias Fuchs]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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.

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Matthias Fuchs]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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.

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Matthias Fuchs]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[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

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Marek Vasut]

> 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

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Stefano Babic]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Fabio Estevam]

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

[U-Boot] [PATCH] mx28: fix i.MX28 spi driver

[Stefano Babic]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================