From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751374AbcGOIHH (ORCPT ); Fri, 15 Jul 2016 04:07:07 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:56909 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750963AbcGOIGz (ORCPT ); Fri, 15 Jul 2016 04:06:55 -0400 From: Arnd Bergmann To: Michael Turquette Cc: John Stultz , Olof Johansson , lkml , "arm@kernel.org" , Stephen Boyd , Rob Herring , Pawel Moll , Wei Xu , Guodong Xu , Zhangfei Gao Subject: Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Date: Fri, 15 Jul 2016 10:06:32 +0200 Message-ID: <1736252.WAIVArieDJ@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <146794451180.73491.16184621585178119543@resonance> References: <1467247725-3665-1-git-send-email-john.stultz@linaro.org> <4270415.JTHdGZyKEo@wuerfel> <146794451180.73491.16184621585178119543@resonance> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:mEh5LgfX5RrwF6Iuxof0E2Fe6t8LHNFcm57dPecsqEWkXYwshi1 YeULm83eW/TGj4//HC4iCSkNaIjJrxzE5pIztS2NOFywa1EKwbX9/5rTiVAnN+zinABEov1 wLmOuHX6vaBcNI0XzTGeW1k14f3NX0TCe0sRarPufD5uKs6DbLlwc3eU07R6Ha+3dpSI9yB dtbMfPa2G0jfXx8kbpprg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gmBZVCrLLSI=:qYn7URg66mSn7jGVyj5Hsg rQChEiDRotJfmEbMDI+/+h3ZVWGVlh4tHzwiyVtwiSp1Vd2Fq9Ao5Dmex2VXWgaIlklFCkwB9 kVpsZOKdHb7at0LuB/5c4mRcgnlKB2gybQuG3fYRVOBDRDT4hrP8yjmaBqfSx2itv1wl/EAoi tetwwpTwC1ZaRk0GBMMuFrzQtZsFgbJg9TfU0LhXfRZBJr8xWHfzqHBRUCZRhiQ22aGRkW1Ec h0yEF06alERI69Y6bkWkO0Cpn/Za4o6Rc0yOFDFb6swb4XkWX3gX2PgXq+/SQM70R8UEfwhV9 dXELncrPjj2C/Pop9uDW7tv8W2+GobUBAqSmfg/2Z+eJuS2iujfk9Za3U9xZr+mmw+j9Gd7rn vCcmF4vfHHHkPdG1gP/jrPXcDrZuAYXgNMOiQzeZWGuet5LEM+qHPf0OVV40ET0I/498RSDe7 +K1p7ADC8Ls0ycKgb7szlqh36nuoR3hU7nzdbNbM+r89CU9tJKbd+ycAcAuKd7ajzjTSm9Pnu 8gLHUcweOf6gPEmzeYtS60Fsibp9nM393oZQ1TR/Ap+3qfkD2lMu7IVjfnKRtPQ5T20VYQIFL FNRQ81wnI3/UgpirC+DF1rrOMDze3XkKPjTijH5ERpSOD3iBeJbOkZfXd6T+DVDE090eE0p6i FouNoWP0mMNZZ5so/aOG4Uvh3Ir5MeTZ7iapIXkF1+BsbzfUcscDiCxuRrJ9pD71BHBGir0p8 0God+bRF8k97bMEA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, July 7, 2016 7:21:51 PM CEST Michael Turquette wrote: > Quoting Arnd Bergmann (2016-07-07 01:22:30) > > On Wednesday, July 6, 2016 5:58:14 PM CEST John Stultz wrote: > > > > We typically have it easier for other subsystems like irqchip or gpio > > where nobody would consider writing a driver that can only handle > > the I/O lines that are used on their board with a minimal set of > > drivers, but for some reason it seems acceptable to do it for clock > > controllers just because they are harder to describe. > > gpio and irqchip are interesting analogues. It makes pretty good sense > to expose all of those lines via DT, since those are resources that > consumer drivers may be interested in. But is the same true for clock > signals? > > Clearly drivers will care about their input clocks, which are often leaf > gates. But the mess and tangle of "root" and "branch" clocks above that? > Why expose it to DT if we don't need to? These are resources that are > often internal to the clock controller IP block. In an ideal world we > would never need to provide a way for clock consumer drivers to get at > these root and branch clocks, just the peripheral leaf clocks. > > As an example of this, ccf has tried to be smart about propagating rate > requests up the chain of parents since it was originally merged, and > that directly has led to lots of consolidation around the cpufreq-dt.c > driver, where a single leaf clock can ultimately affect a PLL or > post-divider without the cpufreq driver needing to know the details of > the clock hierarchy internal to the clock controller IP block. > > (in reality we do need to expose root and branch clocks for drivers some > times, but I disagree that we should expose every single clock signal > just because it is there) (sorry for coming back to this late) I still don't fully understand how we ended up with the missing clk in the specific example here, but it seems to me that what was missing here is indeed a leaf clock, not one of the clocks above it. This is a simple gate that is controlled by a bit in the same register as a number of other clocks, so if I understand you right, it should have been there even if we don't want to expose the internal clocks, correct? Arnd