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

[Otavio Salvador]

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.

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