Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933646AbbFVMx7 (ORCPT ); Mon, 22 Jun 2015 08:53:59 -0400 Received: from gloria.sntech.de ([95.129.55.99]:57038 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933420AbbFVMxu (ORCPT ); Mon, 22 Jun 2015 08:53:50 -0400 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: James Liao Cc: linux-mediatek@lists.infradead.org, Eddie Huang , Matthias Brugger , devicetree@vger.kernel.org, Sascha Hauer , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, djkurtz@chromium.org Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null Date: Mon, 22 Jun 2015 14:53:38 +0200 Message-ID: <8860488.JuX1EN5tWB@diego> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <1434944317.25948.8.camel@mtksdaap41> References: <1434605351-64592-1-git-send-email-eddie.huang@mediatek.com> <8371528.SNAmOgosfF@phil> <1434944317.25948.8.camel@mtksdaap41> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3075 Lines: 74 Hi James, Am Montag, 22. Juni 2015, 11:38:37 schrieb James Liao: > On Fri, 2015-06-19 at 13:36 +0200, Heiko Stuebner wrote: > > Am Donnerstag, 18. Juni 2015, 18:15:03 schrieb Heiko Stuebner: > > > Am Donnerstag, 18. Juni 2015, 13:29:11 schrieb Eddie Huang: > > > > Add clk_null, which represents clocks that can not / need not > > > > controlled by software. > > > > There are many clocks' parent set to clk_null. > > > > > > Devicetree is supposed to describe hardware, and ideally not what > > > software > > > does with it. If the clock simply cannot be controlled by software, it > > > will > > > still have a rate and I think it should probably be modelled - similarly > > > we > > > sometimes have fixed regulators that also are not software controllable. > > > > > > > > > While it might be ok to define dummy clocks as a temporary stopgap, > > > these > > > should definitly be marked as such. This clk_null at least sounds like > > > there is no plan to replace this with a real solution at some point. > > > > > > And of course a bit of context would be cool, to know which type of > > > clocks > > > this actually replaces. > > > > After looking a bit more into this, I'm feel that the clk_null approach is > > wrong. > > > > For one, even if the clk_null stuff would be ok, the binding doc of the > > clock controller does not describe the need of this specific clock at > > all. > > > > > > The other more important point, looking at clk-mt8173 I see at least these > > clocks being set as children of "clk_null": > > > > static const struct mtk_fixed_factor root_clk_alias[] __initconst = { > > > > FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1), > > FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1), > > FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1), > > FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1), > > > > }; > > > > > > These look more like they are fed from some external source to the clock > > controller? I did ask Matthias but he also couldn't find anything > > describing where these clocks actually come from. > > Some clocks such as clkph_mck_o, we don't really care where they come > from and what frequencies are. We model these clocks just because they > or their derived clocks can be the source of topckgen muxes. Is there a > better way to model "don't care" clocks? There are two different concepts at work here. You might not care in your kernel driver implementation _at the moment_ where the clocks come from; but the devicetree is supposed to model how the hardware is structured and not contain implementation specific details. So the clock tree should be modeled according to how the hardware is layed out not how you want to use the clocks at the moment :-) . It would it any case be good, if you could describe where these clocks come from in the hardware, so we can find the best solution on how to model those. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/