[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[vinoth eswaran]

On Tue, Aug 23, 2016 at 6:09 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 08/23/2016 06:23 AM, vinoth eswaran wrote:
>>
>> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren at wwwdotorg.org>
>> wrote:
>>>
>>>
>>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>>
>>>>
>>>> Hello Developers,
>>>>
>>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>>> board. The Linux Kernel version is 4.7 and the u-boot version is
>>>> v2016.05.
>>>> I am building a customised Linux kernel and u-boot to have the fastest
>>>> boot
>>>> time possible.
>>>>
>>>> During Kernel startup I am seeing some error messages related to CPU
>>>> clock
>>>> frequencies like,
>>>>
>>>> [    0.000000] Tegra clk 127: register failed with -17
>>>>
>>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>>>> 696000 KHz
>>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
>>>> changed to: 714000 KHz
>>>>
>>>> On seeing the bootchart I have a feeling that the cpu clock frequency
>>>> might
>>>> be low - as lot of drivers are taking more time than usual, so I now
>>>> wish
>>>> to know what frequency does the cpu cores are running on during boot
>>>> time.
>>>> I am not clear on who is responsible(u-boot/kernel) for setting up the
>>>> cpu
>>>> clock frequency during the boot time.
>>>>
>>>> In u-boot which modules do I need to look to get information about cpu
>>>> frequency being set.
>>>
>>>
>>>
>>> This all happens on SoC-specific code; take a look at
>>> arch/arm/mach-tegra/.
>>>
>>> I don't immediately see anything that sets a particular clock rate for
>>> the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. I'm
>>> CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in
>>> arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL clock
>>> rates. However, I can't guarantee it'll print the correct rates; it's debug
>>> code that was added early on (i.e. prior to Tegra124 support being added) so
>>> it's possible it hasn't been updated to get the correct answer on more
>>> recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other PLL.
>>> You'd need to check which clock source is in use by reading the CAR
>>> registers; see the TRM for details of the CAR.
>>>
>>> Also note that the memory controller clock likely boots at a non-maximal
>>> rate. This is controlled by the BCT.
>>>
>>> Typically both the CPU clock and memory controller clock run at
>>> non-maximal rates at boot time, and hence during U-Boot. That's because
>>> using higher rates may (a) require PMIC programming, and (b) not be safe
>>> without active thermal management. I don't remember which frequency/voltage
>>> combinations are legal/tested/thermally-safe. If you need more details here,
>>> the NVIDIA L4T web forums are the best place to get answers; visit
>>> http://developer.nvidia.com/embedded-computing the follow the community
>>> link, then follow the forum link.
>>>
>>> Once the kernel boots, it is responsible for any clock management. If
>>> higher-than-default clocks are required, the kernel is responsible for
>>> selecting these.
>>
>>
>> After enabling the debug messages in clock.c and tegra124/clock.c I am
>> seeing the following messages during u-boot start up.
>>
> ...
>>
>> PLLX = 0
>
> ...
>>
>> periph 47, rate=6400000, reg=60006128 = 7e
>> Requested clock rate 6400000 not honored (got 6375000)
>
> ...
>>
>> I am seeing lot of requested clock rates are not honored, which I
>> assume to be meaning unable to set to the requested clock frequency
>> and other frequencies being set.
>
>
> Yes, the clock dividers can't generate every possible frequency, so they
> generate the closest possible value and emit a debug message just as a note.
> You can ignore these.
>
>> which is the frequency it is currently running on?
>
>
> PLLX = 0 above is obviously wrong. The only way to find out is to manually
> trace through the CAR registers to find the source the CPU is hooked to, and
> then trace through all the dividers.

In the arch/arm/mach-tegra/tegra124/clock.c file , I am seeing some
TBD features related to clock frequencies.

/*
 * Get the oscillator frequency, from the corresponding hardware configuration
 * field. Note that Tegra30+ support 3 new higher freqs, but we map back
 * to the old T20 freqs. Support for the higher oscillators is TBD.
 */
enum clock_osc_freq clock_get_osc_freq(void)
{

>From the logs and boot graph I feel that the Tegra cpu's are running
at low frequencies and it might be because u-boot has set the clock
frequency low. Is it so?

After cpu_freq driver is initialized the clock frequency is changed to 714 MHz.

[    8.646758] cpufreq: cpufreq_online: CPU0: Running at unlisted
freq: 696000 KHz
[    8.646980] cpufreq: cpufreq_online: CPU0: Unlisted initial
frequency changed to: 714000 KHz

Do you have any idea which part of kernel driver or initialization
phase is responsible to set the clock frequencies?