* Pandita, Vikram <vikram.pandita@xxxxxx> [090519 16:48]: > Tony > > >-----Original Message----- > >From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > >Sent: Tuesday, May 19, 2009 11:30 AM > >To: Pandita, Vikram > >Cc: Christensen, Mikkel; linux-omap@xxxxxxxxxxxxxxx > >Subject: Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board > > > >* Pandita, Vikram <vikram.pandita@xxxxxx> [090518 20:55]: > >> Tony > >> > >> >* Pandita, Vikram <vikram.pandita@xxxxxx> [090518 14:31]: > >> >> Tony > >> >> > >> >> >> > >> >> >> + > >> >> >> + zoom2_init_smsc911x(); > >> >> >> + zoom2_init_quaduart(); > >> >> >> + return platform_add_devices(zoom2_devices, ARRAY_SIZE(zoom2_devices)); > >> >> >> +} > >> >> >> +arch_initcall(omap_zoom2_debugboard_init); > >> >> > > >> >> >Please just move all the related functions to board-zoom2.c. I don't see any > >> >> >reason to have a separate file for the debugboard features. The runtime detection > >> >> >should do the trick. > >> >> > >> >> Two reasons for keeping a separate debug board. > >> >> a) debug board is detachable in h/w and hence we thought its better to keep the s/w also that > >way > >> >> The quart chip on debug bard is a quard-uart and can support 4 different console outputs. > >> >> All those we thought of adding in future. > >> > > >> >Well those you can easily optimize out by not compiling in those devices. > >> > > >> >> > >> >> b) we took reference from board-rx51-peripherals.c wherein some parts of the board file can be > >> >moved out to a new file > >> >> > >> >> If you still think we need to merge, then let us know. > >> >> We are open to suggestions/changes. > >> > > >> >Well the reason for separate board-*-peripheral-whatever.c files is that > >> >they're intended to be shared with other board-*.c files. Currently n8x0 > >> >and rx51 share devices. In general, we should try to do generic platform > >> >init files, like gpmc-onenand.c and gpmc-smc91x.c. > >> > > >> >Then I see need for gpmc-sdp-flash.c that's shared between 2430 and 3430 sdp > >> >at least. > >> > > >> >So yeah, for zoom2, I'd rather see just board-zoom2.c for now. But if you > >> >create some other board that uses the same debug board functions, then > >> >there could be a separate zoom-debugboard.c. > >> > >> > >> Yes. There is next generation of zoom boards that will re-use the Debug board. > >> That way the debug board file will get re-used. > > > >OK, how about rename it to something that makes sense as a name for > >multiple zoom like boards and resubmit. > > I am planning on renaming debug board zoom2 file to board-zoom-debugboard.c > That way it can be used by different Zoom family of boards. OK > >Also the arch_initcall() issue below still needs fixing. > > I have cleaned the issue by making the debug_board_init call as late_initcall(). > > There is a dependency on serial.c file and hence the need for arch_init/late_init calls. > > platform_device_register() should happen for serial.c file (8250) for the omap uarts first and this should be followed by platform_device_register() for the quard uart on debug board. > > So there is a dependency on order of registration of platform device for the same 8250 driver. > > If you ack, then I can post the patches with the changes. Well you still cannot have it as a late_initcall(), you should just call the function from board-zoom2.c. Otherwise it will run for all the boards. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
