Grabbing single stills on MX31 - Re: Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Thu, 7 May 2009, Guennadi Liakhovetski wrote: On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote: ... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. Great, thanks for testing and debugging! Ok, so, I will have to test this case some time... Guennadi, This workaround (queuing 2 buffers when needing only one) is having the side effect of greatly increasing the time taken. I did several tests playing with camera vertical blanking and looking at capture times: Vblank / real / user / sys time: 0 / real0m 0.90s / user0m 0.00s / sys 0m 0.34s 1 frame / real0m 1.04s / user0m 0.00s / sys 0m 0.34s 2 frames / real0m 1.18s / user0m 0.00s / sys 0m 0.33s 2.5 (max)/ real0m 1.23s / user0m 0.00s / sys 0m 0.35s I think the second frame is being captured altogether, and its dma transfer is not allowing any other process to run meanwhile. (VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.) Do you think it will be too hard to fix? Regards, --Agustín. -- 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
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong, but I feel quite lost at the moment. I am starting to fear that I introduced some subtle bug while merging your stack into Sascha's... Where can I check mx3_camera.c, ipu_idmac.c, soc_camera.c prior to the subdev changes? I would like them to check that my edited patches lead to the same sources as the originals. Thanks regards, --Agustín. I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0
Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
Holy cow... On Tue, 5 May 2009, Agustin wrote: On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong... [snip] After checking out every single bit in CSI and IDMAC to be correct according to reference and the same I had in the previous/working version... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. --Agustín. [snip!] -- 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
Re: Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote: Holy cow... mu-u-u-u-u-u?:-) After checking out every single bit in CSI and IDMAC to be correct according to reference and the same I had in the previous/working version... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. Great, thanks for testing and debugging! Ok, so, I will have to test this case some time... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
Hi Guennadi, --- Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? [snip] Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git I managed to merge your patch stack of 20090415 on top of Sascha's stack for 2.6.29. I think that is just before the v4l-subdev work. Then I adapted my code to work pretty much as your mt9p031 driver. Now I get a timeout when trying to capture a single image, with the same hardware configuration that is working fine with 2.6.28-next. I can see my Sixcam camera dumping a few frames before the timeout. I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000 ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000 ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003 ipu-core: ipu_idmac: write param mem - addr = 0x00010078, data = 0x8400 ipu-core: ipu_idmac: write param mem - addr = 0x00010079, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x0001007A, data = 0x3E0E2FFB ipu-core: ipu_idmac: write param mem - addr = 0x0001007B, data = 0x0002 ipu-core: ipu_idmac: write param mem - addr = 0x0001007C, data = 0x dma dma0chan7: ipu_idmac: Submitting sg c4e0772c dma dma0chan7: ipu_idmac: Updated sg c4e0772c on channel 0x7 buffer 0 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x80, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x4001,
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Agustin wrote: Hi Guennadi, --- Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? [snip] Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git I managed to merge your patch stack of 20090415 on top of Sascha's stack for 2.6.29. I think that is just before the v4l-subdev work. Then I adapted my code to work pretty much as your mt9p031 driver. Now I get a timeout when trying to capture a single image, with the same hardware configuration that is working fine with 2.6.28-next. I can see my Sixcam camera dumping a few frames before the timeout. Have you applied this patch: Author: Ming Lei tom.leim...@gmail.com Date: Fri Mar 27 21:50:00 2009 +0800 driver core: fix driver_match_device This patch fixes a bug introduced in commit 49b420a13ff95b449947181190b08367348e3e1b. If a instance of bus_type doesn't have .match method, all .probe of drivers in the bus should be called, or else the .probe have not a chance to be called. Signed-off-by: Ming Lei tom.leim...@gmail.com Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Signed-off-by: Greg Kroah-Hartman gre...@suse.de ? Thanks Guennadi I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000 ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000 ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003 ipu-core: ipu_idmac:
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 5 May 2009, Agustin wrote: Hi Guennadi, --- Guennadi Liakhovetski wrote: On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? [snip] Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git I managed to merge your patch stack of 20090415 on top of Sascha's stack for 2.6.29. I think that is just before the v4l-subdev work. Then I adapted my code to work pretty much as your mt9p031 driver. Now I get a timeout when trying to capture a single image, with the same hardware configuration that is working fine with 2.6.28-next. I can see my Sixcam camera dumping a few frames before the timeout. Have you applied this patch: Author: Ming Lei Date: Fri Mar 27 21:50:00 2009 +0800 driver core: fix driver_match_device This patch fixes a bug introduced in commit 49b420a13ff95b449947181190b08367348e3e1b. If a instance of bus_type doesn't have .match method, all .probe of drivers in the bus should be called, or else the .probe have not a chance to be called. Signed-off-by: Ming Lei Reported-by: Guennadi Liakhovetski Signed-off-by: Greg Kroah-Hartman ? No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac:
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks Guennadi I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000 ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000 ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003 ipu-core: ipu_idmac: write param mem - addr = 0x00010078, data = 0x8400 ipu-core: ipu_idmac: write param mem - addr = 0x00010079, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x0001007A, data = 0x3E0E2FFB ipu-core: ipu_idmac: write param mem - addr = 0x0001007B, data = 0x0002 ipu-core: ipu_idmac: write param mem - addr = 0x0001007C, data = 0x dma dma0chan7:
