[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: Monday, March 11, 2013 11:24 AM
> To: Maupin, Chase
> Cc: Denys Dmytriyenko; Patches and discussions about the oe-core
> layer
> Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
> override order
> 
> On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase
> <chase.maupin at ti.com> wrote:
> >> -----Original Message-----
> >> From: otavio.salvador at gmail.com
> >> [mailto:otavio.salvador at gmail.com] On Behalf Of Otavio
> Salvador
> >> Sent: Saturday, March 09, 2013 6:11 AM
> >> To: Maupin, Chase
> >> Cc: Denys Dmytriyenko; 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 7:16 PM, Maupin, Chase
> >> <chase.maupin at ti.com> wrote:
> >> >> -----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?
> >>
> >> We can have more generic to more specific combinations.
> >>
> >> > 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?
> >>
> >> Exactly so we avoid duplication stuff to boards or SoCs.
> Another
> >> example of use: imx -> mx6q -> mx6.
> >
> > I see.  This could be of some use and I'll play with it.  This
> should not be required though for this patch since right now I
> want to fix the order issue.  Any objection to the patch as is?
> 
> No; not really. I just wanted to ask if you could look at it as
> well
> so we can have it working. It does make things much easier for
> all us.

Sure.  Btw, I noticed a weirdness when looking at this where the COMPATIBLE_MACHINE being evaluated evaulated/matched only has to be a substring of the SOC family to work.  For example if I have:

MACHINE = omap5-evm
SOC_FAMILY = omap-a15
COMPATIBLE_MACHINE = omap

Then this will work because "omap" (the COMPATIBLE_MACHINE) is a substring of SOC_FAMILY (and technically also a substring of omap5-evm)

Even setting COMPATIBLE_MACHINE to omap- will work because that is a substring of omap-a15.  So the "match" operation is not really precise enough.  I'm wondering if this needs to be changed to do an exact match.

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