On Tue, 2005-02-01 at 15:53 -0800, Tim Bird wrote: > john stultz wrote: > > I believe you're right. Although we don't call read_persistent_clock() > > very frequently, nor do we call it in ways we don't already call > > get_cmos_time(). So I'm not sure exactly what the concern is. > > Sorry - I should have given more context. I am worried about > suspend and resume times. An extra (up-to-a) second delay on > suspend it pretty painful for CE devices. (See my SIG for > my other hat in the forum.)
Ok, Nigel clarified it pretty well. Thanks. > > > > Since we call read_persistent_clock(), it should return right as the > > second changes, thus we will be marking the new second as closely as > > possible with the timesource value. If the order was reversed, I think > > it would be a concern. > > > > It sounds like for your code, this synchronization is a valuable. Well, it just affects how much time error we gain on suspend/resume. We can't be perfect (well, unless our active timesource is persistent clock), and the comment points that we're just trying to minimize the error. > For many CE products, the synchronization is not needed. I have a > patch that removes the synchronization for i386 and ppc, but > I haven't submitted it because I didn't want to mess up > non-boot-context callers of get_cmos_time which have valid > synchronization needs. Interesting patch. Indeed, the trade off is just how quickly you want to boot vs how much drift you gain each suspend/resume cycle. Assuming all of the clocks are good, your patch could introduce up to 2 seconds of drift each suspend/resume cycle. > As you can see below, the patch is pretty braindead. > I was wondering if this conflicted with your new timer system or > not. Not really. The issue is present with or without my code. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
