From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id DF28EE00A54; Fri, 10 Jul 2015 04:59:23 -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 * (daiane.list[at]gmail.com) * -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 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.217.170 listed in list.dnswl.org] Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 94791E009D6 for ; Fri, 10 Jul 2015 04:59:19 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so6317633lbb.0 for ; Fri, 10 Jul 2015 04:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Mh4LiIlLhPCAWNrDo0Pc+O8v2Zg90CFn7rS11fPYq8A=; b=eBnJR8KAMKMuGLbY7Ezx6aYRQ2hXjnq7+1/EA6GopLubZNx6fDP1YNbGZUIkyPs3Us XSO93pxftssvSYsiBAMUOXx+6WaxBBIHtR19oXOASvpcITOULLz0q86tZj3YRt4HsYwk t8TGcE1D5LEdQKIgqJm+FBXd1F9xGMEvjVzSy0pzWEiaduaJIVleDGL4hTaBUCHjlKsX qOmj2XgK9yFg/Z3DtqOZ/lOe9gH9keD9X/OxmH9M1L2wAPfwmCnXQiSalIx/f5j5AkW7 5fBEwmUIQH2KmghGNJA2rwajgmPLfZd22XweeJVGWWR8FU4DM0lJ9YFigpTQo+6ttSCv vgWg== MIME-Version: 1.0 X-Received: by 10.152.10.72 with SMTP id g8mr19279893lab.97.1436529558055; Fri, 10 Jul 2015 04:59:18 -0700 (PDT) Sender: angolini@gmail.com X-Google-Sender-Delegation: angolini@gmail.com Received: by 10.114.81.106 with HTTP; Fri, 10 Jul 2015 04:59:17 -0700 (PDT) In-Reply-To: <559E912E.5030800@mail.bg> References: <559E912E.5030800@mail.bg> Date: Fri, 10 Jul 2015 08:59:17 -0300 X-Google-Sender-Auth: a2eVmrvCBgRvjUkg7KO9h42Bje4 Message-ID: From: Daiane Angolini To: Nikolay Dimitrov Cc: "meta-freescale@yoctoproject.org" , Otavio Salvador 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: Fri, 10 Jul 2015 11:59:23 -0000 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 9, 2015 at 12:20 PM, Nikolay Dimitrov wrote: > 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. The problem is that the i.MX6 shares only the name and the core. And share the core is nothing (as i.MX can share the ARM core of any other product in the world) It's like i.MX6UL was the adopted brother. It shares the name but no genetic features. Of course we can use the marketing name on OVERRIDE, but I would prefer if we focus on the SoC convergence instead. > > If we try to express SOC features via OVERRIDE mechanism, it's imho > doomed. I have a crush on philosophy, so I apologize in advance. But i.MX is basicaly it's GPU. Mainly if you think about i.MX6. Represent GPU characteristics on OVERRIDE is not represent a feature, but a core feature. However, I remember Otavio's argument i.MX6 is the exception now, not the rule. Daiane > > Regards, > Nikolay