Re: [PATCH RFC] media: i2c: ds90ub960: Enable second i2c interface

From: Tomi Valkeinen
Date: Wed Apr 02 2025 - 07:28:19 EST

Hi,

On 20/03/2025 12:36, Yemike Abhilash Chandra wrote:
Hi Tomi

On 18/03/25 20:16, Tomi Valkeinen wrote:
Hi,

On 05/03/2025 14:17, Yemike Abhilash Chandra wrote:
The DS90UB960-Q1 includes a second I2C interface for independent control
of the deserializer and remote devices. However, the current driver does
not utilize it, thus restricting users to either CSI TX0 or CSI TX1 on
the primary I2C interface. Enable the second I2C interface, allowing
flexible routing where CSI TX0 can be used on the primary and CSI TX1 on
the secondary, or vice versa by enabling appropriate ports in DT. To
achieve the same only modify the bits relevant to the enabled RX and TX
ports of that interface and during probe and enable_streams call, few
registers were being reset to HW reset state, these operations are not
necessary for functionality and resets the state when secondary I2C
interface is probed, thus drop them.

I'm a bit confused about the description. My recollection is that both CSI TX0 and TX1 can be programmed just fine from the first I2C interface. Is that not so?


I apologize for not giving the entire context while sending the RFC.
The purpose of this patch is not only to enable secondary I2C interface
but also to overcome the v4l2 framework limitation by doing that.

Also, even if the driver supports both CSI TXes, at the moment v4l2 framework doesn't work with it, at least in many cases. E.g. if you connect one TX to a CSIRX, the other TX to another CSIRX, and those CSIRXes are independent, have their own media graphs, it's not going to work at all.


Lets say that the overlay applied is as shown in [1]

[1]: https://gist.github.com/Yemike-Abhilash- Chandra/5c53a5f3a77954b28c5bd4c27cd336a5

Ok. No, we can't merge anything like that. You're creating two linux devices for a single HW device, without any specific support for such. If it works for you, it's just by luck.

Tomi