Hi all, In 2016, we had lots of discussions among the top media developers with regards to connectors and DT bindings. On that time, we didn't reach a final conclusion. We recently received a patchset from Marco changing how tvp5150 driver works, adding a new DT binding proposal: https://patchwork.linuxtv.org/patch/50648/ So, yesterday we did another round in order to try to reach some consensus among the core developers. The goal of this RFC is to summarize the consensus we reached, asking the community to provide us feedback, in order for us to improve the subsystem support for connectors. The entire discussion can be seen at: https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-08-02,Thu Exceptionally, this time we did the discussions at the media maintainer's channel, because #v4l was to noisy with lots of spam being flooded there. Thanks, Mauro 1. Description of the problem ============================= In 2015, we had the first media controller workshop and we added support for new stuff at the media controller side. One of the points agreed there is that connectors should be represented at the media graph. In 2016, we had several discussions about how to properly represent connectors, like, for example: - https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-26,Fri - https://linuxtv.org/irc/irclogger_log/v4l?date=2016-03-03,Thu On that time, the consensus was that connectors should be describing the logical connections, as physically sometimes a single connector (like SCART) can bring several different signals inside, each being routed to a different entity or pad. However, we didn't finish the discussions. On today's meeting, we came with the challenge of answering two questions: (a) should a physical connector that internally comes with two separate electric signals (like S-Video) be mapped as a single connector? (b) what would be the proper way to describe a device like tvp5150, with has internally a MUX that selects between 3 different possible physical connectors (composite 0, composite 1, s-video), mapping them into 2 electrical pins (AIP1A and AIP1B) and the decoder itself can handle just one signal, e. g., physically, the hardware is: "physical" pin input internal connectors terminals input port comp 0 ------\ + ------> AIP1A ----> \ +-----+ +----/ pin \--> | | | luma | | s-video-+ | MUX +---> video decoder | chroma | | +-----\ /--> | | + -----> AIP1B ----> / +-----+ comp 1 -------/ pin So, depending on how the device is seemed, it could have 3, 2 or 1 media controller pads and 3, 2 or 1 Device tree ports. 2. Answers for the questions ============================ question (a): S-Video is a connector? -------------_----------------------- During the discussion, Hans came with a similar problem on a hardware he works with (SX80 telepresence codec). This hardware has: - 3 HDMI inputs; - 1 DVI-I input; - 2 RCA inputs (either two composite or combines to one S-Video); - 2 HDMI outputs; - 1 DVI-I output. The DVI-I mapping is also a challenge, as it can carry either an analog or a digital signal (or both). On this specific hardware, if one wants to use S-Video, it needs a cable with one miniDin 4-pin in one side and 2 RCA pins at the other side. It was also discussed about the properties API, with would allow adding labels to each connector. It was a consensus that the best way to map S-Video is to be a single connector. So, on a hardware like SX80, for example, the properties API could carry a description like: comp0: -> "RCA Y Plug" comp1 -> "RCA C Plug" s-video -> "RCA Y+C Plugs" question (b): how many MC PADs and DT ports tvp5150 should have? ---------------------------------------------------------------- That was the warmer discussion, as we started with 3 different opinions: - Mauro would map at the output of the mux, e. g. 1 pad/port; - Marco proposed on his patchset to use (up to) 3 pad/ports, e. g. at the "physically" visible connectors[1]; - Laurent would map as 2, e. g. at the two physical pins at the tvp5150 chip. [1] That's actually not true physical connectors - as the connectors are device-specific. For example the device I'm using for tests is a Terratec Grabster AV-350. It have one SCART connector with both composite and S-Video signals, a S-Video port and 3 connectors for composite (video, audio R, audio L) and a mechanical switch (labeled Video/Scart) with selects between the SCART connector and the 4 other ones; After some discussions, we reached a consensus that mapping it at the tvp5150 chip pin level - e. g. two pads/ports (AIP1A and AIP1B) is the best model, as it allows more flexibility in the case where the chipset would allow switching s-video luma and croma electrical signals among two separate input pins. Its is also the only way to represent the chip's physical inputs. One point that come to us is that, on such case, it could make sense to map the connector itself as having 2 pads/ports. We ended by agreeing that, for nowadays usage, just one pad/port is enough for S-Video. So, for a device like tvp-5150, the DT binding maps should be: tvp-5150 port@0 (AIP1A) endpoint@0 -----------> Comp0-Con port endpoint@1 -----+-----> Svideo-Con port tvp-5150 port@1 (AIP1B) | endpoint@1 -----+ endpoint@0 -----------> Comp1-Con port tvp-5150 port@2 endpoint (video bitstream output at YOUT[0-7] parallel bus) Yet, for more complex devices that would allow switching the endpoints at the Svideo connector, the model would be: device's port@0 input pin 1 endpoint@0 -----------> Comp0-Con port endpoint@1 -----------> Svideo-Con port@0 (luminance) device's port@1 input pin 2 endpoint@0 -----------> Comp1-Con port endpoint@1 -----------> Svideo-Con port@1 (chrominance) device's port@2 bitstream output pin(s) endpoint Comments? Regards, 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
