From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj8sG-0007Xz-6R for qemu-devel@nongnu.org; Mon, 05 Oct 2015 12:44:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj8s8-0007ep-RI for qemu-devel@nongnu.org; Mon, 05 Oct 2015 12:44:28 -0400 Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:33753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj8s8-0007ef-KC for qemu-devel@nongnu.org; Mon, 05 Oct 2015 12:44:20 -0400 Received: by lafb9 with SMTP id b9so40454042laf.0 for ; Mon, 05 Oct 2015 09:44:20 -0700 (PDT) References: <1436128000-16262-1-git-send-email-crosthwaite.peter@gmail.com> <559997FB.4030301@gmail.com> <560FD3FF.3040206@gmail.com> <5612A041.8000005@gmail.com> From: Dmitry Osipenko Message-ID: <5612A8CA.3090108@gmail.com> Date: Mon, 5 Oct 2015 19:43:54 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC v1 0/2] ARM MPTimer fixes and refactoring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite 05.10.2015 19:27, Peter Crosthwaite пишет: > On Mon, Oct 5, 2015 at 9:07 AM, Dmitry Osipenko wrote: >> 03.10.2015 16:11, Dmitry Osipenko пишет: >> >>> 20.09.2015 20:48, Peter Crosthwaite пишет: >>>> >>>> On Sun, Jul 5, 2015 at 1:58 PM, Peter Crosthwaite >>>> wrote: >>>>> >>>>> On Sun, Jul 5, 2015 at 1:47 PM, Dmitry Osipenko >>>>> wrote: >>>>>> >>>>>> 05.07.2015 23:26, Peter Crosthwaite пишет: >>>>>> >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Based on my comment earlier, this is what I came up with RE >>>>>>> consolidation >>>>>>> of >>>>>>> those arm_mptimer code paths that were giving you problems. I have not >>>>>>> done the >>>>>>> interrupt mask fix, as that one from your series is reasonably >>>>>>> independent. >>>>>>> >>>>>>> Regards, >>>>>>> Peter >>>>>>> >>>>>>> Peter Crosthwaite (2): >>>>>>> timer: arm_mp: Factor out timer value calculation >>>>>>> timer: arm_mp: consolidate control and counter write logic >>>>>>> >>>>>>> hw/timer/arm_mptimer.c | 73 >>>>>>> +++++++++++++++++++++++++++++--------------------- >>>>>>> 1 file changed, 42 insertions(+), 31 deletions(-) >>>>>>> >>>>>> >>>>>> Hi Peter, thanks a lot! Generally, I don't have any trouble with >>>>>> currently >>>>>> missed functionality, just noticed it while was hacking my NVIDIA >>>>>> Tegra2 >>>>>> emulation pet-project and decided to contribute =). >>>>>> >>>>>> It looks like you are trying to duplicate what generic ptimer is >>>>>> already >>>>>> doing, isn't it? >>>>>> >>>>> >>>>> Yes, ptimer was probably the correct way to do this in the first >>>>> place. Some of the new code structures introduced in this patch series >>>>> are directly applicable though for that conversion effort. >>>>> >>>> >>>> I looked into doing this with ptimer, and pitmer doesn't really play >>>> nice with periodic down counters. You could do the subtractions >>>> against an up counter with the load value but that seems just as >>>> complex as the current solution IMO. The hardest part is setting the >>>> counter value on an already running timer. >>>> >>>> The alternative is to patch ptimer to handle down timers. >>>> >>>> Regards, >>>> Peter >>>> >>> >>> Hmm, I think you missed something. Ptimer is doing downcount, not up. >>> ptimer_get_count() might be a misnomer, it returns current timer value (it >>> goes >>> down to 0), not a passed ticks count number. Ptimer also should handle >>> reloading >>> of a running timer just fine with ptimer_set_count(), don't see any >>> trouble >>> here. Anyway, I'll try to re-implement MPtimer using ptimer ASAP and see >>> how it >>> really fits. >>> >> >> Finally, I tried ptimer and everything seem to work perfect. Pausing, >> re-loading, etc works as it should. Will send the patch soon. >> > > Great! > > Thanks for the efforts. I'll take a CC on the review. > > Do on the fly prescaler changes work? > > Regards, > Peter > >> -- >> Dmitry Yes, prescaler works on the fly. I'll post my MPtimer tests somewhere. -- Dmitry