From patchwork Fri Feb 13 10:14:36 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Magnus Damm X-Patchwork-Id: 513 Return-path: Envelope-to: mchehab@infradead.org Delivery-date: Fri, 13 Feb 2009 10:14:41 +0000 Received: from vger.kernel.org ([209.132.176.167]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1LXv4C-0001te-Rp for mchehab@infradead.org; Fri, 13 Feb 2009 10:14:41 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750913AbZBMKOj (ORCPT ); Fri, 13 Feb 2009 05:14:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751231AbZBMKOi (ORCPT ); Fri, 13 Feb 2009 05:14:38 -0500 Received: from rv-out-0506.google.com ([209.85.198.238]:50621 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750913AbZBMKOh (ORCPT ); Fri, 13 Feb 2009 05:14:37 -0500 Received: by rv-out-0506.google.com with SMTP id g37so637546rvb.1 for ; Fri, 13 Feb 2009 02:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lqTr0DiCy316gRNC38kjhWmyDNALM8u+kBlkvy43ih0=; b=Wk6lgYH9gawFCDM94k9DwPR6NqNjDPlrm7RzNKAJD19xFaia5rdA1kSRrOjFuumATd yLr1ZRbG9sW4wi7l2MqokoXoDYqUZIhDvIqvBvaYi0E4KqXdOKj38l1iN05W7mvkb4uP eDFRlX6/cJPd8IZsY/o0zsPCPgjbMw5WUZBhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tOKwdg5mOnCzy/jC2VVzQtrNIu2/+Sk++yfFEy68dpnJbfGOzQNhreXHK5+WOYLITk FbuDWClg6oQrkaR/VUyk/xVWL0Lr2GTZGHpT0lKgL7t8H+Cw73b8Cx3JHbNRv1XntRyF vfsSbOjDEU6GfVf51C88UFwBN5ZLinsRPc6K4= MIME-Version: 1.0 Received: by 10.141.20.6 with SMTP id x6mr1074845rvi.159.1234520076505; Fri, 13 Feb 2009 02:14:36 -0800 (PST) In-Reply-To: <497598ED.3050502@parrot.com> References: <497487F2.7070400@parrot.com> <497598ED.3050502@parrot.com> Date: Fri, 13 Feb 2009 19:14:36 +0900 Message-ID: Subject: Re: soc-camera : sh_mobile_ceu_camera race on free_buffer ? From: Magnus Damm To: Matthieu CASTET Cc: linux-media@vger.kernel.org, Guennadi Liakhovetski , Kuninori Morimoto Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Matthieu, [CC Morimoto-san] [Changed list to linux-media] On Tue, Jan 20, 2009 at 6:27 PM, Matthieu CASTET 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;