RE: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>-----Original Message-----
>From: Tony Lindgren [mailto:tony@xxxxxxxxxxx]
>Sent: Tuesday, May 19, 2009 6:55 PM
>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> [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.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux