KConfig and DTS files

Hi all,

I suspect that this has been discussed previously, but I'm a N00b to DT and Google hasn't helped identify a discussion on the list.

While getting my feet wet with DTS, I was quite surprised to see that there's no support for making parts of DTS files conditional on the kernel configuration.

We often cost-optimize BOMs for our standard boards and omit bits and pieces not needed for a particular build, and it would be nice to surround optional components with conditionals:

    #ifdef CONFIG_BLAH
    #endif

Please advise,

Hi,

Quoted 15 lines · Eric Nelson

Hi all,

I suspect that this has been discussed previously, but I'm a N00b to DT and Google hasn't helped identify a discussion on the list.

While getting my feet wet with DTS, I was quite surprised to see that there's no support for making parts of DTS files conditional on the kernel configuration.

We often cost-optimize BOMs for our standard boards and omit bits and pieces not needed for a particular build, and it would be nice to surround optional components with conditionals:

Quoted 4 lines

     #ifdef CONFIG_BLAH
     #endif

Please advise,

The DTS is independent on what drivers the kernel is actually enabling. It should focus on what is actually there on hardware, and not what is enabled in software.

I think I know where you're coming from on this -- on some board-file setups people used to not register the platform_device if the driver wasn't configured. That was also not really a good way to do it, but it made a bit more sense there, since you'd save the few bytes used by the platform_device/platform_data structures.

Hi Olof,

Quoted 31 lines · Olof Johansson

Hi,

Quoted 16 lines · Eric Nelson

Hi all,

I suspect that this has been discussed previously, but I'm a N00b to DT and Google hasn't helped identify a discussion on the list.

While getting my feet wet with DTS, I was quite surprised to see that there's no support for making parts of DTS files conditional on the kernel configuration.

We often cost-optimize BOMs for our standard boards and omit bits and pieces not needed for a particular build, and it would be nice to surround optional components with conditionals:

Quoted 4 lines

     #ifdef CONFIG_BLAH
     #endif

Please advise,

The DTS is independent on what drivers the kernel is actually enabling. It should focus on what is actually there on hardware, and not what is enabled in software.

Quoted 6 lines

I think I know where you're coming from on this -- on some board-file setups people used to not register the platform_device if the driver wasn't configured. That was also not really a good way to do it, but it made a bit more sense there, since you'd save the few bytes used by the platform_device/platform_data structures.

It's not a question of space, but functionality.

We had this come up recently when optimizing a BOM for use without Wi-Fi. If we omit the device and associated buffers, the SDIO lines are left floating, so the detection code will complain.

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

Prior to DT, we surrounded the device startup calls with #ifdefs like this:

https://github.com/boundarydevices/linux-imx6/blob/boundary-jb4.3_1.0.0-ga/arch/arm/mach-mx6/board-mx6_nitrogen6x.c#L1409

Hi,

Quoted 15 lines · Eric Nelson

Hi all,

I suspect that this has been discussed previously, but I'm a N00b to DT and Google hasn't helped identify a discussion on the list.

While getting my feet wet with DTS, I was quite surprised to see that there's no support for making parts of DTS files conditional on the kernel configuration.

We often cost-optimize BOMs for our standard boards and omit bits and pieces not needed for a particular build, and it would be nice to surround optional components with conditionals:

Quoted 4 lines

    #ifdef CONFIG_BLAH
    #endif

Please advise,

The DTS is independent on what drivers the kernel is actually enabling. It should focus on what is actually there on hardware, and not what is enabled in software.

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

        https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

Quoted 6 lines · On Wednesday 07 May 2014 10:47:27 Eric Nelson wrote:

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

Quoted 9 lines

         https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

It's fine to have two .dtb files (as Olof and Jason also suggested) and you can even have both in the kernel and just pick the right one for your machine.

Another option that works is to have the boot loader set up the present devices. With u-boot, you can easily manipulate the binary dtb and change a 'status="disabled"' to 'status="ok"' or vice versa for devices that are only sometimes populated, or you can change the amount of installed RAM as detected by the loader.

Quoted 21 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 May 2014 10:47:27 Eric Nelson wrote:

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

Quoted 9 lines

         https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

It's fine to have two .dtb files (as Olof and Jason also suggested) and you can even have both in the kernel and just pick the right one for your machine.

Quoted 6 lines

