Re: [PATCH 7/8] x86/mrst: add vrtc driver which serves as a wall clock device

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 18 May 2010, john stultz wrote:

> On Mon, 2010-05-17 at 11:15 +0200, Thomas Gleixner wrote:
> > 
> > 
> > There is no particular reason why we need to read it in
> > timekeeping_init(). Nothing in the kernel needs the correct wall time
> > at that point. So we can safely move the setting of xtime to rtc wall
> > clock time to a separate timekeeping_late_init() function.
> > 
> > John ???
> 
> No big objections here. Still would like to keep the amount of time that
> the kernel is up without xtime being initialized to a minimum. However

Why? Nothing _IS_ depending on xtime at this point. We just should
have it ready when we mount the first file system, but even that is
not a big issue aside of some stupid warnings.

> the generic RTC code already have this issue since some of them require
> interrupts to be enabled to do a read, so pushing it off into a
> _late_init() function is probably just a short term fix until we figure
> out how to get the generic RTC code working better with the timekeeping
> code.

Well, you need to wait until the driver is loaded and the hardware
accessible which might take some time when I2C, SPI or similar stuff
is involved. No way to get this stuff accesible early.

So really the question is, why do we want wall time initialized early?
All we care about until we hit user space is clock monotonic and
working timekeeping in general. NTP is not an issue either before we
hit user space. So what's your concern ?

> Does the delayed init required by vrtc cause any trouble with
> suspend/resume?

No, suspend/resume does not go through that early code. It has
everything setup (mappings, etc)

Thanks,

	tglx