From: Wolfram Sang <wsa@kernel.org>
To: Tobias Schramm <t.schramm@manjaro.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH] i2c: rk3x: disable and reenable I2C after timeouts to fix stuck low SDA
Date: Mon, 29 Nov 2021 11:44:48 +0100 [thread overview]
Message-ID: <YaSvIDfF5YVArOa+@kunai> (raw)
In-Reply-To: <20210826174632.91887-1-t.schramm@manjaro.org>
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
On Thu, Aug 26, 2021 at 07:46:32PM +0200, Tobias Schramm wrote:
> Previously the SDA line sometimes remained stuck low after timeouts
> rendering the I2C bus unusable. Testing has shown that disabling and
> reenabling the I2C peripheral after sending the stop condition seems to
> unstick SDA reliably.
> Disable and reenable the I2C controller on timeout after sending stop
> condition to unstick SDA.
Does it also help to not send STOP? This looks a bit like a hack which
went into the driver somehow. The proper solution might be to remove the
STOP and add proper i2c_bus_recovery at the beginning of a transfer.
>
> Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 819ab4ee517e..fc330cc3686a 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1108,6 +1108,16 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
> val |= REG_CON_EN | REG_CON_STOP;
> i2c_writel(i2c, val, REG_CON);
>
> + /*
> + * Sometimes SDA remains stuck low after timeouts.
> + * Disable and reenable the I2C peripheral to unstick
> + * SDA.
> + */
> + val &= ~REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> + val |= REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> +
> i2c->state = STATE_IDLE;
>
> ret = -ETIMEDOUT;
> --
> 2.31.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@kernel.org>
To: Tobias Schramm <t.schramm@manjaro.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH] i2c: rk3x: disable and reenable I2C after timeouts to fix stuck low SDA
Date: Mon, 29 Nov 2021 11:44:48 +0100 [thread overview]
Message-ID: <YaSvIDfF5YVArOa+@kunai> (raw)
In-Reply-To: <20210826174632.91887-1-t.schramm@manjaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]
On Thu, Aug 26, 2021 at 07:46:32PM +0200, Tobias Schramm wrote:
> Previously the SDA line sometimes remained stuck low after timeouts
> rendering the I2C bus unusable. Testing has shown that disabling and
> reenabling the I2C peripheral after sending the stop condition seems to
> unstick SDA reliably.
> Disable and reenable the I2C controller on timeout after sending stop
> condition to unstick SDA.
Does it also help to not send STOP? This looks a bit like a hack which
went into the driver somehow. The proper solution might be to remove the
STOP and add proper i2c_bus_recovery at the beginning of a transfer.
>
> Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 819ab4ee517e..fc330cc3686a 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1108,6 +1108,16 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
> val |= REG_CON_EN | REG_CON_STOP;
> i2c_writel(i2c, val, REG_CON);
>
> + /*
> + * Sometimes SDA remains stuck low after timeouts.
> + * Disable and reenable the I2C peripheral to unstick
> + * SDA.
> + */
> + val &= ~REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> + val |= REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> +
> i2c->state = STATE_IDLE;
>
> ret = -ETIMEDOUT;
> --
> 2.31.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@kernel.org>
To: Tobias Schramm <t.schramm@manjaro.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH] i2c: rk3x: disable and reenable I2C after timeouts to fix stuck low SDA
Date: Mon, 29 Nov 2021 11:44:48 +0100 [thread overview]
Message-ID: <YaSvIDfF5YVArOa+@kunai> (raw)
In-Reply-To: <20210826174632.91887-1-t.schramm@manjaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]
On Thu, Aug 26, 2021 at 07:46:32PM +0200, Tobias Schramm wrote:
> Previously the SDA line sometimes remained stuck low after timeouts
> rendering the I2C bus unusable. Testing has shown that disabling and
> reenabling the I2C peripheral after sending the stop condition seems to
> unstick SDA reliably.
> Disable and reenable the I2C controller on timeout after sending stop
> condition to unstick SDA.
Does it also help to not send STOP? This looks a bit like a hack which
went into the driver somehow. The proper solution might be to remove the
STOP and add proper i2c_bus_recovery at the beginning of a transfer.
>
> Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 819ab4ee517e..fc330cc3686a 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1108,6 +1108,16 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
> val |= REG_CON_EN | REG_CON_STOP;
> i2c_writel(i2c, val, REG_CON);
>
> + /*
> + * Sometimes SDA remains stuck low after timeouts.
> + * Disable and reenable the I2C peripheral to unstick
> + * SDA.
> + */
> + val &= ~REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> + val |= REG_CON_EN;
> + i2c_writel(i2c, val, REG_CON);
> +
> i2c->state = STATE_IDLE;
>
> ret = -ETIMEDOUT;
> --
> 2.31.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-29 11:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 17:46 [PATCH] i2c: rk3x: disable and reenable I2C after timeouts to fix stuck low SDA Tobias Schramm
2021-08-26 17:46 ` Tobias Schramm
2021-08-26 17:46 ` Tobias Schramm
2021-11-18 18:35 ` John Keeping
2021-11-18 18:35 ` John Keeping
2021-11-18 18:35 ` John Keeping
2021-11-29 10:44 ` Wolfram Sang [this message]
2021-11-29 10:44 ` Wolfram Sang
2021-11-29 10:44 ` Wolfram Sang
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=YaSvIDfF5YVArOa+@kunai \
--to=wsa@kernel.org \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=t.schramm@manjaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.