Re: mx3_camera and DMA / double buffering

Re: mx3_camera and DMA / double buffering

[Markus Niebel]

Am 03.12.2010 21:07, schrieb Guennadi Liakhovetski:
> On Fri, 3 Dec 2010, Markus Niebel wrote:
>
>> Hello,
>>
>> thank you for your answer. I think there is a problem, but I did not describe
>> it correctly. See my comments
>>
>>> On Thu, 2 Dec 2010, Markus Niebel wrote:
>>>
>>>> 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:
>>>>
>>>> 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.
>>
>> 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.

Thanks
Markus

Re: mx3_camera and DMA / double buffering

[Guennadi Liakhovetski]

On Mon, 17 Jan 2011, Markus Niebel wrote:

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

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

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

Re: mx3_camera and DMA / double buffering

[Markus Niebel]

Am 17.01.2011 17:27, schrieb Guennadi Liakhovetski:
> On Mon, 17 Jan 2011, Markus Niebel wrote:
>
>> 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.
>
>> 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.
>
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello,

we see messages like this (with more logging output at higher possibility):

[   24.260000] dma dma0chan7: IDMAC irq 177, buf 1
[   24.260000] dma dma0chan7: IRQ on active buffer on channel 7, active 
1, ready 0, 0, current 80!

and calls from an application to select times out

when changing the order of calls in soc_camera_streamon 
(videobuf_streamon before v4l2_subdev_call(sd, video, s_stream, 1)
images always can be captured.

My assumption for the reason is based on the following:

1) Since CSI is enabled by idmac in ipu_init_channel, mx3_camera has no 
control over the data flow. As soon as the first buffer is queued with 
idmac it will filled - my thoughts are that this can interfere with the 
initial setup during submission of the first two buffers.

2) The freescale sample code (mxc_camera.c, not in mainline) enables the 
CSI after channel and buffers are configured.

Thanks
Markus