* Javier Martinez Canillas <javier@xxxxxxxxxxxx> [131129 01:01]: > Hi Grazvydas, > > On Fri, Nov 29, 2013 at 12:57 AM, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote: > > On Tue, Nov 26, 2013 at 3:17 AM, Tony Lindgren <tony@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
