On Thu, Jan 22, 2009 at 10:20:08AM -0800, Kevin Hilman wrote: > "Mark A. Greer" <[email protected]> writes: > > > On Tue, Jan 20, 2009 at 05:26:38PM -0800, Kevin Hilman wrote: > >> "Mark A. Greer" <[email protected]> writes: > >> > >> > On Tuesday 20 January 2009, David Brownell wrote:
<snip> > > I think we're in violent agreement on this. > > I think so too, good. Good. <snip> > > I suppose that the pragmatic thing to do is leave the code in one > > dir until it becomes too cluttered then move to separate dirs. > > Yes. This is how I would like to proceed as well. OK > And to take it a step further, I would like to see the da8xx support > added to existing _files_ by refactoring existing code or generalizing > it where necessary (except, of course, for the new blocks like > CP_INTC.) > > So to get concrete, here is how I envision things looking > under mach-davinci. > > Device or platform specific files: > > <device>.c: device-specific init, platform_data, etc. > where <device> = [dm644x | dm355 | dm646x | da8xx | ...] > > devices.c : should probably disappear in favor of <device>.c > > board-*.c : board specific init, platform_data etc. One for every > board supported. Current DaVinci git has 4 of these > so far. OK > > NOTE: Care needs to be taken so that device-specific stuff and > board-specific stuff stays in the appropriate <device>.c and > board-*.c files. This way, adding support for new boards is > as easy as possible. > > Generic code for all devices, with init functions that handle device > pecific parameters, either using cpu_is_* checks, or with options > passed in from <device>.c. > > clock.c - with clock definitions moved to <device>.c > edma.c > gpio.c > id.c > io.c - could probably be moved into <device>.c as well > mux.c > psc.c > serial.c > time.c > > and then the non-common blocks, where splitting into a separate file > is much more obvious. > > irq.c | cp_intc.c > > Doing this allows you prevent most of the bloat by only compiling the > <device>.c and board-*.c file that you care about by selecting the > right Kconfig options, and the cpu_is_* code in the common code > will be optimized away by the compiler. Okay, lets do this and see how it looks when we're done. We can always evolve it from there, if we need to. > > 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. > > > > Make sense? > > Yes, and I agree. Okay, cool. Mark -- _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
