SPI trouble on Colibri 270 (PXA)...

SPI trouble on Colibri 270 (PXA)...

[Jakob Viketoft]

Hello!

I've come to a dead end in finding out what's wrong with my SPI setup so 
I was hoping that someone here has some pointers to help me along. I'm 
trying to use an m25p80 SPI flash through the pxa2xx SPI controller 
(through SSP1), but read accesses go wrong (I haven't even tried writing 
yet). What happens is that after the pxa2xx writes the read command on 
the SPI bus, the chip is deselected - effectively terminating the read 
operation. Some 100 us afterwards the cs go low again and it seems as 
the read operation is continued (clock runs, no output data), but by 
then the chip has already terminated. Forcing the cs_change bit on each 
transfer doesn't seem to do any difference, there is still a pause 
between two transfers in the same message.

I haven't seen any other board using the same combination (the m25p80 
and the pxa2xx), but I'm still opting for an error on my part somewhere. 
I've attached my SPI configuration (board setup) in the end of the mail.

I'm ready for any suggestions at this point. Please CC me as I'm not on 
the list.

Regards,

	/Jakob

------------

/*
  *  linux/arch/arm/mach-pxa/colibri-pxa270-spi.c
  *
  *  Separate file for the Toradex Colibri 270 SPI definitions to avoid
  *  conflicts with the "regular" flash includes.
  *  Jakob Viketoft <info@bitsim.com>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License version 2 as
  *  published by the Free Software Foundation.
  */

#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
#include <mach/pxa2xx_spi.h>
#include <mach/mfp-pxa27x.h>
#include <mach/pxa2xx-regs.h>
#include <mach/gpio.h>

#include "generic.h"
#include "devices.h"

/* SPI interface on SSP1 */
static unsigned long colibri_spi_pin_config[] __initdata = {
	GPIO23_SSP1_SCLK,
	GPIO24_SSP1_SFRM,
	GPIO25_SSP1_TXD,
	GPIO26_SSP1_RXD,
};

static struct pxa2xx_spi_master colibri_spi_ssp1_info = {
	.clock_enable = CKEN_SSP1,
	.num_chipselect	= 1,
	.enable_dma = 0,
};

struct mtd_partition fpga_flash_partitions[] = {
	{
		.name		= "FPGA code",
		.size		= 0x00100000,
		.offset		= 0,
		.mask_flags	= 0,
//		.mask_flags	= MTD_WRITEABLE,
	},
};

static struct flash_platform_data colibri_spi_m25p80_info = {
	.type		= "m25p80",
	.name		= "fpga_flash",
	.parts		= fpga_flash_partitions,
	.nr_parts	= ARRAY_SIZE(fpga_flash_partitions),
};

static struct pxa2xx_spi_chip colibri_spi_m25p80_chip = {
	.rx_threshold = 1,
	.tx_threshold = 1,
	.gpio_cs = GPIO24_SSP1_SFRM,
};

static struct spi_board_info __initdata colibri_spi_devices[] = {
	{
		.modalias	= "m25p80",
		.max_speed_hz	= 1200000,
		.bus_num	= 1,
		.chip_select	= 0,
		.platform_data	= &colibri_spi_m25p80_info,
		.controller_data= &colibri_spi_m25p80_chip,
	},
  };

static int __init colibri_init_spi(void)
{
	printk(KERN_ERR "Init Colibri SPI\n");
	pxa2xx_mfp_config(ARRAY_AND_SIZE(colibri_spi_pin_config));
	pxa2xx_set_spi_info(1, &colibri_spi_ssp1_info);
	return spi_register_board_info(ARRAY_AND_SIZE(colibri_spi_devices));
}

subsys_initcall(colibri_init_spi);

SPI trouble on Colibri 270 (PXA)...

[Eric Miao]

