Re: [RFC] omap3-isp G_FMT & ENUM_FMT

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

On Friday 27 July 2012 11:07:50 Michael Jones wrote:
> Hi Laurent,
> 
> On 07/27/2012 01:32 AM, Laurent Pinchart wrote:
> > Hi Michael,
> > 
> > On Thursday 26 July 2012 16:22:17 Michael Jones wrote:
> >> On 07/26/2012 04:05 PM, Laurent Pinchart wrote:
> >>> On Thursday 26 July 2012 13:59:54 Michael Jones wrote:
> >>>> Hello,
> >>>> 
> >>>> I would like to (re)submit a couple of patches to support V4L2 behavior
> >>>> at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they
> >>>> require some discussion first.
> >>> 
> >>> Indeed.
> >>> 
> >>> The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it
> >>> does today is to hack around a restriction in the V4L2 API. We needed a
> >>> way to preallocate and possibly prequeue buffers for snapshot, which
> >>> wasn't possible in a standard-compliant way back then.
> >>> 
> >>> The situation has since changed, and we now have the VIDIOC_CREATE_BUFS
> >>> and VIDIOC_PREPARE_BUF ioctls. My plan is to
> >>> 
> >>> - port the OMAP3 ISP driver to videobuf2
> >>> - implement support for CREATE_BUFS and PREPARE_BUF
> >>> - fix the G_FMT/S_FMT/ENUM_FMT behaviour
> >> 
> >> What will the G_FMT/S_FMT/ENUM_FMT behavior be then?  Can you contrast
> >> it with the behavior of my patches?  If the behavior will be the same
> >> for user space, and your proposed changes won't be in very soon, can we
> >> use my patches until you make your changes?
> > 
> > At the moment the driver accepts any format you give it in a S_FMT call,
> > regardless of the format of the connected pad. The reason for that is to
> > allow VIDIOC_REQBUFS to allocate buffers for an arbitrary size.
> > 
> > With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT
> > should return the format of the connected pad.
> 
> OK, so this sounds like the same behavior I'd like to add before
> CREATE_BUFS and PREPARE_BUFS support is in.  My other question was if
> this is the case, can we use my approach until your planned changes are in?

We can't, as it would break the use case of preallocating buffers without 
providing any alternative solution. That's why I haven't fixed the 
G_FMT/S_FMT/ENUM_FMT issue yet.

-- 
Regards,

Laurent Pinchart