Re: [PATCH v9 2/2] drm/bridge: add support for lontium lt9211c bridge

[Vishnu Saini <vishnu.saini@oss.qualcomm.com>]

On Mon, Sep 28, 2026 at 12:13:42PM +0200, Philipp Zabel wrote:
> On Fr, 2026-09-25 at 15:23 +0200, Philipp Zabel wrote:
> > On Do, 2026-09-24 at 21:29 +0530, vishnu.saini@oss.qualcomm.com wrote:
> > > From: Yi Zhang <zhanyi@qti.qualcomm.com>
> > > 
> > > LT9211C is a Single/Dual-Link DSI/LVDS or Single DPI input to
> > > Single-Link/Dual-Link DSI/LVDS or Single DPI output bridge chip.
> > > Extend the existing lontium-lt9211 driver to support DSI-to-LVDS
> > > bridge configuration by detecting and handling both LT9211 and LT9211C
> > > variants from a single driver.
> > > 
> > > Chip detection in lt9211_read_chipid() is extended to identify the
> > > LT9211C by its distinct chip ID registers, and cross-checked against
> > > the chip type requested by the DT compatible string to catch a
> > > mismatched board/compatible combination.
> > > 
> > > Add LT9211C-specific regmap support and use lt9211_chip_data with
> > > i2c_get_match_data() to provide per-chip configuration.
> > > 
> > > Five new functions implement the LT9211C DSI-to-LVDS initialisation
> > > sequence: lt9211c_configure_rx(), lt9211c_autodetect_rx(),
> > > lt9211c_configure_timing(), lt9211c_configure_plls() and
> > > lt9211c_configure_tx().
> > > 
> > > Defer the remaining LT9211C initialization to a work item scheduled
> > > from atomic_enable(), since RX auto-detection requires an active DSI
> > > stream.
> > 
> > This is still wrong, and I don't understand why you need it.
> > 
> > All scheduling initialization as a work item should allow is for
> > downstream bridges and/or panels to be atomic_enabled while
> > lt9211_work_func() is waiting for a vblank interrupt.
> > They expect the LVDS signal to be active at this point. If LVDS is
> > enabled at some unknown later point in time by the work item, any
> > startup timing requirements the panel might have can not be applied
> > correctly.
> > 
> > Also, deferring initialization as a work item shouldn't have any
> > influence on the upstream DSI signal. That should already be active
> > when lt9211c atomic_enable is called. Could it be that there is a bug
> > in your display controller or DSI bridge driver that causes the DSI
> > signal to still not be completely active at this point?
> > 
> > > Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com>
> > > Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
> > > Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com>
> > > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > > Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > I have not tested this version (yet).
> 
> I have now retested this on RK3576 - both as-is and with the
> "drm/bridge: lt9211: drop delayed work" patch I just sent.
Thank you i will see how atomic_enable is handled in RK3576
   
> I still think we have to figure out why the DSI signal doesn't appear
> to be streaming as it should when lt9211_atomic_enable is called in
> your setup.

> When enabling the lt9211c synchronously, is there any error?
> Is just the Sot/RX: debug output incorrect?
Yes, few details were mentioned in our v6 discussion.
droping delayed work is not working as expected. lt9211_autodetect_rx failed to read the format,
Tried increasing the delay upto 3s before reading the format buf, did not help:

With synchronous approach,
i defined a dummy drm hook, hw_enable_timing which is called after enabling the timing engine in drm/msm dsi host driver, and it starts working (bridge configuration was synchronously but in this dummy drm hook). So to remove delayed work, changes required in dsi host driver. Shall i defer bridge level atomic_enable callback from drm/msm/dsi host till timing engine is enabled?

> Which display controller / DSI bridge drivers are used to send the DSI
> signal?
I used drm/msm/dsi host driver on qcom lemans/kodiak/monaco evk platforms.

> regards
> Philipp