On 05.11.2012 03:57, Shawn Guo wrote:

quoted

The patch in attach fixes this. I can only test the MX28 part -
I don't have any timrot_is_v1() (MX23) hardware and I don't
know whether a source that wraps after ~2 seconds is OK at all.

From my quick testing on imx23 with printk timestamp, it's not OK,
so we may need to leave imx23 out there.

Hmm, does it wrap after 2 seconds? From my grepping and googling
the code should now adapt itself, the hardcoded limit is gone...
What does the dmesg line such as

  sched_clock: 32 bits at 32kHz, resolution 31250ns,
    wraps every 134217727ms

output on that hardware?

Thanks for the comments, I will resubmit the corrected patch after
waiting ~1,5 days to verify correct wrapping with MX28.

Regards
-- 
                                         Stano