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 A685BC433FE for ; Tue, 4 Oct 2022 11:50:16 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8A8BC84C5F; Tue, 4 Oct 2022 13:50:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=amd.com header.i=@amd.com header.b="UDejRvTb"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6167C84C46; Tue, 4 Oct 2022 13:50:11 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2050.outbound.protection.outlook.com [40.107.220.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9FDC584C5F for ; Tue, 4 Oct 2022 13:50:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=michal.simek@amd.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L8DgZMIaw891v3Z91TCPGEp/x39CGcvMRssEFhDg6+50H04s68bZYhvk7Tf1/79JKiRlmYuQOXkbAgmElI55y1AKWJ68ZhZKGkkNZOPNz/U5sxVDMdsRRPfIavOXIL0hxHIAsRJEIl7n+OS0IKYPmbeaBx/EpLgy4GR3+FSDNMx6ghT7f+YUtHUA9THt6mbt0Nul6ErT0QBLNA3dqL3GLbSHbuCGR2GDi1pIesjykkGVXGjYXLrev/zJu4eO9iWLcJ5xzaeHVgj+9jGKaWHc+pOWHMce9dvCTb2MvNV2bo20+CkLVhehnDY3qzLhfP61LffBugK3wa9KNFYcNSORDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TP3169jJDgLwQdmW697Dh9OXZF42NsTWUyVcuIz7QLs=; b=XUGezI0m8TmnvvcAEuCXuu7+kEv+ky8ODdWZhokdQl9yE8pR95wh2SCRvjB8aujyukKEu/Qut8ISes8aCHMVkXYYAclUHbr3zzZXIHWZ7YsrJtje6O7UE56O+dFywGIRrYDZfKvRdk0lWB+wnbk0CRRKelvl+vNisCK697b9TbdP0mc/++qsGS5NtvDhHZTcaOIR7zhKHHyxyMsKUsmMFcav7NFIdtrhBewS1OeZ71ILW/GQPeU/+8vo/oz4URjFjG96cNqKuGAEHo9xFKsclvftzYXiy7tmxD/4C4B+l5Ow99QCulfq1RtgBRHvoEOEh25MZVR1Ls53hS03n0iPYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=denx.de smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TP3169jJDgLwQdmW697Dh9OXZF42NsTWUyVcuIz7QLs=; b=UDejRvTbxv6hIDheypctGAVmTuAHnn4L6Ik5NIBw2HpVlBwtshVFtJLSzWOALyCpPj6hBYVfVV+aTN/mbQe7RknG27d5k0xdFkuVZYBkW+ll5ryten6h9PIEYdGUHMQ4ZqI0UvoAoehgSLKbaC5Ic5btSMnzm0RqXYirNKK4Xzc= Received: from MW4P222CA0006.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::11) by DM4PR12MB6255.namprd12.prod.outlook.com (2603:10b6:8:a4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.28; Tue, 4 Oct 2022 11:50:03 +0000 Received: from CO1NAM11FT067.eop-nam11.prod.protection.outlook.com (2603:10b6:303:114:cafe::a9) by MW4P222CA0006.outlook.office365.com (2603:10b6:303:114::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.31 via Frontend Transport; Tue, 4 Oct 2022 11:50:02 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1NAM11FT067.mail.protection.outlook.com (10.13.174.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5676.17 via Frontend Transport; Tue, 4 Oct 2022 11:50:02 +0000 Received: from [10.254.241.52] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Tue, 4 Oct 2022 06:49:59 -0500 Message-ID: Date: Tue, 4 Oct 2022 13:49:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH 04/10] timer: cadence-ttc: Add timer_early functions Content-Language: en-US To: Stefan Roese , Simon Glass CC: Michal Simek , U-Boot Mailing List , Tom Rini References: <20220921140625.999002-1-sr@denx.de> <20220921140625.999002-5-sr@denx.de> <1570cc7c-5cdc-d2c5-60a1-ad83cc12bee9@denx.de> From: Michal Simek In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1NAM11FT067:EE_|DM4PR12MB6255:EE_ X-MS-Office365-Filtering-Correlation-Id: 97e6e608-a0e3-423d-688a-08daa5fe929c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3MU+eaqcTJgdjcB+IwaRErxJMRgmh0h+KC6Xu+4UB4kTFOnHEFD6ICCJaCSfgquPyv8lvo/ZfittxZhojXBaGzzU2w200frXAh8FqYfaR4VQE0Ofy8/Nqj1jx02FGt0ZXpRrhw7w6Q1PnesFvx8boHEErHH5yn5mhaoXArJQewzzpbjqAdiu5G5ws3XdbBjkGPIxzBtZKz+fJ3LPbjSUJIxZBxQmDMwQEvL53emBrJkbfiU0BtF0Oc+xTm8sgkTtY5vIK30D/UcERMHaCOXo84DS+JVtvIGtbwlg8FrF2pgsTBSNfKsn1D0OxjlrHpgZQc8VF6B0PzTSfIRAzmOniEZG8Wq+H86TUMugwK5OZWaCNEElHH3BbqYlaZ2XIQoZ3lQz7H+d3vRANonACwYt3ccWmz73VehpgFTojpQRsHeIWGjOPGKd+oEbtNF9PZU1VR19Srh/wf6aHUo6URrDrtXlbCwM8m6Wcy0cbjyqt9XF4w1Eg8MzEJ7zFM3Zhrc5O5DLqmdpOPzqxFkWKzM1OTRhxhceX1q+sT6+BGKazl6H6iOX64Bz+EQjLoVP/kzRAHfqQZr3w4oHTqTeyDt+Tpxkn8mdwlNYzMPNaNH396HJ4xZhkLqFdEaX9e9redDH3C7oSnO+Ed0GqJU08ltXXTJrN3TKjimSIy5+y0IgUfY2EX7pcqf7p+25QYZ31nMVFu+sTOn7dS4gnyNtGhPP/pbfKvt6sjRZiG9OHjIIMCa90WZLShmMTKgYYdy+4BJllaWR2+uHnIwGabFvWoQ3gVUvKfuSGkLtg9pdNLH26sBJgWUZteVGy+LoEd5XypurfeK8O3vDjrPazLwzfSdSoA== X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230022)(4636009)(39860400002)(396003)(136003)(376002)(346002)(451199015)(36840700001)(46966006)(40470700004)(2616005)(316002)(82740400003)(336012)(4326008)(426003)(16526019)(186003)(8676002)(70586007)(26005)(70206006)(81166007)(356005)(40480700001)(53546011)(36860700001)(47076005)(478600001)(36756003)(86362001)(40460700003)(54906003)(83380400001)(110136005)(82310400005)(31696002)(16576012)(8936002)(31686004)(44832011)(5660300002)(41300700001)(2906002)(36900700001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2022 11:50:02.4315 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 97e6e608-a0e3-423d-688a-08daa5fe929c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT067.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6255 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 Stefan, On 9/30/22 15:45, Stefan Roese wrote: > Hi Michal, > > On 30.09.22 14:02, Michal Simek wrote: >> Hi Simon and Stefan, >> >> On 9/28/22 03:54, Simon Glass wrote: >>>> Hi Simon, >>>> Hi Michal, >>>> >>>> On 25.09.22 16:15, Simon Glass wrote: >>>>> Hi Stefan, >>>>> >>>>> On Wed, 21 Sept 2022 at 08:06, Stefan Roese wrote: >>>>>> >>>>>> Currently this timer driver provides timer_get_boot_us() to support the >>>>>> BOOTSTAGE functionality. This patch adds the timer_early functions so >>>>>> that the "normal" timer functions can be used, when CONFIG_TIMER_EARLY >>>>>> is enabled. >>>>>> >>>>>> timer_get_boot_us() will get removed in a follow-up patch, once the >>>>>> BOOTSTAGE interface is migrated to timer_get_us(). >>>>>> >>>>>> Signed-off-by: Stefan Roese >>>>>> Cc: Michal Simek >>>>>> --- >>>>>>    drivers/timer/cadence-ttc.c | 25 +++++++++++++++++++++++++ >>>>>>    1 file changed, 25 insertions(+) >>>>>> >>>>>> diff --git a/drivers/timer/cadence-ttc.c b/drivers/timer/cadence-ttc.c >>>>>> index 2eff45060ad6..e26c7923a140 100644 >>>>>> --- a/drivers/timer/cadence-ttc.c >>>>>> +++ b/drivers/timer/cadence-ttc.c >>>>>> @@ -58,6 +58,31 @@ ulong timer_get_boot_us(void) >>>>>>    } >>>>>>    #endif >>>>>> >>>>>> +unsigned long notrace timer_early_get_rate(void) >>>>>> +{ >>>>>> +       return 1; >>>>>> +} >>>>>> + >>>>>> +u64 notrace timer_early_get_count(void) >>>>>> +{ >>>>>> +       u64 ticks = 0; >>>>>> +       u32 rate = 1; >>>>>> +       u64 us; >>>>>> +       int ret; >>>>>> + >>>>>> +       ret = dm_timer_init(); >>>>> >>>>> I don't think you can call this if you want to support bootstage, >>>>> since driver model may not be inited. >>>> >>>> Yes, thanks for noticing. Still, this code is copied from the original >>>> timer_get_boot_us() function in this driver. Which also has problems >>>> with early timer access AFAICT. >>> >>> Yes, good point. >>> >>> Reviewed-by: Simon Glass >> >> I looked at it and kind of interesting code. For getting this working with >> this whole series if ttc gets u-boot,dm-pre-reloc everthing is working fine. > > Yes, makes sense that this is needed. > >> diff --git a/arch/arm/dts/zynqmp-r5.dts b/arch/arm/dts/zynqmp-r5.dts >> index a72172ef2ea4..8059931f2162 100644 >> --- a/arch/arm/dts/zynqmp-r5.dts >> +++ b/arch/arm/dts/zynqmp-r5.dts >> @@ -56,6 +56,7 @@ >> >>                  ttc0: timer@ff110000 { >>                          compatible = "cdns,ttc"; >> +                       u-boot,dm-pre-reloc; >>                          status = "okay"; >>                          reg = <0xff110000 0x1000>; >>                          timer-width = <32>; >> >> What I see based on behavior. Every bootstage call is asking for >> timer_early_get_count() and because dm_timer_init() is failing 0 is returned. >> >> Inside initf_dm() dm_init_and_scan() is called and initialized timer uclass >> also with timer instance. With u-boot,dm-pre-reloc also cadence timer driver. >> On the next dm_timer_init() gd->timer is initialized and value is returned and >> initf_dm() passes. > > This "early" implementation of the counter is broken, as you have > noticed above. Resulting in timer functions only returning valid > values after dm_timer_init(). This timer driver needs re-written > early_timer functions, that will return proper timer values even in > the early boot phase. Please take a look at e.g. rockchip_timer.c, > perhaps something similar works for the cadence timer driver as well? I looked at it and there is a code when OF_REAL is enabled. If not then 0 is returned. That's why I can't see any difference between rockchip and cadence when OF_REAL is not enabled. And not sure how this is working in rockchip case. Who is starting timer in their case? I see start when probe happens but after it dm_timer_init() should return 0 and value can be obtained. > >> Here is the log and output from bootstage. >> >> U-Boot 2022.10-rc5-00130-g1be5bed207c9 (Sep 30 2022 - 14:00:08 +0200) >> >> Model: Xilinx ZynqMP R5 >> DRAM:  512 MiB >> Core:  7 devices, 7 uclasses, devicetree: embed >> MMC: >> Loading Environment from nowhere... OK >> In:    serial@ff010000 >> Out:   serial@ff010000 >> Err:   serial@ff010000 >> Net:   No ethernet found. >> ZynqMP r5> dm tree >>   Class     Index  Probed  Driver                Name >> ----------------------------------------------------------- >>   root          0  [ + ]   root_driver           root_driver >>   clk           0  [ + ]   fixed_clock           |-- clk100 >>   simple_bus    0  [ + ]   simple_bus            |-- amba >>   timer         0  [ + ]   cadence_ttc           |   |-- timer@ff110000 >>   serial        0  [ + ]   serial_zynq           |   `-- serial@ff010000 >>   bootstd       0  [   ]   bootstd_drv           `-- bootstd >>   bootmeth      0  [   ]   bootmeth_distro           `-- distro >> ZynqMP r5> bootstage report >> Timer summary in microseconds (8 records): >>         Mark    Elapsed  Stage >>            0          0  reset >>            0          0  board_init_f >>            0          0  dm_f >>            0          0  dm_r >>       16,319     16,319  eth_common_init >>       18,061      1,742  main_loop >>       18,281        220  cli_loop >>       29,249     10,968  board_init_r >> >> Accumulated time: > > Take a look at sandbox - here you will get proper early timing values > as well: I expect early functions are called before DM is ready that's why to get it work that early we would have to start timer on the first call of early function. It is definitely doable but is it worth to do it? Is there any other use case where early timer counts are needed other then bootstage? Thanks, Michal