* spi-atmel.c: regression
@ 2017-10-02 14:45 Igor Plyatov
[not found] ` <0876ce0a-cb93-07b7-8019-e365d08cca2a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Igor Plyatov @ 2017-10-02 14:45 UTC (permalink / raw)
To: Nicolas Ferre, Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyrille Pitchen
Hello!
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: spi-atmel.c: regression
[not found] ` <0876ce0a-cb93-07b7-8019-e365d08cca2a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-10-05 7:05 ` Igor Plyatov
2017-10-25 9:24 ` Mark Brown
0 siblings, 1 reply; 3+ messages in thread
From: Igor Plyatov @ 2017-10-05 7:05 UTC (permalink / raw)
To: Nicolas Ferre, Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyrille Pitchen,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ludovic Desroches, Ulf Hansson
Hello!
> Hello!
>
> 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.
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: spi-atmel.c: regression
2017-10-05 7:05 ` Igor Plyatov
@ 2017-10-25 9:24 ` Mark Brown
0 siblings, 0 replies; 3+ messages in thread
From: Mark Brown @ 2017-10-25 9:24 UTC (permalink / raw)
To: Igor Plyatov, Nicolas Ferre, Cyrille Pitchen, Ludovic Desroches
Cc: linux-spi, linux-kernel, linux-mmc, Ulf Hansson
[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-10-25 9:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-02 14:45 spi-atmel.c: regression Igor Plyatov
[not found] ` <0876ce0a-cb93-07b7-8019-e365d08cca2a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-10-05 7:05 ` Igor Plyatov
2017-10-25 9:24 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).