drivers: video: Add ov5642 camera driver

[hardevsinh-1]

Add driver to support ov5642 camera sensor

[github-actions]

Hello @hardevsinh-1, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[avolmat-st]

Thanks @hardevsinh-1 for this PR.

There is already an existing driver for the OV5640 sensor. Having very very rapidly checked the difference between the OV5642 and the OV5640, it seems that the OV5642 has less features than the OV5640, having for example only DVP support and limited to 720p maximum frames.
However, considering the numbering of the sensor I am wondering if the sensor behavior might be close enough to the OV5640 so that we could reuse the OV5640 sensor driver to also drive this new OV5642 sensor.
If that is so, and OV5642 is a "subset" of the OV5640, we might be able to make some of the OV5640 features optional or at least checked at runtime if applicable and have both OV5640 / OV5642 handled by the same driver.

Do you know the differences between the OV5640 and the OV5642 and the difference in the way to control it ? Looking very rapidly, it seems that at least on some aspects it is very similar to the OV5640.

Of course if the sensor are very different or if the way to control them is very different, then it makes sense to have a different driver.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
7.3% Duplication on New Code

See analysis details on SonarQube Cloud

[hardevsinh-1]

Thanks @hardevsinh-1 for this PR.

There is already an existing driver for the OV5640 sensor. Having very very rapidly checked the difference between the OV5642 and the OV5640, it seems that the OV5642 has less features than the OV5640, having for example only DVP support and limited to 720p maximum frames. However, considering the numbering of the sensor I am wondering if the sensor behavior might be close enough to the OV5640 so that we could reuse the OV5640 sensor driver to also drive this new OV5642 sensor. If that is so, and OV5642 is a "subset" of the OV5640, we might be able to make some of the OV5640 features optional or at least checked at runtime if applicable and have both OV5640 / OV5642 handled by the same driver.

Do you know the differences between the OV5640 and the OV5642 and the difference in the way to control it ? Looking very rapidly, it seems that at least on some aspects it is very similar to the OV5640.

Of course if the sensor are very different or if the way to control them is very different, then it makes sense to have a different driver.

@avolmat-st, Thanks for the review.
After comparing the OV5640 and OV5642 sensors and their drivers, here are the key points:

• Register maps differ (clock, PLL, exposure, gain, and ISP controls).
• OV5642 lacks AF and advanced ISP blocks present in OV5640.
• DVP timing parameters also differ, and applying OV5640’s settings leads to jitter or frame corruption.
• The initialization flow and power-up timings differ , reusing OV5640’s sequence causes I²C lockups. Sharing one driver would add unnecessary complexity.

Given these differences, what would you recommend ?