PCA9564: "bus is not idle" issue

PCA9564: "bus is not idle" issue

[Yegor Yefremov]

Hi,

I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
2.6.33/34 running on my system I noticed sporadic problems with RTC:

rtc-ds1307 0-0068: read error -11
RTC_RD_TIME: Input/output error
ioctl() to /dev/rtc to read the time failed.

After turning debug messages in i2c subsystem I got following info:

i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
i2c i2c-0: bus is not idle. status is 0x28 (sometimes it is 0x50 or 0x58)

This is the way I configure RTC and I2C:

/*****************************************************************************
 * RTC DS1337 on I2C bus
 ****************************************************************************/
static struct i2c_board_info __initdata vsopenrisc_i2c_rtc = {
		I2C_BOARD_INFO("ds1337", 0x68),
};
static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
	    .gpio = -1,
	    .i2c_clock_speed = 59000,
	    .timeout = 1,
};

static struct resource pca_resources[] = {
	[0] = {
		 .start	= VSOPENRISC_PA_I2C_BASE,
		 .end	= VSOPENRISC_PA_I2C_BASE + 0x400 - 1,
		 .flags	= IORESOURCE_MEM | IORESOURCE_MEM_32BIT,
   	},
	[1] = {
		.start	= 0,
		.end	= 0,
		.flags	= IORESOURCE_IRQ,
	},
};

static struct platform_device vsopenrisc_pca_device = {
	.name		= "i2c-pca-platform",
	.id		= -1,
	.dev		= {
			    .platform_data	= &pca_data,
			},
	.resource	= pca_resources,
	.num_resources	= ARRAY_SIZE(pca_resources),
};

With the older kernel 2.6.26 I have never encountered such problems
before. Diffing i2c-algo-pca.c between 2.6.26 and 2.6.33 showed that
there were some minor changes regarding waiting policy in pca_xfer().
Could this be the reason for such behavior? Any idea?

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Wed, Mar 17, 2010 at 01:59:03PM +0100, Yegor Yefremov wrote:

> Could this be the reason for such behavior? Any idea?

Can you set the algo-module parameter i2c_debug to 3 and post the log for the
transfer that failed, please?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

>> Could this be the reason for such behavior? Any idea?
>
> Can you set the algo-module parameter i2c_debug to 3 and post the log for the
> transfer that failed, please?

I've increased i2c_debug to 3 and now I get a lot of debug messages,
but the error doesn't occur. These debug messages seem to influence
the timing.

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

>>> Could this be the reason for such behavior? Any idea?
>>
>> Can you set the algo-module parameter i2c_debug to 3 and post the log for the
>> transfer that failed, please?
>
> I've increased i2c_debug to 3 and now I get a lot of debug messages,
> but the error doesn't occur. These debug messages seem to influence
> the timing.

If I don't redirect syslog to a remote host I get i2c fail. So here you are:

