KConfig and DTS files

KConfig and DTS files

[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:

     #ifdef CONFIG_BLAH
     #endif

Please advise,


Eric Nelson
Boundary Devices
http://boundarydevices.com
--
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: KConfig and DTS files

[Olof Johansson]

Hi,

On Wed, May 7, 2014 at 10:12 AM, Eric Nelson
<eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> 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,

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.


-Olof
--
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: KConfig and DTS files

[Eric Nelson]

Hi Olof,

On 05/07/2014 10:24 AM, Olof Johansson wrote:
> Hi,
>
> On Wed, May 7, 2014 at 10:12 AM, Eric Nelson
> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
>> 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,
>
> 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.
>

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

Regards,


Eric
--
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: KConfig and DTS files

[Olof Johansson]

On Wed, May 7, 2014 at 10:47 AM, Eric Nelson
<eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> Hi Olof,
>
>
> On 05/07/2014 10:24 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Wed, May 7, 2014 at 10:12 AM, Eric Nelson
>> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
>>>
>>> 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,
>>
>>
>> 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.
>>
>
> 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

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?


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

Re: KConfig and DTS files

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Wed, May 07, 2014 at 10:55:27AM -0700, Olof Johansson wrote:
> 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?

I don't know wether it's actually good or not, but we're using just
this for the imx28-cfa* boards, and it works quite well.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: KConfig and DTS files

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

On Wed, May 07, 2014 at 10:55:27AM -0700, Olof Johansson wrote:
> On Wed, May 7, 2014 at 10:47 AM, Eric Nelson
> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> > Hi Olof,
> >
> >
> > On 05/07/2014 10:24 AM, Olof Johansson wrote:
> >>
> >> Hi,
> >>
> >> On Wed, May 7, 2014 at 10:12 AM, Eric Nelson
> >> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> >>>
> >>> 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,
> >>
> >>
> >> 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.
> >>
> >
> > 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
> 
> 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.

Um.. so I'm trying to work out exactly what you're getting at here.
dtc includes, just like CPP includes are dumb textual inclusion,
there's no theoretical difference between a "dts" and a "dtsi".  There
may be practical differences, though - like the presence of the
/dts-v1/ tag and possibly paths.

> 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?

So, I'm not sure quite what you're envisaging and how it differs from
what we have now.  Using the "overlay" functionality, you can right
now do

/include/ "thatotherdts.dts"

&{/somewhere/in/that/other/tree} {
	adjustable-property = "new value";
};

The only oddity here is that if thatotherdts.dts includes the /dts-v1/
tag, you can't have it in the outer file as well.

If it helps we could make that tag optionally appear any number of
times.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: KConfig and DTS files

[Arnd Bergmann]

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:
> 
>         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.

	Arnd
--
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: KConfig and DTS files

[Eric Nelson]

Thanks Arnd.

On 05/07/2014 11:10 AM, Arnd Bergmann wrote:
> 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:
>>
>>          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.
>

Easily is such a relative term ;)

Thanks for the advice.


Eric

--
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: KConfig and DTS files

[Arnd Bergmann]

On Wednesday 07 May 2014 11:35:12 Eric Nelson wrote:
> 
> On 05/07/2014 11:10 AM, Arnd Bergmann wrote:
> > 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:
> >>
> >>          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.
> >
> 
> 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.

	Arnd
--
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: KConfig and DTS files

[Eric Nelson]

Hi Arnd,

On 05/07/2014 11:38 AM, Arnd Bergmann wrote:
> On Wednesday 07 May 2014 11:35:12 Eric Nelson wrote:
>>
>> On 05/07/2014 11:10 AM, Arnd Bergmann wrote:
>>> 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:
>>>>
>>>>           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.
>>>
>>
>> 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.
>

It turns out not to be so difficult, but it is kinda quirky.

Once the fdt is loaded and the address set with "fdt addr",
the "fdt" command can print all or parts of the tree:

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

And you can read parts of it into variables. This example
sets the "v4lstat" variable to the value of /v4l2_out.status:

	U-Boot > fdt get value v4lstat /v4l2_out status

	U-Boot > echo $v4lstat
	okay

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";
	};

Regards,


Eric
--
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: KConfig and DTS files

[Arnd Bergmann]

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
> 
>         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".

	Arnd
--
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: KConfig and DTS files