Another option that works is to have the boot loader set up the present devices. With u-boot, you can easily manipulate the binary dtb and change a 'status="disabled"' to 'status="ok"' or vice versa for devices that are only sometimes populated, or you can change the amount of installed RAM as detected by the loader.

Easily is such a relative term

Thanks for the advice.

Quoted 30 lines · On Wednesday 07 May 2014 11:35:12 Eric Nelson wrote:

Quoted 27 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 May 2014 10:47:27 Eric Nelson wrote:

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

Quoted 9 lines

          https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

It's fine to have two .dtb files (as Olof and Jason also suggested) and you can even have both in the kernel and just pick the right one for your machine.

Another option that works is to have the boot loader set up the present devices. With u-boot, you can easily manipulate the binary dtb and change a 'status="disabled"' to 'status="ok"' or vice versa for devices that are only sometimes populated, or you can change the amount of installed RAM as detected by the loader.

Quoted 3 lines

Easily is such a relative term

Thanks for the advice.

I haven't done it myself, but I'm told that you can do it from the boot script as normal commands, without having to modify the source.

For me, setting the status to "disabled" required a "resize" first:

U-Boot > fdt set /v4l2_out status disabled libfdt fdt_setprop(): FDT_ERR_NOSPACE U-Boot > fdt resize
U-Boot > fdt set /v4l2_out status disabled

U-Boot > fdt print /v4l2_out v4l2_out {
compatible = "fsl,mxc_v4l2_output"; status = "disabled";
};

Quoted 8 lines · On Wednesday 07 May 2014 12:07:02 Eric Nelson wrote:

For me, setting the status to "disabled" required a "resize" first:

U-Boot > fdt set /v4l2_out status disabled libfdt fdt_setprop(): FDT_ERR_NOSPACE U-Boot > fdt resize
U-Boot > fdt set /v4l2_out status disabled

Quoted 6 lines

U-Boot > fdt print /v4l2_out v4l2_out {
compatible = "fsl,mxc_v4l2_output"; status = "disabled";
};

How about starting out with status="disabled" and then removing that if necessary? Leaving out the status property should have the same effect as setting it to "ok".

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson <[email protected]> wrote:
[...]

Quoted 1 line

Quoted 2 lines

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

Because what you just showed is the use case where you have 1 defconfig, build 1 zImage and then you can have a completely separate delivery of X number of dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.

It is really annoying that you can't include a DTS in another DTS (only DTSIs). This is a major shortcoming of the tools, as far as I am concerned.

So, the best way we've found to do this is to create a shared dtsi that has practically everything in it, then a skeleton DTS for the "full" product, and a separate DTS for the cost-reduced version. The cost-reduced DTS would insert a status = "disabled"; for the sdio controller. That's a solution that scales very poorly as well, though.

Best would be if a DTS could just include another DTS for minor updates, such as disabling the sdio controller in this case. I'm sure there were some language-puritan reasons for not allowing that though. Someone care to fill in the history?

Quoted 64 lines · Eric Nelson

Hi Olof,

Quoted 31 lines · Olof Johansson

Hi,

Quoted 16 lines · Eric Nelson

Hi all,

I suspect that this has been discussed previously, but I'm a N00b to DT and Google hasn't helped identify a discussion on the list.

While getting my feet wet with DTS, I was quite surprised to see that there's no support for making parts of DTS files conditional on the kernel configuration.

We often cost-optimize BOMs for our standard boards and omit bits and pieces not needed for a particular build, and it would be nice to surround optional components with conditionals:

Quoted 4 lines

     #ifdef CONFIG_BLAH
     #endif

Please advise,

The DTS is independent on what drivers the kernel is actually enabling. It should focus on what is actually there on hardware, and not what is enabled in software.

Quoted 6 lines

I think I know where you're coming from on this -- on some board-file setups people used to not register the platform_device if the driver wasn't configured. That was also not really a good way to do it, but it made a bit more sense there, since you'd save the few bytes used by the platform_device/platform_data structures.

It's not a question of space, but functionality.

We had this come up recently when optimizing a BOM for use without Wi-Fi. If we omit the device and associated buffers, the SDIO lines are left floating, so the detection code will complain.

It seems reasonable to tell the kernel to skip this if the WiFi driver isn't configured into the kernel (i.e. there's no point in enumerating), so I was hoping to surround this USDHC2 block with #ifdefs:

https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi#L640

The alternative aren't very nice:
populate extra parts to drive these signals, or copy the DTB and strip out the unused parts

The first is wasteful (and environmentally un-friendly), and the second doesn't scale very well and pollutes the Git tree.

