Hello.
Steve Chen wrote:
A somewhat related point, use of cpu_is_*. I think it would be smarter
to factor out the use of those calls as much as you can. If you had one
overall board.c file that did the cpu_is_*'s and hooked up the correct
device data, platform_data, etc. (or called a routine in an SoC specific
file that did the hooking up). It would make the code more modular,
easier to follow, and easier to add support for new variants.
It would also allow you to alloc space for and copy the necessary data
and make the structs that now can't be __initdata, __initdata.
With the static data being turning into dynamic, what's the win of
converting to __initdata?
The thing that really worries me about cp_intc is entry-macro.S.
Lets say each board has 1KB of static data and there are 10 boards.
That's 10KB of static data but only 1KB is useful. If you figure out
what board the kernel is running on, alloc 1KB of space, copy the
correct 1KB of static data to it during init time, reference the
copied data and not the original static data, you can make the
static data __initdata and it'll disappear. You still have the data
that you need and you save 9KB.
Ah, those multiboard kernels nobody really needs... "much ado about
nothing". :-P
The scenario I found most useful for single kernel binary is
testing/verification of a driver that is shared between several DaVinci
variants. For example, if I made a change in ALSA for DM355, it would
be good to do a quick sanity check on DM644x and DM6467 (depend on the
change). Obviously, I can always rebuild (or keep multiple copies of
the kernel) and test. Single binary certainly makes things simpler. Of
course, you really don't want to compile support for multiple board in
the production version of a custom board.
Mark, Steve, I hope you understand the differentce between the
testing kernel and the production one?
I'm not sure it's worth spending time on optimizing the multiboard
kernel which is most likely to be used just for testing/development.
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
