Re: [RFC-next 0/1] Odroid C2: Enable DVFS for cpu

From: Anand Moon
Date: Fri Dec 13 2019 - 06:28:29 EST

Hi Martin

On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl
<martin.blumenstingl@xxxxxxxxxxxxxx> wrote:
>
> Hi Neil,
>
> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote:
> >
> > On 10/12/2019 22:47, Kevin Hilman wrote:
> > > Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> writes:
> > >
> > >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@xxxxxxxxxxxx> wrote:
> > >>>
> > >>> Anand Moon <linux.amoon@xxxxxxxxx> writes:
> > >>>
> > >>>> Hi Neil / Kevin,
> > >>>>
> > >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote:
> > >>>>>
> > >>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
> > >>>>>> Anand Moon <linux.amoon@xxxxxxxxx> writes:
> > >>>>>>
> > >>>>>>> Some how this patch got lost, so resend this again.
> > >>>>>>>
> > >>>>>>> [0] https://patchwork.kernel.org/patch/11136545/
> > >>>>>>>
> > >>>>>>> This patch enable DVFS on GXBB Odroid C2.
> > >>>>>>>
> > >>>>>>> DVFS has been tested by running the arm64 cpuburn
> > >>>>>>> [1] https://github.com/ssvb/cpuburn-arm/blob/master/cpuburn-a53.S
> > >>>>>>> PM-QA testing
> > >>>>>>> [2] https://git.linaro.org/power/pm-qa.git [cpufreq testcase]
> > >>>>>>>
> > >>>>>>> Tested on latest U-Boot 2019.07-1 (Aug 01 2019 - 23:58:01 +0000) Arch Linux ARM
> > >>>>>>
> > >>>>>> Have you tested with the Harkernel u-boot?
> > >>>>>>
> > >>>>>> Last I remember, enabling CPUfreq will cause system hangs with the
> > >>>>>> Hardkernel u-boot because of improperly enabled frequencies, so I'm not
> > >>>>>> terribly inclined to merge this patch.
> > >>>>
> > >>>> HK u-boot have many issue with loading the kernel, with load address
> > >>>> *it's really hard to build the kernel for HK u-boot*,
> > >>>> to get the configuration correctly.
> > >>>>
> > >>>> Well I have tested with mainline u-boot with latest ATF .
> > >>>> I would prefer mainline u-boot for all the Amlogic SBC, since
> > >>>> they sync with latest driver changes.
> > >>>
> > >>> Yes, we would all prefer mainline u-boot, but the mainline kernel needs
> > >>> to support the vendor u-boot that is shipping with the boards. So
> > >>> until Hardkernel (and other vendors) switch to mainline u-boot we do not
> > >>> want to have upstream kernel defaults that will not boot with the vendor
> > >>> u-boot.
> > >>>
> > >>> We can always support these features, but they just cannot be enabled
> > >>> by default.
> > >> (I don't have an Odroid-C2 but I'm curious)
> > >> should Anand submit a patch to mainline u-boot instead?
> > >
> > > It would be in addition to $SUBJECT patch, not instead, I think.
> > >
> > >> the &scpi_clocks node could be enabled at runtime by mainline u-boot
> > >
> > > That would work, but I don't know about u-boot maintainers opinions on
> > > this kind of thing, so let's see what Neil thinks.
> >
> > U-Boot doesn't anything to do with SCPI, SCPI discusses directly with the SCP
> > processor, and the CPU clock is set to 1,56GHz by the BL2 boot stage before
> > U-boot starts.
> >
> > The only viable solution I see now is to find if we could add a DT OPP table
> > only for Odroid-C2 dts to bypass the SCPI OPP table.
> my understanding is that mainline u-boot (with whatever SCP firmware
> it uses) provides the *correct* OPP table

Right now I am not sure how this OPP table is populated.
But I saw the same freq table used in 3.16.x kernel after enable the clk.

> in this case it would be "safe" to have SCPI enabled with mainline u-boot
> @Anand: please correct me if I misunderstood you
>

As per my understanding DVFS OPP frequency table for SCPI firmware set
for 1.536 GHz
somewhere in BL2 as pointed by Neil.

Arm Trusted firmware added new secure SCPI communication with
Cortex-M3 co processor.
[0] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/meson-gxbb.rst
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/amlogic/common/aml_scpi.c

ATF generated the *bl1.bin* which is replace the Amlogic's bl1.bin
while preparing
the new u-boot *u-boot.gxbb* image.

