On 01/10/2012 07:37 AM, Zhang, Yang Z wrote:
Also, I'm not sure if the update in progress flag still works.
Clients are supposed to wait for UIP=0 before reading the RTC,
and an update is supposed to be at least 220 microseconds away
when UIP=0.
Hardware need a period time to update clock and it would not provide
the right value during the update. So it uses UIP to notify the
software doesn't believe the value if the UIP is set. For emulation,
you can read RTC at any time and it always gives you the right value.
So there is no need to emulate UIP.
This is incorrect, for two reasons. First, the UIP is in the spec, and
we have to implement it. Second, reading the clock is not atomic, and
waiting for UIP=0 gives you 220 microseconds during which you know that
the read will appear atomic.
Also, it would be nice if you could based these patches on the
4-patch series I sent recently that fixes some bugs with
interrupts and 12-hour emulation.
When it will be check in?
I don't know. :)
There is another aspect of RTC emulation that is missing in the
current code; after setting the clock, the next second tick will
occur in exactly 500 ms. I have patches to fix this, but it
looks like it could be incorporated in your series, too.
I do not quite understand it. What does "setting the clock" mean? And
what is the next second tick?
It means that the (not externally visible) millisecond value is set to
500 when you modify the current time of the RTC. The next update of the
clock will happen exactly 500 ms after you reset bit 7 of register B.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
