On Tue, Jul 23, 2024 at 08:57:03PM GMT, Conor Dooley wrote: > On Tue, Jul 23, 2024 at 05:17:12PM +0200, 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! > > > > Hello Conor, > > > > A cycle has been detected: > > Above, you defer to Maxime. > > Yet later, he wrote: > > "DT maintainers have required that reg is always present" > > I think he was actually talking about Krzysztof. I was. > > I propose we NOT mark the "reg" property as required. > > (Thus, keep the binding as proposed in v3.) > > > > Rationale: > > > > - The device can be statically configured by pin straps, > > in which case it is NOT connected to an I2C bus. > > I'm inclined to say that, because connecting the i2c bus is not required > at all for the device to be usable in some circumstances that we should > not require reg. Someone could, in theory, use the device with a SoC > without an i2c controller, right? > > > - Even if the device IS connected to an I2C bus, > > no I2C accesses are required if the default configuration > > meets the ODM's needs. > > In this case, I think a reg property is required actually, because it is > on the bus, and devices on an i2c bus must have a reg property. That > aside, even if the ODM doesn't want to change the defaults, the owner > might. > > > Is that OK with you? Can I get your Amen? > > Sure. We still have an entire sub-thread to this conversation that has been completely ignored by Marc. Upstreaming is process where both sides need to be involved, and I'm not seeing that so far. So, yeah, until that other sub-thread is somewhat resolved, I don't see how we can vet those bindings. Maxime
Attachment:
signature.asc
Description: PGP signature
