Is the V4L2 Video display driver supported in the DM6446 MV5 / DVSDK2.00.00.22 release?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Is the V4L2 Video display driver supported in the DM6446 MV5 / DVSDK2.00.00.22 release?
The best place to look for what is supported by Linux Kernel drivers is the PSP_xx_xx_xx_xxx directory under DVSDK software installation tree. In particular, SPRS566.pdf doc states what features are supported by drivers and what constraints there are; unfortunately, per this document it appears that display capabilities are supported by FBDev driver and not V4L2.
Juan, thats what lead to my question. Thanks for confirming it. It seemed strange to me that the SPRUG96 (V4L2 driver) and SPRUG92 (FBDev driver) documents show and document the new davinci video architecture with the V4F2 as a key layer, but then buried in the SPRS566 document that you referenced, the V4L2 is not supported on the DM644. .. so I had to ask.
I assume that none of the TI demos, examples, or workshops make use of the V4L2 display driver then. Correct?
How/where would one find existing of future TI-davinci V4L2 driver patches?
Is the MV5/SDK2.00.00.22 release in June that is found on the TI site the only repository of this 2.6.18 kernel davinci branch, or is there a distribution repository where package updates for things like this may be found.? Or does one have to go to the GIT kernel development tree, which would imply that a later kernel be used (which will then break all the exisiting APIs found with 2.6.18).
Juan,
Does the DVSDK "Decode" demo use the V4L display drivers? Does the V4L video driver have to be loaded?
Since we have no capture subsytem on our target, and are only compiling the "decode" module , I assumed we would not need the V4L driver as you stated.
But we continue to fail atthe following location on the target:
# export DMAI_DEBUG=0
# ./decode.t -k -v /usb/demo/data/videos/davinci.m2v
Decode demo started.
creating display device ... completed ...
Error: Failed to create display device
This failure was tracked to the following:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
snippet from i ~/dvsdk_2_00_00_22/dvsdk_demos_2_00_00_07/dm6446/decode/display.c
/* Create the display device instance */
printf ("creating display device ... "); (my debug message)
dAttrs.numBufs = NUM_DISPLAY_BUFS;
dAttrs.videoStd = envp->videoStd;
dAttrs.videoOutput = envp->displayOutput;
hDisplay = Display_create(NULL, &dAttrs); (found in ~/dvsdk_2_00_00_22/dmai_1_20_00_06/packages/ti/sdo/dmai/linux/Display.c)
printf ("completed ... \n"); (my debug message)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
With the new DVSDK, the decode application appears to have been rewritten with DMAI, so I found where the DMAI trace can be turned on.
When I turned on the DMAI trace log, I found the following:
# export DMAI_DEBUG=2
# cd /opt/demo
# ./decode.t -k -v /usb/demo/data/videos/davinci.m2v
Decode demo started.
@0x0007c268:[T:0x4001f950]
ti.sdo.dmai - [Dmai] Dmai log level set to '2'. Note that calling
CERuntime_init after this point may cause unexpected change to DMAI
tracing behavior.
@0x00114b9f:[T:0x4001f950] ti.sdo.dmai - [BufTab] Allocating BufTab for 1 buffers
@0x00114d41:[T:0x4001f950] ti.sdo.dmai - [Buffer] Set user pointer 0x42449000 (physical 0x87100000)
@0x00115281:[T:0x4001f950] ti.sdo.dmai - [Display] Display buffer 0 mapped to 0x42449000 has physical address 0x40025000
creating
display device ... @0x0011def0:[T:0x42c75490] ti.sdo.dmai - [Display]
Cannot open /dev/video2 (No such file or directory)
completed ...
Error: Failed to create display device
@0x001226fe:[T:0x43475490] ti.sdo.dmai - [Vdec2] Video decoder instance created
@0x00122904:[T:0x43475490] ti.sdo.dmai - [Vdec2] Made XDM_SETPARAMS control call
@0x00122aba:[T:0x43475490] ti.sdo.dmai - [Vdec2] Made XDM_GETBUFINFO control call
@0x00122b71:[T:0x43475490] ti.sdo.dmai - [BufTab] Allocating BufTab for 5 buffers ......
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
When I then looked at the /proc tree, I saw that we were not setting up the V4L driver, thinking that it was not being used. but the DMAI display routines appears to require and uses the /dev/video2 buffer instead of the FBdev buffer.
So I am confused ... V4L2 seems to be required and used on the demo, even though the documentation states that it is not operational on the DM6446 MV5/2.00.00.22 release. Or am I misinterpretting this?
I do see that we have the video4linux driver built into our kernel:
cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
14 sound
21 sg
29 fb
81 video4linux <-----
89 i2c
90 mtd
116 alsa
128 ptm
136 pts
180 usb
189 usb_device
Block devices:
8 sd
31 mtdblock
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
#
But the /dev/v4l , /dev/video0, /dev/video2, /dev/video3 devices do not show up
# ls -la /dev
<snip>
drwxr-xr-x 2 root root 1320 Jan 1 00:00 vc
drwxr-xr-x 2 root root 80 Jan 1 00:00 vcc
lrwxrwxrwx 1 root root 5 Jan 1 00:00 vcs -> vcc/0
lrwxrwxrwx 1 root root 6 Jan 1 00:00 vcsa -> vcc/a0
crw-rw---- 1 root root 10, 130 Jan 1 00:00 watchdog
crw-rw-rw- 1 root root 1, 5 Jan 1 00:00 zero
#
How do these video devices usually get created?
- gary
Hi,
They should get created if the filesystem scripts have appropriate calls to create them using mknod.
If not you could create it yourself using mknod command (For eg to create video1 entry under /dev, you could use a command like - mknod /dev/video1 c 81 1).
Thanks,
Prathap.
You are correct, it seems like things have changed this latest version and the demos are using V4L2 for display. I just went thru the DMAI code myself. If you used the following in your bootargs
"video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mngr.ch0_output=COMPOSITE mem=118M"
Then the V4L2 device nodes should have been created for you automatically; I just tried these settings on my DM6446 EVM and can confirm they work. I am using dvsdk_2_00_00_22
Juan,
There are probably more topics in the comments and questions below than the title of this thread, but they are somewhat related ...
Regarding the nodes:
Regarding the bootargs:
Regarding the V4L2 usage:
DMAI Rules.make
Prathap, that was a good idea, but it did not work. Even with the /dev/video2 present, the DMAI Display.c can not open up the video2 window.
Somewhere that video window layer would have to get mapped to an actual memory space, wouldnt it?.
On the working EVM, I see the following at boot time:
Linux video capture interface: v2.00
vpfe vpfe.1: DaVinci v4l2 capture driver V1.0 loaded
Trying to register davinci display video device.
layer=c0bdf600,layer->video_dev=c0bdf760
Trying to register davinci display video device.
layer=c0bdf400,layer->video_dev=c0bdf560
davinci_init:DaVinci V4L2 Display Driver V1.0 loaded
Is this what sets up the v4l2 video devices?
would the vfl2 video capture driver be needed in the kernel to setup the video display device?
We have found what is is probably the reason that one of our EVMs will not run the new decode demo that is part of the MV5/DVSDK 2.00.00.22 release.
The kernel distributed in the DSK2.00.00.22 tar'd image does not support the demo contained in that release.
This is my "theory" .... we have not completely vetted and confirmed it yet...
BUT ...
Lesson learned today ... do NOT use the "uImage-ti-davinci_evm-arm_v5t_le-2.6.18_pro500-1.2.1.0801921" kernel found in the new DVSDK2 release
I dont need help with this right now, but am sharing our experience for others who may have this problem in the future. If anyone wishes to chime in, please do so.
- Gary
Gary,
Sorry you had to learn this the long way. I think this has come up at least once before in the forums and you are correct, the recommended strategy is to follow the GSG. I can also confirm I had trouble with the tar file-system but the one from the DVSDK installation per GSG works fine. I am going to recommend that the tar file either be fixed or removed from out software distribution site. For sure, MV5 distros will not work with MV4 software, you need to update all the software components to MV5 per GSG.
Juan, yep, it should be corrected. There should be a prebuilt kernel in the release, that runs the MV5 demo. Just as is the out-of-the box EVM would.
I thought everything that was contained in the MV5/SDK2 release *WAS* MV5. To my knowledge nothing we were using was obtained outside the files located on the TI DVSDK2 release URL: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/index_FDS.html
The kernel image in question actually is 2.6.18, it just was built by someone prior to the DVDSK2 release, included in the release, yet is not built with a configuration that supports the DVSDK2 demo.
We know this now. Hopefully others will find this and related posts ....
---
I have a suggestion for a support doc... provide a clearly linked:to instructions on how to preform a MV5 bare metal restore on an EVM hardware platform to get it to the same pristine of-of-the-box state that one would receive the EVM if it was newly purchased. This state should not require any modifcation of rebuilding of the kernel. ( I am making an assumption here that new EVMs are now shipped with the MV5/SDK2 distribution)
I did see the following link on the DVSDK2 release page. Should they provide such a state?:
Instructions for reformatting and restoring DaVinci Hard Drives:
Gary
First, I would like to apologize, I got confused when I read about the tar file, which brought memories of DM365 tar file I tested a few days ago. On DM365, I found that if you untarred file and try to NFS mount the file-system included in the tared file, the demos did not run. To be fair, I assumed the tar file had a working file-system but no document really told me what the tar file contained or what I could use it for; I felt like the tar file should be removed from our site until there was supporting docs to tell me what I could and could not do with it. If I followed the GSG, everything worked well; I always encourage customers to follow the GSG.
With regards to DM6446, I have not confirmed if the tar file works or not, but given that our DVSDK passes some level of testing (I know we sometimes we miss stuff) if it is referred to by GSG, I assume it works; if it is not referenced by any documentation, then I would need to investigate and possibly have it removed if it serves no purpose other than confusing our users. That said, I will address your latest post below.
Tiger Team said:
DVSDK 2.0 is based on MV5. Do you have any reason to believe this is not so?
Tiger Team said:I have a suggestion for a support doc... provide a clearly linked:to instructions on how to preform a MV5 bare metal restore on an EVM hardware platform to get it to the same pristine of-of-the-box state that one would receive the EVM if it was newly purchased.
I agree this is very important to have. Actually, the information is in our GSG. Section A4 of sprue66f (DM6446 DVSDK 2.0 GSG) suggests the default EVM configuration from factory and details different configurations including the default. In addition, Section A6 discusses how to re-store the HDD. The GSG is a very important doc for our customers to reference. That said, we could create a wiki article to perhaps make gather only the pertinent information into a single page, but as it is, I feel we have so much information out there and not an easy way for our customers to know where to go to find such information. One of the projects I am trying to get some action on is a wiki article (or even better if it can become part of GSG, which I like to think as the number 1 source) to make our customers aware of all the documentation included in the DVSDK and perhaps a brief description of which document is best for what type of information. Do you think this would be helpful?
Juan, ABSOLUTELY !!!! there is information overload. Simple single "cheat sheets" would be great. The wiki about how to create a mpeg3 codec is pretty close. Having a series of single page cheat sheets on various "how to" actions would be wonderful.
Honestly , my programmer, as I imagine other experienced linux programers are guilty of, never read the GSG document. They are so used to building linux kernels and applications, they expect things to be obvious with the documentation in the make files and manpages. He even mentioned the need for a step-by-step instruction to me recently.
There is also confusion about what is current preferred methods and tools and what is older and depreciated. Many of the examples I find scattered around are probably "the older" way of doing things which makes it hard to "learn by example".
I am actually not too crazy about the wiki. It seems to have become an easy dumping ground for a lot of information. This is not unique to TI, I think a lot of companies are relying on them too much. It also can change and evolve. Its a great place to provide errata, workarounds, clarification and examples, but it should expand on a clear linear thought out document system, not replace it.
A new user , which I imagine compromises most of us that are looking at this forum, will need a very clear cut Step1, Step2, Step3. and a list of what documents and tools are available. One good example would be a step by step instructions on how to move an existing EVM from MV4 to MV5. The GSG assumes that a DVD is available, and the repository method is a little different.
I like the printed documents and PDFs. ( I HATE the TI document naming. I have learned to "rename" each downloaded document and append the document title in the filename).
I will respond to your other questions tomorrow ... we got video working tonight!! There is another "gotcha" with building a decode-only V4L target that we found. I will have to get my ducks in a row before trying to explain it.
- gary
Hello,
I don't know whether this is right place for this post.
If not please let me know and redirect to the same.
Right now I am using V4L2 for csmera capture on DM6446 with DVSDK 2_00. I amd using Dmai interfaces and everything is working fine.
My capture application works fine if I request 2 buffers from V4L2 and queue and deque one buffer continuously.
But if I request (req.count = 1 in VIDIOC_REQBUFS) then Q works fine but DQ doesn't return...
So has anybody done this thing with single buffer ?
Right now i am not bothered about performance and frame drops....
Just wanted to know whether it is possible or not ...
I believe this may be a limitation of the driver in that the driver needs to own at least one buffer all the time so it has a place to dump data being captured. Hence of only one buffer is Qed, when you call on DQ for application to take ownership of buffer, driver may refuse to give up the last and only buffer it owns.
That's right. The driver needs to own atleast 1 buffer all the time.
Thanks,
Prathap.