From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 69262E00A6C; Thu, 18 Jun 2015 09:38:36 -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.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -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 8F41AE00A31 for ; Thu, 18 Jun 2015 09:38:32 -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 824966002B73; Thu, 18 Jun 2015 19:38:31 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1434645511; bh=nESqy9WaByMV01XnZmFDjl8ZrxJbMzDA3KWYYOY5dJA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qE6CyB317RhQljYU0xWLylyd47MC1RTSkJtK6hgKl3u/vKxYQegc+IzT8323ED0BD UXtdcu1zZIb1ASxLdORqTKj57AjfCj5rpTy6aymFTfF8OTPXKjtqF/K9tlb6ek+sTU C4uKlRZ1BoLqLrpKerg9srsdctV3n9vXpUTIOmF4= Message-ID: <5582F407.5010803@mail.bg> Date: Thu, 18 Jun 2015 19:38:31 +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: Otavio Salvador References: <1434564146-11377-1-git-send-email-otavio@ossystems.com.br> <1434564146-11377-3-git-send-email-otavio@ossystems.com.br> <5581BC50.5020504@mail.bg> <5581BE95.9060009@mail.bg> <5581C98C.8060802@mail.bg> <5582E4A1.5070108@mail.bg> In-Reply-To: Cc: meta-freescale Mailing List Subject: Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe 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, 18 Jun 2015 16:38:36 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Otavio, On 06/18/2015 07:21 PM, Otavio Salvador wrote: > On Thu, Jun 18, 2015 at 12:32 PM, Nikolay Dimitrov > wrote: >> On 06/18/2015 04:58 PM, Otavio Salvador wrote: >>> >>> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini >>> wrote: >>>> >>>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador >>>> wrote: >>>>> >>>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov >>>>> wrote: >>>>>> >>>>>> So, in terms of functionality this kernel sits somewhere >>>>>> between mainline and FSL releases, is that correct? >>>>> >>>>> >>>>> Yes; it is FSL release + stable releases + vendor/community >>>>> fixes >>>> >>>> >>>> I've been thinking about this issue. And this provider (for >>>> imx6 only) may make sense to have "fslc" sufix, exactly >>>> because it has freescale + community patches >>>> >>>> However, the other (currently linux-fslc) does not make sense. >>>> Maybe linux-cmt makes more sense today. >>>> >>>> I remember one of the arguments to not use only "linux" and >>>> use a prefix was that it's not a pure mainline provider (it >>>> clones from github) and because it leave the "linux" only for >>>> internal kernels >>>> >>>> Any other suggestion? >>> >>> >>> I think we need to consider some things here: >>> >>> linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot >>> tree we maintain >>> >>> both have same goals and the idea is to provide a place to share >>> patches and backports. >>> >>> The motivation to make the 3.14 is because FSL is not taking the >>> fixes and security updates from stable, so a place to merge >>> those seems to be beneficial. I don't want a plethora of names >>> as it makes harder for people to contribute and share work so I >>> propose two solutions: >>> >>> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb >>> >>> or >>> >>> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb >>> >>> Both works. >> >> >> Thanks for sharing your ideas, this helps me to understand somewhat >> better the motivation behind creating these linux kernel >> providers. >> >> So, my comments are not to oppose any changes/improvements at all, >> but just to add a more global perspective on where the Yocto kernel >> providers fit in the long chain between mainline and the OEM: >> >> 1. linux-mainline ----------------- Good generic imx6 support, no >> support for ASRC, VPU. Regarding the GPU - Jon Nettleton is >> working on the etnaviv code, so probably some day we'll have a >> fully open GPU support there. Until then - no GPU support in >> mainline, only basic FB on hdmi/lvds (parallel lcd probably also >> works, but I haven't tested it). Supported by the kernel >> developers. >> >> 2. linux-fslc ------------- Almost mainline. Here we collect >> patches that either will take very long to be applied in mainline, >> or are inappropriate for mainline (but still useful for Yocto >> users). As stability and features should be as good mainline, if >> not slightly better due to custom fixes for Yocto. Supported by >> Yocto community. >> >> 3. linux-as-proposed-by-otavio ------------------------------ >> Man-in-the middle. Forward-ported FSL code, back-ported important >> patches from mainline. Probably something like "linux-imx-next". >> Who will support this code? >> >> 4. linux-imx ------------ THE FSL kernel. Freescale's team is >> doing a great job, and there are more or less regular releases with >> good overall quality. It's quite normal/expected that this kernel >> version will always lag behind mainline. One thing which bothers >> me is that there's no way for the community to interact with the >> FSL BSP team, which means no transparent way to >> submit/track/resolve issues. This same role is currently being >> played by the Yocto community due to several individuals who have >> internal access to the FSL BSP team and can help pushing through >> issues. Supported by Yocto community (including FSL engineers). >> >> >> So, even if I like the idea that #3 will have newer code than #4, >> the main question is who will support it (support means both >> development and validation)? > > #2 linux-fslc is a tree to host fslc modified kernels. It has no > compromise to be mainline only. > > #3 allow us to share work among vendors and bring fixes while reusing > the work done by FSL BSP team, board vendors and community. > > #4 has no support; as soon you port it to your board it is > non-supported kernel. As soon you move away of their BSP release it > is non-supported kernel and plus it does not have patches applied > once tagged (nor security or fixes) so any change needs to wait for > next GA. > > To be honest, FSL does not apply fixes until next GA so there is no > way to improve their kernel, u-boot, whatever. We try to fill the gap > here and avoid work duplication. > > The amount of duplicated work done by board vendors is insane, I am > trying to improve it as much as I can. I see, and fully agree with the explanations. My current understanding (could be wrong) is that the current FSL drivers in 3.14.28 are not possible to be rebased to newer mainline kernels, is that correct? That's why I commented about the possible confusion, as for me it's good to see in the kernel name whether it has or has not support for the SoC bells/whistles (-mainline/-fslc vs -imx). If my assumption is wrong and these drivers *can* be rebased while retaining compatibility with the binary blobs, than probably #2 and #3 start to look like something that can be merged (what Daiane said also). Regards, Nikolay