From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Cameron Esfahani via" <qemu-devel@nongnu.org>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-block@nongnu.org, "Corey Minyard" <minyard@acm.org>,
"David Hildenbrand" <david@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Max Reitz" <mreitz@redhat.com>,
qemu-arm@nongnu.org, "Joel Stanley" <joel@jms.id.au>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Cédric Le Goater" <clg@kaod.org>
Subject: Re: [PATCH 7/7] hw/watchdog/wdt_aspeed: Reduce timer precision to micro-second
Date: Tue, 23 Jun 2020 09:15:58 +0930 [thread overview]
Message-ID: <e1fba66a-8c7e-4b15-9f6e-5e1957555088@www.fastmail.com> (raw)
In-Reply-To: <3e3459aa-7179-56e5-3e4d-b25f2ea3b450@amsat.org>
On Mon, 22 Jun 2020, at 18:13, Philippe Mathieu-Daudé wrote:
> On 6/22/20 2:21 AM, Andrew Jeffery wrote:
> > On Wed, 17 Jun 2020, at 13:11, Philippe Mathieu-Daudé wrote:
> >> Hi Andrew,
> >>
> >> On 6/17/20 3:18 AM, Andrew Jeffery wrote:
> >>> On Tue, 16 Jun 2020, at 17:21, Philippe Mathieu-Daudé wrote:
> >>>> The current implementation uses nano-second precision, while
> >>>> the watchdog can not be more precise than a micro-second.
> >>>
> >>> What's the basis for this assertion? It's true for the AST2500 and AST2600, but
> >>> the AST2400 can run the watchdog from either a 1MHz clock source or the APB
> >>> clock (which must be at least 16.5MHz on palmetto). The reset state on the
> >>> AST2400 configures the watchdog for the APB clock rate.
> >>>
> >>> The Linux driver will eventually configure the watchdog for 1MHz mode
> >>> regardless so perhaps the AST2400 reset state is a bit of a corner case, but
> >>> I feel the assertion should be watered down a bit?
> >>
> >> What about this description?
> >>
> >> "The current implementation uses nano-second precision, but
> >> is not more precise than micro-second precision.
> >> Simplify by using a micro-second based timer.
> >> Rename the timer 'timer_us' to have the unit explicit."
> >
> > So is this a limitation of QEMUTimer? I was establishing that the hardware can
> > operate at greater than 1 micro-second precision.
>
> No, I misread your comment about the AST2400 timer which can run
> at more than 1Mhz.
>
> The QEMUTimer doesn't have a such limitation; this patch
> aimed to simplify the code for reviewers, but you proved
> it incorrect, so let's disregard it.
>
> Thanks for your careful review!
Ah, great, I was wondering where my misunderstanding was.
Thanks for clearing that up.
Andrew
next prev parent reply other threads:[~2020-06-22 23:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 7:51 [PATCH 0/7] misc: Reduce QEMUTimer pressure by using lower precision when possible Philippe Mathieu-Daudé
2020-06-16 7:51 ` [PATCH 1/7] qemu-common: Briefly document qemu_timedate_diff() unit Philippe Mathieu-Daudé
2020-06-18 5:47 ` Markus Armbruster
2020-06-22 8:50 ` Philippe Mathieu-Daudé
2020-06-16 7:51 ` [PATCH 2/7] block/qcow2: Document cache_clean_interval field holds seconds Philippe Mathieu-Daudé
2020-06-16 7:51 ` [PATCH 3/7] block/curl: Reduce timer precision to milli-second Philippe Mathieu-Daudé
2020-06-16 7:51 ` [PATCH 4/7] hw/virtio/virtio-balloon: Rename timer field including 'ms' unit Philippe Mathieu-Daudé
2020-06-16 7:57 ` David Hildenbrand
2020-06-16 7:51 ` [PATCH 5/7] hw/rtc/m48t59: Reduce timer precision to milli-second Philippe Mathieu-Daudé
2020-07-08 23:39 ` Richard Henderson
2020-06-16 7:51 ` [PATCH 6/7] hw/ipmi/ipmi_bmc_extern: " Philippe Mathieu-Daudé
2020-06-16 7:51 ` [PATCH 7/7] hw/watchdog/wdt_aspeed: Reduce timer precision to micro-second Philippe Mathieu-Daudé
2020-06-17 1:18 ` Andrew Jeffery
2020-06-17 3:41 ` Philippe Mathieu-Daudé
2020-06-22 0:21 ` Andrew Jeffery
2020-06-22 8:43 ` Philippe Mathieu-Daudé
2020-06-22 23:45 ` Andrew Jeffery [this message]
2020-07-08 23:40 ` Richard Henderson
2020-06-18 12:23 ` [PATCH 0/7] misc: Reduce QEMUTimer pressure by using lower precision when possible Paolo Bonzini
2020-06-18 12:26 ` Philippe Mathieu-Daudé
2020-06-18 12:42 ` Paolo Bonzini
2020-07-08 23:37 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1fba66a-8c7e-4b15-9f6e-5e1957555088@www.fastmail.com \
--to=andrew@aj.id.au \
--cc=clg@kaod.org \
--cc=david@redhat.com \
--cc=f4bug@amsat.org \
--cc=joel@jms.id.au \
--cc=kwolf@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=minyard@acm.org \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.