On 28/02/14 17:59, Russell King - ARM Linux wrote:

...

+dvi0: connector@0 {

• compatible = "dvi-connector";
• label = "dvi";
• i2c-bus = <&i2c3>;
• dvi_connector_in: endpoint {

• remote-endpoint = <&tfp410_out>;
  

• };

+};

This looks far too simplistic. There are different classes of DVI connector - there is:

DVI A - analogue only DVI D - digital only (single and dual link) DVI I - both (single and dual digital link)

DRM at least makes a distinction between these three classes, and this disctinction is part of the user API. How would a display system know which kind of DVI connector is wired up on the board from this DT description?

Yes, I think that's a valid change. But do we also need to specify single/dual link, in addition to the three types?

I guess the compatible string is the easiest way for differentation, at least for the three main types, i.e. "dvi-d-connector" etc.

"dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link? That looks a bit funny.

Tomi

On Feb 28, 2014, at 9:23 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:

On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:

...

On 28/02/14 17:59, Russell King - ARM Linux wrote:

...

...

+dvi0: connector@0 {

• compatible = "dvi-connector";
• label = "dvi";
• i2c-bus = <&i2c3>;
• dvi_connector_in: endpoint {

• remote-endpoint = <&tfp410_out>;
  

• };

+};

This looks far too simplistic. There are different classes of DVI connector - there is:

DVI A - analogue only DVI D - digital only (single and dual link) DVI I - both (single and dual digital link)

DRM at least makes a distinction between these three classes, and this disctinction is part of the user API. How would a display system know which kind of DVI connector is wired up on the board from this DT description?

Yes, I think that's a valid change. But do we also need to specify single/dual link, in addition to the three types?

I would argue that as it's a difference in physical hardware, then it should be described in DT, even if we don't use it. The reasoning is that although we may not use it today, we may need to use it in the future, and as we're describing what the hardware actually is - and even in this case what pins may be present or missing on the connector, it's unlikely to be problematical (the only problem is when someone omits it...)

And the “we” that uses the DT files is larger than just the Linux, and one of those systems may use it.

Warner

On Fri, Feb 28, 2014 at 04:23:27PM +0000, Russell King - ARM Linux wrote:

On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:

...

On 28/02/14 17:59, Russell King - ARM Linux wrote:

...

...

+dvi0: connector@0 {

• compatible = "dvi-connector";
• label = "dvi";
• i2c-bus = <&i2c3>;
• dvi_connector_in: endpoint {

• remote-endpoint = <&tfp410_out>;
  

• };

+};

This looks far too simplistic. There are different classes of DVI connector - there is:

DVI A - analogue only DVI D - digital only (single and dual link) DVI I - both (single and dual digital link)

DRM at least makes a distinction between these three classes, and this disctinction is part of the user API. How would a display system know which kind of DVI connector is wired up on the board from this DT description?

Yes, I think that's a valid change. But do we also need to specify single/dual link, in addition to the three types?

I would argue that as it's a difference in physical hardware, then it should be described in DT, even if we don't use it. The reasoning is that although we may not use it today, we may need to use it in the future, and as we're describing what the hardware actually is - and even in this case what pins may be present or missing on the connector, it's unlikely to be problematical (the only problem is when someone omits it...)

If you plug a dual-link dvi screen into a soc which can do dual-link but the actual connector is cheap and doesn't have this wired up (differentiate wtf) then the kernel needs to know. Otherwise it can't correctly filter out the modes with dotclocks high enough to require dual link and the user will look at a black screen.

3.14 has a regression in drm/i915 where we've screwed this up ;-) -Daniel

On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:

On 28/02/14 17:59, Russell King - ARM Linux wrote:

...

...

+dvi0: connector@0 {

• compatible = "dvi-connector";
• label = "dvi";
• i2c-bus = <&i2c3>;
• dvi_connector_in: endpoint {

• remote-endpoint = <&tfp410_out>;
  

• };

+};

This looks far too simplistic. There are different classes of DVI connector - there is:

DVI A - analogue only DVI D - digital only (single and dual link) DVI I - both (single and dual digital link)

DRM at least makes a distinction between these three classes, and this disctinction is part of the user API. How would a display system know which kind of DVI connector is wired up on the board from this DT description?

Yes, I think that's a valid change. But do we also need to specify single/dual link, in addition to the three types?

I guess the compatible string is the easiest way for differentation, at least for the three main types, i.e. "dvi-d-connector" etc.

"dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link? That looks a bit funny.

maybe like this:

