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

Mon Mar 11 19:09:37 UTC 2013

On Mon, Mar 11, 2013 at 3:52 PM, Denys Dmytriyenko <denis at denix.org> wrote:
> On Mon, Mar 11, 2013 at 06:03:25PM +0000, Maupin, Chase wrote:
>> > -----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.
>
> COMPATIBLE_MACHINE is a regular expression and after thinking about it some
> more and digging around, I believe it was implemented that way on purpose, to
> be as inclusive as possible, so you can do things like "nokia(800|770)" or
> what I do in Arago - "(?!arago)". Or in case of COMPATIBLE_HOST it could be
> "^(i.86|x86_64|powerpc).*-linux". So, if you need an exact match, then specify
> it with the regular expression syntax:
>
> COMPATIBLE_MACHINE = "^omap$"
>
> The above won't match either of the examples you provided above, unless
> MACHINE or SOC_FAMILY are specifically set to "omap".
>
> For multiple entries in COMPATIBLE_MACHINE, use "^(omap|davinci)$"

The only change I think we need is to pass, for the parser, each value
of SOC_FAMILY, so the regexp is applied to each value.

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