Hi Hans,
Em Mon, 21 Mar 2016 17:01:43 +0100
Hans Verkuil <hverk...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
