Re: [PATCH 01/12 diet] ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting
* Javier Martinez Canillas [131129 01:01]: > Hi Grazvydas, > > On Fri, Nov 29, 2013 at 12:57 AM, Grazvydas Ignotas wrote: > > On Tue, Nov 26, 2013 at 3:17 AM, Tony Lindgren wrote: > >> We can now boot all mach-omap2 related boards using appended device > >> tree by creating a related .dts file with pretty much the same > >> functionality as booted in the legacy platform data mode. > > > > Not really the same, quite some drivers are still missing, and it > > makes pandora unusable :( . For example, SDIO variation of wl1251, > > that one is non-probeable and used to be "detected" by using > > MMC_QUIRK_NONSTD_SDIO quirk (see pandora_wl1251_init_card() in > > board-omap3pandora.c). Also there are at least pandora-backlight, > > twl4030_keypad and panel drivers that are not converted yet. Sounds like the pandora-backlight should be initialized using pdata-quirks.c for now. Then Sebastian has posted some twl4030-keypad patches at: http://linux-kernel.2935.n7.nabble.com/PATCHv3-0-2-twl4030-keypad-DT-binding-td750095.html Other than wl1251 below, looking at board-omap3pandora.c there should not be anything that we could not support with device tree. It seems that pandora can use the panel dpi pdata-quirks.c similar to the LDP. > > Can pdata-quirks.c be used for SDIO wl1251 at least, as I have no idea > > how to express it using device tree? > > > > Yes, pdata-quirks.c can be used to initialize any platform device that > does not have DT support yet and still needs platform data. Until we > add the proper bindings and get rid of it. Yeah at least initially. It should be just a question of adding a new entry to auxdata_quirks[] for pandora to populate the hsmmc platform data, then also add a new entry to omap_auxdata_lookup[] for hsmmc platform data. Similar to what n8x0 is already doing. But ideally we'd completely get rid of the platform data for the omap_hsmmc.c so we can simplify the driver and remove all the callback functions. So we could pass the non-standard configuration by adding a new compatible flag to omap_hsmmc.c for ti,omap3-hsmmc-wl1251. Then based on that omap_hsmmc.c could set the .init_card function from the struct of_device_id match table in the driver. Or we could specify the non-standard SDIO card properties as a child of the hsmmc .dts entry. But that can be done later on naturally and should be discussed on the linux-mmc and device tree lists. Let me know if you need help with the pandora .dts file, I don't have a pandora, but doing the basic .dts file for it should be quite easy. 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 01/12 diet] ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting
Hi Grazvydas, On Fri, Nov 29, 2013 at 12:57 AM, Grazvydas Ignotas wrote: > On Tue, Nov 26, 2013 at 3:17 AM, Tony Lindgren wrote: >> We can now boot all mach-omap2 related boards using appended device >> tree by creating a related .dts file with pretty much the same >> functionality as booted in the legacy platform data mode. > > Not really the same, quite some drivers are still missing, and it > makes pandora unusable :( . For example, SDIO variation of wl1251, > that one is non-probeable and used to be "detected" by using > MMC_QUIRK_NONSTD_SDIO quirk (see pandora_wl1251_init_card() in > board-omap3pandora.c). Also there are at least pandora-backlight, > twl4030_keypad and panel drivers that are not converted yet. > > Can pdata-quirks.c be used for SDIO wl1251 at least, as I have no idea > how to express it using device tree? > Yes, pdata-quirks.c can be used to initialize any platform device that does not have DT support yet and still needs platform data. Until we add the proper bindings and get rid of it. > -- > Gražvydas > -- Best regards, Javier -- 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 01/12 diet] ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting
On Tue, Nov 26, 2013 at 3:17 AM, Tony Lindgren wrote: > We can now boot all mach-omap2 related boards using appended device > tree by creating a related .dts file with pretty much the same > functionality as booted in the legacy platform data mode. Not really the same, quite some drivers are still missing, and it makes pandora unusable :( . For example, SDIO variation of wl1251, that one is non-probeable and used to be "detected" by using MMC_QUIRK_NONSTD_SDIO quirk (see pandora_wl1251_init_card() in board-omap3pandora.c). Also there are at least pandora-backlight, twl4030_keypad and panel drivers that are not converted yet. Can pdata-quirks.c be used for SDIO wl1251 at least, as I have no idea how to express it using device tree? -- Gražvydas -- 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 01/12 diet] ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting
We can now boot all mach-omap2 related boards using appended device tree by creating a related .dts file with pretty much the same functionality as booted in the legacy platform data mode. So let's remove the legacy board files so we can finally make mach-omap2 boot using device tree only. The main reason for doing this is to leave out massive amounts of legacy platform data that is no longer needed when booted with device tree. There are some devices that still need platform data, but that we can deal with using the auxdata support in mach-omap2/pdata-quirks.c based on the board specific device tree compatible flag. The only board-*.c files remaining will be board-generic.c that's used for device tree based booting, and board-n8x0.c that's needed temporarily until basic omap2 legacy devices work with device tree. Note that we're also removing board-ti8168evm.c that's not omap3, but that seems broken anyways as it's missing handle_irq. And there's really nothing stopping us from booting ti81xx with device tree either except adding support to board-generic.c like other omaps have. If you're new to booting things with device tree, here are some quick instructions for bringing up new boards with device tree: 1. Look at the existing files in arch/arm/boot/dts There's a fair chance somebody has already created a suitable file for your board. 2. Create omap3-yourboard.dts file in arch/arm/boot/dts If you don't see a suitable omap3-*.dts file, chances are your board is very similar to one of them. For older 34xx/35xx based boards take a look at the omap3-beagle.dts and omap3-ldp.dts, and for newer 36xx/37xx based boards take a look at omap3-beagle-xm.dts and omap3-evm-37xx.dts. 3. Add omap3-yourboard.dtb to the arch/arm/boot/dts/Makefile 4. Check that you have the necessary .config options enabled CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y CONFIG_PINCTRL_SINGLE=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_FIXED_VOLTAGE=y These are enabled in omap2plus_defconfig by default. 5. Build the kernel $ ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make omap3-myboard.dtb $ ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make zImage 6. Append the .dtb file to zImage $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-evm-37xx.dtb > /tmp/zImage 7. Optionally run mkimage to create uImage file $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/zImage-omap2plus /tmp/uImage-omap2plus 8. Add support for further devices to the .dts files Please try to add support for further devices as device tree drivers. If you need some legacy devices to keep things working, you can also use the pdata-quirk.c to initialize those. Signed-off-by: Tony Lindgren --- Here's the diet version of this patch as the full patch was too big for the lists it seems. This diet version of the patch just removes the legacy board-*.c file entries from Kconfig and Makefile, which should be enough for most people for testing. If the full patch does not make it to the lists, it's also available here: http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/?id=1f7260bc2ba270ef04b8eaa2a7824fb32aa516aa The full patch also removes the following board-*.c files: arch/arm/mach-omap2/board-3430sdp.c | 633 arch/arm/mach-omap2/board-am3517crane.c | 150 --- arch/arm/mach-omap2/board-am3517evm.c| 379 --- arch/arm/mach-omap2/board-cm-t35.c | 771 --- arch/arm/mach-omap2/board-cm-t3517.c | 337 -- arch/arm/mach-omap2/board-devkit8000.c | 655 - arch/arm/mach-omap2/board-ldp.c | 425 arch/arm/mach-omap2/board-omap3beagle.c | 596 arch/arm/mach-omap2/board-omap3logic.c | 251 - arch/arm/mach-omap2/board-omap3pandora.c | 630 arch/arm/mach-omap2/board-omap3stalker.c | 438 arch/arm/mach-omap2/board-omap3touchbook.c | 396 arch/arm/mach-omap2/board-overo.c| 572 --- arch/arm/mach-omap2/board-rx51-peripherals.c | 1323 --- arch/arm/mach-omap2/board-rx51-video.c | 67 - arch/arm/mach-omap2/board-rx51.c | 142 -- arch/arm/mach-omap2/board-ti8168evm.c| 62 - --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -192,80 +192,6 @@ config MACH_OMAP2_TUSB6010 depends on ARCH_OMAP2 && SOC_OMAP2420 default y if MACH_NOKIA_N8X0 -config MACH_OMAP3_BEAGLE - bool "OMAP3 BEAGLE board" - depends on ARCH_OMAP3 - default y - select OMAP_PACKAGE_CBB - -config MACH_DEVKIT8000 - bool "DEVKIT8000 board" - depends on ARCH_OMAP3 - default y - select OMAP_PACKAGE_CUS - -config MACH_OMAP_LDP - bool "OMAP3 LDP board" - depends on ARCH_OMAP3 - default y - select OMAP_PACKAGE_CBB - -co
