Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Prabhakar,

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.

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.

Is that clear ?

-- 
Regards,

Laurent Pinchart