-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
Sent: Tuesday, September 27, 2011 11:36 PM
To: Hiremath, Vaibhav
Cc: Ravi, Deepthy; linux-media at vger.kernel.org; tony at atomide.com;
linux at arm.linux.org.uk; linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
mchehab at infradead.org; g.liakhovetski at gmx.de
Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

Hi Vaibhav,

On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:

quoted

On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:

quoted

On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:

quoted

On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:

quoted

On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:

quoted

From: Vaibhav Hiremath <redacted>

In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.

Why so ? Shouldn't it be queried on the subdev output pad

directly ?

quoted

quoted

quoted

Because standard v4l2 application for analog devices will call these
std ioctls on the streaming device node. So it's done on /dev/video

to

quoted

quoted

quoted

make the existing apllication work.

Existing applications can't work with the OMAP3 ISP (and similar

complex

quoted

quoted

embedded devices) without userspace support anyway, either in the form

of

quoted

quoted

a GStreamer element or a libv4l plugin. I still believe that analog

video

quoted

quoted

standard operations should be added to the subdev pad operations and
exposed through subdev device nodes, exactly as done with formats.

I completely agree with your point that, existing application will not

work

quoted

without setting links properly. But I believe the assumption here is,
media-controller should set the links (along with pad formants) and all
existing application should work as is. Isn't it?

The media controller is an API used (among other things) to set the links.
You
still need to call it from userspace. That won't happen magically. The
userspace component that sets up the links and configures the formats, be
it a
GStreamer element, a libv4l plugin, or something else, can as well setup
the
standard on the TVP5146 subdev.

Please look at from analog device point of view which is interfaced to ISP.

OMAP3 ISP => TVP5146 (video decoder)

As a user I would want to expect the standard to be supported on streaming device node, since all standard streaming applications (for analog devices/interfaces) does this.

Setting up the links and format is still something got added with MC framework, and I would consider it as a separate plug-in along with existing applications.

Why do I need to write/use two different streaming application one for MC compatible device and another for non-MC?

quoted

The way it is being done currently is, set the format at the pad level
which is same as analog standard resolution and use existing application
for streaming...

At then end of the OMAP3 ISP pipeline video data has long lost its analog
roots. I don't think standards make sense there.

I don't agree with you here, I think we made it clear when we started with MC development activity, we will not break existing standard applications. Media-controller will play a roll to setup the links, connecting the pads and stuff.


Thanks,
Vaibhav

quoted

I am ok, if we add s/g/enum_std api support at sub-dev level but this
should also be supported on streaming device node.

--
Regards,

Laurent Pinchart