diff mbox

[PATCHv2,4/8] Doc/DT: Add DT binding documentation for HDMI Connector

Message ID 1395130547-18633-5-git-send-email-tomi.valkeinen@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tomi Valkeinen March 18, 2014, 8:15 a.m. UTC
Add DT binding documentation for HDMI Connector.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
 .../devicetree/bindings/video/hdmi-connector.txt   | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt

Comments

Philipp Zabel March 19, 2014, 8:03 a.m. UTC | #1
Hi Laurent,

Am Mittwoch, den 19.03.2014, 00:43 +0100 schrieb Laurent Pinchart:
> Hello,
> 
> On Tuesday 18 March 2014 09:43:54 Philipp Zabel wrote:
> > Am Dienstag, den 18.03.2014, 10:15 +0200 schrieb Tomi Valkeinen:
> > > Add DT binding documentation for HDMI Connector.
> > > 
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Reviewed-by: Archit Taneja <archit@ti.com>
> > > ---
> > > 
> > >  .../devicetree/bindings/video/hdmi-connector.txt   | 28 +++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > >  create mode 100644
> > >  Documentation/devicetree/bindings/video/hdmi-connector.txt> 
> > > diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > > b/Documentation/devicetree/bindings/video/hdmi-connector.txt new file
> > > mode 100644
> > > index 000000000000..ccccc19e2573
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > > @@ -0,0 +1,28 @@
> > > +HDMI Connector
> > > +==============
> > > +
> > > +Required properties:
> > > +- compatible: "hdmi-connector"
> > > +- type: the HDMI connector type: "a", "b", "c", "d" or "e"
> > > +
> > > +Optional properties:
> > > +- label: a symbolic name for the connector
> > > +
> > > +Required nodes:
> > > +- Video port for HDMI input
> > 
> > Geert's comment also applies to all other connector types. These can be
> > input connectors, too.
> 
> We might not need to define all the properties required by input connectors 
> now, but we need to make sure that future extensions will be backward-
> compatible. I don't see a problem in making the connector DT bindings depend 
> on the direction as long as the direction is specified in the DT node, either 
> explicitly or implicitly.
>
> An obvious solution would be to have separate "hdmi-input-connector" and 
> "hdmi-output-connector" compatible strings but I don't like that, as there's 
> no difference in the HDMI connector itself, only in the usage.

I don't think this is necessary, either. I just meant the wording for
the video port should leave the direction unspecified. I imagine
somebody somewhere will connect a HDMI connector to a mux so that it can
be either input or output.

> We could also add a "direction" property (possibly later, with a default value 
> of "output" in that case), or rely on the link direction, but in the latter 
> case that would require reaching an agreement in the current link directions 
> debate.

If we add a direction property, I think it should be on the ports.

regards
Philipp
Tomi Valkeinen March 19, 2014, 8:11 a.m. UTC | #2
On 19/03/14 10:03, Philipp Zabel wrote:

>>> Geert's comment also applies to all other connector types. These can be
>>> input connectors, too.
>>
>> We might not need to define all the properties required by input connectors 
>> now, but we need to make sure that future extensions will be backward-
>> compatible. I don't see a problem in making the connector DT bindings depend 
>> on the direction as long as the direction is specified in the DT node, either 
>> explicitly or implicitly.
>>
>> An obvious solution would be to have separate "hdmi-input-connector" and 
>> "hdmi-output-connector" compatible strings but I don't like that, as there's 
>> no difference in the HDMI connector itself, only in the usage.
> 
> I don't think this is necessary, either. I just meant the wording for
> the video port should leave the direction unspecified. I imagine
> somebody somewhere will connect a HDMI connector to a mux so that it can
> be either input or output.

I don't disagree, but I think it's better to change the wording when
someone has a working setup and can try it. These bindings have been
designed only with video output in mind, and I'd rather have them
constrained to that purpose for now.

One reason for keeping them output only is that when someone wants to
use these for capture, he needs to change the binding docs, and it'll
gather more attention than just using the bindings in a board's dts.

That said, we should take care to make the bindings so that nothing
prevents their use for capture (which I think they allow in their
current form).

 Tomi
Philipp Zabel March 19, 2014, 8:22 a.m. UTC | #3
Am Mittwoch, den 19.03.2014, 10:11 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:03, Philipp Zabel wrote:
> 
> >>> Geert's comment also applies to all other connector types. These can be
> >>> input connectors, too.
> >>
> >> We might not need to define all the properties required by input connectors 
> >> now, but we need to make sure that future extensions will be backward-
> >> compatible. I don't see a problem in making the connector DT bindings depend 
> >> on the direction as long as the direction is specified in the DT node, either 
> >> explicitly or implicitly.
> >>
> >> An obvious solution would be to have separate "hdmi-input-connector" and 
> >> "hdmi-output-connector" compatible strings but I don't like that, as there's 
> >> no difference in the HDMI connector itself, only in the usage.
> > 
> > I don't think this is necessary, either. I just meant the wording for
> > the video port should leave the direction unspecified. I imagine
> > somebody somewhere will connect a HDMI connector to a mux so that it can
> > be either input or output.
> 
> I don't disagree, but I think it's better to change the wording when
> someone has a working setup and can try it. These bindings have been
> designed only with video output in mind, and I'd rather have them
> constrained to that purpose for now.
> 
> One reason for keeping them output only is that when someone wants to
> use these for capture, he needs to change the binding docs, and it'll
> gather more attention than just using the bindings in a board's dts.
> 
> That said, we should take care to make the bindings so that nothing
> prevents their use for capture (which I think they allow in their
> current form).

I don't disagree, either. I have no objection against the bindings
themselves.

Acked-by: Philipp Zabel <p.zabel@pengutronix.de>

regards
Philipp
Tomi Valkeinen March 19, 2014, 9:08 a.m. UTC | #4
On 19/03/14 10:22, Philipp Zabel wrote:

> I don't disagree, either. I have no objection against the bindings
> themselves.
> 
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>

Thanks. Is the ack for this particular binding, or for the whole series?

 Tomi
Philipp Zabel March 19, 2014, 9:36 a.m. UTC | #5
Hi Tomi,

Am Mittwoch, den 19.03.2014, 11:08 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:22, Philipp Zabel wrote:
> 
> > I don't disagree, either. I have no objection against the bindings
> > themselves.
> > 
> > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> 
> Thanks. Is the ack for this particular binding, or for the whole series?

Thanks for asking, I haven't really looked at the TPD12S015 binding.
The rest of the series, yes.

regards
Philipp
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..ccccc19e2573
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,28 @@ 
+HDMI Connector
+==============
+
+Required properties:
+- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
+
+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";
+
+	type = "a";
+
+	port {
+		hdmi_connector_in: endpoint {
+			remote-endpoint = <&tpd12s015_out>;
+		};
+	};
+};