From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932865AbaLBM64 (ORCPT ); Tue, 2 Dec 2014 07:58:56 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:60664 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753363AbaLBM6z (ORCPT ); Tue, 2 Dec 2014 07:58:55 -0500 From: Laurent Pinchart To: Hans Verkuil Cc: Prabhakar Lad , linux-media , Hans Verkuil , Sakari Ailus , LKML , Sakari Ailus Subject: Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*() Date: Tue, 02 Dec 2014 14:59:29 +0200 Message-ID: <6626165.z9d655UICS@avalon> User-Agent: KMail/4.12.5 (Linux/3.16.5-gentoo; KDE/4.12.5; x86_64; ; ) In-Reply-To: <547DB631.3060309@xs4all.nl> References: <1416220913-5047-1-git-send-email-prabhakar.csengg@gmail.com> <547D6E20.7040406@xs4all.nl> <547DB631.3060309@xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans, On Tuesday 02 December 2014 13:53:05 Hans Verkuil wrote: > On 12/02/14 08:45, Hans Verkuil wrote: > > On 12/02/2014 12:26 AM, Laurent Pinchart wrote: > >> On Sunday 30 November 2014 21:30:35 Prabhakar Lad wrote: > >>> On Sun, Nov 30, 2014 at 9:16 PM, Laurent Pinchart wrote: > >>>> On Sunday 30 November 2014 21:05:50 Prabhakar Lad wrote: > >>>>> On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart wrote: > >>>>>> Hi Prabhakar, > >>>>> > >>>>> [Snip] > >>>>> > >>>>>>>> Sure. That's a better choice than removing the config option > >>>>>>>> dependency of the fields struct v4l2_subdev. > >>>>>> > >>>>>> Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the > >>>>>> in-kernel pad format and selection rectangles helpers is definitely a > >>>>>> good idea. I was thinking about decoupling the try format and > >>>>>> rectangles from v4l2_subdev_fh by creating a kind of configuration > >>>>>> store structure to store them, and embedding that structure in > >>>>>> v4l2_subdev_fh. The pad-level operations would then take a pointer to > >>>>>> the configuration store instead of the v4l2_subdev_fh. Bridge drivers > >>>>>> that want to implement TRY_FMT based on pad-level operations would > >>>>>> create a configuration store, use the pad-level operations, and > >>>>>> destroy the configuration store. The userspace subdev API would use > >>>>>> the configuration store from the file handle. > >>>>> > >>>>> are planning to work/post any time soon ? Or are you OK with > >>>>> suggestion from Hans ? > >>>> > >>>> I have no plan to work on that myself now, I was hoping you could > >>>> implement it ;-) > >>> > >>> OK will implement it. > >>> > >>> Can you please elaborate a more on this "The userspace subdev API would > >>> use the configuration store from the file handle." > >> > >> Basically, > >> > >> 1. Create a subdev pad configuration store structure to store the formats > >> and selection rectangles for each pad. > > > > I wouldn't call it a 'store'. Just call it fmt_config or pad_config > > something like that. Sure, the name doesn't matter too much. > >> 2. Embed an instance of that structure in v4l2_subdev_fh. > >> > >> 3. Modify the subdev pad ops to take a configuration store pointer > >> instead of a file handle pointer. > >> > >> The userspace API implementation (v4l2-subdev.c) would then pass > >> &fh->store to the pad operations instead of fh. > >> > >> Bridge drivers that need to implement TRY_FMT on top of pad ops would > >> create a temporary store (or temporary stores when multiple subsdevs are > >> involved), call the pad ops with a pointer to the temporary store to > >> propagate TRY formats, destroy the store(s) and return the resulting > >> format. > > > > That will work. I think this is a good approach and it shouldn't be too > > difficult. > > Laurent, just so I understand this correctly: does this mean that all > occurrences of 'struct v4l2_subdev_fh *fh' will be replaced by 'struct > v4l2_subdev_pad_config *cfg'? That's the plan, yes. > Is there any reason why the 'fh' should still be passed on? We might find out reasons to still pass the fh, but in that case I think they should be addressed and the fh just dropped from the pad ops arguments. > Personally I am in favor of this since the 'fh' always made it hard for > bridge drivers to use these pad ops. So if we can replace it by something > that can be used by bridge drivers as well, then that will make it easier > to move all drivers over to the pad ops. Good, looks like we have a plan for world domination :-) -- Regards, Laurent Pinchart