dts: stm32h5: Add DCMI device information

[idekine]

The STM32H5 dtsi file lacked DCMI device driver information, despite this SoC family containing a DCMI device driver. This adds device support for DCMI on the STM32H5.

[github-actions]

Hello @idekine, 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. 😊

[josuah]

Glad to see the existing drivers are drop-in compatible. Thank you for testing it!

[josuah]

Taking inspiration from #86690 (comment)
It seems like DCMI is absent from STM32H503xx. Maybe this will need to be put in a SoC-specific .dtsi file rather than in the shared .dsti.

[josuah]

@erwango / @JarmouniA what would be the best way to handle this? maybe adding DCMI it to each of these files except the h503?

[idekine]

You bring up a good point @josuah, I appreciate you pointing out that there is an issue that I didn't notice.

Looking further, it seems even that might not be granular enough, since there is bifurcation even within particular SoCs, e.g. the STM32H533 HE/CE vs RE/VE/ZE (see page 15 of the datasheet). However, it looks like stm32h533.dtsi ignores the issue with FMC, which has the same inconsistency across STM32H533, so I'm inclined to put it there and also in stm32h562.dtsi (which gets included by STM32H563 and 573 dtsi files).

I definitely would like to hear @erwango opinion, and I'll be happy to update this as suggested.

(edited to fix a mistake about the dtsi include structure)

[JarmouniA]

It seems like DCMI is absent from STM32H503xx. Maybe this will need to be put in a SoC-specific .dtsi file rather than in the shared .dtsi.

We can leave it in the root dtsi then use \delete-node\ dcmi; in the files of SoCs that don't have it.

[idekine]

Updated per @JarmouniA to use delete-node to remove from STM32H503xx SoCs

[erwango]

I'm a bit late on this, but I'd prefer to put this node in h533 and h562 (and then use \delete-node\ in HE/CE).
Idea is to minimize the use of \delete-node\ (allowing it in package variants) otherwise this could quickly become a mess to maintain.

[mathieuchopstm]

Nit:

[mathieuchopstm]

Suggested change

	clocks = <&rcc STM32_CLOCK(AHB2, 12U)>;
	clocks = <&rcc STM32_CLOCK(AHB2, 12)>;

[josuah]

The CI test system currently complains about this:

1: UC3 Commit title does not follow [subsystem]: [subject] (and should not start with literal subsys or treewide): "Use delete-node to remove non-existant DCMI from STM32H503xx SoCs"
1: UC6 Commit message body is empty, should at least have 1 line(s).

Here is an example commit message (but use anything you want):

dts: stm32h5: remove the DCMI node where absent

Use delete-node to remove non-existant DCMI from STM32H503xx SoCs

Signed-off-by: Isaac Dekine <[email protected]>

[erwango]

See #88805 (comment)