On Mon, Nov 05, 2012 at 10:14:24AM +0100, Stanislav Meduna wrote: > On 05.11.2012 03:57, Shawn Guo wrote: > > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
