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