[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120621175443.GL4402@gmail.com>
Date: Thu, 21 Jun 2012 10:54:43 -0700
From: Mike Turquette <mturquette@...com>
To: Rob Herring <robherring2@...il.com>
Cc: Chris Ball <cjb@...top.org>, Mitch Bradley <wmb@...top.org>,
mturquette@...aro.org, Arnd Bergmann <arnd@...db.de>,
devicetree-discuss@...ts.ozlabs.org, sboyd@...eaurora.org,
linux-kernel@...r.kernel.org,
Grant Likely <grant.likely@...retlab.ca>,
skannan@...eaurora.org, Olof Johansson <olof@...om.net>,
shawn.guo@...aro.org, s.hauer@...gutronix.de,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 0/4] DT clock bindings
On 20120621-10:00, Rob Herring wrote:
> On 06/21/2012 02:27 AM, Chris Ball wrote:
> >
> > 2) Use alloc_bootmem() instead of kzalloc() in of_clk_add_provider(),
> > because we need to set up clocks during .init_early on ARM (which
> > happens pre-slab) so that they are available for platform init.
>
> This depends on 1 as the common clock code would have the same issue.
> Generally, the first place clocks are needed is the timer init. At that
> point, you can call kzalloc. This is where all the clock init used to be
> done until init_early was added and some platforms have moved their
> clock init. I don't think there was really ever much reason to move it
> other than to make the timer init function only deal with timer setup.
>
Hi Rob,
Just FYI I've been looking at using alloc_bootmem in the common clk code
as a way to get rid of the static initialization stuff (which only
existed due to very early initialization of timers).
The suggested change above to of_clk_add_provider would jive well with
my change to the common clk code.
Regards,
Mike
--
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