I have a VF61 with me and wanted to use it's parallel camera interface provided by the VIU3 subsystem.
http://lxr.free-electrons.com/source/drivers/media/video/fsl-viu.c?v=3.0
I ported the driver on the above link for VF61 and managed to get a /dev/video0 node. I am using ITU656 8 bit as input from a ADV7180 decoder based module. The module is working and has been tested with a different processor. The ADV7180 driver is the same for both these processors.
On running the gstreamer pipeline, gst-launch v4l2src device=/dev/video0 ! ximagesink i get a blank window and the below messages with dmesg.
[ 30.356249] viu: viu: open (minor=0)
[ 30.356276] viu: open minor=0 type=vid-cap users=1
[ 30.356301] viu: Open: fh=0xc64a0600, dev=0xc632d800, dev->vidq=0xc632d874
[ 30.356318] viu: Open: list_empty queued=1
[ 30.356331] viu: Open: list_empty active=1
[ 30.356348] viu: status reg: 0x00000000, field base: 0x00000000
[ 30.385318] viu: Field type invalid.
[ 30.385358] viu: Field type invalid.
[ 30.385586] viu: Field type invalid.
[ 30.385617] viu: Field type invalid.
[ 30.392330] viu: set to pixelformat 'RGB-16'
[ 30.397038] viu: buffer_setup, count=2, size=829440
[ 30.397258] viu: mmap called, vma=0xc6970318
[ 30.399994] viu: vma start=0x41147000, size=831488, ret=0
[ 30.403309] viu: mmap called, vma=0xc6970370
[ 30.406021] viu: vma start=0x41400000, size=831488, ret=0
[ 30.406215] viu: adding vb active=0xc673342c
[ 30.406246] viu: [c6733400/0] buffer_queue - first active
[ 30.406267] viu: buffer_activate [c6733400/0]: dma addr 0x86a00000
[ 30.406287] viu: adding vb queue2=0xc673302c
[ 30.406305] viu: [c6733000/1] buffer_queue - append to active
[ 30.900044] viu: viu/0: [c6733400/0] timeout
[ 30.900069] viu: viu/0: [c6733000/1] timeout
[ 30.900088] viu: restart_video_queue vidq=0xc632d874
[ 30.928459] viu: adding vb active=0xc673342c
[ 30.928492] viu: [c6733400/0] buffer_queue - first active
[ 30.928513] viu: buffer_activate [c6733400/0]: dma addr 0x86a00000
[ 31.020071] eth0: no IPv6 routers present
[ 31.089362] viu: adding vb queue2=0xc673302c
[ 31.089393] viu: [c6733000/1] buffer_queue - append to active
[ 31.420047] viu: viu/0: [c6733400/0] timeout
[ 31.420073] viu: viu/0: [c6733000/1] timeout
[ 31.420091] viu: restart_video_queue vidq=0xc632d874
[ 31.450408] viu: adding vb active=0xc673342c
[ 31.450439] viu: [c6733400/0] buffer_queue - first active
[ 31.450460] viu: buffer_activate [c6733400/0]: dma addr 0x86a00000
[ 31.490781] viu: adding vb queue2=0xc673302c
[ 31.490812] viu: [c6733000/1] buffer_queue - append to active
[ 31.950033] viu: viu/0: [c6733400/0] timeout
[ 31.950058] viu: viu/0: [c6733000/1] timeout
Can someone help me or point me as to what might me the issue? I have attached the patch which shows changes i made to the driver. Not much knowledgeable on V4L2 and video side. This is a completely personal project of mine.
Original Attachment has been moved to: viu.patch.zip
Hello,
Alright, thanks Timesys support for the input. I will keep trying at my end.
I am attaching the complete patch of changes to the http://git.toradex.com/gitweb/linux-toradex.git/tree/colibri_vf tree. Also attached is the file i added for registering the VIU subsystem in /arch/arm/plat-mxc/devices.
If anyone finds this useful and manages to get it to work or can give some inputs on my work, please do contact me or reply here.
Thanks & Regards,
Sanchayan Maity.
Hi Sanchayan,
As it would be cool to have a VIU3 driver working for Linux, I had a look at your patches. First I looked through clock stuff. Your changes seem reasonable, also to VIU clock is enabled by default by U-Boot anyway. But then the empty status register made me curious. There are several bits which are 1 by default according to the RM, the Toradex BSP has devmem2 to get the value from a raw register:
root@vybridvf61-v11:~# devmem2 0x400c9000 /dev/mem opened. Memory mapped at address 0x40303000. Read at address 0x400C9000 (0x40303000): 0x02800000
Interesting! The register is actually not 0x00000000! Can you check why this is not the case in your debug output? Maybe the base address passed to the driver is wrong?
--
Stefan
Hello Stefan,
The debug output shows zero for status configuration register, because in the probe call, the viu_reset() function in the driver is called, which sets the register to 0. This is also done in the viu_default_settings(). I have tried with values 0x02800000 and 0x02000000, with YUV2RGB_EN bit and MODE444 bit set and YUV2RGB_EN set but MODE444 bit not set respectively, in these functions. Also made sure that the YUV2RGB_EN bit is not set to zero anywhere else in the driver in recent trials, by passing 0x02000000 instead of 0, wherever status configuration register was being set.
The base address passed to the register is correct, because output of /proc/iomem shows
400c9000-400c9fff : mvf-viu.0
After running the gstreamer pipeline or after boot up,
root@colibri-vf:/proc/irq# devmem2 0x400c9000
/dev/mem opened.
Memory mapped at address 0x4027e000.
Read at address 0x400C9000 (0x4027e000): 0x02000000
As expected, 0x02000000 is what was used in the driver as default value for status configuration register.
Thanks & Regards,
Sanchayan Maity.
Hi Sanchayan,
are you using the Analougue Camera Module Rev 1.1 from Toradex to encode analog video signals?
We have this module but the command interface i2c is not working with my SOM VF61,
Toradex says: "the problem on the module is caused by a design issue........"
Thanks & Regards,
Antonio Boi
Hello Antonio,
While using Toradex ACM, you need to use pull ups on the I2C lines, while using it with Vybrid. Adding 1K pull ups to the lines, should make the ACM detectable at least.
Thanks & Regards,
Sanchayan Maity.
Dear Sanchayan,
As far as I know, according to the I2C specification, the lowest pull-up value should be 1.5K.
However, using 1K is OK as well as long as the I2C outputs are not overloaded and the input VIL requirements met.
Regards, Naoum Gitnik.
Hello Naoum,
The Toradex Analog Camera Module is for use with the Toradex Evaluation Board. On the Evaluation Board, 4.7k pull ups are there for the I2C lines already.
Thanks & Regards,
Sanchayan Maity.
Hi Sanchayan,
I ran into the same timeout issue when using the internal video decoder (VADC/VDEC) on Vybrid Platform. I have tested this on 4.1 Kernel with VADC/VDEC driver and VIU driver modified to also work with internal video decoder on Vybrid. See log below for reference.
I was wondering if you had found a solution to the above issue? Any pointers will be greatly appreciated.
I would be happy to send patches of all my changes (Incl. VDEC, VADC, VIU Driver, Clock changes) for review, in case anyone has any suggestions to resolve the above issue.
# gst-launch v4l2src device=/dev/video0 ! fakesink
Setting pipeline to PAUSED ...
viu: viu: open (minor=0)
viu: open minor=0 type=vid-cap users=1
viu: Open: fh=0x84c59800, dev=0x859ca210, dev->vidq=0x859ca278
viu: Open: list_empty queued=1
viu: Open: list_empty active=1
viu: status reg: 0x00000000, field base: 0x86200000
viu: Field type invalid.
viu: Field type invalid.
viu: Field type invalid.
viu: Field type invalid.
viu: buffer_setup, count=2, size=1658880
viu: mmap called, vma=0x84c35738
cma: cma_alloc(cma 8077f174, count 405, align 8)
cma: cma_alloc(): returned 85fad000
viu: vma start=0x7665a000, size=1658880, ret=0
viu: mmap called, vma=0x84c35e70
cma: cma_alloc(cma 8077f174, count 405, align 8)
cma: cma_alloc(): returned 85fb1000
viu: vma start=0x764c5000, size=1658880, ret=0
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
viu: restart_video_queue vidq=0x859ca278
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
viu: restart_video_queue vidq=0x859ca278
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
viu: restart_video_queue vidq=0x859ca278
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
viu: restart_video_queue vidq=0x859ca278
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
viu: restart_video_queue vidq=0x859ca278
viu: adding vb active=0x84c80528
viu: [84c80500/0] buffer_queue - first active
viu: buffer_activate [84c80500/0]: dma addr 0x86200000
viu: adding vb queue2=0x84c802a8
viu: [84c80280/1] buffer_queue - append to active
viu: viu/0: [84c80500/0] timeout
viu: viu/0: [84c80280/1] timeout
Thanks,
Roshni
Hello,
Sorry for the delay in reply.
I had worked on VIU again a few weeks back with the 4.1.15 kernel and managed a distorted color space image which lasts for two seconds, but, I do not recall seeing those messages again. However I do not remember if I had enabled debug messages or not. My setup used an external ADV7280 decoder by the way and not the internal VADC/VDEC or the way MQX demo is done.
I will try it again next week and get back to you as I do not have access to the setup at the moment but basically it is still non functional and the issue is not resolved. Will be a while before I fully look into it again.
Regards,
Sanchayan.
Hi roshni shah,
I used Sanchayan' s code with linux kernel 3.0.15, with some little change, with an external video encoder the drive gone well.
The only problem was that v4l2 returned only maximum 2 video buffers and no more, I do not know why.
Antonio
Hi Antonio,
Thank you for your prompt response and confirmation. Was this tested with the Toradex Analougue Camera Module Rev 1.1? Also, you mention you had to make some little changes, were these in the fsl_viu driver (linked above)? Do you mind sending me a patch for the changes for reference?
Thanks a lot,
Roshni
Dear Antonio,
If you are using our Vybrid Tower board, as far as I remember, some I2C lines on it have series low-value (0 to 33 Ohms) resistors, which might simply be unpopulated by default due to sharing several functions by the same Vybrid IO (refer to the schematic).
Please, also verify if the I2C lines have pull-up resistors either on the Vybrid board or the camera module – without them the I2C interface using open-drain topology will not work.
Sincerely, Naoum Gitnik.
Hello Sanchayan,
Nothing stood out to me in the patch why this error would occur. Timesys can support drivers added to the Vybrid BSP under a professional services agreement. Let me know if you have any questions.
Thanks,
Timesys Support
timesyssupport can you attend this case?
Timesys Support can you attend this case?