Getting started with OMAP3 ISP

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux # ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

Hi Gary,

Quoted 12 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Quoted 7 lines

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux # ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 20 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

Quoted 4 lines

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Quoted 70 lines · Laurent Pinchart

Hi Gary,

Quoted 12 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Quoted 7 lines

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 17 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:

Quoted 7 lines

# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Thanks for the info.

When I run 'media-ctl -p', I see the various nodes, etc, and they all look good except that I get lots of messages like this:
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node

When I try to setup my pipeline using something similar to what you provided, the first step runs and I can see that it does something (some lines on the graph went from dotted to solid), but I still get errors:

# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]'
Setting up format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
v4l2_subdev_open: Failed to open subdev device node
Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my driver.

Any ideas what I might be missing?

Thanks

Quoted 75 lines · Gary Thomas

Quoted 69 lines · Laurent Pinchart

Quoted 12 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Quoted 7 lines

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 17 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:

Quoted 7 lines

# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Thanks for the info.

Quoted 5 lines

When I run 'media-ctl -p', I see the various nodes, etc, and they all look good except that I get lots of messages like this:
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node

Could this be related to my missing [udev] device nodes?

I can see media-ctl get confused and try to open a nonsense device name. Here's what I see when I run

   # strace media-ctl -p | grep open
   open("/dev/media0", O_RDWR)             = 3
   open("", O_RDWR)                        = -1 ENOENT (No such file or
directory) write(1, "\tpad0: Input v4l2_subdev_open: F"..., 66) = 66

Quoted 20 lines

When I try to setup my pipeline using something similar to what you provided, the first step runs and I can see that it does something (some lines on the graph went from dotted to solid), but I still get errors:

# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to
inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP
CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up
format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
v4l2_subdev_open: Failed to open subdev device node
Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my driver.

Any ideas what I might be missing?

Thanks

Hi Gary,

Quoted 82 lines · On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:

Quoted 80 lines · Gary Thomas

Quoted 69 lines · Laurent Pinchart

Quoted 12 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Quoted 7 lines

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 17 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:

Quoted 7 lines

# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Thanks for the info.

When I run 'media-ctl -p', I see the various nodes, etc, and they all look good except that I get lots of messages like this:
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node

Quoted 1 line

Could this be related to my missing [udev] device nodes?

It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.

Quoted 28 lines

I can see media-ctl get confused and try to open a nonsense device name. Here's what I see when I run

    # strace media-ctl -p | grep open
    open("/dev/media0", O_RDWR)             = 3
    open("", O_RDWR)                        = -1 ENOENT (No such file or
directory) write(1, "\tpad0: Input v4l2_subdev_open: F"..., 66) = 66

Quoted 20 lines

When I try to setup my pipeline using something similar to what you provided, the first step runs and I can see that it does something (some lines on the graph went from dotted to solid), but I still get errors:

# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to
inactive
Setting up link 16:0 ->  5:0 [1]
Setting up link 5:1 ->  6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP
CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up
format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
v4l2_subdev_open: Failed to open subdev device node
Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my driver.

Any ideas what I might be missing?

Thanks

Quoted 2 lines · Laurent Pinchart

Quoted 1 line · On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:

On 2011-08-30 08:08, Gary Thomas wrote:

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

When I run 'media-ctl -p', I see the various nodes, etc, and they all look good except that I get lots of messages like this:
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node

Quoted 3 lines

Quoted 1 line

Could this be related to my missing [udev] device nodes?

It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.

