Re: [PATCH] omap3isp: implement ENUM_FMT

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

Hans Verkuil wrote:
> On Thursday, March 24, 2011 08:28:31 Michael Jones wrote:
>> Hi Laurent,
>>
>> On 03/23/2011 01:16 PM, Laurent Pinchart wrote:
>>> Hi Michael,
>>>
>> [snip]
>>>>
>>>> Is there a policy decision that in the future, apps will be required to
>>>> use libv4l to get images from the ISP?  Are we not intending to support
>>>> using e.g. media-ctl + some v4l2 app, as I'm currently doing during
>>>> development?
>>>
>>> Apps should be able to use the V4L2 API directly. However, we can't implement 
>>> all that API, as most calls don't make sense for the OMA3 ISP driver. Which 
>>> calls need to be implemented is a grey area at the moment, as there's no 
>>> detailed semantics on how subdev-level configuration and video device 
>>> configuration should interact.
> 
> We definitely need to discuss this in the near future. It's indeed a grey
> area at the moment that needs to be clarified.

I fully agree.

>>> Your implementation of ENUM_FMT looks correct to me, but the question is 
>>> whether ENUM_FMT should be implemented. I don't think ENUM_FMT is a required 
>>> ioctl, so maybe v4l2src shouldn't depend on it. I'm interesting in getting 
>>> Hans' opinion on this.
>>>
>>
>> I only implemented it after I saw that ENUM_FMT _was_ required by V4L2.
>>  From http://v4l2spec.bytesex.org/spec/x1859.htm#AEN1894 :
>> "The VIDIOC_ENUM_FMT ioctl must be supported by all drivers exchanging
>> image data with applications."
> 
> If you can call S_FMT on a device node, then you also have to implement
> ENUM_FMT.

I think the issue here is that it's not possible (or feasible) to
implement ENUM_FMT in a way applications would obtain the information
they're interested in. Available pixel formats are dictated by the
formats on links (validation must be done first in a generic case!) and
in the case of OMAP 3 ISP there's always just one.

S_FMT and TRY_FMT behave more or less the way applications like. The
pixelformat or size may not change, though, and this information is also
used to prepare the buffers.

> I am assuming applications need to call S_FMT for omap3 video nodes, right?
> Because that defines the result of the DMA engine. Or is the result always
> fixed, based on the current pipeline configuration? In the latter case I
> would still expect to see an ENUM_FMT, but one that just returns the current
> format. And S/TRY_FMT would also return the current format.

There are some options in the format that is not defined by the
v4l2_mbus_pixelcode already. Padding is such and I don't think there
should be anything else than that since the v4l2_mbus_pixelcode
conversion and scaling takes places in the subdevs. Laurent? :-)

Cheers,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com