Hi Hans, Em Mon, 21 Mar 2016 17:01:43 +0100 Hans Verkuil <hverkuil@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