=== START
STATE is 0x08
=== SLAVE ADDRESS 0x68+W=0xd0
STATE is 0x18
=== WRITE 0x00
STATE is 0x28
=== REPEATED START
STATE is 0x10
=== SLAVE ADDRESS 0x68+R=0xd1
STATE is 0x40
STATE is 0x50
=== READ 0x27 ACK
STATE is 0x50
=== READ 0x55 ACK
STATE is 0x50
=== READ 0x08 ACK
STATE is 0x50
=== READ 0x05 ACK
STATE is 0x50
=== READ 0x18 ACK
STATE is 0x50
=== READ 0x83 ACK
STATE is 0x58
=== READ 0x10 NACK
=== STOP
}}} transfered 2/2 messages. status is 0x58. control is 0x55
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
{{{ XFER 2 messages
    [00] WR 1 bytes to 0x68 [0xd0, 0x00]
    [01] RD 7 bytes from 0x68 [0xd1, ...]
STATE is 0xf8
=== START
STATE is 0x08
=== SLAVE ADDRESS 0x68+W=0xd0
STATE is 0x18
=== WRITE 0x00
STATE is 0x28
=== REPEATED START
STATE is 0x10
=== SLAVE ADDRESS 0x68+R=0xd1
STATE is 0x40
STATE is 0x50
=== READ 0x27 ACK
STATE is 0x50
=== READ 0x55 ACK
STATE is 0x50
=== READ 0x08 ACK
STATE is 0x50
=== READ 0x05 ACK
STATE is 0x50
=== READ 0x18 ACK
STATE is 0x50
=== READ 0x83 ACK
STATE is 0x58
=== READ 0x10 NACK
=== STOP
}}} transfered 2/2 messages. status is 0x58. control is 0x55
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
{{{ XFER 2 messages
    [00] WR 1 bytes to 0x68 [0xd0, 0x00]
    [01] RD 7 bytes from 0x68 [0xd1, ...]
STATE is 0xf8
=== START
STATE is 0x08
=== SLAVE ADDRESS 0x68+W=0xd0
STATE is 0x18
=== WRITE 0x00
STATE is 0x28
=== REPEATED START
STATE is 0x10
=== SLAVE ADDRESS 0x68+R=0xd1
STATE is 0x40
STATE is 0x50
=== READ 0x27 ACK
STATE is 0x50
=== READ 0x55 ACK
STATE is 0x50
=== READ 0x08 ACK
STATE is 0x50
=== READ 0x05 ACK
STATE is 0x50
=== READ 0x18 ACK
STATE is 0x50
=== READ 0x83 ACK
STATE is 0x58
=== READ 0x10 NACK
=== STOP
}}} transfered 2/2 messages. status is 0x58. control is 0x55
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
{{{ XFER 2 messages
    [00] WR 1 bytes to 0x68 [0xd0, 0x00]
    [01] RD 7 bytes from 0x68 [0xd1, ...]
STATE is 0xf8
=== START
STATE is 0x08
=== SLAVE ADDRESS 0x68+W=0xd0
STATE is 0x18
=== WRITE 0x00
STATE is 0x28
=== REPEATED START
STATE is 0x10
=== SLAVE ADDRESS 0x68+R=0xd1
STATE is 0x40
STATE is 0x50
=== READ 0x27 ACK
STATE is 0x50
=== READ 0x55 ACK
STATE is 0x50
=== READ 0x08 ACK
STATE is 0x50
=== READ 0x05 ACK
}}} transfered 1/2 messages. status is 0x50. control is 0xcd
rtc-ds1307 0-0068: read error -121
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
i2c i2c-0: bus is not idle. status is 0x50
rtc-ds1307 0-0068: read error -11
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
i2c i2c-0: bus is not idle. status is 0x50

As far as I can tell the last transaction lacks "=== STOP" state.

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

> If I don't redirect syslog to a remote host I get i2c fail. So here you are:

Thanks!

[...]

> As far as I can tell the last transaction lacks "=== STOP" state.

Yes. The bus-status being 0x58 instead of 0xf8 says that, too. I wanted to
check if there is something flaky before. Will have a look, but will probably
be the weekend. You said it does not appear when you use 2.6.26, right?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

On Thu, Mar 18, 2010 at 10:19 AM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> If I don't redirect syslog to a remote host I get i2c fail. So here you are:
>
> Thanks!
>
> [...]
>
>> As far as I can tell the last transaction lacks "=== STOP" state.
>
> Yes. The bus-status being 0x58 instead of 0xf8 says that, too. I wanted to
> check if there is something flaky before. Will have a look, but will probably
> be the weekend. You said it does not appear when you use 2.6.26, right?

Right. Either it is so seldom, that I don't notice it or it doesn't
occur. But with 2.6.33 it is really frequent.

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Jean Delvare]

Wolram, Yegor,

On Thu, 18 Mar 2010 10:51:09 +0100, Yegor Yefremov wrote:
> On Thu, Mar 18, 2010 at 10:19 AM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> >> If I don't redirect syslog to a remote host I get i2c fail. So here you are:
> >
> > Thanks!
> >
> > [...]
> >
> >> As far as I can tell the last transaction lacks "=== STOP" state.
> >
> > Yes. The bus-status being 0x58 instead of 0xf8 says that, too. I wanted to
> > check if there is something flaky before. Will have a look, but will probably
> > be the weekend. You said it does not appear when you use 2.6.26, right?
> 
> Right. Either it is so seldom, that I don't notice it or it doesn't
> occur. But with 2.6.33 it is really frequent.

Any progress on this? If this is a regression, we want to fix it
quickly.

Thanks,
-- 
Jean Delvare

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