Quoted 4 lines

Prior to DT, we surrounded the device startup calls with #ifdefs like this:

https://github.com/boundarydevices/linux-imx6/blob/boundary-jb4.3_1.0.0-ga/arch/arm/mach-mx6/board-mx6_nitrogen6x.c#L1409

It is really annoying that you can't include a DTS in another DTS (only DTSIs). This is a major shortcoming of the tools, as far as I am concerned.

So, the best way we've found to do this is to create a shared dtsi that has practically everything in it, then a skeleton DTS for the "full" product, and a separate DTS for the cost-reduced version. The cost-reduced DTS would insert a status = "disabled"; for the sdio controller. That's a solution that scales very poorly as well, though.

Best would be if a DTS could just include another DTS for minor updates, such as disabling the sdio controller in this case. I'm sure there were some language-puritan reasons for not allowing that though. Someone care to fill in the history?

Quoted 4 lines · Bjorn Andersson

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson <[email protected]> wrote:
[...]

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

Because what you just showed is the use case where you have 1 defconfig, build 1 zImage and then you can have a completely separate delivery of X number of dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.

I agree that there's some benefit in being able to generate different DTBs, and it's an advantage (size, speed) to customize the .config as well.

When those clearly go together, it seems natural to define them as such.

I've heard (and appreciate) the pointers about how to get past our current issue(s), but what's the rationale for not allowing the inclusion of autoconf.h and conditionals in the DTS?

Is it a concern that things will become polluted and hard to read?

Hi Bjorn,

Quoted 4 lines · Bjorn Andersson

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson <[email protected]> wrote:
[...]

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

Because what you just showed is the use case where you have 1 defconfig, build 1 zImage and then you can have a completely separate delivery of X number of dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.

I agree that there's some benefit in being able to generate different DTBs, and it's an advantage (size, speed) to customize the .config as well.

When those clearly go together, it seems natural to define them as such.

Quoted 21 lines · On Wednesday 07 May 2014 16:06:49 Eric Nelson wrote:

Quoted 4 lines · Bjorn Andersson

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson <[email protected]> wrote:
[...]

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

Because what you just showed is the use case where you have 1 defconfig, build 1 zImage and then you can have a completely separate delivery of X number of dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.

I agree that there's some benefit in being able to generate different DTBs, and it's an advantage (size, speed) to customize the .config as well.

When those clearly go together, it seems natural to define them as such.

Quoted 7 lines

I've heard (and appreciate) the pointers about how to get past our current issue(s), but what's the rationale for not allowing the inclusion of autoconf.h and conditionals in the DTS?

Is it a concern that things will become polluted and hard to read?

You should be able to take any recent enough Fedora/Debian/OpenSUSE/Ubuntu/OpenWRT kernel binary and install it on all ARMv7 machines to get a working system, keeping your existing .dtb file.

There are still a few issues to be worked out for that (e.g. some drivers still can't be described in DT, and in some exceptional cases we break backwards compatibility), but if the .dtb file depends on the kernel configuration, it can never work, because the person building the kernel does not know what hardware you have.

Quoted 16 lines · Eric Nelson

Hi Bjorn,

Quoted 4 lines · Bjorn Andersson

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson <[email protected]> wrote:
[...]

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

I still wonder about the choice of not allowing inclusion of at least include/generated/autoconf.h.

Because what you just showed is the use case where you have 1 defconfig, build 1 zImage and then you can have a completely separate delivery of X number of dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.

Quoted 6 lines

I agree that there's some benefit in being able to generate different DTBs, and it's an advantage (size, speed) to customize the .config as well.

When those clearly go together, it seems natural to define them as such.

But they don't. The end goal is that the dtb and the Linux kernel _aren't_ tied together. The dtb is shipped with the board, and you configure/build your kernel how you want, and boot it.

Look at the dtb as replacement for the mach-type or boardid number. It's handed to the OS (not necessarily Linux) by the bootloader to say "Here's what you're running on". It's *not* a reflection of the configuration of the Linux Kernel. The dtb describes the hardware for a specific board. Nothing more, nothing less.

Several other projects use the dts files from the kernel tree. Ian Campbell even set up a filter-branch version of the dts files and the binding docs so that other projects could clone that repo without getting the entire Linux commit history. If we tied the dts files to Kconfig symbols, we'd make other projects lives much more difficult. Not to mention possibly driving Ian to drink excessively. :)