"Trilok Soni" <[EMAIL PROTECTED]> writes: > Hi Eric, > > On Mon, Apr 21, 2008 at 7:24 PM, Eric Nelson > <[EMAIL PROTECTED]> wrote: >> >> Trilok Soni wrote: > > ... > >> >> Are you referring to mach-omap2/serial.c? If so, it seems that this >> adds code unecessarily. As you mention, a given board will either >> expose or not expose each of the three UARTs, and by using #ifdef, >> the extra code and data will be stripped from the resulting image. > > Yes, I am referring to the same file. Originally omap_get_config with > TAGs was not accepted by RMK in ARM tree long back, but it is in the > mainline tree now. The OMAP approach indeed will need change in board > specific file in-order to enable the new UART out of three and your > approach will just have to enable in the menuconfig. The OMAP approach > was also added with TAGs as I heard that N8xx Nolo bootloader also > passed this uart_config structure as ATAGS to kernel. > >> >> It's my expectation that any given board will have a davinci_xyz_defconfig >> which will set the appropriate CONFIG_DAVINCI_UARTx variable. >> >> While reviewing this, I did notice that my patch omitted a necessary >> change for the DVEVM (an update to davinci_evm_dm644x_defconfig to >> include UART0). >> >> What's more, on boards like our Xenon board, the RS-232 drivers and >> connectors are optionally installed on a connector board. Having >> these set through CONFIG variables and #ifdefs prevents the need to >> edit the sources to configure for a particular machine. >> >> http://boundarydevices.com/xenon.php >> >> This could probably be done in the board-specific davinci_get_config(), >> but there's currently no support for that in the davinci tree. > > davinci_get_config can be implemented like omap one, should be easy to > do. I have internally started porting this GIT tree to our custom > boards, so I am planning to bring some OMAP features here too. > >> >> Finally, the main reason I structured this code as I did is that >> it was the smallest patch! > > Yes, it is small, but Kevin has to take a decision, which approach > would be clean way to go forward.
My preference is for runtime decision making, not compile-time. As is done in the OMAP tree, the larger goal is to be able to have a single kernel binary that can run on multiple boards, without it having to recompile. As support for more boards and processors in the DaVinci family are added, this will be a guiding design principle of this kernel. While doing things this way may indeed add extra code, this is only init time code, and can be done using __init functions which are freed after boot. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
