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

[Otavio Salvador]

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.

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