SPI controller bugfixes needed (full duplex + DMA, data corruption)
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=/
A message that is not in the archive (sent off-list or not yet received): 200811151422.32748.david-b-yBeKhBN/[email protected]
Hi David,
Quoted 16 lines · 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.candau1550_spi.cdrivers 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.
Quoted 6 lines
Doing it the other order, as is done with
spi_imxand withau1550_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
Signature · 10 lines
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=/A message that is not in the archive (sent off-list or not yet received): [email protected]
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:
Quoted 36 lines
Hi David,
Quoted 16 lines · 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.candau1550_spi.cdrivers 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.
Quoted 7 lines
Doing it the other order, as is done with
spi_imxand withau1550_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
Signature · 20 lines
------------------------------------------------------------------------ *Ing. Andrea Paterniani* *SWAPP* - Studio Professionale Via degli Abeti, 312 - 61100 Pesaro Tel 0721 24256 Fax 178 220 8730 a.paterniani-03BXCEkGbFHYGGNLXY5/[email protected] www.swapp-eng.it <mailto:%0d%0aa.paterniani-03BXCEkGbFHYGGNLXY5/[email protected]%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=/
A message that is not in the archive (sent off-list or not yet received): 49227D0A.40506-03BXCEkGbFHYGGNLXY5/[email protected]
Quoted 3 lines · 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).
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=/