Skip to content

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

Open
Fishwaldo wants to merge 4 commits into
apache:masterfrom
Fishwaldo:upstream-eic7700x-clk
Open

arch/risc-v/eic7700x: Describe the clock tree.#19865
Fishwaldo wants to merge 4 commits into
apache:masterfrom
Fishwaldo:upstream-eic7700x-clk

Conversation

@Fishwaldo

@Fishwaldo Fishwaldo commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

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.

@github-actions github-actions Bot added Area: Build system Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces. Board: risc-v labels Aug 16, 2026
@github-actions

Copy link
Copy Markdown

❌ 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:

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

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

@github-actions

github-actions Bot commented Aug 16, 2026

Copy link
Copy Markdown

MemBrowse Memory Report

No memory changes detected for:

@Fishwaldo
Fishwaldo force-pushed the upstream-eic7700x-clk branch 2 times, most recently from bd5dc0c to 7822a96 Compare August 16, 2026 13:09
@linguini1

Copy link
Copy Markdown
Contributor

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

@github-actions

Copy link
Copy Markdown

🔗 Cross-repo PR dependencies

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

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

@Fishwaldo
Fishwaldo marked this pull request as draft August 16, 2026 16:55
@Fishwaldo

Fishwaldo commented Aug 16, 2026

Copy link
Copy Markdown
Contributor Author

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

Copy link
Copy Markdown

🔗 Cross-repo PR dependencies

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

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

@github-actions

Copy link
Copy Markdown

❌ 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:

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

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

Two declarations in eic7700x_start.c are followed immediately by a
statement, which nxstyle reports as "Missing blank line after
declarations".  Both predate this series and are already in master, but
CI runs checkpatch over the whole range rather than per commit, so any
change touching this file is reported against them.

Whitespace only, no functional change.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Nothing in this port knew what any clock ran at, so a driver needing a
rate had to carry a hard coded one, which is wrong the moment the boot
loader changes.

Register the Clock and Reset Generator 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.  The tree is 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 PLL post divider fields do not sit where the TRM's register diagram
puts them; they are ordered here to match the rates the tree reports.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The architecture registers the clock tree before the board runs, and every
driver the board brings up afterwards depends on it.  Report what
registered, so a tree that came up short is visible without a debug build.

eic7700x_clk_count() supplies the numbers; /proc/clk has the tree itself.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The console divisor was computed from 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 clock tree now reports lsp_uart0_pclk
at 200 MHz, and section 12.4.3.2 makes that clock the UART's baud
reference.

Also enable the fractional divisor.  These are DesignWare UARTs with DLF
implemented, four bits wide at offset 0xc0, which is where
UART_DLF_OFFSET lands once scaled by this board's register increment.
Section 12.4.3.2 works the same example at the same 200 MHz.

At 115200 the error goes from 1.41% to 0.006%.  The old figure with the
old divisor was tolerable; the margin only gets worse at higher rates.

DEBUG_CLK and DEBUG_CLK_ERROR are enabled so a clock that fails to
register is reported.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
@Fishwaldo
Fishwaldo force-pushed the upstream-eic7700x-clk branch from 601e8c4 to d6d7f68 Compare August 29, 2026 08:00
@github-actions

Copy link
Copy Markdown

❌ 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:

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

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

@Fishwaldo
Fishwaldo marked this pull request as ready for review August 29, 2026 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture Board: risc-v Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants