Re: [PATCH 3/4] drm-bridge: lontium lt9611c: fixes and improvements

[Mohit Dsor <mohit.dsor@oss.qualcomm.com>]

On Fri, Jun 26, 2026 at 11:30:56PM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 11, 2026 at 02:44:58AM +0530, Mohit Dsor wrote:
> > Remove two redundant lt9611c_reset() calls:
> > 
> > 1. In lt9611c_bridge_atomic_pre_enable(): a reset is already performed
> >    during probe and resume; calling it again on every display enable
> >    adds ~440ms of unnecessary latency.
> > 
> > 2. At the end of lt9611c_probe(): a reset was already performed earlier
> >    in probe before lt9611c_lock(). The second reset is redundant.
> > 
> > Also, the DRM HDMI bridge framework requires hdmi_write_hdmi_infoframe and
> > hdmi_clear_hdmi_infoframe callbacks for HDMI vendor-specific infoframe
> > (VSI) support, used for features such as HDR metadata signalling.
> > 
> > This patch add stub implementations that return success. Wire them into the bridge
> > function table.
> > 
> > Also, Store the chip variant enum value in the of_match_table .data field and
> > retrieve it via of_device_get_match_data() when probing from a DT node.
> > Fall back to i2c_device_id.driver_data for non-DT (e.g. ACPI) probe
> > paths.
> > 
> > This is the standard kernel pattern for passing per-compatible data
> > through the OF match table, and avoids relying solely on the I2C device
> > ID table for chip type detection when DT is available.
> > 
> > Populate bridge.vendor and bridge.product so the DRM HDMI framework can
> > report the correct manufacturer and product name in the HDMI connector
> > properties (visible via xrandr --prop and related sysfs entries).
> 
> I was going to write that this should be split into several commits, but
> then... I stumbled upon a fact that the driver is not a part of the
> drm-misc. So, instead of posting an update for the not-yet-merged
> driver, please post new iteration of the LT9611C series. Don't forget to
> drop the R-B tags where applicable.
> 
We will merge these changes in base patch only.
> > 
> > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> > ---
> >  drivers/gpu/drm/bridge/lontium-lt9611c.c | 31 ++++++++++++++++++++++++++-----
> >  1 file changed, 26 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> > index b0402726367e..fe51f4978546 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> > @@ -622,7 +622,6 @@ static void lt9611c_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> >  	ret = regulator_bulk_enable(ARRAY_SIZE(lt9611c->supplies), lt9611c->supplies);
> >  	if (ret)
> >  		dev_err(lt9611c->dev, "regulator bulk enable failed.\n");
> > -	lt9611c_reset(lt9611c);
> >  }
> >  
> >  static void lt9611c_bridge_atomic_enable(struct drm_bridge *bridge,
> > @@ -777,6 +776,17 @@ static int lt9611c_hdmi_clear_avi_infoframe(struct drm_bridge *bridge)
> >  	return 0;
> >  }
> >  
> > +static int lt9611c_hdmi_write_hdmi_infoframe(struct drm_bridge *bridge,
> > +					     const u8 *buffer, size_t len)
> > +{
> > +	return 0;
> > +}
> > +
> > +static int lt9611c_hdmi_clear_hdmi_infoframe(struct drm_bridge *bridge)
> > +{
> > +	return 0;
> > +}
> 
> Definite NAK. The purpose of the callbacks is to write the infoframe.
> Purpose of the check in the DRM framework is to ensure that the frame is
> actually written. Please work with Lontium and find a way to write HDMI
> / HVS, SPD and HDR infoframes.
> 
We will implement these callbaks.
> > +
> >  static int lt9611c_hdmi_write_audio_infoframe(struct drm_bridge *bridge,
> >  					      const u8 *buffer, size_t len)
> >  {
> > @@ -895,6 +905,8 @@ static const struct drm_bridge_funcs lt9611c_bridge_funcs = {
> >  	.hdmi_tmds_char_rate_valid = lt9611c_hdmi_tmds_char_rate_valid,
> >  	.hdmi_write_avi_infoframe = lt9611c_hdmi_write_avi_infoframe,
> >  	.hdmi_clear_avi_infoframe = lt9611c_hdmi_clear_avi_infoframe,
> > +	.hdmi_write_hdmi_infoframe = lt9611c_hdmi_write_hdmi_infoframe,
> > +	.hdmi_clear_hdmi_infoframe = lt9611c_hdmi_clear_hdmi_infoframe,
> >  	.hdmi_write_audio_infoframe = lt9611c_hdmi_write_audio_infoframe,
> >  	.hdmi_clear_audio_infoframe = lt9611c_hdmi_clear_audio_infoframe,
> >  
> > @@ -1025,6 +1037,13 @@ static int lt9611c_probe(struct i2c_client *client)
> >  	lt9611c->dev = dev;
> >  	lt9611c->client = client;
> >  	lt9611c->chip_type = id->driver_data;
> > +
> > +	if (dev->of_node) {
> > +		lt9611c->chip_type = (uintptr_t)of_device_get_match_data(dev);
> > +	} else {
> > +		lt9611c->chip_type = id->driver_data;
> > +	}
> 
> Use i2c_get_match_data(). But, also, why? The driver will likely not
> work w/o the OF in place, there is little point in doing something else.
> 
we will use i2c_get_match_data. id->driver_data is in base patch, we
will check with lontium for this.
> > +
> >  	ret = devm_mutex_init(dev, &lt9611c->ocm_lock);
> >  	if (ret)
> >  		return dev_err_probe(dev, ret, "failed to init mutex\n");
> 
> -- 
> With best wishes
> Dmitry