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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 84DB9ECAAD1 for ; Thu, 1 Sep 2022 05:33:44 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 61C3F84228; Thu, 1 Sep 2022 07:33:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1662010422; bh=t+Xv7JNvQ97zCqyQN8OjjNhtNnJCVZ5jZl3Tkp3n5FY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=XalYNhfBopfISiY2OBpwR8ud4fVBZGStjAV8fEF9UIXz2lq6m7QjsyGOVG59xj7UQ 9VwAjgD05z1JjCEBTbtBH6yiaxlQAQzk1EUmmHIXx6AjhlfKZt4N8Y3CFDpQ6zwZOm xEGjppdWKM97t4R3mRziFEOUdsHonshM/IlrsdI69GYNt1dd0KjfT65HcboH7cADhE sFEqL51BiObOSZtAMOAfq9RvmVrjPzhtzFgswgOm1VgeM2wl96Py5w/xOgMcRe/RY1 aLpF0lfKxUSj+Dnss5xHnHhcKrqgBeL27SPkE/aKIpXL+LaudZx5GXsyObAIqKw0g5 om8qh/XyQc/xg== Received: by phobos.denx.de (Postfix, from userid 109) id A3A30849CA; Thu, 1 Sep 2022 07:33:40 +0200 (CEST) Received: from mout-u-204.mailbox.org (mout-u-204.mailbox.org [80.241.59.204]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A0E1A80361 for ; Thu, 1 Sep 2022 07:33:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-204.mailbox.org (Postfix) with ESMTPS id 4MJ8pm5Rq2z9sS9; Thu, 1 Sep 2022 07:33:36 +0200 (CEST) Message-ID: Date: Thu, 1 Sep 2022 07:33:35 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 2/6] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support Content-Language: en-US To: Simon Glass Cc: Michael Walle , U-Boot Mailing List , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Tony Dinh References: <20220830115317.410812-1-sr@denx.de> <20220830115317.410812-3-sr@denx.de> <092fe47f6dee523cb4cdbb81abc0cd40@walle.cc> <57f2671c-3841-74ec-b6c0-2c7aff3c3239@denx.de> <65546e81-1287-3994-6e83-38fea3d1fa6c@denx.de> From: Stefan Roese In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Simon, On 31.08.22 19:44, Simon Glass wrote: >>> It is needed because bootstage is called before driver model is ready. >>> In fact it can be used to time driver model things. >> >> I see, makes sense. This brings up my next questions though, why isn't >> CONFIG_TIMER_EARLY enough in this case? AFAICT it's targeted exactly >> for this early (pre DM) bootstage. From drivers/timer/Kconfig: >> >> config TIMER_EARLY >> bool "Allow timer to be used early in U-Boot" >> depends on TIMER >> # initr_bootstage() requires a timer and is called before initr_dm() >> # so only the early timer is available >> default y if X86 && BOOTSTAGE >> help >> In some cases the timer must be accessible before driver model is >> active. Examples include when using CONFIG_TRACE to trace U-Boot's >> execution before driver model is set up. Enable this option to >> use an early timer. These functions must be supported by your timer >> driver: timer_early_get_count() and timer_early_get_rate(). >> >> So again, do we really need timer_get_boot_us() or isn't it enough >> to select TIMER_EARLY when BOOTSTAGE is enabled? > > The timer is for milliseconds but for bootstage we need microseconds. > > Perhaps the ultimate solution here is to support a microsecond timer > through the TIMER api and use the TIMER_EARLY thing to provide > timer_get_boot_us(), perhaps renaming to timer_early_get_us() ? Yes, sounds like a plan. We should consolidate these implementations. Let me think about it and perhaps do some basic implementations and tests for a while. Thanks, Stefan