On Tue, Apr 20, 2010 at 7:58 PM, Jakob Viketoft <jakob@viketoft.se> wrote:
> Hello!
>
> I've come to a dead end in finding out what's wrong with my SPI setup so I
> was hoping that someone here has some pointers to help me along. I'm trying
> to use an m25p80 SPI flash through the pxa2xx SPI controller (through SSP1),
> but read accesses go wrong (I haven't even tried writing yet). What happens
> is that after the pxa2xx writes the read command on the SPI bus, the chip is
> deselected - effectively terminating the read operation. Some 100 us
> afterwards the cs go low again and it seems as the read operation is
> continued (clock runs, no output data), but by then the chip has already
> terminated. Forcing the cs_change bit on each transfer doesn't seem to do
> any difference, there is still a pause between two transfers in the same
> message.
>
> I haven't seen any other board using the same combination (the m25p80 and
> the pxa2xx), but I'm still opting for an error on my part somewhere. I've
> attached my SPI configuration (board setup) in the end of the mail.
>

Not looked into m25p80 code, but CS is normally asserted before a transfer
begins and deasserted after a transfer is done. I doubt there are some cases
where the transfer is not set up correctly.

Actually, cs_assert() and cs_deassert() are there in pxa2xx_spi.c as two very
good debugging point to print out the transfer information to see if they are
setup correctly.

> I'm ready for any suggestions at this point. Please CC me as I'm not on the
> list.
>
> Regards,
>
> ? ? ? ?/Jakob
>
> ------------
>
> /*
> ?* ?linux/arch/arm/mach-pxa/colibri-pxa270-spi.c
> ?*
> ?* ?Separate file for the Toradex Colibri 270 SPI definitions to avoid
> ?* ?conflicts with the "regular" flash includes.
> ?* ?Jakob Viketoft <info@bitsim.com>
> ?*
> ?* ?This program is free software; you can redistribute it and/or modify
> ?* ?it under the terms of the GNU General Public License version 2 as
> ?* ?published by the Free Software Foundation.
> ?*/
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/physmap.h>
> #include <linux/spi/spi.h>
> #include <linux/spi/flash.h>
> #include <mach/pxa2xx_spi.h>
> #include <mach/mfp-pxa27x.h>
> #include <mach/pxa2xx-regs.h>
> #include <mach/gpio.h>
>
> #include "generic.h"
> #include "devices.h"
>
> /* SPI interface on SSP1 */
> static unsigned long colibri_spi_pin_config[] __initdata = {
> ? ? ? ?GPIO23_SSP1_SCLK,
> ? ? ? ?GPIO24_SSP1_SFRM,
> ? ? ? ?GPIO25_SSP1_TXD,
> ? ? ? ?GPIO26_SSP1_RXD,
> };
>
> static struct pxa2xx_spi_master colibri_spi_ssp1_info = {
> ? ? ? ?.clock_enable = CKEN_SSP1,
> ? ? ? ?.num_chipselect = 1,
> ? ? ? ?.enable_dma = 0,
> };
>
> struct mtd_partition fpga_flash_partitions[] = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "FPGA code",
> ? ? ? ? ? ? ? ?.size ? ? ? ? ? = 0x00100000,
> ? ? ? ? ? ? ? ?.offset ? ? ? ? = 0,
> ? ? ? ? ? ? ? ?.mask_flags ? ? = 0,
> // ? ? ? ? ? ? ?.mask_flags ? ? = MTD_WRITEABLE,
> ? ? ? ?},
> };
>
> static struct flash_platform_data colibri_spi_m25p80_info = {
> ? ? ? ?.type ? ? ? ? ? = "m25p80",
> ? ? ? ?.name ? ? ? ? ? = "fpga_flash",
> ? ? ? ?.parts ? ? ? ? ?= fpga_flash_partitions,
> ? ? ? ?.nr_parts ? ? ? = ARRAY_SIZE(fpga_flash_partitions),
> };
>
> static struct pxa2xx_spi_chip colibri_spi_m25p80_chip = {
> ? ? ? ?.rx_threshold = 1,
> ? ? ? ?.tx_threshold = 1,
> ? ? ? ?.gpio_cs = GPIO24_SSP1_SFRM,
> };
>
> static struct spi_board_info __initdata colibri_spi_devices[] = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.modalias ? ? ? = "m25p80",
> ? ? ? ? ? ? ? ?.max_speed_hz ? = 1200000,
> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 1,
> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
> ? ? ? ? ? ? ? ?.platform_data ?= &colibri_spi_m25p80_info,
> ? ? ? ? ? ? ? ?.controller_data= &colibri_spi_m25p80_chip,
> ? ? ? ?},
> ?};
>
> static int __init colibri_init_spi(void)
> {
> ? ? ? ?printk(KERN_ERR "Init Colibri SPI\n");
> ? ? ? ?pxa2xx_mfp_config(ARRAY_AND_SIZE(colibri_spi_pin_config));
> ? ? ? ?pxa2xx_set_spi_info(1, &colibri_spi_ssp1_info);
> ? ? ? ?return spi_register_board_info(ARRAY_AND_SIZE(colibri_spi_devices));
> }
>
> subsys_initcall(colibri_init_spi);
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

