On Thu, Oct 05, 2017 at 10:05:57AM +0300, Igor Plyatov wrote: > > please help to manage issue with data corruption by PDC of SPI. > > > > > > I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ > > on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression > > in the spi-atmel.c. Nobody working on the driver has any thoughts on this? > > > > New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I see > > corruption in data received by Linux and SPI overruns when OS has big > > CPI and IO load. > > > > Old kernel works fine at 22 MHz with the same device driver and hardware. > > > > Can somebody comment and/or help on how to resolve this issue? > > > > Best wishes. > > -- > > Igor Plyatov > > For those, who has same interest or encountered the same issue as I had... > > Notes: > A) My "gs_mgms_dsp" linux driver is the same for linux-2.6.39 and > linux-4.9.36 > and communicates with DSP through SPI-bus, where data packets are 32 byte > long and last byte is CRC8 to check data integrity. > B) CPU is AT91SAM9G20. > > I have encoutered SPI data corruption during receiving of data from DSP by > linux-4.9.36 if SPI-bus has big traffic in parallel with big traffic at MMC > interface. > > Old linux-2.6.39 does not suffer from such issue, because atmel-mci.c driver > has > PIO access to MMC interface. While new kernel has changed the atmel-mci.c > driver > for use of PDC (Peripheral DMA Controller) for access to MMC interface. > > Both kernels have Atmel SPI driver where PDC used for SPI data transfers. > > SPI data corruption looks like duplication of one of received bytes. > Such bytes surrounded by "**" at log below. > > gs_mgms_dsp spi32766.0: CRC error. > gs_mgms_dsp spi32766.0: <- 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 > gs_mgms_dsp spi32766.0: <- 45 46 47 48 49 4A 4B 4C 4D *4F 4F* 50 51 52 53 A4 > gs_mgms_dsp spi32766.0: -> EIO=0x05 > gs_mgms_dsp spi32766.0: CRC error. > gs_mgms_dsp spi32766.0: <- 0F C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 > gs_mgms_dsp spi32766.0: <- D1 D2 D3 D4 D5 D6 D7 D8 D9 *DB DB* DC DD DE DF 02 > gs_mgms_dsp spi32766.0: -> EIO=0x05 > gs_mgms_dsp spi32766.0: CRC error. > gs_mgms_dsp spi32766.0: <- 03 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 > gs_mgms_dsp spi32766.0: <- *6A 6A* 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 25 > gs_mgms_dsp spi32766.0: -> EIO=0x05 > gs_mgms_dsp spi32766.0: CRC error. > gs_mgms_dsp spi32766.0: <- 15 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 > gs_mgms_dsp spi32766.0: <- 85 86 87 88 89 8A *8C 8C* 8D 8E 8F 90 91 92 93 00 > gs_mgms_dsp spi32766.0: -> EIO=0x05 > gs_mgms_dsp spi32766.0: CRC error. > gs_mgms_dsp spi32766.0: <- 2A EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA > gs_mgms_dsp spi32766.0: <- FB FC FD FE FF 00 01 *03 03* 04 05 06 07 08 09 0A > gs_mgms_dsp spi32766.0: -> EIO=0x05 > > This looks like silent SPI overruns not detected by AT91SAM9G20 HW. > > At the end, after some seconds or milliseconds of communication, HW SPI > overrun > flag detected by the spi-atmel.c driver: > "atmel_spi fffcc000.spi: overrun (0/0 remaining)". > > Strictly speaking this is not a regression of spi-atmel.c, but unfortunate > combination with atmel-mmc.c, where PDC used too and I suppose a HW bug in > AT91SAM9G20 CPU. > > Please help to answer on questions: > 1) How to modify atmel-mci.c driver to have option for PIO access to MMC > interface? > 2) Why SPI overrun flag does not asserted each time? I have not found such > HW bug > in the Errata for AT91SAM9G20 CPU. > > Best wishes. > -- > Igor Plyatov
Attachment:
signature.asc
Description: PGP signature
