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 6568DC38142 for ; Fri, 27 Jan 2023 13:40:34 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 387938571E; Fri, 27 Jan 2023 14:40:16 +0100 (CET) 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="oYRi7kla"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F39DC85473; Thu, 26 Jan 2023 23:12:44 +0100 (CET) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 4B8F885559 for ; Thu, 26 Jan 2023 23:12:12 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=digetx@gmail.com Received: by mail-lf1-x12f.google.com with SMTP id h24so5267035lfv.6 for ; Thu, 26 Jan 2023 14:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NTbJaV7PFeDOiVHCeoVufIFdxs8Zbk9/vmFdqmPpV8s=; b=oYRi7klaVD5eD0BnOtFC29JEFrQvMaTM56RXnepkcvD9ds6BirReMdtiBwo+OFgAq6 T8I4RbwKUwIaLCmPssqQZWEKxKVYJyOG9YTcpUN75U3tIS29KwPivDuYZ8RBhXvMe6CD CBWTv+fuHBcCL6uWptrPG8KBMb5y/YMfI/BGBFiXicDXcYTjJAIZuEVpy7o82F1r54FW NdM9ol6h7KcNonq5DV0m2r9NVe7fzaVvFBR705cGi8PPHMhvOifH3CNwxVhwaiU43xLx ttGAJWfHeCjOtRawNlmrjF1SIzY5r9ygB1hjz+0kyBAI76j75FyFn1wrhnYLNmubGEJ+ Oy8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NTbJaV7PFeDOiVHCeoVufIFdxs8Zbk9/vmFdqmPpV8s=; b=LzpO1Vf2QZquc0k+Be+7Itz42YoCOWEzA9j9e7DQDkq5dRA7zDNuWvYlnU4xZJzpHg egQ66XlYsXHdoS988qiqfomNQMUhCH6ImQIaLPLxbEHs5ytj6hYaorY6t6b0rfcb2cU7 YrNLns1bBrvG33H65xKCgyW5ZGI7PBfTmyuXay1u7kfSWOVG5t/rrOMEMJe0ZZlJRNA0 BebGwxzJi0lZcKJlrfsZOndqByB88m+GMKKUPCmDedhjTEZQP9Cqisx0nEk3t0nwz3/x oJewSpxZxkudcPw5KL+Al8v14b+n/86EUNulyBdlxr+6HQWgM3NqlW1RCgjYvyqWJ4Dv ddlw== X-Gm-Message-State: AFqh2krqJLdhYfWcS1B+8QDygvTNpsBqa/FtaFTpyMlF1snUtFxbPPUj uRNTm67uAgizw+GWFkehJHc= X-Google-Smtp-Source: AMrXdXus+jnQzdNgdSb8Y7O5lhIRzel1WnatloAH8k5bKgmR8sIzkipvxqvCqr5b37hikXwl1fonhg== X-Received: by 2002:a05:6512:158e:b0:4cc:93e9:df8e with SMTP id bp14-20020a056512158e00b004cc93e9df8emr12341178lfb.33.1674771129823; Thu, 26 Jan 2023 14:12:09 -0800 (PST) Received: from [192.168.2.145] (109-252-117-89.nat.spd-mgts.ru. [109.252.117.89]) by smtp.googlemail.com with ESMTPSA id j28-20020ac2551c000000b004d44a75d6b7sm141591lfk.103.2023.01.26.14.12.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Jan 2023 14:12:09 -0800 (PST) Message-ID: <8f5e5307-3cbb-fa97-2722-e8fe2e9fed81@gmail.com> Date: Fri, 27 Jan 2023 01:12:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v6 0/3] Timer support for ARM Tegra Content-Language: en-US From: Dmitry Osipenko To: Thierry Reding , Svyatoslav Ryhel Cc: Rayagonda Kokatanur , Tom Warren , Marek Vasut , Maxim Schwalm , Heinrich Schuchardt , Michal Simek , Stefan Roese , Eugen Hristev , Michael Walle , Simon Glass , Jim Liu , William Zhang , Rick Chen , Stefan Herbrechtsmeier , Andre Przywara , Jaehoon Chung , u-boot@lists.denx.de References: <20230124065751.5973-1-clamor95@gmail.com> <521d7425-559b-0919-84a9-515f1b46ab18@gmail.com> In-Reply-To: <521d7425-559b-0919-84a9-515f1b46ab18@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 27 Jan 2023 14:40:01 +0100 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 27.01.2023 01:00, Dmitry Osipenko пишет: > 26.01.2023 20:54, Thierry Reding пишет: >> On Thu, Jan 26, 2023 at 07:08:54PM +0200, Svyatoslav Ryhel wrote: >>> чт, 26 січ. 2023 р. о 12:35 Thierry Reding пише: >>>> >>>> On Wed, Jan 25, 2023 at 05:41:08PM +0100, Thierry Reding wrote: >>>>> On Tue, Jan 24, 2023 at 08:57:48AM +0200, Svyatoslav Ryhel wrote: >>>>>> - ARM: tegra: remap clock_osc_freq for all Tegra family >>>>>> Enum clock_osc_freq was designed to use only with T20. >>>>>> This patch remaps it to use additional frequencies, added in >>>>>> T30+ SoC while maintaining backwards compatibility with T20. >>>>>> >>>>>> - drivers: timer: add timer driver for ARMv7 based Tegra devices >>>>>> Add timer support for T20/T30/T114 and T124 based devices. >>>>>> Driver is based on DM, has device tree support and can be >>>>>> used on SPL and early boot stage. >>>>>> >>>>>> - ARM: tegra: include timer as default option >>>>>> Enable TIMER as default option for all Tegra devices and >>>>>> enable TEGRA_TIMER for TEGRA_ARMV7_COMMON. Additionally >>>>>> enable SPL_TIMER if build as SPL part and drop deprecated >>>>>> configs from common header. >>>>>> >>>>>> P. S. I have no arm64 Tegra and according to comment in >>>>>> tegra-common.h >>>>>> Use the Tegra US timer on ARMv7, but the architected timer on ARMv8. >>>>>> >>>>>> Svyatoslav Ryhel (3): >>>>>> ARM: tegra: remap clock_osc_freq for all Tegra family >>>>>> drivers: timer: add timer driver for ARMv7 based Tegra devices >>>>>> ARM: tegra: include timer as default option >>>>> >>>>> This causes a regression on Tegra210 (Jetson TX1). I'm trying to >>>>> investigate, but it's complicated by the fact that I'm not getting out >>>>> any debug prints, so I suspect the issue is happening quite early. >>>> >>>> Alright, I managed to make this work on Tegra210 using the following >>>> patch on top of this series: >>>> >>> >>> Hello! Thanks for testing this on T210 SoC. >>> >>>> --- >8 --- >>>> diff --git a/arch/arm/dts/tegra210.dtsi b/arch/arm/dts/tegra210.dtsi >>>> index a521a43d6cfd..ccb5a927da89 100644 >>>> --- a/arch/arm/dts/tegra210.dtsi >>>> +++ b/arch/arm/dts/tegra210.dtsi >>>> @@ -318,7 +318,7 @@ >>>> }; >>>> >>>> timer@60005000 { >>>> - compatible = "nvidia,tegra210-timer", "nvidia,tegra20-timer"; >>>> + compatible = "nvidia,tegra210-timer", "nvidia,tegra30-timer", "nvidia,tegra20-timer"; >>> >>> This compatibe should not be needed since the driver will have t210 >>> compatible included. >> >> Yes, it should be fine to leave this as-is. I had included this before >> updating the driver, to get the driver to bind to this. Upstream Linux >> doesn't include "nvidia,tegra20-timer", so it only has the compatible >> string for Tegra210. I think that's slightly better because the register >> interface isn't quite compatible. That's a separate issue and we can do >> that in a follow-up patch. >> >>> >>>> reg = <0x0 0x60005000 0x0 0x400>; >>>> interrupts = , >>>> , >>>> diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig >>>> index cc3f00e50128..b50eec5b8c9b 100644 >>>> --- a/arch/arm/mach-tegra/Kconfig >>>> +++ b/arch/arm/mach-tegra/Kconfig >>>> @@ -136,6 +136,7 @@ config TEGRA210 >>>> select TEGRA_PINCTRL >>>> select TEGRA_PMC >>>> select TEGRA_PMC_SECURE >>>> + select TEGRA_TIMER >>>> >>>> config TEGRA186 >>>> bool "Tegra186 family" >>>> diff --git a/drivers/timer/tegra-timer.c b/drivers/timer/tegra-timer.c >>>> index d2d163cf3fef..235532ba8926 100644 >>>> --- a/drivers/timer/tegra-timer.c >>>> +++ b/drivers/timer/tegra-timer.c >>>> @@ -58,17 +58,26 @@ static notrace u64 tegra_timer_get_count(struct udevice *dev) >>>> static int tegra_timer_probe(struct udevice *dev) >>>> { >>>> struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev); >>>> + enum clock_osc_freq freq; >>>> u32 usec_config, value; >>>> >>>> /* Timer rate has to be set unconditionally */ >>>> uc_priv->clock_rate = TEGRA_TIMER_RATE; >>>> >>>> + /* >>>> + * The microsecond timer runs off of clk_m on Tegra210, and clk_m >>>> + * runs at half the OSC, so fake this up. >>>> + */ >>>> + freq = clock_get_osc_freq(); >>>> + if (freq == CLOCK_OSC_FREQ_38_4) >>>> + freq = CLOCK_OSC_FREQ_19_2; >>>> + >>> >>> May you confirm that ALL known T210 devices use 19.2MHz as calibration >>> clock for timer? >> >> According to the Tegra210 TRM, the TIMERUS depends on the rate of clk_m >> and clk_m is derived from OSC and either divided by 1, 2, 3 or 4. The >> TRM goes on to say that: >> >> The expectation is that this CLK_M_DIVISOR will only be changed >> once after powering VDD_SOC on in cold boot/LP0 exit path. So >> these sequences are verified with an oscillator clock of 38.4 >> MHz; div2 setting of the CLK_M divisor must be used. The result >> is 19.2 MHz clk_m. >> >> And then it says: >> >> Note: Div2 is the recommended clk_m divisor value. Do not use >> any other value. >> >> This is from Section 5.1.2 "Clk_m Divisor" of the Tegra210 TRM. >> >>> If yes I can set this change in simpler as a separate commit or >>> including into existing patches. >> >> Anything you have in mind? I tried a couple of variations to the above >> and they all failed because in other places it's important that OSC is >> recognized as running at 38.4 MHz. If not, then other PLLs will not >> work properly and even basic things like the debug UART won't work. >> >> Technically the right thing to do would be to base the USEC config off >> the clk_m rate. We didn't do that back at the time, IIRC, because most >> of the clock infrastructure didn't exist, but it might be possible to >> achieve this today. I kept the above because it is still a bit simpler >> and as the TRM suggests nobody should be using anything other than the >> div2 setting for clk_m. I'm certainly not aware of any devices that do >> something different. And U-Boot has always had this assumption as well, >> so I think it's safe to use. > > Am I understanding correctly that for T210 we can/should use > clk_m_get_rate() instead of clock_get_osc_freq() in tegra_timer_probe()? > Have you tested this option? Although, looking at the kernel code, I see that clk_m is the parent clock for timer on all SoCs. Hence replacing clock_get_osc_freq() with clk_m_get_rate() should be the proper solution and then no T210-specific workarounds are needed.