arm64: dts: xilinx: fix zynqmp opp-table-cpu

arm64: dts: xilinx: fix zynqmp opp-table-cpu

Since the following commit, the zynqmp clk driver uses the common
divider_round_rate() when determining the appropriate clock divider for a
requested clock frequency:
https://github.com/torvalds/linux/commit/1fe15be1fb613534ecbac5f8c3f8744f757d237d

This means that all the calculations will be in kHz when determining the
appropriate clock divider for a given cpufreq request. The problem with this
is that the zynqmp.dtsi and zynqmp-clk-ccf.dtsi files have frequency
definitions in Hz, so when dividing requested values in kHz, errors can occur
with the rounding.

For example, the current pss_ref_clk frequency is 33333333 Hz which generates
a cpufreq parent clock frequency of 1199999988 Hz which is the same as the
highest opp-table-cpu frequency in the zynqmp.dtsi.

But if a user requests the value 1199999 kHz as recommended in the available
frequencies:

root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
299999 399999 599999 1199999
root@zynqmp:/ # echo 1199999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed

The calculation will be:
1199999988 / 1199999000 = 1.000001

This will get rounded up to a divider value of 2 giving the following result.

root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999

Also, if a user tries to work around this calculation by using any larger
values, it still will not fix the problem because the driver will use the
largest opp in kHz which leads to the same calculation error.

User requests 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed

Driver converts any value greater than 1199999 to the largest opp which is
1199999 and then calculates the divider value with the same calculation.

The calculation will still be:
1199999988 / 1199999000 = 1.000001

This will get rounded up to a divider value of 2 giving the following result.

root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999

This means there is no way to configure the zynqmp for the fastest opp using
the current dtsi files.

To fix this issue, this patch updates the zynqmp opp-table-cpu and
pss_ref_clk, so the clock rates are calculated correctly.

root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
300000 400000 600000 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
1200000

Signed-off-by: Neal Frager <neal.frager@amd.com>
Acked-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251111070555.1169130-1-neal.frager@amd.com