[Eric Nelson]

Hi Arnd,

On 05/07/2014 12:15 PM, Arnd Bergmann wrote:
> 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
>>
>>          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".
>

For this particular use case, there's no need for the
conditional (the customer will have a custom boot script
anyway), but thanks for the tip about having the
default "disabled".

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

Separate from the case above, we have lots of customers
who re-purpose one or more of our connectors like our
parallel RGB display or parallel camera input and use the
pins for alternate functions.

There is a fine line about when this just becomes a different
"board" though, and DT makes that quite a bit easier.

Regards,


Eric
--
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: KConfig and DTS files

[Bjorn Andersson]

On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
<eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
[...]
>
> 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.

Regards,
Bjorn
--
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: KConfig and DTS files

[Eric Nelson]

Hi Bjorn,

On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
> On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> [...]
>>
>> 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?

Please advise,


Eric
--
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: KConfig and DTS files

[Arnd Bergmann]

On Wednesday 07 May 2014 16:06:49 Eric Nelson wrote:
> On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
> > On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
> > <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> > [...]
> >>
> >> 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?

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.

	Arnd
--
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: KConfig and DTS files

[Eric Nelson]

Hi Arnd,

On 05/08/2014 03:37 AM, Arnd Bergmann wrote:
> On Wednesday 07 May 2014 16:06:49 Eric Nelson wrote:
>> On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
>>> On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
>>> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
>>> [...]
>>>>
>>>> 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?
>
> 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.
>

I think this highlights the difference in perspective.

Your comments (and Bjorn's) reflect a goal of being able to
build a single kernel/DTB that runs on multiple platforms.

My goal(s) are quite different, and center on building
an optimized system for a single purpose. Most customers
of our boards target a single app, and essentially
all of them use a sub-set of a board's functionality.

We encourage them to optimize their kernel configurations to
only include the meaningful pieces, which reduces boot time and
memory usage, log file spew, et cetera. The same goes for userspace
components: only include what you need.

(Re)building the kernel is not seen as an onerous task, as it's
a small piece of the puzzle.

I appreciate the feedback, and I don't want to make a big
deal of this. We have ways of achieving the goal, even if
I do think that judicious use of #ifdef would be helpful.

Regards,


Eric
--
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: KConfig and DTS files

[Jason Cooper]

On Wed, May 07, 2014 at 04:06:49PM -0700, Eric Nelson wrote:
> Hi Bjorn,
> 
> On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
> >On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
> ><eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> >[...]
> >>
> >>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.

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. :)

hth,

Jason.
--
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: KConfig and DTS files

[Eric Nelson]

Hi Jason,

On 05/08/2014 04:55 AM, Jason Cooper wrote:
> On Wed, May 07, 2014 at 04:06:49PM -0700, Eric Nelson wrote:
>> Hi Bjorn,
>>
>> On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
>>> On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
>>> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
>>> [...]
>>>>
>>>> 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.
>
> 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.
>
Therein lies the rub...

In these days of SOCs with pin-muxing, a single description of
"the board" is overly simplistic.

> 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. :)
>
Again, this highlights differing goals.

My original question stemmed from a **desire** for customized
DTBs to reflect customization of a board. We have dozens
of custom and semi-custom versions of our tying these parts
together would make things a bit easier.

Regards,


Eric
--
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: KConfig and DTS files

[Jason Cooper]

Eric,

To add to what Olof said:

On Wed, May 07, 2014 at 10:24:46AM -0700, Olof Johansson wrote:
> Hi,
> 
> On Wed, May 7, 2014 at 10:12 AM, Eric Nelson
> <eric.nelson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> > 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,
> 
> 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 what your looking for is handled by the dtsi/dts paradigm (yeah,
I hate that word, but it fits).  Take the kirkwood.dtsi file for
example.  It lists a bunch of nodes with status = 'disabled'.  The
individual boardfiles then enable the nodes they actually have on the
board.

Say your family of boards used the kirkwood SoC, you could create a
kirkwood-bounddev.dtsi, then a kirkwood-bounddev-boardA.dts and so on
for each board.

The .dtsi lists all the nodes your product family uses.  The .dts
enables only those found on boardA.

If you have a node common to all products (say uart0) you could enable
it in the .dtsi and skip mentioning it in all the .dts board files.

Does that help?

thx,

Jason.
--
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