Yes, that helped a lot. When I create the devices by hand, I can now see my driver starting to be accessed (right now it's very much an empty stub)

Any ideas why udev (version 164) is not making these nodes automatically?

Yes, that helped a lot.  When I create the devices by hand, I can now see my driver starting to be accessed (right now it's very much an empty stub)

From your logs it seems you are using a tvp5150, i've posted a patch

Quoted 4 lines · Gary Thomas

Yes, that helped a lot. When I create the devices by hand, I can now see my driver starting to be accessed (right now it's very much an empty stub)

From your logs it seems you are using a tvp5150, i've posted a patch

[1] for tvp5150 that makes it very close to work, it could be faster to debug it instead of starting from scratch.

Enrico

[1] http://www.spinics.net/lists/linux-media/msg37116.html

Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered.  Does this mean that udev created them for you on boot as well?  If so, what version of udev are you using?  What's your root file system setup? n.b. I'm using an OpenEmbedded variant, Poky

Quoted 6 lines · Gary Thomas

Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered. Does this mean that udev created them for you on boot as well? If so, what version of udev are you using? What's your root file system setup? n.b. I'm using an OpenEmbedded variant, Poky

They are not created on boot but when i modprobe omap3-isp (and tvp5150 gets automatically loaded).

Udev is version 173 and i'm using Angstrom, an OpenEmbedded (core) variant too.

Anyway when developing the patch it happened to me too that i had those subdev open errors, but if i remember correctly only for tvp5150 so it was something wrong in my code.

And if i continue to remember correctly it was because you had to set the V4L2_SUBDEV_FL_HAS_DEVNODE after calling v4l2_i2c_subdev_init. Seems nonsense but this is what i remember, actually this is what the mt9v032 driver does.

Quoted 8 lines · Enrico

Quoted 4 lines · Gary Thomas

Yes, that helped a lot. When I create the devices by hand, I can now see my driver starting to be accessed (right now it's very much an empty stub)

From your logs it seems you are using a tvp5150, i've posted a patch

[1] for tvp5150 that makes it very close to work, it could be faster to debug it instead of starting from scratch.

Quoted 3 lines

Enrico

[1] http://www.spinics.net/lists/linux-media/msg37116.html

Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered. Does this mean that udev created them for you on boot as well? If so, what

Hi Gary,

Quoted 12 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Quoted 7 lines

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux # ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 20 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

Quoted 4 lines

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Quoted 78 lines · Laurent Pinchart

Quoted 15 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 6 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 25 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

What pixel format would I use with ffmpeg?

n.b. I know most of these are pretty n00b questions - I'd look up the answers for myself, but I've had precious little success finding any documentation, especially on media-ctl and/or the OMAP3 ISP setups.

Hi Gary,

Quoted 79 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 78 lines · Laurent Pinchart

Quoted 15 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 6 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 25 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 8 lines

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

Quoted 4 lines

n.b. I know most of these are pretty n00b questions - I'd look up the answers for myself, but I've had precious little success finding any documentation, especially on media-ctl and/or the OMAP3 ISP setups.

Quoted 92 lines · Laurent Pinchart

Quoted 90 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 81 lines · Laurent Pinchart

Quoted 15 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 6 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 28 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Quoted 6 lines

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

Hi Gary,

Quoted 96 lines · On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:

Quoted 95 lines · Laurent Pinchart

Quoted 82 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 81 lines · Laurent Pinchart

Quoted 15 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 6 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 28 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 8 lines

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if it worked out of the box, would it ? :-)

Quoted 103 lines · Laurent Pinchart

Quoted 102 lines · On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:

Quoted 100 lines · Laurent Pinchart

Quoted 84 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 83 lines · Laurent Pinchart

Quoted 16 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 7 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 v4l-subdev1 v4l-subdev4 v4l-subdev7 video2
video5 v4l-subdev2 v4l-subdev5 video0 video3
video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 28 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 8 lines

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

Quoted 4 lines

Quoted 1 line

It's a BT656 encoder - 8-bit UYVY 4:2:2

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if it worked out of the box, would it ? :-)

So, functionality that was present in 2.6.32 (TI PSP version at least) is not currently available?

Hi Gary,

Quoted 106 lines · On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:

Quoted 105 lines · Laurent Pinchart

Quoted 103 lines · On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:

Quoted 94 lines · Laurent Pinchart

Quoted 84 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 83 lines · Laurent Pinchart

Quoted 16 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

Quoted 7 lines

registered. I see a full set in /sys/class/video4linux

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 v4l-subdev1 v4l-subdev4 v4l-subdev7 video2
video5 v4l-subdev2 v4l-subdev5 video0 video3
video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 28 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2

Quoted 6 lines

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 8 lines

Quoted 2 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Quoted 6 lines

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

Quoted 5 lines

Quoted 2 lines

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if it worked out of the box, would it ? :-)

So, functionality that was present in 2.6.32 (TI PSP version at least) is not currently available?

That's right. You can blame TI for not pushing it to mainline :-)

Quoted 57 lines · Laurent Pinchart

Quoted 56 lines · On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:

Quoted 55 lines · Laurent Pinchart

Quoted 54 lines · On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:

Quoted 53 lines · Laurent Pinchart

Quoted 52 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 51 lines · Laurent Pinchart

Quoted 20 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

registered. I see a full set in /sys/class/video4linux

Quoted 7 lines

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 v4l-subdev1 v4l-subdev4 v4l-subdev7 video2

video5 v4l-subdev2 v4l-subdev5 video0 video3

video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 19 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty

Quoted 50 lines

Quoted 50 lines

Quoted 50 lines

Quoted 49 lines

Quoted 41 lines

Quoted 35 lines

Quoted 31 lines

Quoted 9 lines

           # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
           /dev/video2

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 3 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Quoted 5 lines

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Quoted 6 lines

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if it worked out of the box, would it ? :-)