>> >> If I don't redirect syslog to a remote host I get i2c fail. So here you are:
>> >
>> > Thanks!
>> >
>> > [...]
>> >
>> >> As far as I can tell the last transaction lacks "=== STOP" state.
>> >
>> > Yes. The bus-status being 0x58 instead of 0xf8 says that, too. I wanted to
>> > check if there is something flaky before. Will have a look, but will probably
>> > be the weekend. You said it does not appear when you use 2.6.26, right?
>>
>> Right. Either it is so seldom, that I don't notice it or it doesn't
>> occur. But with 2.6.33 it is really frequent.
>
> Any progress on this? If this is a regression, we want to fix it
> quickly.

I'm not really further. But I use a workaround for my system by just
using this revision:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=commit;h=eff9ec95efaaf6b12d230f0ea7d3c295d3bc9d57.
With revision i2c is working quite stable.

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Wed, Mar 17, 2010 at 01:59:03PM +0100, Yegor Yefremov wrote:
> Hi,
> 
> I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
> 2.6.33/34 running on my system I noticed sporadic problems with RTC:

[...]

> static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
> 	    .gpio = -1,
> 	    .i2c_clock_speed = 59000,
> 	    .timeout = 1,
> };

Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.

> before. Diffing i2c-algo-pca.c between 2.6.26 and 2.6.33 showed that
> there were some minor changes regarding waiting policy in pca_xfer().
> Could this be the reason for such behavior? Any idea?

You were almost there, just use 'git log' next time.

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PCA9564: "bus is not idle" issue

[Jean Delvare]

On Sat, 3 Apr 2010 18:29:39 +0200, Wolfram Sang wrote:
> On Wed, Mar 17, 2010 at 01:59:03PM +0100, Yegor Yefremov wrote:
> > Hi,
> > 
> > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
> > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
> 
> [...]
> 
> > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
> > 	    .gpio = -1,
> > 	    .i2c_clock_speed = 59000,
> > 	    .timeout = 1,
> > };
> 
> Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
> jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
> 
> > before. Diffing i2c-algo-pca.c between 2.6.26 and 2.6.33 showed that
> > there were some minor changes regarding waiting policy in pca_xfer().
> > Could this be the reason for such behavior? Any idea?
> 
> You were almost there, just use 'git log' next time.

So this means the bug isn't in the mainline kernel tree and I can
ignore it?

As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
to 10000, so the actual timeout depends on the value of HZ, which is
probably not desirable. Not to mention that a timeout of over one
minute (worst case) doesn't seem too smart ;)

-- 
Jean Delvare

Re: PCA9564: "bus is not idle" issue

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

> > > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
> > > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
> > 
> > [...]
> > 
> > > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
> > > 	    .gpio = -1,
> > > 	    .i2c_clock_speed = 59000,
> > > 	    .timeout = 1,
> > > };
> > 
> > Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
> > jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
> 
> So this means the bug isn't in the mainline kernel tree and I can
> ignore it?

A confirmation from Yegor would be nice, but his logs let me believe that
this is really the cause.

> As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
> to 10000, so the actual timeout depends on the value of HZ, which is
> probably not desirable. Not to mention that a timeout of over one
> minute (worst case) doesn't seem too smart ;)

There is also an i2c-gpio-user using non-HZ value. Will prepare patches.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

On Sun, Apr 4, 2010 at 5:29 AM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> > > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
>> > > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
>> >
>> > [...]
>> >
>> > > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
>> > >       .gpio = -1,
>> > >       .i2c_clock_speed = 59000,
>> > >       .timeout = 1,
>> > > };
>> >
>> > Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
>> > jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
>>
>> So this means the bug isn't in the mainline kernel tree and I can
>> ignore it?
>
> A confirmation from Yegor would be nice, but his logs let me believe that
> this is really the cause.
>
>> As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
>> to 10000, so the actual timeout depends on the value of HZ, which is
>> probably not desirable. Not to mention that a timeout of over one
>> minute (worst case) doesn't seem too smart ;)
>
> There is also an i2c-gpio-user using non-HZ value. Will prepare patches.

Thank for your solution. I'll try it on Tuesday and confirm ASAP.

Happy Easter!

Best regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

