DM6446 V4L2 display driver

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? 

the demos use fbdev driver for display.  They also use V4L2 for capture.

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:

• We have two setups and have made the mistake of not verifying that the toolchains are identical on them
  • On my setup, they are there and I can run the DMAI Decode application. 
  • On my programmer's system, they are not on his EVM  build ...
    
    • and his is the system that we are building the target image from.
  • We are comparing our toolchains and build options later today
• I will also attempt to set them up manually and see if that permits the DMAI/V4L2-based Decode app to work

Regarding the bootargs:

• yes, this is the bootarg that we are using at the moment.
• why does the following boot error occur with it?
  
  • davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.
• Why is the osd0 set to a 576 pal resolution? ( I found that 720x480x16 works just as well)
• Until just now, I did not understand why the vid0 and vid1 parameters would not work if a explicit resolution was included. 
  
  • I now understand that the decode app now uses V4L drivers and the buffers needed to be reserved, but not claimed by the FBdev driver
• Is OSD1 only for 4bit deep attributes?
• I spent several hours yesterday trying different bootargs for this program and a few of the other various examples that I have found scattered around.
• I have not been able to find a singlecommon  video bootarg that works with both the Decode program as well as the labs from the Davinci workshop and some of the other example apps
• Once one is developing a "real" target, what is typically used? Should the setup be remved from this line and explictly setup by each application?
• is the "davinci_enc_mngr.ch0_mode=ntsc"  and "davinci_enc_mngr.ch0_output=COMPOSITE" still used? 
  
  • I did not see that they were actually used now
  • I also see from section 2.1.1  in the SPRS566 document that the" Output and mode are set using sysfs interface

Regarding the V4L2 usage:

• According to the section 2.1.1.1, page 24 of the SPRS566 Linux Kernel Device Driver document   "Currently V4L2 is not supported"  on the DM6446 ( as you mentioned earler)
• Yet  THE primary demo application provided for use with the DM6446 EVM is based on V4L.  ... there is a conflict here. 
• Is  V4L2 supported in the PSP v2.00.00.140 / DVSDK 2.00.00.22 / MVL5 release?

DMAI Rules.make

• The Rules.make  to build the DMAI as a stand-alone is incorrect
• ~/dvsdk_2_00_00_22/dmai_1_20_00_06/Rules.make  point to an incorrect toolchain for the MV5 / DVSDK2.00.00.22 release
• The top-layer rules will work, but the DMAI can not be rebuilt as a stand-alone without correcting 
• No big thing, but it did confuse me at first and I wanted to bring it to the communities attention

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...

• As discussed above, the new primary dvevmdemo in this MV5 release (of which decode is a subset) uses a new layer called DMAI. The previous MV4 / dvsdkv 1.xx.xx releases did not.
• The demo now uses DMAI to open up and use the V4L  display driver and buffers  (even though the SPRS566 (page24) linux driver says that the V4L display driver is NOT supported)
• This is one reason why the video vid0 and vid1 bootargs have changed.  The buffers have to be reserved for the v4l video driver but not given to the fbdev driver. (see SPRUG92, page 13)
• This is also why other examples and older workbook demos may not run now with the newer bootargs, they may need the vid0 and vid1 explicitly setup by the bootargs so that fbdev driver can claim them
• So, V4L display driver IS required for the new demos to run .. and they require a different bootarg (as shown in the sprue66f GSG and elsewhere in this forum) ... They also need the /dev/vl4 node and at least the /dev/video2 linked node ( and possibly the /dev/video0 and /dev/video3 nodes) setup and the display device registered by the kernel at boot time.

BUT ...

• We had older MV4 EVMS so did not have a new MV5 DVD (if they exist) .. as a first step, we thought that we would load the distribution images, thinking that they would get us a working baseline before adding the variable of rebuilding the kernel. ... They do not.
• If one uses the dm6446 uImage kernel that is provided in the SDK 2.00.00.22  "mvltarget5_0_0801921_update.tar.gz" package,  it will not create these v4l video nodes and thus will not work
• I fairness, If one follows the sprue66F GSG exactly and fully , gets the bootargs correct, and loads all the toolchain,  and rebuilds the kernel from scratch, then the rebuilt kernel should work and support the new demo.
• But those in need of a quick fix, or choose not to add the development variable of rebuilding the kernel will go down this same path that we have been fighting

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:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/exports//HDD_ReadMe.html

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:

I thought everything that was contained in the MV5/SDK2 release *WAS*  MV5.  

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.

Hey Juan, Pratp thanks.

I was guessing same thing and got confirmed.

Finally my "one buffer to work " requirement got solved with 2 buffers and a bit of logic.

Thanks and regards,

Omkar