* Isak Lichtenstein <Isak.Lichtenstein@xxxxxxxxxxx> [180223 11:54]: > And indeed we do see the warning popping up more times than expected (on some devices every couple of hours), but the gp_timer isn't stopped. > Here the output of such a warning: > > Feb 22 09:45:02 DUT1 user.warn kernel: WARNING: CPU: 0 PID: 0 ....../kernel-source/arch/arm/plat-omap/include/plat/dmtimer.h:403 omap2_gp_timer_set_next_event+0xb4/0xcc > Feb 22 09:45:02 DUT1 user.warn kernel: __omap_dm_timer_load_start(): Timer 2 not started!! > Feb 22 09:45:02 DUT1 user.warn kernel: [<c012e5a0>] (warn_slowpath_fmt) from [<c011aba8>] (omap2_gp_timer_set_next_event+0xb4/0xcc) > Feb 22 09:45:02 DUT1 user.warn kernel: [<c011aba8>] (omap2_gp_timer_set_next_event) from [<c017e8a8>] (clockevents_program_min_delta+0x64/0x70) > Feb 22 09:45:02 DUT1 user.warn kernel: [<c017fcd0>] (tick_program_event) from [<c01729a8>] (hrtimer_start_range_ns+0x1f8/0x214) > Feb 22 09:45:02 DUT1 user.warn kernel: [<c01729a8>] (hrtimer_start_range_ns) from [<c0180258>] (tick_nohz_restart.constprop.9+0x80/0xa0) Hmm so I wonder if the read back with posted mode actually causes you to hit OMAP_TIMER_ERRATA_I103_I767. Can you please disable OMAP_TIMER_POSTED and I think you also need to comment out __omap_dm_timer_override_errata() in omap2_gp_clockevent_init(). So the same test in non-posted mode and see if you get errors. > Unfortunately not the entire log message is output, guess due to the "\n" in it. Or there is some other issue that is really the root cause here such as bad memory? > Nevertheless it gives a clue, although one I'm not sure what to do with it as it leaves me rather confused. > As we read the register using __omap_dm_timer_read, I would assume that the "posted" issue should be mitigated. If so what else can it be? Yes it should get there eventually with posted writes. But it could be that now the added read-back triggers the errata :) > Why would the gp_timer sometimes stop completely while other times it continuous working properly? In the posted mode it could be that write never gets there if the interconnect is idled before the write is completed. Could it be that you have some other software reading the clockevent counter values causing you to now hit posted-mode errata OMAP_TIMER_ERRATA_I103_I767? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
