Received: by 10.213.65.68 with SMTP id h4csp1865139imn; Thu, 5 Apr 2018 05:15:31 -0700 (PDT) X-Google-Smtp-Source: AIpwx491brLCcxuImm7usoM93mW7/E5JD45MDB17X/6ye7NySq9NHONa152riOT24UOqKsQEjIRQ X-Received: by 2002:a17:902:8c93:: with SMTP id t19-v6mr22593833plo.301.1522930531739; Thu, 05 Apr 2018 05:15:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522930531; cv=none; d=google.com; s=arc-20160816; b=txRwV1AvtOM8+sxDlGFEtpOpohcyVGjSMC+ReJw6REq19lTukbB3B9VA774E4TTXay pewvP/izZK4aGKKg48HAZH07mRIB73ZCNNtT9cPlNRUnYQF0NRcWpLkbWvhxfDH1oCQy eBiXgC5IB+HOScGw1Fa0nP6EdKRsO71tGw8FCMraiWxRmc79Hzq4wqoWQPmPU+vV+65s d6sLDuO0K5mPkS9qwnvCAl7AExxUW1ImlZXwLRGGB+CNDKTB1qJGruxRGqN2M1jUFmw5 NQPOUNglfP+7td0c7n5O37RXM6tiSZMEv6/3cac42/RYBO6U4HtYMP1tx+zqIERjh76U nXVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=QgLaMfdSBvXUR29zZWwfrE5sNzyJGca1bSclh36EDyo=; b=WQSq9D/7jwzVvW19Jqb3IilfRSw+i0F68DVtosUSQmGwVqGDV8dTi/Bds+b8s9xF4e jAmnBSPCmTEYFrUCkyV/V0CqknULlX9l6b90UQFuC/LvJ+qBSENCqQ3DiBGAkJQHlLG4 S2YJNJJvoeX4R6g2egLsLaAKcwgRyn3cipfsBlrVQpSMjjrCxvoE99jM9nUyNCI7MHGO rWwCdyCfzXlbp1x8MecVM9/MvN9xOEJTyvQBJCyGteyYFwotVpyhGZsEjeBKaF73qWXp KzzKm8v/S9si0UxY11cnDLcL8ZO6TAj5GB+YKSTx1Bv7wuVPe2MLUs9DjHaVcC4H4tJw OHSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=k4HmPuqJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c76si5409138pga.156.2018.04.05.05.15.17; Thu, 05 Apr 2018 05:15:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=k4HmPuqJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751314AbeDEMOJ (ORCPT + 99 others); Thu, 5 Apr 2018 08:14:09 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:16976 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbeDEMOH (ORCPT ); Thu, 5 Apr 2018 08:14:07 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id w35CCwP5001463; Thu, 5 Apr 2018 07:12:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1522930378; bh=LWZ6RGmB7GWtC2bZDtp5reR69ygdFNE9zOZrVjW2QJ4=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=k4HmPuqJcebz9trd1wQFBuI9AO2SNLA8q0tzNL4tMHsfUmqxeDJ8aV87gWXpNhYrH yaonBr+5JL4AMHhj3+WxEAbI6dgG656jLsZWoRrkawPEhHdUZD/UrQOcGahux2nUsV XD5fA1zvKJ73Xf6NSAKBSvTkdm1PVaur2ASpm2v4= Received: from DLEE110.ent.ti.com (dlee110.ent.ti.com [157.170.170.21]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w35CCwaD000566; Thu, 5 Apr 2018 07:12:58 -0500 Received: from DLEE103.ent.ti.com (157.170.170.33) by DLEE110.ent.ti.com (157.170.170.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 5 Apr 2018 07:12:58 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Thu, 5 Apr 2018 07:12:58 -0500 Received: from [172.24.190.172] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w35CCp96011926; Thu, 5 Apr 2018 07:12:52 -0500 Subject: Re: [PATCH v8 20/42] ARM: davinci: pass clock as parameter to davinci_timer_init() To: David Lechner , , , CC: Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Kevin Hilman , Bartosz Golaszewski , Adam Ford , References: <1521168778-27236-1-git-send-email-david@lechnology.com> <1521168778-27236-21-git-send-email-david@lechnology.com> From: Sekhar Nori Message-ID: <43434ed4-162c-cb39-70ef-a458e3999f8b@ti.com> Date: Thu, 5 Apr 2018 17:42:51 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1521168778-27236-21-git-send-email-david@lechnology.com> 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 On Friday 16 March 2018 08:22 AM, David Lechner wrote: > This changes davinci_timer_init() so that we pass the clock as a > parameter instead of using clk_get(). This is done in preparation > for converting to the common clock framework. > > It removes the requirement that we have to have a clock with con_id > of "timer0", which will be good for DT bindings since clock-names = > "timer0" doesn't really make sense. > > Additionally, when we convert to the common clock framework, most of > the clocks will be platform devices, which will not be available at > this point during the boot process, so we will need to pass a clock > that is available (i.e. ref_clk) instead of the "timer0" clock. > > NB: The comment added in time.c is not entirely true when this patch > is applied, but it will be correct once the conversion to the common > clock framework is complete in subsequent patches. I think its better to add the comment when its actually applicable, even if it needs to be a separate patch. > > Also, drop use of extern in header file since we are touching the > definition. > > Signed-off-by: David Lechner > - > -void __init davinci_timer_init(void) > +void __init davinci_timer_init(struct clk *timer_clk) > { > - struct clk *timer_clk; > struct davinci_soc_info *soc_info = &davinci_soc_info; > unsigned int clockevent_id; > unsigned int clocksource_id; > @@ -373,7 +371,14 @@ void __init davinci_timer_init(void) > } > } > > - timer_clk = clk_get(NULL, "timer0"); > + /* > + * REVISIT: Currently, timer_clk will be "ref_clk". However, the actual > + * clock for this device comes from a PLL AUXCLK or a PSC clock > + * (depending on the SoC). The PLL and PSC clocks are not registered > + * until later in boot because they are platform devices. We should try > + * again later to get the real clock so that the real clock is not > + * turned off when disabling unused clocks, which would stop the timer. This disabling later should not happen because you have the timer clocks marked as LPSC_ALWAYS_ENABLED which translates to CLK_IS_CRITICAL and that should make sure they are never disabled. The issue should be documented is that we depend on bootloader leaving the timer0 enabled on DM355, DM365, DM644x and DM646x. Of these, I have tested only DM644x so far. I will check others and see the status of timer0 there. Its not really a great situation here, but I don't have a good alternative to suggest as well if having genpd support in PSC means we cannot be using CLK_OF_DECLARE(). Thanks, Sekhar