Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [111003 02:20]: On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. This is really our goal, we will have soon the board-generic.c for that, someone will just have to migrate these ~30 board files to device tree DTS files For the purpose of build-time validation using randconfig, there is no problem in keeping some board files forever, as long as the generic board file is always built-in. Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. That's what I had initially, but now that board file has become omap2-specific and no longer works on omap3-only or omap4-only configurations. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
* Arnd Bergmann a...@arndb.de [111004 00:10]: On Monday 03 October 2011, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [111003 02:20]: On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. This is really our goal, we will have soon the board-generic.c for that, someone will just have to migrate these ~30 board files to device tree DTS files For the purpose of build-time validation using randconfig, there is no problem in keeping some board files forever, as long as the generic board file is always built-in. Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. That's what I had initially, but now that board file has become omap2-specific and no longer works on omap3-only or omap4-only configurations. Will send a pull request for basic DT bootstrap support from Benoit that fixes that. So maybe let's sort that out first, then always select it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [111004 00:10]: On Monday 03 October 2011, Tony Lindgren wrote: Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. That's what I had initially, but now that board file has become omap2-specific and no longer works on omap3-only or omap4-only configurations. Will send a pull request for basic DT bootstrap support from Benoit that fixes that. So maybe let's sort that out first, then always select it? Yes, sounds good. That is certainly the better solution in the long run. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] initial omap DT support for v3.2 merge window (Re: [PATCH 26/30] ARM: omap: add board autoselection)
* Arnd Bergmann a...@arndb.de [111004 11:55]: On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [111004 00:10]: On Monday 03 October 2011, Tony Lindgren wrote: Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. That's what I had initially, but now that board file has become omap2-specific and no longer works on omap3-only or omap4-only configurations. Will send a pull request for basic DT bootstrap support from Benoit that fixes that. So maybe let's sort that out first, then always select it? Yes, sounds good. That is certainly the better solution in the long run. Here you are. We had to rebase it earlier today because of the SOB update in fixes branch for the musb related fix that's needed here to avoid a merge conflict. This series pretty much depends and conflicts with all the ealier branches, so I created a new dt-base branch to deal with the merge conflicts. If you prefer some other base, please let me know. If you prefer to build some other merge base yourself, see the attached patch that's needed to avoid two build warnings after merging the various base branches together. The dt-base I did is a merge of cleanup-part3, voltage, dmtimer and l3 into fixes. You may not yet have l3 and fixes pulled in, I sent pull requests for those yesterday. The others you have already pulled I believe. Despite using the merge base this will cause a minor merge conflict in board-generic.c with Nicolas Pitre's earlier patch titled ARM: mach-omap2: convert boot_params to atag_offset. The atag_offset can be just left out, as the default will work. Regards, Tony The following changes since commit c541c15fb5ab48c47bc9b90121538fd30d152f23: Tony Lindgren (1): Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-base are available in the git repository at: git://github.com/tmlind/linux.git dt Benoit Cousson (18): ARM: OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API ARM: OMAP2+: pm: Use hwmod name instead of dev pointer ARM: OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM ARM: OMAP: omap_device: Create a default omap_device_pm_latency ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures of: Add helpers to get one string in multiple strings property ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration ARM: OMAP: omap_device: Add a method to build an omap_device from a DT node arm/dts: Add initial device tree support for OMAP4 SoC arm/dts: Add support for OMAP4 PandaBoard arm/dts: Add support for OMAP4 SDP board arm/dts: Add initial device tree support for OMAP3 SoC arm/dts: Add support for OMAP3 Beagle board ARM: OMAP2+: board-generic: Add DT support to generic board ARM: OMAP2+: board-generic: Add i2c static init ARM: OMAP2+: l3-noc: Add support for device-tree arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver arm/dts: OMAP3+: Add mpu, dsp and iva nodes Nishanth Menon (1): ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_name Tony Lindgren (1): Merge branch 'for_3.2/3_omap_devicetree' of git://gitorious.org/omap-pm/linux into dt Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 + Documentation/devicetree/bindings/arm/omap/iva.txt | 19 ++ .../devicetree/bindings/arm/omap/l3-noc.txt| 19 ++ Documentation/devicetree/bindings/arm/omap/mpu.txt | 27 ++ .../devicetree/bindings/arm/omap/omap.txt | 43 +++ arch/arm/boot/dts/omap3-beagle.dts | 29 ++ arch/arm/boot/dts/omap3.dtsi | 63 arch/arm/boot/dts/omap4-panda.dts | 29 ++ arch/arm/boot/dts/omap4-sdp.dts| 29 ++ arch/arm/boot/dts/omap4.dtsi | 103 +++ arch/arm/mach-omap2/Kconfig|8 +- arch/arm/mach-omap2/board-generic.c| 156 --- arch/arm/mach-omap2/board-omap3beagle.c|4 +- arch/arm/mach-omap2/devices.c | 51 +--- arch/arm/mach-omap2/display.c | 11 +- arch/arm/mach-omap2/dma.c | 11 +- arch/arm/mach-omap2/gpio.c | 12 +- arch/arm/mach-omap2/hsmmc.c| 18 +- arch/arm/mach-omap2/hwspinlock.c | 12 +- arch/arm/mach-omap2/mcbsp.c| 11 +- arch/arm/mach-omap2/omap_l3_noc.c | 25 ++- arch/arm/mach-omap2/pm.c | 72 ++--- arch/arm/mach-omap2/serial.c | 25 +-- arch/arm/mach-omap2/sr_device.c| 11 +- arch/arm/mach-omap2/usb-musb.c | 11 +- arch/arm/plat-omap/i2c.c | 10 +-
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote: +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA Do we need all above 'depends on *' ? Even if they get selected for one of the below ARCH along with default machine, build should be happy. Right ? I'm not too happy with having to maintain a list for each subarchitecture, when each one has the same problem. In general, I would really like to have the flexibility to disable all but any one board, which requires either maintaining a list like the above, or expressing the same like config MACH_OMAP_AUTO_BOARD def_bool y depends on !MACH_OMAP_BOARD_SELECTED select MACH_OMAP_GENERIC if ARCH_OMAP2 select MACH_OMAP_3430SDP if ARCH_OMAP3 !ARCH_OMAP2 select MACH_OMAP_4430SDP if ARCH_OMAP4 !ARCH_OMAP3 !ARCH_OMAP2 and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more to write but perhaps a little less error-prone. In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 02:41 PM, Arnd Bergmann wrote: On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote: +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA Do we need all above 'depends on *' ? Even if they get selected for one of the below ARCH along with default machine, build should be happy. Right ? I'm not too happy with having to maintain a list for each subarchitecture, when each one has the same problem. In general, I would really like to have the flexibility to disable all but any one board, which requires either maintaining a list like the above, or expressing the same like Ok. config MACH_OMAP_AUTO_BOARD def_bool y depends on !MACH_OMAP_BOARD_SELECTED select MACH_OMAP_GENERIC if ARCH_OMAP2 select MACH_OMAP_3430SDP if ARCH_OMAP3 !ARCH_OMAP2 select MACH_OMAP_4430SDP if ARCH_OMAP4 !ARCH_OMAP3 !ARCH_OMAP2 and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more to write but perhaps a little less error-prone. In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. I see your point. Sounds a good idea to me. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. This is really our goal, we will have soon the board-generic.c for that, someone will just have to migrate these ~30 board files to device tree DTS files For the purpose of build-time validation using randconfig, there is no problem in keeping some board files forever, as long as the generic board file is always built-in. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
* Arnd Bergmann a...@arndb.de [111003 02:20]: On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. This is really our goal, we will have soon the board-generic.c for that, someone will just have to migrate these ~30 board files to device tree DTS files For the purpose of build-time validation using randconfig, there is no problem in keeping some board files forever, as long as the generic board file is always built-in. Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/30] ARM: omap: add board autoselection
At least one board file needs to be selected to successfully build a kernel, so this one adds logic to the omap Kconfig file to pick one default board file when all others are disabled. Since the available boards depend on the SoC family (omap2/3/4) being selected first, this adds one default for each family. Signed-off-by: Arnd Bergmann a...@arndb.de --- arch/arm/mach-omap2/Kconfig | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3c9fb89..fd0ab18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC depends on ARCH_OMAP2 default y +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA + select MACH_OMAP_GENERIC if ARCH_OMAP2 + select MACH_OMAP_3430SDP if ARCH_OMAP3 !ARCH_OMAP2 + select MACH_OMAP_4430SDP if ARCH_OMAP4 !ARCH_OMAP3 !ARCH_OMAP2 + help + The kernel needs to have support for at least one board + in order to build. If none is selected, default to the + generic board. + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 SOC_OMAP2420 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: At least one board file needs to be selected to successfully build a kernel, so this one adds logic to the omap Kconfig file to pick one default board file when all others are disabled. Since the available boards depend on the SoC family (omap2/3/4) being selected first, this adds one default for each family. Signed-off-by: Arnd Bergmann a...@arndb.de --- arch/arm/mach-omap2/Kconfig | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3c9fb89..fd0ab18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC depends on ARCH_OMAP2 default y +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA Do we need all above 'depends on *' ? Even if they get selected for one of the below ARCH along with default machine, build should be happy. Right ? + select MACH_OMAP_GENERIC if ARCH_OMAP2 + select MACH_OMAP_3430SDP if ARCH_OMAP3 !ARCH_OMAP2 + select MACH_OMAP_4430SDP if ARCH_OMAP4 !ARCH_OMAP3 !ARCH_OMAP2 This is fine. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
