>-----Original Message----- >From: Tony Lindgren [mailto:[email protected]] >Sent: Tuesday, May 19, 2009 6:55 PM >To: Pandita, Vikram >Cc: Christensen, Mikkel; [email protected] >Subject: Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board > >* Pandita, Vikram <[email protected]> [090519 16:48]: >> Tony >> >> >-----Original Message----- >> >From: Tony Lindgren [mailto:[email protected]] >> >Sent: Tuesday, May 19, 2009 11:30 AM >> >To: Pandita, Vikram >> >Cc: Christensen, Mikkel; [email protected] >> >Subject: Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board >> > >> >* Pandita, Vikram <[email protected]> [090518 20:55]: >> >> Tony >> >> >> >> >* Pandita, Vikram <[email protected]> [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.
The problem is that serial.c: platform_device_register() for UART1/2/3 happens as arch_init(). We want that Quard/Dbg-board Uart console to appear as UART4(ttyS3) and so the platform_device_register() has to happen after the arch_init() call from serial.c If we put the dbg-board init in .init_machine = omap_zoom2_init() function, then this gets called first before the serial.c:arch_init() and assigns ttyS0(UART0) to the debug board uart. This is not what we want to do. > >Regards, > >Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
