* H. Nikolaus Schaller hns@goldelico.com [160216 02:48]:
Am 15.02.2016 um 23:40 schrieb Grazvydas Ignotas grazvydas.ignotas@openpandora.org:
Maybe something like this would help (untested in any way):
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..af38614 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -670,6 +670,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, l |= OMAP_TIMER_CTRL_PT; l |= trigger << 10; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
__omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
brilliant!
That made this error go away and reappear somewhere else. After applying the same fix to several other locations where timer registers are written I could make them all go away.
Hmm, I don't think I've seen this one either.
But IMHO there is a deeper issue. The third parameter of __omap_dm_timer_read() is called "posted" and setting it to 1 makes the driver wait for some activity to finish.
There is also a comment in omap_dm_timer_read_reg() which says:
"The posted mode bit is encoded in reg."
But the code does not "decode" it depending on the register number. Rather there is a timer->posted flag which is set or reset globally depending on how the driver is initialized or if __omap_dm_timer_enable_posted() is called.
This appears to be hooked up from the wrong end. Either the SoC (L3 interconnect) needs this posting mechanism or it does not. How can the code using the driver know better than the driver itself.
Sounds like we have a bug somewhere though. Are using the new drivers/pwm/pwm-omap-dmtimer.c?
And maybe on OMAP5 we need it. While on OMAP3 we don't (because the A8 is slower but L3 might have similar speed). So it does not depend on what the user of the dmtimer wants to have.
BTW: there was also some "cleanup" proposed a while ago, but did not find it into mainline:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/117682....
Jon was planning to improve that patch further to optimize the code for clocksource as noted later on in the thread here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/119241....
which also shows the "wrong" approach. Why should it be possible to "configure" the whole timer to posted mode. IMHO it is sort of transaction processing, i.e. grouping register writes and then committing them. So it depends on the sequence of write commands.
That was needed earlier to optimize the code for system timers as the clockevent write without posted mode can take a while, and for clocksource read we want to optimize it out.
Regards,
Tony