So, functionality that was present in 2.6.32 (TI PSP version at least) is not currently available?

That's right. You can blame TI for not pushing it to mainline :-)

Is this only important if I want to push data past the CCDC? In the past, we were happy with just using the CCDC like a frame grabber which delivered YUV data to memory [raw data from /dev/videoN] Is this possible with the CCDC support as is? The only discussion I could find about this on this list was in early March 2011 and I think you implied that it should work. I'm a bit concerned that it won't as the BT656 data has embedded syncs that the CCDC needs to be set up for.

I saw a reference to 'Add YUV support to CCDC' on 2010-11-15, but no followup. That work seemed to be for a much older driver and not applicable to the current work, or am I missing something?

Has there been other discussion on this topic (I didn't see it in onthis list which I've been quietly monitoring for two years)? Is the lack of YUV support in CCDC for this current driver (drivers/media/video/omap3isp) a concious decision, or just a lack of movement?

Is there someone at TI that I should contact?

I'm just trying to understand what I have to do to move forward on this. I really hadn't planned/scheduled a large effort to recreate functionality that we've already been using for years when we moved to a newer kernel.

That said though I can see that this new driver structure (with the flexible elements and connections, etc) is a vast improvement on the old, hard-wired stuff. I only hope I can figure out how to make it work with my sensor.

Hi Gary,

Quoted 58 lines · On Wednesday 31 August 2011 14:01:07 Gary Thomas wrote:

Quoted 57 lines · Laurent Pinchart

Quoted 56 lines · On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:

Quoted 55 lines · Laurent Pinchart

Quoted 54 lines · On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:

Quoted 53 lines · Laurent Pinchart

Quoted 52 lines · On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:

Quoted 51 lines · Laurent Pinchart

Quoted 20 lines · On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been

registered. I see a full set in /sys/class/video4linux

Quoted 7 lines

# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 v4l-subdev1 v4l-subdev4 v4l-subdev7 video2

video5 v4l-subdev2 v4l-subdev5 video0 video3

video6

It looks like a udev issue. I don't think that's related to the kernel drivers.

Quoted 19 lines

Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g.

# v4l2-dbg --info /dev/video3

Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x04000002

Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs).

I tried something off-the-shelf which also fails pretty

bad:

Quoted 58 lines

Quoted 50 lines

Quoted 50 lines

Quoted 50 lines

Quoted 49 lines

Quoted 41 lines

Quoted 35 lines

Quoted 31 lines

Quoted 9 lines

            # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
            /dev/video2

junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong.

Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'

Quoted 3 lines

After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline.

Quoted 5 lines

Getting somewhere now, thanks. When I use this full pipeline, I can get all the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline? For example, I'd normally be happy with just the CCDC output. How would I do that?

Quoted 6 lines

Then connect CCDC's pad 1 to the CCDC output video node and capture on that video node.

Quoted 1 line

What pixel format would I use with ffmpeg?

What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if it worked out of the box, would it ? :-)

So, functionality that was present in 2.6.32 (TI PSP version at least) is not currently available?

That's right. You can blame TI for not pushing it to mainline :-)

Quoted 7 lines

Is this only important if I want to push data past the CCDC? In the past, we were happy with just using the CCDC like a frame grabber which delivered YUV data to memory [raw data from /dev/videoN] Is this possible with the CCDC support as is? The only discussion I could find about this on this list was in early March 2011 and I think you implied that it should work. I'm a bit concerned that it won't as the BT656 data has embedded syncs that the CCDC needs to be set up for.

The CCDC needs to be setup for BT.656 synchronization. That shouldn't be difficult.

Quoted 3 lines

I saw a reference to 'Add YUV support to CCDC' on 2010-11-15, but no followup. That work seemed to be for a much older driver and not applicable to the current work, or am I missing something?

