All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Codrin.Ciubotariu@microchip.com>
To: <peda@axentia.se>, <linux-i2c@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>
Cc: <Ludovic.Desroches@microchip.com>, <Nicolas.Ferre@microchip.com>,
	<alexandre.belloni@bootlin.com>, <robh+dt@kernel.org>,
	<wsa@kernel.org>, <kamel.bouhara@bootlin.com>
Subject: Re: Regression: at24 eeprom writing times out on sama5d3
Date: Fri, 10 Jun 2022 07:35:00 +0000	[thread overview]
Message-ID: <2bb4868b-90ab-887e-bf13-9de8b79231bd@microchip.com> (raw)
In-Reply-To: <074b39c5-55fc-2bc1-072d-aef1070e284d@axentia.se>

On 09.06.2022 17:28, Peter Rosin wrote:
> Hi!

Hi Peter,

> 
> I have not actually bisected this issue but reverting the effects of
> patch a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
> makes the problem go away.
> 
> I.e. I need something like this in my dts
> 
> &i2c2 {
>          status = "okay";
> 
>          pinctrl-names = "default";
>          /delete-property/ pinctrl-1;
>          /delete-property/ sda-gpios;
>          /delete-property/ scl-gpios;
> 
>          eeprom@50 {
>                  compatible = "st,24c64", "atmel,24c64";
>                  reg = <0x50>;
>                  wp-gpios = <&filter_gpio 7 GPIO_ACTIVE_HIGH>;
>          };
> };
> 
> for multi-page eeprom writes to not time out (a page is 32 bytes on this
> eeprom).
> 
> For reference, the current defaults for this SoC/I2C-bus, that I modify,
> are:
> 
>          pinctrl-names = "default", "gpio";
>          pinctrl-0 = <&pinctrl_i2c2>;
>          pinctrl-1 = <&pinctrl_i2c2_gpio>;
>          sda-gpios = <&pioA 18 GPIO_ACTIVE_HIGH>;
>          scl-gpios = <&pioA 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> 
> I suspect that the underlying reason is that the bus recovery takes
> too long and that the at24 eeprom driver gives up prematurely. I doubt
> that this is chip specific, but I don't know that.
> 
> I can work around the issue in user space with by writing in 4 byte
> chunks, like so
> 
> dd if=source.file of=/sys/bus/i2c/devices/2-0050/eeprom obs=4
> 
> but that is really ugly and gets slow too, about 20 seconds to program
> the full 8kB eeprom. With the above in my dts it takes a second or
> so (a bit more with dynamic debug active).
> 
> 
> If I run
> 
> dd if=source.file of=/sys/bus/i2c/devices/2-0050/eeprom
> 
> with a source.file of 8kB and the upstream dts properties in place, I can
> collect the following debug output from at24, i2c-core and i2c-at91:
> 
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@0 --> 0 (-23170)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@32 --> -121 (-23169)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@32 --> 0 (-23168)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@64 --> -121 (-23168)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@64 --> 0 (-23167)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -121 (-23167)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: controller timed out
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -110 (-23155)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: controller timed out
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -110 (-23143)
> 
> And then there is no more action. I.e. only a couple of 32 byte pages
> are written.
> 
> With the above mentioned dts override in place I instead get this, which is
> a lot more sensible:
> 
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@0 --> 0 (753629)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@32 --> -121 (753629)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@32 --> 0 (753630)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@64 --> -121 (753630)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@64 --> 0 (753631)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@96 --> -121 (753631)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@96 --> 0 (753632)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@128 --> -121 (753632)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@128 --> 0 (753633)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@160 --> -121 (753633)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@160 --> 0 (753634)
> ... snip ...
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8128 --> -121 (753883)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8128 --> 0 (753884)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8160 --> -121 (753884)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8160 --> 0 (753885)

could you please apply this patch-set [1] and let us know if it 
addresses your issue?

Thanks and best regards,
Codrin

https://patchwork.ozlabs.org/project/linux-i2c/list/?series=255408

WARNING: multiple messages have this Message-ID (diff)
From: <Codrin.Ciubotariu@microchip.com>
To: <peda@axentia.se>, <linux-i2c@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>
Cc: kamel.bouhara@bootlin.com, alexandre.belloni@bootlin.com,
	wsa@kernel.org, Ludovic.Desroches@microchip.com,
	robh+dt@kernel.org
Subject: Re: Regression: at24 eeprom writing times out on sama5d3
Date: Fri, 10 Jun 2022 07:35:00 +0000	[thread overview]
Message-ID: <2bb4868b-90ab-887e-bf13-9de8b79231bd@microchip.com> (raw)
In-Reply-To: <074b39c5-55fc-2bc1-072d-aef1070e284d@axentia.se>

On 09.06.2022 17:28, Peter Rosin wrote:
> Hi!

Hi Peter,

