> > All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig
> Just one thing though, one of my cron behavior change with 3.17, when I use the cmd "/sbin/hwclock --adjust -f /dev/rtc1" I get this new error I never had before:
> "hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
>
> where rtc1 if the i2c rtc connected to the i2C bus, can this be related to the i2c patch that would slow down i2c operation or somthing ?
Hi Benoit
It won't fix your problem, but if the built in RTC is not usable, it
would be good to disable it in the .dts file. The i2c RTC will then
become RTC0.
The actual "error" message is odd:
"hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
Success means it actually worked, not an error. Does the RTC contain
the correct time afterwards?
Andrew
Le 15 oct. 2014 ? 16:41, Andrew Lunn <[email protected]> a ?crit :
>>> All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig
>> Just one thing though, one of my cron behavior change with 3.17, when I use the cmd "/sbin/hwclock --adjust -f /dev/rtc1" I get this new error I never had before:
>> "hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
>>
>> where rtc1 if the i2c rtc connected to the i2C bus, can this be related to the i2c patch that would slow down i2c operation or somthing ?
>
> Hi Benoit
>
> It won't fix your problem, but if the built in RTC is not usable, it
> would be good to disable it in the .dts file. The i2c RTC will then
> become RTC0.
>
>
> The actual "error" message is odd:
> "hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
>
Yes this is the wired thing is that everything works, even getting the date via "cat /sys/class/i2c-adapter/i2c-0/0-0051/rtc/rtc1/time" is ok
reading the rtc driver code it seems this message is shown when multiple resources try to access shared rtc... but why now and not before ?
So I was wondering if the i2c_quirk() applied by the batch has any effect with this ?
Anyhow I'll handle the message for now and see if there are performance impact on this...
Benoit
> Success means it actually worked, not an error. Does the RTC contain
> the correct time afterwards?
>
> Andrew