mx3_camera and DMA / double buffering

Quoted 25 lines

Hello,

thank you for your answer. I think there is a problem, but I did not describe it correctly. See my comments

Quoted 8 lines · Markus Niebel

Quoted 7 lines

Hello,

we're working with a special cameraboard (CCD + Analog Frontend IC). Using the
soc_camera stack on the i.MX35 (mx3_camera) the following problem arises:

Quoted 10 lines

Quoted 10 lines

VIDIOC_STREAMON calls soc_camera_streamon which calls videobuf_streamon - when
iterating the buffers in the queue the function mx3_videobuf_queue is called
for every buffer. This sends the buffers to the omage DMA (IDMAC) using the
tx_submit method. The function ipu_init_channel_buffer (DMA driver ipu_core)
gets only one buffer from the scatterlist, this leads to a single buffer capture.

Quoted 7 lines

What I wanted to say was, that tx_submit (in case of ipu_core idmac_tx_submit) calls ipu_init_channel_buffer if channel status is< IPU_CHANNEL_READY. Since only one buffer is submitted (mx3_videobuf_queue is called in a loop for every single buffer in the videobuf_queue) in the IPU_CHA_DB_MODE_SEL register double buffering will not be enabled for the channel. When I put a debug message in ipu_init_channel_buffer I saw that phyaddr_1 is set to NULL.

Correct, but then, when the second buffer is queued, ipu_update_channel_buffer() shall be called and then IPU_CHA_DB_MODE_SEL shall be set. Isn't this happening?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Hello,

sorry for the __very__ long timeout. The doublebuffering is indeed enabled when the second buffer is queued - my fault, should have read the code more carfully.

But in this way a new question arises:

in soc_camera.c, function soc_camera_streamon the subdev's s_stream handler is called first before videobuf_streamon gets called. This way the videosource is producing data which could produce a race condition with the idmac.

Maybe I'm
wrong but in some cases (especially whith enabled dev_dbg in ipu_idmac.c) we fail to get frames from the driver.

Quoted 6 lines

Hello,

sorry for the __very__ long timeout. The doublebuffering is indeed enabled when the second buffer is queued - my fault, should have read the code more carfully.

Good.

Quoted 5 lines

But in this way a new question arises:

in soc_camera.c, function soc_camera_streamon the subdev's s_stream handler is called first before videobuf_streamon gets called. This way the videosource is producing data which could produce a race condition with the idmac.

Starting the sensor before the host shouldn't cause any problems, because hosts should be capable of handling sensors, continuously streaming data. So, the order should be ok, if the mx3-camera driver gets problems with it, it has a bug and it should be fixed.

Quoted 3 lines

Maybe I'm
wrong but in some cases (especially whith enabled dev_dbg in ipu_idmac.c) we fail to get frames from the driver.

Sorry, what exactly do you mean? Capture doesn't start at all? Or it begins and then hangs? Or some fraims get dropped? Please, explain in more detail.

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html