From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57612)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VB4Dd-0001xm-5Z
	for qemu-devel@nongnu.org; Sun, 18 Aug 2013 10:44:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VB4DY-0002Wj-Ph
	for qemu-devel@nongnu.org; Sun, 18 Aug 2013 10:44:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:48573)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VB4DY-0002WP-He
	for qemu-devel@nongnu.org; Sun, 18 Aug 2013 10:44:32 -0400
Message-ID: <5210DDA2.1060703@redhat.com>
Date: Sun, 18 Aug 2013 16:43:46 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1376489436-29136-1-git-send-email-james.hogan@imgtec.com>
In-Reply-To: <1376489436-29136-1-git-send-email-james.hogan@imgtec.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 1/1] mc146818rtc: correct UIP hold length
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: James Hogan <james.hogan@imgtec.com>
Cc: Yang Zhang <yang.z.zhang@intel.com>, Igor Mammedov <imammedo@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>

Il 14/08/2013 16:10, James Hogan ha scritto:
> The UIP (update in progress) hold time was set to 8 32.768KHz clock
> cycles (around 244uS). However the timing diagram in the datasheet
> (Figure 16) shows that the UIP bit is held for both the update cycle
> time (either 248uS or 1984uS depending on the clock source), and the
> minimum time before update cycle (244uS).
>=20
> It's clear from periodic_timer_update() that only a 32.768KHz clock
> source is expected, so correct the hold time to 244uS + 1984uS =3D 73
> 32.768KHz clock cycles.

I am not sure if this time would actually go from t-244us to t+1984us on
real hardware?  You could measure this using a divider reset and
sampling PF and UF.

The emulation right now does "instant" updates, which elegantly
sidesteps the problem. :)

> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Andreas F=C3=A4rber <afaerber@suse.de>
> Cc: Anthony Liguori <aliguori@us.ibm.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Yang Zhang <yang.z.zhang@intel.com>
> ---
>  hw/timer/mc146818rtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> index 3c3baac..6000feb 100644
> --- a/hw/timer/mc146818rtc.c
> +++ b/hw/timer/mc146818rtc.c
> @@ -55,7 +55,7 @@
> =20
>  #define RTC_REINJECT_ON_ACK_COUNT 20
>  #define RTC_CLOCK_RATE            32768
> -#define UIP_HOLD_LENGTH           (8 * NSEC_PER_SEC / 32768)
> +#define UIP_HOLD_LENGTH           (73 * NSEC_PER_SEC / 32768)
> =20
>  #define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_=
RTC)
> =20
> @@ -597,7 +597,7 @@ static int update_in_progress(RTCState *s)
>      }
> =20
>      guest_nsec =3D get_guest_rtc_ns(s);
> -    /* UIP bit will be set at last 244us of every second. */
> +    /* UIP bit will be set at last 1984us + 244us of every second. */
>      if ((guest_nsec % NSEC_PER_SEC) >=3D (NSEC_PER_SEC - UIP_HOLD_LENG=
TH)) {
>          return 1;
>      }
>=20