Re: Re: [RFC PATCH 6/8] media: i2c: ov2312: add Omnivison OV2312 driver

[Mirela Rabulea <mirela.rabulea@nxp.com>]

Hi Sakari,

On 10/6/26 10:36, Sakari Ailus wrote:
> Hi Mirela,
>
> On Fri, Oct 02, 2026 at 07:16:11PM +0300, Mirela Rabulea wrote:
>> Laurent, Hans, Sakari,
>>
>> did you encounter similar situations? Any comments or proposals? The concern
>> here, to summarize, is: v4l2 control cannot be committed to sensor registers
>> right away (even when streaming) and we are also unsure when the right
>> moment to perform the register access may come.
> In practice there's little the kernel overall can do about this: the timing
> of everything is handled by the userspace. Drivers that aren't directly in
> control of the data path don't even have frame timing information and even
> if we did pass that to drivers, I²C writes always have some uncertainty
> (system scheduling, I²C access failures etc.), so one needs to be prepared
> to failing to do the writes in time, which would further complicate the
> UAPI.

On the kerne side, what would help would be a way to make an atomic 
operation out of an i2c read (the status register to determine the 
active context) plus a group hold update (a few i2c register writes). I 
don't know if that is possible.

On the v4l2 API side, I believe the current expectation is that upon 
s_ctrl, if the value was accepted by the kernel, it will return success, 
but user-space should not assume frames will immediately reflect the new 
values.

Traditionally, with drivers I have seen so far, if s_ctrl is applied 
while streaming, it is applied immediately (but fail in case of i2c 
access failure). Upon success, captured frames will reflect the values 
after N+1 or N+2.

>
> Do you have libcamera in userspace or something else?

Yes, we experienced with libcamera. I can also reproduce the unwanted 
behavior with v4l2-ctl streaming + i2ctranfer script that stress the 
group hold writes.

If we were to place the responsibility on userspace/libcamera, than 
libcamera should be able to handle this:

- after a successful s_ctrl, captured frames will reflect the values 
after not N+2 but  X+N+2, where X can be anything because we do not know 
when we catch the right context to do the group hold access

- do not expect s_ctrl to fail, unless the value was not accepted; i2c 
access failures cannot be catched, because we cannot apply the control 
value instantly

- a control value may get accidentally applied to the wrong stream; 
because VC takes effect at frame N+1 and exposure and gain settings take 
effect at frame N+2, if the group write timing is improper, these may 
get out of sync; so user-space may see frames optimized for RGB on the 
stream that was supposed to be optimized for Ir or vice-versa, as 
confirmed by RishiKesh and Jai on ov2312.

- embedded data information may help identify what settings were 
actually applied for a particular captured frame (if embedded data is 
available reliably)

Regards,

Mirela

>
> --
> Kind regards,
>
> Sakari Ailus