Sergio Aguirre worked on YUV support in the CCDC some time ago. The patch didn't make it as-is as some changes were needed, and it hasn't been reworked since.

Quoted 4 lines

Has there been other discussion on this topic (I didn't see it in onthis list which I've been quietly monitoring for two years)? Is the lack of YUV support in CCDC for this current driver (drivers/media/video/omap3isp) a concious decision, or just a lack of movement?

Just a lack of movement. It should not be difficult to implement.

Quoted 1 line

Is there someone at TI that I should contact?

TI moved to the OMAP4, I'm not sure if there's anyone still working on the OMAP3 ISP there.

Quoted 4 lines

I'm just trying to understand what I have to do to move forward on this. I really hadn't planned/scheduled a large effort to recreate functionality that we've already been using for years when we moved to a newer kernel.

I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC.

Quoted 5 lines

That said though I can see that this new driver structure (with the flexible elements and connections, etc) is a vast improvement on the old, hard-wired stuff. I only hope I can figure out how to make it work with my sensor.

I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC.

Quoted 2 lines · Laurent Pinchart

I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC.

What tree are those based on?

Hi Enrico,

Quoted 1 line · On Wednesday 31 August 2011 18:25:28 Enrico wrote:

On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote:

Quoted 4 lines

Quoted 2 lines

I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC.

What tree are those based on?

On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Quoted 7 lines · Laurent Pinchart

Quoted 5 lines · On Wednesday 31 August 2011 18:25:28 Enrico wrote:

Quoted 2 lines · Laurent Pinchart

I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC.

What tree are those based on?

Quoted 4 lines

On
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Sorry to be a pain, but is there an easy way to generate a patchset for this tree against the vanilla released 3.0 tree? (that's what my tree is using)

On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Quoted 4 lines · Laurent Pinchart

On
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward:

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628

Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

I tried also to route it through the resizer but nothing changes.

Is it normal that --enum-formats returns this?

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video capture device.
- Available formats:
Video format: (00000000) 0x0 buffer size 0

Hi Enrico,

Quoted 16 lines · On Thursday 01 September 2011 11:51:58 Enrico wrote:

Quoted 4 lines · Laurent Pinchart

On
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward:

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628

Quoted 2 lines

Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

Does your tvp5150 generate progressive or interlaced images ?

On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart

Quoted 1 line

Does your tvp5150 generate progressive or interlaced images ?

In the driver it is setup to decode by default in bt656 mode, so interlaced.

I've read on the omap trm that the isp can deinterlace it setting properly SDOFST, i just noticed in the register dump this:

omap3isp omap3isp: ###CCDC SDOFST=0x00000000

and maybe this is related too:

omap3isp omap3isp: ###CCDC REC656IF=0x00000000

Moreover i just found this [1] old thread about the same problem, i'm reading it now.

Enrico

[1]: http://www.spinics.net/lists/linux-media/msg28079.html

Quoted 21 lines · Enrico

On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart

Quoted 1 line

Does your tvp5150 generate progressive or interlaced images ?

In the driver it is setup to decode by default in bt656 mode, so interlaced.

I've read on the omap trm that the isp can deinterlace it setting properly SDOFST, i just noticed in the register dump this:

omap3isp omap3isp: ###CCDC SDOFST=0x00000000

and maybe this is related too:

omap3isp omap3isp: ###CCDC REC656IF=0x00000000

Moreover i just found this [1] old thread about the same problem, i'm reading it now.

Enrico

Quoted 1 line

[1]: http://www.spinics.net/lists/linux-media/msg28079.html

Still not working, and much more doubts :D

1) In board code isp_parallel_platform_data i added the bt656 = 1 setting and i see it gets applied, but reading code and omap trm i've found that you must set ISPCCDC_REC656IF_ECCFVH flag too.

2) ispccdc.c:ccdc_config_outlineoffset(..) seems broken to me.

It is used only once in ccdc_configure:
ccdc_config_outlineoffset(ccdc, ccdc->video_out.bpl_value, 0, 0);

so the last two parameters are always set to 0, while they should be (conditionally) set with for ex. EVENODD, 1

Moreover the implementation has this (hope it will keep formatting...):

switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines & 0x7) <<
ISPCCDC_SDOFST_LOFST0_SHIFT); break;
case ODDEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines & 0x7) <<
ISPCCDC_SDOFST_LOFST1_SHIFT); break;
case EVENODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines & 0x7) <<
ISPCCDC_SDOFST_LOFST2_SHIFT); break;
case ODDODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines & 0x7) <<

