[meta-freescale] [meta-fsl-arm-extra PATCH 2/2] linux-boundary: Add support to Vivante 4.6.9p12 GPU code

[Eric Nelson]

On 08/12/2013 09:45 AM, Daiane Angolini wrote:
> On 08/12/2013 01:34 PM, Otavio Salvador wrote:
>> On Mon, Aug 12, 2013 at 12:48 PM, Eric Nelson
>> <eric.nelson at boundarydevices.com> wrote:
>>> On 08/12/2013 08:18 AM, Otavio Salvador wrote:
>>>>
>>>> On Mon, Aug 12, 2013 at 11:05 AM, Eric Nelson
>>>> <eric.nelson at boundarydevices.com> wrote:
>>>>>
>>>>> On 08/12/2013 05:50 AM, Otavio Salvador wrote:
>>>>>>
>>>>>> On Sat, Aug 10, 2013 at 7:12 PM, Eric Nelson
>>>>>> <eric.nelson at boundarydevices.com> wrote:
>>>>>>>
>>>>>>> Right now, gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.bin only supports hard
>>>>>>> float. Will the EABI (4.0.0) binaries continue to be supported or
>>>>>>> will there be a corresponding package of EABI binaries?
>>>>>>
>>>>>>
>>>>>> There's also a gpu-viv-bin-mx6q-3.5.7-1.0.0-sfp.bin and it is
>>>>>> taken in
>>>>>> case you're building for Soft Float-Point. It should 'Just Work'.
>>>>>>
>>>>>
>>>>> If that's the case, we can just push the patches onto our
>>>>> main branch and not deal with the old/new GPU package question.
>>>>
>>>> Not really as it will make impossible for your customers to use the
>>>> kernel with LTIB at 4.0.0 BSP (well, I'd love they stop using it
>>>> but...).
>>>>
>>>
>>> It's not just LTIB that's a question mark. The same comment
>>> goes for Debian, Buildroot, Timesys, Ubuntu, Arch or home-brew
>>> userspaces.
>>>
>>> If it's Freescale's recommendation that this GPU package is
>>> the **right** one for production use, our primary kernel
>>> branch should probably reflect that.
>>
>> I think the recommendation is to stay in their 'official' and 'test'
>> set of packages so I think it is better to have p12 support as patches
>> so it is clear it is something we are doing 'by ourselves'.

Okay. I didn't mean to open a can of worms here. I was just trying
to simplify things.

>
> 3.5.7-1.0.0 - is an alpha release. It does not have the same "stability"
> comparing with a GA release. It is not shared with *all* customers.
>

My bad. I figured since patches were being released into the wild,
this is officially "shared".

>>
>>> There's no reason someone using another userspace builder
>>> can't patch their process to update things.
>>
>> Well yes but it makes their life harder and a branch which won't work
>> with 'official' package set. So I think patches are the way to go for
>> now.
>>
>>> That said, I haven't quite heard this as Freescale's recommendation.
>>> Daiane, I don't suppose you want to stick your neck out...?
>>
>> Poor Daiane ;-)

I'm not trying to get you in trouble, Daiane. Just trying to grok
the current status.

>
> When I'm talking to meta-freescale I'm "Freescale". When I'm talking to
> guys inside Freescale, I'm "community".
>

But but but, we're all the "community", right?

We're all trying to get the best stuff into end-users' hands so they
can build great applications with a minimum of hassle!

> Here, I can only say public and official stuff. If you need Freescale's
> help, please enter a SR or a question on imx-community.
>
> =(
>

Sounds scary! Like there may be lawyers trolling there ;)

Regards,


Eric