how to set core's frequency and voltage separately

Hi,

I am doing my experiments to explore the voltage limitation. http://elinux.org/Jetson/Performance says how to tune the voltage/frequency, but voltage and frequency change simultaneously. I can change from 1.24GHz/1.05V to 1.12GHZ/1.00V, for example. I want to how to decouple the voltage and frequency scaling. For example, fix the frequency to 1.24GHz but adjust the voltage from 1.05V to 1.04V. Do TK1 provides an interface to do that?

Thanks.

You might want to see if the pin was exported. Do you see the correct pin in “/sys/class/gpio/”? Further in you’ll see a symbolic link named after the specific controller of the gpio pin (the hex address). If you run “find /sys -name ‘gpio’” you may find other indications as to what else might be using the pin.
See the next reply instead.

I have a further question

Thank you @linuxdev.
So you mean I should first find out which pin is related to voltage/frequency, then check if it is exported. If yes, I can modify the value to set the voltage/frequency. Am I correct? Also, can I set different voltage for different cores?

It looks like my first answer was actually a cross post meant for another gpio thread (I’m not sure how that would happen other than my being asleep at the time…there was actually another thread this would be the answer for). In terms of performance there won’t be a gpio pin for changing things.

Voltage and frequency settings which are available come from dvfs tables, so the values are not necessarily independent (a number of values are set simultaneously based on one row of a table). If you look at the kernel source, and search for files ending in “*dvfs.c” or “*dvfs.h”, you’ll see which values the kernel will allow. Reducing frequency also reduces the need for voltage…and increasing frequency voltage required goes up (you could use more voltage than needed, or lower frequency than needed, but not the other way around…it’s just that it is either a waste or a possibility of damage as to why you wouldn’t want to maintain too high of a voltage for a given frequency).

If you want to make more combinations available (not recommended if it exceeds voltage at a given frequency, voltage in peak, or frequency in peak), then you’ll probably be interested in the tegra12 series of dvfs files (tegra12x is the SoC series, tegra124 is specific to the JTK1). For example, as a starting point, look at the struct values initialized in:

arch/arm/mach-tegra/tegra12_dvfs.c

Notice some of those table lines correspond to values accepted in the “/sys” performance settings.

Thank you so much. I find the dvfs table at /sys/kernel/debug/clock/dvfs_table. I guess cpu_g is the frequency, but what’s different
between the vdd_cpu and vdd_cpu(dfll)? It seems the dvfs table is established at “cpu_cvb_dvfs_table” function in tegra12_dvfs.c file. Is it correct? Can I just change some values of that function to implement my own dvfs strategy?

Why I want to do this that I want to capture errors. Theoretically, a lower voltage increases the delay of the critical path, and if the clock frequency is still high, the hardware, e.g., adder, reports an error. But with the default dvfs, a lower voltage automatically leads to a lower frequency, so no error anymore.

I’ve not been brave enough to force invalid values, but the the method for finding weak points via higher clocks without increases in voltage seems sound. I do not know what each clock value is, so I’m not sure which value would change what. What I’d advise is to step through each clock (via sysfs echo) and watch voltage change, then compare to lines out of the dvfs tables. Whatever sysfs calls it is probably the best clue…how the other values from the tables change or don’t change between those other frequency and voltage changes would give a good idea what value they need even if you don’t know the exact meaning. I would expect that there may be more than one version of a table depending on what power mode it is in at the time. Someone who knows more about specific clocks could probably answer without guessing.