Hi Mauro,
On Monday 03 October 2011 21:06:14 Mauro Carvalho Chehab wrote:
> Em 03-10-2011 06:53, Javier Martinez Canillas escreveu:
> > On Mon, Oct 3, 2011 at 10:39 AM, Laurent Pinchart wrote:
> >> On Monday 03 October 2011 08:30:25 Hans Verkuil wrote:
> >>> On Monday, October 03, 2011 04:17:06 Mauro Carvalho Chehab wrote:
> >>>> Em 02-10-2011 18:18, Javier Martinez Canillas escreveu:
> >>>>> On Sun, Oct 2, 2011 at 6:30 PM, Sakari Ailus wrote:
> >> [snip]
> >>
> >>>>>>> static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
> >>>>>>>
> >>>>>>> .s_routing = tvp5150_s_routing,
> >>>>>>>
> >>>>>>> + .s_stream = tvp515x_s_stream,
> >>>>>>> + .enum_mbus_fmt = tvp515x_enum_mbus_fmt,
> >>>>>>> + .g_mbus_fmt = tvp515x_mbus_fmt,
> >>>>>>> + .try_mbus_fmt = tvp515x_mbus_fmt,
> >>>>>>> + .s_mbus_fmt = tvp515x_mbus_fmt,
> >>>>>>> + .g_parm = tvp515x_g_parm,
> >>>>>>> + .s_parm = tvp515x_s_parm,
> >>>>>>> + .s_std_output = tvp5150_s_std,
> >>>>>>
> >>>>>> Do we really need both video and pad format ops?
> >>>>>
> >>>>> Good question, I don't know. Can this device be used as a standalone
> >>>>> v4l2 device? Or is supposed to always be a part of a video streaming
> >>>>> pipeline as a sub-device with a source pad? Sorry if my questions are
> >>>>> silly but as I stated before, I'm a newbie with v4l2 and MCF.
> >>>>
> >>>> The tvp5150 driver is used on some em28xx devices. It is nice to add
> >>>> auto-detection code to the driver, but converting it to the media bus
> >>>> should be done with enough care to not break support for the existing
> >>>> devices.
> >>>
> >>> So in other words, the tvp5150 driver needs both pad and non-pad ops.
> >>> Eventually all non-pad variants in subdev drivers should be replaced by
> >>> the pad variants so you don't have duplication of ops. But that will
> >>> take a lot more work.
> >>
> >> What about replacing direct calls to non-pad operations with core V4L2
> >> functions that would use the subdev non-pad operation if available, and
> >> emulate if with the pad operation otherwise ? I think this would ease
> >> the transition, as subdev drivers could be ported to pad operations
> >> without worrying about the bridges that use them, and bridge drivers
> >> could be switched to the new wrappers with a simple search and replace.
> >
> > Ok, that is a good solution. I'll do that. Implement V4L2 core
> > operations as wrappers of the subdev pad operations.
>
> As I said, I can't see _any_ reason why setting a format would be needed
> at pad level. Patches shouldn't increase driver/core and userspace
> complexity for nothing.
Sorry ? We already have format setting at the pad level, and that's used by
drivers and applications. It's one key feature of the V4L2/MC API.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