ISPCCDC_SDOFST_LOFST3_SHIFT); break;
        default:
                break;
        }

But reading the omap trm (Figure 12-77) it seems to me that all the LOFSTX should be set.

3) Last but not least, i'm using V4L2_MBUS_FMT_UYVY8_1X16 format in tvp5150, but i'm not sure it is correct. What is the proper format for bt656? Maybe V4L2_MBUS_FMT_UYVY8_2X8?

Quoted 3 lines · Laurent Pinchart

On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward:

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628

Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

I tried also to route it through the resizer but nothing changes.

Is it normal that --enum-formats returns this?

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video capture device.
- Available formats:
Video format: (00000000) 0x0 buffer size 0

Thanks,

Enrico

Quoted 9 lines · Enrico

Quoted 4 lines · Laurent Pinchart

On
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp
- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward:

Quoted 6 lines

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628

I'm at nearly the same point, but I'm getting a couple of strange messages:

# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[UYVY 720x480], "OMAP3 ISP CCDC":0[UYVY
720x480], "OMAP3 ISP CCDC":1[UYVY 720x480]' Setting up format UYVY 720x480
on pad tvp5150m1 2-005c/0
Format set: unknown 720x480
Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0
Format set: unknown 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
Format set: UYVY 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1
Format set: UYVY 720x480

# yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: UYVY (59565955) 720x480 buffer size 691200
Video format: UYVY (59565955) 720x480 buffer size 691200
6 buffers requested.
length: 691200 offset: 0
Buffer 0 mapped at address 0x40211000.
length: 691200 offset: 692224
Buffer 1 mapped at address 0x402dc000.
length: 691200 offset: 1384448
Buffer 2 mapped at address 0x4047f000.
length: 691200 offset: 2076672
Buffer 3 mapped at address 0x40614000.
length: 691200 offset: 2768896
Buffer 4 mapped at address 0x40792000.
Buffer 5 mapped at address 0x40854000.
Unable to start streaming: 32.

What does 'Format set: unknown 720x480' mean from media-ctl?

Why 'Unable to start streaming: 32' - is this an EPIPE error?

Quoted 11 lines

Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

I tried also to route it through the resizer but nothing changes.

Is it normal that --enum-formats returns this?

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video capture device.
- Available formats:
Video format: (00000000) 0x0 buffer size 0

Hi Gary,

Quoted 52 lines · On Thursday 01 September 2011 14:50:59 Gary Thomas wrote:

Quoted 9 lines · Enrico

Quoted 4 lines · Laurent Pinchart

On
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp
- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward:

Quoted 6 lines

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628

I'm at nearly the same point, but I'm getting a couple of strange messages:

# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive
Setting up link 16:0 ->  5:0 [1]
Setting up link 5:1 ->  6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[UYVY 720x480], "OMAP3 ISP CCDC":0[UYVY
720x480], "OMAP3 ISP CCDC":1[UYVY 720x480]' Setting up format UYVY 720x480
on pad tvp5150m1 2-005c/0
Format set: unknown 720x480
Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0
Format set: unknown 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
Format set: UYVY 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1
Format set: UYVY 720x480

# yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: UYVY (59565955) 720x480 buffer size 691200
Video format: UYVY (59565955) 720x480 buffer size 691200
6 buffers requested.
length: 691200 offset: 0
Buffer 0 mapped at address 0x40211000.
length: 691200 offset: 692224
Buffer 1 mapped at address 0x402dc000.
length: 691200 offset: 1384448
Buffer 2 mapped at address 0x4047f000.
length: 691200 offset: 2076672
Buffer 3 mapped at address 0x40614000.
length: 691200 offset: 2768896
Buffer 4 mapped at address 0x40792000.
Buffer 5 mapped at address 0x40854000.
Unable to start streaming: 32.

Quoted 1 line

What does 'Format set: unknown 720x480' mean from media-ctl?

That probably means that media-ctl got compiled against a different media controller API version than the one running on your system. Make sure you set the --with-kernel-headers= to the path to kernel headers for the kernel running on your system.

Quoted 2 lines

Why 'Unable to start streaming: 32' - is this an EPIPE error?

