From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH 1/2] clk: add lpc18xx creg clk driver Date: Thu, 18 Feb 2016 18:36:45 -0800 Message-ID: <20160219023645.GP4847@codeaurora.org> References: <1436651307-24098-1-git-send-email-manabian@gmail.com> <1436651307-24098-2-git-send-email-manabian@gmail.com> <20150811204127.31346.16729@quantum> <20150818002604.31346.18322@quantum> <20160217005629.2278.90197@quark.deferred.io> <20160217202824.2278.25956@quark.deferred.io> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-clk-owner@vger.kernel.org To: Joachim Eastwood Cc: Michael Turquette , devicetree@vger.kernel.org, linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org On 02/17, Joachim Eastwood wrote: > > For creg-clk it would probably work. > > cgu would need to register most of clocks early since it needs to > support whatever setup the bootloader throws at it. The only clocks > that could be taken out is the base clocks (clk_onecell_data > clk_base_data) except for one of them. But splitting this table would > be a bad idea as hw clk numbers are used as indexes for easy look up. > > Come to think of it; isn't splitting the clock table between a early > init and platform driver going become a problem? > At least the lookup in the driver or framework would become more complex(?) > And won't you confuse the lookup? > If the early driver register one clock table with > of_clk_add_provider() and then sometime later the platform driver > register another clock table, both using the same of_node. How is that > suppose to work? I believe that should work, although I haven't tested it. The code looks until it finds a provider that matches the device node and gives us a valid clk pointer. If we don't get a valid pointer we keep looking for another provider until we exhaust all providers. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project