[PATCH 0/4] (no cover subject)

[PATCH 0/4] (no cover subject)

[Mohit Dsor]

From: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Subject: [PATCH 0/4] LT9611C improvements and fixes updates

Hi,

This series contains improvements and fixes for the Lontium LT9611C
MIPI DSI to HDMI bridge driver, along with DT binding updates.

The key addition is support for selecting the DSI input port using
a new device tree property, which is required for configurations
using port B or dual-port (A+B) operation.

Summary of changes:
- Add DSI port selection support via DT property
- Fixes and improvements
- Increase MCU polling timeout for stability

- Add dt-binding for port configuration

Patches:

1. dt-bindings: bridge: lt9611c: add port-select property for LT9611C
2. drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
3. drm-bridge: lontium lt9611c: fixes and improvements
4. drm/bridge: lontium-lt9611c: Add DSI port selection via DT property

This has been tested on LT9611C-based platforms.
Please review.

Thanks,
Mohit

Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
Mohit Dsor (4):
      dt-bindings: brige: lt9611c: add port-select property for LT9611C
      drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
      drm-bridge: lontium lt9611c: fixes and improvements
      drm/bridge: lontium-lt9611c: Add DSI port selection via DT property

 .../bindings/display/bridge/lontium,lt9611.yaml    | 13 ++++
 drivers/gpu/drm/bridge/lontium-lt9611c.c           | 79 ++++++++++++++++++++--
 2 files changed, 85 insertions(+), 7 deletions(-)
---
base-commit: 7b61c580d964f499f3eaf96d6579a7127dda606b
change-id: 20260611-lt9611-b4-send-6f1d39c2d6d7
prerequisite-message-id: <20260420061644.1251070-1-syyang@lontium.com>
prerequisite-patch-id: 5e0ea8907c87174a28fac5456fc51183d8e8b36f
prerequisite-patch-id: 6fd8685174c2c83b8871d9e6419c6f3bd29ccc1a

Best regards,
--  
Mohit Dsor <mohit.dsor@oss.qualcomm.com>

[PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C

[Mohit Dsor]

Add a new optional `lontium,port-select` property to describe the DSI
input port configuration for the LT9611C variant, which supports
single-port (A or B) and dual-port (A+B) operation.

This property allows explicitly selecting the active DSI input port(s):
  0 = port A (default)
  1 = port B
  2 = ports A and B (dual-port)

Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
 .../devicetree/bindings/display/bridge/lontium,lt9611.yaml  | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
index e0821a63d9d7..77220f893bf8 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -41,6 +41,17 @@ properties:
   vcc-supply:
     description: Regulator for 3.3V IO power.
 
+  lontium,port-select:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [0, 1, 2]
+    default: 0
+    description: |
+      Selects which DSI input port(s) the bridge uses. Only relevant for
+      the lontium,lt9611c compatible.
+        0 = PORT_SELECT_A  - single DSI port A (default)
+        1 = PORT_SELECT_B  - single DSI port B
+        2 = PORT_SELECT_AB - dual DSI ports A and B
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
 
@@ -104,6 +115,8 @@ examples:
         vdd-supply = <&lt9611_1v8>;
         vcc-supply = <&lt9611_3v3>;
 
+        lontium,port-select = <1>;
+
         ports {
           #address-cells = <1>;
           #size-cells = <0>;

-- 
2.34.1

Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C

[Krzysztof Kozlowski]

On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> Add a new optional `lontium,port-select` property to describe the DSI
> input port configuration for the LT9611C variant, which supports
> single-port (A or B) and dual-port (A+B) operation.
> 
> This property allows explicitly selecting the active DSI input port(s):
>   0 = port A (default)
>   1 = port B
>   2 = ports A and B (dual-port)
> 
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml  | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> index e0821a63d9d7..77220f893bf8 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> @@ -41,6 +41,17 @@ properties:
>    vcc-supply:
>      description: Regulator for 3.3V IO power.
>  
> +  lontium,port-select:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [0, 1, 2]
> +    default: 0
> +    description: |
> +      Selects which DSI input port(s) the bridge uses. Only relevant for
> +      the lontium,lt9611c compatible.
> +        0 = PORT_SELECT_A  - single DSI port A (default)
> +        1 = PORT_SELECT_B  - single DSI port B
> +        2 = PORT_SELECT_AB - dual DSI ports A and B

Why graph is not enough? Seems exactly duplicating the graph ports.

Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C

[Mohit Dsor]

On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> > Add a new optional `lontium,port-select` property to describe the DSI
> > input port configuration for the LT9611C variant, which supports
> > single-port (A or B) and dual-port (A+B) operation.
> > 
> > This property allows explicitly selecting the active DSI input port(s):
> >   0 = port A (default)
> >   1 = port B
> >   2 = ports A and B (dual-port)
> > 
> > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> > ---
> >  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml  | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > index e0821a63d9d7..77220f893bf8 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > @@ -41,6 +41,17 @@ properties:
> >    vcc-supply:
> >      description: Regulator for 3.3V IO power.
> >  
> > +  lontium,port-select:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    enum: [0, 1, 2]
> > +    default: 0
> > +    description: |
> > +      Selects which DSI input port(s) the bridge uses. Only relevant for
> > +      the lontium,lt9611c compatible.
> > +        0 = PORT_SELECT_A  - single DSI port A (default)
> > +        1 = PORT_SELECT_B  - single DSI port B
> > +        2 = PORT_SELECT_AB - dual DSI ports A and B
> 
> Why graph is not enough? Seems exactly duplicating the graph ports.
> 
> Best regards,
> Krzysztof
>
Hi Krzysztof,

Thanks for the review.

The graph describes the physical connectivity between endpoints, however it does not fully capture the internal mode of operation of the LT9611C. This variant supports multiple functional configurations (single-port A, single-port B, or dual-port A+B), which affect how the hardware internally combines or selects DSI inputs.

In particular:
- The graph can describe connections to both ports, but it does not indicate whether the device should operate in single-port or dual-port aggregation mode.
- For single-port use, both ports may be described in DT for board consistency, while the driver still needs to know which port is actively selected.
- Dual-port mode requires explicit configuration even when both endpoints are present in the graph.

So, this property is not duplicating connectivity, but rather describing the *operational mode* of the device, which cannot be reliably inferred from the graph alone.

Thanks,
Mohit

Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C

[Laurent Pinchart]

On Mon, Jun 22, 2026 at 05:31:36PM +0530, Mohit Dsor wrote:
> On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
> > On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> > > Add a new optional `lontium,port-select` property to describe the DSI
> > > input port configuration for the LT9611C variant, which supports
> > > single-port (A or B) and dual-port (A+B) operation.
> > > 
> > > This property allows explicitly selecting the active DSI input port(s):
> > >   0 = port A (default)
> > >   1 = port B
> > >   2 = ports A and B (dual-port)
> > > 
> > > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> > > ---
> > >  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml  | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > index e0821a63d9d7..77220f893bf8 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > @@ -41,6 +41,17 @@ properties:
> > >    vcc-supply:
> > >      description: Regulator for 3.3V IO power.
> > >  
> > > +  lontium,port-select:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > +    enum: [0, 1, 2]
> > > +    default: 0
> > > +    description: |
> > > +      Selects which DSI input port(s) the bridge uses. Only relevant for
> > > +      the lontium,lt9611c compatible.
> > > +        0 = PORT_SELECT_A  - single DSI port A (default)
> > > +        1 = PORT_SELECT_B  - single DSI port B
> > > +        2 = PORT_SELECT_AB - dual DSI ports A and B
> > 
> > Why graph is not enough? Seems exactly duplicating the graph ports.
> > 
> > Best regards,
> > Krzysztof
> >
> Hi Krzysztof,
> 
> Thanks for the review.
> 
> The graph describes the physical connectivity between endpoints,
> however it does not fully capture the internal mode of operation of
> the LT9611C. This variant supports multiple functional configurations
> (single-port A, single-port B, or dual-port A+B), which affect how the
> hardware internally combines or selects DSI inputs.
> 
> In particular:
> - The graph can describe connections to both ports, but it does not
>   indicate whether the device should operate in single-port or dual-port
>   aggregation mode.
> - For single-port use, both ports may be described in DT for board
>   consistency, while the driver still needs to know which port is
>   actively selected.
> - Dual-port mode requires explicit configuration even when both
>   endpoints are present in the graph.

If both modes of operation are possible on a given board, then it sounds
like the mode should be selected at runtime, not hardcoded in the device
tree.

> So, this property is not duplicating connectivity, but rather
> describing the *operational mode* of the device, which cannot be
> reliably inferred from the graph alone.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C

[Krzysztof Kozlowski]

On 22/06/2026 14:08, Laurent Pinchart wrote:
> On Mon, Jun 22, 2026 at 05:31:36PM +0530, Mohit Dsor wrote:
>> On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
>>> On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
>>>> Add a new optional `lontium,port-select` property to describe the DSI
>>>> input port configuration for the LT9611C variant, which supports
>>>> single-port (A or B) and dual-port (A+B) operation.
>>>>
>>>> This property allows explicitly selecting the active DSI input port(s):
>>>>   0 = port A (default)
>>>>   1 = port B
>>>>   2 = ports A and B (dual-port)
>>>>
>>>> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
>>>> ---
>>>>  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml  | 13 +++++++++++++
>>>>  1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> index e0821a63d9d7..77220f893bf8 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> @@ -41,6 +41,17 @@ properties:
>>>>    vcc-supply:
>>>>      description: Regulator for 3.3V IO power.
>>>>  
>>>> +  lontium,port-select:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    enum: [0, 1, 2]
>>>> +    default: 0
>>>> +    description: |
>>>> +      Selects which DSI input port(s) the bridge uses. Only relevant for
>>>> +      the lontium,lt9611c compatible.
>>>> +        0 = PORT_SELECT_A  - single DSI port A (default)
>>>> +        1 = PORT_SELECT_B  - single DSI port B
>>>> +        2 = PORT_SELECT_AB - dual DSI ports A and B
>>>
>>> Why graph is not enough? Seems exactly duplicating the graph ports.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> Hi Krzysztof,
>>
>> Thanks for the review.
>>
>> The graph describes the physical connectivity between endpoints,
>> however it does not fully capture the internal mode of operation of
>> the LT9611C. This variant supports multiple functional configurations
>> (single-port A, single-port B, or dual-port A+B), which affect how the
>> hardware internally combines or selects DSI inputs.
>>
>> In particular:
>> - The graph can describe connections to both ports, but it does not
>>   indicate whether the device should operate in single-port or dual-port
>>   aggregation mode.
>> - For single-port use, both ports may be described in DT for board
>>   consistency, while the driver still needs to know which port is
>>   actively selected.
>> - Dual-port mode requires explicit configuration even when both
>>   endpoints are present in the graph.
> 
> If both modes of operation are possible on a given board, then it sounds
> like the mode should be selected at runtime, not hardcoded in the device
> tree.

Yeah. Especially "while the driver still needs to know which port is
actively selected" for a case when DT already clearly defines which
ports are available, feels like 100% runtime decision, e.g. based on
what is actually plugged into the connector.

Best regards,
Krzysztof

[PATCH 2/4] drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms

[Mohit Dsor]

The on-chip MCU may take longer than 100ms to respond on some hardware
variants or slower I2C buses, causing spurious -ETIMEDOUT errors during
normal operation. Double the poll timeout from 100ms to 200ms to improve
reliability without changing the poll interval.

Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
 drivers/gpu/drm/bridge/lontium-lt9611c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
index cb584855fd8f..b0402726367e 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
@@ -97,7 +97,7 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
 	regmap_write(lt9611c->regmap, 0xe0de, 0x01);
 
 	ret = regmap_read_poll_timeout(lt9611c->regmap, 0xe0ae, temp,
-				       temp == 0x01, 1000, 100 * 1000);
+				       temp == 0x01, 1000, 200 * 1000);
 	if (ret)
 		return -ETIMEDOUT;
 
@@ -107,7 +107,7 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
 	regmap_write(lt9611c->regmap, 0xe0de, 0x02);
 
 	ret = regmap_read_poll_timeout(lt9611c->regmap, 0xe0ae, temp,
-				       temp == 0x02, 1000, 100 * 1000);
+				       temp == 0x02, 1000, 200 * 1000);
 	if (ret)
 		return -ETIMEDOUT;
 

