Reduce reset time for OV5640

[AxelLin]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

When test OV5640 on ESP32S3, I notice the esp_camera_init() call takes 670ms which is much longer than I expect.
The reset() function in sensors/ov5640 has very long delay in:

1. 100ms delay before software reset
2. 100ms delay before write regs to sensor_default_regs
3. 100ms delay after write regs to sensor_default_regs

I'm wondering if these delays are required.
Is there anything mentioned these delays requirement in datasheet?
Test by removing all above delays, I cannot see any difference.
So I'm wondering if the is can be improved.
IMHO:

1. is not necessary.
   If it really needs delay for 2/3, 10ms should be enough (100ms is quite long period from h/w's point of view).

[me-no-dev]

I no longer recall, but this can and should definitely be tested with a few sensors to confirm (since there can be differences in sensor batches and settings selected). OV5640 does have an MCU inside the sensor.

[AxelLin]

I just check sensor_default_regs in ov5640_settings.h

In begin of sensor_default_regs, the first setting is to do software reset, it also
includes necessary delay after software reset. (Which means current code actually does software reset twice).
In the end of sensor_default_regs, it also adds delay 300ms after s/w power on.
So I think all the delays and the explicitly software reset call in reset() can be removed.

[github-actions]

This issue appears to be stale. Please close it if its no longer valid.

[AxelLin]

I think this issue is still valid and needs review.
In https://dlscorp.com/wp-content/uploads/2018/04/OmniVision-OV5640-Software-Application-Notes.pdf ,
it shows
write_i2c(0x3008, 0x82); // software reset, bit[7]
// delay 5ms

(i.e. no delay is required before software reset, and only 5 ms delay after software reset)

[github-actions]

This issue appears to be stale. Please close it if its no longer valid.