SPI trouble on Colibri 270 (PXA)...

[Jakob Viketoft]

Eric Miao wrote:
> On Tue, Apr 20, 2010 at 7:58 PM, Jakob Viketoft <jakob@viketoft.se> wrote:
<...>
>> I haven't seen any other board using the same combination (the m25p80 and
>> the pxa2xx), but I'm still opting for an error on my part somewhere. I've
>> attached my SPI configuration (board setup) in the end of the mail.
>>
> 
> Not looked into m25p80 code, but CS is normally asserted before a transfer
> begins and deasserted after a transfer is done. I doubt there are some cases
> where the transfer is not set up correctly.

Well, in this case when doing a read you must set up a write transfer to 
write the read command + address and then a read transfer to actually 
read back the data. In this case the cs musn't be deasserted between 
transfers because this means the operation is terminated.

> Actually, cs_assert() and cs_deassert() are there in pxa2xx_spi.c as two very
> good debugging point to print out the transfer information to see if they are
> setup correctly.

When I look at how these two are used I get a an serie of assert, 
assert, deassert for each read operation (which should be correct 
behaviour). This suggests that something else is deasserting the cs or 
that the CPU is doing something on it's own accord. Hmmm...

Regards,

	/Jakob

SPI trouble on Colibri 270 (PXA)...

[Marek Vasut]

Dne ?t 20. dubna 2010 17:20:37 Jakob Viketoft napsal(a):
> Eric Miao wrote:
> > On Tue, Apr 20, 2010 at 7:58 PM, Jakob Viketoft <jakob@viketoft.se> wrote:
> <...>
> 
> >> I haven't seen any other board using the same combination (the m25p80
> >> and the pxa2xx), but I'm still opting for an error on my part
> >> somewhere. I've attached my SPI configuration (board setup) in the end
> >> of the mail.
> > 
> > Not looked into m25p80 code, but CS is normally asserted before a
> > transfer begins and deasserted after a transfer is done. I doubt there
> > are some cases where the transfer is not set up correctly.
> 
> Well, in this case when doing a read you must set up a write transfer to
> write the read command + address and then a read transfer to actually
> read back the data. In this case the cs musn't be deasserted between
> transfers because this means the operation is terminated.
> 
> > Actually, cs_assert() and cs_deassert() are there in pxa2xx_spi.c as two
> > very good debugging point to print out the transfer information to see
> > if they are setup correctly.
> 
> When I look at how these two are used I get a an serie of assert,
> assert, deassert for each read operation (which should be correct
> behaviour). This suggests that something else is deasserting the cs or
> that the CPU is doing something on it's own accord. Hmmm...
> 
> Regards,
> 
> 	/Jakob
> 

You can try using gpio-spi driver as used in palmz72.c ... I had issues with 
pxa2xx-spi interfacing the OV96xx camera, but it worked well for me with gpio-
spi.

Looking at it now, it seems the patch was never merged, here's a shortened 
version, try something similar:

>From 777212ce6d3bacea76281aa3d74839a3c38b32a4 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marek.vasut@gmail.com>
Date: Sat, 22 Aug 2009 05:15:10 +0200
Subject: [PATCH 3/3] PalmZ72: Add support for OV9640 camera sensor

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
 arch/arm/mach-pxa/include/mach/palmz72.h |    5 +
 arch/arm/mach-pxa/palmz72.c              |  126 
