what's the "standard" for adding .dts patches to a BSP layer?
looking for common practice here ... what's the canonical way that
one should add content to a .dts file for a new board -- all at once, or broken into patches associated with corresponding .scc files that come into play only if one selects that functionality?
i ask since i'm a big fan of modularity, but that doesn't seem to
work very well here. if i start with a baseline .dts file, and break the rest into optional patches, then based on what a developer selects for his build, some of those patches simply aren't going to apply very cleanly.
it would, of course, be easier to just add everything even
potentially necessary to the single .dts file, since that's not really adding any actual functionality, just adding more detailed information about the target board (even if it's never used).
thoughts? am i overthinking this?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 12 lines · Robert P. J. Day
looking for common practice here ... what's the canonical way that
one should add content to a .dts file for a new board -- all at once, or broken into patches associated with corresponding .scc files that come into play only if one selects that functionality?i ask since i'm a big fan of modularity, but that doesn't seem to
work very well here. if i start with a baseline .dts file, and break the rest into optional patches, then based on what a developer selects for his build, some of those patches simply aren't going to apply very cleanly.
Quoted 6 lines
it would, of course, be easier to just add everything even
potentially necessary to the single .dts file, since that's not really adding any actual functionality, just adding more detailed information about the target board (even if it's never used).thoughts? am i overthinking this?
One common way is to have a .dts (or .dtsi) file that includes all of the sections you might want, but leave them disabled, hence not changing the actual setup. Then add snippets (via .scc or patch) that enable the sections. This is how the i.MX6 space (FreeScale/NXP boards and products) is managed.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 18 lines · Gary Thomas
Quoted 17 lines · Robert P. J. Day
looking for common practice here ... what's the canonical way
that one should add content to a .dts file for a new board -- all at once, or broken into patches associated with corresponding .scc files that come into play only if one selects that functionality?i ask since i'm a big fan of modularity, but that doesn't seem
to work very well here. if i start with a baseline .dts file, and break the rest into optional patches, then based on what a developer selects for his build, some of those patches simply aren't going to apply very cleanly.it would, of course, be easier to just add everything even
potentially necessary to the single .dts file, since that's not really adding any actual functionality, just adding more detailed information about the target board (even if it's never used).
Quoted 7 lines
Quoted 1 line
thoughts? am i overthinking this?
One common way is to have a .dts (or .dtsi) file that includes all of the sections you might want, but leave them disabled, hence not changing the actual setup. Then add snippets (via .scc or patch) that enable the sections. This is how the i.MX6 space (FreeScale/NXP boards and products) is managed.
i'm not sure that's a total solution, for the following general
reason, which might be completely idiotic if i'm misunderstanding something.
if i have *any* text file for which i can apply some subset of
possible changes, and those changes are geographically close to each other, it seems possible that i'll have conflicting patches trying to be applied next to each other, no? i tried something like that a while back, and that's exactly what happened.
as a trivial example (and, again, maybe i'm being clueless about
this and missing an easy solution), say i have two possible lines i can add to the end of a text file via patches -- patch 1 appends the line:
#include feature1
while patch 2 appends the line
#include feature2
won't i run into trouble based on whether i apply one patch, or the other, or both? certainly, in some circumstances, *some* patch application is going to fail. this seems like a simple example of the more general issue -- it's probably a bad idea to allow the conditional application of a set of patches to the same text file.
the simplest solution i've come up with to retain some semblance of
modularity is to have a base .dts file, then a number of specific .dtsi files, and just flat out include those .dtsi files, whether i need them or not. or am i missing something obvious?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================