Thank you both for your assistance.

I was able to make it work by correcting my vsync and hsync inputs,
adjusting the vertical blanking, and finally taking out all my debug
cruft that had built up.

It's nice that my changes were limited to the
board-omap3beagle-camera.c and my custom camera driver file, which I
was able to base on the fsr172x driver (thanks Laurent and AJ).

-chris


On Sun, Feb 26, 2012 at 5:59 PM, Sakari Ailus [off-list ref] wrote:

Hi Laurent,

Laurent Pinchart wrote:

quoted

On Monday 27 February 2012 01:35:14 Sakari Ailus wrote:

quoted

Laurent Pinchart wrote:

quoted

On Saturday 25 February 2012 01:48:02 Sakari Ailus wrote:

quoted

On Fri, Feb 17, 2012 at 05:32:31PM -0600, Chris Whittenburg wrote:

quoted

I fixed my sensor to respect a "run" signal from the omap, so that now
it only sends data when the ccdc is expecting it.

This fixed my problem, and now I can capture the 640x1440 frames.

At least the first one...

Subsequent frames are always full of 0x55, like the ISP didn't write
anything into them.

I still get the VD0 interrupts, and I checked that WEN in the
CCDC_SYN_MODE register is set, and that the EXWEN bit is clear.

I'm using the command:
yavta -c2 -p -F --skip 0 -f Y8 -s 640x1440 /dev/video2

Here are my register settings:

[ 6534.029907] omap3isp omap3isp: -------------CCDC Register
dump------------- [ 6534.029907] omap3isp omap3isp: ###CCDC
PCR=0x00000000
[ 6534.029937] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030f00
[ 6534.029937] omap3isp omap3isp: ###CCDC HD_VD_WID=0x00000000
[ 6534.029937] omap3isp omap3isp: ###CCDC PIX_LINES=0x00000000
[ 6534.029968] omap3isp omap3isp: ###CCDC HORZ_INFO=0x0000027f
[ 6534.029968] omap3isp omap3isp: ###CCDC VERT_START=0x00000000
[ 6534.029968] omap3isp omap3isp: ###CCDC VERT_LINES=0x0000059f
[ 6534.029998] omap3isp omap3isp: ###CCDC CULLING=0xffff00ff
[ 6534.029998] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x00000280
[ 6534.029998] omap3isp omap3isp: ###CCDC SDOFST=0x00000000
[ 6534.030029] omap3isp omap3isp: ###CCDC SDR_ADDR=0x00001000
[ 6534.030029] omap3isp omap3isp: ###CCDC CLAMP=0x00000010
[ 6534.030029] omap3isp omap3isp: ###CCDC DCSUB=0x00000000
[ 6534.030059] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11
[ 6534.030059] omap3isp omap3isp: ###CCDC BLKCMP=0x00000000
[ 6534.030059] omap3isp omap3isp: ###CCDC FPC=0x00000000
[ 6534.030090] omap3isp omap3isp: ###CCDC FPC_ADDR=0x00000000
[ 6534.030090] omap3isp omap3isp: ###CCDC VDINT=0x059e03c0
[ 6534.030090] omap3isp omap3isp: ###CCDC ALAW=0x00000000
[ 6534.030120] omap3isp omap3isp: ###CCDC REC656IF=0x00000000
[ 6534.030120] omap3isp omap3isp: ###CCDC CFG=0x00008000
[ 6534.030120] omap3isp omap3isp: ###CCDC FMTCFG=0x0000e000
[ 6534.030151] omap3isp omap3isp: ###CCDC FMT_HORZ=0x00000280
[ 6534.030151] omap3isp omap3isp: ###CCDC FMT_VERT=0x000005a0
[ 6534.030151] omap3isp omap3isp: ###CCDC PRGEVEN0=0x00000000
[ 6534.030181] omap3isp omap3isp: ###CCDC PRGEVEN1=0x00000000
[ 6534.030181] omap3isp omap3isp: ###CCDC PRGODD0=0x00000000
[ 6534.030181] omap3isp omap3isp: ###CCDC PRGODD1=0x00000000
[ 6534.030212] omap3isp omap3isp: ###CCDC VP_OUT=0x0b3e2800
[ 6534.030212] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x00006600
[ 6534.030212] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x00000000
[ 6534.030242] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x00000000
[ 6534.030242] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
[ 6534.030242] omap3isp omap3isp:
--------------------------------------------

Output frame 0 is always good, while output frame 1 is 0x5555.

I believe my sensor is respecting the clocks required before and after
the frame.

Could the ISP driver be writing my data to some unexpected location
rather than to the v4l2 buffer?

Is there a way to determine if the CCDC is writing to memory or not?

How long vertical blanking do you have? It shouldn't have an effect,
though.

It definitely can :-) If vertical blanking isn't long enough, the CCDC
will start processing the next frame before the driver gets time to update
the hardware with the pointer to the next buffer. The first frame will
then be overwritten.

Sure, but in that case no buffers should be dequeued from the driver
either --- as they should always be marked faulty since reprogramming
the CCDC isn't possible.

Does the driver detect that ?

It does. The CCDC is disabled in VD1 interrupt which should arrive well
before VD0. The CCDC continues to process frame until the end of it, and
once it becomes idle, a new buffer address is programmed. At least as
far as I remember and how the code looks like to me this late in the
evening. ;)

Chris: are you capturing at CCDC output video node?

It might also make sense to check whether VD1 and VD0 interrupts arrive
as expected. (I.e. VD1 first, then VD0 on each frame.)

Regards,

--
Sakari Ailus
sakari.ailus@iki.fi