[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Eric Anholt]

The register at poweron contains 0x40, which at our typical 100khz bus
rate means .64ms instead of the desired 25ms.

Fixes many clock stretching timeouts when talking to the DSI panel's
bridge chip, and will hopefully fix talking to the FXL6408 GPIO
expander on the Pi3 as well.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/i2c/busses/i2c-bcm2835.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 818b051d25e6..1348f224013d 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -28,6 +28,11 @@
 #define BCM2835_I2C_FIFO	0x10
 #define BCM2835_I2C_DIV		0x14
 #define BCM2835_I2C_DEL		0x18
+/*
+ * 16-bit field for the number of SCL cycles to wait after rising SCL
+ * before deciding the slave is not responding.  0 disables the
+ * timeout detection.
+ */
 #define BCM2835_I2C_CLKT	0x1c
 
 #define BCM2835_I2C_C_READ	BIT(0)
@@ -238,6 +243,7 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
 	u32 bus_clk_rate, divider;
 	int ret;
 	struct i2c_adapter *adap;
+	u32 clkt;
 
 	i2c_dev = devm_kzalloc(&pdev->dev, sizeof(*i2c_dev), GFP_KERNEL);
 	if (!i2c_dev)
@@ -280,6 +286,15 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
 	}
 	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider);
 
+	/*
+	 * SMBUS says "Devices participating in a transfer will
+	 * timeout when any clock low exceeds the value of
+	 * T_TIMEOUT,MIN of 25 ms."
+	 */
+	clkt = DIV_ROUND_UP(25 * bus_clk_rate, 1000);
+	clkt = min(clkt, 0xffffu);
+	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_CLKT, clkt);
+
 	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	if (!irq) {
 		dev_err(&pdev->dev, "No IRQ resource\n");
-- 
2.8.0.rc3

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Stefan Wahren]

Hi Eric,

Am 02.06.2016 um 00:07 schrieb Eric Anholt:
> The register at poweron contains 0x40, which at our typical 100khz bus
> rate means .64ms instead of the desired 25ms.
>
> Fixes many clock stretching timeouts when talking to the DSI panel's
> bridge chip, and will hopefully fix talking to the FXL6408 GPIO
> expander on the Pi3 as well.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  drivers/i2c/busses/i2c-bcm2835.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
> index 818b051d25e6..1348f224013d 100644
> --- a/drivers/i2c/busses/i2c-bcm2835.c
> +++ b/drivers/i2c/busses/i2c-bcm2835.c
> @@ -28,6 +28,11 @@
>  #define BCM2835_I2C_FIFO	0x10
>  #define BCM2835_I2C_DIV		0x14
>  #define BCM2835_I2C_DEL		0x18
> +/*
> + * 16-bit field for the number of SCL cycles to wait after rising SCL
> + * before deciding the slave is not responding.  0 disables the
> + * timeout detection.
> + */
>  #define BCM2835_I2C_CLKT	0x1c
>  
>  #define BCM2835_I2C_C_READ	BIT(0)
> @@ -238,6 +243,7 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
>  	u32 bus_clk_rate, divider;
>  	int ret;
>  	struct i2c_adapter *adap;
> +	u32 clkt;
>  
>  	i2c_dev = devm_kzalloc(&pdev->dev, sizeof(*i2c_dev), GFP_KERNEL);
>  	if (!i2c_dev)
> @@ -280,6 +286,15 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
>  	}
>  	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider);
>  
> +	/*
> +	 * SMBUS says "Devices participating in a transfer will
> +	 * timeout when any clock low exceeds the value of
> +	 * T_TIMEOUT,MIN of 25 ms."
> +	 */
> +	clkt = DIV_ROUND_UP(25 * bus_clk_rate, 1000);
> +	clkt = min(clkt, 0xffffu);
> +	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_CLKT, clkt);
> +

could we really assume that the clk rate never change after driver probing?

This also affects Gerd's patch [PATCH 28/32] i2c: bcm2835: Set up the
rising/falling edge delays.

Stefan

