arch/risc-v/eic7700x: Describe the clock tree.

[Fishwaldo]

Summary

This PR is one commit, based on master, carrying only the clock driver. CI
composes it with #19863 through the Depends-On: declaration below. Two
small board-side commits (reporting the tree at startup, and correcting the
UART reference clock in the defconfigs) touch files #19863 creates, so they
cannot ride on a master-based branch; they follow as an update here once
#19863 merges.

Nothing in this port knew what any clock ran at, so a driver needing a rate
carried a hard coded one, which is wrong as soon as the boot loader changes.

The clock tree. The Clock and Reset Generator is registered with the NuttX
clock framework: the PLLs, muxes, dividers and gates covering the low speed
peripherals, the U84 cluster, the RTC and timers, the NOC, boot SPI, SCPU,
LPCPU, DDR and TCU, the high speed peripherals, the always on DMA and secure
blocks, the GPU, DSP, die to die link and NPU, and the video input, output and
codec paths. 264 clocks, visible through /proc/clk.

Registration writes nothing: the tree comes up describing what the boot loader
left behind. A clock moves only when a driver asks, by enabling a gate, setting
a divider or reparenting a mux. A mux carrying a clock the system is running on
will speed up on request and refuses to slow down, because that changes the
timing every driver downstream was configured for while they are using it.

The board reports what registered, so a tree that came up short is visible
without a debug build:

clk: registered 264 clocks, 0 failed

The UART reference clock was 198144000, a figure with no source in the
manual, the vendor tree or Linux, all of which give the low speed peripheral
clock as 200 MHz. The tree now reports lsp_uart0_pclk at 200 MHz, and section
12.4.3.2 makes that clock the UART's baud reference. The fractional divisor is
enabled with it: these are DesignWare UARTs with DLF implemented, four bits
wide at offset 0xc0. At 115200 the error goes from 1.41% to 0.006%.

Errors that mean the tree did not come up — a clock that fails to register, and
an orphaned clock — are reported with syslog(LOG_ERR) so they survive a
release build, since the DEBUGPANIC() that follows the second does not.
Conditions a caller already learns about from an errno stay on the gated
clkerr()/clkwarn() macros.

Impact

EIC7700X boards only. DEBUG_CLK and DEBUG_CLK_ERROR are enabled in both
board configurations; DEBUG_CLK_INFO is not, so the tree is described but not
narrated. No effect on any other architecture.

Testing

EIC7700 EVB:

[CPU0] clk: registered 264 clocks, 0 failed

nsh> cat /proc/clk
   clock                                  enable_cnt        rate       phase
ext_mclk                                           0           0           0
lpddr_ref_bak                                      0    50000000           0
xtal_32k                                           0       32768           0
xtal_24m                                           5    24000000           0
  gpu_gray_clk                                     0    24000000           0
  clk_lpcpu_core_src                               0    24000000           0
    clk_lpcpu_core                                 1    24000000           0
  timer0_clk                                       1    24000000           0
  cpupll_fout1                                     1  1400000000           0
    clk_u84_core                                   0  1400000000           0
      u84_core0_clk                                1  1400000000           0

264 clocks, with the U84 cores at the 1.4 GHz the tree derives rather than a
figure written down anywhere. The console runs at 115200 off the corrected
200 MHz reference for the whole of this boot, including the dump above.

StarPro64 builds.

The boot log above comes from the full stack on the EVB, including the two
board-side commits that will follow #19863. The driver itself is entirely
behind CONFIG_EIC7700X_CLK, which no in-tree defconfig sets yet, so CI
proves the compose and the build but does not execute this code.

Depends-On: #19863

[github-actions]

❌ Cross-repo dependency could not be applied

The Build report says the declared dependency PR(s) could not be applied, so CI did not run against the combined code:

• boards/risc-v/eic7700x: Add the ESWIN EIC7700 EVB and share the SoC glue. #19863
• drivers/pinctrl, drivers/clk: Add debug output levels. #19864

Reason: cherry-pick failed (if your PR has merge commits, rebase instead)

CI run: https://github.com/apache/nuttx/actions/runs/31945069105

[github-actions]

MemBrowse Memory Report

hifive1-revb

• flash: .text -4 B (-0.0%, 83,376 B / 4,194,304 B, total: 2% used)

qemu-armv8a

• Code: .text.exec_builtin +8 B (+0.0%, 319,072 B)
  No memory changes detected for:
• arduino-mega2560
• esp32-devkitc
• mirtoo
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[linguini1]

This is a massive change! Can you please submit in multiple PRs?

[github-actions]

🔗 Cross-repo PR dependencies

The read-only Build run reported the following dependent PR(s) and fetched head SHA(s):

• boards/risc-v/eic7700x: Add the ESWIN EIC7700 EVB and share the SoC glue. #19863 @ ddddf0d

CI run: https://github.com/apache/nuttx/actions/runs/31949018880

[Fishwaldo]

Converting to draft: the diff currently shows this PR's prerequisites (#19863 and the now-merged #19864) as well as its own changes, which makes it impossible to review.

Once #19863 lands, I'll rebase to carry only the clock-tree changes and marked ready for review again.

(Stacked PR's and that Depends On workflow got me hopeful I could land a whole bunch of EIC PR's in succession. Guess I'll just have to be patient instead!)

[github-actions]

🔗 Cross-repo PR dependencies

The read-only Build run reported the following dependent PR(s) and fetched head SHA(s):

• boards/risc-v/eic7700x: Add the ESWIN EIC7700 EVB and share the SoC glue. #19863 @ ddddf0d

CI run: https://github.com/apache/nuttx/actions/runs/32026730309