Add DT binding document for TI TMDS181 and SN65DP159 HDMI retimers.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
.../bindings/display/bridge/ti,tmds181.yaml | 104 ++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
new file mode 100644
index 000000000000..87ffb556c4ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,tmds181.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TMDS181 and SN65DP159 HDMI retimer/redriver chips
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: |
+ Texas Instruments TMDS181 and SN65DP159 retimer and redriver chips.
+ https://www.ti.com/product/TMDS181
+ https://www.ti.com/product/TMDS181
+
+properties:
+ compatible:
+ enum:
+ - ti,tmds181
+ - ti,sn65dp159
+
+ reg:
+ enum:
+ - 0x5b
+ - 0x5c
+ - 0x5d
+ - 0x5e
+
+ oe-gpios:
+ maxItems: 1
+ description: GPIO specifier for OE pin (active high).
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Video port for HDMI (ish) input
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Video port for HDMI output (panel or bridge)
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@5b {
+ compatible = "ti,sn65dp159";
+ reg = <0x5b>;
+
+ oe-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&encoder_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+ };
--
2.43.0
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
On Tue, Aug 12, 2025 at 04:51:34PM +0200, Mike Looijmans wrote:
> Add DT binding document for TI TMDS181 and SN65DP159 HDMI retimers.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> ---
>
> .../bindings/display/bridge/ti,tmds181.yaml | 104 ++++++++++++++++++
> 1 file changed, 104 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
> new file mode 100644
> index 000000000000..87ffb556c4ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,tmds181.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TMDS181 and SN65DP159 HDMI retimer/redriver chips
> +
> +maintainers:
> + - Mike Looijmans <mike.looijmans@topic.nl>
> +
> +description: |
> + Texas Instruments TMDS181 and SN65DP159 retimer and redriver chips.
> + https://www.ti.com/product/TMDS181
> + https://www.ti.com/product/TMDS181
These two links are the same.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,tmds181
> + - ti,sn65dp159
The driver contains:
+ { .compatible = "ti,tmds181", },
+ { .compatible = "ti,sn65dp159", },
+ {}
so why is a fallback compatible not suitable here?
Otherwise, this looks fine to me.
> +
> + reg:
> + enum:
> + - 0x5b
> + - 0x5c
> + - 0x5d
> + - 0x5e
> +
> + oe-gpios:
> + maxItems: 1
> + description: GPIO specifier for OE pin (active high).
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Video port for HDMI (ish) input
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Video port for HDMI output (panel or bridge)
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bridge@5b {
> + compatible = "ti,sn65dp159";
> + reg = <0x5b>;
> +
> + oe-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&encoder_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> + };
> --
> 2.43.0
>
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
> System Expert
>
>
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
>
> T: +31 (0) 499 33 69 69
> E: mike.looijmans@topic.nl
> W: www.topic.nl
>
> Please consider the environment before printing this e-mail
On 12-08-2025 19:58, Conor Dooley wrote:
> On Tue, Aug 12, 2025 at 04:51:34PM +0200, Mike Looijmans wrote:
>> Add DT binding document for TI TMDS181 and SN65DP159 HDMI retimers.
>>
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>> ---
>>
>> .../bindings/display/bridge/ti,tmds181.yaml | 104 ++++++++++++++++++
>> 1 file changed, 104 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
>> new file mode 100644
>> index 000000000000..87ffb556c4ad
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tmds181.yaml
>> @@ -0,0 +1,104 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/ti,tmds181.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TMDS181 and SN65DP159 HDMI retimer/redriver chips
>> +
>> +maintainers:
>> + - Mike Looijmans <mike.looijmans@topic.nl>
>> +
>> +description: |
>> + Texas Instruments TMDS181 and SN65DP159 retimer and redriver chips.
>> + https://www.ti.com/product/TMDS181
>> + https://www.ti.com/product/TMDS181
> These two links are the same.
Will fix in v3
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - ti,tmds181
>> + - ti,sn65dp159
> The driver contains:
> + { .compatible = "ti,tmds181", },
> + { .compatible = "ti,sn65dp159", },
> + {}
> so why is a fallback compatible not suitable here?
I don't understand the question. The two are slightly different chips,
so it makes sense to describe that in the DT.
--
Mike Looijmans
On 19/08/2025 09:46, Mike Looijmans wrote:
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - ti,tmds181
>>> + - ti,sn65dp159
>> The driver contains:
>> + { .compatible = "ti,tmds181", },
>> + { .compatible = "ti,sn65dp159", },
>> + {}
>> so why is a fallback compatible not suitable here?
>
> I don't understand the question. The two are slightly different chips,
Your driver says they are compatible. No one said the same, but compatible.
> so it makes sense to describe that in the DT.
Compatible devices should use fallback. There is plenty of examples (90%
of all binding files?) including example-schema describing this.
>
Best regards,
Krzysztof
On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
> On 19/08/2025 09:46, Mike Looijmans wrote:
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + enum:
>>>> + - ti,tmds181
>>>> + - ti,sn65dp159
>>> The driver contains:
>>> + { .compatible = "ti,tmds181", },
>>> + { .compatible = "ti,sn65dp159", },
>>> + {}
>>> so why is a fallback compatible not suitable here?
>> I don't understand the question. The two are slightly different chips,
> Your driver says they are compatible. No one said the same, but compatible.
>
>> so it makes sense to describe that in the DT.
> Compatible devices should use fallback. There is plenty of examples (90%
> of all binding files?) including example-schema describing this.
Please help me out here, I'm happy to oblige, but I don't understand
what you're asking.
To the best of my knowledge "fallback" compatible is when you write
something like this in the device-tree:
compatible = "st,m25p80", "jedec,spi-nor";
Which means that we can use the "jedec,spi-nor" driver if there's no
specific match for "st,m25p80", correct?
I don't understand how that relates to your request, this is the first
time I ever got this particular feedback. Looking at say the
ti,sn65dsi83 driver, it does the same thing (supports the ti,sn65dsi83
and ti,sn65dsi84).
Please explain or point me somewhere where I can find this?
>
>
> Best regards,
> Krzysztof
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
On 19/08/2025 10:26, Mike Looijmans wrote:
> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
>> On 19/08/2025 09:46, Mike Looijmans wrote:
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + enum:
>>>>> + - ti,tmds181
>>>>> + - ti,sn65dp159
>>>> The driver contains:
>>>> + { .compatible = "ti,tmds181", },
>>>> + { .compatible = "ti,sn65dp159", },
>>>> + {}
>>>> so why is a fallback compatible not suitable here?
>>> I don't understand the question. The two are slightly different chips,
>> Your driver says they are compatible. No one said the same, but compatible.
>>
>>> so it makes sense to describe that in the DT.
>> Compatible devices should use fallback. There is plenty of examples (90%
>> of all binding files?) including example-schema describing this.
>
> Please help me out here, I'm happy to oblige, but I don't understand
> what you're asking.
>
> To the best of my knowledge "fallback" compatible is when you write
> something like this in the device-tree:
> compatible = "st,m25p80", "jedec,spi-nor";
> Which means that we can use the "jedec,spi-nor" driver if there's no
> specific match for "st,m25p80", correct?
Yes.
>
> I don't understand how that relates to your request, this is the first
> time I ever got this particular feedback. Looking at say the
> ti,sn65dsi83 driver, it does the same thing (supports the ti,sn65dsi83
> and ti,sn65dsi84).
>
> Please explain or point me somewhere where I can find this?
I already pointed out to example-schema.
Also, e.g. first file in iio/adc:
adi,ad4000.yaml
Best regards,
Krzysztof
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
On 20-08-2025 08:44, Krzysztof Kozlowski wrote:
> On 19/08/2025 10:26, Mike Looijmans wrote:
>> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
>>> On 19/08/2025 09:46, Mike Looijmans wrote:
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + enum:
>>>>>> + - ti,tmds181
>>>>>> + - ti,sn65dp159
>>>>> The driver contains:
>>>>> + { .compatible = "ti,tmds181", },
>>>>> + { .compatible = "ti,sn65dp159", },
>>>>> + {}
>>>>> so why is a fallback compatible not suitable here?
>>>> I don't understand the question. The two are slightly different chips,
>>> Your driver says they are compatible. No one said the same, but compatible.
>>>
>>>> so it makes sense to describe that in the DT.
>>> Compatible devices should use fallback. There is plenty of examples (90%
>>> of all binding files?) including example-schema describing this.
>> Please help me out here, I'm happy to oblige, but I don't understand
>> what you're asking.
>>
>> To the best of my knowledge "fallback" compatible is when you write
>> something like this in the device-tree:
>> compatible = "st,m25p80", "jedec,spi-nor";
>> Which means that we can use the "jedec,spi-nor" driver if there's no
>> specific match for "st,m25p80", correct?
> Yes.
>
>> I don't understand how that relates to your request, this is the first
>> time I ever got this particular feedback. Looking at say the
>> ti,sn65dsi83 driver, it does the same thing (supports the ti,sn65dsi83
>> and ti,sn65dsi84).
>>
>> Please explain or point me somewhere where I can find this?
> I already pointed out to example-schema.
>
> Also, e.g. first file in iio/adc:
> adi,ad4000.yaml
>
I think I get it. Instead of having compatibles "a" and "b" the driver only
supports "a" in its match table, and the devicetree entry must be either
compatible="a"; or compatible="b","a". Using compatible="b"; would be disallowed.
I actually planned (I have implemented it locally already for v3) for the
driver to check the chip type and complain if it doesn't match the devicetree.
If the wrong device is there, the most likely cause is that the input and
output buses got mixed up. That would also justify having separate
compatibles, right?
On Wed, Aug 20, 2025 at 11:37:24AM +0200, Mike Looijmans wrote: > I actually planned (I have implemented it locally already for v3) for the > driver to check the chip type and complain if it doesn't match the > devicetree. If the wrong device is there, the most likely cause is that the > input and output buses got mixed up. That would also justify having separate > compatibles, right? It's not the kernel's job to verify the devicetree, it should be assumed to be correct. You're ensuring that when another compatible device arrives later on that a new string in a binding will not be sufficient for the device to be supported and driver changes will be required to make it work.
On 20/08/2025 11:37, Mike Looijmans wrote: > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijmans@topic.nl > W: www.topic.nl Please fix your email client not to attach such top signature. ... >> >> Also, e.g. first file in iio/adc: >> adi,ad4000.yaml >> > I think I get it. Instead of having compatibles "a" and "b" the driver only > supports "a" in its match table, and the devicetree entry must be either > compatible="a"; or compatible="b","a". Using compatible="b"; would be disallowed. > > I actually planned (I have implemented it locally already for v3) for the > driver to check the chip type and complain if it doesn't match the devicetree. > If the wrong device is there, the most likely cause is that the input and > output buses got mixed up. That would also justify having separate I don't understand why. I don't get what is input and output bus. Either devices are compatible or not. If you can check which device you have via registers, then usually they are compatible. Best regards, Krzysztof
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijmans@topic.nl W: www.topic.nl Please consider the environment before printing this e-mail On 20-08-2025 13:35, Krzysztof Kozlowski wrote: > On 20/08/2025 11:37, Mike Looijmans wrote: > Please fix your email client not to attach such top signature. > > ... It's actually the company IT that does that, but I'll keep doing my best to prevent it (though sometimes it kicks in anyway). > >>> Also, e.g. first file in iio/adc: >>> adi,ad4000.yaml >>> >> I think I get it. Instead of having compatibles "a" and "b" the driver only >> supports "a" in its match table, and the devicetree entry must be either >> compatible="a"; or compatible="b","a". Using compatible="b"; would be disallowed. >> >> I actually planned (I have implemented it locally already for v3) for the >> driver to check the chip type and complain if it doesn't match the devicetree. >> If the wrong device is there, the most likely cause is that the input and >> output buses got mixed up. That would also justify having separate > I don't understand why. I don't get what is input and output bus. > > Either devices are compatible or not. > > If you can check which device you have via registers, then usually they > are compatible. > They have almost the same registers, but they are intended for opposite sides of the HDMI cable. The DP159 variant expects to drive signals into the cable, while the TDMS181 expects to receive its input from the cable. If you encounter a TMDS181 where you expected the other, something's wrong with your board (the board manufacturer placed the wrong chip) or your devicetree (e.g. you mixed up the I2C addresses of the receiver and sender). In such case, the chip will happily do its thing, but the system may not work as expected. Valid setups: CRTC -> pcb -> DP159 -> cable -> hdmi-monitor CRTC -> pcb -> cable -> TMDS181 -> hdmi-to-lvds -> panel CRTC -> pcb -> DP159 -> cable -> TMDS181 -> hdmi-to-lvds -> panel
On Tue, Aug 19, 2025 at 10:26:15AM +0200, Mike Looijmans wrote:
> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
> > On 19/08/2025 09:46, Mike Looijmans wrote:
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + enum:
> > > > > + - ti,tmds181
> > > > > + - ti,sn65dp159
> > > > The driver contains:
> > > > + { .compatible = "ti,tmds181", },
> > > > + { .compatible = "ti,sn65dp159", },
> > > > + {}
> > > > so why is a fallback compatible not suitable here?
> > > I don't understand the question. The two are slightly different chips,
> > Your driver says they are compatible. No one said the same, but compatible.
> >
> > > so it makes sense to describe that in the DT.
> > Compatible devices should use fallback. There is plenty of examples (90%
> > of all binding files?) including example-schema describing this.
>
> Please help me out here, I'm happy to oblige, but I don't understand what
> you're asking.
>
> To the best of my knowledge "fallback" compatible is when you write
> something like this in the device-tree:
> compatible = "st,m25p80", "jedec,spi-nor";
> Which means that we can use the "jedec,spi-nor" driver if there's no
> specific match for "st,m25p80", correct?
>
> I don't understand how that relates to your request, this is the first time
> I ever got this particular feedback. Looking at say the ti,sn65dsi83 driver,
> it does the same thing (supports the ti,sn65dsi83 and ti,sn65dsi84).
>
> Please explain or point me somewhere where I can find this?
Devices that are supersets of, or functionally identical to, others should
use fallback compatibles. The driver treats these devices as functionally
identical to one another when it comes to match data (as there is none)
so you need to either use a fallback compatible or explain in your
commit message why one is not suitable here.
© 2016 - 2025 Red Hat, Inc.