Hi Nikita, On Tue, Sep 23, 2014 at 09:58:08PM +0400, Nikita Yushchenko wrote: > Hi > > I'm currently forward-porting a BSP for imx6-based custom board from > pre-devicetree kernel to modern kernel. > > In old BSP there was a board setup file, that registered all board's > devices. For new BSP, I need to replace that with device tree based > solution. > > However, old BSP used conditional code to register devices > differently based on GPIO inputs and on kernel command line. This > approach was used to > > - handle board's jumper that switches SPI CS lines: current jumper > setting is available over gpio, depending on that old BSP registered > chips differently, > > - handle different i2c connections on different board revisions: > board has 5 i2c busses with quite a few devices connected, these > busses are routed to different hardware busses on different board > revisions, board revision could be read over gpios. > > - handle different possible display connections (lvds vs lcd, 6bit > vs 8bit hw interface) based on kernel command line options > > - handle different possible camera connections by registered camera > differently based on kernel command line option > > ... and more, > > > Device tree describes hardware unconditionally. I already have to > provide 2 dts files for imx6q and imx6dl based setups (both just > include a common dtsi) ... But providing separate dts file for > every possible hardware configuration will result into 2^n device > trees, which is inconvenient visible regression against old BSP that > "just worked" on all hardware configurations. > > > Is there a sane way to handle hardware configurations like above in > device tree based kernel? This depends on your definition of sane, but here the options I know of: - Let the bootloader modify the device tree based on the GPIOs. This seems doable in new projects, but not when you want to keep the old bootloader. - Use device tree overlays in the Kernel which is something Pantelis Antoniou works on. I think the intention here is more to plug a daughter board to a CPU board. I don't know how good this works when you have to manipulate many different places in the device tree. - I heard people working on a shim to place between bootloader and kernel. The shim translates the bootloader information into the device tree. I can't remember who it was though. For going this way I wouldn't rewrite the shim but use barebox instead of course ;) BTW where do the command line options in your setup come from? Are they autogenerated from other informations in the bootloader or are they entered there by a user? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
