Hi Matthieu, [CC Morimoto-san] [Changed list to linux-media] On Tue, Jan 20, 2009 at 6:27 PM, Matthieu CASTET <matthieu.castet@xxxxxxxxxx> wrote: > Magnus Damm a écrit : >> On Mon, Jan 19, 2009 at 11:02 PM, Matthieu CASTET >>> But we didn't do stop_capture, so as far I understand the controller is >>> still writing data in memory. What prevent us to free the buffer we are >>> writing. >> >> I have not looked into this in great detail, but isn't this handled by >> the videobuf state? The videobuf has state VIDEOBUF_ACTIVE while it is >> in use. I don't think such a buffer is freed. > Well from my understanding form videobuf_queue_cancel [1], we call > buf_release on all buffer. Yeah, you are correct. I guess waiting for the buffer before freeing is the correct way to do this. I guess vivi doesn't have to do this since it's not using DMA. Morimoto-san, can you check the attached patch? I've tested it on my Migo-R board together with mplayer and it seems to work well here. I don't think using mplayer triggers this error case though, so maybe we should try some other application. Cheers, / magnus
--- 0001/drivers/media/video/sh_mobile_ceu_camera.c +++ work/drivers/media/video/sh_mobile_ceu_camera.c 2009-02-13 18:55:55.000000000 +0900 @@ -150,6 +150,7 @@ static void free_buffer(struct videobuf_ if (in_interrupt()) BUG(); + videobuf_waiton(&buf->vb, 0, 0); videobuf_dma_contig_free(vq, &buf->vb); dev_dbg(&icd->dev, "%s freed\n", __func__); buf->vb.state = VIDEOBUF_NEEDS_INIT;
