arch/risc-v/eic7700x: Add CPU core clock control. - #20065
Merged
Conversation
Drives the speed of the four application cores. The rate is set to any of the operating points the vendor validates, all of which share a core voltage, so this touches no regulator. The cores run from the PLL being reprogrammed, so they park on a slower clock first, through a selector the vendor names as glitch free. While parked the PLL is stopped, given new dividers, restarted and watched until it locks; if it never locks the cores stay parked, since returning them to an unlocked PLL does not fail safely. Above a gigahertz the bus ratio must be two to one before the cores return: the bus fabric does not reach beyond about eight hundred megahertz. That is the one step in the sequence software cannot recover from, so the mux is moved before the ratio. The rate is measured rather than derived. The cores are counted against the crystal derived time counter and the result reported beside what the clock tree computes, because the manual and the vendor's code number the CPU PLL's outputs differently. The core selector's parent is cpupll_fout1, and the three CPU PLL outputs are marked CLK_GET_RATE_NOCACHE since this driver reprograms that PLL at run time. Assisted-by: Claude:claude-opus-5 Signed-off-by: Justin Hammond <justin@dynam.ac>
github-actions
Bot
added
Area: Documentation
|
xiaoxiang781216
approved these changes
Sep 6, 2026
acassis
approved these changes
Sep 6, 2026
Contributor
|
Hello @acassis , can you revert this PR temporarily, please? Please check file |
Contributor
but the added Kconfig seems fine: 
Probably the unpaired Kconfig is commit from other Kconfig, let's find it |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A driver for the speed of the four application cores. It sets the rate to any
of the operating points the vendor validates, and reports the rate at start up:
Every operating point shares a core voltage, so this touches no regulator.
How the rate is set
The cores run from the PLL being reprogrammed, so they park on a slower clock
first, through a selector the vendor names as glitch free. While parked the PLL
is stopped, given new dividers, restarted and watched until it locks. If it
never locks the cores stay parked: returning them to an unlocked PLL does not
fail safely.
Above a gigahertz the bus ratio must be two to one before the cores return,
because the bus fabric does not reach beyond about eight hundred megahertz. The
mux is therefore moved before the ratio. That ordering is the one step in the
sequence software cannot recover from, and it is commented as such at the site.
How the rate is read
Measured, not derived: the cores are counted against the crystal derived time
counter, because the manual and the vendor's code number the CPU PLL's outputs
differently. The measurement is reported beside what the clock tree computes so
the two can be compared on any board.
Two consequences for
eic7700x_clk.c: the core selector's parent iscpupll_fout1, and the three CPU PLL outputs areCLK_GET_RATE_NOCACHE, sincethis driver reprograms that PLL at run time and the framework computes rates
from the registers.
Testing
Built with
-Wno-cpp -Werrorforeic7700-evb:nsh, and booted on the ESWINEIC7700 EVB, where the measurement reads 1399 to 1400 MHz against a tree that
computes 1400.
tools/checkpatch.sh -c -u -m -g master..HEADpasses.Depends on nothing; the clock tree merged as #19865.
It is a prerequisite for the EIC7700X devfreq driver, which follows in its
own PR and calls
eic7700x_cpuclk_setrate()to give the thermal governorsomething to slow down.