Required Properties: - compatible: should contain one of the following: * "dvi-d-connector" * "dvi-a-connector" * "dvi-i-connector"

Optional Properties: - dual-link: Should be set for dual-link capable connectors

-- Sebastian

On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:

On 10/03/14 23:45, Rob Herring wrote:

...

I like this proposal over the others. Although, would dual link be a

I don't like inferring the information. With the above, you can't find out that the DVI connector has digital and analog support before all the drivers are loaded.

...

single endpoint or 2 endpoints? How would you differentiate that?

Hmm, well endpoints for a single port are exclusive. So it's either a single port and a single endpoint, or two ports and two endpoints. I think dual link has to be single port & endpoint, as the TMDS links need to be driven together as a single bus.

And dual-link is not really "two links". DVI dual-link means 1 clock lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for single-link.

What about having a property for the number of data lanes?

Gr{oetje,eeting}s,

Geert

-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

Am Dienstag, den 11.03.2014, 10:04 +0200 schrieb Tomi Valkeinen:

On 11/03/14 10:00, Geert Uytterhoeven wrote:

...

On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:

...

On 10/03/14 23:45, Rob Herring wrote:

...

I like this proposal over the others. Although, would dual link be a

I don't like inferring the information. With the above, you can't find out that the DVI connector has digital and analog support before all the drivers are loaded.

...

single endpoint or 2 endpoints? How would you differentiate that?

Hmm, well endpoints for a single port are exclusive. So it's either a single port and a single endpoint, or two ports and two endpoints. I think dual link has to be single port & endpoint, as the TMDS links need to be driven together as a single bus.

And dual-link is not really "two links". DVI dual-link means 1 clock lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for single-link.

What about having a property for the number of data lanes?

That was already suggested by Philipp in this thread. I don't see anything wrong with that, but I don't really see benefit either. "dual-link" is a standard term for 6 data lanes for the DVI connector. And the choices are 3 or 6 data lanes, nothing else.

The number of lanes of a DisplayPort connector could be 1 to 4. Also, there's dual-mode DP which can use four lanes to drive somewhat-like-HDMI single link TMDS signals.

regards Philipp

On 28/02/14 18:06, Russell King - ARM Linux wrote:

...

+hdmi0: connector@1 {

• compatible = "hdmi-connector";
• label = "hdmi";
• hdmi_connector_in: endpoint {

• remote-endpoint = <&tpd12s015_out>;
  

• };

+};

It seems rather weird to have DVI connectors having an optional I2C property, but HDMI (which augments DVI) not having that as at least an optional property.

I have added only the properties that I have used. I did think about the i2c for HDMI also, but thought that I don't use it, and so can't test it, and so I could well create a bad binding.

And, as I don't see any issue in adding it later, when someone uses it, I decided to leave it out.

I can quite well see the iMX HDMI support needing an i2c bus here.

Also, HDMI has two connector standards - type A and type B, much like the single vs dual link of DVI. Again, DRM exposes this to userspace.

True, but isn't that just a form factor? No functional differences? But I agree, we can add the two types here also to the compatible string.

Tomi

On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:

There's actually three HDMI connectors:

All three connectors carry all required HDMI signals, including a TMDS link. The Type B connector is slightly larger and carries a second TMDS link, which is necessary to support very high resolution displays using dual link. The Type C connector carries the same signals as the Type A but is more compact and intended for mobile applications.

So, Type C and Type A are electrically the same.

There's also D (e.g. on BeagleBone Black) and E:

http://en.wikipedia.org/wiki/HDMI#Connectors

Electrically they seem to be the same as A/C.

Gr{oetje,eeting}s,

Geert

-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

On 17/03/14 16:19, Laurent Pinchart wrote:

...

+Generic MIPI DPI Panel +======================

+Required properties: +- compatible: "panel-dpi"

+Optional properties: +- label: a symbolic name for the panel +- gpios: panel enable gpio and backlight enable gpio

While integrated in the panel module, the backlight is a separate piece of hardware, which could be controlled through other means (I2C for instance). Wouldn't it be better to add an explicit DT node for the backlight device and reference that node from the panel node ?

Yes, I agree, but do we have the infrastructure or bindings for that?

Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT bindings.

Tomi

On 17/03/14 16:22, Laurent Pinchart wrote:

...

+Example +-------

+lcd0: display {

• compatible = "tpo,taal", "panel-dsi-cm";
• label = "lcd0";
• gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */

If the panel uses a TE GPIO but no reset GPIO, do you plan to express this with a "hole" for the reset GPIO ? e.g. something like

gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;

Yes.

Wouldn't it be better to split the gpios property into "reset-gpios" and "te- gpios" ?

Yes, I can change it. I don't have a strong preference.

I've gotten similar comments for other bindings also, so I guess the preferred way is to use named "-gpios" properties for everything except the case where you really have multiple gpios with the same purpose?

The gpio binding documentation doesn't give much guidance on this.

Tomi

On 28/02/14 14:57, Sebastian Hesselbarth wrote:

Out of curiosity, will there be DT nodes for pull-up resistors soon, too? ;)

If they don't work automatically, yes, we need DT nodes and drivers for them.

Honestly, TPD12S015 is a level shifter, there is nothing in it that would justify a DT node nor a driver.

TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE and CT_CP_HPD, which need to be controlled based on what the user wants and the state of the HPD line. Who controls those?

Above you already note, that connector nodes should offer HPD in the future, but I guess the binding should represent that now already.

I think it can be added when somebody uses it. I don't see why that would cause trouble later to those that don't use it.

I will be a DT stub anyway, the corresponding video sink driver will have to look it up.

I'm not sure what you mean with that. Yes, it's not the most complex DT nodes out there.

Looking through the bindings for DVI and HDMI, I guess HPD gpio is better kept in those nodes. From the relevant (DT) properties DVI and HDMI connectors are in no way different.

Well, I think the HPD gpio should be where it's most logical to have it.

I mean, you could have a setup where you have the SoC HDMI encoder and and the HDMI connector, and the HPD pin goes directly to the HDMI encoder, which has HW support for it. In that case, the HDMI encoder node should contain the HPD, and the HDMI encoder should handle it.

Or, your HDMI encoder could not have any kind of support for HPD. In that case you could have the HDMI connector driver handle the hotplug event. You could of course make the HDMI encoder driver handle the HPD gpio, but I usually try to have the driver handle the hardware device in question.

In OMAP's case, we have the TPD chip between the HDMI encoder and the connector, and the logical place to handle HPD GPIO in that case is the TPD driver, as that's where the HPD is connected to and the TPD needs to be configured according to the state of the HPD.

Tomi

On 28/02/14 15:51, Sebastian Hesselbarth wrote:

...

TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE and CT_CP_HPD, which need to be controlled based on what the user wants and the state of the HPD line. Who controls those?

Strictly speaking TPD12S015 has _no_ GPIO but only buffers. It

What do you mean with that? That TPD doesn't provide GPIOs that you could control, in the sense that SoCs do? Sure. I didn't mean that. I meant it has gpios in the same sense that, say, a panel might have a 'enable' gpio.

Somebody needs to control the gpio state. For a panel, I would say it's the panel driver's job. And the gpio would be present in the panel's DT node. The same way for TDP.

translates one voltage to another. The controlling instance is your "video card" that is really interested in the actual state of HPD signal.

Well. I think it's the driver for the respective hardware device that handles the gpio. Of course, that driver will usually get information from somewhere else when to use those gpios. It may be the "video card", but really, the video card driver also gets the information if to enable the output from somewhere else.

Also the same for power, TPD12S015 doesn't decide to be powered up or down but the "video card" does. We have GPIO regulators that deal with that situation already.

The same here. TPD driver gets told to enable itself (or some particular feature that it supports). It will then enable the required powers.

Consider the same board but replace TPD12S015 with another level- shifter, you still want OMAP video driver work with that out-of-the-box,

Right. For this exact reason, the TPD is a separate driver. I can easily leave it out, or replace it with any other similar chip. Or the TPD driver can be used on some other platform.

OMAP video driver doesn't know anything about TPD, as TPD is not part of OMAP video hardware, or even OMAP SoC.

How would this work without TPD, or with, say, TPD1234567, which instead has 5 GPIOs that need to be set in particular order? The video card driver would need to know the exact details of all possible level shifters out there? Or?

don't you? Fact is, OMAP IP requires GPIOs to sense HPD status hence that GPIO is a property of the corresponding OMAP node. How level- translation happens is irrelevant here.

No it doesn't. There are different ways to handle HPD on OMAP HDMI. It's true that the HDMI IP supports directly handling HPD, but that's not used as there were some issues with it (I don't remember what). The HPD can as well be handled outside the HDMI driver.

If the HDMI IP would be handling the HPD, then, yes, HDMI node would have HPD gpio defined.

Thinking about it again, HPD gpio shouldn't be a property of the connector at all but again the controlling instance. The connector cannot deal with the information provided by HPD nor can it determine if anyone is listening to HPD events.

Well, this goes into the driver implementation details, but I disagree.

You have a video pipeline, let's say it's just SoC's HDMI encoder, and HDMI connector. In this particular case, the HDMI encoder IP has no support for HPD. On top of that, you have a "video card" driver, "display subsystem" driver, or whatever you want to call it, which is in control of the video pipeline. Let's call it controller.

The controller asks to get notified of a HPD event from the video pipeline. It doesn't care if the HPD is handled by the HDMI encoder driver or the connector driver. They can each handle it, in ways that suit the particular hardware they control. Of course, handling it in only one place usually makes sense.

When the controller is notified of a HPD, it can then decide what to do. If the user has told it to enable video output on HPD, the controller can command the video pipeline to be enabled.

...

Well, I think the HPD gpio should be where it's most logical to have it.

Right, but this is usually the controlling instance and not the consuming one. E.g. to detect presence of an MMC card by GPIO, you'd put that into the MMC _controller_ not any card node.

I'm not familiar with MMC, so there it may be clear. With video, we can have arbitrarily long video pipeline chains, with each component changed to some other, differently behaving component.

Let's think of another case. SoC's DSI encoder, an external HDMI encoder, and a HDMI connector. Who handles the HPD? Surely not the SoC's DSI encoder, as there's no such concept as HPD in DSI? The "video card" driver? Maybe, but from the video card's perspective, it is driving a DSI peripheral, and again no HPD in DSI.

The logical place there is the external HDMI encoder. And again, the HDMI encoder doesn't independently handle decisions about what to do when HPD happens. It just catches it, and tells somebody wiser about it.

And really, what's the difference with, say, an external HDMI encoder and TPD? Ok, lots =). But they both take video input in, output video, and require some config/control to make the chip work.

I totally agree that TPD is on the simpler side of components. But I think it fits right in into the model, and it works great on OMAP. Compared to older version, where TPD support was baked into the OMAP HDMI driver, which was a mess.

...

I mean, you could have a setup where you have the SoC HDMI encoder and and the HDMI connector, and the HPD pin goes directly to the HDMI encoder, which has HW support for it. In that case, the HDMI encoder node should contain the HPD, and the HDMI encoder should handle it.

I wonder, if in case of an dedicated HPD pin, you would ever expose that in DT.

Yes, if it's a dedicated pin, no configuration information needed, thus no information needed in DT. Well, pinctrl maybe.

Having a driver for a dumb connector seems to be a little exaggerated. Consider your generic HDMI connector "driver" connected to dedicated HPD case above. It is pretty useless then. OTOH video controllers with dedicated HPD know very well they can control HPD themselves, video controllers without dedicated HPD also know very well that they need GPIO for it.

Yes, I have to say I'm not 100% sure about the connectors. They could perhaps be left out. But they make things consistent, in my opinion, as they present a terminator for the video pipeline.

Say, you could have these two different boards:

SoC HDMI -> TPD -> HDMI connector

SoC HDMI -> TPD -> Embedded HDMI panel

In both cases, there's a component at the end, which is the end of the pipeline (as far as we're concerned). I think it makes the driver side a bit cleaner, and doesn't leave the TPD's output "hanging out" there.

Also I have used the connector drivers for actual work. The DVI connector has support for reading EDID via i2c. This is again something that you can argue that, hey, it should be the "video card" doing it. But it fits quite well into the DVI connector, and there's no other hardware component that has any support for the EDID.

I again see the above so that the video pipeline offers a way to read EDID. Where exactly that's done and how it happens on the hardware level, the controller doesn't care.

...

In OMAP's case, we have the TPD chip between the HDMI encoder and the connector, and the logical place to handle HPD GPIO in that case is the TPD driver, as that's where the HPD is connected to and the TPD needs to be configured according to the state of the HPD.

Is it really the logical place to handle HPD? I'd have put it into the HDMI encoder because it's the unit most interested in the state of HPD.

At least in OMAP's case, when not using the HDMI encoder's support for HPD, the HDMI encoder is not interested at all about the HPD.

Please, don't get me wrong, I like all this to be baked into a binding - just wondering if a level-shifter driver plus corresponding DT node is too much detail in here.

Thanks for the comments, I appreciate it. I hope I've convinced you enough =).

Tomi

Hi,

Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:

On 02/28/14 13:20, Tomi Valkeinen wrote:

...

This series is a re-send of http://article.gmane.org/gmane.linux.drivers.devicetree/61739

...

...

Shortly about the display components in the series, in the order of probable public interest:

• Analog TV, DVI and HDMI Connectors represent a respective connector on the board. They don't do much, but they do mark the end of the video pipeline (from the board's pov), and they should also in the future offer ways to handle things like the +5V pin on DVI and HDMI connector and HPD pin.

• MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels using the respective video bus.

• Sony acx565akm is an SPI controlled panel using flatlink video bus.

• TFP410 is a DPI to DVI encoder.

• TPD12S015 is a HDMI companion chip, used on OMAP boards.

Tomi,

Out of curiosity, will there be DT nodes for pull-up resistors soon, too? ;)

Honestly, TPD12S015 is a level shifter, there is nothing in it that would justify a DT node nor a driver.

Above you already note, that connector nodes should offer HPD in the future, but I guess the binding should represent that now already. I will be a DT stub anyway, the corresponding video sink driver will have to look it up.

Looking through the bindings for DVI and HDMI, I guess HPD gpio is better kept in those nodes. From the relevant (DT) properties DVI and HDMI connectors are in no way different.

I like the idea of adding actual connector nodes to the board device trees. A TV encoder driver for example could this way detect from the device tree whether it is connected to a VGA, Composite, or S-Video connector (or maybe to both Composite and S-Video connectors at the same time).

regards Philipp

On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:

This is totally unclear to me. How does it become a public standard? What's the forum for this?

Me too. That's where I'd hope someone on devicetree-discuss will be able to help us work out what's the right approach here. :)

On 03/03/14 10:04, Tomi Valkeinen wrote:

Hi Rob, Pawel, Mark, Ian, Kumar,

Ping,

Any hints on how to continue with this?

On 28/02/14 18:56, Russell King - ARM Linux wrote:

...

On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:

...

This is totally unclear to me. How does it become a public standard? What's the forum for this?

Me too. That's where I'd hope someone on devicetree-discuss will be able to help us work out what's the right approach here. :)

The story briefly so far: I've implemented DT support for OMAP display, and created bindings for various (non-OMAP) display components, including generic connector bindings for DVI, HDMI and analog-tv.

Russell's point was that these connector bindings are very generic, i.e. they are not for any particular chip from a particular vendor, but for any connector for DVI, HDMI or analog-tv. And he's worried that maybe we shouldn't define such generic bindings without consulting the whole device-tree community (i.e including non-linux users).

So the question is, is there such a community and a forum to bring up this kind of things? If yes, should we bring this up there? If yes, what kind of things in general should be brought into the attention of non-linux users?

What I wonder here is that while a thing like DVI connector is, of course, more generic than, say, "ti,tfp410" encoder chip, but isn't the case still the same: we're defining global bindings for hardware that should work for everyone, not only Linux users?

Tomi

Hi Grant,

Ping.

Are you fine with me proceeding with the current V4L2 port/endpoint bindings?

Tomi

On 12/03/14 10:15, Tomi Valkeinen wrote:

Hi Grant,

On 28/02/14 14:20, Tomi Valkeinen wrote:

...

Hi,

This series is a re-send of http://article.gmane.org/gmane.linux.drivers.devicetree/61739

I'm cc'ing more people, and I want to clarify the contents of the series:

While this has been developed for OMAP, only the first patch is about OMAP bindings. The rest are generic bindings for video components, which can be used on any platform.

The bindings use the V4L2 style video port/endpoint system, described in Documentation/devicetree/bindings/media/video-interfaces.txt, to connect the components. The same port/endpoint bindings are used by Philipp Zabel in his imx-drm patch series.

This series is a piece of bigger series, which brings DT support for OMAP display subsystem. This uses the same V4L2 style ports/endpoints as has been discussed recently regarding the series from Philipp. It doesn't use the helper code from Philipp, but a custom one as Philipp's code didn't exist when I made this, and also because I needed extra functionality not present in Philipp's series (which aimed to just move the current V4L2 code to a common place).

The main concerns with the ports/endpoints has been the optional 'port' node for the case where we have a single endpoint, and the double-linking of the endpoints.

If I remove the optional 'port' usage from my series, are you ok with me proceeding with this series for 3.15, with the double-linked endpoints?

As far as I see, when we come to a conclusion how the linking should be made, it's trivial to change the bindings in this series to match it, even without needing any compatibility code. I just need to remove the other link, and old dts files having double-linking will still work fine.

The reason I want to push this forward asap is that omap4 and omap5 are already DT only, and for omap5 we don't have working display without DT support for display. For omap4, we have a really hacky way to add display support for a few boards, but that is causing major headaches and I want to get rid of it.

Tomi