Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755120AbbGELTt (ORCPT ); Sun, 5 Jul 2015 07:19:49 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:65382 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751371AbbGELTk (ORCPT ); Sun, 5 Jul 2015 07:19:40 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Thomas Gleixner , Paul Osmialowski , Mark Rutland , Nicolas Pitre , Linus Walleij , Rob Herring , Alexander Potashev , Jiri Slaby , linux-clk@vger.kernel.org, Russell King , Vinod Koul , Geert Uytterhoeven , linux-serial@vger.kernel.org, Uwe Kleine-Koenig , Anson Huang , Michael Turquette , devicetree@vger.kernel.org, Frank Li , Pawel Moll , Ian Campbell , Jingchang Lu , Yuri Tikhonov , linux-gpio@vger.kernel.org, Rob Herring , Sergei Poselenov , Paul Bolle , Greg Kroah-Hartman , Stephen Boyd , linux-kernel@vger.kernel.org, Kumar Gala , dmaengine@vger.kernel.org Subject: Re: [PATCH v2 3/9] arm: twr-k70f120m: clock driver for Kinetis SoC Date: Sat, 04 Jul 2015 21:54:12 +0200 Message-ID: <2009463.YLtdMegFel@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1435667250-28299-1-git-send-email-pawelo@king.net.pl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:CRSxE9ZqDKRk/ElQjXWzTvK7C1WPOl156gtokxNOHGUGRnsYI7L uKuTcA5A6ApXaiU0Wz39tIqVmlOE8DCpEW/zdt4oMohDiVy6Jb1ZcXxrOGnwmyeUhoZ51n1 qxNvZEJjMNBYzuKuECMdrFW2Jfj4tVRGUpm/1jj475pOwoDvEA5K2ctnbSjMdLP4D6vUjq0 GK0Rpd8fW6MxhXVmRG4tA== X-UI-Out-Filterresults: notjunk:1;V01:K0:tlbL92YMIOY=:Lew9eyvy9UBIz8MkFVXUMC yvPxyoN20ZgHhLZLQosRcHAIxnV0kPeO9A5scFdjhnEYriOmhYsRqlsGdhSXzlshLhvWT7evu JH+19LWXGFOZkZQGCAe8R3HlUGr7wXOKRTcx+aMD9EvrujpJijXQiARTwy6E8bNbGJ1jTqDmP MqJYFrvZkqq+3nrP2eMpAvXGUDGHUFNw21xMGtnnI/QgE1IOmmr03gF0QGsZC+OVJEPPRNoTr 8lFcbZG+D9n+Ir8MjrCb7ntZ+TC6cnt8+aA9qH4oJgyiNHaQ3jv0+5q0gZYoMWS4esFtmkpTB PdRin2Aq0P7MR8gXr0z0q4K9ImPInfTS5c4AkrgoYx1Pu2eouGEUmcNAHU4lY+YHO5SZCn++7 lAiN9+IThECFs6+pAh7uOS/uX2IuNcFbhBGcsYopsM/7QIkKbpYq3pnPg7u6uVhIFVd5CU6kT Dtlzebd1BUkfaxuevIeWDsY76BRxyTXhxSr1TWvlnTPDUARa2rACGEJniLA6iRCf0VhiJXvTc 5siPGfsz8jyHV3yyprr7k20KxvMGVOL4FqAsjgn6xL4OP4eRQcHuWmwSjzkgF+lJ62IeBf0ai +nXDIldeK0+A5k5IImLN3kIc+3afnWQLZNh5Jiqy49Oqc+vkAWuervGwYktNK4RT6YVYcCbUf c+bF9CQjcf+OujAfsF68pig8dbRri/f/91UREWqVRpyxMPQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1507 Lines: 31 On Friday 03 July 2015 00:08:27 Thomas Gleixner wrote: > On Thu, 2 Jul 2015, Paul Osmialowski wrote: > > On Thu, 2 Jul 2015, Arnd Bergmann wrote: > > > > > I wonder if you could move out the fixed rate clocks into their own > > > nodes. Are they actually controlled by the same block? If they are > > > just fixed, you can use the normal binding for fixed rate clocks > > > and only describe the clocks that are related to the driver. > > > > In my view having these clocks grouped together looks more convincing. After > > all, they all share the same I/O regs in order to read configuration. > > The fact that they share a register is not making them a group. That's > just a HW design decision and you need to deal with that by protecting > the register access, but not by trying to group them artificially at > the functional level. I'd disagree with that: The clock controller is the device that owns the registers and that should be one node in DT, as Paul's first version does. The part I'm still struggling with is understanding how the fixed-rate clocks are controlled through those registers. If they are indeed configured through the registers, the name is probably wrong and should be changed to whatever kind of non-fixed clock this is. Arnd -- 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/