[meta-freescale] VPU_EncGetVersionInfo failed

[Tim Harvey]

On Mon, Jul 14, 2014 at 10:11 AM, Allan Matthew <amatthew at 3drobotics.com> wrote:
> I believe I found the issue.  In my device tree I had the VPU supply set to
> pu_dummy when it should have been set to a regulator.  Seems to have fixed
> the issue.
>
> Allan Matthew
> Embedded Software Engineer, 3DRx
> 3D Robotics
> (858) 225-1414
> website | facebook | instagram

Alan,

This info was extremely helpful - I ran into this as well after
recently moving my boards to the 3.10.17_1.0.0-ga kernel. Note that I
also had to set system_rev based on the SOC type so that the imx-vpu
could determine the vpu firmware name... not clear where this was ever
set in Freescale's vendor kernel and thus if VPU even works on the
references boards with the 3.10.17 kernel.

Perhaps Freescale can shed some light on the subject? I'm wondering if
I'm completely misunderstanding the comments in the dts files or if
they are just plain wrong:

imx6qdl-sabresd.dtsi:
&vpu {
        pu-supply = <&pu_dummy>; /* ldo-bypass:use pu_dummy if VDDSOC
share with VDDPU */
};

The comment above seems to indicate that if you are using LDO-bypass
mode you would set this to pu-dummy. I think this comment is
backwards, and if you are bypassing the LDO you need to set to to
reg_pu (which is what I needed to do on my board to get the VPU
initialized properly).

imx6q-sabresd-ldo.dts:
&vpu {
        pu-supply = <&reg_pu>; /* ldo-bypass:use pu_dummy if VDDSOC
share with VDDPU */
};

Same comment, different choice. Is 'imx6q-sabresd-ldo.dts' the dtb for
sabresd 'using' the internal LDO or 'bypassing' the internal LDO's? We
are talking about multiple LDO's correct? (LDO_ARM on VDDARM*_CAP*
pins and LDO_SOC on VDDSOC_CAP* pins and LDO_PU on VDDPU_CAP* pins).
On our boards we provide our own VDD_ARM and VDD_SOC to VDDARM*_IN*
and VDDSOC_IN* pins to support the higher freq IMX6Q parts so I have
always assumed I am using 'ldo bypass' mode.

Please advise,

Regards,

Tim

>
>
> On Mon, Jul 14, 2014 at 7:36 AM, Lauren Post <Lauren.Post at freescale.com>
> wrote:
>>
>> Sorry I was wrong on my part numbers – that is a solo which does have a
>> VPU.  The DTS for solo and dual lite are the same.
>>
>>
>>
>> From: meta-freescale-bounces at yoctoproject.org
>> [mailto:meta-freescale-bounces at yoctoproject.org] On Behalf Of Lauren Post
>> Sent: Monday, July 14, 2014 9:28 AM
>> To: Allan Matthew
>> Cc: meta-freescale at yoctoproject.org
>> Subject: Re: [meta-freescale] VPU_EncGetVersionInfo failed
>>
>>
>>
>> On Fri, Jul 11, 2014 at 3:41 PM, Otavio Salvador <otavio at ossystems.com.br>
>> wrote:
>>
>> On Fri, Jul 11, 2014 at 6:08 PM, Allan Matthew <amatthew at 3drobotics.com>
>> wrote:
>> > I'm using a custom MCIMX6S5EVM10AC board and am having an issue with the
>> > vpuenc gstreamer plugin.  I'm able to otherwise use gstreamer plugins
>> > like
>> > mfw_v4lsink, tvsrc, mfw_isink etc but the vpu does not seem to be
>> > working.
>> > When invoking vpuenc with the h.264 codec, I get the following debug
>> > error
>> > from gst-launch:
>> >
>> >  0:00:02.613795334  1154   0x389920 ERROR                 vpuenc
>> > vpuenc.c:441:vpuenc_core_init: func VPU_EncGetVersionInfo failed!! with
>> > ret
>>
>>
>>
>> This part you are using is a i.MX 6 Solo Lite chip which does not have a
>> VPU.  That is why you are getting this failure.
>>
>>
>>
>>
>>
>>
>
>
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>