Re: [PATCH 2/2] platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 ms

[Hans de Goede <hansg@kernel.org>]

Hi,

On 25-Jul-25 7:47 PM, Sakari Ailus wrote:
> Hi Hans, Andy,
> 
> On Fri, Jul 25, 2025 at 04:52:26PM +0200, Andy Shevchenko wrote:
>> On Fri, Jul 25, 2025 at 4:44 PM Hans de Goede <hansg@kernel.org> wrote:
>>>
>>> On HP laptops with an ov08x40 sensor the 25 ms delay coming from Intel's
>>> out of tree drivers is not enough. Testing has confirmed that 45 ms does
>>> work.
>>>
>>> Add a quirk to the int3472_gpio_map[] to increase the delay to 45 ms to fix
>>> probing of the ov08x40 sensor failing on these laptops.
>>>
>>> Note this only impacts laptops which actually use an ov08x40 sensor with
>>> a handshake GPIO.
>>
>> ...
>>
>>> +       /*
>>> +        * ov08x40 sensor with a handshake pin needs a 45 ms delay on some HP laptops
>>> +        * https://bugzilla.redhat.com/show_bug.cgi?id=2333331
>>> +        */
>>> +       { "OVTI08F4", INT3472_GPIO_TYPE_HANDSHAKE, INT3472_GPIO_TYPE_HANDSHAKE,
>>> +         false, "dvdd", 45 * USEC_PER_MSEC },
>>>  };
>>
>> My gut feeling is that this might be needed for most of the cameras
>> with the handshake signal. Do you have ones that work without this
>> delay?

For those laptops with the CV chip that Sakari talks about below,
25 ms, which is what is currently the default delay seems to be
enough.

> I'd expect this to depend on the CV chip, if not solely then primarily at
> least (firmware could play a part maybe??). Isn't there a way to figure
> that out?

These HP laptops do not appear to use a CV chip at all, yet they do
have a handshake signal... Specifically there is no CV / USBIO chip
on the USB bus and the I2c and GPIOs for the camera sensor come
directly from the main SoC.

With that said, even if there were a CV chip, then given all
the problems we're having with those I do not expect us to be
able to get this info from the CV chip.

Just getting the basic IO-expander functionality upstream has
been and still is a very troublesome process.

Which includes very different behavior between USBIO chips which report
the exact same firmware version, it looks like the fw-version reported
over USB does not always get updated in fw updates...

Regards,

Hans