From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK8pn-0000TS-3s for qemu-devel@nongnu.org; Fri, 15 Jan 2016 13:10:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aK8pm-0003dD-6A for qemu-devel@nongnu.org; Fri, 15 Jan 2016 13:10:51 -0500 References: <5c18054d536f3f940d3059235f0ac4aad42c835c.1452359845.git.digetx@gmail.com> <20160112035858.GG3308@pcrost-box> <5695420E.2020709@gmail.com> From: Dmitry Osipenko Message-ID: <56993601.5010400@gmail.com> Date: Fri, 15 Jan 2016 21:10:09 +0300 MIME-Version: 1.0 In-Reply-To: <5695420E.2020709@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v10 5/7] hw/ptimer: Legalize running with delta = load = 0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , qemu-arm@nongnu.org, QEMU Developers 12.01.2016 21:12, Dmitry Osipenko пишет: > 12.01.2016 06:58, Peter Crosthwaite пишет: >> On Sat, Jan 09, 2016 at 08:39:53PM +0300, Dmitry Osipenko wrote: >>> Currently ptimer would print error message and clear enable flag for an >>> arming timer that has delta = load = 0. That actually could be a valid case >>> for some hardware, like instant IRQ trigger for oneshot timer or continuous >>> in periodic mode. Support those cases by printing error message only when >>> period = 0. >>> >> >> Isn't the continuous-periodic the same as period = 0, so if we were to really >> support this, there should be no error message. This would simplify as we >> can remove the conditionals of 0 period completely and rely only on the >> too-fast clamps you add in previous patches. >> > > I don't think that clamping is needed. Instead doing the ptimer_tick might be > necessary, so ptimer user could handle that case on it own. > > BTW, that printf isn't quite reliable, hw_error or other way of execution abort > should been used instead. > > Thanks for the comment. > Looking more at it, I think we should keep period = 0 forbidden. So it's treated as undefined behaviour and ptimer user should take care of it. If we'd want to handle period = 0 within ptimer, then we should also handle freq = 0, which implies potential ptimer VMSD version bump. Also it is uncertain what default behaviour should be chosen for period = 0, my guess is that pausing (_not_disabling_) the timer (like in freq = 0 case) should be more common among various hardware. If you have any thoughts on it, please let me know. -- Dmitry