DM365 - Video 4 Linux 'RAW' inputs?

Philip Coombes said:

The composite and s-video inputs I can understand but I am unsure what the RAW and RAW-1 inputs represent. Also using v4l2 ioctls I am unable to select inputs 0 and 1, getting an 'invalid argument' response. So even if I knew what they were it does not look like I would be able to access them. The camera device we are using includes digital video and I was was wondering if this was how the DV was presented but cannot find any documentation on this side of things (most of the tech notes etc regarding v4l2 seem to relate to output rather than capture). If  anyone can give me any pointers on this it would also be very helpful.

I believe RAW and RAW-1 are unconfigured inputs, that is I believe you would modify the capture driver with a configuration for a particular image sensor that could be applied to RAW or RAW-1. As to documentation, I believe the area you may want to look at for this is section 2.2.5.2 of the VPFE Capture Driver User's Guide (should be able to use this link if you log in).

Philip Coombes said:

I have found a boot parameter which is a module argument to the davinci capture driver and might be related to this. This is davinci_capture.device_type. I have been unable to find any comprehensive documentation about what are permissible values other than 1 relates to TVP5146 and 2 is MT9T031. The previous setting (and that recommended in the startup guide) is 4 but I cannot find out what device that relates to.

Unfortunately as you point out, the documentation can be hard to find, some of the documents were not ready at the time the PSP for the DM365 was pushed out so they do not all necessarily exist in the install. Luckily the document mentioned above also discusses this in section 6.2, the 4 maps to TVP7002 (so you can have the HDTV component input the out of box demo needs).

Philip Coombes said:

Changing it 1 allows V4L2 input switching to channel 2 so my application and ffmpeg were both able then to access the analog s-video input and I could create ffmpeg streams from it. Other than that using 1 or 4 seems to make little difference, and values of 0, 2 or 3 don't work at all. If someone knows anything else about this parameter I would be interested as I am a little in the dark about what it is doing.

The values of 0,2, and 3 are all for image sensors that are not built into the EVM board, so they will probably have a failure somewhere if you try to configure for them without a daughtercard in place.

Thanks for the document link. It looks very useful.

One area I am still unclear about then is how digital video is exposed if it is not one of the inputs available via V4L. I am referring to the DV inputs on the J10 connector as we have a device generating video over these which I am trying to validate.

I have not found any kind of demo or documentation about how to capture digital video or what kind of interface it might be exposed on, if not V4L, so any additional help or pointers with that would be very useful.

Philip Coombes said:

One area I am still unclear about then is how digital video is exposed if it is not one of the inputs available via V4L. I am referring to the DV inputs on the J10 connector as we have a device generating video over these which I am trying to validate.

From a capture perspective the MT9xxxx drivers are what would be utilizing the J10 interface on the DM365 EVM, though the cameras exist such as this board from Leopard Imaging, I have not had a chance to use one myself. Unfortunately the drivers are not very generic in what you can configure them for out of the box, in general they are built and tested against specific hardware, primarily that which is built into the EVM itself (i.e. TVP5146, TVP7002, etc.) or is available on a specific daughter board (MT9xxxx). In general if you have hardware other than what is on the EVM you will probably have to modify the video capture driver source to handle your specific hardware.

Thanks for that Bernie. We have a digital video feed connected, I'm just not really sure where to look for it in software terms. Am I right in thinking that if the MT9xxxx drviers were being used then it would manifest itself via the V4L api or are DV feeds so different that it would normally require customisation of the drivers to work, and if so, do you mean the MT9 drivers or the V4L ones?

I was half expecting the DV to be one of the RAW inputs and the SPRUGP9 documents seems to confirm that is likely to be the case (p7). I was also expecting there to be some work involved in decoding it however as I cannot switch to that input in the V4L api I have not been able to actually look at what is coming out (if anything). Do you have any suggestions to offer here? Is is likely to be the case that I will have to intercept the video directly from the MT9 driver if the V4L layer does not understand it? If so is there a reference (or examples) available for direct MT9 driver access?

Thanks for your continued help on this. I am feeling that I am nearly there with this issue but missing just the one crucial bit of understanding :|

Philip Coombes said:

Am I right in thinking that if the MT9xxxx drviers were being used then it would manifest itself via the V4L api or are DV feeds so different that it would normally require customisation of the drivers to work, and if so, do you mean the MT9 drivers or the V4L ones?

In general, regardless of the hardware front end, the software will interact with the V4L2 API, there may be some extra ioctls added to perform specific functionality if needed to expand beyond V4L2, however in general the basic functionality of the capture driver from a user perspective is still V4L2. This being said, when I suggest modifying the drivers I am really referring to the lower level hardware abstraction layers, which you could call a MT9xxxx driver, though there is no direct user interface to such a driver, rather it adapts the sensor to the V4L2 layer, a driver in a driver. I typically think of the total V4L2 driver stack as a whole capture driver, encompassing both MT9xxxx code and V4L2 API code, though it is divided internally into multiple funtional pieces as you suggest, I apologize if this take on it is not the most intuitive.

Philip Coombes said:

I was half expecting the DV to be one of the RAW inputs and the SPRUGP9 documents seems to confirm that is likely to be the case (p7). I was also expecting there to be some work involved in decoding it however as I cannot switch to that input in the V4L api I have not been able to actually look at what is coming out (if anything). Do you have any suggestions to offer here?

The digital interface is exposed by those inputs, however the low level code that is activated by selecting those inputs is expecting there to be a particular MT9Txxxx sensor attached to that bus as well as the I2C interface for configuration, so chances are the low level code is throwing some error that prevents you from using those inputs directly. In other words, accessing the digital video bus on the DM365 is not as easy as just switching to a particular V4L2 input as it has hardware dependencies, as most digital video inputs would require some additional external configuration and format consideration.

