Re: mx3_camera and DMA / double buffering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux