From: Ludovic Desroches <ludovic.desroches@microchip.com>
To: Peter Rosin <peda@axentia.se>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Ludovic Desroches <ludovic.desroches@microchip.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: Sluggish AT91 I2C driver causes SMBus timeouts
Date: Tue, 17 Oct 2017 09:58:07 +0200 [thread overview]
Message-ID: <20171017075807.tsh5walc3sla3pth@rfolt0960.corp.atmel.com> (raw)
In-Reply-To: <92675fc4-060b-0056-4fe8-3fe3368cb617@axentia.se>
Hi Peter,
On Fri, Oct 13, 2017 at 05:01:04PM +0200, Peter Rosin wrote:
> On 2017-10-13 15:29, Alan Cox wrote:
> > On Thu, 12 Oct 2017 13:35:17 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> Hi!
> >>
> >> I have encountered an "interesting" bug. It silently corrupts data
> >> and is generally nasty...
> >>
> >> On an I2C bus, driven by the at91 driver and DMA (an Atmel
> >> sama5d31 chip), I have an 256 byte eeprom (NXP SE97BTP). I'm using
> >> Linux v4.13.
> >
> > If your force the transfer to PIO does it behave ? Does the controller in
> > fact need to siwtch to PIO for SMBUS ?
>
> Like, what if I disable DMA?
>
> I saw no way to do that, short of short-cutting a few things in the
> driver code. So, did that and I cannot tickle the bug. But I don't
> know if that makes me safe?
>
> Ludovic, any reason to believe disabling DMA will prevent these
> stalls, or will they just appear under different circumstances?
Sorry I am currently on vacation. I outlined this discussion.
As you noticed, there are some hardware constraints when using DMA.
Switching from DMA to PIO to handle the end of the transfer is probably the
root cause of the delay you get.
I read you added traces, did you manage to get some information about
timings? Do we waste time waiting for the dma callback? for the RXRDY
interrupt?
If we spend time waiting for the dma callback for sure, disabling DMA
should prevent these stalls. If the stall is inbetween the two last
RXRDY interrupts, it seems it can appear under different circumstances.
>
> I used this dirty "patch" to i2c-at91.c:at91_twi_configure_dma() for
> testing:
>
> - dev->use_dma = true;
> + //dev->use_dma = true;
>
You can simply remove dma bindings from the i2c node to force the i2c
controller to use the PIO mode.
Regards
Ludovic
> Cheers,
> Peter
next prev parent reply other threads:[~2017-10-17 7:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 11:35 Sluggish AT91 I2C driver causes SMBus timeouts Peter Rosin
2017-10-12 14:32 ` Peter Rosin
2017-10-12 14:42 ` Guenter Roeck
2017-10-12 21:19 ` Peter Rosin
2017-10-13 1:27 ` Guenter Roeck
2017-10-13 13:29 ` Alan Cox
2017-10-13 15:01 ` Peter Rosin
2017-10-17 7:58 ` Ludovic Desroches [this message]
2017-10-25 21:40 ` Peter Rosin
2017-10-31 16:10 ` Ludovic Desroches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171017075807.tsh5walc3sla3pth@rfolt0960.corp.atmel.com \
--to=ludovic.desroches@microchip.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox