From: ben.dooks@codethink.co.uk (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: Clock register in early init
Date: Tue, 22 May 2012 10:20:50 +0100 [thread overview]
Message-ID: <4FBB5A72.2080101@codethink.co.uk> (raw)
In-Reply-To: <20120521084642.GV20304@tbergstrom-lnx.Nvidia.com>
On 21/05/12 09:46, Peter De Schrijver wrote:
>>
>> On OMAP I think the only "gotcha" is setting up the timer. One
>> solution is to open code the register reads and the rate calculation
>> in the timer code. That is ugly... but it works.
>>
>>> Which advantages do you see in dynamically allocating all this?
>>>
>>
>> There are many but I'll name a couple. The most significant point is
>> that we can avoid exposing the definition of struct clk if we
>> dynamically allocate stuff. One can use struct clk_hw_init to
>> statically initialize data, or instead rely on direct calls to
>> clk_register with a bunch of parameters.
>>
>
> Which means if you make a mistake in specifying parents for example, it will
> only fail at runtime, possibly before any console is active. With static
> initialization, this will fail at compiletime. Much easier to debug.
>
>> Another point is that copying the data at registration-time makes
>> __initdata possible. I haven't done the math yet to see if this
>> really makes a difference. However if we start doing single zImage's
>> with multiple different ARM SoCs then this could recover some pages.
>>
>
> On the other hand most clock structures are small, so there will be internal
> fragmentation. Also the arrays of parent clock pointers can be shared between
> different clocks. We have about 70 muxes in Tegra30 and 12 different parent
> arrays.
We had at-least that on the older Samsung parts and they where still
growing. I would suggest that in a multi-kernel image situation the
more data that can be discarded after init-time the better.
Also, __initdata gets gathered into one place so there's no possibility
of page fragmentation there. If you mean fragmentation of the memory
map, then allocate the size of all the clocks you know of at init time
in one go.
It would possible even be useful to have construction code that took
some brief details of the clocks and constructed the list/tree of clocks
at start time.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next prev parent reply other threads:[~2012-05-22 9:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1337227884.2066.9.camel@pgaikwad-dt2>
[not found] ` <20120517062131.GA9305@gmail.com>
2012-05-18 4:48 ` Clock register in early init Prashant Gaikwad
2012-05-18 11:21 ` Peter De Schrijver
2012-05-18 20:17 ` Turquette, Mike
2012-05-21 8:46 ` Peter De Schrijver
2012-05-21 18:05 ` Turquette, Mike
2012-05-22 11:15 ` Peter De Schrijver
2012-05-22 9:20 ` Ben Dooks [this message]
2012-05-22 12:08 ` Peter De Schrijver
2012-05-22 17:37 ` Turquette, Mike
2012-05-23 9:19 ` Peter De Schrijver
2012-05-23 16:20 ` Turquette, Mike
2012-05-24 1:02 ` Paul Mundt
2012-05-24 15:51 ` Turquette, Mike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBB5A72.2080101@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).