Plea for help... While working with the -rt patch + HRT on OMAP3, I'm seeing are data aborts during the first access to any timer register after the fclk is (re)enabled by dm_timer_set_source(). There's a __delay() after the clk_enable() with a comment saying that some delay is necessary. What's strange is that I can increase this delay by several orders of magnitude, and it still gets a data abort. Even stranger, this only happens when using one of the preempt modes. It doesn't happen under CONFIG_PREEMPT_NONE. However, it is happening during bootup where there's only one thread (pid: 0) running so no preemption is actually happening as far as I can tell. Debugging this is quite difficult as slight changes for debugging change which access triggers the data abort or makes the problem go away entirely. I have played with various combinations of posted/non-posted mode for the accesses but there is always a data abort somewhere. Are there any erratta on the ES1 silicon I should know about? What about any subtle differences between OMAP2/3 in this area? I seem to have same problem whether I use the 32k or sys_ck source. Any ideas? Kevin - 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
