linux-kernel - Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-tmds181: Add TI TMDS181 and SN65DP159 bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <34d4e81a-d4fa-47f2-85d1-ef01c9c21173@topic.nl>
Date: Wed, 20 Aug 2025 14:10:04 +0200
From: Mike Looijmans <mike.looijmans@...ic.nl>
To: Krzysztof Kozlowski <krzk@...nel.org>, Conor Dooley <conor@...nel.org>
CC: dri-devel@...ts.freedesktop.org, Andrzej Hajda <andrzej.hajda@...el.com>,
 Conor Dooley <conor+dt@...nel.org>, David Airlie <airlied@...il.com>,
 Jernej Skrabec <jernej.skrabec@...il.com>, Jonas Karlman <jonas@...boo.se>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Neil Armstrong <neil.armstrong@...aro.org>, Rob Herring <robh@...nel.org>,
 Robert Foss <rfoss@...nel.org>, Simona Vetter <simona@...ll.ch>,
 Thomas Zimmermann <tzimmermann@...e.de>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-tmds181: Add TI TMDS181
 and SN65DP159 bindings


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@...ic.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