Re: [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Sun, Apr 26, 2026 at 11:54:57AM +0200, Heiko Stuebner wrote:
> Am Sonntag, 26. April 2026, 01:48:45 Mitteleuropäische Sommerzeit schrieb Laurent Pinchart:
> > On Sun, Apr 26, 2026 at 12:44:59AM +0300, Dmitry Baryshkov wrote:
> > > On Sat, Apr 25, 2026 at 01:10:02PM -0500, Dennis Gilmore wrote:
> > > > On Sat, Apr 25, 2026 at 9:24 AM Dmitry Baryshkov wrote:
> > > > > On Sat, Apr 25, 2026 at 02:28:44PM +0300, Laurent Pinchart wrote:
> > > > > > Hi Dennis,
> > > > > >
> > > > > > Thank you for the patch.
> > > > > >
> > > > > > On Fri, Apr 24, 2026 at 10:10:08PM -0500, Dennis Gilmore wrote:
> > > > > > > The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
> > > > > > > to HDMI2.0 converter, designed to connect a USB Type-C source or
> > > > > > > a DP1.4 source to an HDMI2.0 sink.
> > > > > >
> > > > > > As far as I can tell, the LT8711UXD has an I2C control interface.
> > > > > > Shouldn't it be an I2C device ?
> > > > >
> > > > > From the datasheet:
> > > > >
> > > > > The device is capable of automatic operation which is
> > > > > enabled by an integrated microprocessor that uses an
> > > > > embedded SPI flash for firmware storage. System control
> > > > > is also available through the use of a dedicated
> > > > > configuration I2C slave interface.
> > > > >
> > > > > My guess was that it can either be an I2C device or it can function as a
> > > > > simple platdev with no I2C controls. Please correct me if my
> > > > > understanding was wrong.
> > > > >
> > > > > But now looking at the schematics, it seems to be connected to I2C6.
> > > > > Which means that it should be desribed (and bound) as such.
> > > > 
> > > > Hi Dmitry and Laurent,
> > > > 
> > > > While the schematic shows that it can use I2C and has been wired up,
> > > > it also shows that both MODE_SEL and I2C_ADDR have unpopulated 10k
> > > > resistors; as a result, MODE_SEL is connected directly to GND,
> 
> looking at the schematics linked in the board patch, I somehow see
> both R9 (mode_sel -> vcc3v3_io) but also R17 (mode_sel -> gnd) marked
> as 10K.nc ?
> 
> > > > putting
> > > > the bridge in autonomous mode. I confirmed this by running `i2cdetect
> > > > -r -y 6`, with the only device on the bus being the HYM8563 RTC at
> > > > 0x51. Without reworking the board, the device is not directly
> > > > controllable and just runs autonomously.
> > > 
> > > I think it would be nice to mention:
> > > - In the commit for the bindings, that the device can be running
> > >   uncontrolled or it can be attached over I2C, bindings describe the
> > >   uncontrolled mode.
> > > - In this commit message, the same.
> > > - In the commit message for the board DT mention your findings about the
> > >   board, mention soldering R9 or R17 (which one?) and R27.
> > 
> > Additionally, how are we going to handle boards where the device
> > operates in I2C mode ? Will we use a different compatible string (maybe
> > "lontium,lt8711uxd-i2c") ? If DT maintainers are fine with that, I have
> > no objection to this patch.
> 
> I would assume it'd be more the dt-maintainers objecting?

Yes, probably :-) My main concern here is making sure we're not
cornering ourselves.

> I.e. the two different bindings for the same hardware and leaking Linux
> implementation-specifics into the binding.
> 
> I'm don't have deep insight into the i2c framework, but I guess the i2c
> device probe does not need to talk to an i2c device due to resources
> needing setup. Does the i2c core need to talk to the device at all?
> 
> Because otherwise, you could just do a regular i2c device (the routing
> for everything is there afterall), add a lontium,automatic-mode; flag
> to the node to denote mode.

That would work in this case, but if we have a board where the I2C lines
are really not routed, we would have to invent a fake connection to an
I2C controller. That's not very nice.

There seem to be precedents for devices that can be controlled through
either I2C or SPI. See for instance
Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml that defines
two compatible strings for the same device, "st,st21nfcb-i2c" and
"st,st21nfcb-spi". I don't know if that's the best practice recommended
by the DT maintainers, or a hack that slipped through.

> And if for whatever reason a variant appears with the lines connected
> you can just modifiy the DT via an overlay?

-- 
Regards,

Laurent Pinchart