Em Tue, 31 Jul 2018 10:52:56 +0200
Javier Martinez Canillas <javierm@xxxxxxxxxx> escreveu:
> Hello Mauro,
>
> On 07/30/2018 08:18 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 28 Jun 2018 18:20:50 +0200
> > Marco Felsch <m.felsch@xxxxxxxxxxxxxx> escreveu:
> >
> >> From: Javier Martinez Canillas <javierm@xxxxxxxxxx>
> >>
> >> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> >> added input signals support for the tvp5150, but the approach was found
> >> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> >> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> >>
> >> This left the driver with an undocumented (and wrong) DT parsing logic,
> >> so lets get rid of this code as well until the input connectors support
> >> is implemented properly.
> >>
> >> It's a partial revert due other patches added on top of mentioned commit
> >> not allowing the commit to be reverted cleanly anymore. But all the code
> >> related to the DT parsing logic and input entities creation are removed.
> >>
> >> Suggested-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> >> Signed-off-by: Javier Martinez Canillas <javierm@xxxxxxxxxx>
> >> Acked-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> >> [m.felsch@xxxxxxxxxxxxxx: rm TVP5150_INPUT_NUM define]
> >> Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
> >> ---
> >
> > ...
> >
> >> -static int tvp5150_registered(struct v4l2_subdev *sd)
> >> -{
> >> -#ifdef CONFIG_MEDIA_CONTROLLER
> >> - struct tvp5150 *decoder = to_tvp5150(sd);
> >> - int ret = 0;
> >> - int i;
> >> -
> >> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> >> - struct media_entity *input = &decoder->input_ent[i];
> >> - struct media_pad *pad = &decoder->input_pad[i];
> >> -
> >> - if (!input->name)
> >> - continue;
> >> -
> >> - decoder->input_pad[i].flags = MEDIA_PAD_FL_SOURCE;
> >> -
> >> - ret = media_entity_pads_init(input, 1, pad);
> >> - if (ret < 0)
> >> - return ret;
> >> -
> >> - ret = media_device_register_entity(sd->v4l2_dev->mdev, input);
> >> - if (ret < 0)
> >> - return ret;
> >> -
> >> - ret = media_create_pad_link(input, 0, &sd->entity,
> >> - DEMOD_PAD_IF_INPUT, 0);
> >> - if (ret < 0) {
> >> - media_device_unregister_entity(input);
> >> - return ret;
> >> - }
> >> - }
> >> -#endif
> >
> > Hmm... I suspect that reverting this part may cause problems for drivers
> > like em28xx when compiled with MC, as they rely that the supported demods
> > will have 3 pads (DEMOD_NUM_PADS).
> >
>
> I don't see how this change could affect em28xx and other drivers. The function
> tvp5150_registered() being removed here, only register the media entity and add
> a link if input->name was set. This is set in tvp5150_parse_dt() and only if a
> input connector as defined in the Device Tree file.
>
> In other words, all the code removed by this patch is DT-only and isn't used by
> any media driver that makes use of the tvp5151.
>
> As mentioned in the commit message, this code has never been used (besides from
> my testings) and should had been removed when the DT binding was reverted, but
> for some reasons the first patch landed and the second didn't at the time.
Short answer:
Yeah, you're right. Yet, patch 19/22 will cause regressions.
Long answer:
That's easy enough to test.
Without this patch, a em28xx-based board (Terratec Grabster AV350) reports:
$ ./mc_nextgen_test -D
digraph board {
rankdir=TB
colorscheme=x11
labelloc="t"
label="Grabster AV 350
driver:em28xx, bus: usb-0000:00:14.0-2
"
intf_devnode_7 [label="intf_devnode_7\nvideo\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
intf_devnode_10 [label="intf_devnode_10\nvbi\n/dev/vbi0", shape=box, style=filled, fillcolor=yellow]
entity_1 [label="{{<pad_2> 0} | entity_1\nATV decoder\ntvp5150 0-005c | {<pad_3> 1 | <pad_4> 2}}", shape=Mrecord, style=filled, fillcolor=lightblue]
entity_6 [label="{{<pad_12> 0} | entity_6\nV4L I/O\n2-2:1.0 video}", shape=Mrecord, style=filled, fillcolor=aquamarine]
entity_9 [label="{{<pad_13> 0} | entity_9\nVBI I/O\n2-2:1.0 vbi}", shape=Mrecord, style=filled, fillcolor=aquamarine]
entity_14 [label="{entity_14\nunknown entity type\nComposite | {<pad_15> 0}}", shape=Mrecord, style=filled, fillcolor=cadetblue]
entity_16 [label="{entity_16\nunknown entity type\nS-Video | {<pad_17> 0}}", shape=Mrecord, style=filled, fillcolor=cadetblue]
intf_devnode_7 -> entity_6 [dir="none" color="orange"]
intf_devnode_10 -> entity_9 [dir="none" color="orange"]
entity_1:pad_3 -> entity_6:pad_12 [color=blue]
entity_1:pad_4 -> entity_9:pad_13 [color=blue]
entity_14:pad_15 -> entity_1:pad_2 [color=blue]
entity_16:pad_17 -> entity_1:pad_2 [color=blue style="dashed"]
}
tvp5150 reports 3 pads (one input, two output pads), and media core
properly connects the source pads.
With patch 18/22, I got the same graph. So, yeah, applying this patch
won't cause regressions.
However, when we apply patch 19/22:
$ mc_nextgen_test -D
digraph board {
rankdir=TB
colorscheme=x11
labelloc="t"
label="Grabster AV 350
driver:em28xx, bus: usb-0000:00:14.0-2
"
intf_devnode_7 [label="intf_devnode_7\nvideo\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
intf_devnode_10 [label="intf_devnode_10\nvbi\n/dev/vbi0", shape=box, style=filled, fillcolor=yellow]
entity_1 [label="{{<pad_2> 0 | <pad_3> 1 | <pad_4> 2} | entity_1\nATV decoder\ntvp5150 0-005c | {<pad_5> 3}}", shape=Mrecord, style=filled, fillcolor=lightblue]
entity_6 [label="{{<pad_12> 0} | entity_6\nV4L I/O\n2-2:1.0 video}", shape=Mrecord, style=filled, fillcolor=aquamarine]
entity_9 [label="{{<pad_13> 0} | entity_9\nVBI I/O\n2-2:1.0 vbi}", shape=Mrecord, style=filled, fillcolor=aquamarine]
entity_14 [label="{entity_14\nunknown entity type\nComposite | {<pad_15> 0}}", shape=Mrecord, style=filled, fillcolor=cadetblue]
entity_16 [label="{entity_16\nunknown entity type\nS-Video | {<pad_17> 0}}", shape=Mrecord, style=filled, fillcolor=cadetblue]
intf_devnode_7 -> entity_6 [dir="none" color="orange"]
intf_devnode_10 -> entity_9 [dir="none" color="orange"]
entity_1:pad_3 -> entity_6:pad_12 [color=blue]
entity_1:pad_4 -> entity_9:pad_13 [color=blue]
entity_14:pad_15 -> entity_1:pad_2 [color=blue]
entity_16:pad_17 -> entity_1:pad_2 [color=blue style="dashed"]
}
The graph is not built correct, as it is linking tvp5150's input pads as
if they were output ones.
The problem is that now you need to teach drivers/media/v4l2-core/v4l2-mc.c
to do the proper wiring for tvp5150.
I suspect that fixing v4l2-mc for doing that is not hard, but it may
require changes at the other demods. Thankfully there aren't many
demod drivers, but such patch should be applied before patch 19/22.
In the specific case of demods that don't support sliced VBI (or
where sliced VBI is not coded), there should be just one source pad.
On demods with sliced VBI, there are actually two source pads,
although, for simplicity, maybe we could map them as just one.
If we map as just one source pad, it is probably easy to change the
code at v4l2-mc to do the right thing.
I'll do some tests here and try to code it.
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
