dw_spi CS control/transfer modes

dw_spi CS control/transfer modes

[Jamie Iles]

Hi,

I have a platform with a DesignWare SSI and I'm trying to use the dw_spi 
block using a GPIO for the chip select to workaround the problem of CS 
changing and the device losing state (we have a SPI flash attached), and 
I've found that using interrupt driven transfers, reading the SPI flash 
results in very few interrupts from the controller and a sluggish system 
(and no data from the flash).

However, I've found that removing the conditional transfer mode setting 
(effectively reverting commit 052dc7c45 [spi/dw_spi: conditional 
transfer mode changes]) allows everything to work fine by keeping the 
transfer mode to transmit+receive.

Does anyone have any ideas on the best way to fix this?  That code must 
have been added for a reason so perhaps it's just a quirk on our 
platform, but I'd be keen to know in what ways it's been tested before - 
afaict, no other in-tree platforms are using dw_spi with their own 
cs_control so it's difficult to know if perhaps these are all doing 
polled mode transfers.

Thanks,

Jamie

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: dw_spi CS control/transfer modes

[Feng Tang]

Hi Jamie,

On Sat, 19 Mar 2011 04:11:35 +0800
Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:

> Hi,
> 
> I have a platform with a DesignWare SSI and I'm trying to use the
> dw_spi block using a GPIO for the chip select to workaround the
> problem of CS changing and the device losing state (we have a SPI
> flash attached), and I've found that using interrupt driven
> transfers, reading the SPI flash results in very few interrupts from
> the controller and a sluggish system (and no data from the flash).
> 
> However, I've found that removing the conditional transfer mode
> setting (effectively reverting commit 052dc7c45 [spi/dw_spi:
> conditional transfer mode changes]) allows everything to work fine by
> keeping the transfer mode to transmit+receive.

What version of code are you using? The "cs_control" will be default to
NULL if "dw_spi_chip" as the controller data doesn't explicitly set it,
and then that piece of code won't be called.

Thanks,
Feng

> 
> Does anyone have any ideas on the best way to fix this?  That code
> must have been added for a reason so perhaps it's just a quirk on our 
> platform, but I'd be keen to know in what ways it's been tested
> before - afaict, no other in-tree platforms are using dw_spi with
> their own cs_control so it's difficult to know if perhaps these are
> all doing polled mode transfers.
> 
> Thanks,
> 
> Jamie
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: dw_spi CS control/transfer modes

[Jamie Iles]

Hi Feng,

On Mon, Mar 21, 2011 at 10:06:42AM +0800, Feng Tang wrote:
> Hi Jamie,
> 
> On Sat, 19 Mar 2011 04:11:35 +0800
> Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
> 
> > Hi,
> > 
> > I have a platform with a DesignWare SSI and I'm trying to use the
> > dw_spi block using a GPIO for the chip select to workaround the
> > problem of CS changing and the device losing state (we have a SPI
> > flash attached), and I've found that using interrupt driven
> > transfers, reading the SPI flash results in very few interrupts from
> > the controller and a sluggish system (and no data from the flash).
> > 
> > However, I've found that removing the conditional transfer mode
> > setting (effectively reverting commit 052dc7c45 [spi/dw_spi:
> > conditional transfer mode changes]) allows everything to work fine by
> > keeping the transfer mode to transmit+receive.
> 
> What version of code are you using? The "cs_control" will be default to
> NULL if "dw_spi_chip" as the controller data doesn't explicitly set it,
> and then that piece of code won't be called.

Sorry, I should have specified that; I'm using next as of a couple of 
days ago.  I am intentionally specifying a cs_control callback so that 
we can control the chip select using GPIO as we've seen with this block 
that allowing the FIFO to empty will cause the block driven CS to go 
low.  If we use only the block controlled CS then we get all zero's back 
from a programmed SPI flash.

Jamie

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d