Hello.
Mark A. Greer wrote:
On the cost side of the equation, things are going to be messier in
mach-davinci because there will now be parallel files (e.g.,
a davinci devices.c file and a da8xx devices.c file, a davinci irq.c
file and a da8xx irq.c file).
There won't be DA8xx irq.c file as cp_intc is not specific to DA8xx.
That being said, when the multiple-device support is done
correctly, the size and performance problems disappear when you simply
build a kernel for a single device and board. Even in multiple device
kernels, __init data and functions allows you to recover any wasted
memory, and conditional cpu_is_* code can be optimized away:
if (cpu_is_davinci_dm355())
foo()
becomes
if (0)
foo
if dm355 support is not built in, allowing the compiler to simply
optimize this code away.
Yep.
I have noticed this feature only yesterday.
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?
Make sense?
Mark
--
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
