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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8b377d15-1fe3-42fb-b220-09f4e667f7da@ti.com>
Date: Thu, 20 Mar 2025 16:06:52 +0530
From: Yemike Abhilash Chandra <y-abhilashchandra@...com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, <mchehab@...nel.org>
CC: <linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <vaishnav.a@...com>, <u-kumar1@...com>, <r-donadkar@...com>
Subject: Re: [PATCH RFC] media: i2c: ds90ub960: Enable second i2c interface

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

On the physical connection, if we have one V3Link Fusion, where:
CSITX0 is connected to CSIRX0 and CSITX1 is connected to CSIRX1
and the following overlays are applied:

ti/k3-am68-sk-v3link-fusion-dual-csitx.dtbo \ (same overlay as in [1])
ti/k3-v3link-imx219-0-2.dtbo ti/k3-v3link-imx219-0-3.dtbo \
ti/k3-v3link-imx219-1-0.dtbo ti/k3-v3link-imx219-1-1.dtbo

and now each media graph will contain two IMX219 sensors and a
UB960 , with the same UB960 being emulated in both media graphs.
This configuration assigns CSITX0 to the first media
graph and CSITX1 to the second media graph and the
sensors in the first media graph are programmed using the
primary I2C bus, while the sensors in the second media graph
are programmed using the secondary I2C bus.

and this will not break the existing usage, as it will
dynamically check the overlay applied and use primary and
secondary I2C interface accordingly ( primary for Port4
CSITX0 and secondary for port5 CSITX1 )

> So I guess my question is, what's the target here, how did you test 
> this, etc?
> 

for the details I discussed above, I have attached detailed logs
including applying the v3link overlay [1] and sensor overlays
and setting up routes. I ran a free running capture after that.

[2]: 
https://gist.github.com/Yemike-Abhilash-Chandra/1afc731e098fd23cad32dd5438852219

>   Tomi
>