Re: Device tree vs hardware configurations

[Sascha Hauer]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/