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

[Otavio Salvador]

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.

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