From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIdUL-0001hF-5E for qemu-devel@nongnu.org; Thu, 30 Jun 2016 11:02:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIdUI-00010o-LE for qemu-devel@nongnu.org; Thu, 30 Jun 2016 11:02:45 -0400 Received: from mail-vk0-x232.google.com ([2607:f8b0:400c:c05::232]:34037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIdUI-00010e-Gm for qemu-devel@nongnu.org; Thu, 30 Jun 2016 11:02:42 -0400 Received: by mail-vk0-x232.google.com with SMTP id c2so113529401vkg.1 for ; Thu, 30 Jun 2016 08:02:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5814242b-8a8c-852a-51e8-268033b51200@gmail.com> References: <20160625123521.16752-1-digetx@gmail.com> <5814242b-8a8c-852a-51e8-268033b51200@gmail.com> From: Peter Maydell Date: Thu, 30 Jun 2016 16:02:22 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2] hw/ptimer: Don't wrap around counter for expired timer that uses tick handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dmitry Osipenko Cc: QEMU Developers , qemu-arm , Peter Crosthwaite , Mark Cave-Ayland On 27 June 2016 at 19:26, Dmitry Osipenko wrote: > On 27.06.2016 16:27, Peter Maydell wrote: >> I guess this fixes a regression, but it looks really weird. >> Why should the timer behaviour change if there happens to be >> a bottom half present? That should be an internal implementation >> detail. It's also a bit odd that use_icount is in the check: >> that shouldn't generally affect device emulation behaviour... > > In case of a polled timer that doesn't have ptimer trigger bottom half callback > setup, we are free to wrap around counter since timer behaviour isn't changed > from ptimer user perspective, as it won't be able to change it's state in the > handler. > > I just decided to keep that wraparound feature for a case of a polled free > running timer, this should result in a better distribution of the polled value. > The potential users of that feature are "imx_epit" and "digic" timer device > models. I should have mentioned it in the commit message to avoid confusion, sorry. > > It is still an internal implementation detail, not sure what you are meaning. > Could you elaborate, please? What I meant was: ptimer_get_count() is typically called to generate a value to return from a register. That's a separate thing, conceptually, from whether the device happens to also trigger an interrupt on timer expiry by passing a bh to ptimer_init(). So it's very odd for a detail of interrupt-on-timer-expiry (that there is a bottom half) to affect the value returned when you read the timer count register. thanks -- PMM