From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>,
<linux-media@vger.kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum
Date: Mon, 21 Mar 2016 15:23:23 -0300 [thread overview]
Message-ID: <20160321152323.01e29553@recife.lan> (raw)
In-Reply-To: <56F038A0.1010004@xs4all.nl>
Em Mon, 21 Mar 2016 19:08:32 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 03/21/2016 06:50 PM, Mauro Carvalho Chehab wrote:
> > 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.
>
> Poorly worded on my side. I'll elaborate below.
>
> > 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.
>
> Indeed. So a tvp5150 has three sink pads and one source pad (pixel port).
I would actually map tvp5150 with just one sink pad, with 3 links
(one for each connector).
In other words, I'm mapping tvp5150 input mux via links, and the
output of its mux as the sink pad.
IMHO, this works a way better than one sink pad per input at its
internal mux.
Regards,
Mauro
next prev parent reply other threads:[~2016-03-21 18:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 19:09 [RFC PATCH 0/3] [media] tvp515p: Proposal for MC input connector support Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum Javier Martinez Canillas
2016-03-18 15:45 ` Hans Verkuil
2016-03-18 17:33 ` Hans Verkuil
2016-03-21 14:40 ` Mauro Carvalho Chehab
2016-03-21 15:05 ` Hans Verkuil
2016-03-21 16:01 ` Hans Verkuil
2016-03-21 17:50 ` Mauro Carvalho Chehab
2016-03-21 18:08 ` Hans Verkuil
2016-03-21 18:23 ` Mauro Carvalho Chehab [this message]
2016-03-21 18:48 ` Hans Verkuil
2016-03-21 18:24 ` Javier Martinez Canillas
2016-03-21 18:34 ` Mauro Carvalho Chehab
2016-03-21 18:38 ` Javier Martinez Canillas
2016-03-21 18:51 ` Hans Verkuil
2016-03-21 19:06 ` Hans Verkuil
2016-03-21 19:20 ` Javier Martinez Canillas
2016-03-21 19:30 ` Hans Verkuil
2016-03-21 19:48 ` Javier Martinez Canillas
2016-03-21 21:15 ` Mauro Carvalho Chehab
2016-03-22 0:22 ` Javier Martinez Canillas
2016-03-21 21:20 ` Mauro Carvalho Chehab
2016-03-22 0:16 ` Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 2/3] [media] tvp5150: Add input connectors DT bindings Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 3/3] [media] tvp5150: Replace connector support according to DT binding Javier Martinez Canillas
2016-03-18 15:01 ` [RFC PATCH 0/3] [media] tvp515p: Proposal for MC input connector support Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160321152323.01e29553@recife.lan \
--to=mchehab@osg.samsung.com \
--cc=hans.verkuil@cisco.com \
--cc=hverkuil@xs4all.nl \
--cc=javier@osg.samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shuahkh@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.