>>> > > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
>>> > > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
>>> >
>>> > [...]
>>> >
>>> > > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
>>> > >       .gpio = -1,
>>> > >       .i2c_clock_speed = 59000,
>>> > >       .timeout = 1,
>>> > > };
>>> >
>>> > Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
>>> > jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
>>>
>>> So this means the bug isn't in the mainline kernel tree and I can
>>> ignore it?
>>
>> A confirmation from Yegor would be nice, but his logs let me believe that
>> this is really the cause.
>>
>>> As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
>>> to 10000, so the actual timeout depends on the value of HZ, which is
>>> probably not desirable. Not to mention that a timeout of over one
>>> minute (worst case) doesn't seem too smart ;)
>>
>> There is also an i2c-gpio-user using non-HZ value. Will prepare patches.
>
> Thank for your solution. I'll try it on Tuesday and confirm ASAP.

Wolfram, do you mean so:

static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
           .gpio = -1,
           .i2c_clock_speed = 59000,
           .timeout = HZ,
};

I've tried this, but with the same result. The bus is still not idle.

Regards,
Yegor

Re: PCA9564: "bus is not idle" issue

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

On Tue, Apr 06, 2010 at 09:48:49AM +0200, Yegor Yefremov wrote:
> >>> > > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
> >>> > > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
> >>> >
> >>> > [...]
> >>> >
> >>> > > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
> >>> > >       .gpio = -1,
> >>> > >       .i2c_clock_speed = 59000,
> >>> > >       .timeout = 1,
> >>> > > };
> >>> >
> >>> > Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
> >>> > jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
> >>>
> >>> So this means the bug isn't in the mainline kernel tree and I can
> >>> ignore it?
> >>
> >> A confirmation from Yegor would be nice, but his logs let me believe that
> >> this is really the cause.
> >>
> >>> As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
> >>> to 10000, so the actual timeout depends on the value of HZ, which is
> >>> probably not desirable. Not to mention that a timeout of over one
> >>> minute (worst case) doesn't seem too smart ;)
> >>
> >> There is also an i2c-gpio-user using non-HZ value. Will prepare patches.
> >
> > Thank for your solution. I'll try it on Tuesday and confirm ASAP.
> 
> Wolfram, do you mean so:
> 
> static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
>            .gpio = -1,
>            .i2c_clock_speed = 59000,
>            .timeout = HZ,
> };
> 
> I've tried this, but with the same result. The bus is still not idle.

That's bad news :(( Did you notice a difference in behaviour? There should be a
1 second delay now before the message arises...

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PCA9564: "bus is not idle" issue

[Yegor Yefremov]

>> >>> > > I'm using PCA9564 attached to a ks8695 SoC. During my efforts to get
>> >>> > > 2.6.33/34 running on my system I noticed sporadic problems with RTC:
>> >>> >
>> >>> > [...]
>> >>> >
>> >>> > > static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
>> >>> > >       .gpio = -1,
>> >>> > >       .i2c_clock_speed = 59000,
>> >>> > >       .timeout = 1,
>> >>> > > };
>> >>> >
>> >>> > Commit 8e99ada8deaa9033600cd2c7d0a9366b0e99ab68 changed the timeout settings to
>> >>> > jiffies. So, one jiffy as timeout will not work. Try 'HZ' here.
>> >>>
>> >>> So this means the bug isn't in the mainline kernel tree and I can
>> >>> ignore it?
>> >>
>> >> A confirmation from Yegor would be nice, but his logs let me believe that
>> >> this is really the cause.
>> >>
>> >>> As a side note, arch/blackfin/mach-bf561/boards/acvilon.c sets timeout
>> >>> to 10000, so the actual timeout depends on the value of HZ, which is
>> >>> probably not desirable. Not to mention that a timeout of over one
>> >>> minute (worst case) doesn't seem too smart ;)
>> >>
>> >> There is also an i2c-gpio-user using non-HZ value. Will prepare patches.
>> >
>> > Thank for your solution. I'll try it on Tuesday and confirm ASAP.
>>
>> Wolfram, do you mean so:
>>
>> static struct i2c_pca9564_pf_platform_data  __initdata pca_data ={
>>            .gpio = -1,
>>            .i2c_clock_speed = 59000,
>>            .timeout = HZ,
>> };
>>
>> I've tried this, but with the same result. The bus is still not idle.
>
> That's bad news :(( Did you notice a difference in behaviour? There should be a
> 1 second delay now before the message arises...

Yes, I can confirm this delay. But apart from these delay I can't see
any difference in behavior.

Regards,
Yegor