what's the "standard" for adding .dts patches to a BSP layer?

what's the "standard" for adding .dts patches to a BSP layer?

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

  thoughts? am i overthinking this?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what's the "standard" for adding .dts patches to a BSP layer?

[Gary Thomas]

On 2016-04-28 14:14, Robert P. J. Day wrote:
>
>    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?

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: what's the "standard" for adding .dts patches to a BSP layer?

[Robert P. J. Day]

On Thu, 28 Apr 2016, Gary Thomas wrote:

> On 2016-04-28 14:14, Robert P. J. Day wrote:
> >
> >    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?
>
> 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

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================