Re: [PATCH v4 3/6] media: i2c: ov5693: Gate the MIPI clock lane for non-continuous clock

[Fernando Rimoli <fernandorimoli11@gmail.com>]

Hi Jakob,

One follow-up question, because two later results bear on your unpatched
numbers and they do not agree with each other.

A Surface Pro 8 user ran the negative control, removing only the flagged
INT33BE entry for Tiger Lake. Without it his front camera streams on the
first capture after boot, with real image data, and every later capture in
that boot hangs at zero bytes. With the entry, every capture works.

A Surface Pro 7+ user then ran the same control on a machine that also
enumerates INT33BE on Tiger Lake, so the same configuration as yours, and
got the opposite: his first capture of that boot already returned zero
frames. He checked the journal to confirm nothing had opened the sensor
earlier in the boot.

So "works once per boot" describes one of those machines and not the other.
The Pro 8 user now suspects his own result is an artefact of how his machine
is set up: he streams an IR camera continuously for face unlock, so a
neighbouring CSI-2 port on the same ISYS was active during his first
capture. He is retesting with that stopped.

Your 3 of 20 is the measurement that would help separate these. Do you
remember whether your harness rebooted or power-cycled the sensor between
runs, or were all 20 opens inside a single boot?

Either answer is useful and neither needs a retest on your part. If all 20
were in one boot, then the machines genuinely differ and I will say so
rather than fold them into one story. If some followed a reboot or a power
cycle, that supports reading it as once per sensor power cycle, which I
would then describe as holding on some machines rather than as the general
behaviour.

I am only trying to describe the unpatched behaviour accurately, since the
current commit message says no frames arrive at all and all three results
contradict that in different ways.

Thanks,
Fernando