[meta-freescale] [meta-fsl-arm][PATCH 11/14] imx-vpu: Upgrade to 3.10.31-1.1.0 Beta

[John Weber]

On 8/31/14, 2:15 PM, Otavio Salvador wrote:
> On Sun, Aug 31, 2014 at 12:25 AM, Lauren Post <Lauren.Post at freescale.com> wrote:
>> We prefer this to match our BSP version not internal version.
> I certainly prefer it to map to the real version; we had same
> situation on the MM modules and we now overcome it, could we do
> another small step in the right direction?
>
I've been following the comments from Otavio and Daiane, and wanted to offer my 
opinion here, for what it is worth.

My understanding is that you have a version for the VPU libaries (and others) 
that you use internally (in this case 5.4.26), but the bb file you want to plug 
into the fsl-community-bsp is named for a tested kernel version (in this case, 
3.10.31_1.1.0).

However, when a user starts an application with those libraries (gst-launch for 
example, using a vpuenc element), they would see your internal version number 
pop up.  For example:

vpuenc versions :)
     plugin: 3.0.11
     wrapper: 1.0.46(VPUWRAPPER_ARM_LINUX Build on Aug 30 2014 15:33:08)
     vpulib: 5.4.23
     firmware: 3.1.1.46056

I contend that this could cause some confusion, don't you?  They are 
including/building an OE package with one version, but their system reports 
something different, and they have to then resolve the two different versions.

Another reason to consider going a different path is that naming them after a 
kernel release (as implied by the 3.10.31_1.1.0 name), implies (to me) that 
these are only tested and will work on the corresponding kernel version.  They 
might not always be the case, if there are no changes to the programming interfaces.

John