That means the pipeline hasn't been configured properly. Either the pipeline is broken, or formats on two ends of a link don't match.

Quoted 11 lines

Quoted 11 lines

Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

I tried also to route it through the resizer but nothing changes.

Is it normal that --enum-formats returns this?

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video capture device.
- Available formats:
Video format: (00000000) 0x0 buffer size 0

- entity 16: tvp5150m1 2-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8
       pad0: Output [unknown 720x480 (1,1)/720x480] -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

Quoted 8 lines · Gary Thomas

- entity 16: tvp5150m1 2-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8
       pad0: Output [unknown 720x480 (1,1)/720x480] -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

I didn't notice that, if you are using UYVY8_2X8 the reason is in media-ctl main.c:

{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },

You can add a line like:

{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },

recompile and it should work, i'll try it now.

Quoted 14 lines · Enrico

Quoted 7 lines · Gary Thomas

- entity 16: tvp5150m1 2-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
-> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

I didn't notice that, if you are using UYVY8_2X8 the reason is in media-ctl main.c:

{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },

Quoted 5 lines

You can add a line like:

{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },

recompile and it should work, i'll try it now.

That worked, but now there is another problem.

yavta will set UYVY (PIX_FMT), this will cause a call to ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i < ARRAY_SIZE(formats); ++i) {
                if (formats[i].pixelformat == pix->pixelformat)
                        break;
}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,

          V4L2_MBUS_FMT_UYVY8_1X16, 0,
          V4L2_PIX_FMT_UYVY, 16, 16, },

but you wanted this:

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,

          V4L2_MBUS_FMT_UYVY8_2X8, 0,
          V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if it's possibile to pass a width requirement or if it's already there in some struct passed to the function.

Hi Enrico,

Quoted 17 lines · On Thursday 01 September 2011 19:24:54 Enrico wrote:

Quoted 16 lines · Enrico

Quoted 7 lines · Gary Thomas

- entity 16: tvp5150m1 2-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
-> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

I didn't notice that, if you are using UYVY8_2X8 the reason is in media-ctl main.c:

{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },

You can add a line like:

Quoted 5 lines

Quoted 3 lines

{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },

recompile and it should work, i'll try it now.

That worked, but now there is another problem.

That's correct. My bad for not spotting it sooner.

Quoted 18 lines

yavta will set UYVY (PIX_FMT), this will cause a call to ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i<  ARRAY_SIZE(formats); ++i) {
                 if (formats[i].pixelformat == pix->pixelformat)
                         break;
}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,

           V4L2_MBUS_FMT_UYVY8_1X16, 0,
           V4L2_PIX_FMT_UYVY, 16, 16, },

but you wanted this:

Quoted 7 lines

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,

           V4L2_MBUS_FMT_UYVY8_2X8, 0,
           V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if it's possibile to pass a width requirement or if it's already there in some struct passed to the function.

That's not really an issue, as the isp_video_pix_to_mbus() and isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill the bytesperline and sizeimage fields. From a quick look at the code isp_video_check_format() should succeed as well.

Have you run into any specific issue with isp_video_pix_to_mbus() when using V4L2_MBUS_FMT_UYVY8_2X8 ?

Quoted 23 lines · Laurent Pinchart

Quoted 22 lines · On Thursday 01 September 2011 19:24:54 Enrico wrote:

Quoted 21 lines · Enrico

Quoted 10 lines · Gary Thomas

- entity 16: tvp5150m1 2-005c (1 pad, 1 link)

type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8

pad0: Output [unknown 720x480 (1,1)/720x480]

-> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

I didn't notice that, if you are using UYVY8_2X8 the reason is in media-ctl main.c:

{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },

You can add a line like:

{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

recompile and it should work, i'll try it now.

That worked, but now there is another problem.

That's correct. My bad for not spotting it sooner.

Will you be adding this to the media-ctl tree? Would you like a patch?

Quoted 34 lines

Quoted 20 lines

yavta will set UYVY (PIX_FMT), this will cause a call to ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i< ARRAY_SIZE(formats); ++i) {

                 if (formats[i].pixelformat == pix->pixelformat)
                 
                         break;

}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,

           V4L2_MBUS_FMT_UYVY8_1X16, 0,
           V4L2_PIX_FMT_UYVY, 16, 16, },

but you wanted this:

Quoted 8 lines

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,

           V4L2_MBUS_FMT_UYVY8_2X8, 0,
           V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if it's possibile to pass a width requirement or if it's already there in some struct passed to the function.

