| Message ID | CE7A9795-C2AF-451A-8018-3A0B8788BF60@perenite.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> > 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
On Wed, Oct 15, 2014 at 02:53:02AM +0200, Benoit Masson wrote: > > Le 6 oct. 2014 à 18:13, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > > > On 10/06/2014 01:11 AM, Benoit Masson wrote: > >> Le 3 oct. 2014 à 17:41, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>> On 10/03/2014 05:29 PM, Benoit Masson wrote: > >>>> Le 3 oct. 2014 à 17:06, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>>>> On 10/03/2014 04:11 PM, Jason Cooper wrote: > >>>>>> On Sun, Sep 21, 2014 at 04:11:23PM +0200, Benoit Masson wrote: > >>>>>>>> Le 19 sept. 2014 à 22:14, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>> [...] > >>>>>>>> Patches are based on v3.17-rc1 and intended for v3.18 but I am not in > >>>>>>>> a hurry. I only compile tested this, so a formal Tested-by from Benoit > >>>>>>>> for the ix4 and any other Armada XP board would be great. > >>>>>>> > >>>>>>> I'm not sure what to test since I only receive some patch from the > >>>>>>> series of 8. Should I get all 8 or only those you sent me. I'll be > >>>>>>> able to test during next week. > >>>>>> > >>>>>> Did you ever get a chance to test this series? > >>>>> > >>>>> Uhm, I never prepared a branch for Benoit to test. I have pushed the > >>>>> patches with Thomas Acked-by's and renamed eeprom node based on > >>>>> v3.17-rc1 to > >>>>> > >>>>> https://github.com/shesselba/linux-dove.git devel/mvebu-ix4 > >>>>> > >>> [...] > >> Maybe I missed something ? is this branch you sent me a bare fork > >> from mainline 3.17 ? does it includes the armada XP step A0 patch ? > > > > Benoit, > > > Hi, > > I prepared more branches with the series > > - on top of v3.17 release: > > https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17 > > > > - on top of next-20141003 (i.e. what will become v3.18-rc1): > > https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003 > > > > It would be great, if you can test in this order: > > - vanilla v3.17 > > - mvebu-ix4_v3.17 > > - mvebu-ix4_next-20141003 > > > All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig > > The reason why it didn't worked last time was that apparently the A0 patch (copied) below was not merged into 3.17 :( > > This means that ix4-300d support is broken on 3.17 because of the A0 stepping patch not merged. Do you have a link to an email thread or the patch Subject line? I can confirm it's missing from mvebu/fixes... thx, Jason. > patch (from Andrew Lunn Acked-by Gregory Clement is missing: > > --- > arch/arm/mach-mvebu/board-v7.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c > index b2524d6..b1e148d 100644 > --- a/arch/arm/mach-mvebu/board-v7.c > +++ b/arch/arm/mach-mvebu/board-v7.c > @@ -174,7 +174,7 @@ static void __init thermal_quirk(void) > > static void __init mvebu_dt_init(void) > { > - if (of_machine_is_compatible("plathome,openblocks-ax3-4")) > + if (of_machine_is_compatible("marvell,armadaxp")) > i2c_quirk(); > if (of_machine_is_compatible("marvell,a375-db")) { > external_abort_quirk(); > -- > 1.9.1 > > If any branch fails, you can stop and please report back. > > > > I also have the ix4 but I need more time for a full setup like you > > already seem to have ready. Again, there is no hurry, take your time. > > > > Thanks! > > > > Sebastian >
On 10/15/2014 04:42 PM, Jason Cooper wrote: > On Wed, Oct 15, 2014 at 02:53:02AM +0200, Benoit Masson wrote: >> Le 6 oct. 2014 à 18:13, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : >>> I prepared more branches with the series >>> - on top of v3.17 release: >>> https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17 >>> >>> - on top of next-20141003 (i.e. what will become v3.18-rc1): >>> https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003 >>> >>> It would be great, if you can test in this order: >>> - vanilla v3.17 >>> - mvebu-ix4_v3.17 >>> - mvebu-ix4_next-20141003 >>> >> All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig >> >> The reason why it didn't worked last time was that apparently the A0 patch (copied) below was not merged into 3.17 :( >> >> This means that ix4-300d support is broken on 3.17 because of the A0 stepping patch not merged. > > Do you have a link to an email thread or the patch Subject line? I can > confirm it's missing from mvebu/fixes... http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html But you and Andrew should check what Arnd suggested. IIRC, there was also an appropriate follow-up patch discussion started by Andrew. Sebastian
> >Do you have a link to an email thread or the patch Subject line? I can > >confirm it's missing from mvebu/fixes... > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html > > But you and Andrew should check what Arnd suggested. IIRC, there > was also an appropriate follow-up patch discussion started by > Andrew. There was a lot of back and forth with Arnd. In the end, he gave up arguing because too many voices did not like his solution. So my original version stands. However, the patch at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html is useful, and it would be nice if it could be merged as well. Andrew
On Wed, Oct 15, 2014 at 04:55:39PM +0200, Andrew Lunn wrote: > > >Do you have a link to an email thread or the patch Subject line? I can > > >confirm it's missing from mvebu/fixes... > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html > > > > But you and Andrew should check what Arnd suggested. IIRC, there > > was also an appropriate follow-up patch discussion started by > > Andrew. > > There was a lot of back and forth with Arnd. In the end, he gave up > arguing because too many voices did not like his solution. So my > original version stands. Yes, this appears to have been a mistake on my part. In the conversation regarding patch #2 of V2, you said you were going to work on implementing something and would report back. I applied that to the whole series instead of just to the second patch. At any rate, applied to mvebu/fixes now. > However, the patch at the end of > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html > > is useful, and it would be nice if it could be merged as well. I'll take a look. thx, Jason.
Le 15 oct. 2014 à 16:41, Andrew Lunn <andrew@lunn.ch> 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
On Wed, Oct 15, 2014 at 11:30:49AM -0400, Jason Cooper wrote: > On Wed, Oct 15, 2014 at 04:55:39PM +0200, Andrew Lunn wrote: > > > >Do you have a link to an email thread or the patch Subject line? I can > > > >confirm it's missing from mvebu/fixes... > > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html > > > > > > But you and Andrew should check what Arnd suggested. IIRC, there > > > was also an appropriate follow-up patch discussion started by > > > Andrew. > > > > There was a lot of back and forth with Arnd. In the end, he gave up > > arguing because too many voices did not like his solution. So my > > original version stands. > > Yes, this appears to have been a mistake on my part. In the > conversation regarding patch #2 of V2, you said you were going to work > on implementing something and would report back. I applied that to the > whole series instead of just to the second patch. At any rate, applied > to mvebu/fixes now. > > > However, the patch at the end of > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html > > > > is useful, and it would be nice if it could be merged as well. > > I'll take a look. I'd still like to see that note captured in the binding doc. Did I miss another patch somewhere? thx, Jason.
On Wed, Oct 15, 2014 at 02:53:02AM +0200, Benoit Masson wrote: > > Le 6 oct. 2014 à 18:13, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > > > On 10/06/2014 01:11 AM, Benoit Masson wrote: > >> Le 3 oct. 2014 à 17:41, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>> On 10/03/2014 05:29 PM, Benoit Masson wrote: > >>>> Le 3 oct. 2014 à 17:06, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>>>> On 10/03/2014 04:11 PM, Jason Cooper wrote: > >>>>>> On Sun, Sep 21, 2014 at 04:11:23PM +0200, Benoit Masson wrote: > >>>>>>>> Le 19 sept. 2014 à 22:14, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a écrit : > >>> [...] > >>>>>>>> Patches are based on v3.17-rc1 and intended for v3.18 but I am not in > >>>>>>>> a hurry. I only compile tested this, so a formal Tested-by from Benoit > >>>>>>>> for the ix4 and any other Armada XP board would be great. > >>>>>>> > >>>>>>> I'm not sure what to test since I only receive some patch from the > >>>>>>> series of 8. Should I get all 8 or only those you sent me. I'll be > >>>>>>> able to test during next week. > >>>>>> > >>>>>> Did you ever get a chance to test this series? > >>>>> > >>>>> Uhm, I never prepared a branch for Benoit to test. I have pushed the > >>>>> patches with Thomas Acked-by's and renamed eeprom node based on > >>>>> v3.17-rc1 to > >>>>> > >>>>> https://github.com/shesselba/linux-dove.git devel/mvebu-ix4 > >>>>> > >>> [...] > >> Maybe I missed something ? is this branch you sent me a bare fork > >> from mainline 3.17 ? does it includes the armada XP step A0 patch ? > > > > Benoit, > > > Hi, > > I prepared more branches with the series > > - on top of v3.17 release: > > https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17 > > > > - on top of next-20141003 (i.e. what will become v3.18-rc1): > > https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003 > > > > It would be great, if you can test in this order: > > - vanilla v3.17 > > - mvebu-ix4_v3.17 > > - mvebu-ix4_next-20141003 > > > All the 3 branch works WHEN APPLYING A0 patch (below), with both my > custom kernel config and the arch/arm/configs/mvebu_v7_defconfig Can I count this as a Tested-by? > The reason why it didn't worked last time was that apparently the A0 > patch (copied) below was not merged into 3.17 :( Yep, sorry. Life got the best of me. The pull request is now sent. > This means that ix4-300d support is broken on 3.17 because of the A0 > stepping patch not merged. Not a problem. It's flagged for stable v3.12 and up. thx, Jason.
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c index b2524d6..b1e148d 100644 --- a/arch/arm/mach-mvebu/board-v7.c +++ b/arch/arm/mach-mvebu/board-v7.c @@ -174,7 +174,7 @@ static void __init thermal_quirk(void) static void __init mvebu_dt_init(void) { - if (of_machine_is_compatible("plathome,openblocks-ax3-4")) + if (of_machine_is_compatible("marvell,armadaxp")) i2c_quirk(); if (of_machine_is_compatible("marvell,a375-db")) { external_abort_quirk();