Fix renesas pll clock config

[duynguyenxa]

The new update of clock device tree make the pll p q r clock source cannot be chosen
This fix adds 1 new dts binding for pll out p q r out line so that it can be select by others module
Change clock div value get in clock control driver to get direct value from device tree instead of via hal API.

Fix for PR: #78365

Fixes #80889

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_renesas	zephyrproject-rtos/hal_renesas@3dafd03	zephyrproject-rtos/hal_renesas@1032651 (main)	zephyrproject-rtos/[email protected]

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[KhiemNguyenT]

Please update the commit ID.

[soburi]

The frequency originally input to the PLL is multiplied and divided by PLLMUL and PLLDIV, and the divided frequency is then further divided by P, Q, and R to determine the frequency.
Is the frequency set here reflecting PLLMUL and PLLDIV?
I would like to find this calculately if possible, but if it becomes too complicated I think this is fine.

[duynguyenxa]

@soburi , The fix is not relate to the calculation of PLL P Q R frequency but to separate them as device node so that other node can choose them as clock source, the previous patch only allow the node to choose <&pll> as clock source, now we can set <&pllp>, <&pllq>, <&pllr>. Frequency calculation is as your understanding.
Your request here is to create a macro for the frequency calculation instead of set them on device tree, is my understanding correct ?

[soburi]

@duynguyenxa

I understood why the change is necessary.
This change separates PLLP, Q, and R into independent nodes, so I think it becomes necessary to correctly express their relationship with the PLL.

What I'm paying attention to is whether the device tree give an appropriate expression for the hardware configuration.

From the register configuration, it appears that PLLP, Q, and R are dividers that use the PLL as their source, so I don't think they have frequency attributes here, these has only 'ratio'.
Instead, I think we need to calculate the relationship to the PLL.
This is why we need a frequency calculation macro.

I think that a "fixed-factor-clock" like definition can be used for this node.

[duynguyenxa]

@soburi , I got it, I think for each clock node here we will need a clock driver to provide enough information for the child node, current clock design for now there is no good way to get pll frequency. So now, to keep it simple I would like to keep this implementation,
Next patch for clock driver we will update driver for each clock node and change PLL Q P R into fixed-factor-clock.

[soburi]

I think there is no problem with proceeding as is, but if possible, it may be preferable to incorporate this change into 4.0.0 as well, since this would not result in any changes to the external interface.

[thaoluonguw]

Hello @nordic-krch , this is bug fixing for RA8. May I confirm that it can be merged in v4.0.0 RC2?

[mmahadevan108]

@duynguyenxa Can you please add an issue with details and link that issue to this PR. After RC2 only bug fixes with an associated Github issue will be merged into the upcoming 4.0 release.

[duynguyenxa]

@duynguyenxa Can you please add an issue with details and link that issue to this PR. After RC2 only bug fixes with an associated Github issue will be merged into the upcoming 4.0 release.

@mmahadevan108 , I created #80889 ticket for this PR