* Re: Using MT9P031 digital sensor
@ 2012-03-23 19:01 Joshua Hintze
2012-03-26 5:13 ` Joshua Hintze
0 siblings, 1 reply; 41+ messages in thread
From: Joshua Hintze @ 2012-03-23 19:01 UTC (permalink / raw)
To: laurent.pinchart, linux-media
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 666624 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-23 19:01 Using MT9P031 digital sensor Joshua Hintze
@ 2012-03-26 5:13 ` Joshua Hintze
2012-03-26 8:25 ` Laurent Pinchart
[not found] ` <4F708A66.8090303@mlbassoc.com>
0 siblings, 2 replies; 41+ messages in thread
From: Joshua Hintze @ 2012-03-26 5:13 UTC (permalink / raw)
To: laurent.pinchart, linux-media
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.hintze@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 666624 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 5:13 ` Joshua Hintze
@ 2012-03-26 8:25 ` Laurent Pinchart
2012-03-26 15:44 ` Joshua Hintze
[not found] ` <4F708A66.8090303@mlbassoc.com>
1 sibling, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2012-03-26 8:25 UTC (permalink / raw)
To: Joshua Hintze; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
[not found] ` <4F708A66.8090303@mlbassoc.com>
@ 2012-03-26 15:37 ` Joshua Hintze
2012-03-26 16:32 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Joshua Hintze @ 2012-03-26 15:37 UTC (permalink / raw)
To: Gary Thomas, linux-media, laurent.pinchart
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 <gary@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 Hintze<joshua.hintze@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 666624 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 8:25 ` Laurent Pinchart
@ 2012-03-26 15:44 ` Joshua Hintze
2012-03-26 17:38 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Joshua Hintze @ 2012-03-26 15:44 UTC (permalink / raw)
To: Laurent Pinchart, linux-media
Laurent,
On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart
<laurent.pinchart@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
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 15:37 ` Joshua Hintze
@ 2012-03-26 16:32 ` Gary Thomas
2012-03-26 16:55 ` Joshua Hintze
2012-03-27 14:44 ` jean-philippe francois
0 siblings, 2 replies; 41+ messages in thread
From: Gary Thomas @ 2012-03-26 16:32 UTC (permalink / raw)
To: Joshua Hintze; +Cc: linux-media, laurent.pinchart
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 Thomas<gary@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 Hintze<joshua.hintze@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 666624 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 majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> --
>> ------------------------------------------------------------
>> Gary Thomas | Consulting for the
>> MLB Associates | Embedded world
>> ------------------------------------------------------------
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 16:32 ` Gary Thomas
@ 2012-03-26 16:55 ` Joshua Hintze
2012-03-27 14:44 ` jean-philippe francois
1 sibling, 0 replies; 41+ messages in thread
From: Joshua Hintze @ 2012-03-26 16:55 UTC (permalink / raw)
To: Gary Thomas; +Cc: linux-media, laurent.pinchart
Gary,
On Mon, Mar 26, 2012 at 10:32 AM, Gary Thomas <gary@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 Thomas<gary@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 Hintze<joshua.hintze@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 666624 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 majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> Gary Thomas | Consulting for the
>>> MLB Associates | Embedded world
>>> ------------------------------------------------------------
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 15:44 ` Joshua Hintze
@ 2012-03-26 17:38 ` Laurent Pinchart
2012-03-26 17:43 ` Joshua Hintze
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2012-03-26 17:38 UTC (permalink / raw)
To: Joshua Hintze; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 17:38 ` Laurent Pinchart
@ 2012-03-26 17:43 ` Joshua Hintze
0 siblings, 0 replies; 41+ messages in thread
From: Joshua Hintze @ 2012-03-26 17:43 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-media
Laurent,
On Mon, Mar 26, 2012 at 11:38 AM, Laurent Pinchart
<laurent.pinchart@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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-26 16:32 ` Gary Thomas
2012-03-26 16:55 ` Joshua Hintze
@ 2012-03-27 14:44 ` jean-philippe francois
2012-03-29 11:33 ` Laurent Pinchart
1 sibling, 1 reply; 41+ messages in thread
From: jean-philippe francois @ 2012-03-27 14:44 UTC (permalink / raw)
To: Gary Thomas; +Cc: Joshua Hintze, linux-media, laurent.pinchart
Le 26 mars 2012 18:32, Gary Thomas <gary@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 Thomas<gary@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 Hintze<joshua.hintze@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 666624 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 majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> Gary Thomas | Consulting for the
>>> MLB Associates | Embedded world
>>> ------------------------------------------------------------
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2012-03-27 14:44 ` jean-philippe francois
@ 2012-03-29 11:33 ` Laurent Pinchart
0 siblings, 0 replies; 41+ messages in thread
From: Laurent Pinchart @ 2012-03-29 11:33 UTC (permalink / raw)
To: jean-philippe francois; +Cc: Gary Thomas, Joshua Hintze, linux-media
On Tuesday 27 March 2012 16:44:50 jean-philippe francois wrote:
> Le 26 mars 2012 18:32, Gary Thomas <gary@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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-30 17:00 ` Gary Thomas
@ 2011-11-30 23:49 ` Laurent Pinchart
0 siblings, 0 replies; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-30 23:49 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 666624 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-30 14:57 ` Gary Thomas
2011-11-30 17:00 ` Gary Thomas
@ 2011-11-30 23:42 ` Laurent Pinchart
1 sibling, 0 replies; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-30 23:42 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 frames are 666624 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?
You don't have to change any resolution. The driver reports the line length
through the bytesperline field in response to G_FMT/TRY_FMT/S_FMT, you can use
the value to find out whether there's padding at the end of lines.
Alternatively, if you want frames with no line padding, you will need to set
the width to a multiple of 16 on the source pad connected to the video node
you capture video from.
> > 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.
>
> >> (*) 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
> >
> > I'm surprised that omap_vout doesn't compile on v3.1. What was the error
> > ?
>
> The old 'kzalloc' isn't defined. I fixed it like this:
>
> $ git diff v3.1 drivers/media/video/omap/omap_vout.c
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c index b3a5ecd..3422da0 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -38,6 +38,7 @@
> #include <linux/irq.h>
> #include <linux/videodev2.h>
> #include <linux/dma-mapping.h>
> +#include <linux/slab.h>
>
> #include <media/videobuf-dma-contig.h>
> #include <media/v4l2-device.h>
Could you submit a patch to the linux-media mailing list (CC'ing Vaibhav) ? I
can do it if that's more convenient for you.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-30 14:57 ` Gary Thomas
@ 2011-11-30 17:00 ` Gary Thomas
2011-11-30 23:49 ` Laurent Pinchart
2011-11-30 23:42 ` Laurent Pinchart
1 sibling, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-30 17:00 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 666624 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/
>
>>
>> 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.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-30 14:30 ` Laurent Pinchart
2011-11-30 14:38 ` Hiremath, Vaibhav
@ 2011-11-30 14:57 ` Gary Thomas
2011-11-30 17:00 ` Gary Thomas
2011-11-30 23:42 ` Laurent Pinchart
1 sibling, 2 replies; 41+ messages in thread
From: Gary Thomas @ 2011-11-30 14:57 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 666624 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?
>
> 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.
>
>> (*) 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
>
> I'm surprised that omap_vout doesn't compile on v3.1. What was the error ?
The old 'kzalloc' isn't defined. I fixed it like this:
$ git diff v3.1 drivers/media/video/omap/omap_vout.c
diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
index b3a5ecd..3422da0 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -38,6 +38,7 @@
#include <linux/irq.h>
#include <linux/videodev2.h>
#include <linux/dma-mapping.h>
+#include <linux/slab.h>
#include <media/videobuf-dma-contig.h>
#include <media/v4l2-device.h>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply related [flat|nested] 41+ messages in thread
* RE: Using MT9P031 digital sensor
2011-11-30 14:30 ` Laurent Pinchart
@ 2011-11-30 14:38 ` Hiremath, Vaibhav
2011-11-30 14:57 ` Gary Thomas
1 sibling, 0 replies; 41+ messages in thread
From: Hiremath, Vaibhav @ 2011-11-30 14:38 UTC (permalink / raw)
To: Laurent Pinchart, Gary Thomas
Cc: Javier Martinez Canillas, Linux Media Mailing List
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@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 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 666624 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.
>
> So this means that your original problem comes from the BT656 patches.
>
> > (*) 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
>
> I'm surprised that omap_vout doesn't compile on v3.1. What was the error ?
>
Do you have below patch in your kernel baseline -
commit 5ebbf72dc51bd3b481aa91fea37a7157da5fc548
Author: archit taneja <archit@ti.com>
Date: Fri Aug 5 04:19:21 2011 -0300
[media] OMAP_VOUT: Fix build break caused by update_mode removal in DSS2
Thanks,
Vaibhav
> --
> Regards,
>
> Laurent Pinchart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-30 14:13 ` Gary Thomas
@ 2011-11-30 14:30 ` Laurent Pinchart
2011-11-30 14:38 ` Hiremath, Vaibhav
2011-11-30 14:57 ` Gary Thomas
0 siblings, 2 replies; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-30 14:30 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 666624 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.
So this means that your original problem comes from the BT656 patches.
> (*) 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
I'm surprised that omap_vout doesn't compile on v3.1. What was the error ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-28 12:49 ` Laurent Pinchart
2011-11-28 12:53 ` Gary Thomas
@ 2011-11-30 14:13 ` Gary Thomas
2011-11-30 14:30 ` Laurent Pinchart
1 sibling, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-30 14:13 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 666624 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 the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-28 12:49 ` Laurent Pinchart
@ 2011-11-28 12:53 ` Gary Thomas
2011-11-30 14:13 ` Gary Thomas
1 sibling, 0 replies; 41+ messages in thread
From: Gary Thomas @ 2011-11-28 12:53 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-28 12:42 ` Gary Thomas
@ 2011-11-28 12:49 ` Laurent Pinchart
2011-11-28 12:53 ` Gary Thomas
2011-11-30 14:13 ` Gary Thomas
0 siblings, 2 replies; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-28 12:49 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-28 11:07 ` Laurent Pinchart
@ 2011-11-28 12:42 ` Gary Thomas
2011-11-28 12:49 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-28 12:42 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>>>>>>>>>>>> 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: 4444160
>>>>>>>>>>>> Buffer 7 mapped at address 0x40adf000.
>>>>>>>>>>>>
>>>>>>>>>>>> Unable to handle kernel NULL pointer dereference at virtual
>>>>>>>>>>>> address 00000018
>>>>>>>>>>>
>>>>>>>>>>> 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 this mode?
>>>>>>>>>> * Why is the statement not written (as all others are)
>>>>>>>>>>
>>>>>>>>>> struct isp_pipeline *pipe =
>>>>>>>>>> to_isp_pipeline(&ccdc->subdev.entity);
>>>>>>>>>>
>>>>>>>>>> I tried this change and the kernel doesn't crash.
>>>>>>>>>>
>>>>>>>>>> I've found that I can get raw frames out of CCDC, but I don't get
>>>>>>>>>> anything at all when the output continues through the preview
>>>>>>>>>> and/or resize nodes.
>>>>>>>>>>
>>>>>>>>>> Ideas?
>>>>>>>>>
>>>>>>>>> I'm really puzzled, this should have been caught much earlier :-)
>>>>>>>>>
>>>>>>>>> Your analysis makes sense. Would you like to submit a patch
>>>>>>>>> yourself ? If not I can do it.
>>>>>>>>
>>>>>>>> Sure, I can submit a patch. I would like to figure out why it's not
>>>>>>>> working first.
>>>>>>>
>>>>>>> Oops, I've overlooked that, sorry.
>>>>>>>
>>>>>>>> Any ideas how I can debug this? I can't seem to get anything past
>>>>>>>> the CCDC, e.g. into the preview or resize units. Is there some way
>>>>>>>> to trace packets/data through the various stages? Any ideas what
>>>>>>>> might cause it to stall?
>>>>>>>
>>>>>>> How have you configured your pipeline ? Can you try tracing the
>>>>>>> preview engine and/or resizer interrupts ?
>>>>>>
>>>>>> 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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-25 11:50 ` Gary Thomas
@ 2011-11-28 11:07 ` Laurent Pinchart
2011-11-28 12:42 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-28 11:07 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> >>>>>>>>>> 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: 4444160
> >>>>>>>>>> Buffer 7 mapped at address 0x40adf000.
> >>>>>>>>>>
> >>>>>>>>>> Unable to handle kernel NULL pointer dereference at virtual
> >>>>>>>>>> address 00000018
> >>>>>>>>>
> >>>>>>>>> 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 this mode?
> >>>>>>>> * Why is the statement not written (as all others are)
> >>>>>>>>
> >>>>>>>> struct isp_pipeline *pipe =
> >>>>>>>> to_isp_pipeline(&ccdc->subdev.entity);
> >>>>>>>>
> >>>>>>>> I tried this change and the kernel doesn't crash.
> >>>>>>>>
> >>>>>>>> I've found that I can get raw frames out of CCDC, but I don't get
> >>>>>>>> anything at all when the output continues through the preview
> >>>>>>>> and/or resize nodes.
> >>>>>>>>
> >>>>>>>> Ideas?
> >>>>>>>
> >>>>>>> I'm really puzzled, this should have been caught much earlier :-)
> >>>>>>>
> >>>>>>> Your analysis makes sense. Would you like to submit a patch
> >>>>>>> yourself ? If not I can do it.
> >>>>>>
> >>>>>> Sure, I can submit a patch. I would like to figure out why it's not
> >>>>>> working first.
> >>>>>
> >>>>> Oops, I've overlooked that, sorry.
> >>>>>
> >>>>>> Any ideas how I can debug this? I can't seem to get anything past
> >>>>>> the CCDC, e.g. into the preview or resize units. Is there some way
> >>>>>> to trace packets/data through the various stages? Any ideas what
> >>>>>> might cause it to stall?
> >>>>>
> >>>>> How have you configured your pipeline ? Can you try tracing the
> >>>>> preview engine and/or resizer interrupts ?
> >>>>
> >>>> 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-24 11:28 ` Laurent Pinchart
@ 2011-11-25 11:50 ` Gary Thomas
2011-11-28 11:07 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-25 11:50 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>>>>>>>>>> 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: 4444160
>>>>>>>>>> Buffer 7 mapped at address 0x40adf000.
>>>>>>>>>>
>>>>>>>>>> Unable to handle kernel NULL pointer dereference at virtual
>>>>>>>>>> address 00000018
>>>>>>>>>
>>>>>>>>> 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 this mode?
>>>>>>>> * Why is the statement not written (as all others are)
>>>>>>>>
>>>>>>>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
>>>>>>>>
>>>>>>>> I tried this change and the kernel doesn't crash.
>>>>>>>>
>>>>>>>> I've found that I can get raw frames out of CCDC, but I don't get
>>>>>>>> anything at all when the output continues through the preview and/or
>>>>>>>> resize nodes.
>>>>>>>>
>>>>>>>> Ideas?
>>>>>>>
>>>>>>> I'm really puzzled, this should have been caught much earlier :-)
>>>>>>>
>>>>>>> Your analysis makes sense. Would you like to submit a patch yourself
>>>>>>> ? If not I can do it.
>>>>>>
>>>>>> Sure, I can submit a patch. I would like to figure out why it's not
>>>>>> working first.
>>>>>
>>>>> Oops, I've overlooked that, sorry.
>>>>>
>>>>>> Any ideas how I can debug this? I can't seem to get anything past the
>>>>>> CCDC, e.g. into the preview or resize units. Is there some way to
>>>>>> trace packets/data through the various stages? Any ideas what might
>>>>>> cause it to stall?
>>>>>
>>>>> How have you configured your pipeline ? Can you try tracing the preview
>>>>> engine and/or resizer interrupts ?
>>>>
>>>> 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)
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-16 12:03 ` Gary Thomas
@ 2011-11-24 11:28 ` Laurent Pinchart
2011-11-25 11:50 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-24 11:28 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> >>>>>>>> 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: 4444160
> >>>>>>>> Buffer 7 mapped at address 0x40adf000.
> >>>>>>>>
> >>>>>>>> Unable to handle kernel NULL pointer dereference at virtual
> >>>>>>>> address 00000018
> >>>>>>>
> >>>>>>> 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 this mode?
> >>>>>> * Why is the statement not written (as all others are)
> >>>>>>
> >>>>>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
> >>>>>>
> >>>>>> I tried this change and the kernel doesn't crash.
> >>>>>>
> >>>>>> I've found that I can get raw frames out of CCDC, but I don't get
> >>>>>> anything at all when the output continues through the preview and/or
> >>>>>> resize nodes.
> >>>>>>
> >>>>>> Ideas?
> >>>>>
> >>>>> I'm really puzzled, this should have been caught much earlier :-)
> >>>>>
> >>>>> Your analysis makes sense. Would you like to submit a patch yourself
> >>>>> ? If not I can do it.
> >>>>
> >>>> Sure, I can submit a patch. I would like to figure out why it's not
> >>>> working first.
> >>>
> >>> Oops, I've overlooked that, sorry.
> >>>
> >>>> Any ideas how I can debug this? I can't seem to get anything past the
> >>>> CCDC, e.g. into the preview or resize units. Is there some way to
> >>>> trace packets/data through the various stages? Any ideas what might
> >>>> cause it to stall?
> >>>
> >>> How have you configured your pipeline ? Can you try tracing the preview
> >>> engine and/or resizer interrupts ?
> >>
> >> 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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-16 1:26 ` Laurent Pinchart
@ 2011-11-16 12:03 ` Gary Thomas
2011-11-24 11:28 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-16 12:03 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>>>>>>>> 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: 4444160
>>>>>>>> Buffer 7 mapped at address 0x40adf000.
>>>>>>>>
>>>>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>>>>> 00000018
>>>>>>>
>>>>>>> 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 this mode?
>>>>>> * Why is the statement not written (as all others are)
>>>>>>
>>>>>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
>>>>>>
>>>>>> I tried this change and the kernel doesn't crash.
>>>>>>
>>>>>> I've found that I can get raw frames out of CCDC, but I don't get
>>>>>> anything at all when the output continues through the preview and/or
>>>>>> resize nodes.
>>>>>>
>>>>>> Ideas?
>>>>>
>>>>> I'm really puzzled, this should have been caught much earlier :-)
>>>>>
>>>>> Your analysis makes sense. Would you like to submit a patch yourself ?
>>>>> If not I can do it.
>>>>
>>>> Sure, I can submit a patch. I would like to figure out why it's not
>>>> working first.
>>>
>>> Oops, I've overlooked that, sorry.
>>>
>>>> Any ideas how I can debug this? I can't seem to get anything past the
>>>> CCDC, e.g. into the preview or resize units. Is there some way to trace
>>>> packets/data through the various stages? Any ideas what might cause it
>>>> to stall?
>>>
>>> How have you configured your pipeline ? Can you try tracing the preview
>>> engine and/or resizer interrupts ?
>>
>> 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?
Thanks for your time
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-14 11:42 ` Gary Thomas
@ 2011-11-16 1:26 ` Laurent Pinchart
2011-11-16 12:03 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-16 1:26 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> >>>>>> 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: 4444160
> >>>>>> Buffer 7 mapped at address 0x40adf000.
> >>>>>>
> >>>>>> Unable to handle kernel NULL pointer dereference at virtual address
> >>>>>> 00000018
> >>>>>
> >>>>> 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 this mode?
> >>>> * Why is the statement not written (as all others are)
> >>>>
> >>>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
> >>>>
> >>>> I tried this change and the kernel doesn't crash.
> >>>>
> >>>> I've found that I can get raw frames out of CCDC, but I don't get
> >>>> anything at all when the output continues through the preview and/or
> >>>> resize nodes.
> >>>>
> >>>> Ideas?
> >>>
> >>> I'm really puzzled, this should have been caught much earlier :-)
> >>>
> >>> Your analysis makes sense. Would you like to submit a patch yourself ?
> >>> If not I can do it.
> >>
> >> Sure, I can submit a patch. I would like to figure out why it's not
> >> working first.
> >
> > Oops, I've overlooked that, sorry.
> >
> >> Any ideas how I can debug this? I can't seem to get anything past the
> >> CCDC, e.g. into the preview or resize units. Is there some way to trace
> >> packets/data through the various stages? Any ideas what might cause it
> >> to stall?
> >
> > How have you configured your pipeline ? Can you try tracing the preview
> > engine and/or resizer interrupts ?
>
> 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-11 14:26 ` Laurent Pinchart
@ 2011-11-14 11:42 ` Gary Thomas
2011-11-16 1:26 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-14 11:42 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>>>>>> 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: 4444160
>>>>>> Buffer 7 mapped at address 0x40adf000.
>>>>>>
>>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>>> 00000018
>>>>>
>>>>> 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 this mode?
>>>> * Why is the statement not written (as all others are)
>>>>
>>>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
>>>>
>>>> I tried this change and the kernel doesn't crash.
>>>>
>>>> I've found that I can get raw frames out of CCDC, but I don't get
>>>> anything at all when the output continues through the preview and/or
>>>> resize nodes.
>>>>
>>>> Ideas?
>>>
>>> I'm really puzzled, this should have been caught much earlier :-)
>>>
>>> Your analysis makes sense. Would you like to submit a patch yourself ? If
>>> not I can do it.
>>
>> Sure, I can submit a patch. I would like to figure out why it's not working
>> first.
>
> Oops, I've overlooked that, sorry.
>
>> Any ideas how I can debug this? I can't seem to get anything past the CCDC,
>> e.g. into the preview or resize units. Is there some way to trace
>> packets/data through the various stages? Any ideas what might cause it to
>> stall?
>
> How have you configured your pipeline ? Can you try tracing the preview engine
> and/or resizer interrupts ?
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?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-09 16:24 ` Gary Thomas
@ 2011-11-11 14:26 ` Laurent Pinchart
2011-11-14 11:42 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-11 14:26 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> >>>> 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: 4444160
> >>>> Buffer 7 mapped at address 0x40adf000.
> >>>>
> >>>> Unable to handle kernel NULL pointer dereference at virtual address
> >>>> 00000018
> >>>
> >>> 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 this mode?
> >> * Why is the statement not written (as all others are)
> >>
> >> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
> >>
> >> I tried this change and the kernel doesn't crash.
> >>
> >> I've found that I can get raw frames out of CCDC, but I don't get
> >> anything at all when the output continues through the preview and/or
> >> resize nodes.
> >>
> >> Ideas?
> >
> > I'm really puzzled, this should have been caught much earlier :-)
> >
> > Your analysis makes sense. Would you like to submit a patch yourself ? If
> > not I can do it.
>
> Sure, I can submit a patch. I would like to figure out why it's not working
> first.
Oops, I've overlooked that, sorry.
> Any ideas how I can debug this? I can't seem to get anything past the CCDC,
> e.g. into the preview or resize units. Is there some way to trace
> packets/data through the various stages? Any ideas what might cause it to
> stall?
How have you configured your pipeline ? Can you try tracing the preview engine
and/or resizer interrupts ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-09 16:18 ` Laurent Pinchart
@ 2011-11-09 16:24 ` Gary Thomas
2011-11-11 14:26 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-09 16:24 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>>>> 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: 4444160
>>>> Buffer 7 mapped at address 0x40adf000.
>>>>
>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>> 00000018
>>>
>>> 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 this mode?
>> * Why is the statement not written (as all others are)
>> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
>> I tried this change and the kernel doesn't crash.
>>
>> I've found that I can get raw frames out of CCDC, but I don't get anything
>> at all when the output continues through the preview and/or resize nodes.
>>
>> Ideas?
>
> I'm really puzzled, this should have been caught much earlier :-)
>
> Your analysis makes sense. Would you like to submit a patch yourself ? If not
> I can do it.
Sure, I can submit a patch. I would like to figure out why it's
not working first.
Any ideas how I can debug this? I can't seem to get anything past the
CCDC, e.g. into the preview or resize units. Is there some way to trace
packets/data through the various stages? Any ideas what might cause it
to stall?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-09 11:01 ` Gary Thomas
@ 2011-11-09 16:18 ` Laurent Pinchart
2011-11-09 16:24 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-09 16:18 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> >> 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: 4444160
> >> Buffer 7 mapped at address 0x40adf000.
> >>
> >> Unable to handle kernel NULL pointer dereference at virtual address
> >> 00000018
> >
> > 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 this mode?
> * Why is the statement not written (as all others are)
> struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
> I tried this change and the kernel doesn't crash.
>
> I've found that I can get raw frames out of CCDC, but I don't get anything
> at all when the output continues through the preview and/or resize nodes.
>
> Ideas?
I'm really puzzled, this should have been caught much earlier :-)
Your analysis makes sense. Would you like to submit a patch yourself ? If not
I can do it.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-09 0:54 ` Laurent Pinchart
@ 2011-11-09 11:01 ` Gary Thomas
2011-11-09 16:18 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-09 11:01 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
>> 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: 4444160
>> Buffer 7 mapped at address 0x40adf000.
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 00000018
>
> 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);
I tried this change and the kernel doesn't crash.
I've found that I can get raw frames out of CCDC, but I don't get anything at
all when the output continues through the preview and/or resize nodes.
Ideas?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 13:38 ` Gary Thomas
2011-11-08 13:40 ` Gary Thomas
@ 2011-11-09 0:54 ` Laurent Pinchart
2011-11-09 11:01 ` Gary Thomas
1 sibling, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-09 0:54 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> 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: 4444160
> Buffer 7 mapped at address 0x40adf000.
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000018
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 ground line
in
+ * between would have been nice), logic 0 levels can raise up to
650mV.
+ * This exceeds the camera input pins VIL maximum voltage.
+ *
+ * To work around the issue, disable pull-ups on the PCLK, HS and VS
+ * signals.
+ */
+ OMAP3_MUX(CAM_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_HS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_VS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
> pgd = c0004000
> [00000018] *pgd=00000000
> 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 : [<00000000>] psr: 60000193
> sp : c0433e70 ip : 00000000 fp : 00000001
> r10: 00000001 r9 : c0470524 r8 : 00000001
> r7 : 00000080 r6 : 00000000 r5 : 00000000 r4 : cee45b88
> r3 : 00000004 r2 : 00000000 r1 : 00000000 r0 : cee45c28
> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 8e4d8019 DAC: 00000015
> Process swapper (pid: 0, stack limit = 0xc04322f0)
> Stack: (0xc0433e70 to 0xc0434000)
> 3e60: 00000004 00000000 00000000
> 00000000 3e80: 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 3ea0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 3ec0: 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 3ee0: 00000000 00000000 00000000
> 00000000 80000000 cee45b88 80000000 c0252d88 3f00: cee40000 80000000
> 00000000 00000080 00000001 c024a424 cee2ff80 00000018 3f20: c04476e8
> c0089bd8 c04476e8 ced051c0 00004c00 c04476e8 00000000 c0468d44 3f40:
> c0437154 80004059 413fc082 00000000 00000000 c0089d40 c04476e8 c008b7f4
> 3f60: 00000018 c00896c4 0000019a c0033060 60000013 ffffffff fa200000
> c003caf4 3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c
> c0468d44 c0437154 3fa0: 80004059 413fc082 00000000 00000000 00000000
> c0433fc8 c003dfec c003dff0 3fc0: 60000013 ffffffff c043415c c0029e24
> c0682980 c0008a04 c0008488 00000a7d 3fe0: 80000100 c0029e24 10c53c7d
> c0434080 c0029e20 8000803c 00000000 00000000 [<c0251ae0>]
> (ccdc_hs_vs_isr+0x28/0x40) from [<c0252d88>]
> (omap3isp_ccdc_isr+0x2c4/0x2d8) [<c0252d88>]
> (omap3isp_ccdc_isr+0x2c4/0x2d8) from [<c024a424>] (isp_isr+0x19c/0x230)
> [<c024a424>] (isp_isr+0x19c/0x230) from [<c0089bd8>]
> (handle_irq_event_percpu+0x30/0x170) [<c0089bd8>]
> (handle_irq_event_percpu+0x30/0x170) from [<c0089d40>]
> (handle_irq_event+0x28/0x38) [<c0089d40>] (handle_irq_event+0x28/0x38)
> from [<c008b7f4>] (handle_level_irq+0xac/0xd4) [<c008b7f4>]
> (handle_level_irq+0xac/0xd4) from [<c00896c4>]
> (generic_handle_irq+0x30/0x44) [<c00896c4>] (generic_handle_irq+0x30/0x44)
> from [<c0033060>] (asm_do_IRQ+0x60/0x84) [<c0033060>]
> (asm_do_IRQ+0x60/0x84) from [<c003caf4>] (__irq_svc+0x34/0x80) Exception
> stack(0xc0433f80 to 0xc0433fc8)
> 3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c c0468d44
> c0437154 3fa0: 80004059 413fc082 00000000 00000000 00000000 c0433fc8
> c003dfec c003dff0 3fc0: 60000013 ffffffff
> [<c003caf4>] (__irq_svc+0x34/0x80) from [<c003dff0>] (cpu_idle+0x4c/0x88)
> [<c003dff0>] (cpu_idle+0x4c/0x88) from [<c0008a04>]
> (start_kernel+0x26c/0x2c0) [<c0008a04>] (start_kernel+0x26c/0x2c0) from
> [<8000803c>] (0x8000803c) Code: ebfce5a2 e3a03004 e58d3000 e28400a0
> (e5953018)
> ---[ end trace bd263f5099189d04 ]---
>
> Any ideas of where to look?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 13:38 ` Gary Thomas
@ 2011-11-08 13:40 ` Gary Thomas
2011-11-09 0:54 ` Laurent Pinchart
1 sibling, 0 replies; 41+ messages in thread
From: Gary Thomas @ 2011-11-08 13:40 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
> 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: 4444160
> Buffer 7 mapped at address 0x40adf000.
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000018
> pgd = c0004000
> [00000018] *pgd=00000000
> 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 : [<00000000>] psr: 60000193
> sp : c0433e70 ip : 00000000 fp : 00000001
> r10: 00000001 r9 : c0470524 r8 : 00000001
> r7 : 00000080 r6 : 00000000 r5 : 00000000 r4 : cee45b88
> r3 : 00000004 r2 : 00000000 r1 : 00000000 r0 : cee45c28
> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 8e4d8019 DAC: 00000015
> Process swapper (pid: 0, stack limit = 0xc04322f0)
> Stack: (0xc0433e70 to 0xc0434000)
> 3e60: 00000004 00000000 00000000 00000000
> 3e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3ee0: 00000000 00000000 00000000 00000000 80000000 cee45b88 80000000 c0252d88
> 3f00: cee40000 80000000 00000000 00000080 00000001 c024a424 cee2ff80 00000018
> 3f20: c04476e8 c0089bd8 c04476e8 ced051c0 00004c00 c04476e8 00000000 c0468d44
> 3f40: c0437154 80004059 413fc082 00000000 00000000 c0089d40 c04476e8 c008b7f4
> 3f60: 00000018 c00896c4 0000019a c0033060 60000013 ffffffff fa200000 c003caf4
> 3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c c0468d44 c0437154
> 3fa0: 80004059 413fc082 00000000 00000000 00000000 c0433fc8 c003dfec c003dff0
> 3fc0: 60000013 ffffffff c043415c c0029e24 c0682980 c0008a04 c0008488 00000a7d
> 3fe0: 80000100 c0029e24 10c53c7d c0434080 c0029e20 8000803c 00000000 00000000
> [<c0251ae0>] (ccdc_hs_vs_isr+0x28/0x40) from [<c0252d88>] (omap3isp_ccdc_isr+0x2c4/0x2d8)
> [<c0252d88>] (omap3isp_ccdc_isr+0x2c4/0x2d8) from [<c024a424>] (isp_isr+0x19c/0x230)
> [<c024a424>] (isp_isr+0x19c/0x230) from [<c0089bd8>] (handle_irq_event_percpu+0x30/0x170)
> [<c0089bd8>] (handle_irq_event_percpu+0x30/0x170) from [<c0089d40>] (handle_irq_event+0x28/0x38)
> [<c0089d40>] (handle_irq_event+0x28/0x38) from [<c008b7f4>] (handle_level_irq+0xac/0xd4)
> [<c008b7f4>] (handle_level_irq+0xac/0xd4) from [<c00896c4>] (generic_handle_irq+0x30/0x44)
> [<c00896c4>] (generic_handle_irq+0x30/0x44) from [<c0033060>] (asm_do_IRQ+0x60/0x84)
> [<c0033060>] (asm_do_IRQ+0x60/0x84) from [<c003caf4>] (__irq_svc+0x34/0x80)
> Exception stack(0xc0433f80 to 0xc0433fc8)
> 3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c c0468d44 c0437154
> 3fa0: 80004059 413fc082 00000000 00000000 00000000 c0433fc8 c003dfec c003dff0
> 3fc0: 60000013 ffffffff
> [<c003caf4>] (__irq_svc+0x34/0x80) from [<c003dff0>] (cpu_idle+0x4c/0x88)
> [<c003dff0>] (cpu_idle+0x4c/0x88) from [<c0008a04>] (start_kernel+0x26c/0x2c0)
> [<c0008a04>] (start_kernel+0x26c/0x2c0) from [<8000803c>] (0x8000803c)
> Code: ebfce5a2 e3a03004 e58d3000 e28400a0 (e5953018)
> ---[ end trace bd263f5099189d04 ]---
>
> Any ideas of where to look?
>
Note: I was able to grab the raw SGRBG12 data using yavta, I only
get the failure when I run it through the CCDC->previewer->resizer
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 13:06 ` Laurent Pinchart
@ 2011-11-08 13:38 ` Gary Thomas
2011-11-08 13:40 ` Gary Thomas
2011-11-09 0:54 ` Laurent Pinchart
0 siblings, 2 replies; 41+ messages in thread
From: Gary Thomas @ 2011-11-08 13:38 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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 0x403d0000.
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: 4444160
Buffer 7 mapped at address 0x40adf000.
Unable to handle kernel NULL pointer dereference at virtual address 00000018
pgd = c0004000
[00000018] *pgd=00000000
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 : [<00000000>] psr: 60000193
sp : c0433e70 ip : 00000000 fp : 00000001
r10: 00000001 r9 : c0470524 r8 : 00000001
r7 : 00000080 r6 : 00000000 r5 : 00000000 r4 : cee45b88
r3 : 00000004 r2 : 00000000 r1 : 00000000 r0 : cee45c28
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8e4d8019 DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc04322f0)
Stack: (0xc0433e70 to 0xc0434000)
3e60: 00000004 00000000 00000000 00000000
3e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3ee0: 00000000 00000000 00000000 00000000 80000000 cee45b88 80000000 c0252d88
3f00: cee40000 80000000 00000000 00000080 00000001 c024a424 cee2ff80 00000018
3f20: c04476e8 c0089bd8 c04476e8 ced051c0 00004c00 c04476e8 00000000 c0468d44
3f40: c0437154 80004059 413fc082 00000000 00000000 c0089d40 c04476e8 c008b7f4
3f60: 00000018 c00896c4 0000019a c0033060 60000013 ffffffff fa200000 c003caf4
3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c c0468d44 c0437154
3fa0: 80004059 413fc082 00000000 00000000 00000000 c0433fc8 c003dfec c003dff0
3fc0: 60000013 ffffffff c043415c c0029e24 c0682980 c0008a04 c0008488 00000a7d
3fe0: 80000100 c0029e24 10c53c7d c0434080 c0029e20 8000803c 00000000 00000000
[<c0251ae0>] (ccdc_hs_vs_isr+0x28/0x40) from [<c0252d88>] (omap3isp_ccdc_isr+0x2c4/0x2d8)
[<c0252d88>] (omap3isp_ccdc_isr+0x2c4/0x2d8) from [<c024a424>] (isp_isr+0x19c/0x230)
[<c024a424>] (isp_isr+0x19c/0x230) from [<c0089bd8>] (handle_irq_event_percpu+0x30/0x170)
[<c0089bd8>] (handle_irq_event_percpu+0x30/0x170) from [<c0089d40>] (handle_irq_event+0x28/0x38)
[<c0089d40>] (handle_irq_event+0x28/0x38) from [<c008b7f4>] (handle_level_irq+0xac/0xd4)
[<c008b7f4>] (handle_level_irq+0xac/0xd4) from [<c00896c4>] (generic_handle_irq+0x30/0x44)
[<c00896c4>] (generic_handle_irq+0x30/0x44) from [<c0033060>] (asm_do_IRQ+0x60/0x84)
[<c0033060>] (asm_do_IRQ+0x60/0x84) from [<c003caf4>] (__irq_svc+0x34/0x80)
Exception stack(0xc0433f80 to 0xc0433fc8)
3f80: 00000001 c0446be0 0039acad 60000013 c0432000 c043715c c0468d44 c0437154
3fa0: 80004059 413fc082 00000000 00000000 00000000 c0433fc8 c003dfec c003dff0
3fc0: 60000013 ffffffff
[<c003caf4>] (__irq_svc+0x34/0x80) from [<c003dff0>] (cpu_idle+0x4c/0x88)
[<c003dff0>] (cpu_idle+0x4c/0x88) from [<c0008a04>] (start_kernel+0x26c/0x2c0)
[<c0008a04>] (start_kernel+0x26c/0x2c0) from [<8000803c>] (0x8000803c)
Code: ebfce5a2 e3a03004 e58d3000 e28400a0 (e5953018)
---[ end trace bd263f5099189d04 ]---
Any ideas of where to look?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 12:52 ` Gary Thomas
@ 2011-11-08 13:06 ` Laurent Pinchart
2011-11-08 13:38 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-08 13:06 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 12:30 ` Javier Martinez Canillas
2011-11-08 12:33 ` Laurent Pinchart
@ 2011-11-08 12:52 ` Gary Thomas
2011-11-08 13:06 ` Laurent Pinchart
1 sibling, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-08 12:52 UTC (permalink / raw)
To: Javier Martinez Canillas; +Cc: Laurent Pinchart, Linux Media Mailing List
On 2011-11-08 05:30, Javier Martinez Canillas wrote:
> On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas<gary@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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 12:30 ` Javier Martinez Canillas
@ 2011-11-08 12:33 ` Laurent Pinchart
2011-11-08 12:52 ` Gary Thomas
1 sibling, 0 replies; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-08 12:33 UTC (permalink / raw)
To: Javier Martinez Canillas; +Cc: Gary Thomas, Linux Media Mailing List
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 <gary@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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-08 12:20 ` Gary Thomas
@ 2011-11-08 12:30 ` Javier Martinez Canillas
2011-11-08 12:33 ` Laurent Pinchart
2011-11-08 12:52 ` Gary Thomas
0 siblings, 2 replies; 41+ messages in thread
From: Javier Martinez Canillas @ 2011-11-08 12:30 UTC (permalink / raw)
To: Gary Thomas; +Cc: Laurent Pinchart, Linux Media Mailing List
On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas <gary@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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-04 10:37 ` Laurent Pinchart
@ 2011-11-08 12:20 ` Gary Thomas
2011-11-08 12:30 ` Javier Martinez Canillas
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-08 12:20 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux Media Mailing List
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Using MT9P031 digital sensor
2011-11-01 18:52 Gary Thomas
@ 2011-11-04 10:37 ` Laurent Pinchart
2011-11-08 12:20 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: Laurent Pinchart @ 2011-11-04 10:37 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Using MT9P031 digital sensor
@ 2011-11-01 18:52 Gary Thomas
2011-11-04 10:37 ` Laurent Pinchart
0 siblings, 1 reply; 41+ messages in thread
From: Gary Thomas @ 2011-11-01 18:52 UTC (permalink / raw)
To: Linux Media Mailing List
I'm trying to use the MT9P031 digital sensor with the Media Controller
Framework. media-ctl tells me that the sensor is set to capture using
SGRBG12 2592x1944
Questions:
* What pixel format in ffmpeg does this correspond to?
* Can I zoom/crop with this driver using the MCF? If so, how?
Thanks for any help
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-03-29 11:33 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-23 19:01 Using MT9P031 digital sensor Joshua Hintze
2012-03-26 5:13 ` Joshua Hintze
2012-03-26 8:25 ` Laurent Pinchart
2012-03-26 15:44 ` Joshua Hintze
2012-03-26 17:38 ` Laurent Pinchart
2012-03-26 17:43 ` Joshua Hintze
[not found] ` <4F708A66.8090303@mlbassoc.com>
2012-03-26 15:37 ` Joshua Hintze
2012-03-26 16:32 ` Gary Thomas
2012-03-26 16:55 ` Joshua Hintze
2012-03-27 14:44 ` jean-philippe francois
2012-03-29 11:33 ` Laurent Pinchart
-- strict thread matches above, loose matches on Subject: below --
2011-11-01 18:52 Gary Thomas
2011-11-04 10:37 ` Laurent Pinchart
2011-11-08 12:20 ` Gary Thomas
2011-11-08 12:30 ` Javier Martinez Canillas
2011-11-08 12:33 ` Laurent Pinchart
2011-11-08 12:52 ` Gary Thomas
2011-11-08 13:06 ` Laurent Pinchart
2011-11-08 13:38 ` Gary Thomas
2011-11-08 13:40 ` Gary Thomas
2011-11-09 0:54 ` Laurent Pinchart
2011-11-09 11:01 ` Gary Thomas
2011-11-09 16:18 ` Laurent Pinchart
2011-11-09 16:24 ` Gary Thomas
2011-11-11 14:26 ` Laurent Pinchart
2011-11-14 11:42 ` Gary Thomas
2011-11-16 1:26 ` Laurent Pinchart
2011-11-16 12:03 ` Gary Thomas
2011-11-24 11:28 ` Laurent Pinchart
2011-11-25 11:50 ` Gary Thomas
2011-11-28 11:07 ` Laurent Pinchart
2011-11-28 12:42 ` Gary Thomas
2011-11-28 12:49 ` Laurent Pinchart
2011-11-28 12:53 ` Gary Thomas
2011-11-30 14:13 ` Gary Thomas
2011-11-30 14:30 ` Laurent Pinchart
2011-11-30 14:38 ` Hiremath, Vaibhav
2011-11-30 14:57 ` Gary Thomas
2011-11-30 17:00 ` Gary Thomas
2011-11-30 23:49 ` Laurent Pinchart
2011-11-30 23:42 ` Laurent Pinchart
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.