Philip Coombes said:

Is is likely to be the case that I will have to intercept the video directly from the MT9 driver if the V4L layer does not understand it? If so is there a reference (or examples) available for direct MT9 driver access?

It is not so much that you would intercept video directly from the low level driver code, but rather that you would adjust the low level driver code that it works with both your particular video hardware and the V4L2 layer, I do not know of any references or examples for accessing the low level code directly.

I am still wrestling with this issue though I am now somewhat clearer in my mind what it is that I do not know [:S]

The camera module we are attaching to the J10 connection on the DM365 board is configure (from the camera side) to emit BT.656 video. Thus we only have the data and clock lines connected. I have experiemented with other camera modules (e.g. the Leopard LI-5M02) and they connect through to the MT9P031 capture device directly.

Looking at the daVinci drivers I can see them setting the interface type to BT.656 when using the TVP5146 decoder. I assume this means that the TVP5146 emits BT.656 encoded video that has been captured from the composite and/or s-video ports.

What I am confused about is simply this. If BT.656 encoded video is being passed directly via the J10 connector, where does it go? In other words I assume the TVP5146 BT.656 video goes into the VPFE, does the J10 video go directly into the VPFE also or does it also go via the TVP5146 also? The source of my confusion is this. The drivers allow you to select a device type from which a hardware interface type is derived. The only device type options appear to be TVPxxxx or MT9xxxx devices, and the BT.656 hardware interface type is only selected for TVP5146 devices (which I had previously assumed only applied to analog video).

So, how do I instruct the drivers that the video should be captured directly in BT.656 mode from a source connected to J.10 and not from an analog port via the TVP5146 encoder? Or have I totally misunderstood how this all works?

Philip Coombes said:

Looking at the daVinci drivers I can see them setting the interface type to BT.656 when using the TVP5146 decoder. I assume this means that the TVP5146 emits BT.656 encoded video that has been captured from the composite and/or s-video ports.

This is true, TVP5146 does output bt.656.

Philip Coombes said:

What I am confused about is simply this. If BT.656 encoded video is being passed directly via the J10 connector, where does it go? In other words I assume the TVP5146 BT.656 video goes into the VPFE, does the J10 video go directly into the VPFE also or does it also go via the TVP5146 also?

The digital video data that is fed into the DM365's VPFE is multiplexed on the DM365 EVM, so it can actually come from three different sources, the TVP5146 SD video decoder, the TVP7002 HD video ADC, or the J10 connector intended for a camera daughterboard. This is actaully controlled through an i2c register in the CPLD on the EVM which is discussed in section 2.1.1.2.4 of the tech reference for the EVM, there are also schematics in this same document that give more detail on the physical connections (page 116 has the actual mux). This is one of the registers that the driver will have to modify to bring in a different source in addition to configuring the capture device itself.

Philip Coombes said:

The source of my confusion is this. The drivers allow you to select a device type from which a hardware interface type is derived. The only device type options appear to be TVPxxxx or MT9xxxx devices, and the BT.656 hardware interface type is only selected for TVP5146 devices (which I had previously assumed only applied to analog video).

This is correct, the drivers provided by the PSP team here at TI only cover hardware on the EVM, though in this case that includes a MT9xxxx daughter board, other interfaces are not included because the PSP team has no way of testing and validating them.

Philip Coombes said:

So, how do I instruct the drivers that the video should be captured directly in BT.656 mode from a source connected to J.10 and not from an analog port via the TVP5146 encoder? Or have I totally misunderstood how this all works?

You would have to modify the driver source to add a new device that acts like the TVP5146 driver without actually trying to configure the TVP5146, or just strip any TVP5146 specific configuration code out and call your device TVP5146, there is not an easy driver switch to do this. Unfortuantely all of our driver software is tied to the EVM hardware out of the box, you are not the first to ask for such a simplistic driver though I do not have any better solutions other than getting into driver modifications.

Ok, thanks Bernie. I'm sure more questions will follow but at least now I know what I have to do next. *rolls up sleeves*

Hi once more,

I am still working on this, specifically on a basic driver for DV over the J10 connector. I am basing the driver on one of the existing drivers such as the TVP5146 driver in terms of what the video output would look like however I am unsure what to do in terms of all the i2c instructions in the driver.

Am I right in assuming that the i2c reads and writes in the driver are directed to the TVP chip itself or (in the case of the MT9xxxx drivers to a CCD connected over the J10) and that as the only connections we have on the J10 are in the form of clock and 'DV in' that I can safely remove all i2c reads and writes from the driver? The reason I ask is that I have tried that and I get a load of I2C write failed messages when invoking the driver even though there is no longer any reference to i2c in it. Is i2c more deeply embedded in the driver architecture than I appreciate?

I was expecting a DV driver to be more or less a simple case of configured the VPFE for BT656 input and then kicking the whole thing off as there would be no facility to configure the video due to the lack of write facilities over the J10 interface in our case. That does not appear to be the case.

Any tips or guidance appreciated as always.

Philip Coombes

Hi Philip,

I was wondering if you were ever able to develop a solution to your situation described in this post.  I am begining a project which sounds like it has identical needs (Bt.656 input over the J10 connector)

Any tips and guidance would be helpful

Thanks,

--Jacob Leemaster

Hi Philip, hi Jacob

I am trying to capture video from J10 on DM365 too and i meet problems like this. Can You give me roadmap or solutions?

Thanks,

Alexandr Dmitriev