From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Liao Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null Date: Thu, 2 Jul 2015 11:06:19 +0800 Message-ID: <1435806379.3526.31.camel@mtksdaap41> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Daniel Kurtz Cc: Sascha Hauer , Heiko =?ISO-8859-1?Q?St=FCbner?= , "open list:OPEN FIRMWARE AND..." , Mike Turquette , Stephen Boyd , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, ted.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org, Matthias Brugger , Eddie Huang , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org 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 devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html