From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs Date: Wed, 23 Nov 2011 11:19:19 -0800 Message-ID: <20111123191919.GH31337@atomide.com> References: <1321926047-14211-1-git-send-email-mturquette@linaro.org> <1321926047-14211-6-git-send-email-mturquette@linaro.org> <20111122154900.GB18954@kroah.com> <20111122191347.GB4844@kroah.com> <20111123165903.GF31337@atomide.com> <20111123180651.GB19739@n2100.arm.linux.org.uk> <20111123185518.GG31337@atomide.com> <20111123190954.GA4365@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20111123190954.GA4365-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org Errors-To: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org To: Mark Brown Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, Greg KH , eric.miao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org, sboyd-jfJNa2p1gH1BDgjK7y7TUQ@public.gmane.org, magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Russell King - ARM Linux , tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org, linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, skannan-jfJNa2p1gH1BDgjK7y7TUQ@public.gmane.org List-Id: linux-omap@vger.kernel.org * Mark Brown [111123 10:34]: > On Wed, Nov 23, 2011 at 10:55:19AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [111123 09:31]: > > > > Keep the clk API as a fundamental thing which should be initialized early > > > so we don't have to invent new clk APIs to get around its unavailability. > > > What else are you aware of that is really needed early for clocks other > > than clockevent? > > If nothing else we'd have to resolve all the device probe ordering > issues (Grant's patches seem a bit stalled) and convert all the systems > using the API to handle deferring probes until their clocks appear. > Using an early initcall of some kind would help with that but it does > seem like a lot of trouble and I'd expect it'll end up getting forced in > on most systems anyway. Yes the ordering depends on the system. In any case, initcalls are not super early compared to setup_timer. Tony