> my idea to "enable SCPI with mainline u-boot" is to have u-boot update
> the "status" property of the scpi_clocks node.
> u-boot does something similar with the mac-address property of the
> Ethernet controller for example.
> as result of this users of mainline u-boot would have working CPU
> DVFS, while users of the old vendor u-boot would run at fixed 1.54GHz.
>
>
> Martin

Right now as per my understanding 1.536 GHz max is bit under clocked.

Some time ago on Odroid Forum tried to over clock the cpu to 2GHz.
[3] https://forum.odroid.com/viewtopic.php?f=139&t=18738
So more investigation need to done in this line.

I also tried the same with HardKernel Image, with modifying the boot.ini
I could increase the max DVFS cpu frequency to 1.90 GHz,
This is just proof of concept.

odroid:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
100000 250000 500000 1000000 1296000 1536000 1656000 1680000 1752000 1896000

I have some minimal stress testing attached are the results for HK
3.16.x kernel.

For now we should not enable this clock.
Until we can possible to check for higher clock frequency to work stable
on all Amlogic S905X SBC.

I like the Neil's approach to use it's own dts OPP table for SCPI protocol.

-Anand
root@odroid:~# sysbench --test=cpu --threads=4 --cpu-max-prime=2000000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Prime numbers limit: 2000000

Initializing worker threads...

Threads started!

CPU speed:
events per second: 0.09

General statistics:
total time: 46.4799s
total number of events: 4

Latency (ms):
min: 31319.82
avg: 38583.37
max: 46478.53
95th percentile: 46103.52
sum: 154333.47

Threads fairness:
events (avg/stddev): 1.0000/0.00
execution time (avg/stddev): 38.5834/6.98
root@odroid:~# cpufreq-
cpufreq-aperf cpufreq-info cpufreq-set
root@odroid:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
driver: meson_cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us.
hardware limits: 100.0 MHz - 1.90 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz, 1.66 GHz, 1.68 GHz, 1.75 GHz, 1.90 GHz
available cpufreq governors: hotplug, interactive, conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 100.0 MHz and 100.0 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 100.0 MHz (asserted by call to hardware).
cpufreq stats: 100.0 MHz:28.54%, 250 MHz:0.00%, 500 MHz:0.00%, 1000 MHz:0.00%, 1.30 GHz:0.00%, 1.54 GHz:0.00%, 1.66 GHz:0.00%, 1.68 GHz:0.00%, 1.75 GHz:0.00%, 1.90 GHz:71.46% (2)
analyzing CPU 1:
driver: meson_cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us.
hardware limits: 100.0 MHz - 1.90 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz, 1.66 GHz, 1.68 GHz, 1.75 GHz, 1.90 GHz
available cpufreq governors: hotplug, interactive, conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 100.0 MHz and 100.0 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 100.0 MHz (asserted by call to hardware).
cpufreq stats: 100.0 MHz:28.54%, 250 MHz:0.00%, 500 MHz:0.00%, 1000 MHz:0.00%, 1.30 GHz:0.00%, 1.54 GHz:0.00%, 1.66 GHz:0.00%, 1.68 GHz:0.00%, 1.75 GHz:0.00%, 1.90 GHz:71.46% (2)
analyzing CPU 2:
driver: meson_cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us.
hardware limits: 100.0 MHz - 1.90 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz, 1.66 GHz, 1.68 GHz, 1.75 GHz, 1.90 GHz
available cpufreq governors: hotplug, interactive, conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 100.0 MHz and 100.0 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 100.0 MHz (asserted by call to hardware).
cpufreq stats: 100.0 MHz:28.54%, 250 MHz:0.00%, 500 MHz:0.00%, 1000 MHz:0.00%, 1.30 GHz:0.00%, 1.54 GHz:0.00%, 1.66 GHz:0.00%, 1.68 GHz:0.00%, 1.75 GHz:0.00%, 1.90 GHz:71.46% (2)
analyzing CPU 3:
driver: meson_cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us.
hardware limits: 100.0 MHz - 1.90 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz, 1.66 GHz, 1.68 GHz, 1.75 GHz, 1.90 GHz
available cpufreq governors: hotplug, interactive, conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 100.0 MHz and 100.0 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 100.0 MHz (asserted by call to hardware).
cpufreq stats: 100.0 MHz:28.55%, 250 MHz:0.00%, 500 MHz:0.00%, 1000 MHz:0.00%, 1.30 GHz:0.00%, 1.54 GHz:0.00%, 1.66 GHz:0.00%, 1.68 GHz:0.00%, 1.75 GHz:0.00%, 1.90 GHz:71.45% (2)
root@odroid:~#