From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id A90E2E009D7; Thu, 9 Jul 2015 08:20:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id EFD0CE009A7 for ; Thu, 9 Jul 2015 08:20:24 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id C56A460075E9; Thu, 9 Jul 2015 18:20:14 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1436455214; bh=TM2wkgv9muXzRYTgzInXoy42cNzev8WTHE53jsMO20U=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=y7v/4kZ8SH7RrtPwJqH21bT+vzsn6pTiSfc9CjJmvkaI+2/f4dFa3ekNExJK9oZjt zSRKx0MaxgoLho0/ITN39va+y63+kIqB9XvV+rdF+L6F7VdSrfVUQnlBRoTH8p4ITq xYqWLNPWlujSb3yV+II5mvVObnf8UuHMoLMK9SE4= Message-ID: <559E912E.5030800@mail.bg> Date: Thu, 09 Jul 2015 18:20:14 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Daiane Angolini , Otavio Salvador References: In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: SOC_FAMILY Rework X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 15:20:29 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daiane, On 07/09/2015 05:54 PM, Daiane Angolini wrote: >> It does not work. The point of OVERRIDE is to make changes in a set of >> SoCs and we cannot contaminate other BSP (Intel, TI, Samsung, >> Qualcomm...) > > GPU is a SoC characteristic, and it's obvious it's the most important > BSP piece on i.MX6 family. Instead of having a tree like: > > imx -> imx6 -> everysingle soc > > We could have something like: > > imx -> imx6-light -> ligh socs > imx -> imx6-heavy -> heavy socs > > and, instead of list "everysingle soc" when setting GPU BSP, we can > list only "light and heavy". > > The downside is to list "light and heavy" in packages for imx6 > > > I don't see how it will contaminate other BSP. I'm trying to stress > the imx OVERRIDE just included. This is an excellent example. The OVERRIDEs should generalize, not specialize (although you can always interpret a root-leaf traversal as a specialization :D). Detailed specialization will lead to OVERRIDEs tree explosion while trying to express every single SOC feature on each level of the tree. If we try to express SOC features via OVERRIDE mechanism, it's imho doomed. Regards, Nikolay