> 
> I have not actually bisected this issue but reverting the effects of
> patch a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
> makes the problem go away.
> 
> I.e. I need something like this in my dts
> 
> &i2c2 {
>          status = "okay";
> 
>          pinctrl-names = "default";
>          /delete-property/ pinctrl-1;
>          /delete-property/ sda-gpios;
>          /delete-property/ scl-gpios;
> 
>          eeprom@50 {
>                  compatible = "st,24c64", "atmel,24c64";
>                  reg = <0x50>;
>                  wp-gpios = <&filter_gpio 7 GPIO_ACTIVE_HIGH>;
>          };
> };
> 
> for multi-page eeprom writes to not time out (a page is 32 bytes on this
> eeprom).
> 
> For reference, the current defaults for this SoC/I2C-bus, that I modify,
> are:
> 
>          pinctrl-names = "default", "gpio";
>          pinctrl-0 = <&pinctrl_i2c2>;
>          pinctrl-1 = <&pinctrl_i2c2_gpio>;
>          sda-gpios = <&pioA 18 GPIO_ACTIVE_HIGH>;
>          scl-gpios = <&pioA 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> 
> I suspect that the underlying reason is that the bus recovery takes
> too long and that the at24 eeprom driver gives up prematurely. I doubt
> that this is chip specific, but I don't know that.
> 
> I can work around the issue in user space with by writing in 4 byte
> chunks, like so
> 
> dd if=source.file of=/sys/bus/i2c/devices/2-0050/eeprom obs=4
> 
> but that is really ugly and gets slow too, about 20 seconds to program
> the full 8kB eeprom. With the above in my dts it takes a second or
> so (a bit more with dynamic debug active).
> 
> 
> If I run
> 
> dd if=source.file of=/sys/bus/i2c/devices/2-0050/eeprom
> 
> with a source.file of 8kB and the upstream dts properties in place, I can
> collect the following debug output from at24, i2c-core and i2c-at91:
> 
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@0 --> 0 (-23170)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@32 --> -121 (-23169)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@32 --> 0 (-23168)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@64 --> -121 (-23168)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@64 --> 0 (-23167)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -121 (-23167)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: controller timed out
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -110 (-23155)
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:56:34 me20 kernel: at91_i2c f801c000.i2c: controller timed out
> Jun  9 15:56:34 me20 kernel: i2c i2c-2: Trying i2c bus recovery
> Jun  9 15:56:34 me20 kernel: at24 2-0050: write 32@96 --> -110 (-23143)
> 
> And then there is no more action. I.e. only a couple of 32 byte pages
> are written.
> 
> With the above mentioned dts override in place I instead get this, which is
> a lot more sensible:
> 
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@0 --> 0 (753629)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@32 --> -121 (753629)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@32 --> 0 (753630)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@64 --> -121 (753630)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@64 --> 0 (753631)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@96 --> -121 (753631)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@96 --> 0 (753632)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@128 --> -121 (753632)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@128 --> 0 (753633)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@160 --> -121 (753633)
> Jun  9 15:48:53 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:53 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:53 me20 kernel: at24 2-0050: write 32@160 --> 0 (753634)
> ... snip ...
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8128 --> -121 (753883)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8128 --> 0 (753884)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: received nack
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8160 --> -121 (753884)
> Jun  9 15:48:55 me20 kernel: i2c i2c-2: at91_xfer: processing 1 messages:
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer: write 34 bytes.
> Jun  9 15:48:55 me20 kernel: at91_i2c f801c000.i2c: transfer complete
> Jun  9 15:48:55 me20 kernel: at24 2-0050: write 32@8160 --> 0 (753885)

could you please apply this patch-set [1] and let us know if it 
addresses your issue?

Thanks and best regards,
Codrin

https://patchwork.ozlabs.org/project/linux-i2c/list/?series=255408
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-06-10  7:35 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 14:28 Regression: at24 eeprom writing times out on sama5d3 Peter Rosin
2022-06-09 14:28 ` Peter Rosin
2022-06-10  7:35 ` Codrin.Ciubotariu [this message]
2022-06-10  7:35   ` Codrin.Ciubotariu
2022-06-10 20:51   ` Peter Rosin
2022-06-10 20:51     ` Peter Rosin
2022-06-30  7:44     ` Peter Rosin
2022-06-30  7:44       ` Peter Rosin
2022-09-08 12:06       ` Thorsten Leemhuis
2022-09-08 12:06         ` Thorsten Leemhuis
2022-09-08 13:59         ` Peter Rosin
2022-09-08 13:59           ` Peter Rosin
2022-09-26 13:32           ` Regression: at24 eeprom writing times out on sama5d3 #forregzbot Thorsten Leemhuis
2022-09-26 13:32             ` Thorsten Leemhuis
2022-12-15 17:53           ` Regression: at24 eeprom writing times out on sama5d3 Thorsten Leemhuis
2022-12-15 17:53             ` Thorsten Leemhuis
2022-12-15 18:50             ` Conor.Dooley
2022-12-15 18:50               ` Conor.Dooley
2023-03-15 11:07               ` Linux regression tracking (Thorsten Leemhuis)
2023-03-15 11:07                 ` Linux regression tracking (Thorsten Leemhuis)
2022-06-13 14:58   ` Wolfram Sang
2022-06-13 14:58     ` Wolfram Sang
2022-06-13 15:43     ` Peter Rosin
2022-06-13 15:43       ` Peter Rosin
2022-06-13 20:06       ` Wolfram Sang
2022-06-13 20:06         ` Wolfram Sang
2022-06-14  8:25       ` Codrin.Ciubotariu
2022-06-14  8:25         ` Codrin.Ciubotariu
2022-06-14 13:53         ` Codrin.Ciubotariu
2022-06-14 13:53           ` Codrin.Ciubotariu
2022-06-14 14:25           ` Conor.Dooley
2022-06-14 14:25             ` Conor.Dooley
2022-06-15  8:34             ` Codrin.Ciubotariu
2022-06-15  8:34               ` Codrin.Ciubotariu
2022-06-11 13:41 ` Thorsten Leemhuis
2022-06-11 13:41   ` Thorsten Leemhuis

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=2bb4868b-90ab-887e-bf13-9de8b79231bd@microchip.com \
    --to=codrin.ciubotariu@microchip.com \
    --cc=Ludovic.Desroches@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kamel.bouhara@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=robh+dt@kernel.org \
    --cc=wsa@kernel.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.