Received: by 10.223.176.5 with SMTP id f5csp472658wra; Fri, 2 Feb 2018 00:40:58 -0800 (PST) X-Google-Smtp-Source: AH8x2267LNi24CNMf6ndzbi5l62jsO1AQUE41eG7gbuq8Z6wQQk5hjKoo4K5CyNDAvFEBvNlglbu X-Received: by 10.99.126.84 with SMTP id o20mr30767118pgn.329.1517560858380; Fri, 02 Feb 2018 00:40:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517560858; cv=none; d=google.com; s=arc-20160816; b=nX33ut3rdH1WEYzrmO2fa0D0iqT16OE4RyItsQakA3HoB8x85Z5d90jh3OwmDrluUM v/o5kx7wddaRL+ldGl6Ww8hV35f77m7SGoa2TNr19YCqKfsiNrW+oQuHb3aMV+wPeoMm OKAVnqe9YijQPbZu3P+rwAZ0fWH46wjYMzsDdIYoMYLp9e6USG4pBEJzAI1TK3w7jvXB MVGeDJR8TbdJcQqJoKn41GkfmJHS0SR11l2/w9LkDqHUfyf7R8GJj1je5q1/ahMlaaAJ qu8y8BcgtazcMvjJA5mZ066Ju35z0YVdn9j6PZtZJFuYhVjC+YecrfsoeDZVDxED+g6K e66A== 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=dOlngk/oijgu8imDNaaAMGmzPvL6qRRTmeJGycWzzxE=; b=BMAHqodl3Uv1zUFFDvPIWiA5HiIZYOvaDNDni/ZQXr3k+BBsYjB/dcqH8SZRM6RKHp i3GbXKH63I4lYDBmTXQepZ+xh6LG/guPhlWl44ku8hupRFiUA4SvTi1S0U/TJQLno5DH 7OHLYSPkYcsryOFFf108DrOs4mTgcjSOMvF7Fa4OqfzGWbbq3EFxM8mfdudGVId5HCdx BtLG+O+R3sTxysBqwkTV1bRhKXWH6NqC1ERTI81OXstQhC7z/mUoR9idnJanOTE7kj3A Ci0mubJTPg64Vhg9Y2RiololuyB+u1xNEid+EVnS6/g1BOoDei1T/cJpZpsByGJII38X Q7EQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=S8zQAYwd; 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 y5si1319295pfl.267.2018.02.02.00.40.43; Fri, 02 Feb 2018 00:40:58 -0800 (PST) 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=S8zQAYwd; 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 S1751856AbeBBIiu (ORCPT + 99 others); Fri, 2 Feb 2018 03:38:50 -0500 Received: from lelnx194.ext.ti.com ([198.47.27.80]:25462 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750795AbeBBIil (ORCPT ); Fri, 2 Feb 2018 03:38:41 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id w128bcwh011243; Fri, 2 Feb 2018 02:37:38 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1517560658; bh=UjdiToYeRr65q29napWDv4AXSAj3Fo0Nrqc0gYOzyiQ=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=S8zQAYwdOy6i9xWkxOiNJzfsx9f0xGWVXnQ+Ni98UykAz+M+rbJ1jSM8Dzge4oeB7 OxV3hhV0OxYtf7tcqGScqnDFq+CV4ROqDEI9hqLYyRiYOPcyTwQEbYDKbz4w6vVJCq eV93TF/yjYzAoYDjoN9zVrKXTusr7IIvKqXgBIMA= Received: from DFLE105.ent.ti.com (dfle105.ent.ti.com [10.64.6.26]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w128bcvP021641; Fri, 2 Feb 2018 02:37:38 -0600 Received: from DFLE100.ent.ti.com (10.64.6.21) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 2 Feb 2018 02:37:38 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Fri, 2 Feb 2018 02:37:38 -0600 Received: from [172.24.190.171] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w128bVAt015380; Fri, 2 Feb 2018 02:37:32 -0600 Subject: Re: [PATCH v6 04/41] clk: davinci: Add platform information for TI DA850 PLL To: David Lechner , , , CC: Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Kevin Hilman , Bartosz Golaszewski , Adam Ford , References: <1516468460-4908-1-git-send-email-david@lechnology.com> <1516468460-4908-5-git-send-email-david@lechnology.com> <7d7e0522-30d5-6232-853e-7ab32fadfe48@lechnology.com> From: Sekhar Nori Message-ID: Date: Fri, 2 Feb 2018 14:07:31 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7d7e0522-30d5-6232-853e-7ab32fadfe48@lechnology.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit 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 02 February 2018 12:52 AM, David Lechner wrote: >> +static const char * const da850_pll1_obsclk_parent_names[] >> __initconst = { >> +    "oscin", > > Re: the issue of "ref_clk" vs. "oscin"... > > This is one of the places where having the otherwise unnecessary "oscin" > clock > really helps out. The PLL driver doesn't control "ref_clk" - it comes > from somewhere > else. And in the case of DT, it may not even be named "ref_clk", so we > really > don't want to hard-code the name "ref_clk" here. TBH, I don't really see what is wrong with mandating the name "ref_clk" as the reference clock name to be provided. And for all board-files and DTs to supply the same name. > If we have to allow a variable name here, it just makes more work in the > driver > shuffling names around. > > And the name "oscin" totally makes sense here because the TRM lists this > input to the > mux as "OSCIN". Fine with me if you feel it simplifies implementation for you (and also because of the distinction you want to make between the external "before CLKMODE" clock and internal "after CLKMODE" clock). What I do care about though is: a) In the DT case, ability for different boards to provide different ref_clk frequencies. We never really had this in the legacy board file way (except some rudimentary support on DM6467T). And its fine to continue with status quo for board files. b) In the DT case, ability for board to specify whether it uses the on-chip oscillator or has an external clean clock provider. >> +void __init da850_pll_clk_init(void __iomem *pll0, void __iomem *pll1) >> +{ >> +    const struct davinci_pll_sysclk_info *info; >> + >> +    davinci_pll_clk_register(&da850_pll0_info, "ref_clk", pll0); > > And really, we probably shouldn't be hard-coding "ref_clk" here either. > Basically, we are making the assumption that the board file has registered > a clock named "ref_clk". It would probably be better to pass the name > as a parameter. As I noted before, I am not sure if this level of naming flexibility is needed. Every board needs to have one anyway. They might as well call it by the same name. That said, I wont oppose it either if you decide to have that flexibility. Thanks, Sekhar