2010/11/4 Bastian Hecht <hechtb@xxxxxxxxxxxxxx>: > 2010/11/4 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> Hi Bastian, >> >> On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: >>> 2010/11/3 Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx>: >>> > Bastian Hecht wrote: >>> >> 2010/11/3 Bastian Hecht <hechtb@xxxxxxxxxxxxxx>: >>> >>> Hello ISP team, >>> >>> >>> >>> I succeeded to stream the first images from the sensor to userspace >>> >>> using Laurent's media-ctl and yafta. Unfortunately all images are >>> >>> black (10MB of zeros). >>> >>> Once by chance I streamed some images (1 of 20 about) with content. >>> >>> All values were < 0x400, so that I assume the values were correctly >>> >>> transferred for my 10-bit pixels. >>> >>> >>> >>> I shortly describe my setup: >>> >>> As I need xclk_a activated for my sensor to work (I2C), I activate the >>> >>> xclk in the isp_probe function. Early hack that I want to remove >>> >>> later. >>> > >>> > It _might_ be better to have this in isp_get(). >>> > >>> >>> While I placed my activation in mid of the probe function, I had >>> >>> somehow the interrupts disabled when trying to stream using yafta. So >>> >>> I hacked in the reenabling of the interrupts somewhere else in probe() >>> >>> too. >>> > >>> > That should definitely not be necessary. The interrupts are enabled in >>> > isp_get(). >>> > >>> >>> As I dug through the isp code I saw that it is better to place the >>> >>> clock activation after the final isp_put in probe() then the >>> >>> interrupts keep working, but this way I never got a valid picture so >>> >>> far. It's all a mess, I know. I try to transfer the activation to my >>> >>> sensor code and board-setup code like in the et8ek8 code. >>> >> >>> >> I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 >>> >> HS_VS_event is generated per second. 1fps corresponds to my clocking, >>> >> so 1 vs per second is fine. But shouldn't I see about 2000 hs >>> >> interrupts there too? HS_VS_IRQ is described as "HS or VS synchro >>> >> event". >>> > >>> > Are you getting any other interrupts? Basically every ISP block which is >>> > on the pipe will produce interrupts. Which ISP block is writing the >>> > images to memory for you? >>> >>> I read out the CCDC with this pipeline: >>> ./media-ctl -r -l '"mt9p031 2-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 >>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >>> ./media-ctl -f '"mt9p031 2-005d":0[SGRBG10 2592x1944], "OMAP3 ISP >>> CCDC":1[SGRBG10 2592x1944]' >>> ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 >>> >>> I get these interrupts while reading 4 frames: >>> >>> [ 3962.689483] s_stream is it! enable: 1 >>> [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ >>> [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ >>> [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ >>> [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ >>> [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ >>> [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ >>> [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ >>> [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ >>> [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ >>> [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ >>> [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ >>> [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable >>> module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being >>> disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to >>> disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is >>> being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user >>> wants to disable module. >>> [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being >>> disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ >>> [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ >>> [ 3967.242614] s_stream is it! enable: 0 >>> >>> > Maybe a stupid question, but have you set exposure and gain to a >>> > reasonable value? :-) >>> >>> First reaction was - that must be it! But hmmm... the flanks on the >>> data lines of the camera are mostly high. When I press my finger on >>> the sensor they are mostly low. The other values seem to be good too: >>> xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within >>> the limits of the datasheets - camera and omap isp). cam_vs raises for >>> about 1 sec goes shortly down and comes up again. cam_hs seems to fit >>> too. >>> Every 20th try I get data from an image sample the other times only zeros. >> >> The CCDC is configured with a DC subtract value of 64 by default, so it >> subtract 64 from every pixel. If your pixel values are lower than or equal to >> 64 you will get a black image. As a quick hack you can replace >> >> ccdc->clamp.dcsubval = 64; >> >> with >> >> ccdc->clamp.dcsubval = 0; >> >> in isp_ccdc_init(). The correct solution is to use the >> VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0. > > This is not the problem. The 64 reduction is a nice hint as I was > wondering why I get 0x3BF when the sensor is full in light and I was > lucky and a frame was read. I wondered why it is not 0x3FF - all 10 > bits high. When I slightly press my finger on it I get about > 0x045-0x1bf. So the sensor values seem to be ok. The values fill the > whole 10MB image. I want to clarify this: I try to read images with yafta. I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. I repeat the process some times and keep checking the data. After - let's say the 6th time - the images contain exactly the data I expect. WHEN they are read they are good. I just don't want to read 20 black images before 1 image is transferred right. -Bastian > Can you give me an other media-ctl setup, so that I can read jpegs > from the preview unit, please? > > I want to follow 3 leads now: > > - replace my igep with another one > - check if the isp (code) works better with preview data > - I want to check yafta > > Thank you, > > Bastian > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
