Re: platform: coda: how to use firmware-imx binary releases?
On 2017-10-05 17:45, Philipp Zabel wrote:
> On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
>> Hi,
>>
>> Commit
>>
>> be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
>> and
>> 3.1.1 as supported
>>
>> says firmware version 3.1.1 revision 46072 is contained in
>> "firmware-imx-5.4.bin", that's probably
>>
>> sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-
>> 5.4.bin
>>
>> How do I use this in order to get a VPU firmware blob that the coda
>> platform driver can work with?
>>
>>
>>
>> (Maybe it'd be worth adding some short documentation on this. There
>> doesn't seem to be a devicetree bindings doc for coda in
>> Documentation/devicetree/bindings/media
>
> I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
> It was added in commit 657eee7d25fb ("media: coda: use genalloc API").
Right. Not greppable with "coda". If you've also missed it because of
that, it might likely help others when "coda" is mendtioned in it :)
Re: platform: coda: how to use firmware-imx binary releases?
On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
> Hi,
>
> Commit
>
> be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
> and
> 3.1.1 as supported
>
> says firmware version 3.1.1 revision 46072 is contained in
> "firmware-imx-5.4.bin", that's probably
>
> sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-
> 5.4.bin
>
> How do I use this in order to get a VPU firmware blob that the coda
> platform driver can work with?
>
>
>
> (Maybe it'd be worth adding some short documentation on this. There
> doesn't seem to be a devicetree bindings doc for coda in
> Documentation/devicetree/bindings/media
I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
It was added in commit 657eee7d25fb ("media: coda: use genalloc API").
regards
Philipp
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 16:10 schrieb Nicolas Dufresne: Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit : > This message is most likely just a result of the VDOA not supporting > the > selected capture format. In vdoa_context_configure, you can see that > the > VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink A bit unrelated, but kmssink remains a better choice here. True, but I'm currently not yet interested in the other end of the pipe :) Decoding works in principal. VDOA is still disabled however :( I don't see what I can do about this right now, which is a bit odd. It is definitely probed (and not removed). I see at least a few frames of the video, so I guess the video file is fine? Or could it be a file (or pixel) format that isn't supported? Again, ffprobe says Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc thanks After this, I want to have video conversion (color space) via a v4l2 interface that in turn uses the imx6 IPU. I guess gst-inspect-1.0 should see a V4L2 Converter, which it currently doesn't here: # gst-inspect-1.0 | grep v4l2 video4linux2: v4l2video1dec: V4L2 Video Decoder video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2src: Video (video4linux2) Source # dmesg | grep ipu [1.394717] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 0xc07d4b60) [1.402258] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 0xc07d4b60) [1.514984] imx-ipuv3 240.ipu: IPUv3H probed should imx-ipuv3 provide a video4linux2 interface for video conversion? At least I don't see it yet. (or other V4L2 Linux config options than I already have enabled)
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit : > > This message is most likely just a result of the VDOA not supporting > > the > > selected capture format. In vdoa_context_configure, you can see that > > the > > VDOA only writes YUYV or NV12. > > ok. I'll have to look into it, and just in case you see a problem on > first sight: > this is what coda says with debug level 1, when doing > > gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 > video-sink=fbdevsink A bit unrelated, but kmssink remains a better choice here. Nicolas
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 10:19 schrieb Philipp Zabel: Hi Martin, On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote: I'm running a little off-topic here, but with the newest firmware too, my coda driver says "Video Data Order Adapter: Disabled" when started by video playback via v4l2. This message is most likely just a result of the VDOA not supporting the selected capture format. In vdoa_context_configure, you can see that the VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink with the video file being (ffprobe) Input #0, h264, from 'test2_hd480.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc after some s_ctrl: id/val printings: [ 98.833023] coda 204.vpu: Created instance 0 (cefc5000) [ 98.837550] coda 204.vpu: Releasing instance cefc5000 [ 98.839080] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.839091] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.839100] coda 204.vpu: Created instance 0 (ceeb2000) [ 98.842867] coda 204.vpu: Releasing instance ceeb2000 [ 98.845435] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.845447] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.845458] coda 204.vpu: Created instance 0 (cefc5000) [ 98.851652] coda 204.vpu: Setting format for type 2, wxh: 852x480, fmt: H264 L [ 98.851670] coda 204.vpu: Setting format for type 1, wxh: 852x480, fmt: NV12 T [ 98.854800] coda 204.vpu: get 2 buffer(s) of size 819200 each. [ 99.022191] coda 204.vpu: get 2 buffer(s) of size 622080 each. [ 99.025904] coda 204.vpu: Video Data Order Adapter: Disabled [ 99.025922] coda 204.vpu: H264 Profile/Level: High L3 [ 99.026214] coda 204.vpu: __coda_start_decoding instance 0 now: 864x480 [ 99.036277] coda 204.vpu: 0: not ready: need 2 buffers available (1, 0) [ 99.063157] coda 204.vpu: job ready so while the video is shown, the VDOA is "disabled". thanks a lot for your help (it's shown far from fluent yet, almost frame by frame, but that's ok for now... I'll still need to took into the v4l2 interface for the imx6 IPU) (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed, a dev_info "probed" would maybe be useful for others too?) It supsequently fails with cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12 That is -ENOMEM. Is CMA enabled and sufficiently large? For example, CONFIG_CMA=y CONFIG_CMA_DEBUGFS=y CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=256 CONFIG_CMA_SIZE_SEL_MBYTES=y My cma buffer size was indeed just too small.
Re: platform: coda: how to use firmware-imx binary releases?
Hi Martin, On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote: > I'm running a little off-topic here, but with the newest firmware too, > my > coda driver says "Video Data Order Adapter: Disabled" when started > by video playback via v4l2. This message is most likely just a result of the VDOA not supporting the selected capture format. In vdoa_context_configure, you can see that the VDOA only writes YUYV or NV12. > (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed, > a dev_info "probed" would maybe be useful for others too?) > > It supsequently fails with > > cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12 That is -ENOMEM. Is CMA enabled and sufficiently large? For example, CONFIG_CMA=y CONFIG_CMA_DEBUGFS=y CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=256 CONFIG_CMA_SIZE_SEL_MBYTES=y > which may or may not be related to having the vdoa (is it?), but > shouldn't the VDOA module be active by default? > > # cat /sys/module/coda/parameters/disable_vdoa > 0 I think it is not related to VDOA at all. Yes, by default the VDOA should be activated automatically for any supported format. regards Philipp
Re: platform: coda: how to use firmware-imx binary releases?
Am 04.10.2017 11:22 schrieb Philipp Zabel: Hi Martin, On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote: Hi, Commit be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 3.1.1 as supported says firmware version 3.1.1 revision 46072 is contained in "firmware-imx-5.4.bin", that's probably sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-5.4.bin Yes. How do I use this in order to get a VPU firmware blob that the coda platform driver can work with? These are self-extracting shell scripts with an attached compressed tar archive. This particular file can be extracted by skipping the first 34087 bytes: dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv thanks! (Maybe it'd be worth adding some short documentation on this. There doesn't seem to be a devicetree bindings doc for coda in Documentation/devicetree/bindings/media which would be a good place for documenting how to use these binaries too) Thank you for pointing this out, the device tree binding docs for coda are indeed missing. I'm not sure the device tree binding docs are the right place to document driver and firmware though. For that, adding a coda.rst entry to Documentation/media/v4l-drivers would probably be a better place. True. That'd be great. Some firmware-handling and maybe even firmware version changelogs would definitely be useful. I'm running a little off-topic here, but with the newest firmware too, my coda driver says "Video Data Order Adapter: Disabled" when started by video playback via v4l2. (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed, a dev_info "probed" would maybe be useful for others too?) It supsequently fails with cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12 which may or may not be related to having the vdoa (is it?), but shouldn't the VDOA module be active by default? # cat /sys/module/coda/parameters/disable_vdoa 0 thanks martin
Re: platform: coda: how to use firmware-imx binary releases?
Hi Martin, On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote: > Hi, > > Commit > > be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and > 3.1.1 as supported > > says firmware version 3.1.1 revision 46072 is contained in > "firmware-imx-5.4.bin", that's probably > > sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-5.4.bin Yes. > How do I use this in order to get a VPU firmware blob that the coda > platform driver can work with? These are self-extracting shell scripts with an attached compressed tar archive. This particular file can be extracted by skipping the first 34087 bytes: dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv > (Maybe it'd be worth adding some short documentation on this. There > doesn't seem to be a devicetree bindings doc for coda in > Documentation/devicetree/bindings/media which would > be a good place for documenting how to use these binaries too) Thank you for pointing this out, the device tree binding docs for coda are indeed missing. I'm not sure the device tree binding docs are the right place to document driver and firmware though. For that, adding a coda.rst entry to Documentation/media/v4l-drivers would probably be a better place. regards Philipp
platform: coda: how to use firmware-imx binary releases?
Hi, Commit be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 3.1.1 as supported says firmware version 3.1.1 revision 46072 is contained in "firmware-imx-5.4.bin", that's probably sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-5.4.bin How do I use this in order to get a VPU firmware blob that the coda platform driver can work with? (Maybe it'd be worth adding some short documentation on this. There doesn't seem to be a devicetree bindings doc for coda in Documentation/devicetree/bindings/media which would be a good place for documenting how to use these binaries too) thanks martin
