[meta-freescale] [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe

[Ann Thornton]

Thanks for the kind words, Nikolay.  We are trying to respond more quickly.

Ann Thornton

On 6/18/2015 10:32 AM, Nikolay Dimitrov wrote:
> Hi Daiane, Otavio,
>
> On 06/18/2015 04:58 PM, Otavio Salvador wrote:
>> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini
>> <daiane.list at gmail.com> wrote:
>>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
>>> <otavio at ossystems.com.br> wrote:
>>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov
>>>> <picmaster at mail.bg> 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)?
>
> Regards,
> Nikolay


-- 
Ann Thornton

/Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton at freescale.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20150618/7606c9eb/attachment.html>