From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 451D4C433DB for ; Thu, 7 Jan 2021 21:05:33 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A5E66233CF for ; Thu, 7 Jan 2021 21:05:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5E66233CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:45882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxcTL-0002T2-HU for qemu-devel@archiver.kernel.org; Thu, 07 Jan 2021 16:05:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxcG2-0004yU-NJ for qemu-devel@nongnu.org; Thu, 07 Jan 2021 15:51:46 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:37808) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kxcG1-00053r-06 for qemu-devel@nongnu.org; Thu, 07 Jan 2021 15:51:46 -0500 Received: by mail-ej1-x62c.google.com with SMTP id ga15so11630235ejb.4 for ; Thu, 07 Jan 2021 12:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gqi24Ai0MHhPoFwoMyHu9fKaAXLmhYyMzu9GXm1LsrM=; b=NjO57jFTI9+HM4g6sWEwJzQhjaD66Jd0feXVPmgziRSukdgI3JdsR+NR4mPMsqjkJ2 KZbMjvU+LB+MlP96cNzQN1gVF85tz1wXv4TGVArPrjDK0QfjhLF/Owlo9XTvo4kqvyB5 AFDlORPoemfXplrPyV/JilgYYyPWYac5AlZJyAaHkp3o9eK5cp3mDnmCmxLHRLsCgGry aLnc8UkU7OjARUnwd2GX8+ElIuwf6MEVCSr/xO8XzYHLh/ncG/iwAFmMLa/cI8CI7tw0 nCbBlrEIM9JUaiiJM+OkBblPGmuKT+ZbQE8IUtHSilIMo84ovSbAMl/0fIEUXhKAvsEB UoDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gqi24Ai0MHhPoFwoMyHu9fKaAXLmhYyMzu9GXm1LsrM=; b=B/8PzdLV+5Nxk5hGb+hFSuvdeiZ7ClKYqgf+OQtVh6LDY3/5sC/MAUhM7DWRG+04w6 Ejxlw/zx9QFtmny2cz9zkmAuoQlm/yERAqYjb7jIysEL5Qk07ykJzMmpdx1DtZz4gpSU fN6L34wWKxrZ6Qw16u/lIYWMryQYWTatDD1wYBNy1wUIQwoqksmlKey4IbaXAWFK9oFf PPDSmpv7mRCirea78WyrDpqsNez8VA8pA58zmxPYTXTobIRv+Crv6VXmQ0e/H3f6aUmo gBtxt9yAhkgZciRqfpkRsJOwiOdoLUOr3Ud0o6goVj0DdinlAzZ+ZyU1j0EjLMuhDcrN C/7A== X-Gm-Message-State: AOAM533ykSAdf4hWDgdGvn9vjQC9Tapy5CGQKcN4yH/naHW3xP3l11ak ysjz+z61y/tXvVbvJKDl0AhIwkojs8e/7GSy99uEmg== X-Google-Smtp-Source: ABdhPJz28f09I3L+W6JJqpAaay2G29A3rVQh3AiQNv0lOQzACY9IsoulTpdVknPGVr+tjeAfdS/IQCaJ7iyAXGWkJe4= X-Received: by 2002:a17:906:6b88:: with SMTP id l8mr468767ejr.482.1610052702610; Thu, 07 Jan 2021 12:51:42 -0800 (PST) MIME-Version: 1.0 References: <20201217004349.3740927-1-wuhaotsh@google.com> <20201217004349.3740927-3-wuhaotsh@google.com> In-Reply-To: <20201217004349.3740927-3-wuhaotsh@google.com> From: Peter Maydell Date: Thu, 7 Jan 2021 20:51:31 +0000 Message-ID: Subject: Re: [PATCH v4 2/6] hw/timer: Refactor NPCM7XX Timer to use CLK clock To: Hao Wu Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Patrick Venture , Havard Skinnemoen , QEMU Developers , CS20 KFTing , qemu-arm , IS20 Avi Fishman , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 17 Dec 2020 at 00:45, Hao Wu wrote: > > This patch makes NPCM7XX Timer to use a the timer clock generated by the > CLK module instead of the magic number TIMER_REF_HZ. > > Reviewed-by: Havard Skinnemoen > Reviewed-by: Tyrone Ting > Signed-off-by: Hao Wu > --- > hw/arm/npcm7xx.c | 5 +++++ > hw/timer/npcm7xx_timer.c | 25 ++++++++++++++----------- > include/hw/misc/npcm7xx_clk.h | 6 ------ > include/hw/timer/npcm7xx_timer.h | 1 + > 4 files changed, 20 insertions(+), 17 deletions(-) > @@ -130,7 +130,7 @@ static int64_t npcm7xx_timer_count_to_ns(NPCM7xxTimer *t, uint32_t count) > { > int64_t ns = count; > > - ns *= NANOSECONDS_PER_SECOND / NPCM7XX_TIMER_REF_HZ; > + ns *= clock_get_ns(t->ctrl->clock); > ns *= npcm7xx_tcsr_prescaler(t->tcsr); I'm afraid that since you wrote and sent this we've updated the clock API (in commits 554d523785ef868 and de6a65f11d7e5a2a93f), so clock_get_ns() doesn't exist any more. Instead there is a new function clock_ticks_to_ns(). The idea of the new function is that clocks don't necessarily have a period which is a whole number of nanoseconds, so doing arithmetic on the return value from clock_get_ns() introduces rounding errors, especially in the case of "multiply clock_get_ns() by a tick count to get a duration". (The worst case for this is "clock frequency >1GHz", at which point the rounding means that clock_get_ns() returns 0...) There is as yet no function for "convert duration to tick count", so code like: count = ns / clock_get_ns(t->ctrl->clock); should probably for the moment call clock_ticks_to_ns() passing a tick count of 1. But I plan to write a patchset soon which will avoid the need to do that. Strictly speaking, even "call clock_ticks_to_ns() and then multiply by the prescaler value" can introduce rounding error; to deal with that I think you'd need to either have an internal Clock object whose period you adjusted as the prescalar value was updated by the guest, or else do arithmetic with the return value of clock_get() (which is in units of 2^-32 ns); I'm not sure either is worth it. thanks -- PMM