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

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Mohit,

On Mon Jun 22, 2026 at 2:08 PM CEST, Mohit Dsor wrote:
> On Fri, Jun 12, 2026 at 11:26:34AM +0200, Luca Ceresoli wrote:
>> On Wed Jun 10, 2026 at 11:14 PM CEST, 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).
>> >
>> > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
>>
>> These are several unrelated changes and should be separate commits.
>>
>> Luca
>>
>> --
>> Luca Ceresoli, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
> Hi Luca,
> Thanks for the review.
> I see your point about separation, but in this case I intended this as a single cohesive update to the driver rather than unrelated changes.
>
> The redundant lt9611c_reset() removals are cleanup to avoid unnecessary latency during enable/probe.
> The HDMI VSI infoframe callbacks are required to align with the DRM HDMI bridge framework expectations.
> The OF match data change ensures correct chip variant detection when probing via DT.
> The bridge vendor/product population improves user-visible HDMI connector reporting.

This a list of 4 things your patch does, and they seem fairly independent
from each other. That's a hint that they should probably be 4 patches.

If each is small, no problem.

An additional, pragmatic reason to split: if there's a bug in one of your
patches, it can be easily bisected and the problematic patch be reverted
without removing the other 3 patches.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com