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. 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
