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

[Stephen Warren]

On 08/24/2016 05:44 AM, vinoth eswaran wrote:
> 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)
> {

I /believe/ support for the "higher oscillators is TBD" because there 
aren't any boards that actually use those frequencies, so whether 
they're supported isn't relevant at present.

> 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?

Certainly the Linux kernel clock driver isn't the first piece of kernel 
code to run, so the initial kernel boot will be at whatever frequency 
U-Boot set the CPU to.

> 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?

It'll be some part of the clock (drivers/clk/tegra) or cpufreq 
(drivers/cpufreq/tegra*) code.