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 X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3932FC43603 for ; Wed, 18 Dec 2019 09:29:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 076AF21582 for ; Wed, 18 Dec 2019 09:29:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="M0503mgO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726802AbfLRJ3S (ORCPT ); Wed, 18 Dec 2019 04:29:18 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:54430 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725799AbfLRJ3R (ORCPT ); Wed, 18 Dec 2019 04:29:17 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id xBI9SFbt030551; Wed, 18 Dec 2019 03:28:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1576661295; bh=iGk7YRT+kPnqstyHZEl2eYWpUaNqZx8s0Pjx38SCwGo=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=M0503mgOmC+63+lhfjTAtturSJzFirhFDnzpQjn4VuFPV9r/pRlTAzS2AQKuysbEV WVUzj8nTNILNsZJmzW7LJf62u6tY3T9krMHZ3Yvak26fJ83EO0ajFVxVX1ua68asny 47Zc1haxMdZHMJ7LD5Xf6xJyf90PZ9aXphTaOfSE= Received: from DFLE114.ent.ti.com (dfle114.ent.ti.com [10.64.6.35]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id xBI9SFxW120738 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Dec 2019 03:28:15 -0600 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Wed, 18 Dec 2019 03:28:15 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Wed, 18 Dec 2019 03:28:15 -0600 Received: from [10.24.69.35] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id xBI9S8be074543; Wed, 18 Dec 2019 03:28:12 -0600 Subject: Re: [PATCH 1/3] clocksource: davinci: work around a clocksource problem on dm365 SoC To: Bartosz Golaszewski , Daniel Lezcano , Thomas Gleixner , David Lechner , Kevin Hilman CC: , , Bartosz Golaszewski References: <20191213162453.15691-1-brgl@bgdev.pl> <20191213162453.15691-2-brgl@bgdev.pl> From: Sekhar Nori Message-ID: <51eb10e9-245e-7b3e-51ff-578e06e0759b@ti.com> Date: Wed, 18 Dec 2019 14:58:07 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191213162453.15691-2-brgl@bgdev.pl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bart, On 13/12/19 9:54 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The DM365 platform has a strange quirk (only present when using ancient > u-boot - mainline u-boot v2013.01 and later works fine) where if we > enable the second half of the timer in periodic mode before we do its > initialization - the time won't start flowing and we can't boot. > > When using more recent u-boot, we can enable the timer, then reinitialize > it and all works fine. > > I've been unable to figure out why that is, but a workaround for this > is straightforward - just cache the enable bits for tim34. > > Signed-off-by: Bartosz Golaszewski Timer Global Control Register (TGCR) has bits to reset both halves of timer. Does placing both halves in reset, waiting a bit (say 10ms) and then taking them out of reset help solve the this problem? Also, there are LPSCs controlling the timers. As an experiment, can you see if using LPSC_STATE_SWRSTDISABLE instead of LPSC_STATE_DISABLE in davinci_lpsc_clk_disable() and then doing a clk_disable() + clk_enable() on timer can get the timer out of this bad state. We need some way for Linux to start on a clean state after bootloader is done. And trying to reset the timer before use seems to be a better way to accomplish it. I assume the original code was just lucky in not hitting this case? Thanks, Sekhar