From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
vaishnav.a@ti.com, u-kumar1@ti.com, r-donadkar@ti.com,
mchehab@kernel.org
Subject: Re: [PATCH RFC] media: i2c: ds90ub960: Enable second i2c interface
Date: Wed, 2 Apr 2025 14:27:57 +0300 [thread overview]
Message-ID: <0e9cef43-0f15-497c-9781-d31e5cd0adb7@ideasonboard.com> (raw)
In-Reply-To: <8b377d15-1fe3-42fb-b220-09f4e667f7da@ti.com>
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
prev parent reply other threads:[~2025-04-02 11:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 12:17 Yemike Abhilash Chandra
2025-03-18 14:46 ` Tomi Valkeinen
2025-03-20 10:36 ` Yemike Abhilash Chandra
2025-04-02 11:27 ` Tomi Valkeinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e9cef43-0f15-497c-9781-d31e5cd0adb7@ideasonboard.com \
--to=tomi.valkeinen@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=r-donadkar@ti.com \
--cc=u-kumar1@ti.com \
--cc=vaishnav.a@ti.com \
--cc=y-abhilashchandra@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®