[OE-core] [PATCH] soc-family: fix SOC_FAMILY override order

[Maupin, Chase]

> -----Original Message-----
> From: otavio.salvador at gmail.com
> [mailto:otavio.salvador at gmail.com] On Behalf Of Otavio Salvador
> Sent: Friday, March 08, 2013 2:27 PM
> To: Denys Dmytriyenko
> Cc: Maupin, Chase; Patches and discussions about the oe-core
> layer
> Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
> override order
> 
> On Fri, Mar 8, 2013 at 5:06 PM, Denys Dmytriyenko
> <denis at denix.org> wrote:
> > On Fri, Mar 08, 2013 at 03:52:57PM -0300, Otavio Salvador
> wrote:
> >> On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin
> <Chase.Maupin at ti.com> wrote:
> >> > * the current order has SOC_FAMILY settings, which are
> generic
> >> >   settings for a group of devices, overriding the machine
> specific
> >> >   settings.  For example:
> >> >
> >> >   KERNEL_DEVICETREE_ti33x = "xxxx"
> >> >   KERNEL_DEVICETREE_beaglebone = "yyyy"
> >> >
> >> >   Should yield "yyyy" when building for the beaglebone
> because
> >> >   that is a more specific device than ti33x.  However,
> without this
> >> >   change the result is that the value is set to "xxxx"
> meaning the
> >> >   more generic setting overrides the more specific setting.
> >> >
> >> > Signed-off-by: Chase Maupin <Chase.Maupin at ti.com>
> >>
> >> Maybe while on that you could look at supporting xx:yy as SoC
> family?
> >> like am37xx:am3715 ?
> >
> > Did you mean am3517? That's a slightly different variant of
> am35x/omap35x SoC.
> 
> Yes; sorry ... what I meant was 'am35xx:am3517'
> 
> > But if you really meant am3715 (as well as am3705, am3725 and
> am3730), then
> > those are variants of am37x SoC, just with some subsystems,
> like SGX or DSP,
> > being absent or present. Having those variants handled by
> SOC_FAMILY would be
> > an overkill. Instead, we've started using MACHINE_FEATURES to
> distinguish
> > between those variants of the same SoC, by checking for "sgx"
> and/or "dsp"
> > flags there and pulling in needed software components
> accordingly.
> 
> My main concern here is that COMPATIBLE_MACHINE also parses
> SOC_FAMILY
> however if you have two (as the 'am35xx:am3517') it is going to
> fail;
> it could split it and parse it individually.

Sorry, I'm not sure if I'm following here.  Are you saying you would find it useful to have support for a MACHINE to have more than one SOC_FAMILY?  In the example above I would have expected that you would have a machine config file for am3517 which has an SOC_FAMILY of am35xx.  Why would you specify two SOC_FAMILY values per machine?

Or are you trying to build something like omap3->am35xx->am3517 where you can use omap3 as a more generic setting but still use am35xx for a slightly more restrictive group that is still grouping like parts, and finally you use am3517 for the exact part?

> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854
> http://projetos.ossystems.com.br