media controller interface
Any idea why /dev/media0 is not available to media users, in particular those in group 'video'? On my system I see: $ ls -l /dev/vid* crw-rw 1 root video 81, 0 Feb 6 18:45 /dev/video0 crw-rw 1 root video 81, 1 Feb 6 18:45 /dev/video1 crw-rw 1 root video 81, 2 Feb 6 18:45 /dev/video2 crw-rw 1 root video 81, 3 Feb 6 18:45 /dev/video3 $ ls -l /dev/media0 crw--- 1 root root 253, 0 Feb 6 18:45 /dev/media0 So my actual media files are usable by my 'video' user, but not the media controller interface. Also, where are these devices created? I'm running udev 182 Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ISPsupport
On 2012-09-27 15:32, John Tobias wrote: Hi Laurent, I am using Pandaboard ES. I got it working now, although I am still trying to figure out how to use the pipe, resizer, uyvy output instead of SGRBG10. Do you have some example for creating a pipe/link in media-ctl from SGRBG10 to UYVY?. You can try this, but I wasn't able to make it work TI haven't been any help figuring out why (the media-control based pipelines are not officially supported by TI) media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:2 - OMAP4 ISS ISP IPIPE:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPE:1 - OMAP4 ISS ISP resizer:0 [1]' media-ctl -l 'OMAP4 ISS ISP resizer:1 - OMAP4 ISS ISP resizer a output:0 [1]' media-ctl -V 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -V 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -V 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]' media-ctl -V 'OMAP4 ISS ISP IPIPE:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP resizer:0 [UYVY 2592x1944]' If you can make it go, please let me/us know how! On Wed, Sep 26, 2012 at 4:33 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi John, On Monday 10 September 2012 20:00:54 John Tobias wrote: Hi all, I tried devel-ISPSUPPORT-IPIPE and devel-ISPSUPPORT, It would help you you told use what hardware you're running on, what kernel version you're using, and what devel-ISPSUPPORT-IPIPE and devel-ISPSUPPORT are. the kernel detected my image sensor (ov5650). But, when I execute the yavta /dev/video0 -c4 -n1 -s2592x1944 -fSGRBG10 -Fov5650-2592x1944-#.bin I was getting Unable to start streaming: Invalid argument (22).. I would like to know if anyone here can guide me a bit in order to have a working environment?. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media-ctl: Fix build error with newer autotools
Rename configure.in to be configure.ac - required for newer
versions of autotools (older versions silently handled
this, now it's an error)
Signed-off-by: Gary Thomas g...@mlbassoc.com
---
configure.ac | 93 ++
configure.in | 93 --
2 files changed, 93 insertions(+), 93 deletions(-)
create mode 100644 configure.ac
delete mode 100644 configure.in
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..98459d4
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,93 @@
+AC_PREREQ([2.61])
+AC_INIT([media-ctl], [0.0.1], [laurent.pinch...@ideasonboard.com])
+AC_CONFIG_SRCDIR([src/main.c])
+AC_CONFIG_AUX_DIR([config])
+AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_MACRO_DIR([m4])
+
+AM_INIT_AUTOMAKE([-Wall -Werror foreign])
+
+# Checks for programs.
+AC_PROG_CC
+AM_PROG_CC_C_O
+# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it
+m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
+AC_PROG_LIBTOOL
+
+# Checks for libraries.
+
+AC_ARG_WITH([libudev],
+AS_HELP_STRING([--with-libudev],
+[Enable libudev to detect a device name]))
+
+AS_IF([test x$with_libudev = xyes],
+[PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)],
+[have_libudev=no])
+
+AS_IF([test x$have_libudev = xyes],
+[
+AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
+LIBUDEV_CFLAGS=$libudev_CFLAGS
+LIBUDEV_LIBS=$libudev_LIBS
+AC_SUBST(LIBUDEV_CFLAGS)
+AC_SUBST(LIBUDEV_LIBS)
+],
+[AS_IF([test x$with_libudev = xyes],
+[AC_MSG_ERROR([libudev requested but not found])
+])
+])
+
+
+# Kernel headers path.
+AC_ARG_WITH(kernel-headers,
+[AC_HELP_STRING([--with-kernel-headers=DIR],
+[specify path of Linux kernel headers [/usr/src/kernel-headers]])],
+[case ${withval} in
+yes | no) AC_MSG_ERROR([bad value ${withval} for
--with-kernel-headers]) ;;
+*) KERNEL_HEADERS_DIR=${withval} ;;
+ esac],
+[KERNEL_HEADERS_DIR=/usr/src/kernel-headers])
+
+CPPFLAGS=-I$KERNEL_HEADERS_DIR/include
+
+# Checks for header files.
+AC_CHECK_HEADERS([linux/media.h \
+ linux/types.h \
+ linux/v4l2-mediabus.h \
+ linux/v4l2-subdev.h \
+ linux/videodev2.h],
+ [],
+ [echo ERROR: Kernel header file not found or not usable!;
exit 1])
+
+AC_CHECK_HEADERS([fcntl.h \
+ stdlib.h \
+ string.h \
+ sys/ioctl.h \
+ sys/time.h \
+ unistd.h],
+ [],
+ [echo ERROR: Header file not found or not usable!; exit 1])
+
+# Checks for typedefs, structures, and compiler characteristics.
+AC_C_INLINE
+AC_TYPE_SIZE_T
+AC_CHECK_MEMBERS([struct stat.st_rdev])
+
+# Checks for library functions.
+AC_HEADER_MAJOR
+AS_IF([test x$cross_compiling != xyes],
+[
+AC_FUNC_MALLOC
+AC_FUNC_REALLOC
+])
+AC_CHECK_FUNCS([memset strerror strrchr strtoul])
+
+AC_CONFIG_FILES([
+ Makefile
+ src/Makefile
+ libmediactl.pc
+ libv4l2subdev.pc
+])
+
+AC_OUTPUT
+
diff --git a/configure.in b/configure.in
deleted file mode 100644
index 98459d4..000
--- a/configure.in
+++ /dev/null
@@ -1,93 +0,0 @@
-AC_PREREQ([2.61])
-AC_INIT([media-ctl], [0.0.1], [laurent.pinch...@ideasonboard.com])
-AC_CONFIG_SRCDIR([src/main.c])
-AC_CONFIG_AUX_DIR([config])
-AC_CONFIG_HEADERS([config.h])
-AC_CONFIG_MACRO_DIR([m4])
-
-AM_INIT_AUTOMAKE([-Wall -Werror foreign])
-
-# Checks for programs.
-AC_PROG_CC
-AM_PROG_CC_C_O
-# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it
-m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
-AC_PROG_LIBTOOL
-
-# Checks for libraries.
-
-AC_ARG_WITH([libudev],
-AS_HELP_STRING([--with-libudev],
-[Enable libudev to detect a device name]))
-
-AS_IF([test x$with_libudev = xyes],
-[PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)],
-[have_libudev=no])
-
-AS_IF([test x$have_libudev = xyes],
-[
-AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
-LIBUDEV_CFLAGS=$libudev_CFLAGS
-LIBUDEV_LIBS=$libudev_LIBS
-AC_SUBST(LIBUDEV_CFLAGS)
-AC_SUBST(LIBUDEV_LIBS)
-],
-[AS_IF([test x$with_libudev = xyes],
-[AC_MSG_ERROR([libudev requested but not found])
-])
-])
-
-
-# Kernel headers path.
-AC_ARG_WITH(kernel-headers,
-[AC_HELP_STRING([--with-kernel-headers=DIR],
-[specify path of Linux kernel headers [/usr/src/kernel-headers]])],
-[case ${withval} in
-yes | no) AC_MSG_ERROR([bad value ${withval} for
--with-kernel-headers]) ;;
-*) KERNEL_HEADERS_DIR=${withval} ;;
- esac],
-[KERNEL_HEADERS_DIR=/usr/src/kernel-headers])
-
-CPPFLAGS=-I$KERNEL_HEADERS_DIR/include
-
-# Checks for header files.
-AC_CHECK_HEADERS([linux/media.h \
- linux/types.h \
- linux/v4l2
gstreamer caps and v4l2
I know this is slightly off topic for this list, but I hope
someone here can help me. I have asked on the gstreamer list,
but it's quite often slow/unreliable.
I'm trying to capture video using v4l2src. The problem is
that my sensor only delivers bayer RGB and I can't figure
out what the caps should be to match. The Linux driver calls
the video mode SGRBG10
When I tried these caps
'video/x-raw-bayer,format=(string)grbg,width=2592,height=1944'
it failed with this assertion:
gst_v4l2src_fixate: assertion `G_VALUE_TYPE (v) == GST_TYPE_LIST' failed
So, I thought I might need a more general string:
'video/x-raw-bayer,format=(string){bggr,grbg,gbrg,rggb},width=2592,height=1944'
which now fails with:
gst_value_get_fourcc: assertion `GST_VALUE_HOLDS_FOURCC (value)' failed
Any ideas how I tell v4l2src the details of my sensor?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 support
Ping? Can anyone help me with these issues? On 2012-07-15 14:24, Gary Thomas wrote: On 2012-07-15 08:31, Sergio Aguirre wrote: Hi Gary, On Fri, Jul 13, 2012 at 5:24 AM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? Sure. I just pushed an internal branch I had, named: devel-ISPSUPPORT-IPIPE, please take that as a base. And please try these commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]','OMAP4 ISS ISP IPIPEIF:2 - OMAP4 ISS ISP IPIPE:0 [1]','OMAP4 ISS ISP IPIPE:1 - OMAP4 ISS ISP resizer:0 [1]','OMAP4 ISS ISP resizer:1 - OMAP4 ISS ISP resizer a output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]','OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPE:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP resizer:0 [UYVY 2592x1944]' yavta /dev/video3 -c4 -n1 -s2592x1944 -fUYVY -Fov5650_2592x1944_UYVY_8bpp.yuv With the new branch, I am able to set up the pipeline for UYVY. That part's good. However, just like before, with either RAW10 or UYVY, the grab process does not start more times than it does (it only starts about 1 out of 10 tries). If I just ^C and try again, it may start, it may not. The single time I was able to get the UYVY capture to work, I got an error after the first frame: # grab-uyvy Device /dev/video3 opened. Device `OMAP4 ISS ISP resizer a output
Re: OMAP4 support
On 2012-07-15 08:31, Sergio Aguirre wrote: Hi Gary, On Fri, Jul 13, 2012 at 5:24 AM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? Sure. I just pushed an internal branch I had, named: devel-ISPSUPPORT-IPIPE, please take that as a base. And please try these commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]','OMAP4 ISS ISP IPIPEIF:2 - OMAP4 ISS ISP IPIPE:0 [1]','OMAP4 ISS ISP IPIPE:1 - OMAP4 ISS ISP resizer:0 [1]','OMAP4 ISS ISP resizer:1 - OMAP4 ISS ISP resizer a output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]','OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPE:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP resizer:0 [UYVY 2592x1944]' yavta /dev/video3 -c4 -n1 -s2592x1944 -fUYVY -Fov5650_2592x1944_UYVY_8bpp.yuv With the new branch, I am able to set up the pipeline for UYVY. That part's good. However, just like before, with either RAW10 or UYVY, the grab process does not start more times than it does (it only starts about 1 out of 10 tries). If I just ^C and try again, it may start, it may not. The single time I was able to get the UYVY capture to work, I got an error after the first frame: # grab-uyvy Device /dev/video3 opened. Device `OMAP4 ISS ISP resizer a output' on `media' is a video capture device. Video format set: UYVY (59565955) 2592x1944 buffer size
Re: OMAP4 support
On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? I have been able to capture RAW10 data, but often the whole thing just sits there (hangs). Restarting the process sometimes works, sometimes not. Looking at the registers and the actual signals on a scope do not show any difference that we can find. Any ideas what might cause this? Have you seen it as well? Thanks for the help - Please let me know how I can get this working... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 support
On 2012-07-13 04:24, Gary Thomas wrote: On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? I have been able to capture RAW10 data, but often the whole thing just sits there (hangs). Restarting the process sometimes works, sometimes not. Looking at the registers and the actual signals on a scope do not show any difference that we can find. Any ideas what might cause this? Have you seen it as well? Thanks for the help - Please let me know how I can get this working... One more question - what's the best branch to work from in your tree? I'm currently using devel-ISPSUPPORT -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 support
I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? Also, does anyone know of any support for the CPI input interface which is available on the OMAP4460? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 support
On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3ISP won't start
I'm testing Laurent's tree with the BT656 support. My system has an OMAP/3530 + TVP5150 running in BT656 mode. Sadly, this isn't working - I only get an endless stream of these messages [ 43.457427] omap3isp omap3isp: CCDC won't become idle! [ 43.490814] omap3isp omap3isp: CCDC won't become idle! I've compared the operation between a similarly patched 3.2 system and the current 3.3. All OMAP3 CCDC registers are identical, as well as the TVP5150 registers at the time that streaming is enabled. Any ideas what might be wrong? where else to look? Thanks Just to be clear - I did have to make a few patches to both the TVP5150 driver and CCDC part of OMAP3ISP as some of the BT656 support is still not in Laurent's tree. I'll send patches, etc, once I get it working, but as mentioned above, at least at the register level, these are set up the same as in my working tree. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3ISP won't start
On 2012-04-02 06:32, Enrico wrote: On Mon, Apr 2, 2012 at 2:24 PM, Gary Thomasg...@mlbassoc.com wrote: Just to be clear - I did have to make a few patches to both the TVP5150 driver and CCDC part of OMAP3ISP as some of the BT656 support is still not in Laurent's tree. I'll send patches, etc, once I get it working, but as mentioned above, at least at the register level, these are set up the same as in my working tree. What patches did you add on top of Laurent tree? I had a look some days ago and for example it's missing the right setup for VD0/VD1 (no VD1 and VD0 set to half height), this could be the cause of a not working isp. You can check if you get interrupts from the isp (/proc/interrupts). Getting lots of interrupts: 24: 3376 INTC omap-iommu.0, OMAP3 ISP Another thing that is missing is the logic in the irq handler that wait for a complete frame before calling next video buffer (or something like that). The items you mention are just what I merged from my previous kernel. My changes are still pretty rough but I can send them to you if you'd like. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3ISP won't start
On 2012-04-02 07:15, Enrico wrote:
On Mon, Apr 2, 2012 at 2:45 PM, Gary Thomasg...@mlbassoc.com wrote:
The items you mention are just what I merged from my previous kernel.
My changes are still pretty rough but I can send them to you if you'd
like.
Post them here and we will try to spot where the problem is, they
could be useful for Laurent too as a reference.
Attached.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index f62a38b..ab2717b 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -62,6 +62,8 @@ static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_UYVY8_2X8,
};
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+
/*
* ccdc_print_status - Print current CCDC Module register values.
* @ccdc: Pointer to ISP CCDC device.
@@ -794,11 +796,16 @@ static void ccdc_apply_controls(struct isp_ccdc_device *ccdc)
void omap3isp_ccdc_restore_context(struct isp_device *isp)
{
struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct v4l2_mbus_framefmt *format;
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_VDLC);
- ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
- | OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+ if ((format-code != V4L2_MBUS_FMT_UYVY8_2X8)
+(format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF |
+ OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
ccdc_apply_controls(ccdc);
ccdc_configure_fpc(ccdc);
}
@@ -1012,6 +1019,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1023,10 +1033,10 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
if (pdata pdata-bt656)
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
}
/* CCDC formats descriptions */
@@ -1108,6 +1118,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
struct isp_parallel_platform_data *pdata = NULL;
struct v4l2_subdev *sensor;
struct v4l2_mbus_framefmt *format;
+ struct v4l2_pix_format pix;
const struct isp_format_info *fmt_info;
struct v4l2_subdev_format fmt_src;
unsigned int depth_out;
@@ -1166,6 +1177,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
/* CCDC_PAD_SINK */
format = ccdc-formats[CCDC_PAD_SINK];
+ if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
+ isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG,
+ ISPCCDC_CFG_Y8POS);
+
/* Mosaic filter */
switch (format-code) {
case V4L2_MBUS_FMT_SRGGB10_1X10:
@@ -1185,28 +1200,70 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
ccdc_pattern = ccdc_sgrbg_pattern;
break;
}
- ccdc_config_imgattr(ccdc, ccdc_pattern);
- /* Generate VD0 on the last line of the image and VD1 on the
- * 2/3 height line.
- */
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+ if ((format-code != V4L2_MBUS_FMT_YUYV8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc_config_imgattr(ccdc, ccdc_pattern);
+
+ /* BT656: Generate VD0 on the last line of each field, and we
+ * don't use VD1.
+ * Non BT656: Generate VD0 on the last line of the image and VD1 on the
+ * 2/3 height line.
+ */
+ if (pdata-bt656)
+ isp_reg_writel(isp,
+ (format-height/2 - 2) ISPCCDC_VDINT_0_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+ else
+ isp_reg_writel(isp,
+ ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
+ ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
- isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
- ((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
+ isp_video_mbus_to_pix(ccdc-video_out, format, pix);
+
+ /* For BT656 the number of bytes would be width*2 */
+ if (pdata-bt656)
+ isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
+ ((pix.bytesperline - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+ OMAP3_ISP_IOMEM_CCDC
Re: OMAP3ISP won't start
On 2012-04-02 08:38, Enrico wrote: On Mon, Apr 2, 2012 at 3:31 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-04-02 07:15, Enrico wrote: On Mon, Apr 2, 2012 at 2:45 PM, Gary Thomasg...@mlbassoc.comwrote: The items you mention are just what I merged from my previous kernel. My changes are still pretty rough but I can send them to you if you'd like. Post them here and we will try to spot where the problem is, they could be useful for Laurent too as a reference. Attached. I just had a quick look and it seems everything is there, i can't test it right now but when i did test a mainline 3.3 kernel with my patches i had to use the nohlt kernel parm. If i'm not wrong without that param i had the same error, you can give it a try. Hurray, that does work. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3isp Linux-3.3
Laurent, I'm looking at your latest tree. I've merged my platform support that I had working in 3.2, but I never see the TVP5150 sensor driver being probed. Has this changed? Do you have an example [tree] with working board support? Previously you had a branch with support for the BeagleBoard in place. Is 'omap3isp-sensors-board' up to date? Thanks - I'll keep trying to figure out what's happening here. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp Linux-3.3
On 2012-03-30 07:33, Laurent Pinchart wrote: Hi Gary, On Friday 30 March 2012 04:59:24 Gary Thomas wrote: Laurent, I'm looking at your latest tree. I've merged my platform support that I had working in 3.2, but I never see the TVP5150 sensor driver being probed. Is the OMAP3 ISP driver loaded ? What does it print to the kernel log ? Has this changed? Do you have an example [tree] with working board support? Previously you had a branch with support for the BeagleBoard in place. Is 'omap3isp-sensors-board' up to date? The branch is up-to-date, yes. It contains support for the Beagleabord-xM with the MT9P031 camera module. Thanks. My configuration was a bit messed up, got that part working now. Sadly, the TVP5150 driver has no pad operations which I'm now re-adding from my previous version. I'll let you know what else I find. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2012-03-26 09:37, Joshua Hintze wrote: Gary, I'm using linux branch from 2.6.39 Fetch URL: git://www.sakoman.com/git/linux-omap-2.6 branch: omap-2.6.39 I'm using an overo board so I figured I should follow Steve Sakoman's repository. Which brings up another question, would you recommend going off of one of Laurent's repo's and if so which one? The last time I tried Laurent's repo, it did not have the UYVY support in the OMAP3ISP/CCDC merged in. I don't know if that has changed recently. On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomasg...@mlbassoc.com wrote: On 2012-03-25 23:13, Joshua Hintze wrote: Alright I made some progress on this. I can access the Mt9p031 registers that are exposed using a command such as ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can set the exposure and analog gain with ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8--- This seems to give the desired effect. Note that ./yavta -w (short option for --set-control) gives a seg fault for me. Possible bug in yavta?? Now I'm working on fixing the white balance. In my office the incandescent light bulbs give off a yellowish tint late at night. I've been digging through the omap3isp code to figure out how to enable the automatic white balance. I was able to find the private IOCTLs for the previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this IOCTL I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and OMAP3ISP_PREV_RGB2RGB. Since I wasn't sure where to start on adjusting these values I just set them all to the TRM's default register values. However when I did so a strange thing occurred. What I saw was all the colors went to a decent color. I'm curious if anybody can shed some light on the best way to get a high quality image. Ideally if I could just set a bit for auto white balance and auto exposure that could be good too. Just curious - what codebase (git URL) are you using? On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintzejoshua.hin...@gmail.com wrote: Sorry to bring up this old message list. I was curious when you spoke about the ISP preview engine being able to adjust the white balance. When I enumerate the previewer's available controls all I see is... root@overo:~# ./yavta -l /dev/v4l-subdev3 --- User Controls (class 0x00980001) --- control 0x00980900 `Brightness' min 0 max 255 step 1 default 0 current 0. control 0x00980901 `Contrast' min 0 max 255 step 1 default 16 current 16. 2 controls found. Is this what you are referring to? Are there other settings I can adjust to get the white balance and focus better using the OMAP3 ISP AWEB/OMAP3 ISP AF? Thanks, Josh Hi Gary, On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote: On 2011-11-30 07:57, Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: [snip] This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output line lenghts must be multiple of 32 bytes. The driver adds padding at end of lines when the output width isn't a multiple of 16 pixels. Any guess which resolution(s) I should change and to what? I changed the resizer output to be 672x496 and was able to capture video using ffmpeg. I don't know what to expect with this sensor (I've never seen it in use before), but the image seems to have color balance issues - it's awash in a green hue. It may be the poor lighting in my office... I did try the 9 test patterns which I was able to select via # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N and these looked OK. You can see them at http://www.mlbassoc.com/misc/mt9p031_images/ Neither the sensor nor the OMAP3 ISP implement automatic white balance. The ISP preview engine can be used to modify the white balance, and the statistics engine can be used to extract data useful to compute the white balance parameters, but linking the two needs to be performed in userspace. So this means that your original problem comes from the BT656 patches. Yes, it does look that way. Now that I have
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-30 10:30, Gary Thomas wrote: On 2012-01-20 05:19, Laurent Pinchart wrote: Hi Enrico, On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0] .i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. rant Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). /rant I totally understand your feeling. I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I have no YUV image source hardware, so I can only review the patches but not test them. If someone can rebase the existing patches on top of http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv and test them, then I'll review the result. The attached patches produce a working setup against Laurent's tree above. That said, I don't recall exactly where which changes came from (I'm old school and not very git savvy, sorry). I've CC'd all the folks I think provided at least part of these changes. Perhaps we can all work together to come up with a proper set of patches which can be pushed upstream for this, once and for all? Thanks Ping! Is no one but me interested in getting these changes into the mainline? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-20 05:19, Laurent Pinchart wrote:
Hi Enrico,
On Thursday 19 January 2012 15:17:57 Enrico wrote:
On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomasg...@mlbassoc.com wrote:
On 2012-01-19 06:35, Gary Thomas wrote:
My camera init code is attached. In the previous kernel, the I2C bus was
probed implicitly when I initialized the OMAP3ISP. I thought I
remembered some discussion about how that worked (maybe changing), so
this is probably
where the problem starts.
If you have an example, I can check my setup against it.
Note: I reworked how the sensor+I2C was initialized to be
omap3_init_camera(cobra3530p73_isp_platform_data);
omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0]
.i2c_adapter_id, 400,
cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1);
The TVP5150 is now found, but 'media-ctl -p' still dies :-(
Have a look at [1] (the linux_3.2.bb file to see the list of
patches,inside linux-3.2 directory for the actual patches), it's based
on mainline kernel 3.2 and the bt656 patches i submitted months ago,
it should be easy to adapt it for you board.
rant
Really, there are patches for all these problems since months (from
me, Javier, TI), but because no maintainer cared (apart from Laurent)
they were never reviewed/applied and there is always someone who comes
back with all the usual problems (additional yuv format, bt656 mode,
tvp5150 that doesn't work...).
/rant
I totally understand your feeling.
I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I
have no YUV image source hardware, so I can only review the patches but not
test them.
If someone can rebase the existing patches on top of
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-yuv and test them, then I'll review the result.
The attached patches produce a working setup against Laurent's tree above.
That said, I don't recall exactly where which changes came from (I'm old
school and not very git savvy, sorry). I've CC'd all the folks I think
provided at least part of these changes. Perhaps we can all work together
to come up with a proper set of patches which can be pushed upstream
for this, once and for all?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
From 2ab6c0c7b481d116c9d7faf120efcff1ef2a732f Mon Sep 17 00:00:00 2001
From: Gary Thomas g...@mlbassoc.com
Date: Wed, 25 Jan 2012 07:57:21 -0700
Subject: [PATCH 1/2] Merge working driver for TVP5150
---
drivers/media/video/tvp5150.c | 419 -
include/media/tvp5150.h |6 +
2 files changed, 375 insertions(+), 50 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 6be9910..a472ebe 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -5,15 +5,17 @@
* This code is placed under the terms of the GNU General Public License v2
*/
+#include linux/module.h
#include linux/i2c.h
#include linux/slab.h
#include linux/videodev2.h
#include linux/delay.h
-#include linux/module.h
#include media/v4l2-device.h
#include media/tvp5150.h
#include media/v4l2-chip-ident.h
#include media/v4l2-ctrls.h
+#include media/v4l2-subdev.h
+#include media/v4l2-mediabus.h
#include tvp5150_reg.h
@@ -26,11 +28,79 @@ static int debug;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, Debug level (0-2));
+/* enum tvp515x_std - enum for supported standards */
+enum tvp515x_std {
+ STD_PAL_BDGHIN = 0,
+ STD_NTSC_MJ,
+ STD_INVALID
+};
+
+/**
+ * struct tvp515x_std_info - Structure to store standard informations
+ * @width: Line width in pixels
+ * @height:Number of active lines
+ * @video_std: Value to write in REG_VIDEO_STD register
+ * @standard: v4l2 standard structure information
+ */
+struct tvp515x_std_info {
+ u8 video_std;
+ struct v4l2_standard standard;
+ struct v4l2_mbus_framefmt format;
+};
+
+/**
+ * Supported standards -
+ *
+ * Currently supports two standards only, need to add support for rest of the
+ * modes, like SECAM, etc...
+ */
+static struct tvp515x_std_info tvp515x_std_list[] = {
+ /* Standard: STD_NTSC_MJ */
+ /* Standard: STD_PAL_BDGHIN */
+ [STD_PAL_BDGHIN] = {
+ .video_std = VIDEO_STD_PAL_BDGHIN_BIT,
+ .standard = {
+ .index = 1,
+ .id = V4L2_STD_PAL,
+ .name = PAL,
+ .frameperiod = {1, 25},
+ .framelines = 625
+ },
+ .format = {
+ .width = PAL_NUM_ACTIVE_PIXELS,
+ .height = PAL_NUM_ACTIVE_LINES,
+ .code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .field = V4L2_FIELD_INTERLACED,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ },
+ },
+ [STD_NTSC_MJ] = {
+ .video_std = VIDEO_STD_NTSC_MJ_BIT,
+ .standard = {
+ .index = 0,
+ .id = V4L2_STD_NTSC,
+ .name = NTSC,
+ .frameperiod = {1001, 3},
+ .framelines = 525
+ },
+ .format = {
+ .width
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-17 08:33, Laurent Pinchart wrote: snip I already had a couple of YUV support patches in my OMAP3 ISP tree at git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and pushed them to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv. Could you please try them, and see if they're usable with your sensor ? I just tried this kernel with my board. The media control infrastructure comes up and all of the devices are created, but I can't access them. From the bootup log: Linux media interface: v0.10 Linux video capture interface: v2.00 When I try to access the devices: root@cobra3530p73:~# media-ctl -p Opening media device /dev/media0 media_open_debug: Can't open media device /dev/media0 Failed to open /dev/media0 The devices look OK to me: root@cobra3530p73:~# ls -l /dev/v* /dev/med* crw--- 1 root root 252, 0 Nov 8 10:44 /dev/media0 crw-rw 1 root video 81, 7 Nov 8 10:44 /dev/v4l-subdev0 crw-rw 1 root video 81, 8 Nov 8 10:44 /dev/v4l-subdev1 crw-rw 1 root video 81, 9 Nov 8 10:44 /dev/v4l-subdev2 crw-rw 1 root video 81, 10 Nov 8 10:44 /dev/v4l-subdev3 crw-rw 1 root video 81, 11 Nov 8 10:44 /dev/v4l-subdev4 crw-rw 1 root video 81, 12 Nov 8 10:44 /dev/v4l-subdev5 crw-rw 1 root video 81, 13 Nov 8 10:44 /dev/v4l-subdev6 crw-rw 1 root video 81, 14 Nov 8 10:44 /dev/v4l-subdev7 crw-rw 1 root video 81, 15 Nov 8 10:44 /dev/v4l-subdev8 crw-rw 1 root tty7, 0 Nov 8 10:44 /dev/vcs crw-rw 1 root tty7, 1 Nov 8 10:44 /dev/vcs1 crw-rw 1 root tty7, 128 Nov 8 10:44 /dev/vcsa crw-rw 1 root tty7, 129 Nov 8 10:44 /dev/vcsa1 crw-rw 1 root video 81, 0 Nov 8 10:44 /dev/video0 crw-rw 1 root video 81, 1 Nov 8 10:44 /dev/video1 crw-rw 1 root video 81, 2 Nov 8 10:44 /dev/video2 crw-rw 1 root video 81, 3 Nov 8 10:44 /dev/video3 crw-rw 1 root video 81, 4 Nov 8 10:44 /dev/video4 crw-rw 1 root video 81, 5 Nov 8 10:44 /dev/video5 crw-rw 1 root video 81, 6 Nov 8 10:44 /dev/video6 Ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 05:50, Laurent Pinchart wrote:
Hi Gary,
On Thursday 19 January 2012 13:41:57 Gary Thomas wrote:
On 2012-01-17 08:33, Laurent Pinchart wrote:
snip
I already had a couple of YUV support patches in my OMAP3 ISP tree at
git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and
pushed them to
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-yuv. Could you please try them, and see if they're usable with
your sensor ?
I just tried this kernel with my board. The media control infrastructure
comes up and all of the devices are created, but I can't access them.
From the bootup log:
Linux media interface: v0.10
Linux video capture interface: v2.00
Any message from the omap3isp driver and from the sensor driver ?
No, it doesn't appear that the sensor was probed (or maybe it failed but
no messages). I'll check into this.
Has the way of adding the sensors on the i2c bus changed? I have my
TVP5150 on a i2c-2 all by itself and with the 3.0+ kernel, it was being
added when I initialized the camera subsystem.
Do you have an example driver (like the BeagleBoard one that was in
your omap3isp-sensors-next branch previously)?
When I try to access the devices:
root@cobra3530p73:~# media-ctl -p
Opening media device /dev/media0
media_open_debug: Can't open media device /dev/media0
Failed to open /dev/media0
Could you please strace that ?
Attached. Looks like it blows up immediately.
Note: my media-ctl program was built from SRCREV
7266b1b5433b5644a06f05edf61c36864ab11683
The devices look OK to me:
root@cobra3530p73:~# ls -l /dev/v* /dev/med*
crw--- 1 root root 252, 0 Nov 8 10:44 /dev/media0
crw-rw 1 root video 81, 7 Nov 8 10:44 /dev/v4l-subdev0
crw-rw 1 root video 81, 8 Nov 8 10:44 /dev/v4l-subdev1
crw-rw 1 root video 81, 9 Nov 8 10:44 /dev/v4l-subdev2
crw-rw 1 root video 81, 10 Nov 8 10:44 /dev/v4l-subdev3
crw-rw 1 root video 81, 11 Nov 8 10:44 /dev/v4l-subdev4
crw-rw 1 root video 81, 12 Nov 8 10:44 /dev/v4l-subdev5
crw-rw 1 root video 81, 13 Nov 8 10:44 /dev/v4l-subdev6
crw-rw 1 root video 81, 14 Nov 8 10:44 /dev/v4l-subdev7
crw-rw 1 root video 81, 15 Nov 8 10:44 /dev/v4l-subdev8
crw-rw 1 root tty7, 0 Nov 8 10:44 /dev/vcs
crw-rw 1 root tty7, 1 Nov 8 10:44 /dev/vcs1
crw-rw 1 root tty7, 128 Nov 8 10:44 /dev/vcsa
crw-rw 1 root tty7, 129 Nov 8 10:44 /dev/vcsa1
crw-rw 1 root video 81, 0 Nov 8 10:44 /dev/video0
crw-rw 1 root video 81, 1 Nov 8 10:44 /dev/video1
crw-rw 1 root video 81, 2 Nov 8 10:44 /dev/video2
crw-rw 1 root video 81, 3 Nov 8 10:44 /dev/video3
crw-rw 1 root video 81, 4 Nov 8 10:44 /dev/video4
crw-rw 1 root video 81, 5 Nov 8 10:44 /dev/video5
crw-rw 1 root video 81, 6 Nov 8 10:44 /dev/video6
Have the device nodes have been created manually ?
No, automatically created by udev.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
execve(/usr/bin/media-ctl, [media-ctl, -p], [/* 10 vars */]) = 0
brk(0) = 0x13000
uname({sys=Linux, node=cobra3530p73, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40007000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=8733, ...}) = 0
mmap2(NULL, 8733, PROT_READ, MAP_PRIVATE, 3, 0) = 0x400e7000
close(3)= 0
open(/usr/lib/libmediactl.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340\t\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=8776, ...}) = 0
mmap2(NULL, 40300, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x40182000
mprotect(0x40184000, 28672, PROT_NONE) = 0
mmap2(0x4018b000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x4018b000
close(3)= 0
open(/usr/lib/libv4l2subdev.so.0, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\350\10\0\0004\0\0\0..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=8220, ...}) = 0
mmap2(NULL, 39692, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x400dd000
mprotect(0x400df000, 28672, PROT_NONE) = 0
mmap2(0x400e6000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x400e6000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0hy\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1175744, ...}) = 0
mmap2(NULL, 1217808
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 06:28, Laurent Pinchart wrote:
Hi Gary,
On Thursday 19 January 2012 14:13:53 Gary Thomas wrote:
On 2012-01-19 05:50, Laurent Pinchart wrote:
On Thursday 19 January 2012 13:41:57 Gary Thomas wrote:
On 2012-01-17 08:33, Laurent Pinchart wrote:
snip
I already had a couple of YUV support patches in my OMAP3 ISP tree at
git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree
and pushed them to
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp
- omap3isp-yuv. Could you please try them, and see if they're usable
with your sensor ?
I just tried this kernel with my board. The media control
infrastructure comes up and all of the devices are created, but I can't
access them.
From the bootup log:
Linux media interface: v0.10
Linux video capture interface: v2.00
Any message from the omap3isp driver and from the sensor driver ?
No, it doesn't appear that the sensor was probed (or maybe it failed but
no messages). I'll check into this.
Is the omap3-isp driver compiled as a module ? If so, make sure iommu2.ko is
loaded first. 'rmmod omap3-isp modprobe iommu2 modprobe omap3-isp' is a
quick way to test it.
I have everything compiled in - no modules.
My camera init code is attached. In the previous kernel, the I2C bus was
probed implicitly when I initialized the OMAP3ISP. I thought I remembered
some discussion about how that worked (maybe changing), so this is probably
where the problem starts.
If you have an example, I can check my setup against it.
Has the way of adding the sensors on the i2c bus changed? I have my
TVP5150 on a i2c-2 all by itself and with the 3.0+ kernel, it was being
added when I initialized the camera subsystem.
Do you have an example driver (like the BeagleBoard one that was in
your omap3isp-sensors-next branch previously)?
When I try to access the devices:
root@cobra3530p73:~# media-ctl -p
Opening media device /dev/media0
media_open_debug: Can't open media device /dev/media0
Failed to open /dev/media0
Could you please strace that ?
Attached. Looks like it blows up immediately.
Note: my media-ctl program was built from SRCREV
7266b1b5433b5644a06f05edf61c36864ab11683
The devices look OK to me:
root@cobra3530p73:~# ls -l /dev/v* /dev/med*
crw--- 1 root root 252, 0 Nov 8 10:44 /dev/media0
crw-rw 1 root video 81, 7 Nov 8 10:44 /dev/v4l-subdev0
crw-rw 1 root video 81, 8 Nov 8 10:44 /dev/v4l-subdev1
crw-rw 1 root video 81, 9 Nov 8 10:44 /dev/v4l-subdev2
crw-rw 1 root video 81, 10 Nov 8 10:44 /dev/v4l-subdev3
crw-rw 1 root video 81, 11 Nov 8 10:44 /dev/v4l-subdev4
crw-rw 1 root video 81, 12 Nov 8 10:44 /dev/v4l-subdev5
crw-rw 1 root video 81, 13 Nov 8 10:44 /dev/v4l-subdev6
crw-rw 1 root video 81, 14 Nov 8 10:44 /dev/v4l-subdev7
crw-rw 1 root video 81, 15 Nov 8 10:44 /dev/v4l-subdev8
crw-rw 1 root tty7, 0 Nov 8 10:44 /dev/vcs
crw-rw 1 root tty7, 1 Nov 8 10:44 /dev/vcs1
crw-rw 1 root tty7, 128 Nov 8 10:44 /dev/vcsa
crw-rw 1 root tty7, 129 Nov 8 10:44 /dev/vcsa1
crw-rw 1 root video 81, 0 Nov 8 10:44 /dev/video0
crw-rw 1 root video 81, 1 Nov 8 10:44 /dev/video1
crw-rw 1 root video 81, 2 Nov 8 10:44 /dev/video2
crw-rw 1 root video 81, 3 Nov 8 10:44 /dev/video3
crw-rw 1 root video 81, 4 Nov 8 10:44 /dev/video4
crw-rw 1 root video 81, 5 Nov 8 10:44 /dev/video5
crw-rw 1 root video 81, 6 Nov 8 10:44 /dev/video6
Have the device nodes have been created manually ?
No, automatically created by udev.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
#include media/tvp5150.h
#define TVP5150_I2C_ADDR 0x5C
static struct i2c_board_info cobra3530p73_i2c2_sensor_info[] = {
{
I2C_BOARD_INFO(tvp5150, TVP5150_I2C_ADDR),
},
};
static struct isp_subdev_i2c_board_info tvp5150_camera_subdevs[] = {
{
.board_info = cobra3530p73_i2c2_sensor_info,
.i2c_adapter_id = 2,
},
{ NULL, 0, },
};
static struct isp_v4l2_subdevs_group cobra3530p73_camera_subdevs[] = {
{
.subdevs = tvp5150_camera_subdevs,
.interface = ISP_INTERFACE_PARALLEL,
.bus = {
.parallel = {
.data_lane_shift = 0,
.clk_pol = 0,
.bt656 = 1,
}
},
},
{ },
};
static struct isp_platform_data cobra3530p73_isp_platform_data
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 06:35, Gary Thomas wrote: On 2012-01-19 06:28, Laurent Pinchart wrote: Hi Gary, On Thursday 19 January 2012 14:13:53 Gary Thomas wrote: On 2012-01-19 05:50, Laurent Pinchart wrote: On Thursday 19 January 2012 13:41:57 Gary Thomas wrote: On 2012-01-17 08:33, Laurent Pinchart wrote: snip I already had a couple of YUV support patches in my OMAP3 ISP tree at git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and pushed them to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-yuv. Could you please try them, and see if they're usable with your sensor ? I just tried this kernel with my board. The media control infrastructure comes up and all of the devices are created, but I can't access them. From the bootup log: Linux media interface: v0.10 Linux video capture interface: v2.00 Any message from the omap3isp driver and from the sensor driver ? No, it doesn't appear that the sensor was probed (or maybe it failed but no messages). I'll check into this. Is the omap3-isp driver compiled as a module ? If so, make sure iommu2.ko is loaded first. 'rmmod omap3-isp modprobe iommu2 modprobe omap3-isp' is a quick way to test it. I have everything compiled in - no modules. My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0].i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( I'm going to see if I can't figure out where the ENXIO is coming from... Has the way of adding the sensors on the i2c bus changed? I have my TVP5150 on a i2c-2 all by itself and with the 3.0+ kernel, it was being added when I initialized the camera subsystem. Do you have an example driver (like the BeagleBoard one that was in your omap3isp-sensors-next branch previously)? When I try to access the devices: root@cobra3530p73:~# media-ctl -p Opening media device /dev/media0 media_open_debug: Can't open media device /dev/media0 Failed to open /dev/media0 Could you please strace that ? Attached. Looks like it blows up immediately. Note: my media-ctl program was built from SRCREV 7266b1b5433b5644a06f05edf61c36864ab11683 The devices look OK to me: root@cobra3530p73:~# ls -l /dev/v* /dev/med* crw--- 1 root root 252, 0 Nov 8 10:44 /dev/media0 crw-rw 1 root video 81, 7 Nov 8 10:44 /dev/v4l-subdev0 crw-rw 1 root video 81, 8 Nov 8 10:44 /dev/v4l-subdev1 crw-rw 1 root video 81, 9 Nov 8 10:44 /dev/v4l-subdev2 crw-rw 1 root video 81, 10 Nov 8 10:44 /dev/v4l-subdev3 crw-rw 1 root video 81, 11 Nov 8 10:44 /dev/v4l-subdev4 crw-rw 1 root video 81, 12 Nov 8 10:44 /dev/v4l-subdev5 crw-rw 1 root video 81, 13 Nov 8 10:44 /dev/v4l-subdev6 crw-rw 1 root video 81, 14 Nov 8 10:44 /dev/v4l-subdev7 crw-rw 1 root video 81, 15 Nov 8 10:44 /dev/v4l-subdev8 crw-rw 1 root tty 7, 0 Nov 8 10:44 /dev/vcs crw-rw 1 root tty 7, 1 Nov 8 10:44 /dev/vcs1 crw-rw 1 root tty 7, 128 Nov 8 10:44 /dev/vcsa crw-rw 1 root tty 7, 129 Nov 8 10:44 /dev/vcsa1 crw-rw 1 root video 81, 0 Nov 8 10:44 /dev/video0 crw-rw 1 root video 81, 1 Nov 8 10:44 /dev/video1 crw-rw 1 root video 81, 2 Nov 8 10:44 /dev/video2 crw-rw 1 root video 81, 3 Nov 8 10:44 /dev/video3 crw-rw 1 root video 81, 4 Nov 8 10:44 /dev/video4 crw-rw 1 root video 81, 5 Nov 8 10:44 /dev/video5 crw-rw 1 root video 81, 6 Nov 8 10:44 /dev/video6 Have the device nodes have been created manually ? No, automatically created by udev. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 07:11, Javier Martinez Canillas wrote: On Thu, Jan 19, 2012 at 2:35 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:28, Laurent Pinchart wrote: Hi Gary, On Thursday 19 January 2012 14:13:53 Gary Thomas wrote: On 2012-01-19 05:50, Laurent Pinchart wrote: On Thursday 19 January 2012 13:41:57 Gary Thomas wrote: On 2012-01-17 08:33, Laurent Pinchart wrote: snip I already had a couple of YUV support patches in my OMAP3 ISP tree at git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and pushed them to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-yuv. Could you please try them, and see if they're usable with your sensor ? I just tried this kernel with my board. The media control infrastructure comes up and all of the devices are created, but I can't access them. From the bootup log: Linux media interface: v0.10 Linux video capture interface: v2.00 Any message from the omap3isp driver and from the sensor driver ? No, it doesn't appear that the sensor was probed (or maybe it failed but no messages). I'll check into this. Is the omap3-isp driver compiled as a module ? If so, make sure iommu2.ko is loaded first. 'rmmod omap3-ispmodprobe iommu2modprobe omap3-isp' is a quick way to test it. I have everything compiled in - no modules. At least for me, it only worked when compiled both the omap3-isp and tvp5150 drivers as a module. If I compile them built-in, it fails. Can you share your board/sensor init code from your board-init.c so I can see how to manage this as a module? n.b. I really don't like messing with modules - it used to work fine, so IMO it should continue to do so. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 10:08, Gary Thomas wrote: On 2012-01-19 07:36, Gary Thomas wrote: On 2012-01-19 07:11, Javier Martinez Canillas wrote: On Thu, Jan 19, 2012 at 2:35 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:28, Laurent Pinchart wrote: Hi Gary, On Thursday 19 January 2012 14:13:53 Gary Thomas wrote: On 2012-01-19 05:50, Laurent Pinchart wrote: On Thursday 19 January 2012 13:41:57 Gary Thomas wrote: On 2012-01-17 08:33, Laurent Pinchart wrote: snip I already had a couple of YUV support patches in my OMAP3 ISP tree at git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and pushed them to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-yuv. Could you please try them, and see if they're usable with your sensor ? I just tried this kernel with my board. The media control infrastructure comes up and all of the devices are created, but I can't access them. From the bootup log: Linux media interface: v0.10 Linux video capture interface: v2.00 Any message from the omap3isp driver and from the sensor driver ? No, it doesn't appear that the sensor was probed (or maybe it failed but no messages). I'll check into this. Is the omap3-isp driver compiled as a module ? If so, make sure iommu2.ko is loaded first. 'rmmod omap3-isp modprobe iommu2 modprobe omap3-isp' is a quick way to test it. I have everything compiled in - no modules. At least for me, it only worked when compiled both the omap3-isp and tvp5150 drivers as a module. If I compile them built-in, it fails. Can you share your board/sensor init code from your board-init.c so I can see how to manage this as a module? n.b. I really don't like messing with modules - it used to work fine, so IMO it should continue to do so. I figured out part of the problem - I had tried to reuse my 3.0 kernel config. Sadly, this left out major chunks, in particular the OMAP3ISP was left out because OMAP_IOVMMU is new. I got this configured and it's starting to initialize, but now it fails during boot: kernel BUG at /local/pinchartl-media/drivers/media/media-entity.c:348 [c02416c4] (media_entity_create_link+0x60/0x138) from [c0251c0c] (isp_probe+0x938/0xba4) [c0251c0c] (isp_probe+0x938/0xba4) from [c01e381c] (platform_drv_probe+0x1c/0x24) [c01e381c] (platform_drv_probe+0x1c/0x24) from [c01e24f4] (driver_probe_device+0xcc/0x1b4) [c01e24f4] (driver_probe_device+0xcc/0x1b4) from [c01e1a0c] (bus_for_each_drv+0x4c/0x8c) [c01e1a0c] (bus_for_each_drv+0x4c/0x8c) from [c01e2750] (device_attach+0x74/0xa0) [c01e2750] (device_attach+0x74/0xa0) from [c01e1838] (bus_probe_device+0x28/0x50) [c01e1838] (bus_probe_device+0x28/0x50) from [c01e07f8] (device_add+0x40c/0x590) [c01e07f8] (device_add+0x40c/0x590) from [c01e3e44] (platform_device_add+0x108/0x168) [c01e3e44] (platform_device_add+0x108/0x168) from [c0457c84] (cobra3530p73_camera_init+0x13c/0x188) [c0457c84] (cobra3530p73_camera_init+0x13c/0x188) from [c0008730] (do_one_initcall+0x94/0x15c) [c0008730] (do_one_initcall+0x94/0x15c) from [c044d21c] (kernel_init+0x78/0x120) [c044d21c] (kernel_init+0x78/0x120) from [c00146c8] (kernel_thread_exit+0x0/0x8) Any ideas what else I might have missed? My kernel config is attached in case that helps. It turns out that drivers/media/video/tvp5150.c is not the most recent one posted - it has no v4l2_subdev support in it at all :-( I copied the one I've been using from my 3.0+ kernel and it now builds. I can run media-ctl and configure the pipeline, etc, but sadly no data is captured at all :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
On 2012-01-19 10:22, Gary Thomas wrote: On 2012-01-19 10:08, Gary Thomas wrote: On 2012-01-19 07:36, Gary Thomas wrote: On 2012-01-19 07:11, Javier Martinez Canillas wrote: On Thu, Jan 19, 2012 at 2:35 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:28, Laurent Pinchart wrote: Hi Gary, On Thursday 19 January 2012 14:13:53 Gary Thomas wrote: On 2012-01-19 05:50, Laurent Pinchart wrote: On Thursday 19 January 2012 13:41:57 Gary Thomas wrote: On 2012-01-17 08:33, Laurent Pinchart wrote: snip I already had a couple of YUV support patches in my OMAP3 ISP tree at git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and pushed them to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-yuv. Could you please try them, and see if they're usable with your sensor ? I just tried this kernel with my board. The media control infrastructure comes up and all of the devices are created, but I can't access them. From the bootup log: Linux media interface: v0.10 Linux video capture interface: v2.00 Any message from the omap3isp driver and from the sensor driver ? No, it doesn't appear that the sensor was probed (or maybe it failed but no messages). I'll check into this. Is the omap3-isp driver compiled as a module ? If so, make sure iommu2.ko is loaded first. 'rmmod omap3-isp modprobe iommu2 modprobe omap3-isp' is a quick way to test it. I have everything compiled in - no modules. At least for me, it only worked when compiled both the omap3-isp and tvp5150 drivers as a module. If I compile them built-in, it fails. Can you share your board/sensor init code from your board-init.c so I can see how to manage this as a module? n.b. I really don't like messing with modules - it used to work fine, so IMO it should continue to do so. I figured out part of the problem - I had tried to reuse my 3.0 kernel config. Sadly, this left out major chunks, in particular the OMAP3ISP was left out because OMAP_IOVMMU is new. I got this configured and it's starting to initialize, but now it fails during boot: kernel BUG at /local/pinchartl-media/drivers/media/media-entity.c:348 [c02416c4] (media_entity_create_link+0x60/0x138) from [c0251c0c] (isp_probe+0x938/0xba4) [c0251c0c] (isp_probe+0x938/0xba4) from [c01e381c] (platform_drv_probe+0x1c/0x24) [c01e381c] (platform_drv_probe+0x1c/0x24) from [c01e24f4] (driver_probe_device+0xcc/0x1b4) [c01e24f4] (driver_probe_device+0xcc/0x1b4) from [c01e1a0c] (bus_for_each_drv+0x4c/0x8c) [c01e1a0c] (bus_for_each_drv+0x4c/0x8c) from [c01e2750] (device_attach+0x74/0xa0) [c01e2750] (device_attach+0x74/0xa0) from [c01e1838] (bus_probe_device+0x28/0x50) [c01e1838] (bus_probe_device+0x28/0x50) from [c01e07f8] (device_add+0x40c/0x590) [c01e07f8] (device_add+0x40c/0x590) from [c01e3e44] (platform_device_add+0x108/0x168) [c01e3e44] (platform_device_add+0x108/0x168) from [c0457c84] (cobra3530p73_camera_init+0x13c/0x188) [c0457c84] (cobra3530p73_camera_init+0x13c/0x188) from [c0008730] (do_one_initcall+0x94/0x15c) [c0008730] (do_one_initcall+0x94/0x15c) from [c044d21c] (kernel_init+0x78/0x120) [c044d21c] (kernel_init+0x78/0x120) from [c00146c8] (kernel_thread_exit+0x0/0x8) Any ideas what else I might have missed? My kernel config is attached in case that helps. It turns out that drivers/media/video/tvp5150.c is not the most recent one posted - it has no v4l2_subdev support in it at all :-( I copied the one I've been using from my 3.0+ kernel and it now builds. I can run media-ctl and configure the pipeline, etc, but sadly no data is captured at all :-( It also looks like none of the BT656 support is in this driver either. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 ISP BT656
I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have bad video, the data is all blown out and barely recognizable. All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour. The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline. Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-( Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board). Any help/ideas gladly accepted. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP BT656
On 2012-01-17 14:50, Gary Thomas wrote: I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have bad video, the data is all blown out and barely recognizable. All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour. Sorry, attribution should be to Laurent Pinchart :-) The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline. Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-( Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board). Any help/ideas gladly accepted. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C and mt9p031 on Overo
On 2011-12-11 13:25, Robert Åkerblom-Andersson wrote: Hi, I trying to get the mt9p031 to work on the Overo board. So far I have it working in the Beagleboard xM, and now I have sort of ported/used the same files to get it to work with Overo. My problem now is that when I probe the camera board (LI-5M03 with an adapter board in between providing extra voltage levels) it seams fine. OMAP3ISP loads without any bigger error but the mt9p031 driver can't find the device, but it does not seam to be a driver problem rather a board problem. I think this since I've been debugging with i2cdetect -y -r 3 to scan the bus for the camera. Most of the times I get nothing, but a couple of times (out of hundreds or more, I used a while loop with i2cdetect and then a sleep 1) it showed up with it's address. I think it happens when I just inserted the board but I'm sure or if I get it into some weird state just adding it. It could be a contact error but I have a felling it is something else I have missed. Some pin configuration or something that stops it from working. Do you have any tips on how to debug further or on what might the my problem? I have tried to lower the i2c speed to 100 KHz but it did not seam to make any difference. I too had problems with this device. I have [yet another] different DM3750 board which uses this sensor, so my experience is not exactly the same as yours on the Overo. However, I found that I had to have a pretty substantial delay (500ms) between the time that the MT9P031 was taken out of reset (I have this on a GPIO pin) and when the I2C bus is scanned for the device (mt9p031_probe called). With the delay, the device is discovered and works great. Without it, the device is never seen on the I2C bus. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap_vout: Fix compile error in 3.1
This patch is against the mainline v3.1 release (c3b92c8) and fixes a compile error when building for OMAP3+DSS+VOUT -- Gary Thomas | Consulting for the MLB Associates |Embedded world From 9c98079cf3a8b82c48139a5c9fc213c88064bb44 Mon Sep 17 00:00:00 2001 From: Gary Thomas g...@mlbassoc.com Date: Thu, 1 Dec 2011 05:47:20 -0700 Subject: [PATCH] omap_vout: Fix compile error Signed-off-by: Gary Thomas g...@mlbassoc.com --- drivers/media/video/omap/omap_vout.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index b3a5ecd..3422da0 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -38,6 +38,7 @@ #include linux/irq.h #include linux/videodev2.h #include linux/dma-mapping.h +#include linux/slab.h #include media/videobuf-dma-contig.h #include media/v4l2-device.h -- 1.7.6.4
Re: [PATCH] omap_vout: Fix compile error in 3.1
On 2011-12-01 12:06, Laurent Pinchart wrote: Hi Gary, On Thursday 01 December 2011 13:51:09 Gary Thomas wrote: This patch is against the mainline v3.1 release (c3b92c8) and fixes a compile error when building for OMAP3+DSS+VOUT Thanks for the patch. Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com In the future, could you please send patches inlined instead of as an attachment ? It makes it easier for developers to review the patches, and they can be picked by automated tools such as patchwork. I highly recommend using git send-email to send patches to mailing lists. Will do, thanks. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-28 05:49, Laurent Pinchart wrote: Hi Gary, On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? (*) to build on v3.1, I had to manually add the mt9p031 driver and fix a compile error in drivers/media/video/omap/omap_vout.c Thanks -- Gary Thomas | Consulting
Re: Using MT9P031 digital sensor
On 2011-11-30 07:30, Laurent Pinchart wrote: Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output
Re: Using MT9P031 digital sensor
On 2011-11-30 07:57, Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output line lenghts must be multiple of 32 bytes. The driver adds padding at end of lines when the output width isn't a multiple of 16 pixels. Any guess which resolution(s) I should change and to what? I
Re: Using MT9P031 digital sensor
On 2011-11-28 04:07, Laurent Pinchart wrote: Hi Gary, On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 Ouch :-( Could you please verify that arch/arm/mach-omap2/board-overo.c includes the following code, and that CONFIG_OMAP_MUX is enabled ? I'm
Re: Using MT9P031 digital sensor
On 2011-11-28 05:49, Laurent Pinchart wrote: Hi Gary, On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? OK, I'll give that a try get back to you. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-24 04:28, Laurent Pinchart wrote: Hi Gary, On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 Ouch :-( Could you please verify that arch/arm/mach-omap2/board-overo.c includes the following code, and that CONFIG_OMAP_MUX is enabled ? I'm not using an Overo board - rather one of our own internal designs. My bad, sorry. I have verified that the pull up/down on those
Re: Using MT9P031 digital sensor
On 2011-11-15 18:26, Laurent Pinchart wrote: Hi Gary, On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 Ouch :-( Could you please verify that arch/arm/mach-omap2/board-overo.c includes the following code, and that CONFIG_OMAP_MUX is enabled ? I'm not using an Overo board - rather one of our own internal designs. My bad, sorry. I have verified that the pull up/down on those pins is disabled. The failure is coming from this code in ispccdc.c static void ccdc_hs_vs_isr(struct
Re: Using MT9P031 digital sensor
On 2011-11-11 07:26, Laurent Pinchart wrote:
Hi Gary,
On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote:
On 2011-11-09 09:18, Laurent Pinchart wrote:
On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote:
On 2011-11-08 17:54, Laurent Pinchart wrote:
On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:
On 2011-11-08 06:06, Laurent Pinchart wrote:
On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:
On 2011-11-08 05:30, Javier Martinez Canillas wrote:
On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:
On 2011-11-04 04:37, Laurent Pinchart wrote:
On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:
I'm trying to use the MT9P031 digital sensor with the Media
Controller Framework. media-ctl tells me that the sensor is set
to capture using SGRBG12 2592x1944
Questions:
* What pixel format in ffmpeg does this correspond to?
I don't know if ffmpeg supports Bayer formats. The corresponding
fourcc in V4L2 is BA12.
ffmpeg doesn't seem to support these formats
If your sensor is hooked up to the OMAP3 ISP, you can then
configure the pipeline to include the preview engine and the
resizer, and capture YUV data
at the resizer output.
I am using the OMAP3 ISP, but it's a bit unclear to me how to set
up the pipeline
Hi Gary,
I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I
can help you.
using media-ctl (I looked for documentation on this tool, but came
up dry - is there any?)
Do you have an example of how to configure this using the OMAP3
ISP?
This is how I configure the pipeline to connect the CCDC with the
Previewer and Resizer:
./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]'
./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer
output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]'
./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]'
./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]'
Hope it helps,
Thanks, I'll give this a try.
I assume that your sensor is probably larger than 752x480 (the
mt9p031 is 2592x1944 raw) and that setting the smaller frame size
enables some scaling and/or cropping in the driver?
The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You
should modify the resolutions in the above commands according to your
sensor. Note that the CCDC crops online line when outputting data to
the preview engine, and that the preview engine crops 18 columsn and
8 lines. You can then scale the image by modifying the resizer
output size.
Thanks. After much trial and error (and some kernel printks to
understand what parameters were failing), I came up with this sequence:
media-ctl -r
media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer
output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12
2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12
2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]'
media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]'
When I tried to grab though, I got this:
# yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
Device /dev/video6 opened.
Device `OMAP3 ISP resizer output' on `media' is a video capture
device. Video format set: YUYV (56595559) 642x483 buffer size 633696
Video format: YUYV (56595559) 642x483 buffer size 633696
8 buffers requested.
length: 633696 offset: 0
Buffer 0 mapped at address 0x4028c000.
length: 633696 offset: 634880
Buffer 1 mapped at address 0x403d.
length: 633696 offset: 1269760
Buffer 2 mapped at address 0x404b3000.
length: 633696 offset: 1904640
Buffer 3 mapped at address 0x4062b000.
length: 633696 offset: 2539520
Buffer 4 mapped at address 0x406d6000.
length: 633696 offset: 3174400
Buffer 5 mapped at address 0x40821000.
length: 633696 offset: 3809280
Buffer 6 mapped at address 0x4097c000.
length: 633696 offset: 160
Buffer 7 mapped at address 0x40adf000.
Unable to handle kernel NULL pointer dereference at virtual address
0018
Ouch :-(
Could you please verify that arch/arm/mach-omap2/board-overo.c includes
the following code, and that CONFIG_OMAP_MUX is enabled ?
I'm not using an Overo board - rather one of our own internal designs.
My bad, sorry.
I have verified that the pull up/down on those pins is disabled.
The failure is coming from this code in ispccdc.c
static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
{
struct isp_pipeline *pipe =
to_isp_pipeline
Re: Using MT9P031 digital sensor
On 2011-11-08 17:54, Laurent Pinchart wrote:
Hi Gary,
On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:
On 2011-11-08 06:06, Laurent Pinchart wrote:
On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:
On 2011-11-08 05:30, Javier Martinez Canillas wrote:
On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:
On 2011-11-04 04:37, Laurent Pinchart wrote:
On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:
I'm trying to use the MT9P031 digital sensor with the Media
Controller Framework. media-ctl tells me that the sensor is set to
capture using SGRBG12 2592x1944
Questions:
* What pixel format in ffmpeg does this correspond to?
I don't know if ffmpeg supports Bayer formats. The corresponding
fourcc in V4L2 is BA12.
ffmpeg doesn't seem to support these formats
If your sensor is hooked up to the OMAP3 ISP, you can then configure
the pipeline to include the preview engine and the resizer, and
capture YUV data
at the resizer output.
I am using the OMAP3 ISP, but it's a bit unclear to me how to set up
the pipeline
Hi Gary,
I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can
help you.
using media-ctl (I looked for documentation on this tool, but came up
dry - is there any?)
Do you have an example of how to configure this using the OMAP3 ISP?
This is how I configure the pipeline to connect the CCDC with the
Previewer and Resizer:
./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]'
./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]'
./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]'
./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]'
Hope it helps,
Thanks, I'll give this a try.
I assume that your sensor is probably larger than 752x480 (the mt9p031
is 2592x1944 raw) and that setting the smaller frame size enables some
scaling and/or cropping in the driver?
The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should
modify the resolutions in the above commands according to your sensor.
Note that the CCDC crops online line when outputting data to the preview
engine, and that the preview engine crops 18 columsn and 8 lines. You
can then scale the image by modifying the resizer output size.
Thanks. After much trial and error (and some kernel printks to
understand what parameters were failing), I came up with this sequence:
media-ctl -r
media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]'
media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]'
When I tried to grab though, I got this:
# yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
Device /dev/video6 opened.
Device `OMAP3 ISP resizer output' on `media' is a video capture device.
Video format set: YUYV (56595559) 642x483 buffer size 633696
Video format: YUYV (56595559) 642x483 buffer size 633696
8 buffers requested.
length: 633696 offset: 0
Buffer 0 mapped at address 0x4028c000.
length: 633696 offset: 634880
Buffer 1 mapped at address 0x403d.
length: 633696 offset: 1269760
Buffer 2 mapped at address 0x404b3000.
length: 633696 offset: 1904640
Buffer 3 mapped at address 0x4062b000.
length: 633696 offset: 2539520
Buffer 4 mapped at address 0x406d6000.
length: 633696 offset: 3174400
Buffer 5 mapped at address 0x40821000.
length: 633696 offset: 3809280
Buffer 6 mapped at address 0x4097c000.
length: 633696 offset: 160
Buffer 7 mapped at address 0x40adf000.
Unable to handle kernel NULL pointer dereference at virtual address
0018
Ouch :-(
Could you please verify that arch/arm/mach-omap2/board-overo.c includes the
following code, and that CONFIG_OMAP_MUX is enabled ?
I'm not using an Overo board - rather one of our own internal designs.
I have verified that the pull up/down on those pins is disabled.
The failure is coming from this code in ispccdc.c
static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
{
struct isp_pipeline *pipe =
to_isp_pipeline(ccdc-video_out.video.entity);
The value of pipe is NULL which leads to the failure.
Questions:
* I assume that getting HS/VS interrupts is correct in this mode?
* Why is the statement not written (as all others are)
struct isp_pipeline *pipe = to_isp_pipeline(ccdc-subdev.entity
Re: Using MT9P031 digital sensor
On 2011-11-09 09:18, Laurent Pinchart wrote:
Hi Gary,
On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote:
On 2011-11-08 17:54, Laurent Pinchart wrote:
On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:
On 2011-11-08 06:06, Laurent Pinchart wrote:
On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:
On 2011-11-08 05:30, Javier Martinez Canillas wrote:
On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:
On 2011-11-04 04:37, Laurent Pinchart wrote:
On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:
I'm trying to use the MT9P031 digital sensor with the Media
Controller Framework. media-ctl tells me that the sensor is set
to capture using SGRBG12 2592x1944
Questions:
* What pixel format in ffmpeg does this correspond to?
I don't know if ffmpeg supports Bayer formats. The corresponding
fourcc in V4L2 is BA12.
ffmpeg doesn't seem to support these formats
If your sensor is hooked up to the OMAP3 ISP, you can then
configure the pipeline to include the preview engine and the
resizer, and capture YUV data
at the resizer output.
I am using the OMAP3 ISP, but it's a bit unclear to me how to set up
the pipeline
Hi Gary,
I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can
help you.
using media-ctl (I looked for documentation on this tool, but came
up dry - is there any?)
Do you have an example of how to configure this using the OMAP3 ISP?
This is how I configure the pipeline to connect the CCDC with the
Previewer and Resizer:
./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]'
./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer
output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]'
./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]'
./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]'
./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]'
Hope it helps,
Thanks, I'll give this a try.
I assume that your sensor is probably larger than 752x480 (the mt9p031
is 2592x1944 raw) and that setting the smaller frame size enables some
scaling and/or cropping in the driver?
The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You
should modify the resolutions in the above commands according to your
sensor. Note that the CCDC crops online line when outputting data to
the preview engine, and that the preview engine crops 18 columsn and 8
lines. You can then scale the image by modifying the resizer output
size.
Thanks. After much trial and error (and some kernel printks to
understand what parameters were failing), I came up with this sequence:
media-ctl -r
media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer
output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]'
media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]'
When I tried to grab though, I got this:
# yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
Device /dev/video6 opened.
Device `OMAP3 ISP resizer output' on `media' is a video capture device.
Video format set: YUYV (56595559) 642x483 buffer size 633696
Video format: YUYV (56595559) 642x483 buffer size 633696
8 buffers requested.
length: 633696 offset: 0
Buffer 0 mapped at address 0x4028c000.
length: 633696 offset: 634880
Buffer 1 mapped at address 0x403d.
length: 633696 offset: 1269760
Buffer 2 mapped at address 0x404b3000.
length: 633696 offset: 1904640
Buffer 3 mapped at address 0x4062b000.
length: 633696 offset: 2539520
Buffer 4 mapped at address 0x406d6000.
length: 633696 offset: 3174400
Buffer 5 mapped at address 0x40821000.
length: 633696 offset: 3809280
Buffer 6 mapped at address 0x4097c000.
length: 633696 offset: 160
Buffer 7 mapped at address 0x40adf000.
Unable to handle kernel NULL pointer dereference at virtual address
0018
Ouch :-(
Could you please verify that arch/arm/mach-omap2/board-overo.c includes
the following code, and that CONFIG_OMAP_MUX is enabled ?
I'm not using an Overo board - rather one of our own internal designs.
My bad, sorry.
I have verified that the pull up/down on those pins is disabled.
The failure is coming from this code in ispccdc.c
static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
{
struct isp_pipeline *pipe =
to_isp_pipeline(ccdc-video_out.video.entity);
The value of pipe is NULL which leads to the failure.
Questions:
* I assume that getting HS/VS interrupts is correct
Re: Using MT9P031 digital sensor
On 2011-11-04 04:37, Laurent Pinchart wrote: Hi Gary, On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? * Can I zoom/crop with this driver using the MCF? If so, how? That depends on what host/bridge you use. The OMAP3 ISP has scaling capabilities (controller by the crop rectangle at the resizer input and the format at the resizer output), others might not. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: Hi Gary, On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-08 06:06, Laurent Pinchart wrote: Hi Gary, On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 pgd = c0004000 [0018] *pgd= Internal error: Oops: 17 [#1] Modules linked in: sdmak lpm_omap3530 dsplinkk cmemk ipv6 CPU: 0Not tainted (3.0.0 #3) PC is at ccdc_hs_vs_isr+0x28/0x40 LR is at 0x0 pc : [c0251ae0]lr : []psr: 6193 sp : c0433e70 ip : fp : 0001 r10: 0001 r9 : c0470524 r8 : 0001 r7 : 0080 r6 : r5 : r4 : cee45b88 r3 : 0004 r2 : r1 : r0 : cee45c28 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8e4d8019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc04322f0) Stack: (0xc0433e70 to 0xc0434000) 3e60: 0004 3e80: 3ea0:
Re: Using MT9P031 digital sensor
On 2011-11-08 06:38, Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: Hi Gary, On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 pgd = c0004000 [0018] *pgd= Internal error: Oops: 17 [#1] Modules linked in: sdmak lpm_omap3530 dsplinkk cmemk ipv6 CPU: 0 Not tainted (3.0.0 #3) PC is at ccdc_hs_vs_isr+0x28/0x40 LR is at 0x0 pc : [c0251ae0] lr : [] psr: 6193 sp : c0433e70 ip : fp : 0001 r10: 0001 r9 : c0470524 r8 : 0001 r7 : 0080 r6 : r5 : r4 : cee45b88 r3 : 0004 r2 : r1 : r0 : cee45c28 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8e4d8019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc04322f0) Stack: (0xc0433e70 to 0xc0434000) 3e60: 0004 3e80: 3ea0: 3ec0:
Re: media0 not showing up on beagleboard-xm
On 2011-11-06 15:26, Chris Whittenburg wrote: Hi Laurent, On Fri, Nov 4, 2011 at 6:49 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Chris, On Tuesday 25 October 2011 04:48:13 Chris Whittenburg wrote: I'm using oe-core to build the 3.0.7+ kernel, which runs fine on my beagleboard-xm. You will need board code to register the OMAP3 ISP platform device that will then be picked by the OMAP3 ISP driver. Example of such board code can be found at http://git.linuxtv.org/pinchartl/media.git/commit/37f505296ccd3fb055e03b2ab15ccf6ad4befb8d I followed your example to add the MT9P031 support, and now I get /dev/media0 and /dev/video0 to 7. I don't have the actual sensor hooked up yet. If I try media-ctl -p, I see lots of Failed to open subdev device node msgs. http://pastebin.com/F1TC9A1n This is with the media-ctl utility from: http://feeds.angstrom-distribution.org/feeds/core/ipk/eglibc/armv7a/base/media-ctl_0.0.1-r0_armv7a.ipk I also tried with the latest from your media-ctl repository, but got the same msgs. Is this an issue with my 3.0.8 kernel not being compatible with current media-ctl utility? Is there some older commit that I should build from? Or maybe it is just a side effect of the sensor not being connected yet. Does your kernel config enable CONFIG_VIDEO_V4L2_SUBDEV_API? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Using MT9P031 digital sensor
I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? * Can I zoom/crop with this driver using the MCF? If so, how? Thanks for any help -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Starting OMAP3 ISP as module
To date, I've only been using the OMAP3 ISP + Media Controller Framework builtin to the kernel. Now I'd like to try it as a set of modules, but I can't seem to get it to fire up. What the module insert/probe sequence should I use? Any other hints? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
On 2011-10-23 13:15, Boris Todorov wrote: On Thu, Oct 20, 2011 at 5:36 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 14:14, schrieb Boris Todorov: On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 08:56, schrieb Boris Todorov: On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) How exactly did you solved your problem? I don't see how XCLK in _remove will help. Pls explain. Sorry, I mean deactive / power off your sensor. Btw I'm feeding TVP with external clock (not from xtal pins) - omap.cam_xclk - tvp.clk_in I mean the cam_xclk. And I'm using kind of hack to get it: isp_probe() + isp_set_xclk(isp, 2700, 1); This is your problem. You should control the clock via board / platform callback from your driver. Example: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html It is important that you set the clock to zero when your driver is not in use. The problem is connected to the use count of the ISP and some initialisation which only happen when the counter change between zero and one. tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call happens when video starts streaming and if tvp is not configured - kernel panic. I use an other sensor and driver and this config the sensor during start stream. And what about the case when TVP is used with OSC on XTAL pins and CLK_IN is not used at all? Then your system will work, as you never call isp_set_xclk. The problem is not the clock, but how the isp driver works. It expects, that the sensor driver disable the cam_xclk, if the sensor is not used. Maybe I don't fully understand what is happening... or isp_set_xclk() use is messing up with ISP On my system I have the same issues as you if I don't set the cam_xclk to zero during stop streaming. I haven't investigate in the real cause for the issue. I only released, that this issue stick together with an always enabled cam_xclk. Regards, Stefan Thanks Stefan. Now I have IRQs and I'm able to get some image from TVP. How did you end up fixing this? I ask only to enlighten the list, not to embarrass you, as others and I have had no troubles making this go from the start. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP with digital sensor
On 2011-10-21 10:34, Laurent Pinchart wrote: Hi Gary, Aarrg, I'm sorry for the very late reply. Your mail splipped through the cracks :-/ (94 mails to go in my inbox, then I'll move to my mailing lists backlog :-)) On Tuesday 11 October 2011 15:42:01 Gary Thomas wrote: Laurent, Do you have an example of how to use a digital sensor, in particular the MT9P031, with the OMAP3 ISP? Yes, you can find sample board code in the omap3isp-sensors-board branch of the git://linuxtv.org/pinchartl/media.git repository. No worries, I just now got my hands on one :-) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
On 2011-10-18 07:33, Boris Todorov wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. Why are you using /dev/video4? The CCDC output is on /dev/video2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
On 2011-10-18 08:28, Boris Todorov wrote: I'm using different board. What board? I would think the architecture of the OMAP3 ISP would not change, based on the board? According media-ctl -p: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [UYVY2X8 720x525] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'tvp5150 3-005c':pad0 [ACTIVE] pad1: Output [UYVY2X8 720x525] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [UYVY2X8 720x524] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] Should be /dev/video4... Could you send your pipeline setup and full output of 'media-ctl -p'? On Tue, Oct 18, 2011 at 5:07 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-18 07:33, Boris Todorov wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. Why are you using /dev/video4? The CCDC output is on /dev/video2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
[SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (4,6)/4086x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 4096x4095] - 'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video7 pad0: Output - 'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video8 pad0: Input - 'OMAP3 ISP resizer':pad1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 16: tvp5150 3-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8 pad0: Output [UYVY2X8 720x525] - 'OMAP3 ISP CCDC':pad0 [ACTIVE] On Tue, Oct 18, 2011 at 5:07 PM, Gary Thomasg...@mlbassoc.comwrote: On 2011-10-18 07:33, Boris Todorov wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. Why are you using /dev/video4? The CCDC output is on /dev/video2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
[ACTIVE] -'OMAP3 ISP resizer':pad0 [] pad2: Output [UYVY2X8 720x524] -'OMAP3 ISP preview':pad0 [] -'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] -'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] -'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] -'OMAP3 ISP preview output':pad0 [] -'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output -'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (4,6)/4086x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 4096x4095] -'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video7 pad0: Output -'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video8 pad0: Input - 'OMAP3 ISP resizer':pad1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 16: tvp5150 3-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8 pad0: Output [UYVY2X8 720x525] -'OMAP3 ISP CCDC':pad0 [ACTIVE] On Tue, Oct 18, 2011 at 5:07 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-18 07:33, Boris Todorov wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. Why are you using /dev/video4? The CCDC output is on /dev/video2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 ISP - interlaced data incorrect
For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Note 2: I think I have explanations for much of the ghosting that has been observed: * Frame to frame tearing results from the fact that the frames are interlaced and the actual data changes from one half of the frame to the other. This would not be observed with traditional media, e.g. film, where nothing can move from one frame to the next because of the speed of shutters. In the purely digital capture case, every pixel has the opportunity to change constantly and to find some that change with the 33ms (NTSC) window (1 frame) is quite probable. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. Note 3: The image viewer found at http://djv.sourceforge.net/ works great for these analyses. Just run 'djv_view' and point at the first image in a sequence :-) n.b. I'm not associated with that project, but I really like it! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP - interlaced data incorrect
On 2011-10-14 17:07, Gary Thomas wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Note 2: I think I have explanations for much of the ghosting that has been observed: * Frame to frame tearing results from the fact that the frames are interlaced and the actual data changes from one half of the frame to the other. This would not be observed with traditional media, e.g. film, where nothing can move from one frame to the next because of the speed of shutters. In the purely digital capture case, every pixel has the opportunity to change constantly and to find some that change with the 33ms (NTSC) window (1 frame) is quite probable. To be clear, moving from film to video, there would be no change of data within a single frame between the two interleaved halves. I'm sure this was even true of old cameras, which were not digital capture devices being used to send interleaved analogue data. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. In the case of ffmpeg capturing raw data, there were no times that the ISP driver wanted a buffer and failed to get one, at least when storing the frames in a RAM disk. If stored to a physical device like MMC card, this might not be true. However, when ffmpeg is used to create an MP4 image, even to RAM disk, nearly 1/2 of the time the ISP goes wanting, which certainly can't be good! I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. Note 3: The image viewer found at http://djv.sourceforge.net/ works great for these analyses. Just run 'djv_view' and point at the first image in a sequence :-) n.b. I'm not associated with that project, but I really like it! -- Gary Thomas | Consulting for the MLB Associates |Embedded world
Re: OMAP3 ISP - interlaced data incorrect
On 2011-10-14 17:43, Enrico wrote: On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomasg...@mlbassoc.com wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Just set the FINV bit (search for it in ispccdc.c), i tested it before and i had the opposite result (from a good looking nemo-swapped-like picture to a bad one). That works great, thanks. Maybe we need another user flag, like fldmode, for this? I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. I've tested it with the dsp and nothing changes, same problems. But i will be happy if proven wrong! I'll play with this a bit more tomorrow. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-13 06:32, Enrico wrote: On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.comwrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Is there any way to prove this by doing the de-interlacing in software? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
is RAW you can manipulate this way. Best regards, -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] omap3isp: add BT656 support
On 2011-10-12 02:07, Enrico wrote: On Wed, Oct 12, 2011 at 12:34 AM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.comwrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout In multimedia/video capture/omap2 video4linux I had it disabled and enabling it gave me an error too, but it's not something that is changed by my patches so it is broken in the -yuv tree. I made a distclean rebuild and i don't have any errors, are you sure you need that include in ispccdc.c? Yes, I started from a 100% clean build + tree. Without that change, I get a compile error. With it, and the TVP patches, I can now grab some video from my camera. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-11 07:20, Gary Thomas wrote:
As a number of us have seen, when using the OMAP3 ISP with a BT-656
sensor, e.g. TVP5150, the results are not 100% correct. Some number
of frames (typically 2) will be correct, followed by another set (3)
which are incorrect and show only partially correct data. Note: I
think the numbers (2 correct, 3 wrong) are not cast in stone and may
be related to some other factors like number of buffers in use, etc.
Anyway, I've observed that in the incorrect frames, 1/2 the data is
correct (even lines?) and the other 1/2 is wrong. One of my customers
pointed out that it looks like the incorrect data is just what was
left in memory during some previous frame. I'd like to prove this
by zeroing the entire frame data memory before the frame is captured.
That way, there won't be stale data from a previous frame, but null
data which should show up strongly when examined. Does anyone in this
group have a suggestion the best way/place to do this?
Final question: given a properly connected TVP5150-CCDC, including
all SYNC signals, could this setup be made to work in RAW, non BT-656
mode? My board at least has all of these signals routed, so it should
just be a matter of configuring the software...
Any ideas on this? My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
diff --git a/arch/arm/mach-omap2/board-cobra3530p60.c
b/arch/arm/mach-omap2/board-cobra3530p60.c
index a8e8f21..5e97838 100644
--- a/arch/arm/mach-omap2/board-cobra3530p60.c
+++ b/arch/arm/mach-omap2/board-cobra3530p60.c
@@ -480,6 +480,6 @@ static struct isp_v4l2_subdevs_group
cobra3530p60_camera_subdevs[] = {
.data_lane_shift = 0,
.clk_pol = 1,
-.bt656 = 1,
+.bt656 = 0,
.fldmode = 1,
}
},
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index f4a66c7..26360ae 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -499,7 +499,7 @@ static const struct i2c_reg_value tvp5150_init_enable[] = {
},{ /* Activates video std autodetection for all standards */
TVP5150_AUTOSW_MSK, 0x0
},{ /* Default format: 0x47. For 4:2:2: 0x40 */
- TVP5150_DATA_RATE_SEL, 0x47
+ TVP5150_DATA_RATE_SEL, 0x40 /*0x47*/
},{
TVP5150_CHROMA_PROC_CTL_1, 0x0c
},{
@@ -993,7 +993,7 @@ static int tvp515x_s_stream(struct v4l2_subdev *subdev, int
enable)
/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
if (enable)
- tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09);
+ tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09+0x04);
else
tvp5150_write(subdev, TVP5150_MISC_CTL, 0x00);
OMAP3 ISP ghosting
As a number of us have seen, when using the OMAP3 ISP with a BT-656 sensor, e.g. TVP5150, the results are not 100% correct. Some number of frames (typically 2) will be correct, followed by another set (3) which are incorrect and show only partially correct data. Note: I think the numbers (2 correct, 3 wrong) are not cast in stone and may be related to some other factors like number of buffers in use, etc. Anyway, I've observed that in the incorrect frames, 1/2 the data is correct (even lines?) and the other 1/2 is wrong. One of my customers pointed out that it looks like the incorrect data is just what was left in memory during some previous frame. I'd like to prove this by zeroing the entire frame data memory before the frame is captured. That way, there won't be stale data from a previous frame, but null data which should show up strongly when examined. Does anyone in this group have a suggestion the best way/place to do this? Final question: given a properly connected TVP5150-CCDC, including all SYNC signals, could this setup be made to work in RAW, non BT-656 mode? My board at least has all of these signals routed, so it should just be a matter of configuring the software... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 ISP with digital sensor
Laurent, Do you have an example of how to use a digital sensor, in particular the MT9P031, with the OMAP3 ISP? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] omap3isp: add BT656 support
On 2011-10-11 09:08, Enrico Butera wrote:
This patch series add support for BT656 to omap3isp. It is based
on patches from Deepthy Ravi and Javier Martinez Canillas.
To be applied on top of omap3isp-omap3isp-yuv branch at:
git.linuxtv.org/pinchartl/media.git
Enrico Butera (2):
omap3isp: ispvideo: export isp_video_mbus_to_pix
omap3isp: ispccdc: configure CCDC registers and add BT656 support
Javier Martinez Canillas (1):
omap3isp: ccdc: Add interlaced field mode to platform data
drivers/media/video/omap3isp/ispccdc.c | 143 ++-
drivers/media/video/omap3isp/ispccdc.h |1 +
drivers/media/video/omap3isp/ispreg.h |1 +
drivers/media/video/omap3isp/ispvideo.c |2 +-
drivers/media/video/omap3isp/ispvideo.h |4 +-
include/media/omap3isp.h|3 +
6 files changed, 129 insertions(+), 25 deletions(-)
Sorry, this just locks up on boot for me, immediately after finding the TVP5150.
I applied your changes to the above tree
commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Wed Aug 31 16:03:53 2011 +0200
However, it does not build for my OMAP3530 without the attached patches.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b5ef362..045bcf8 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -38,6 +38,7 @@
#include linux/irq.h
#include linux/videodev2.h
#include linux/dma-mapping.h
+#include linux/slab.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
@@ -2194,6 +2195,7 @@ static int __init omap_vout_probe(struct platform_device
*pdev)
'%s' Display already enabled\n,
def_display-name);
}
+#if 0 // This code generates compile errors?
/* set the update mode */
if (def_display-caps
OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
@@ -2207,6 +2209,7 @@ static int __init omap_vout_probe(struct platform_device
*pdev)
dssdrv-set_update_mode(def_display,
OMAP_DSS_UPDATE_AUTO);
}
+#endif
}
}
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index fde3268..7d059b6 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -31,6 +31,7 @@
#include linux/dma-mapping.h
#include linux/mm.h
#include linux/sched.h
+#include linux/slab.h
#include media/v4l2-event.h
#include isp.h
Re: [RFC 0/3] omap3isp: add BT656 support
On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] omap3isp: add BT656 support
On 2011-10-11 16:34, Gary Thomas wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. That said, it's not clear the current/final state of them. I don't see any repost after the very long discussion with Laurent. Maybe you could just send that file to me directly? However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
video4linux2 -i /dev/video2 -qscale 1 -f mp4 test1.mp4 I think there are some aspect ratio issues with these but what bothers me the most is how much the captured data tears whenever there is a lot of motion in the video. I figured out how to split your raw video into individual frames. The problems don't look like only interlace issues to me. Take a look at http://www.mlbassoc.com/misc/UYVY_examples/PAL_from_JavierMartinezCanillas/ especially image #9 which shows some very serious ghosting. I see the same behaviour here and it bothers me quite a lot. I do hope that we can figure out what's causing it - we have a number of customers that are wanting to do analogue video capture using the OMAP+TVP5150, so it's pretty important to us. Thanks for your time -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
video captured using my OMAP board and converted to MP4 on the fly by this command: ffmpeg -r 30/1 -pix_fmt uyvy422 -s 720x524 -f video4linux2 -i /dev/video2 -qscale 1 -f mp4 test1.mp4 I think there are some aspect ratio issues with these but what bothers me the most is how much the captured data tears whenever there is a lot of motion in the video. I figured out how to split your raw video into individual frames. The problems don't look like only interlace issues to me. Take a look at http://www.mlbassoc.com/misc/UYVY_examples/PAL_from_JavierMartinezCanillas/ especially image #9 which shows some very serious ghosting. Yes, I don't know if this is because I'm not copying the sub-frame in the correct buffer or another. I see the same behaviour here and it bothers me quite a lot. I do hope that we can figure out what's causing it - we have a number of customers that are wanting to do analogue video capture using the OMAP+TVP5150, so it's pretty important to us. Thanks for your time Yes, we are in the same situation. I did my best to fix this but I couldn't. I minimized the effect with those changes but there still exists. Do we know for sure that these problems are happening in the ISP itself or could they possibly be in the TVP5150? Does anyone have experience with a different analogue encoder? I hope as Enrico says that Laurent, Sakari (who im cc'ing here) or Deepthy that know better the ISP can enter the discussion. So we can all work together to resolve this issue. Best regards, -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
On 2011-10-07 05:02, Javier Martinez Canillas wrote: On Fri, Oct 7, 2011 at 12:36 PM, Enricoebut...@users.berlios.de wrote: On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomasg...@mlbassoc.com wrote: Do we know for sure that these problems are happening in the ISP itself or could they possibly be in the TVP5150? Does anyone have experience with a different analogue encoder? Never tried another encoder, but at this point it's something to look at. I don't think some TI people will say yes the encoder has ghosting artifacts. Enrico I have never tried with an different decoder either. I don't think this is a HW thing. As far as I know the tvp5150 is used in some em28xx devices that is what Mauro said, and he would notice that behaviour. Also, if you try getting 625 lines (for PAL) but disable the line-output-formatter for deinterlacing, i.e: pdata-fldmode = 0; ispccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0); ispccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ispccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0); ispccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); Then you get a frame with the 313 odd lines and 312 even lines correctly. That means that the TVP5151 is generating correctly the interlaced video. Also the ISP is doing correctly the deinterlacing for a some frames. But all the approaches used so far (wait for two VD0 interrupt to change the CCCDC output memory direction), looks more like a hack than a clean solution to me, but maybe is the only way to do it with the ISP. Looking at your sequence of pictures, you can see that image #10 and #11 are pretty good, but #12..14 are all bad, then #15 16 are OK again. In the bad ones, it looks like every other line has been shifted left by some number of pixels. It's hard to tell, but I think the shift is constant when it happens. My guess is that the problem is the ISP driver that before this configuration (TVP5150/1 + ISP) had never been tested with an video decoder that generates interlaced data. Of course, there's the comment in the manual that says it's not supported :-) According to 12.4.4.1, BT656 (ITU) data can only use progressive scan sensors. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
On 2011-10-06 01:51, Javier Martinez Canillas wrote: On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Oct 5, 2011 at 6:28 PM, Enricoebut...@users.berlios.de wrote: Hi all, since we are all interested in this driver (and tvp5150) i'll try to make a summary of the current situation and understand what is needed to finally get it into the main tree instead of having to apply a dozen patches manually. The current status of git repositories/branches is: - main tree: working (i suppose) but no support for bt656 input - pinchartl/media: * omap3isp-omap3isp-next: i think it's in sync with linuxtv master (for the omap3-isp parts) * omap3isp-omap3isp-yuv: like ..next but with some additional format patches Floating patches: - Deepthy: sent patches (against mainline) to add bt656 support Laurent made some comments, i haven't seen a v2 to be applied - Javier: sent patches for tvp5150, currently discussed on linux-media; possible patches/fixes for omap3-isp Hello, Since the patches are not against mainline I can't post for reviewing but can be found in one of our development trees [1]. Comments are highly appreciated. The tree is a 2.6.37 that already contain Deepthy patch. I rebased my changes on top of that to correctly support both BT656 an non-BT656 video data processing. [1]: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.37.y-next Any chance of rebasing these against a more up to date kernel, e.g. 3.2-working with the patches Laurent sent today? I will find some free time slots to resolve the issues called out by Sakari, Hans and Mauro and resend the patch-set for the tvp5151. Also I can send the patches of the modifications I made to the ISP driver. Right now I'm working on top of Deepthy patches. I can either send on top of that patch or rebase to mainline, whatever you think is better for reviewing. Now what can we all do to converge to a final solution? I think this is also blocking the possible development/test of missing features, like the recently-discussed resizer and cropping ones. Enrico Right now I have a working the tvp5151 with the ISP. I can capture ITU-R BT656 video both in PAL-M and NTSC standard. Also, the whole pipeline is configured automatically with the video standard detected by the tvp5151. Also, I'm using the CCDC to crop the frames and only capture the active lines for each standard (576 for PAL and 480 for NTSC) using the CCDC to crop the image. As I told you before video capturing is working for both PAL and NTSC using standard V4L2 application (i.e: gstreamer) but the video still shows some motion artifacts. Capturing YUV frames and looking at them I realized that there does exist a pattern, the sequence 2 frames correct and 3 frames with interlacing effects always repeats. I think I've seen this as well. Could you provide a short video which shows the artefacts? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp status
On 2011-10-06 08:50, Javier Martinez Canillas wrote: On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-06 01:51, Javier Martinez Canillas wrote: On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas martinez.jav...@gmail.comwrote: On Wed, Oct 5, 2011 at 6:28 PM, Enricoebut...@users.berlios.dewrote: Hi all, since we are all interested in this driver (and tvp5150) i'll try to make a summary of the current situation and understand what is needed to finally get it into the main tree instead of having to apply a dozen patches manually. The current status of git repositories/branches is: - main tree: working (i suppose) but no support for bt656 input - pinchartl/media: * omap3isp-omap3isp-next: i think it's in sync with linuxtv master (for the omap3-isp parts) * omap3isp-omap3isp-yuv: like ..next but with some additional format patches Floating patches: - Deepthy: sent patches (against mainline) to add bt656 support Laurent made some comments, i haven't seen a v2 to be applied - Javier: sent patches for tvp5150, currently discussed on linux-media; possible patches/fixes for omap3-isp Hello, Since the patches are not against mainline I can't post for reviewing but can be found in one of our development trees [1]. Comments are highly appreciated. The tree is a 2.6.37 that already contain Deepthy patch. I rebased my changes on top of that to correctly support both BT656 an non-BT656 video data processing. [1]: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.37.y-next Any chance of rebasing these against a more up to date kernel, e.g. 3.2-working with the patches Laurent sent today? Sure, but I won't have time to do it neither today nor tomorrow. But will do it during the weekend. I will find some free time slots to resolve the issues called out by Sakari, Hans and Mauro and resend the patch-set for the tvp5151. Also I can send the patches of the modifications I made to the ISP driver. Right now I'm working on top of Deepthy patches. I can either send on top of that patch or rebase to mainline, whatever you think is better for reviewing. Now what can we all do to converge to a final solution? I think this is also blocking the possible development/test of missing features, like the recently-discussed resizer and cropping ones. Enrico Right now I have a working the tvp5151 with the ISP. I can capture ITU-R BT656 video both in PAL-M and NTSC standard. Also, the whole pipeline is configured automatically with the video standard detected by the tvp5151. Also, I'm using the CCDC to crop the frames and only capture the active lines for each standard (576 for PAL and 480 for NTSC) using the CCDC to crop the image. As I told you before video capturing is working for both PAL and NTSC using standard V4L2 application (i.e: gstreamer) but the video still shows some motion artifacts. Capturing YUV frames and looking at them I realized that there does exist a pattern, the sequence 2 frames correct and 3 frames with interlacing effects always repeats. I think I've seen this as well. Could you provide a short video which shows the artefacts? Yes, I've attached a 16-frame video file. It is a PAL-M video (720x576) in YUV 4:22 data format. Please let me know if it is OK for you. Sorry, I didn't notice the size of the image (13 MB) and got a lot of rejects from your MTAs. I uploaded the file to my personal github account [1]. [1]: https://github.com/martinezjavier/omap3isp_tvp5151/blob/master/pal.yuv Very interesting. What was your source (camera type, etc)? How are you looking (or extracting) individual frames for analysis? I see much the same sort of artefacts as you are. An example is at http://www.mlbassoc.com/misc/untitled.m2t This is a little example I put together using kdenlive. The first segment is the raw video from my camera, imported via USB. The second is roughly the same video captured using my OMAP board and converted to MP4 on the fly by this command: ffmpeg -r 30/1 -pix_fmt uyvy422 -s 720x524 -f video4linux2 -i /dev/video2 -qscale 1 -f mp4 test1.mp4 I think there are some aspect ratio issues with these but what bothers me the most is how much the captured data tears whenever there is a lot of motion in the video. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On 2011-10-01 10:39, Enrico wrote: On Sat, Oct 1, 2011 at 5:55 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). That was already posted on the list [1], there was some discussion but i don't know what's the status/plan to get it into mainline. And, as you can see in [2], don't expect many comments :D [1]: http://www.spinics.net/lists/linux-media/msg37710.html [2]: http://www.spinics.net/lists/linux-media/msg37116.html Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. I think you got it right, i haven't tested it but the output format shouldn't be affected by the video source( if it stays pal/ntsc of course). Maybe you will get only a different active video area so only cropping will be affected. It's not so much the video output [shape], rather that the input source can be selected and there does not seem to be a way to do that currently using the MC framework. I was thinking perhaps to have the driver have 3 different output pads and depending on which one you choose to link up tells the driver how to configure the input. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On 2011-09-30 18:33, Javier Martinez Canillas wrote: Hello, The tvp5150 video decoder is usually used on a video pipeline with several video processing integrated circuits. So the driver has to be migrated to the new media device API to reflect this at the software level. Also the tvp5150 is able to detect what is the video standard at which the device is currently operating, so it makes sense to add video format detection in the driver as well as. This patch-set migrates the tvp5150 driver to the MCF and adds video format detection. What is this patchset relative to? Does it still handle the case of overscan? e.g. I typically capture from an NTSC source using this device at 720x524. Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Have you given any thought as to how the input (composite-A, composite-B or S-Video) could be configured using the MCF? Note: CC list trimmed to only the linux-media list. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] OMAP3EVM: Add support for MT9T111 sensor
On 2011-09-27 07:40, Deepthy Ravi wrote: This patchset -adds support for MT9T111 sensor on omap3evm. Currently the sensor driver supports only VGA resolution. -enables MT9T111 sensor in omap2plus_defconfig. This is dependent on the following patchset http://www.spinics.net/lists/linux-media/msg37270.html which adds YUYV input support for OMAP3ISP. And is applied on top of rc1-for-3.2 of gliakhovetski/v4l-dvb.git Why not use the same base as Lennart? The set is based on http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-omap3isp-next --- Changes in v2: As per the discussion here, https://lkml.org/lkml/2011/9/20/280 the existing mt9t112 driver is reused for adding support for mt9t111 sensor. Deepthy Ravi (3): [media] v4l: Add support for mt9t111 sensor driver ispccdc: Configure CCDC_SYN_MODE register omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers Vaibhav Hiremath (2): omap3evm: Enable regulators for camera interface omap3evm: Add Camera board init/hookup file arch/arm/configs/omap2plus_defconfig|9 + arch/arm/mach-omap2/Makefile|5 + arch/arm/mach-omap2/board-omap3evm-camera.c | 185 arch/arm/mach-omap2/board-omap3evm.c| 26 + drivers/media/video/Kconfig |7 + drivers/media/video/Makefile|1 + drivers/media/video/mt9t111_reg.h | 1367 +++ drivers/media/video/mt9t112.c | 320 ++- drivers/media/video/omap3isp/ispccdc.c | 11 +- include/media/mt9t111.h | 45 + 10 files changed, 1937 insertions(+), 39 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c create mode 100644 drivers/media/video/mt9t111_reg.h create mode 100644 include/media/mt9t111.h -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
On 2011-09-27 16:31, Mauro Carvalho Chehab wrote: Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu: -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, September 16, 2011 6:36 PM To: Ravi, Deepthy Cc: linux-media@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de; Hiremath, Vaibhav Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl Hi Deepthy, On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: From: Vaibhav Hiremathhvaib...@ti.com In order to support TVP5146 (for that matter any video decoder), it is important to support G/S/ENUM_STD ioctl on /dev/videoX device node. Why so ? Shouldn't it be queried on the subdev output pad directly ? Because standard v4l2 application for analog devices will call these std ioctls on the streaming device node. So it's done on /dev/video to make the existing apllication work. Existing applications can't work with the OMAP3 ISP (and similar complex embedded devices) without userspace support anyway, either in the form of a GStreamer element or a libv4l plugin. I still believe that analog video standard operations should be added to the subdev pad operations and exposed through subdev device nodes, exactly as done with formats. [Hiremath, Vaibhav] Laurent, I completely agree with your point that, existing application will not work without setting links properly. But I believe the assumption here is, media-controller should set the links (along with pad formants) and all existing application should work as is. Isn't it? Yes. The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming... Yes. I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node. Agreed. Standards selection should be done at device node, just like any other device. So how do you handle a part like the TVP5150 that is standard agnostic? That device can sense the standard from the input signal and sets the result appropriately. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and UYVY422
On 2011-09-08 07:22, Enrico wrote: On Wed, Sep 7, 2011 at 5:55 PM, Gary Thomasg...@mlbassoc.com wrote: My UYVY422 data looks like this (raw-3.0): 000: 0080 0080 007f 0080 007f 0080 007f 0080 010: 0080 0080 0080 0080 0080 0080 0080 0080 020: 0080 0080 0080 0080 007f 0080 0080 0080 030: 0080 007f 0080 007f 0080 007f 0080 007f It should look more like this (raw-2.6.32): 000: 8034 8033 8034 8034 8034 8034 8034 8034 .4.3.4.4.4.4.4.4 010: 8034 8033 8034 8034 8034 8034 8034 8033 .4.3.4.4.4.4.4.3 020: 8034 8034 8034 8034 8034 8034 8033 8032 .4.4.4.4.4.4.3.2 030: 8034 8035 8033 8034 8033 8034 8033 8034 .4.5.3.4.3.4.3.4 n.b. these are grabbed from the same image on the camera, on the same board - either running the new media controller code (3.0+) or old TI PSP code (2.6.32) I've compared the CCDC registers between the two systems and they look pretty good to me (none of the differences explain the behaviour above) It looks to me like the 8 bit data coming into the CCDC is not being packed properly, as well as the second byte of each pair is being dropped. Any hints on where to look, what might be mis-configured, etc? Apart from that (i have the same issue) do you get the full 720 horizontal pixels? Because this is what i get: http://imageshack.us/f/215/newkernel0.png/ It's not simply stretched, the right part is missing. Did you change some ccdc parameters in the files i sent you? This is precisely what I see. If you look at the raw UYVY data as I did, you'll see that 1/2 of the data is being lost. It looks like there is some setup wrong in how the data is being moved from the CCDC to memory but I don't know enough about the code to know where that might be configured. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and UYVY422
On 2011-09-08 07:40, Gary Thomas wrote: On 2011-09-08 07:22, Enrico wrote: On Wed, Sep 7, 2011 at 5:55 PM, Gary Thomasg...@mlbassoc.com wrote: My UYVY422 data looks like this (raw-3.0): 000: 0080 0080 007f 0080 007f 0080 007f 0080 010: 0080 0080 0080 0080 0080 0080 0080 0080 020: 0080 0080 0080 0080 007f 0080 0080 0080 030: 0080 007f 0080 007f 0080 007f 0080 007f It should look more like this (raw-2.6.32): 000: 8034 8033 8034 8034 8034 8034 8034 8034 .4.3.4.4.4.4.4.4 010: 8034 8033 8034 8034 8034 8034 8034 8033 .4.3.4.4.4.4.4.3 020: 8034 8034 8034 8034 8034 8034 8033 8032 .4.4.4.4.4.4.3.2 030: 8034 8035 8033 8034 8033 8034 8033 8034 .4.5.3.4.3.4.3.4 n.b. these are grabbed from the same image on the camera, on the same board - either running the new media controller code (3.0+) or old TI PSP code (2.6.32) I've compared the CCDC registers between the two systems and they look pretty good to me (none of the differences explain the behaviour above) It looks to me like the 8 bit data coming into the CCDC is not being packed properly, as well as the second byte of each pair is being dropped. Any hints on where to look, what might be mis-configured, etc? Apart from that (i have the same issue) do you get the full 720 horizontal pixels? Because this is what i get: http://imageshack.us/f/215/newkernel0.png/ It's not simply stretched, the right part is missing. Did you change some ccdc parameters in the files i sent you? This is precisely what I see. If you look at the raw UYVY data as I did, you'll see that 1/2 of the data is being lost. It looks like there is some setup wrong in how the data is being moved from the CCDC to memory but I don't know enough about the code to know where that might be configured. Note: I just saw a set of patches for exactly this CCDC with BT656 support on the Linux-OMAP mailing list. I'll look at them to see if they are anything different from what Laurent provided. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 ISP and UYVY422
I now have my camera, attached to TVP5150 running in BT656 mode, grabbing data. Sadly, the output is not yet correct. My pipeline is set up as: media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -f 'tvp5150 2-005c:0[UYVY2X8 720x480], OMAP3 ISP CCDC:0[UYVY2X8 720x480], OMAP3 ISP CCDC:1[UYVY2X8 720x480]' Running this command to grab the data: ffmpeg -r 14/1 -pix_fmt uyvy422 -s 720x480 -f video4linux2 -i /dev/video2 -f rawvideo raw-3.0 My UYVY422 data looks like this (raw-3.0): 000: 0080 0080 007f 0080 007f 0080 007f 0080 010: 0080 0080 0080 0080 0080 0080 0080 0080 020: 0080 0080 0080 0080 007f 0080 0080 0080 030: 0080 007f 0080 007f 0080 007f 0080 007f It should look more like this (raw-2.6.32): 000: 8034 8033 8034 8034 8034 8034 8034 8034 .4.3.4.4.4.4.4.4 010: 8034 8033 8034 8034 8034 8034 8034 8033 .4.3.4.4.4.4.4.3 020: 8034 8034 8034 8034 8034 8034 8033 8032 .4.4.4.4.4.4.3.2 030: 8034 8035 8033 8034 8033 8034 8033 8034 .4.5.3.4.3.4.3.4 n.b. these are grabbed from the same image on the camera, on the same board - either running the new media controller code (3.0+) or old TI PSP code (2.6.32) I've compared the CCDC registers between the two systems and they look pretty good to me (none of the differences explain the behaviour above) It looks to me like the 8 bit data coming into the CCDC is not being packed properly, as well as the second byte of each pair is being dropped. Any hints on where to look, what might be mis-configured, etc? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-09-01 03:51, Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: 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 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? 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: () 0x0 buffer size 0 Thanks, Enrico -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-09-01 07:26, Laurent Pinchart wrote: Hi Gary, On Thursday 01 September 2011 14:50:59 Gary Thomas wrote: On 2011-09-01 03:51, Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote: 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 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? 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. To make sure, I just rebuilt 'media-ctl' against my latest kernel (headers). I'm using a OpenEmbedded derivative (Yocto) so this is all automatic. # bitbake virtual/kernel media-ctl -c cleansstate # bitbake virtual/kernel # bitbake media-ctl Sadly, I still get the same error. 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. Probably because of the unknown (above). Here's what the pertinent nodes say: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [UYVY 720x480] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'tvp5150m1 2-005c':pad0 [ACTIVE] pad1: Output [UYVY 720x480] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [UYVY 720x479] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - 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? 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: () 0x0 buffer size 0 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-09-01 12:14, Laurent Pinchart wrote:
Hi Enrico,
On Thursday 01 September 2011 19:24:54 Enrico wrote:
On Thu, Sep 1, 2011 at 6:14 PM, Enricoebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomasg...@mlbassoc.com wrote:
- 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.
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?
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.
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 ?
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)
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-31 05:00, Laurent Pinchart wrote: Hi Gary, On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote: On 2011-08-31 02:13, Laurent Pinchart wrote: On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote: On 2011-08-30 16:50, Laurent Pinchart wrote: On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote: On 2011-08-29 04:49, Laurent Pinchart wrote: 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 # 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. 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 : 0x0402 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? 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. 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. 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 ? :-) 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
Re: Getting started with OMAP3 ISP
On 2011-08-31 09:15, Laurent Pinchart wrote: Hi Gary, On Wednesday 31 August 2011 14:01:07 Gary Thomas wrote: On 2011-08-31 05:00, Laurent Pinchart wrote: On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote: On 2011-08-31 02:13, Laurent Pinchart wrote: On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote: On 2011-08-30 16:50, Laurent Pinchart wrote: On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote: On 2011-08-29 04:49, Laurent Pinchart wrote: 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 # 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. 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 : 0x0402 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? 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. 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. 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 ? :-) 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
Re: Getting started with OMAP3 ISP
On 2011-08-31 10:33, Laurent Pinchart wrote: Hi Enrico, On Wednesday 31 August 2011 18:25:28 Enrico wrote: On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote: 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. 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) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-29 04:49, Laurent Pinchart wrote: Hi Gary, 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 # 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. 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 : 0x0402 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? 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. 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 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-30 08:20, Laurent Pinchart wrote: Hi Gary, On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote: On 2011-08-30 08:08, Gary Thomas wrote: On 2011-08-29 04:49, Laurent Pinchart wrote: 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 # 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. 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 : 0x0402 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? 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. 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 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? 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 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
Re: Getting started with OMAP3 ISP
On 2011-08-30 10:07, Enrico wrote: On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomasg...@mlbassoc.com wrote: 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 Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-30 10:36, Enrico wrote: On Tue, Aug 30, 2011 at 6:23 PM, Gary Thomasg...@mlbassoc.com wrote: 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. Yes, without that setting, the tvp device doesn't register a proper v4l_subdev node. I'm getting the devices created, i.e. they exist in /sys, but just not in /dev. I'll see if I can run a new udev - maybe that will fix it. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-29 04:49, Laurent Pinchart wrote: Hi Gary, 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 # 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. 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 : 0x0402 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? 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. 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. Thanks again -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-08-30 16:50, Laurent Pinchart wrote: Hi Gary, On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote: On 2011-08-29 04:49, Laurent Pinchart wrote: 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 # 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. 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 : 0x0402 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? 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. 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. What pixel format would I use with ffmpeg? What does your subdev deliver ? It's a BT656 encoder - 8-bit UYVY 4:2:2 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. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp and tvp5150 hangs
[ 70.365112] 5e20: c04b8a7c c04b8a48 c04b8a7c bf0f59ac bf0f59ac 0023 001c [ 70.373687] 5e40: c0212c7c c0212c68 c0211c00 c04b8a48 c04b8a7c bf0f59ac [ 70.382263] 5e60: c0211d1c bf0f59ac dec75e78 c0211cbc c0210eb0 df806ef8 df867df0 [ 70.390838] 5e80: bf0f59ac bf0f59ac ded60a40 c04df5e0 c0211520 bf0f32c5 bf0f32ca [ 70.399414] 5ea0: 0033 bf0f59ac bf0f5c38 0001 bf0fb000 001c c0212230 [ 70.408020] 5ec0: bf0f5bf0 bf0f5c38 0001 bf0fb000 001c c0008574 [ 70.416595] 5ee0: bf0fb000 0001 bf0f5bf0 bf0f5bf0 bf0f5c38 0001 ded6cb40 [ 70.425170] 5f00: 0001 c0058728 bf0f5bfc c00082dc c0056534 c0354308 bf0f5d14 00de2320 [ 70.433746] 5f20: ded5d66c e0952000 00021a7a e09695d0 e0969471 e0970fd0 dedc6000 00014d2c [ 70.442321] 5f40: 00016fcc 0021 0022 0016 001a 000f [ 70.450897] 5f60: c044ad1c [ 70.459472] 5f80: 00de2070 0080 c000d6c4 dec74000 [ 70.468048] 5fa0: 00de2168 c000d540 00de2070 400c3000 00021a7a 00de2320 [ 70.476623] 5fc0: 00de2070 0080 00de2070 00de2020 00de2168 [ 70.485198] 5fe0: 00de2320 beb5498c b620 4024d674 6010 400c3000 [ 70.493804] [c0010430] (__bug+0x1c/0x28) from [c027d390] (media_entity_create_link+0x4c/0xfc) [ 70.503173] [c027d390] (media_entity_create_link+0x4c/0xfc) from [bf0e2d04] (isp_probe+0x748/0x954 [omap3_isp]) [ 70.514190] [bf0e2d04] (isp_probe+0x748/0x954 [omap3_isp]) from [c0212c7c] (platform_drv_probe+0x14/0x18) [ 70.524597] [c0212c7c] (platform_drv_probe+0x14/0x18) from [c0211c00] (driver_probe_device+0xc8/0x184) [ 70.534698] [c0211c00] (driver_probe_device+0xc8/0x184) from [c0211d1c] (__driver_attach+0x60/0x84) [ 70.544555] [c0211d1c] (__driver_attach+0x60/0x84) from [c0210eb0] (bus_for_each_dev+0x4c/0x78) [ 70.554046] [c0210eb0] (bus_for_each_dev+0x4c/0x78) from [c0211520] (bus_add_driver+0x98/0x210) [ 70.563537] [c0211520] (bus_add_driver+0x98/0x210) from [c0212230] (driver_register+0xa8/0x12c) [ 70.573028] [c0212230] (driver_register+0xa8/0x12c) from [c0008574] (do_one_initcall+0x90/0x160) [ 70.582641] [c0008574] (do_one_initcall+0x90/0x160) from [c0058728] (sys_init_module+0x15fc/0x17c4) [ 70.592498] [c0058728] (sys_init_module+0x15fc/0x17c4) from [c000d540] (ret_fast_syscall+0x0/0x30) [ 70.602264] Code: e59f0010 e1a01003 eb0cf943 e3a03000 (e5833000) [ 70.608764] ---[ end trace c33463a29bf37706 ]--- If it could be useful i can send the board file where the v4l subdev is registered, but basically i copied it from a working version from the manufacturer repository (kernel 2.6.35). It's not a hardware problem because it works with manufacturer kernel. Thanks, Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 : 0x0402 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? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems configuring OMAP35x ISP driver
Eino-Ville Talvala wrote: Zach, We've gotten a Aptina MT9P031 driver working with the latest ISP patchset, both with YUV and RAW data. I don't know what the problem might be with YUYV data - we get useful YUYV data without any changes to the ISP defaults. However, to request RAW data, that simply uses the CCDC and bypasses all the processing in the ISP, request the pixelformat of V4L2_PIX_FMT_SGRBG10. This will give you two bytes per pixel, at least in our case (although we have a 12-bit sensor cut down to 10 bits), so be prepared to throw out every other byte. Hope this helps, Eino-Ville (Eddy) Talvala Computer Graphics Lab Stanford University I've been working on this same issue, using a Micron MT9T001 sensor, without much success. Could you share your tree and/or patches (against what?)?? This would be most helpful. Thanks On 7/14/2009 9:49 AM, Zach LeRoy wrote: Hello Sergio, I spoke with you earlier about using the ISP and omap34xxcam drivers with a micron mt9d111 SOC sensor. I have since been able to take pictures, but the sensor data is not making it through the ISP data-path correctly. I know the problem is in the ISP data-path because I am configuring the sensor the exact same way as I have been on my working PXA system. I am expecting 4:2:2 packed YUV data, but all of the U and V data is no more than 2 bits where it should be 8. I know the ISP has a lot of capabilities, but all I want to use it for is grabbing 8-bit data from my sensor and putting it in a buffer untouched using the CCDC interface (and of course clocking and timing). What are the key steps to take to get this type of configuration? Other Questions: Is there any processing done on YUV data in the ISP driver by default that I am missing? Has any one else experienced similar problems while adding new sensor support? Any help here would be greatly appreciated. Thank you, Zach LeRoy -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2_int_device vs v4l2_subdev?
Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, June 22, 2009 1:06 PM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-media@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S- video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? I normally use a small test binary I wrote which saves the captured frames to memory, so later I can see them with either IrfanView (when capturing RAW images) or PYUV for seeing the YUV422 images. You should be able to use any standard V4l2 capturing application anyways. Btw, any contribution would be completely welcome. Either on Testing or on development. :) Thanks for your interest in helping. I've built for the Zoom, now I just need to figure out how to capture the data. I'll let you know if I have any questions or problems. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-media@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
