kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Primoz Beltram <primoz.beltram@gmail.com>
To: kernelnewbies@kernelnewbies.org
Subject: I2C bus driver TIMEDOUT because of PM autosuspend
Date: Thu, 21 Nov 2019 17:59:55 +0100	[thread overview]
Message-ID: <83466c12-9329-dbee-1751-6f7717210f4f@gmail.com> (raw)

I am analysing a problem with I2C bus driver where the problem shows up 
as I2C bus completely blocked. The LX driver in question is 
/drivers/i2c/busses/i2c-xiic.c.
Problem is difficult to reproduce, it happens very rarely. So far I saw 
that the main precondition is to have very heavy I2C traffic on bus.
In my case this is achieved/reproduced via netdev driving SFP LEDs via 
/sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. 
Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0.
What I saw from debugging this problem is that I2C bus get blocked when 
wait_event_timeout() completes because of timeout. The timeout handling 
in this driver is probably not robust enough (bus should not remain 
blocked), but at this moment this are just my speculations (don't know 
enough details).

Looking the driver code and data on oscilloscope, I saw that SCL in 
single I2C data transfer sequence can be interrupted for very long 
delays, e.g up to hundredths of usec (SCL is 100kHz). I started to 
suspect that PM autosuspend delay could play some role here. There are 
only two delays in driver code, first in wait_event_timeout and second 
in set autosuspend delay. Case is a bit strange because in very busy I2C 
traffic, PM autosuspend should not be triggered at all. Additionally, if 
I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem 
sooner (waits for problem hit are in order of n*10minutes).

It looks to me that PM autosupend is playing some role here.

Power management options in my .config:
# CONFIG_SUSPEND is not set
# CONFIG_PM is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y

I intentionally did not put all detail descriptions of embedded system 
and test setup here (long list), because the main reason of this post is:

The workaround that works for me/customer (at the moment) is to disable 
PM autosuspend in the driver code, either by incerementing PM delay from 
1000 to 10000 or by disabling autosuspend (comment out call to 
pm_runtime_put_autosuspend() in xiic_xfer()).

But, I would like to expose/discuss this issue (maintainer of the code, 
or others).
The reason/source of the problem can be much more complex and in some 
other place.

So my question is who should I contact, is this the M: in the 
MAINTAINERS list, the MODULE_AUTHOR, ...?
How to proceed.

WBR Primoz


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

             reply	other threads:[~2019-11-29 20:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21 16:59 Primoz Beltram [this message]
2019-12-03  1:30 ` I2C bus driver TIMEDOUT because of PM autosuspend anish singh
2019-12-03  9:26   ` Primoz Beltram
2019-11-27 14:49 Primoz Beltram

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=83466c12-9329-dbee-1751-6f7717210f4f@gmail.com \
    --to=primoz.beltram@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    /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;
as well as URLs for NNTP newsgroup(s).