Device tree vs hardware configurations

Device tree vs hardware configurations

[Nikita Yushchenko]

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?


Nikita Yushchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html