On Fri, 2009-01-23 at 23:45 +0300, Sergei Shtylyov wrote:
> Mark A. Greer 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
> > --
> 
> 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


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to