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