From: Gary Thomas <gary@mlbassoc.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Javier Martinez Canillas <martinez.javier@gmail.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Using MT9P031 digital sensor
Date: Wed, 30 Nov 2011 07:57:30 -0700 [thread overview]
Message-ID: <4ED6445A.2070908@mlbassoc.com> (raw)
In-Reply-To: <201111301530.58977.laurent.pinchart@ideasonboard.com>
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
------------------------------------------------------------
next prev parent reply other threads:[~2011-11-30 14:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-01 18:52 Using MT9P031 digital sensor 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 [this message]
2011-11-30 17:00 ` Gary Thomas
2011-11-30 23:49 ` Laurent Pinchart
2011-11-30 23:42 ` Laurent Pinchart
-- strict thread matches above, loose matches on Subject: below --
2012-03-23 19:01 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ED6445A.2070908@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=martinez.javier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox