On Mon, Nov 05, 2012 at 10:14:24AM +0100, Stanislav Meduna wrote:

On 05.11.2012 03:57, Shawn Guo wrote:

quoted

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.

I should say it's practically not OK since it wraps in such a short
period.  But it actually works as expected.

Hmm, does it wrap after 2 seconds?

Yes, it does 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?

Yes, something like:

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

Shawn