Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbbGBDHQ (ORCPT ); Wed, 1 Jul 2015 23:07:16 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:59041 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751932AbbGBDHM (ORCPT ); Wed, 1 Jul 2015 23:07:12 -0400 X-Listener-Flag: 11101 Message-ID: <1435806379.3526.31.camel@mtksdaap41> Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null From: James Liao To: Daniel Kurtz CC: Sascha Hauer , Heiko =?ISO-8859-1?Q?St=FCbner?= , "open list:OPEN FIRMWARE AND..." , Mike Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , , , Matthias Brugger , "Eddie Huang" , "linux-arm-kernel@lists.infradead.org" Date: Thu, 2 Jul 2015 11:06:19 +0800 In-Reply-To: References: <1434605351-64592-1-git-send-email-eddie.huang@mediatek.com> <8860488.JuX1EN5tWB@diego> <1435132455.28866.21.camel@mtksdaap41> <1510058.fTE6dlSRsH@diego> <1435655229.19330.15.camel@mtksdaap41> <20150701064935.GC18611@pengutronix.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1949 Lines: 50 Hi Daniel, On Wed, 2015-07-01 at 19:54 +0800, Daniel Kurtz wrote: > On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer wrote: > > The problem is not that you use fixed clocks for non software > > controllable clocks of unknwown rates, but that you try to use a single > > clock for all of them and name it 'dummy' or 'null'. Name it > > > > dpi_ck { > > compatible = "fixed-clock"; > > rate = <0>; /* unknown, generated by some Analog block */ > > }; > > It would be nice, though, to use the real clock rates. > Otherwise, we end up with a bunch of unknown clock rates, like this: > > clock enable_cnt prepare_cnt rate > accuracy phase > ---------------------------------------------------------------------------------------- > clk_null 2 2 0 > 0 0 > mm_lvds_cts 0 0 0 > 0 0 > mm_lvds_pixel 0 0 0 > 0 0 > mm_dpi1_pixel 0 0 0 > 0 0 > Furthermore, at least some of these children clocks are possible > source clocks for other clocks for which we do want to know the > resulting frequency. For example, the "dmpll_*" clocks are mux inputs > for many of the subsystem clocks. These clocks such as clkph_mck_o are configured by other modules before kernel init, and their rates may different among platforms. So we can't use a hard-coded rate for them. And we also don't care the actual rate of these clocks, so assign a dummy rate such as 0 to them should be a better way. Best regards, james -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/