+++++++++++++++++++++++++++++-
 2 files changed, 130 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index c3645aa..e4449ad 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -30,6 +30,7 @@
 #include <linux/wm97xx_batt.h>
 #include <linux/power_supply.h>
 #include <linux/usb/gpio_vbus.h>
+#include <linux/i2c-gpio.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -120,6 +123,28 @@ static unsigned long palmz72_pin_config[] __initdata = {
        GPIO22_GPIO,    /* LCD border color */
        GPIO96_GPIO,    /* lcd power */

+       /* I2C */
+       GPIO117_GPIO,   /* I2C_SCL */
+       GPIO118_GPIO,   /* I2C_SDA */

+static struct i2c_gpio_platform_data palmz72_i2c_bus_data = {
+       .sda_pin = 118,
+       .scl_pin = 117,
+       .udelay  = 10,
+       .timeout = 100,
+};
+
+static struct platform_device palmz72_i2c_bus_device = {
+       .name           = "i2c-gpio",
+       .id             = 0, /* we use this as a replacement for i2c-pxa */
+       .dev = {
+               .platform_data = &palmz72_i2c_bus_data,
+       }
+};

 #ifdef CONFIG_PM
 
 /* We have some black magic here
@@ -576,6 +665,8 @@ static struct platform_device *devices[] __initdata = {
        &palmz72_asoc,
        &power_supply,
        &palmz72_gpio_vbus,
+       &palmz72_i2c_bus_device,
 };
 

SPI trouble on Colibri 270 (PXA)...

[Eric Miao]

On Wed, Apr 21, 2010 at 5:44 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Dne ?t 20. dubna 2010 17:20:37 Jakob Viketoft napsal(a):
>> Eric Miao wrote:
>> > On Tue, Apr 20, 2010 at 7:58 PM, Jakob Viketoft <jakob@viketoft.se> wrote:
>> <...>
>>
>> >> I haven't seen any other board using the same combination (the m25p80
>> >> and the pxa2xx), but I'm still opting for an error on my part
>> >> somewhere. I've attached my SPI configuration (board setup) in the end
>> >> of the mail.
>> >
>> > Not looked into m25p80 code, but CS is normally asserted before a
>> > transfer begins and deasserted after a transfer is done. I doubt there
>> > are some cases where the transfer is not set up correctly.
>>
>> Well, in this case when doing a read you must set up a write transfer to
>> write the read command + address and then a read transfer to actually
>> read back the data. In this case the cs musn't be deasserted between
>> transfers because this means the operation is terminated.
>>
>> > Actually, cs_assert() and cs_deassert() are there in pxa2xx_spi.c as two
>> > very good debugging point to print out the transfer information to see
>> > if they are setup correctly.
>>
>> When I look at how these two are used I get a an serie of assert,
>> assert, deassert for each read operation (which should be correct
>> behaviour). This suggests that something else is deasserting the cs or
>> that the CPU is doing something on it's own accord. Hmmm...
>>
>> Regards,
>>
>> ? ? ? /Jakob
>>
>
> You can try using gpio-spi driver as used in palmz72.c ... I had issues with
> pxa2xx-spi interfacing the OV96xx camera, but it worked well for me with gpio-
> spi.
>
> Looking at it now, it seems the patch was never merged, here's a shortened
> version, try something similar:
>
> From 777212ce6d3bacea76281aa3d74839a3c38b32a4 Mon Sep 17 00:00:00 2001
> From: Marek Vasut <marek.vasut@gmail.com>
> Date: Sat, 22 Aug 2009 05:15:10 +0200
> Subject: [PATCH 3/3] PalmZ72: Add support for OV9640 camera sensor
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> ?arch/arm/mach-pxa/include/mach/palmz72.h | ? ?5 +
> ?arch/arm/mach-pxa/palmz72.c ? ? ? ? ? ? ?| ?126
> +++++++++++++++++++++++++++++-
> ?2 files changed, 130 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
> index c3645aa..e4449ad 100644
> --- a/arch/arm/mach-pxa/palmz72.c
> +++ b/arch/arm/mach-pxa/palmz72.c
> @@ -30,6 +30,7 @@
> ?#include <linux/wm97xx_batt.h>
> ?#include <linux/power_supply.h>
> ?#include <linux/usb/gpio_vbus.h>
> +#include <linux/i2c-gpio.h>
>
> ?#include <asm/mach-types.h>
> ?#include <asm/mach/arch.h>
> @@ -120,6 +123,28 @@ static unsigned long palmz72_pin_config[] __initdata = {
> ? ? ? ?GPIO22_GPIO, ? ?/* LCD border color */
> ? ? ? ?GPIO96_GPIO, ? ?/* lcd power */
>
> + ? ? ? /* I2C */
> + ? ? ? GPIO117_GPIO, ? /* I2C_SCL */
> + ? ? ? GPIO118_GPIO, ? /* I2C_SDA */
>
> +static struct i2c_gpio_platform_data palmz72_i2c_bus_data = {
> + ? ? ? .sda_pin = 118,
> + ? ? ? .scl_pin = 117,
> + ? ? ? .udelay ?= 10,
> + ? ? ? .timeout = 100,
> +};
> +
> +static struct platform_device palmz72_i2c_bus_device = {
> + ? ? ? .name ? ? ? ? ? = "i2c-gpio",
> + ? ? ? .id ? ? ? ? ? ? = 0, /* we use this as a replacement for i2c-pxa */
> + ? ? ? .dev = {
> + ? ? ? ? ? ? ? .platform_data = &palmz72_i2c_bus_data,
> + ? ? ? }
> +};
>

