[PATCH] soc-family: fix SOC_FAMILY override order

[PATCH] soc-family: fix SOC_FAMILY override order

[Chase Maupin]

* 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@ti.com>
---
 meta/conf/machine/include/soc-family.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/soc-family.inc b/meta/conf/machine/include/soc-family.inc
index 612039c..0251da0 100644
--- a/meta/conf/machine/include/soc-family.inc
+++ b/meta/conf/machine/include/soc-family.inc
@@ -1,2 +1,2 @@
 # Add SOC_FAMILY to machine overrides so we get access to e.g. 'omap3' and 'ti335x'
-MACHINEOVERRIDES .= "${@['', ':${SOC_FAMILY}']['${SOC_FAMILY}' != '']}"
+MACHINEOVERRIDES =. "${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}"
-- 
1.7.0.4

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin <Chase.Maupin@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@ti.com>

Maybe while on that you could look at supporting xx:yy as SoC family?
like am37xx:am3715 ?

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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Denys Dmytriyenko]

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

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.

-- 
Denys

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Fri, Mar 8, 2013 at 5:06 PM, Denys Dmytriyenko <denis@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@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@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.

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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Maupin, Chase]

> -----Original Message-----
> From: otavio.salvador@gmail.com
> [mailto:otavio.salvador@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@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@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@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@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854
> http://projetos.ossystems.com.br

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com
>> [mailto:otavio.salvador@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@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@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@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.

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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Maupin, Chase]

> -----Original Message-----
> From: otavio.salvador@gmail.com
> [mailto:otavio.salvador@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@ti.com> wrote:
> >> -----Original Message-----
> >> From: otavio.salvador@gmail.com
> >> [mailto:otavio.salvador@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@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@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@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?

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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com
>> [mailto:otavio.salvador@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@ti.com> wrote:
>> >> -----Original Message-----
>> >> From: otavio.salvador@gmail.com
>> >> [mailto:otavio.salvador@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@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@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@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.

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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Maupin, Chase]

> -----Original Message-----
> From: otavio.salvador@gmail.com
> [mailto:otavio.salvador@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@ti.com> wrote:
> >> -----Original Message-----
> >> From: otavio.salvador@gmail.com
> >> [mailto:otavio.salvador@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@ti.com> wrote:
> >> >> -----Original Message-----
> >> >> From: otavio.salvador@gmail.com
> >> >> [mailto:otavio.salvador@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@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@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@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@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854
> http://projetos.ossystems.com.br

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Denys Dmytriyenko]

On Mon, Mar 11, 2013 at 06:03:25PM +0000, Maupin, Chase wrote:
> > -----Original Message-----
> > From: otavio.salvador@gmail.com
> > [mailto:otavio.salvador@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@ti.com> wrote:
> > >> -----Original Message-----
> > >> From: otavio.salvador@gmail.com
> > >> [mailto:otavio.salvador@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@ti.com> wrote:
> > >> >> -----Original Message-----
> > >> >> From: otavio.salvador@gmail.com
> > >> >> [mailto:otavio.salvador@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@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@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@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)$"

-- 
Denys

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Mon, Mar 11, 2013 at 3:52 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> On Mon, Mar 11, 2013 at 06:03:25PM +0000, Maupin, Chase wrote:
>> > -----Original Message-----
>> > From: otavio.salvador@gmail.com
>> > [mailto:otavio.salvador@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@ti.com> wrote:
>> > >> -----Original Message-----
>> > >> From: otavio.salvador@gmail.com
>> > >> [mailto:otavio.salvador@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@ti.com> wrote:
>> > >> >> -----Original Message-----
>> > >> >> From: otavio.salvador@gmail.com
>> > >> >> [mailto:otavio.salvador@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@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@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@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@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Richard Purdie]

On Mon, 2013-03-11 at 13:24 -0300, Otavio Salvador wrote:
> On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase <chase.maupin@ti.com> wrote:
> >> On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase
> >> 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.

As pointed out this already merged.

I'd also point out that you can use MACHINEOVERRIDES directly to specify
additional machine overrides so I'm not sure there is much extra
complexity here that is really needed.

Cheers,

Richard

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Otavio Salvador]

On Tue, Mar 12, 2013 at 3:19 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2013-03-11 at 13:24 -0300, Otavio Salvador wrote:
>> On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> >> On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase
>> >> 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.
>
> As pointed out this already merged.
>
> I'd also point out that you can use MACHINEOVERRIDES directly to specify
> additional machine overrides so I'm not sure there is much extra
> complexity here that is really needed.

Yes I can do it using machine overrides but it does seem to be clear
for someone reading the code if it is included in SOC_FAMILY.

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

Re: [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@gmail.com
> > [mailto:otavio.salvador@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@ti.com> wrote:
> > >> -----Original Message-----
> > >> From: otavio.salvador@gmail.com
> > >> [mailto:otavio.salvador@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@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@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@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

Re: [PATCH] soc-family: fix SOC_FAMILY override order

[Maupin, Chase]

[snip]

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

I see.  Thanks.  What are the chances of this getting picked up into Danny or is this too risky of a change for the stable branch?

> 
> --
> Denys