linux-kernel - Re: [PATCH v4 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: <aa80b3c4-01b5-4d4c-9fe0-523cdb895eb3@topic.nl>
Date: Wed, 3 Sep 2025 08:17:33 +0200
From: Mike Looijmans <mike.looijmans@...ic.nl>
To: Maxime Ripard <mripard@...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>,
 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 v4 1/2] dt-bindings: drm/bridge: ti-tmds181: Add TI
 TMDS181 and SN65DP159 bindings

On 02-09-2025 19:29, Maxime Ripard wrote:
> On Mon, Sep 01, 2025 at 04:29:01PM +0200, Mike Looijmans wrote:
>> +  ti,retimer-threshold-hz:
>> +    minimum: 25000000
>> +    maximum: 600000000
>> +    default: 200000000
>> +    description:
>> +      Cross-over point. Up until this pixel clock frequency
>> +      the chip remains in the low-power redriver mode. Above
>> +      the threshold the chip should operate in retimer mode.
> Why should anyone want to tune this at the firmware level?

It's a board property. You'd set this based on the hardware you've soldered 
on. If your clock and serdes are good quality, there's no need for the chip to 
be in retimer mode (it will consume more power and actually make the signal 
worse). At higher speeds, that situation may change, hence the need for a way 
to describe that. The chip has a similar function built in, but with only 2 
choices of cross-over point.

To tune these parameters (retimer, equalizer), you'll probably have to take 
your equipment to a test facility (like we did). It's not something that 
end-users would want to tune themselves.

Most of these settings can also be done using pin strapping. I guess it'd be 
helpful if I added that to the description.

>> +  ti,dvi-mode:
>> +    type: boolean
>> +    description: Makes the DP159 chip operate in DVI mode.
> Ditto. Both describe policy, not hardware.

I would set this flag if I've soldered on a DVI connector instead of a HDMI 
one. I'd consider that hardware.

>> +  ti,slew-rate:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    minimum: 0
>> +    maximum: 3
>> +    default: 3
>> +    description: Set slew rate, 0 is slowest, 3 is fastest.
>> +
>> +  ti,disable-equalizer:
>> +    type: boolean
>> +    description: Disable the equalizer (to save power).
> Why shouldn't we disable all the time then? Again, it looks like a
> policy, and not something that should be set in stone in the firmware.

Again, board property. The equalizer is there to make up for things like PCB 
losses (mismatch maybe?) or serdes running at (or beyond) its maximum. Again, 
depending on your board you may need this or not. It replaces a pinstrapping 
option.

>> +  ti,adaptive-equalizer:
>> +    type: boolean
>> +    description: Set the equalizer to adaptive mode.

It's the default setting of the chip so this flag will be removed in the next 
version.

> Maxime

Mike.