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 67DFBECAAD2 for ; Fri, 2 Sep 2022 02:51:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BA8C3840B1; Fri, 2 Sep 2022 04:51:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PpC/n3sn"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 207FC84A04; Fri, 2 Sep 2022 04:51:47 +0200 (CEST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EA811840B1 for ; Fri, 2 Sep 2022 04:51:43 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mibodhi@gmail.com Received: by mail-vs1-xe35.google.com with SMTP id 190so774062vsz.7 for ; Thu, 01 Sep 2022 19:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=FPRxH3f8bLRU8mW2hsK2SXEcIeLMMDngIsf6JuQcR2A=; b=PpC/n3snfraMd9Kxie3yTjDEAUn43vUQzpPfGKVkYM1tY3bqSgoLB1giK6ZMPjsOkz fO5DIyox2PYCxAeNIc9s6BfMokXE2+gP6ZY1PSwQ2YqnomWoYGzZClZzK7OAbZZSXLwt jm5wWUlb2ucRdx04tGg1mp4SRH5OtR6M6oAON7Nc7xWvTETfg8UviBdbveSb7JytpmA1 arwuArzfgeUvaDwP8qij/iX2jNl+khjEhLXBRVTLafTDPIEAgaT+AwAsGuP7RYf/NI1s dPB3FCuUypZ05/TDe9rr6pcHlMFjQzTqcVmACfikoUgdNNugnRIKF3RJYff3tUdpZ+oQ 84Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=FPRxH3f8bLRU8mW2hsK2SXEcIeLMMDngIsf6JuQcR2A=; b=6ESxxB7vYu1+KSSlIsk44/1tjmd/kBLVy5r0QrvgXYJmfkyZWLqcbLC0Ymz9WByV1k Imnp6a2tAt7/MsPLirRginUOlVWSLlbmJzxtvei6tKxmnpsd4nrVOqRJZz7Rr0Q+iP0i 2PPyeJsM19d7lK1XfM7pJYtuzFF/eoVSzEQNdrklwuhnZJHiZUmh8FBDDA+q3hL7aOEY BmpQ8TWFG1Qm52HSZM0p923Gh2qINi3stwWv9mNgp+bQYXmLGfvm3alcxmaN9fd47npe L5eoK8bIo9OT7WwatwpSvq+nIzbymKmKuekulr/RWsQmflqfxTiNm2bUVR1hCDUfWu1k 6rwQ== X-Gm-Message-State: ACgBeo0udWoVQwrPRHIbWSl1rgLiKNop53oCUpyx14nGQX+aiW49+ou6 dtaCVviuTngWupuUafOIk4yxkxO/tbciwu8B97o= X-Google-Smtp-Source: AA6agR4pnyJp39RiAMiz2oFnDAbiArqENNUtUmZg/Js791YKVs7s7zESlm9Wmp6gXagnndQTFfEO7zCaXRmu16Kzrq8= X-Received: by 2002:a05:6102:3a10:b0:388:6f3a:8d2a with SMTP id b16-20020a0561023a1000b003886f3a8d2amr9999606vsu.76.1662087102532; Thu, 01 Sep 2022 19:51:42 -0700 (PDT) MIME-Version: 1.0 References: <20220830115317.410812-1-sr@denx.de> <282eefe1-58d4-89cd-f940-2428bdd42b59@denx.de> In-Reply-To: From: Tony Dinh Date: Thu, 1 Sep 2022 19:51:31 -0700 Message-ID: Subject: Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards To: Simon Glass Cc: Stefan Roese , U-Boot Mailing List , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Michael Walle , stefan.herbrechtsmeier-oss@weidmueller.com Content-Type: text/plain; charset="UTF-8" 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 Hello, On Thu, Sep 1, 2022 at 4:46 PM Tony Dinh wrote: > > Hi Stefan R, > > On Thu, Sep 1, 2022 at 7:35 AM Simon Glass wrote: > > > > Hi, > > > > On Thu, 1 Sept 2022 at 03:27, Stefan Roese wrote: > > > > > > Hi Tony, > > > > > > On 01.09.22 09:39, Tony Dinh wrote: > > > > > > > > > > > > >>> Some ideas. > > > >>> > > > >>> The get_timer() function looks wrong assigning an uint64_t to ulong. > > > >>> > > > >>> lib/time.c > > > >>> > > > >>> static uint64_t notrace tick_to_time(uint64_t tick) > > > >>> uint64_t notrace get_ticks(void) > > > >>> uint64_t __weak notrace get_ticks(void) > > > >>> > > > >>> ulong __weak get_timer(ulong base) > > > >>> { > > > >>> return tick_to_time(get_ticks()) - base; > > > >>> } > > > >>> > > > >>> Most of the timer infrastructure is using uint64_t. I'm seeing this > > > >>> __weak function get_timer was invoked in Kirkwood boards. Both in > > > >>> sleep and timer commands. > > > >> > > > >> The get_ticks() thing can run at 1MHz but the timer is 1KHz, so that > > > >> is why we don't need a u64 for the timer. > > > > This is wrong, I meant that get_tbclk() can run at 1MHZ (for example). > > The tick is 1KHz. > > > > > > > > > > Thanks for your explanation! However, would you agree that code is > > > > problematic and needed some improvement ? IOW, depending what the > > > > compiler does, it might return the 1st 32 bit of the 64-bit integer > > > > result? > > > > Yes, we should really use ulong for the tick count as well. The use of > > 64-bits seems wrong (on 32-bit machines). > > > > > > > > It will return the lower 32 bits if the system is 32bit, yes. > > > > > > To check if we have a problem here, please add this (totally untested) > > > code and extend it if it makes sense: > > > > > > diff --git a/lib/time.c b/lib/time.c > > > index bbf191f67323..ef5252419f3b 100644 > > > --- a/lib/time.c > > > +++ b/lib/time.c > > > @@ -146,7 +146,15 @@ int __weak timer_init(void) > > > /* Returns time in milliseconds */ > > > ulong __weak get_timer(ulong base) > > > { > > > - return tick_to_time(get_ticks()) - base; > > > + u64 ticks = get_ticks(); > > > + u64 time_ms = tick_to_time(ticks); > > > + > > > + if (time_ms & 0xffffffff00000000ULL) > > > + printf("ticks=%lld time_ms=%lld\n", ticks, time_ms); > > > + if ((time_ms - base) & 0xffffffff80000000ULL) > > > + printf("ticks=%lld time_ms=%lld base=%ld ret=%lld\n", > > > ticks, time_ms, base, time_ms - base); > > > + > > > + return time_ms - base; > > > } > > With this patch, indeed it showed a wrap around. And the system was > frozen during the next command. > > Below is the log (my annotated comment starts with ***). > > > U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Sep 01 2022 - 15:44:22 -0700) > Pogoplug V4 > > SoC: Kirkwood 88F6281_A1 > Model: Cloud Engines PogoPlug Series 4 > DRAM: 128 MiB > orion_timer_probe Clock Rate 166000000 > orion_timer_probe successful > Core: 19 devices, 15 uclasses, devicetree: separate > NAND: 128 MiB > MMC: mvsdio@90000: 0 > Loading Environment from NAND... OK > In: serial > Out: serial > Err: serial > pcie0.0: Link up > Net: eth0: ethernet-controller@72000 > Hit any key to stop autoboot: 0 > Pogo_V4> sleep 5 > do_sleep got a timer start = 14344 > do_sleep delay = 5000 > do_sleep delay = 5000 > do_sleep sleeping... > do_sleep start 14344 curent 100 > do_sleep start 14344 curent 200 > > do_sleep start 14344 curent 4800 > do_sleep start 14344 curent 4900 > do_sleep end of sleep ... current = 5000 > > Pogo_V4> sleep 10 > do_sleep got a timer start = 22370 > do_sleep delay = 10000 > do_sleep delay = 10000 > do_sleep sleeping... > do_sleep start 22370 curent 100 > do_sleep start 22370 curent 200 > do_sleep start 22370 curent 300 > do_sleep start 22370 curent 400 > > do_sleep start 22370 curent 3300 > do_sleep start 22370 curent 3400 > do_sleep start 22370 curent 3500 > ticks=188 time_ms=0 base=22370 ret=-22370 > do_sleep end of sleep ... current = 4294944926 > > *** we are seeing wrap around here > > Pogo_V4> sleep 15 > do_sleep got a timer start = 15733 > do_sleep delay = 15000 > do_sleep delay = 15000 > do_sleep sleeping... > do_sleep start 15733 curent 100 > do_sleep start 15733 curent 200 > do_sleep start 15733 curent 300 > do_sleep start 15733 curent 400 > > > do_sleep start 15733 curent 9900 > do_sleep start 15733 curent 10000 > do_sleep start 15733 curent 10100 > > *** And the system was frozen here > > > > Thanks, > Tony > > > > > > > > > > > > At least here, you seem to have a wrap around with the 32bits AFAICT: > > > > > > > GoFlexHome> sleep 20.5 > > > > do_sleep got a timer start = 15031 > > > > do_sleep delay = 20000 > > > > do_sleep delay = 20500 > > > > do_sleep sleeping... > > > > do_sleep start 15031 current 100 > > > > > > > > do_sleep start 15031 current 6400 > > > > do_sleep end of sleep ... current = 4294952265 > > > > > > > > *** Something strange happened here. current should be 6500, but it > > > > seems to have garbage. So the loop exits prematurely. > > > > > > 4294952265 = 0xFFFFC549! > > > > Yes this all needs a look, I think. > > > > Regards, > > Simon I think Stefan H's response above is right. drivers/timer/orion-timer.c struct orion_timer_priv { void *base; }; static uint64_t orion_timer_get_count(struct udevice *dev) { struct orion_timer_priv *priv = dev_get_priv(dev); return ~readl(priv->base + TIMER0_VAL); } To handle the wrap-around in a 32-bit system, it should invoke "u64 timer_conv_64(u32 count)". This function in timer-uclass increments the tbh when the tbl wraps around. return timer_conv_64(~readl(priv->base + TIMER0_VAL)); I'll patch that and do some tests. Thanks, Tony