SPI controller bugfixes needed (full duplex + DMA, data corruption)

SPI controller bugfixes needed (full duplex + DMA, data corruption)

[David Brownell]

Hi,

We recently turned up a bug in the pxa2xx SPI driver, which
turns out to also be present in the spi_imx.c and au1550_spi.c
drivers too.

Briefly, full duplex transfers are allowed to share the
same buffer (or partially overlap it), which means that
the dma mapping operations must be done in a safe order:

 - first map the TX buffer, so cache data gets written
   to memory where the DMA will pick it up;

 - then map the RX buffer, so that cache entries (with
   soon-to-be-stale data) get removed.

Doing it the other order, as is done with spi_imx and
with au1550_spi, causes data corruption by discarding
data from the cache *before* writing it to memory.

If you can do it, it'd be good to see this fixed before
the 2.6.28 kernel ships.

- Dave

p.s. Note that full duplex transfers became a bit more
     common after f9b90e39cbc5c4d6ef60022fd1f25d541df0aad1
     merged (in the 2.6.28-rc0 merge frenzy).

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SPI controller bugfixes needed (full duplex + DMA, data corruption)

[Sascha Hauer]

Hi David,

On Sat, Nov 15, 2008 at 02:22:32PM -0800, David Brownell wrote:
> Hi,
> 
> We recently turned up a bug in the pxa2xx SPI driver, which
> turns out to also be present in the spi_imx.c and au1550_spi.c
> drivers too.
> 
> Briefly, full duplex transfers are allowed to share the
> same buffer (or partially overlap it), which means that
> the dma mapping operations must be done in a safe order:
> 
>  - first map the TX buffer, so cache data gets written
>    to memory where the DMA will pick it up;
> 
>  - then map the RX buffer, so that cache entries (with
>    soon-to-be-stale data) get removed.
> 
> Doing it the other order, as is done with spi_imx and
> with au1550_spi, causes data corruption by discarding
> data from the cache *before* writing it to memory.
> 
> If you can do it, it'd be good to see this fixed before
> the 2.6.28 kernel ships.

Hm, this is a non trivial fix. I don't have a MX1 based hardware with
something on the SPI bus handy, so this would be a shot in the dark for
me. I hope Andrea jumps in, otherwise we'll have to wait till the driver
works on MX2.

Sascha

-- 
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SPI controller bugfixes needed (full duplex + DMA, data corruption)

[Andrea Paterniani]

I have an iMX1 based HW running kernel 2.6.25.8.
I checked the patch and to seems to be ok (solves old problems on full 
duplex transfers).

Regards,
-- Andrea

Sascha Hauer ha scritto:
> Hi David,
>
> On Sat, Nov 15, 2008 at 02:22:32PM -0800, David Brownell wrote:
>   
>> Hi,
>>
>> We recently turned up a bug in the pxa2xx SPI driver, which
>> turns out to also be present in the spi_imx.c and au1550_spi.c
>> drivers too.
>>
>> Briefly, full duplex transfers are allowed to share the
>> same buffer (or partially overlap it), which means that
>> the dma mapping operations must be done in a safe order:
>>
>>  - first map the TX buffer, so cache data gets written
>>    to memory where the DMA will pick it up;
>>
>>  - then map the RX buffer, so that cache entries (with
>>    soon-to-be-stale data) get removed.
>>
>> Doing it the other order, as is done with spi_imx and
>> with au1550_spi, causes data corruption by discarding
>> data from the cache *before* writing it to memory.
>>
>> If you can do it, it'd be good to see this fixed before
>> the 2.6.28 kernel ships.
>>     
>
> Hm, this is a non trivial fix. I don't have a MX1 based hardware with
> something on the SPI bus handy, so this would be a shot in the dark for
> me. I hope Andrea jumps in, otherwise we'll have to wait till the driver
> works on MX2.
>
> Sascha
>
>   

-- 


 

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

*Ing. Andrea Paterniani*

*SWAPP* - Studio Professionale
Via degli Abeti, 312 - 61100 Pesaro
Tel 0721 24256
Fax 178 220 8730
 
a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org
www.swapp-eng.it 
<mailto:%0d%0aa.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org%0d%0awww.swapp-eng.it>

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SPI controller bugfixes needed (full duplex + DMA, data corruption)

[David Brownell]

On Tuesday 18 November 2008, Andrea Paterniani wrote:
> I have an iMX1 based HW running kernel 2.6.25.8.
> I checked the patch and to seems to be ok (solves old problems on full 
> duplex transfers).

Cool ... "solves old problems".  ;)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/