| Message ID | 1314897912-18178-8-git-send-email-b-cousson@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Benoit Cousson <b-cousson@ti.com> [110901 19:52]: > In order to avoid conflict with the new board-omap3-dt.c file, > remove the .dt_compat entry from the beagle regular board > file. > > Any DT work for OMAP3 will have to be done on the generic DT > board file to avoid breaking the legacy board support until > DT migration is done. In general we should not keep duplicate old non-DT data around now that we have the DT append support. Instead we should just require the .dts file appended to zImage for all mach-omap2 machines. Otherwise we'll end up with double bloat :) So it's OK to have the DT entries in board files so drivers that get converted will work with them. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/2/2011 10:12 AM, Tony Lindgren wrote: > * Benoit Cousson<b-cousson@ti.com> [110901 19:52]: >> In order to avoid conflict with the new board-omap3-dt.c file, >> remove the .dt_compat entry from the beagle regular board >> file. >> >> Any DT work for OMAP3 will have to be done on the generic DT >> board file to avoid breaking the legacy board support until >> DT migration is done. > > In general we should not keep duplicate old non-DT data around > now that we have the DT append support. Instead we should just > require the .dts file appended to zImage for all mach-omap2 > machines. Otherwise we'll end up with double bloat :) Mmm, I'm not sure to get your point. We are not duplicating, since a pure DT generic board will not have anything except a of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); And the regular board files will keep initializing devices statically. The drivers will then for the moment support both pdata and DT method to get board parameters. > So it's OK to have the DT entries in board files so drivers > that get converted will work with them. Well, it will be a little bit more tricky, because having DT in current board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding DT compatible inside each boards will prevent the pure generic DT one to work. In that case we will duplicate the DT migration in every legacy boards files... That's why the current strategy is to keep the current board files non-DT aware and add the DT support only to the generic DT board file. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Cousson, Benoit <b-cousson@ti.com> [110902 11:26]: > On 9/2/2011 10:12 AM, Tony Lindgren wrote: > >* Benoit Cousson<b-cousson@ti.com> [110901 19:52]: > >>In order to avoid conflict with the new board-omap3-dt.c file, > >>remove the .dt_compat entry from the beagle regular board > >>file. > >> > >>Any DT work for OMAP3 will have to be done on the generic DT > >>board file to avoid breaking the legacy board support until > >>DT migration is done. > > > >In general we should not keep duplicate old non-DT data around > >now that we have the DT append support. Instead we should just > >require the .dts file appended to zImage for all mach-omap2 > >machines. Otherwise we'll end up with double bloat :) > > Mmm, I'm not sure to get your point. We are not duplicating, since a > pure DT generic board will not have anything except a > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); > And the regular board files will keep initializing devices statically. > The drivers will then for the moment support both pdata and DT > method to get board parameters. Well when converting a driver to DT, we should just drop pdata support. No need to keep it around as it will just make it harder for us to clean up afterwards. > >So it's OK to have the DT entries in board files so drivers > >that get converted will work with them. > > Well, it will be a little bit more tricky, because having DT in > current board files will be a mess with a bunch of #ifdef CONFIG_OF, > and adding DT compatible inside each boards will prevent the pure > generic DT one to work. In that case we will duplicate the DT > migration in every legacy boards files... We should just select CONFIG_OF deal with it that way. > That's why the current strategy is to keep the current board files > non-DT aware and add the DT support only to the generic DT board > file. Well I don't like that, it will be a big mess. We'll end up with twice the amount of platform_data and init code. It's OK to require CONFIG_OF as it's known to work with the append support for older boards. It's easier just to require DT append for all the boards. In most cases it's just a trivial include of the common dts file for now. When we convert something to DT, there's no point going back. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/2/2011 12:48 PM, Tony Lindgren wrote: > * Cousson, Benoit<b-cousson@ti.com> [110902 11:26]: >> On 9/2/2011 10:12 AM, Tony Lindgren wrote: >>> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]: >>>> In order to avoid conflict with the new board-omap3-dt.c file, >>>> remove the .dt_compat entry from the beagle regular board >>>> file. >>>> >>>> Any DT work for OMAP3 will have to be done on the generic DT >>>> board file to avoid breaking the legacy board support until >>>> DT migration is done. >>> >>> In general we should not keep duplicate old non-DT data around >>> now that we have the DT append support. Instead we should just >>> require the .dts file appended to zImage for all mach-omap2 >>> machines. Otherwise we'll end up with double bloat :) >> >> Mmm, I'm not sure to get your point. We are not duplicating, since a >> pure DT generic board will not have anything except a >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); >> And the regular board files will keep initializing devices statically. >> The drivers will then for the moment support both pdata and DT >> method to get board parameters. > > Well when converting a driver to DT, we should just drop pdata > support. No need to keep it around as it will just make it harder > for us to clean up afterwards. I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so far. Dropping pdata when a driver is adapted means that all these boards should be properly adapted to DT and tested... (board-XXX.dts + board-XXX.c). That's a huge effort for my point of view. Whereas keeping the legacy pdata method will allow progressing on the boart-dt only without breaking any legacy boards. It will allow the board manufacturers to potentially do the DTS file for their own system using then the generic board-dt.c file. That being said, keeping the legacy pdata code in some driver along with the DT is a big pain as well:-( In some cases, DT can even provide some good way to encode HW information that we do not have today with hwmod/omap_device. So in that case we do not even have any alternative method yet. >>> So it's OK to have the DT entries in board files so drivers >>> that get converted will work with them. >> >> Well, it will be a little bit more tricky, because having DT in >> current board files will be a mess with a bunch of #ifdef CONFIG_OF, >> and adding DT compatible inside each boards will prevent the pure >> generic DT one to work. In that case we will duplicate the DT >> migration in every legacy boards files... > > We should just select CONFIG_OF deal with it that way. > >> That's why the current strategy is to keep the current board files >> non-DT aware and add the DT support only to the generic DT board >> file. > > Well I don't like that, it will be a big mess. We'll end up with > twice the amount of platform_data and init code. It's OK to > require CONFIG_OF as it's known to work with the append support > for older boards. > > It's easier just to require DT append for all the boards. In most > cases it's just a trivial include of the common dts file for now. That part is easy indeed, this is hacking every board-XXX.c and testing them that will be tricky. This is as well the board specifics settings that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin mux, regulator bindings, audio codec stuff... > When we convert something to DT, there's no point going back. Agree on that, in theory, I'm just wondering how practical it will be to progress on every board at the same time. I guess we do need some advice from the DT gurus on that as well. It looks to me that both approaches are painful and will require some efforts. It is too bad that nobody did a devicetree-migration-o-matic-for-lazy-developer.py script to handle that... Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Cousson, Benoit <b-cousson@ti.com> [110902 15:02]: > On 9/2/2011 12:48 PM, Tony Lindgren wrote: > > I'm not sure it is that simple. We have 20+ OMAP3+ boards supported > so far. Dropping pdata when a driver is adapted means that all these > boards should be properly adapted to DT and tested... (board-XXX.dts > + board-XXX.c). > That's a huge effort for my point of view. Whereas keeping the > legacy pdata method will allow progressing on the boart-dt only > without breaking any legacy boards. It will allow the board > manufacturers to potentially do the DTS file for their own system > using then the generic board-dt.c file. Yeah but we've seen how badly "we'll clean it up later" approach works :( Unfortunately that path means nobody comes back to clean-up anything after the party is over and all that work falls on the maintainers. So the one driver at a time conversion approach is better. > That being said, keeping the legacy pdata code in some driver along > with the DT is a big pain as well:-( Yup and duplicate data will lead to nasty bugs and support issues. > >It's easier just to require DT append for all the boards. In most > >cases it's just a trivial include of the common dts file for now. > > That part is easy indeed, this is hacking every board-XXX.c and > testing them that will be tricky. This is as well the board > specifics settings that are tricky not the generic OMAP stuff. We do > have to set GPIOs, pin mux, regulator bindings, audio codec stuff... Right but for most part it's just removing the data. The board specific things are usually number of MMC data lines, number of USB transceiver data lines, GPIO to enable etc. Pretty trivial stuff that the board maintainers can test. > >When we convert something to DT, there's no point going back. > > Agree on that, in theory, I'm just wondering how practical it will > be to progress on every board at the same time. That should not be too bad for most part. For example, the board-*.c files all just call omap_register_i2c_bus with the controllers. So not much there to convert, just add the controllers to board .dts files and remove from board-*.c files. > I guess we do need some advice from the DT gurus on that as well. > > It looks to me that both approaches are painful and will require > some efforts. Yes, but if we don't drop the pdata then we'll be in half-converted state eternally. > It is too bad that nobody did a > devicetree-migration-o-matic-for-lazy-developer.py script to handle > that... The conversion for some drivers can be scripted for sure :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index a7923ca..2c358a2 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -19,7 +19,6 @@ #include <linux/err.h> #include <linux/clk.h> #include <linux/io.h> -#include <linux/of_platform.h> #include <linux/leds.h> #include <linux/gpio.h> #include <linux/input.h> @@ -388,9 +387,7 @@ static int __init omap3_beagle_i2c_init(void) /* Bus 3 is attached to the DVI port where devices like the pico DLP * projector don't work reliably with 400kHz */ omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom)); -#ifdef CONFIG_OF omap_register_i2c_bus(2, 100, NULL, 0); -#endif /* CONFIG_OF */ return 0; } @@ -528,10 +525,6 @@ static void __init beagle_opp_init(void) static void __init omap3_beagle_init(void) { -#ifdef CONFIG_OF - of_platform_prepare(NULL, NULL); -#endif /* CONFIG_OF */ - omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); omap3_beagle_init_rev(); omap3_beagle_i2c_init(); @@ -563,11 +556,6 @@ static void __init omap3_beagle_init(void) beagle_opp_init(); } -static const char *omap3_beagle_dt_match[] __initdata = { - "ti,omap3-beagle", - NULL -}; - MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board") /* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */ .boot_params = 0x80000100, @@ -577,5 +565,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board") .init_irq = omap3_beagle_init_irq, .init_machine = omap3_beagle_init, .timer = &omap3_secure_timer, - .dt_compat = omap3_beagle_dt_match, MACHINE_END