>> >>> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
