Re: [BUG] spi/spi-atmel: DMA rx buffer corruption with SPI_IOC_MESSAGE

[Richard Genoud]

2013/10/21 Yang, Wenyou <Wenyou.Yang@xxxxxxxxx>:
> Hi Richard,
>
>> -----Original Message-----
>> From: Richard Genoud [mailto:richard.genoud@xxxxxxxxx]
>> Sent: 2013å10æ17æ 19:01
>> To: Yang, Wenyou
>> Cc: linux-spi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Ferre, Nicolas;
>> Mark Brown
>> Subject: Re: [BUG] spi/spi-atmel: DMA rx buffer corruption with
>> SPI_IOC_MESSAGE
>>
>> 2013/10/8 Richard Genoud <richard.genoud@xxxxxxxxx>:
>> > Hi all,
>> >
>> > I finally found the bug I saw months ago, before "[PATCH v8 3/8]
>> > spi/spi-atmel: add dmaengine support" was merged.
>> >
>> > Here it is:
>> >
>> > When the ioctl SPI_IOC_MESSAGE is used with small and big buffers,
>> > the big RX buffer is corrupted with bytes from the big TX buffer.
>> > (Small means size < DMA_MIN_BYTES, Big means size >
>> DMA_MIN_BYTES)
>> >
>> > I'm attaching the test software that I used ( ./spi_test /dev/spidevx.x )
>> >
>> > It fills 3 TX buffers with 0xAA pattern: a small, a big and a small again.
>> > It reads in return 3 RX buffers.
>> > The MISO pin has to be on 3.3v.
>> >
>> > It checks if the received buffers are filled with 0xFF (they should
>> > be, as MISO is high).
>> > And I've got a lot of buffers filled partially with 0xAA bytes.
>> >
>> > BUT, if you apply this patch:
>> > ---8<----
>> > diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
>> > index 83cf609..cde42a4 100644
>> > --- a/drivers/spi/spi-atmel.c
>> > +++ b/drivers/spi/spi-atmel.c
>> > @@ -187,7 +187,7 @@
>> >  /* use PIO for small transfers, avoiding DMA setup/teardown overhead
>> and
>> >   * cache operations; better heuristics consider wordsize and bitrate.
>> >   */
>> > -#define DMA_MIN_BYTES  16
>> > +#define DMA_MIN_BYTES  0
>> >
>> >  struct atmel_spi_dma {
>> >         struct dma_chan                 *chan_rx;
>> > ---8<----
>> > There's no error any more.
>> > So there's something wrong happening when switching from/to pio
>> > transfer to/from DMA.
>> >
>> > We didn't saw that at the time of the merge because we did the test
>> > with a loop on MISO/MOSI,
>> > so the RX buffer was corrupted with identical bytes.
>> >
>> > Best regards,
>> > Richard.
>>
>> Hi Wenyou,
>>
>> Did you have the opportunity to give it a test ?
>>
>> Thread: https://lkml.org/lkml/2013/10/8/329
> I tried to reproduce it with this thread, but I didn't
> Which slave device did you use?

Hi Wenyou,

I'm not using any slave device, I'm just setting the MISO pin to 3.3V,
then I execute the C code ( https://lkml.org/lkml/2013/10/8/329 )
So, we should only receive 0xFF in the buffer.
But i'm getting :
aa aa aa aa aa aa aa aa aa aa aa aa aa aa ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/