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 93807C433FE for ; Wed, 5 Oct 2022 06:59:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4AAF584E2B; Wed, 5 Oct 2022 08:59:30 +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="YRgh3IPB"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 433B184E09; Wed, 5 Oct 2022 08:59:28 +0200 (CEST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2044.outbound.protection.outlook.com [40.107.237.44]) (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 9971D84E2B for ; Wed, 5 Oct 2022 08:59:23 +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=LZ8LCPY8zu2Ailg4wVc9GUdlfUkgxeYeAWVUzJ3aSCau/V52E04/QMdWMNHvyRZNCGUPFAhnsWIOV8X2zGIV3ixDEHh1OHGXT7cr/6gXnPOgRyxAPXxEbiNxS8zP3mOYGqKw4pnw+OOp2gGPpLuZFDXUMQ/uQJzGYhPwO9QB+KX9GUmHzCo23wykhjT3e62XJrvevb3ttuHhzslgg4T6e6zgDkY8Ap+gnmLeAlFQxUK1Cg4H7AptcsY6JBAWDpxkdnEyogn2fQxSngFWOAZ3TpOJMpXyUCkz0dzWus1K4QoJTsD+PbYlVBdeUCF9UBhMkofTCQyO0s/l54bUYhx9/g== 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=HKB/XTtkM7OXxy69Cfa5G2Oknyesjk9LMAmAgP03Fc4=; b=moJi9SSkjBesHgzdnI31eQMbMhCUTNXO022DbiQTA6NviyPZtvR6lWpemEEGcGExZT7ENUsvm5IT4Rpz7GFUTHsCnijVmVKdyiW9Tw4TFFPCWkPc4t/7OX4WBX8JNYYeWreR/LDLj6WNuVhJV56dXAQ2MozimqzS3KxA5y4QMJGiHpMjIwr7sV+WodE8PwddG1SfvuFyaDW4FfmcXXF21oOKwuqueLvihuRto+vxiOqlO0UnAvn8oTHee31cusbUhAuLv7/81cus+cf5IWS7iN2pcnZfygKwRyf5v4sQ5zpfMXg46gDGAvrQdY3ijRdAP+1N6d3d7VzY9QJhBgV3gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=chromium.org 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=HKB/XTtkM7OXxy69Cfa5G2Oknyesjk9LMAmAgP03Fc4=; b=YRgh3IPBDxG67BzuW553MNwRCrQhUaRUSBg0f66Zxie+gBJBQYOXoES9BugJFznEQkKMMQO/uSMt1OPHZJfnHggn6zJDgdt0RvHoOO2brO5ZhucDb/0NYBhHL3qNLPWaQU6EXnz/hvaL8IcvfbWO7IfITe6Anz5Ue24d+1Q0yto= Received: from BN1PR14CA0018.namprd14.prod.outlook.com (2603:10b6:408:e3::23) by MN0PR12MB6080.namprd12.prod.outlook.com (2603:10b6:208:3c8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.24; Wed, 5 Oct 2022 06:59:20 +0000 Received: from BL02EPF0000C409.namprd05.prod.outlook.com (2603:10b6:408:e3:cafe::d5) by BN1PR14CA0018.outlook.office365.com (2603:10b6:408:e3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.29 via Frontend Transport; Wed, 5 Oct 2022 06:59:20 +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 BL02EPF0000C409.mail.protection.outlook.com (10.167.241.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5676.17 via Frontend Transport; Wed, 5 Oct 2022 06:59:19 +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; Wed, 5 Oct 2022 01:59:17 -0500 Message-ID: <89fa326f-9962-7487-2373-898b8017dcdf@amd.com> Date: Wed, 5 Oct 2022 08:59:15 +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: Simon Glass CC: Stefan Roese , 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: 7bit 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: BL02EPF0000C409:EE_|MN0PR12MB6080:EE_ X-MS-Office365-Filtering-Correlation-Id: 5168be28-4939-4456-7079-08daa69f206e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 65RyOYxu9ev6a1MFES5iAfM42uyvh0Rg8m4yZfd6x2a/X6TFqPMAguuWTB/48oOlmTaONJVAo91Bo9KmFRPMpH0yC0ucGRtvOWoBNLh5lIs149IQ+wJ38112cHCNe8fp9DJi3ZsbHnwnKKaVY4rwmAhKVAVymFoutpgWa8vCMwrczN7s+vkAPWBLFerWXwmA+xQdPQ+63X7JlA4b+9NQrDVX+G/XQo3tApR+AC50vCI35eb6RYhkg4QPoe95O6NTW9vOcBVYCiD0hUJcgVP4DyZa9GwPrf2zM9LceuZtfHsgKtlwZLG7j4bJrhiRuu45wiw7O4YKBspMedpWfIA5b5voo1sdsMwB5zj7P6ilkZdpxa8qsPBaSMUE3FsCELWK5x1VUoIordFjwXxlZgSl/n+77k/Ee8wrf5sy+8JZhestQ3btC2O6EZls9DOrkKlycNT7Rh2kRnfaWWmwGunH7oTbkMyaqHE9vijvpCV64W1FWqgvlZ1O/hNOCb27MJHHQFgK6SwDX3ra7kY3MlPUdHEOk65qXVg0cbnNtHUi2NB5N18f9Sy3nhBJhZK04DFQQ8Ev3pmkvT3K9nTcTtCQhIVarOZ0NLZWfTRlGiwZJsqI0bv+RsdUKMmGPQyz65x6rLtOc+Cn6WT5w4ocwS7lhzEI3jHe5wX3TJdAVWkjgfxzxSHuEfeh22gbFognIgxuMImNFFMgFW1vt+/ax0HFe1heNkVHVBAgcqzDzq2whQFoR4yqpObOyTzVKuEF+YCugC1/JrybB+FZ0YjT7FDv+vuD5H5gV2Aou3pelki3XKYmdEW/hjUewucSZtaU3FhDKc/8dUAC+H7xwapw1qZK5kuvkq0DIITAAiaQ6hSEFJs= 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)(396003)(136003)(39860400002)(346002)(376002)(451199015)(36840700001)(46966006)(40470700004)(186003)(16526019)(47076005)(31686004)(336012)(53546011)(426003)(356005)(82740400003)(6916009)(44832011)(82310400005)(5660300002)(41300700001)(4326008)(54906003)(31696002)(36756003)(26005)(70206006)(8936002)(2906002)(70586007)(86362001)(478600001)(83380400001)(8676002)(16576012)(40460700003)(316002)(36860700001)(40480700001)(2616005)(81166007)(21314003)(36900700001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2022 06:59:19.9684 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5168be28-4939-4456-7079-08daa69f206e 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: BL02EPF0000C409.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6080 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, On 10/4/22 18:29, Simon Glass wrote: > Hi, > > On Tue, 4 Oct 2022 at 05:50, Michal Simek wrote: >> >> 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? > > Here is how it should work, I think: > > static void notrace ensure_timer_setup(void) > { > // set up the timer if not already done > // avoid using any DM functions > } > > static u64 xx_get_count(void) > { > // read and return the timer counter > } > > u64 notrace timer_early_get_count(void) > { > ensure_timer_setup(); > return xxx_get_count(); > } > > static u64 xx_timer_get_count(struct udevice *dev) > { > return xxx_get_count(); > } > > int xxx_timer_probe(struct udevice *dev) > { > ensure_timer_setup()\; > > return 0; > } ok this is clear and understandable. As far as I see the only information we need is to have address where timer is. Rockchip and uclass drivers are using tick-timer when multiple timers are described in DT. That's why for systems with only one timer this property is not needed. Also this option is enabled only when OF_REAL is enabled. When it is clear which link to use for getting address from DT or via DM we can change drivers pretty easily. Thanks, Michal