Re: KConfig and DTS files

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