Received: by 10.192.165.148 with SMTP id m20csp285700imm; Fri, 20 Apr 2018 06:49:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+P5Wu4BmMc1Kte6IpP6S7GI9u68E8z7LGWmkHzfmy+VkIXtV5fTvnC7WQ152YKRhMgOcJT X-Received: by 2002:a17:902:189:: with SMTP id b9-v6mr8534308plb.204.1524232187641; Fri, 20 Apr 2018 06:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524232187; cv=none; d=google.com; s=arc-20160816; b=pTS4nkgMrbwa3YUFyv+FKELuNl78dXBAj62jieRn4gBSxNSuGfs5z4MX7TVHJHYcm2 zW5AZHoZ1WSSTr7Ll4IU1IdhzcwVZtjlQRPaQUPyq1o+M1dsMq2IopxJDm4UGgCbQXDn 8ctfffs/dqTWlk8lEGn5Wra5LbMbAbI99DabSIXxZdsXaD/AUF5ODFPurrWnode02LjS B1Bj/hzsm/Ouuj4TpRrvxZnF0G321RzqnCd/MSOmcXGV9LqPOeaaFdcrd62zeHNgFtQD 6GbemRp8SaMyb7YrBsjajVJoMAhGdG3xLI6VylRnFKUykACM1u5CzPK//Jdk+s7CoZuW Tjew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=9nyyLBOglsjZUyw8IqVinrmzvVqGNPYWXwKNE1qbuxk=; b=XNTLoAmgPe/YFdvRjK9ww64mmbf7T21F5/vjXhgifXlolo2g/BO7llN+QyJh13gX5U 2PRRSt1vHL0FJNoGgsPn//+t/EfO7SmwDVUUCyEET3Zh2QEDgR9VSOBogP010DjSHwsx yDxVXo1QDPNDtgAyweTOAfGbk5TS08aWX3DSJDt8OcETsPDqN8Qsg18P1cTmBJLet3td ZckM1YeXIFZPqc+6m6r7NDzvZTEmNK6GZMmu23poGHh9KE3c/bTWX6bIyiuoMxwKbSuo LNBrEubdhl7pCX8vEUstikrLu2uRC4ttowWFx5e8fEQfcN2erpnpXZghK5yxKYVMJEjf klHQ== 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 q22si2503304pfi.282.2018.04.20.06.49.32; Fri, 20 Apr 2018 06:49:47 -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 S1755141AbeDTNsS (ORCPT + 99 others); Fri, 20 Apr 2018 09:48:18 -0400 Received: from lb3-smtp-cloud9.xs4all.net ([194.109.24.30]:44894 "EHLO lb3-smtp-cloud9.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754899AbeDTNsQ (ORCPT ); Fri, 20 Apr 2018 09:48:16 -0400 Received: from [IPv6:2001:420:44c1:2579:b9bc:5629:432c:e3ba] ([IPv6:2001:420:44c1:2579:b9bc:5629:432c:e3ba]) by smtp-cloud9.xs4all.net with ESMTPA id 9WOZf0tyenprp9WOcf2XA5; Fri, 20 Apr 2018 15:48:15 +0200 Subject: Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling To: Paul Kocialkowski , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Cc: Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Maxime Ripard , Chen-Yu Tsai , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Hans Verkuil , Sakari Ailus , Philipp Zabel , Arnd Bergmann , Alexandre Courbot , Tomasz Figa References: <20180419154124.17512-1-paul.kocialkowski@bootlin.com> <20180419154124.17512-3-paul.kocialkowski@bootlin.com> From: Hans Verkuil Message-ID: <2bf8e1f2-796a-c25e-c8cf-8795ed55850a@xs4all.nl> Date: Fri, 20 Apr 2018 15:48:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20180419154124.17512-3-paul.kocialkowski@bootlin.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJjJ2JHMlJ6+uBzr66pQMO1xjtXTi0shi3Dlk9gNyPcMlHAVJa1Bq8I41KFHAnm/tflkxjwfLy9kUHKiJoDNy3Udp2G6ZPy0KRWGC9m+RI0t7eJsLIf7 6tZgkAwwl2coLPQ0Z2lsQivMTvlYvdJYnmgc6PkZXT+NC99TP8Voxk/oQJsl9ZlAhuI+zDv0vHmOsnyTWBnRO618YA/qvOHl5794joaPE6kZsLnSWlXj69n0 siemFfnKvvbohc5OtMBPBgX4w4WqmXoJl8mniMswIpuU+f87jSr/IgADhJHATvEd9cWDZmAbYu+Y6C17pvNDJYPEwNba0TqbGFtBZlyZPwq2Oec1zoCVHhin CkaX7/vk/dX0MBnZht4+M3stb7BRFG96PvP9EwMqNSGaNtw64Mq8db12931YW06YkiAAtMnoE2OgZryjjmZ5y3aub5cgeev54c783/mQjUlPRESlhw/QWbSA K9nL1JimJkaqmbc/NshK2pjQ7EBIvDWrrbsrGODQecjbmdIh8YEWCjQbIJFrg3JxSPAqLgz+SzNX6Q6JnECFh/bcr5QR2yXFlcV76Hsttn0do5F8b5zh+lJz lP251wy1HoR7kzC1f+1QNPUIYvsY+77DQx3GcJlUvCmMs+2w6krxbC7K+s3lKHF9tF+pthT0MBfr/wuV1A8Io+9fVscOGDK1HgRQpkSDb2jNqRZtDK+a7RW1 0HB02sbTYljCm0QCLd/G8ZhPXfuCHOaZ+yfhJTQPvX4Tyk2mqKIlmnJsUUQtnxkTKJbM3E26fcBJT55WUDlFHe4MyIm5mQ29A+GzsfOX0xo0ecjUPRq6c5hG 971VF7x/HoSgvQdOd3izY01XFaX8sye8kzlJv8HkINXC5j+X4SU4SG37HiDJoxzwwpfyLEoWxUsJrW6tVFUUeZzV07s5BJ8DiQlqbpnE9mYF2I8LOrQrBhEl 7Xu5+C9vpDifdJZ2cq6+KxLHmoXKCmecbgZkqpEp5UN2AaKRC3K48di8mHAh2NGID7/3ofgIGAn0lsdh6tPM9swxNxb7hJEQXdJV4LHnay4ir5lpTh5gO6f0 Z2GpMlnAIxqvD+SrxpsH+w38Ran9ZjNw5zJooBPbmsZyPquXDnBxjqGA Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/19/18 17:41, 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. I'll need to think about this a bit more. I understand the problem so something needs to be done. I would like to avoid adding yet another op, though. Regards, Hans > > 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); > }; > > /** >