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 <[email protected]>
> > ---
> > 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, <9611c->ocm_lock);
> > if (ret)
> > return dev_err_probe(dev, ret, "failed to init mutex\n");
>
> --
> With best wishes
> Dmitry
