Re: Using MT9P031 digital sensor
On Tuesday 27 March 2012 16:44:50 jean-philippe francois wrote: Le 26 mars 2012 18:32, Gary Thomas g...@mlbassoc.com a écrit : 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. I think you are talking about UYVY/YUYV sensor input to the CDCD which was not working. However, the previewer part is working, ie Bayer input and YUV output. UYVY input is present in one of Laurent's tree. I did not test it. I've updated my tree with the latest code. I unfortunately still don't have the necessary hardware to test it. -- 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
Re: Using MT9P031 digital sensor
Le 26 mars 2012 18:32, Gary Thomas g...@mlbassoc.com a écrit : 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. I think you are talking about UYVY/YUYV sensor input to the CDCD which was not working. However, the previewer part is working, ie Bayer input and YUV output. UYVY input is present in one of Laurent's tree. I did not test it. Jean-Philippe François 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
Re: Using MT9P031 digital sensor
Hi Joshua, On Sunday 25 March 2012 23:13:02 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?? That's strange, I use -w all the time and haven't noticed any segfault. Can you compile yavta with debugging information and provide some context ? 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. The ISP doesn't implement automatic white balance. It can apply white balancing (as well as other related processing), but computing values for those parameters needs to be performed in userspace. The ISP statistics engine engine can help speeding up the process, but the AEWB algorithm must be implemented in your application. -- 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
Re: Using MT9P031 digital sensor
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? Thanks, Josh On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomas g...@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 something that moves data, I can compare how the ISP is setup between the two versions and come up with a
Re: Using MT9P031 digital sensor
Laurent, On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Joshua, On Sunday 25 March 2012 23:13:02 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?? That's strange, I use -w all the time and haven't noticed any segfault. Can you compile yavta with debugging information and provide some context ? Then this must be my problem. I slightly modified yavta to output to stdout for net cat streaming to mplayer on my desktop. I probably didn't get the short options string correct. 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. The ISP doesn't implement automatic white balance. It can apply white balancing (as well as other related processing), but computing values for those parameters needs to be performed in userspace. The ISP statistics engine engine can help speeding up the process, but the AEWB algorithm must be implemented in your application. Dang, I'll have to look up some AEWB algorithms. I'm curious why TI would have this register bit then (AEW_EN bit 15 in H3A_PCR)? Is this the same for auto focus and auto exposure? Meaning that I'll need to get information from the histogram/statistics to adjust focus and exposure times? Thanks, Josh -- 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
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: Using MT9P031 digital sensor
Gary, On Mon, Mar 26, 2012 at 10:32 AM, Gary Thomas g...@mlbassoc.com wrote: 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. I've been able to use UYVY and YUYV with the kernel that I mentioned. So I would assume it should be in since my kernel is an older version of the omap3isp driver 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
Re: Using MT9P031 digital sensor
Hi Joshua, On Monday 26 March 2012 09:44:52 Joshua Hintze wrote: On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart wrote: On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote: [snip] 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. The ISP doesn't implement automatic white balance. It can apply white balancing (as well as other related processing), but computing values for those parameters needs to be performed in userspace. The ISP statistics engine engine can help speeding up the process, but the AEWB algorithm must be implemented in your application. Dang, I'll have to look up some AEWB algorithms. I will publish sample code soon (likely in a couple of weeks, could be a bit before). I'm curious why TI would have this register bit then (AEW_EN bit 15 in H3A_PCR)? That bit enables the AEWB statistics collection, not an AEWB algorithm. Is this the same for auto focus and auto exposure? Meaning that I'll need to get information from the histogram/statistics to adjust focus and exposure times? That's right. -- 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
Re: Using MT9P031 digital sensor
Laurent, On Mon, Mar 26, 2012 at 11:38 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Joshua, On Monday 26 March 2012 09:44:52 Joshua Hintze wrote: On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart wrote: On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote: [snip] Dang, I'll have to look up some AEWB algorithms. I will publish sample code soon (likely in a couple of weeks, could be a bit before). Great! I look forward to it. Thanks, Josh -- 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
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. Thanks, Josh On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintze joshua.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 something that moves data, I can compare how the ISP is setup between the two versions and come up with a fix. This is next on my plate, but it may take a while to figure it out. Is there some recent tree which will have this digital (mt9p031) part working that also has the BT656 support in it? I'd like to try that rather than spending time figuring out why an older tree isn't working. No, I haven't had time to create one, sorry. It shouldn't be difficult to rebase the BT656 patches on top of the latest OMAP3 ISP and MT9P031 code. -- Regards, Laurent Pinchart -- To
Re: Using MT9P031 digital sensor
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 something that moves data, I can compare how the ISP is setup between the two versions and come up with a fix. This is next on my plate, but it may take a while to figure it out. Is there some recent tree which will have this digital (mt9p031) part working that also has the BT656 support in it? I'd like to try that rather than spending time figuring out why an older tree isn't working. No, I haven't had time to create one, sorry. It shouldn't be difficult to rebase the BT656 patches on top of the latest OMAP3 ISP and MT9P031 code. -- 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 -- 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 for
Re: Using MT9P031 digital sensor
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
RE: Using MT9P031 digital sensor
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Wednesday, November 30, 2011 8:01 PM To: Gary Thomas Cc: Javier Martinez Canillas; Linux Media Mailing List Subject: Re: Using MT9P031 digital sensor 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
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
Hi Gary, On Wednesday 30 November 2011 15:57:30 Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: 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
Re: Using MT9P031 digital sensor
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 something that moves data, I can compare how the ISP is setup between the two versions and come up with a fix. This is next on my plate, but it may take a while to figure it out. Is there some recent tree which will have this digital (mt9p031) part working that also has the BT656 support in it? I'd like to try that rather than spending time figuring out why an older tree isn't working. No, I haven't had time to create one, sorry. It shouldn't be difficult to rebase the BT656 patches on top of the latest OMAP3 ISP and MT9P031 code. -- 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
Re: Using MT9P031 digital sensor
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
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
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 ? -- 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
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
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
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
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
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 =
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
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 =
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 in
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 Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas g...@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, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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
Hi Javier, On Tuesday 08 November 2011 13:30:08 Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas g...@mlbassoc.com 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 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: Thanks for the instructions. I would add that you should start with media-ctl -r to reset all links to the disabled state. This will make sure the below link setup commands start with a consistent device state. ./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, -- 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
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
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. -- 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
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: Using MT9P031 digital sensor
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 ?
@@ -497,6 +558,23 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /*
+* Camera
+*
+* The level shifters used on the Caspa camera module have a 4k output
+* impedance. Combined with the 100uA pull-up resistors in the OMAP3,
+* this raises the ground level to 400mV. Adding crosstalk between the
+* pixel clock and the HS/VS signals on the flat cable (a
Re: Using MT9P031 digital sensor
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. 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. * 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. -- 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