I thought we were talking about SPI?

SPI trouble on Colibri 270 (PXA)...

[Martin Guy]

On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:

>  I thought we were talking about SPI?

We are. It affects boards that have a single SD/MMC card on the SPI
bus and use SFRMOUT as the chip select line, which impacts how the SPI
driver needs to handle multi-part messages without dropping CS between
transfers

    M

SPI trouble on Colibri 270 (PXA)...

[Eric Miao]

On Wed, Apr 21, 2010 at 7:11 PM, Martin Guy <martinwguy@gmail.com> wrote:
> On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
>
>> ?I thought we were talking about SPI?
>
> We are. It affects boards that have a single SD/MMC card on the SPI
> bus and use SFRMOUT as the chip select line, which impacts how the SPI
> driver needs to handle multi-part messages without dropping CS between
> transfers
>

If CS isn't expected to be dropped between transfers within a single message,
I guess that's possible with ".cs_change", otherwise might be not feasible with
the current code.

> ? ?M
>

SPI trouble on Colibri 270 (PXA)...

[Martin Guy]

On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
>  If CS isn't expected to be dropped between transfers within a single message,
>  I guess that's possible with ".cs_change", otherwise might be not feasible with
>  the current code.

That is already in; we are trying to make it work as it should

   M

SPI trouble on Colibri 270 (PXA)...

[Marek Vasut]

