On 28/06/2024 09:49, Dmitry Baryshkov wrote: > On Fri, Jun 28, 2024 at 09:36:57AM GMT, Krzysztof Kozlowski wrote: >> On 27/06/2024 18:45, Marc Gonzalez wrote: >>> On 27/06/2024 18:25, Conor Dooley wrote: >>>> On Thu, Jun 27, 2024 at 01:13:03PM +0200, Marc Gonzalez wrote: >>>> >>>>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver. >>>>> It supports DVI 1.0, HDMI 1.4b and 2.0b. >>>>> It supports 4 TMDS channels, HPD, and a DDC interface. >>>>> It supports dual power supply rails (1.1V on VDD, 3.3V on VCC) >>>>> for power reduction. Several methods of power management are >>>>> implemented to reduce overall power consumption. >>>>> It supports fixed receiver EQ gain using I2C or pin strap to >>>>> compensate for different lengths input cable or board traces. >>>>> >>>>> Features >>>>> >>>>> - AC-coupled TMDS or DisplayPort dual-mode physical layer input >>>>> to HDMI 2.0b TMDS physical layer output supporting up to 6Gbps >>>>> data rate, compatible with HDMI 2.0b electrical parameters >>>>> - DisplayPort dual-mode standard version 1.1 >>>>> - Programmable fixed receiver equalizer up to 15.5dB >>>>> - Global or independent high speed lane control, pre-emphasis >>>>> and transmit swing, and slew rate control >>>>> - I2C or pin strap programmable >>>>> - Configurable as a DisplayPort redriver through I2C >>>>> - Full lane swap on main lanes >>>>> - Low power consumption (200 mW at 6Gbps, 8 mW in shutdown) >>>>> >>>>> https://www.ti.com/lit/ds/symlink/tdp158.pdf >>>>> >>>>> Signed-off-by: Marc Gonzalez <mgonzalez@xxxxxxxxxx> >>>>> --- >>>>> .../bindings/display/bridge/ti,tdp158.yaml | 51 ++++++++++++++++++++++ >>>>> 1 file changed, 51 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml >>>>> new file mode 100644 >>>>> index 0000000000000..21c8585c3bb2d >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml >>>>> @@ -0,0 +1,51 @@ >>>>> +# SPDX-License-Identifier: GPL-2.0-only >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/display/bridge/ti,tdp158.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: TI TDP158 HDMI to TMDS Redriver >>>>> + >>>>> +maintainers: >>>>> + - Arnaud Vrac <avrac@xxxxxxxxxx> >>>>> + - Pierre-Hugues Husson <phhusson@xxxxxxxxxx> >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: ti,tdp158 >>>>> + >>>>> + reg: >>>>> + description: I2C address of the device >>>> >>>> Is reg not required? How do you communicate with the device if the i2c >>>> bus is not connected? Is the enable GPIO enough to operate it in some >>>> situations? >>>> >>>> Otherwise this looks good to me, but given Maxime commented about the >>>> complexity of the device, I'm probably out of my depth! >>> >>> Valid question. >>> >>> As discussed in my brilliantly expanded commit message (:p) >>> the device can be configured in various ways, either through I2C registers >>> or by pin strap. We use the device in its default settings, so we don't >>> touch any I2C registers, thus I'm not sure the reg property is required. >> >> But then how would it be represented in the DT? Where / under which parent? >> >> If this is supposed to be always in I2C bus in DT, then you always need >> reg. If you could place it in other place, then your reasoning is valid >> - reg is optional. > > As far as I understood, the device is connected to I2C bus, it just > doesn't need to be programmed. So I'd conclude that reg is required. Just to be clear (and as far as I understand), the TDP158 can be configured via 2 different methods: - dynamically at run-time, through I2C registers (requires an I2C bus) - statically at layout-time through pin straps (no I2C bus required) On our board, the TDP158 is connected to blsp2_i2c1. So, in my understanding, the "reg" property would be required for the first method, but is not applicable for the second method. I don't feel strongly about the issue, so I can mark the "reg" property as required if it makes more sense. Regards
