Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754425AbdLTJYn (ORCPT ); Wed, 20 Dec 2017 04:24:43 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:35510 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753863AbdLTJYk (ORCPT ); Wed, 20 Dec 2017 04:24:40 -0500 X-Google-Smtp-Source: ACJfBosGOtftWbUin3j6jRTDtkD+TyZABNy+T1wnVIqApeX/rDpwWK1MM4MYZ9ZffpUom5vIlri4Fg== MIME-Version: 1.0 In-Reply-To: <1513371751.3541.6.camel@ndufresne.ca> References: <20171215075625.27028-1-acourbot@chromium.org> <1513371751.3541.6.camel@ndufresne.ca> From: Alexandre Courbot Date: Wed, 20 Dec 2017 18:24:17 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/9] media: base request API support To: Nicolas Dufresne Cc: Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Pawel Osciak , Marek Szyprowski , Tomasz Figa , Sakari Ailus , Gustavo Padovan , Linux Media Mailing List , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id vBK9Omst032060 Content-Length: 2187 Lines: 41 On Sat, Dec 16, 2017 at 6:02 AM, Nicolas Dufresne wrote: > Le vendredi 15 décembre 2017 à 16:56 +0900, Alexandre Courbot a écrit : >> Here is a new attempt at the request API, following the UAPI we agreed on in >> Prague. Hopefully this can be used as the basis to move forward. >> >> This series only introduces the very basics of how requests work: allocate a >> request, queue buffers to it, queue the request itself, wait for it to complete, >> reuse it. It does *not* yet use Hans' work with controls setting. I have >> preferred to submit it this way for now as it allows us to concentrate on the >> basic request/buffer flow, which was harder to get properly than I initially >> thought. I still have a gut feeling that it can be improved, with less back-and- >> forth into drivers. >> >> Plugging in controls support should not be too hard a task (basically just apply >> the saved controls when the request starts), and I am looking at it now. >> >> The resulting vim2m driver can be successfully used with requests, and my tests >> so far have been successful. >> >> There are still some rougher edges: >> >> * locking is currently quite coarse-grained >> * too many #ifdef CONFIG_MEDIA_CONTROLLER in the code, as the request API >> depends on it - I plan to craft the headers so that it becomes unnecessary. >> As it is, some of the code will probably not even compile if >> CONFIG_MEDIA_CONTROLLER is not set >> >> But all in all I think the request flow should be clear and easy to review, and >> the possibility of custom queue and entity support implementations should give >> us the flexibility we need to support more specific use-cases (I expect the >> generic implementations to be sufficient most of the time though). >> >> A very simple test program exercising this API is available here (don't forget >> to adapt the /dev/media0 hardcoding): >> https://gist.github.com/Gnurou/dbc3776ed97ea7d4ce6041ea15eb0438 > > It looks like the example uses Hans control work you just mention. > Notably, it uses v4l2_ext_controls ctrls.request. Oops, I indeed forgot to remove that bit. You will want to edit that line out if trying to compile.