Re: [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Hi Hans,

Em Mon, 21 Mar 2016 17:01:43 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> > A reasonable solution to simplify converting legacy drivers without creating
> > these global ugly pad indices is to add a new video (and probably audio) op
> > 'g_pad_of_type(type)' where you ask the subdev entity to return which pad carries
> > signals of a certain type.  
> 
> This basically puts a layer between the low-level pads as defined by the entity
> and the 'meta-pads' that a generic MC link creator would need to handle legacy
> drivers. The nice thing is that this is wholly inside the kernel so we can
> modify it at will later without impacting userspace.

I prepared a long answer to your email, but I guess we're not at the
same page.

Let be clear on my view. Please let me know where you disagree:

1) I'm not defending Javier's patchset. I have my restrictions to
it too. My understanding is that he sent this as a RFC for feeding
our discussions for the media summit.

Javier, please correct me if I'm wrong.

2) I don't understand what you're calling as "meta-pads". For me, a
PAD is a physical set of pins. 

3) IMO, the best is to have just one PAD for a decoder input. That makes
everything simple, yet functional.

In my view, the input PAD will be linked to several "input connections".
So, in the case of tvp5150, it will have:

	- composite 1
	- composite 2
	- s-video

4) On that view, the input PAD is actually a set of pins. In the
case of tvp5150, the pins that compose the input PADs are
AIP1A and AIP1B.

The output PAD is also a set of pins YOUT0 to YOUT7, plus some other
pins for sync. Yet, it should, IMHO, have just one output PAD at
the MC graph.

-- 
Thanks,
Mauro