Received: by 10.192.165.148 with SMTP id m20csp4488791imm; Tue, 24 Apr 2018 03:44:01 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+gQiWobXJM5njo0FlzcbTyhNaxHQNj4UTbPTg47yXbw6VGkFaOzF4liSZohGN65aeOPDmP X-Received: by 10.98.10.72 with SMTP id s69mr23098865pfi.134.1524566641613; Tue, 24 Apr 2018 03:44:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524566641; cv=none; d=google.com; s=arc-20160816; b=bxBM7q86be8nifGEZYLi6gB/oNly7ArFqLmkfeHa+BahcvbpV5IACi1ADWlj7etK3V H+NNdqJjjZsxAkJujYeU8ORFRtyT9SiOD5fXhlT0XTJ+IyHH5aUzNwyC3s0UCbBnOdOZ 8kLYlslM4nrbJCC/BaQB4r2d9onXKkC7IRPCAkmbEELrx3Z7LArKz8k5P8YPV55hdIx4 aqZD2gitooeGf6PBEo97dN81ZNyeuyOy5hf/HZ2OriZH9ObJSPhe6Qmg+KiQVO0LcjMj dfHdlUaPT28cdZBPzGpGM2kUAnZ6WiLA2h4eR08QvG1p63hxiBGbmfgkpNGaZmrt+bfH 1L1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DECt2SHbzVbuyqNfCLHNAkDUXy3YmkStETjTSDy5V6I=; b=EgDIeGni07Ds81xDjk8I75qh1Ef8YOcl2jdBqfn2vGT1KXo2VZsGMXjZN9jlKh5LkT IgwGbeGJrTY34J8Q2HmJWucbiSXWn0KQavcZ03xLSxqY5k0QZNdZmEBi5JhToavm8dg8 Xpx6oE68S/4sc8ykJPNN1JvIDJ1+3UpvLCcZ9gpXQiLBwjRPFETRYIi1ohILaOg+GCYR w+kv98r5D6F4ZNJxc3F2YotdhvqtmMoy5W7d2jenhKwdxZh/VLp4/pxX3cXebSU4hmM/ s2zcbWP9ptiKeBWzFoChjuw1wHcK69REjSbKtYIKTMYFA0i8qrJqYd/86jarlU6ZK7fb h1Pg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f95-v6si11984216plb.401.2018.04.24.03.43.47; Tue, 24 Apr 2018 03:44:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756871AbeDXI2o (ORCPT + 99 others); Tue, 24 Apr 2018 04:28:44 -0400 Received: from mga05.intel.com ([192.55.52.43]:31745 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756144AbeDXI2i (ORCPT ); Tue, 24 Apr 2018 04:28:38 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 01:28:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,321,1520924400"; d="scan'208";a="34818586" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga008.fm.intel.com with ESMTP; 24 Apr 2018 01:28:33 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 5884A2050A; Tue, 24 Apr 2018 11:28:32 +0300 (EEST) Date: Tue, 24 Apr 2018 11:28:32 +0300 From: Sakari Ailus To: Paul Kocialkowski Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Maxime Ripard , Chen-Yu Tsai , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Hans Verkuil , Philipp Zabel , Arnd Bergmann , Alexandre Courbot , Tomasz Figa Subject: Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling Message-ID: <20180424082831.zfgzuvnop6md4iyf@paasikivi.fi.intel.com> References: <20180419154124.17512-1-paul.kocialkowski@bootlin.com> <20180419154124.17512-3-paul.kocialkowski@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180419154124.17512-3-paul.kocialkowski@bootlin.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, On Thu, Apr 19, 2018 at 05:41:16PM +0200, Paul Kocialkowski wrote: > When using the request API in the context of a m2m driver, the > operations that come with a m2m run scheduling call in their > (m2m-specific) ioctl handler are delayed until the request is queued > (for instance, this includes queuing buffers and streamon). > > Thus, the m2m run scheduling calls are not called in due time since the > request AP's internal plumbing will (rightfully) use the relevant core > functions directly instead of the ioctl handler. > > This ends up in a situation where nothing happens if there is no > run-scheduling ioctl called after queuing the request. > > In order to circumvent the issue, a new media operation is introduced, > called at the time of handling the media request queue ioctl. It gives > m2m drivers a chance to schedule a m2m device run at that time. > > The existing req_queue operation cannot be used for this purpose, since > it is called with the request queue mutex held, that is eventually needed > in the device_run call to apply relevant controls. Based on the description I'm not entirely sure what's the intent here. What would be the purpose for acquiring the request queue mutex during the execution of the request? It is only intended for serialising access to the request objects while the request is being validated and queued. If a driver does a significant amount of processing that is not related to managing the request as such, then one option could be to add a work queue for it. > > Signed-off-by: Paul Kocialkowski > --- > drivers/media/media-request.c | 3 +++ > include/media/media-device.h | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c > index 415f7e31019d..28ac5ccfe6a2 100644 > --- a/drivers/media/media-request.c > +++ b/drivers/media/media-request.c > @@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct media_request *req) > media_request_get(req); > } > > + if (mdev->ops->req_complete) > + mdev->ops->req_complete(req); > + > return ret; > } > > diff --git a/include/media/media-device.h b/include/media/media-device.h > index 07e323c57202..c7dcf2079cc9 100644 > --- a/include/media/media-device.h > +++ b/include/media/media-device.h > @@ -55,6 +55,7 @@ struct media_entity_notify { > * @req_alloc: Allocate a request > * @req_free: Free a request > * @req_queue: Queue a request > + * @req_complete: Complete a request > */ > struct media_device_ops { > int (*link_notify)(struct media_link *link, u32 flags, > @@ -62,6 +63,7 @@ struct media_device_ops { > struct media_request *(*req_alloc)(struct media_device *mdev); > void (*req_free)(struct media_request *req); > int (*req_queue)(struct media_request *req); > + void (*req_complete)(struct media_request *req); > }; > > /** > -- > 2.16.3 > -- Sakari Ailus sakari.ailus@linux.intel.com