-- 
2.34.1

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

[Mohit Dsor]

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>
---
 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;
+}
+
 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;
+	}
+
 	ret = devm_mutex_init(dev, &lt9611c->ocm_lock);
 	if (ret)
 		return dev_err_probe(dev, ret, "failed to init mutex\n");
@@ -1111,6 +1130,9 @@ static int lt9611c_probe(struct i2c_client *client)
 			DRM_BRIDGE_OP_HDMI_AUDIO;
 	lt9611c->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 
+	lt9611c->bridge.vendor = "Lontium";
+	lt9611c->bridge.product = "LT9611C";
+
 	lt9611c->bridge.hdmi_audio_dev = dev;
 	lt9611c->bridge.hdmi_audio_max_i2s_playback_channels = 8;
 	lt9611c->bridge.hdmi_audio_dai_port = 2;
@@ -1136,7 +1158,6 @@ static int lt9611c_probe(struct i2c_client *client)
 	lt9611c->hdmi_connected = false;
 	i2c_set_clientdata(client, lt9611c);
 	enable_irq(client->irq);
-	lt9611c_reset(lt9611c);
 
 	return 0;
 
@@ -1214,9 +1235,9 @@ static struct i2c_device_id lt9611c_id[] = {
 };
 
 static const struct of_device_id lt9611c_match_table[] = {
-	{ .compatible = "lontium,lt9611c" },
-	{ .compatible = "lontium,lt9611ex" },
-	{ .compatible = "lontium,lt9611uxd" },
+	{ .compatible = "lontium,lt9611c",   .data = (void *)CHIP_LT9611C   },
+	{ .compatible = "lontium,lt9611ex",  .data = (void *)CHIP_LT9611EX  },
+	{ .compatible = "lontium,lt9611uxd", .data = (void *)CHIP_LT9611UXD },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, lt9611c_match_table);

