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

[Denys Dmytriyenko]

On Mon, Mar 11, 2013 at 02:49:20PM +0000, Maupin, Chase 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?

BTW, this was already pushed:

http://cgit.openembedded.org/openembedded-core/commit/?id=0b836b9d79255a5b2f358fe718c67638f52ecf72

-- 
Denys