>  	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>  	if (!irq) {
>  		dev_err(&pdev->dev, "No IRQ resource\n");

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Eric Anholt]

Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Eric,
>
> Am 02.06.2016 um 00:07 schrieb Eric Anholt:
>> The register at poweron contains 0x40, which at our typical 100khz bus
>> rate means .64ms instead of the desired 25ms.
>>
>> Fixes many clock stretching timeouts when talking to the DSI panel's
>> bridge chip, and will hopefully fix talking to the FXL6408 GPIO
>> expander on the Pi3 as well.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>  drivers/i2c/busses/i2c-bcm2835.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
>> index 818b051d25e6..1348f224013d 100644
>> --- a/drivers/i2c/busses/i2c-bcm2835.c
>> +++ b/drivers/i2c/busses/i2c-bcm2835.c
>> @@ -28,6 +28,11 @@
>>  #define BCM2835_I2C_FIFO	0x10
>>  #define BCM2835_I2C_DIV		0x14
>>  #define BCM2835_I2C_DEL		0x18
>> +/*
>> + * 16-bit field for the number of SCL cycles to wait after rising SCL
>> + * before deciding the slave is not responding.  0 disables the
>> + * timeout detection.
>> + */
>>  #define BCM2835_I2C_CLKT	0x1c
>>  
>>  #define BCM2835_I2C_C_READ	BIT(0)
>> @@ -238,6 +243,7 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
>>  	u32 bus_clk_rate, divider;
>>  	int ret;
>>  	struct i2c_adapter *adap;
>> +	u32 clkt;
>>  
>>  	i2c_dev = devm_kzalloc(&pdev->dev, sizeof(*i2c_dev), GFP_KERNEL);
>>  	if (!i2c_dev)
>> @@ -280,6 +286,15 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
>>  	}
>>  	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider);
>>  
>> +	/*
>> +	 * SMBUS says "Devices participating in a transfer will
>> +	 * timeout when any clock low exceeds the value of
>> +	 * T_TIMEOUT,MIN of 25 ms."
>> +	 */
>> +	clkt = DIV_ROUND_UP(25 * bus_clk_rate, 1000);
>> +	clkt = min(clkt, 0xffffu);
>> +	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_CLKT, clkt);
>> +
>
> could we really assume that the clk rate never change after driver probing?
>
> This also affects Gerd's patch [PATCH 28/32] i2c: bcm2835: Set up the
> rising/falling edge delays.

The I2C_DIV register setup you see in this hunk is what is producing the
SCL clock, so this code is in the right place.  If we need to add
switching of bus rates at runtime then we'd have to move all of it,
which would be a separate change.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160602/9907ea19/attachment.sig>

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Wolfram Sang]

> +	/*
> +	 * SMBUS says "Devices participating in a transfer will
> +	 * timeout when any clock low exceeds the value of
> +	 * T_TIMEOUT,MIN of 25 ms."
> +	 */

SMBus has that timeout, but I2C doesn't. How about disabling the timeout
simply? Or using the max value if you want to keep the timeout
detection?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160704/92d7d6c0/attachment.sig>

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Eric Anholt]

Wolfram Sang <wsa@the-dreams.de> writes:

>> +	/*
>> +	 * SMBUS says "Devices participating in a transfer will
>> +	 * timeout when any clock low exceeds the value of
>> +	 * T_TIMEOUT,MIN of 25 ms."
>> +	 */
>
> SMBus has that timeout, but I2C doesn't. How about disabling the timeout
> simply? Or using the max value if you want to keep the timeout
> detection?

Disabling the timeout seems fine to me.  We still have a 1-second
timeout around the entire transfer.  I'll be back on my DSI branch this
week and test it out then.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160703/83f4c082/attachment.sig>

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Wolfram Sang]

On Sun, Jul 03, 2016 at 06:02:32PM -0700, Eric Anholt wrote:
> Wolfram Sang <wsa@the-dreams.de> writes:
> 
> >> +	/*
> >> +	 * SMBUS says "Devices participating in a transfer will
> >> +	 * timeout when any clock low exceeds the value of
> >> +	 * T_TIMEOUT,MIN of 25 ms."
> >> +	 */
> >
> > SMBus has that timeout, but I2C doesn't. How about disabling the timeout
> > simply? Or using the max value if you want to keep the timeout
> > detection?
> 
> Disabling the timeout seems fine to me.  We still have a 1-second
> timeout around the entire transfer.  I'll be back on my DSI branch this
> week and test it out then.

Did it work?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160722/f1cb495b/attachment.sig>

[PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

[Eric Anholt]

Wolfram Sang <wsa@the-dreams.de> writes:

> On Sun, Jul 03, 2016 at 06:02:32PM -0700, Eric Anholt wrote:
>> Wolfram Sang <wsa@the-dreams.de> writes:
>> 
>> >> +	/*
>> >> +	 * SMBUS says "Devices participating in a transfer will
>> >> +	 * timeout when any clock low exceeds the value of
>> >> +	 * T_TIMEOUT,MIN of 25 ms."
>> >> +	 */
>> >
>> > SMBus has that timeout, but I2C doesn't. How about disabling the timeout
>> > simply? Or using the max value if you want to keep the timeout
>> > detection?
>> 
>> Disabling the timeout seems fine to me.  We still have a 1-second
>> timeout around the entire transfer.  I'll be back on my DSI branch this
>> week and test it out then.
>
> Did it work?

Sorry for the long-delayed feedback: It turned out that the reason I was
getting timeouts and looking into i2c in the first place was that the
firmware was driving that controller behind my back, so I couldn't do
useful testing anyway.

I put together a patch
(https://github.com/anholt/linux/commit/894200276239d2e4c60b378bdc52164fcb13af8d)
but I'm a bit concerned by it: I don't see a way to get the controller
back to its idle state without continuing through the I2C state machine,
and if the clock is still being stretched it doesn't continue unless CLK
is triggered.

What is supposed to happen when adap->timeout times out while the clock
is being stretched?  Should we be able to try starting a fresh new I2C
transaction cleanly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161003/880af017/attachment.sig>