Re: [PATCH 3/3] stop the periodic RTC update timer

[Paolo Bonzini <pbonzini@redhat.com>]

On 01/12/2012 11:20 AM, Marcelo Tosatti wrote:
>> >
>> >  The point is not_correctness_.  It is_atomicity_.
> Quoting you earlier
>
> "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."

(The actual figure is 244, not 220; my mistake).

> Agree with the first point, but the second, the emulated RTC never
> returns a bogus read.

That's true: the update cycle takes 1984 us on the real RTC, and 0 us on 
QEMU.

However, the data sheet says that the update cycle begins 244 us _after_ 
the rising edge of UIP.  In other words, UIP is set for 1984 + 244 us on 
the real RTC, and should be set for 0 + 244 us on the emulated RTC.

This is done on purpose: the data sheet says, "if a low is read on the 
UIP bit, the user has at least 244 us before the time/calendar data will 
be changed".  As long as you read the time within 244 us, the following 
cannot happen:

    read UIP     => 0
    read HOURS   => 10
    read MINUTES => 59
    read SECONDS => 59
    ...
    read UIP     => 0
    read HOURS   => 10
    read MINUTES => 59
                       update happens! (on real RTC: update cycle starts)
    read SECONDS => 0                  (on real RTC: undefined)

You are a kernel junkie and as such you are too much accustomed to 
seqlocks. ;)

If you know the read will take more than 244 us, the data sheet suggests 
that you use the update-ended interrupt.  But you can also wait for the 
falling edge of UIP, like Xen does.  The falling edge of UIP will never 
happen if the emulated RTC always returns 0 for UIP.

Paolo