Dne St 21. dubna 2010 12:47:29 Eric Miao napsal(a):
> On Wed, Apr 21, 2010 at 5:44 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dne ?t 20. dubna 2010 17:20:37 Jakob Viketoft napsal(a):
> >> Eric Miao wrote:
> >> > On Tue, Apr 20, 2010 at 7:58 PM, Jakob Viketoft <jakob@viketoft.se> 
wrote:
> >> <...>
> >> 
> >> >> I haven't seen any other board using the same combination (the m25p80
> >> >> and the pxa2xx), but I'm still opting for an error on my part
> >> >> somewhere. I've attached my SPI configuration (board setup) in the
> >> >> end of the mail.
> >> > 
> >> > Not looked into m25p80 code, but CS is normally asserted before a
> >> > transfer begins and deasserted after a transfer is done. I doubt there
> >> > are some cases where the transfer is not set up correctly.
> >> 
> >> Well, in this case when doing a read you must set up a write transfer to
> >> write the read command + address and then a read transfer to actually
> >> read back the data. In this case the cs musn't be deasserted between
> >> transfers because this means the operation is terminated.
> >> 
> >> > Actually, cs_assert() and cs_deassert() are there in pxa2xx_spi.c as
> >> > two very good debugging point to print out the transfer information
> >> > to see if they are setup correctly.
> >> 
> >> When I look at how these two are used I get a an serie of assert,
> >> assert, deassert for each read operation (which should be correct
> >> behaviour). This suggests that something else is deasserting the cs or
> >> that the CPU is doing something on it's own accord. Hmmm...
> >> 
> >> Regards,
> >> 
> >>       /Jakob
> > 
> > You can try using gpio-spi driver as used in palmz72.c ... I had issues
> > with pxa2xx-spi interfacing the OV96xx camera, but it worked well for me
> > with gpio- spi.
> > 
> > Looking at it now, it seems the patch was never merged, here's a
> > shortened version, try something similar:
> > 
> > From 777212ce6d3bacea76281aa3d74839a3c38b32a4 Mon Sep 17 00:00:00 2001
> > From: Marek Vasut <marek.vasut@gmail.com>
> > Date: Sat, 22 Aug 2009 05:15:10 +0200
> > Subject: [PATCH 3/3] PalmZ72: Add support for OV9640 camera sensor
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > ---
> >  arch/arm/mach-pxa/include/mach/palmz72.h |    5 +
> >  arch/arm/mach-pxa/palmz72.c              |  126
> > +++++++++++++++++++++++++++++-
> >  2 files changed, 130 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
> > index c3645aa..e4449ad 100644
> > --- a/arch/arm/mach-pxa/palmz72.c
> > +++ b/arch/arm/mach-pxa/palmz72.c
> > @@ -30,6 +30,7 @@
> >  #include <linux/wm97xx_batt.h>
> >  #include <linux/power_supply.h>
> >  #include <linux/usb/gpio_vbus.h>
> > +#include <linux/i2c-gpio.h>
> > 
> >  #include <asm/mach-types.h>
> >  #include <asm/mach/arch.h>
> > @@ -120,6 +123,28 @@ static unsigned long palmz72_pin_config[] __initdata
> > = { GPIO22_GPIO,    /* LCD border color */
> >        GPIO96_GPIO,    /* lcd power */
> > 
> > +       /* I2C */
> > +       GPIO117_GPIO,   /* I2C_SCL */
> > +       GPIO118_GPIO,   /* I2C_SDA */
> > 
> > +static struct i2c_gpio_platform_data palmz72_i2c_bus_data = {
> > +       .sda_pin = 118,
> > +       .scl_pin = 117,
> > +       .udelay  = 10,
> > +       .timeout = 100,
> > +};
> > +
> > +static struct platform_device palmz72_i2c_bus_device = {
> > +       .name           = "i2c-gpio",
> > +       .id             = 0, /* we use this as a replacement for i2c-pxa
> > */ +       .dev = {
> > +               .platform_data = &palmz72_i2c_bus_data,
> > +       }
> > +};
> 
> I thought we were talking about SPI?

Argh, yes sorry, I was in a hurry when I was replying. Ignore this.

SPI trouble on Colibri 270 (PXA)...

[Jakob Viketoft]

Martin Guy wrote:
> On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
> 
>>  I thought we were talking about SPI?
> 
> We are. It affects boards that have a single SD/MMC card on the SPI
> bus and use SFRMOUT as the chip select line, which impacts how the SPI
> driver needs to handle multi-part messages without dropping CS between
> transfers

Does this mean that this is a know issue with the pxa2xx spi driver? At 
the moment I'm rather pressed for time and have instead opted for 
compressing the two transfers (read command and actual read) into one. 
There is a slight memory overhead in writing, but nothing that will 
impact our system...

	/Jakob

SPI trouble on Colibri 270 (PXA)...

[Martin Guy]

On 4/21/10, Jakob Viketoft <jakob@viketoft.se> wrote:
> Martin Guy wrote:
> > On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
> > >  I thought we were talking about SPI?
> >
> > We are. It affects boards that have a single SD/MMC card on the SPI
> > bus and use SFRMOUT as the chip select line, which impacts how the SPI
> > driver needs to handle multi-part messages without dropping CS between
> > transfers
>
>  Does this mean that this is a know issue with the pxa2xx spi driver? At the
> moment I'm rather pressed for time and have instead opted for compressing
> the two transfers (read command and actual read) into one. There is a slight
> memory overhead in writing, but nothing that will impact our system...

No, it means I'm on the wrong thread and I'm talking complete rubbish.
That was about the ep93x-spi-mmc problems in the next room.
Sorry about that. Just ignore me, I'm confused...

    M

SPI trouble on Colibri 270 (PXA)...

[Jakob Viketoft]

Eric Miao wrote:
> On Wed, Apr 21, 2010 at 8:47 PM, Jakob Viketoft <jakob@viketoft.se> wrote:
>> Martin Guy wrote:
>>> On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>
>>>>  I thought we were talking about SPI?
>>> We are. It affects boards that have a single SD/MMC card on the SPI
>>> bus and use SFRMOUT as the chip select line, which impacts how the SPI
>>> driver needs to handle multi-part messages without dropping CS between
>>> transfers
>> Does this mean that this is a know issue with the pxa2xx spi driver? At the
>> moment I'm rather pressed for time and have instead opted for compressing
>> the two transfers (read command and actual read) into one.
> 
> I'm expecting this to be correct code, i.e. by combining read command
> transfer and actual read transfer into a single message, with .cs_change
> indicating that CS not changed during transfer. No?

The original code currently combines the two transfers in one message as
you say (leaving CS asserted unless cs_change is set). However, I don't
know if it's a problem with scheduling or that the interrupt takes too
long to serve, but on my platform the two transfers (in the same
message) doesn't go back-to-back as they should and CS gets deasserted
in the middle. Thus I have combined the two transfers into one and the
message only hold this single transfer. Now things work at my end, but
it's annoying that I don't have time to track down the real issue at the
moment...

	/Jakob

SPI trouble on Colibri 270 (PXA)...

[Vernon Sauder]

Jakob Viketoft wrote, On 04/22/2010 10:36 AM:
> Eric Miao wrote:
>> On Wed, Apr 21, 2010 at 8:47 PM, Jakob Viketoft <jakob@viketoft.se>
>> wrote:
>>> Martin Guy wrote:
>>>> On 4/21/10, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>
>>>>>  I thought we were talking about SPI?
>>>> We are. It affects boards that have a single SD/MMC card on the SPI
>>>> bus and use SFRMOUT as the chip select line, which impacts how the SPI
>>>> driver needs to handle multi-part messages without dropping CS between
>>>> transfers
>>> Does this mean that this is a know issue with the pxa2xx spi driver?
>>> At the
>>> moment I'm rather pressed for time and have instead opted for
>>> compressing
>>> the two transfers (read command and actual read) into one.
>>
>> I'm expecting this to be correct code, i.e. by combining read command
>> transfer and actual read transfer into a single message, with .cs_change
>> indicating that CS not changed during transfer. No?
> 
> The original code currently combines the two transfers in one message as
> you say (leaving CS asserted unless cs_change is set). However, I don't
> know if it's a problem with scheduling or that the interrupt takes too
> long to serve, but on my platform the two transfers (in the same
> message) doesn't go back-to-back as they should and CS gets deasserted
> in the middle. Thus I have combined the two transfers into one and the
> message only hold this single transfer. Now things work at my end, but
> it's annoying that I don't have time to track down the real issue at the
> moment...
> 
>     /Jakob
> 

As part of this thread:
http://permalink.gmane.org/gmane.linux.kernel.spi.devel/1517
I added the following note to Documentation/spi/pxa2xx. I have not
checked to see if the patch hit mainline. Is this part of the answer to
your question?

> +NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the
> +chipselect is dropped after each spi_transfer.  Most devices need chip select
> +asserted around the complete message.  Use SSPFRM as a GPIO (through cs_control)
> +to accomodate these chips.

That was my solution to using the pxa2xx SPI with M25Pxx flash.

-- 
Regards,
 Vernon Sauder
 (: !Have a great day! :)

SPI trouble on Colibri 270 (PXA)...

[Jakob Viketoft]

Vernon Sauder wrote:
> Jakob Viketoft wrote, On 04/22/2010 10:36 AM:
<...>
>> The original code currently combines the two transfers in one message as
>> you say (leaving CS asserted unless cs_change is set). However, I don't
>> know if it's a problem with scheduling or that the interrupt takes too
>> long to serve, but on my platform the two transfers (in the same
>> message) doesn't go back-to-back as they should and CS gets deasserted
>> in the middle. Thus I have combined the two transfers into one and the
>> message only hold this single transfer. Now things work at my end, but
>> it's annoying that I don't have time to track down the real issue at the
>> moment...
>>
>>     /Jakob
>>
> 
> As part of this thread:
> http://permalink.gmane.org/gmane.linux.kernel.spi.devel/1517
> I added the following note to Documentation/spi/pxa2xx. I have not
> checked to see if the patch hit mainline. Is this part of the answer to
> your question?
> 
>> +NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the
>> +chipselect is dropped after each spi_transfer.  Most devices need chip select
>> +asserted around the complete message.  Use SSPFRM as a GPIO (through cs_control)
>> +to accomodate these chips.
> 
> That was my solution to using the pxa2xx SPI with M25Pxx flash.
> 

Yes, I saw that note in the documentation. Unfortunately it wasn't what 
was causing my problem. I think a code patch has been applied to control 
  the SSPFRM as a gpio through the .gpio_cs option, but this seem to be 
missing from the documentation.

 From the sound of it, I think I'm running into the same kind of trouble 
as shown by the SPI controller on the EP93xx.

	/Jakob

SPI trouble on Colibri 270 (PXA)...

[Eric Miao]

On Sat, Apr 24, 2010 at 3:57 AM, Jakob Viketoft <jakob@viketoft.se> wrote:
> Vernon Sauder wrote:
>>
>> Jakob Viketoft wrote, On 04/22/2010 10:36 AM:
>
> <...>
>>>
>>> The original code currently combines the two transfers in one message as
>>> you say (leaving CS asserted unless cs_change is set). However, I don't
>>> know if it's a problem with scheduling or that the interrupt takes too
>>> long to serve, but on my platform the two transfers (in the same
>>> message) doesn't go back-to-back as they should and CS gets deasserted
>>> in the middle. Thus I have combined the two transfers into one and the
>>> message only hold this single transfer. Now things work at my end, but
>>> it's annoying that I don't have time to track down the real issue at the
>>> moment...
>>>
>>> ? ?/Jakob
>>>
>>
>> As part of this thread:
>> http://permalink.gmane.org/gmane.linux.kernel.spi.devel/1517
>> I added the following note to Documentation/spi/pxa2xx. I have not
>> checked to see if the patch hit mainline. Is this part of the answer to
>> your question?
>>
>>> +NOTE: the SPI driver cannot control the chip select if SSPFRM is used,
>>> so the
>>> +chipselect is dropped after each spi_transfer. ?Most devices need chip
>>> select
>>> +asserted around the complete message. ?Use SSPFRM as a GPIO (through
>>> cs_control)
>>> +to accomodate these chips.
>>
>> That was my solution to using the pxa2xx SPI with M25Pxx flash.
>>
>
> Yes, I saw that note in the documentation. Unfortunately it wasn't what was
> causing my problem. I think a code patch has been applied to control ?the
> SSPFRM as a gpio through the .gpio_cs option, but this seem to be missing
> from the documentation.
>

You want to configure the SSPFRM pin as generic GPIO with MFP API
as well, if you want to set that pin as .gpio_cs.

> From the sound of it, I think I'm running into the same kind of trouble as
> shown by the SPI controller on the EP93xx.
>
> ? ? ? ?/Jakob
>