That's not really an issue, as the isp_video_pix_to_mbus() and isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill the bytesperline and sizeimage fields. From a quick look at the code isp_video_check_format() should succeed as well.

Quoted 2 lines

Have you run into any specific issue with isp_video_pix_to_mbus() when using V4L2_MBUS_FMT_UYVY8_2X8 ?

Not yet - I was able to configure the pipeline as

   # media-ctl -f '"tvp5150m1 2-005c":0[UYVY2X8 720x480], "OMAP3 ISP
CCDC":0[UYVY2X8 720x480], "OMAP3 ISP CCDC":1[UYVY2X8 720x480]' and this
gets me all the way into my driver (which I'm now working on)

Quoted 17 lines · On Thursday 01 September 2011 19:24:54 Enrico wrote:

yavta will set UYVY (PIX_FMT), this will cause a call to ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i < ARRAY_SIZE(formats); ++i) {
                if (formats[i].pixelformat == pix->pixelformat) break;
}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16, 0, V4L2_PIX_FMT_UYVY, 16, 16, },

but you wanted this:

Quoted 7 lines

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8, 0, V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if it's possibile to pass a width requirement or if it's already there in some struct passed to the function.

That's not really an issue, as the isp_video_pix_to_mbus() and isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill the bytesperline and sizeimage fields. From a quick look at the code isp_video_check_format() should succeed as well.

Have you run into any specific issue with isp_video_pix_to_mbus() when using V4L2_MBUS_FMT_UYVY8_2X8 ?

Quoted 31 lines · Laurent Pinchart

Quoted 17 lines · On Thursday 01 September 2011 19:24:54 Enrico wrote:

yavta will set UYVY (PIX_FMT), this will cause a call to ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i < ARRAY_SIZE(formats); ++i) {
                if (formats[i].pixelformat == pix->pixelformat)
                        break;
}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,

          V4L2_MBUS_FMT_UYVY8_1X16, 0,
          V4L2_PIX_FMT_UYVY, 16, 16, },

but you wanted this:

Quoted 7 lines

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,

          V4L2_MBUS_FMT_UYVY8_2X8, 0,
          V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if it's possibile to pass a width requirement or if it's already there in some struct passed to the function.

That's not really an issue, as the isp_video_pix_to_mbus() and isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill the bytesperline and sizeimage fields. From a quick look at the code isp_video_check_format() should succeed as well.

Quoted 2 lines

Have you run into any specific issue with isp_video_pix_to_mbus() when using V4L2_MBUS_FMT_UYVY8_2X8 ?

No, i assumed it was used to set the format on the pad too but this is not the case, sorry for the noise.

Right now my problem is that i can't get the isp to generate interrupts, i think there is some isp configuration error.

Quoted 2 lines · On Friday 02 September 2011 11:02:23 Enrico wrote:

Right now my problem is that i can't get the isp to generate interrupts, i think there is some isp configuration error.

If your device generates interlaced images that's not surprising, as the CCDC will only receive half the number of lines it expects.

Quoted 6 lines · Laurent Pinchart

Quoted 2 lines · On Friday 02 September 2011 11:02:23 Enrico wrote:

Right now my problem is that i can't get the isp to generate interrupts, i think there is some isp configuration error.

If your device generates interlaced images that's not surprising, as the CCDC will only receive half the number of lines it expects.

Yes that was the first thing i tried, anyway now i have it finally working. Well at least yavta doesn't hang, do you know some application to see raw yuv images?

Now the problem is that the fix is weird...as you suggested you must use half height values for VD0 and VD1 (2/3) interrupts, problem is that it only works if you DISABLE vd1 interrupt.
If it is enabled the vd1_isr is run (once) and nothing else happens.

Quoted 4 lines · On Monday 05 September 2011 18:37:04 Enrico wrote:

Now the problem is that the fix is weird...as you suggested you must use half height values for VD0 and VD1 (2/3) interrupts, problem is that it only works if you DISABLE vd1 interrupt.
If it is enabled the vd1_isr is run (once) and nothing else happens.

Have you set VD0 at half height and VD1 at 1/3 height ?

Quoted 3 lines · On Monday 05 September 2011 18:37:04 you wrote:

Yes that was the first thing i tried, anyway now i have it finally working. Well at least yavta doesn't hang, do you know some application to see raw yuv images?