-- 
2.34.1

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

[Luca Ceresoli]

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

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

[Mohit Dsor]

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.

All of these are small, tightly scoped updates that improve correctness, framework compliance, and observability of the same driver without introducing independent functional changes.
Given that, I felt keeping them together makes the update easier to review in context. However, I can split them if you strongly prefer that.
Regards,
Mohit

[PATCH 4/4] drm/bridge: lontium-lt9611c: Add DSI port selection via DT property

[Mohit Dsor]

Some board designs connect only DSI port B, or both DSI ports A and B,
to the LT9611C. Add support for a 'lontium,port-select' DT property that
allows the board DTS to specify which DSI port(s) the chip should use:

  0 = PORT_SELECT_A  (default, single DSI port A)
  1 = PORT_SELECT_B  (single DSI port B)
  2 = PORT_SELECT_AB (dual DSI ports A+B)

When the property is absent the driver defaults to PORT_SELECT_A (0),
preserving backward compatibility with existing DTS files.

The selected port is programmed into the chip via lt9611c_select_port()
during probe, after the chip ID has been verified.

Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
 drivers/gpu/drm/bridge/lontium-lt9611c.c | 44 ++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
index fe51f4978546..5d67bb7391fb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
@@ -41,6 +41,12 @@ enum lt9611_chip_type {
 	CHIP_LT9611UXD,
 };
 
+enum lt9611c_PORT_SELECT {
+	PORT_SELECT_A  = 0,
+	PORT_SELECT_B  = 1,
+	PORT_SELECT_AB = 2,
+};
+
 struct lt9611c {
 	struct device *dev;
 	struct i2c_client *client;
@@ -60,6 +66,8 @@ struct lt9611c {
 	enum lt9611_chip_type chip_type;
 	 /* HDMI cable connection status */
 	bool hdmi_connected;
+	/* Selected DSI port configuration */
+	int selected_port;
 };
 
 DECLARE_CRC8_TABLE(lt9611c_crc8_table);
@@ -115,6 +123,34 @@ static int lt9611c_read_write_flow(struct lt9611c *lt9611c, u8 *params,
 				return_count);
 }
 
+static int lt9611c_select_port(struct lt9611c *lt9611c, int port_select)
+{
+	int ret;
+	u8 set_port_select_cmd[6] = {0x57, 0x4d, 0x31, 0x3a, 0x01, 0xc0};
+	u8 set_port_select_ret[5];
+
+	if (port_select == PORT_SELECT_B) {
+		set_port_select_cmd[5] = 0x40;
+	} else if (port_select == PORT_SELECT_AB) {
+		set_port_select_cmd[4] = 0x02;
+		set_port_select_cmd[5] = 0xd0;
+	} else if (port_select != PORT_SELECT_A) {
+		return -EINVAL;
+	}
+
+	/* MCU must be running (0xe0ee=0x00) for lt9611c_read_write_flow */
+	guard(mutex)(&lt9611c->ocm_lock);
+
+	ret = lt9611c_read_write_flow(lt9611c, set_port_select_cmd,
+			ARRAY_SIZE(set_port_select_cmd),
+			set_port_select_ret,
+			ARRAY_SIZE(set_port_select_ret));
+	if (ret < 0 || set_port_select_ret[4] == 0)
+		return ret < 0 ? ret : -EIO;
+
+	return 0;
+}
+
 static void lt9611c_config_parameters(struct lt9611c *lt9611c)
 {
 	const struct reg_sequence seq_write_paras[] = {
@@ -924,6 +960,10 @@ static int lt9611c_parse_dt(struct device *dev,
 
 	lt9611c->dsi1_node = of_graph_get_remote_node(dev->of_node, 1, -1);
 
+	if (of_property_read_u32(dev->of_node, "lontium,port-select",
+				 &lt9611c->selected_port))
+		lt9611c->selected_port = 0;
+
 	return drm_of_find_panel_or_bridge(dev->of_node, 2, -1, NULL, &lt9611c->bridge.next_bridge);
 }
 
@@ -1070,6 +1110,10 @@ static int lt9611c_probe(struct i2c_client *client)
 
 	lt9611c_reset(lt9611c);
 
+	ret = lt9611c_select_port(lt9611c, lt9611c->selected_port);
+	if (ret < 0)
+		dev_err(lt9611c->dev, "failed to select port %d\n", lt9611c->selected_port);
+
 	lt9611c_lock(lt9611c);
 
 	ret = lt9611c_read_chipid(lt9611c);

-- 
2.34.1