From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr57V-0006P1-8P for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:21:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr57R-0003W9-1K for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:21:01 -0400 Received: from mail-lf0-x229.google.com ([2a00:1450:4010:c07::229]:33128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr57Q-0003VA-QW for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:20:56 -0400 Received: by lffv3 with SMTP id v3so173018203lff.0 for ; Tue, 27 Oct 2015 07:20:55 -0700 (PDT) References: From: Dmitry Osipenko Message-ID: <562F8807.2090107@gmail.com> Date: Tue, 27 Oct 2015 17:19:51 +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] arm mptimer implementation - why prescaler is multiply by 10? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Krzeminski, Marcin (Nokia - PL/Wroclaw)" , "qemu-devel@nongnu.org" Cc: "peter.maydell@linaro.org" , "crosthwaitepeter@gmail.com" 27.10.2015 16:48, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет: > Hello, > I am playing with U-Boot on ARM under qemu. > U-boot uses mptimer, and under qemu one second takes about 1 in real world. > At the moment it seem that in u-boot is ok, so I have question about below function. > Why prescaler value is multiply by 10? > static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s) > { > uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT, > R_CONTROL_PRESCALER_LEN); > return (prescale + 1) * 10; > } > Regards, > Marcin Hello Marcin, From my observation, Linux kernel is booting noticeably faster in the emulated guest and host machine CPU usage is lower if we "artificially" slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that trick shouldn't affect guest behavior. However, maybe there is some other rational behind it and Peter C and/or Peter M might know better. -- Dmitry