From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vms173001pub.verizon.net ([206.46.173.1]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1UF9s1-00084Y-33 for openembedded-core@lists.openembedded.org; Mon, 11 Mar 2013 22:03:01 +0100 Received: from gandalf.denix.org ([unknown] [108.45.150.102]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MJI0087XKCDPVG0@vms173001.mailsrvcs.net> for openembedded-core@lists.openembedded.org; Mon, 11 Mar 2013 15:46:00 -0500 (CDT) Received: by gandalf.denix.org (Postfix, from userid 1000) id 697E1200A9; Mon, 11 Mar 2013 16:45:49 -0400 (EDT) Date: Mon, 11 Mar 2013 16:45:49 -0400 From: Denys Dmytriyenko To: "Maupin, Chase" Message-id: <20130311204549.GC31635@denix.org> References: <1362765064-27663-1-git-send-email-Chase.Maupin@ti.com> <20130308200628.GB15481@denix.org> <7D46E86EC0A8354091174257B2FED1015944E4E0@DLEE12.ent.ti.com> <7D46E86EC0A8354091174257B2FED101594532C3@DLEE12.ent.ti.com> MIME-version: 1.0 In-reply-to: <7D46E86EC0A8354091174257B2FED101594532C3@DLEE12.ent.ti.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Otavio Salvador , Patches and discussions about the oe-core layer Subject: Re: [PATCH] soc-family: fix SOC_FAMILY override order X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:03:40 -0000 Content-type: text/plain; charset=us-ascii Content-disposition: inline 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 > > 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 > > >> 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 > > >> 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 > > >> >> > > >> >> 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