[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5213CF58.50703@gmail.com>
Date: Tue, 20 Aug 2013 22:19:36 +0200
From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To: Stephen Warren <swarren@...dotorg.org>
CC: Russell King <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 02/17] ARM: call clk_of_init from time_init
On 08/20/2013 09:52 PM, Stephen Warren wrote:
> On 08/20/2013 01:47 PM, Sebastian Hesselbarth wrote:
>> On 08/20/2013 05:46 PM, Stephen Warren wrote:
>>> Some SoCs call this function in .init_irq() rather than .init_time().
>>> Perhaps we adjust this patch to do that instead. That way, we can
>>> presumably get rid of patch 1/17 since we can eliminate any duplicate
>>> calls, and adjust patch 14/17 (Tegra board file) to remove its custom
>>> call to of_clock_init(NULL)?
>>
>> Currently as of -next from yesterday, only tegra is requiring clocks
>> that early, while others are fine with them close to timers. I really
>> have no strong opinion on that. That decision should rather be made
>> by those with a far more complete insight of the consequences than I
>> have.
>
> Perhaps if Tegra is a special-case, it shouldn't rely on the generic
> init_time() callback, and hence you could still eliminate patch 1/17?
>
Perhaps Tegra is the common case but other SoC haven't dug deep enough?
IMHO from a HW point-of-view clocks are really among the essential
things that need to be running before you can do anything useful.
Just consider boot loaders that run fine without irqs but don't without
clocks (even if just represented by API). Maybe you are right, and we
should call of_clk_init(NULL) as early as possible. That would also
eliminate patch 1/17 as you suggest.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists