@@ -0,0 +1,23 @@+HDMI Connector+=======++Required properties:+- compatible: "hdmi-connector"++Optional properties:+- label: a symbolic name for the connector++Required nodes:+- Video port for HDMI input++Example+-------++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 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.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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
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.
quoted
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.
HDMI A is 19 pins carrying TMDS channels 0-2. HDMI B is 29 pins
carrying TMDS channels 0-5. So, the difference is the same as the
single vs dual link on DVI-D/I connectors.
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.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
[off-list ref] 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
From: Tomi Valkeinen <hidden> Date: 2014-03-03 07:23:05
On 01/03/14 20:58, Geert Uytterhoeven wrote:
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
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.
Right. And then there are the HDMI versions, and things like HDMI
Ethernet Channel. After looking at these a bit, I don't think the HDMI
connector needs any of those (hdmi version, eth) defined.
So...
compatible = "hdmi-connector";
type = "a";
Or
compatible = "hdmi-connector";
type-a;
I don't right away see any big pro with either one compared to the other.
Tomi
@@ -0,0 +1,23 @@+HDMI Connector+=======++Required properties:+- compatible: "hdmi-connector"++Optional properties:+- label: a symbolic name for the connector++Required nodes:+- Video port for HDMI input++Example+-------++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 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.
Yeah, there's a dual-link hdmi standard somewhere. I've never seen it in
the wild anywhere though, and newer hdmi all just increase the max link
clock to push higher res modes over the wire. Imo can't hurt to just
enumerate all type of physical connectors standardized.
HDMI revisions themselves are only relevant for the sink (as advertised
capabilities in the EDID) and for your hdmi encoder chip (where pretty
much just the max dotclock is interesting really). So I don't think we
need a hdmi revision in dt for the physical connector.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Tomi Valkeinen <hidden> Date: 2014-03-05 08:42:36
On 01/03/14 20:58, Geert Uytterhoeven wrote:
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
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.