Message ID | 20191101143126.2549-1-linux.amoon@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Odroid C2: Enable DVFS for cpu | expand |
Anand Moon <linux.amoon@gmail.com> 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. > Patch based on my next-20191031 for 5.5.x kernel. > Hope this is not late entry. Re: "too late". FYI... when you post things as RFC, it means you're looking for comments (Request For Comment) but that it's not intended for merging. I didn't see any comments on this, but I also didn't see a non-RFC follow-up, so I didn't queue it for v5.5. Kevin
On 09/12/2019 23:12, Kevin Hilman wrote: > Anand Moon <linux.amoon@gmail.com> 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. Same, since the bootloader boots with the max supported freq of the board, there is not real need of DVFS except for specific low-power use-cases. And still, some early boards still use the bad SCPI freq table, we can't break them. Neil > >> Patch based on my next-20191031 for 5.5.x kernel. >> Hope this is not late entry. > > Re: "too late". FYI... when you post things as RFC, it means you're > looking for comments (Request For Comment) but that it's not intended > for merging. > > I didn't see any comments on this, but I also didn't see a non-RFC > follow-up, so I didn't queue it for v5.5. > > Kevin >
Hi Neil / Kevin, On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: > > On 09/12/2019 23:12, Kevin Hilman wrote: > > Anand Moon <linux.amoon@gmail.com> 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. > > Same, since the bootloader boots with the max supported freq of the board, > there is not real need of DVFS except for specific low-power use-cases. > > And still, some early boards still use the bad SCPI freq table, we can't break them. > > Neil > I will leave this to your expert domain knowledge if you want to enable this now. Here is output of on the latest kernel. *cpupower* # cpupower frequency-info analyzing CPU 0: driver: scpi-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.54 GHz available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 100.0 MHz and 100.0 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 100.0 MHz (asserted by call to hardware) *powertop* # powertop Package | CPU 0 100 MHz 47.1% | 100 MHz 41.5% 250 MHz 0.0% | 250 MHz 0.0% 500 MHz 0.0% | 500 MHz 0.0% 1000 MHz 0.0% | 1000 MHz 0.0% 1296 MHz 0.0% | 1296 MHz 0.0% 1.54 GHz 0.0% | 1.54 GHz 0.0% Idle 52.9% | Idle 58.5% > > > >> Patch based on my next-20191031 for 5.5.x kernel. > >> Hope this is not late entry. > > > > Re: "too late". FYI... when you post things as RFC, it means you're > > looking for comments (Request For Comment) but that it's not intended > > for merging. Ok thanks for this input. > > > > I didn't see any comments on this, but I also didn't see a non-RFC > > follow-up, so I didn't queue it for v5.5. No problem. > > > > Kevin > > > -Anand
Anand Moon <linux.amoon@gmail.com> writes: > Hi Neil / Kevin, > > On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: >> >> On 09/12/2019 23:12, Kevin Hilman wrote: >> > Anand Moon <linux.amoon@gmail.com> 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. Kevin
On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: > > Anand Moon <linux.amoon@gmail.com> writes: > > > Hi Neil / Kevin, > > > > On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: > >> > >> On 09/12/2019 23:12, Kevin Hilman wrote: > >> > Anand Moon <linux.amoon@gmail.com> 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? the &scpi_clocks node could be enabled at runtime by mainline u-boot Martin
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: >> >> Anand Moon <linux.amoon@gmail.com> writes: >> >> > Hi Neil / Kevin, >> > >> > On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: >> >> >> >> On 09/12/2019 23:12, Kevin Hilman wrote: >> >> > Anand Moon <linux.amoon@gmail.com> 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. Kevin
On 10/12/2019 22:47, Kevin Hilman wrote: > Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: >>> >>> Anand Moon <linux.amoon@gmail.com> writes: >>> >>>> Hi Neil / Kevin, >>>> >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: >>>>> >>>>> On 09/12/2019 23:12, Kevin Hilman wrote: >>>>>> Anand Moon <linux.amoon@gmail.com> 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. The arm,scpi-clocks driver registers a clk for this CPU clock, using SCPI to set the rate, right now this is ok. But, arm,scpi-clocks also registers a "scpi-cpufreq" device, which calls scpi_ops->add_opps_to_device() which gets the SCPI OPPs and adds them to the CPU. A way to handle this would be to check if DT has OPPs in drivers/cpufreq/scpi-cpufreq.c _before/instead_ calling scpi_ops->add_opps_to_device() to use the DT OPPs instead of the firmware OPPs, like in drivers/cpufreq/cpufreq-dt.c. calling: ret = dev_pm_opp_of_get_sharing_cpus() if (ret) { scpi_ops->add_opps_to_device() scpi_get_sharing_cpus() } would maybe work. Neil > > Kevin > >
Hi Neil, On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > On 10/12/2019 22:47, Kevin Hilman wrote: > > Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > > > >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: > >>> > >>> Anand Moon <linux.amoon@gmail.com> writes: > >>> > >>>> Hi Neil / Kevin, > >>>> > >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: > >>>>> > >>>>> On 09/12/2019 23:12, Kevin Hilman wrote: > >>>>>> Anand Moon <linux.amoon@gmail.com> 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 in this case it would be "safe" to have SCPI enabled with mainline u-boot @Anand: please correct me if I misunderstood you 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
Hi Martin On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Neil, > > On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > > > On 10/12/2019 22:47, Kevin Hilman wrote: > > > Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > > > > > >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: > > >>> > > >>> Anand Moon <linux.amoon@gmail.com> writes: > > >>> > > >>>> Hi Neil / Kevin, > > >>>> > > >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: > > >>>>> > > >>>>> On 09/12/2019 23:12, Kevin Hilman wrote: > > >>>>>> Anand Moon <linux.amoon@gmail.com> 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@vger.kernel.org, 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:~#
On 13/12/2019 12:28, Anand Moon wrote: > Hi Martin > > On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: >> >> Hi Neil, >> >> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >>> >>> On 10/12/2019 22:47, Kevin Hilman wrote: >>>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: >>>> >>>>> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: >>>>>> >>>>>> Anand Moon <linux.amoon@gmail.com> writes: >>>>>> >>>>>>> Hi Neil / Kevin, >>>>>>> >>>>>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: >>>>>>>> >>>>>>>> On 09/12/2019 23:12, Kevin Hilman wrote: >>>>>>>>> Anand Moon <linux.amoon@gmail.com> 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. This is the point, the Odroid-C2 is *not* stable at 2GHz, a large amount of board doesn't support 2GHz, this is why Amlogic dropped the freq > 1.536 GHz for the GXBB family. But HardKernel still delivers the SCPI table with > 1.536 GHz which breaks on most of the boards, but doesn't on 3.14 since they have a hack disabling higher freqs with a cmdline set in boot.ini. > [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. The various tests gave very little perf enhancement by going > 1,536 GHz, seriously it's not worth the pain. Neil > > -Anand >
Hi Neil On Fri, 13 Dec 2019 at 18:54, Neil Armstrong <narmstrong@baylibre.com> wrote: > > On 13/12/2019 12:28, Anand Moon wrote: > > Hi Martin > > > > On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > >> > >> Hi Neil, > >> > >> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >>> > >>> On 10/12/2019 22:47, Kevin Hilman wrote: > >>>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > >>>> > >>>>> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <khilman@baylibre.com> wrote: > >>>>>> > >>>>>> Anand Moon <linux.amoon@gmail.com> writes: > >>>>>> > >>>>>>> Hi Neil / Kevin, > >>>>>>> > >>>>>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <narmstrong@baylibre.com> wrote: > >>>>>>>> > >>>>>>>> On 09/12/2019 23:12, Kevin Hilman wrote: > >>>>>>>>> Anand Moon <linux.amoon@gmail.com> 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. > > This is the point, the Odroid-C2 is *not* stable at 2GHz, > a large amount of board doesn't support 2GHz, this is why Amlogic > dropped the freq > 1.536 GHz for the GXBB family. > > But HardKernel still delivers the SCPI table with > 1.536 GHz which breaks > on most of the boards, but doesn't on 3.14 since they have a hack disabling > higher freqs with a cmdline set in boot.ini. > > > [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. > > The various tests gave very little perf enhancement by going > 1,536 GHz, seriously > it's not worth the pain. > > Neil > Ok Thanks for your expert knowledge. I agree with you completely on this to set max freq to 1,536 GHz for all S905 SoC. -Anand
On 14/12/2019 12:24 am, Neil Armstrong wrote: > > This is the point, the Odroid-C2 is *not* stable at 2GHz, > a large amount of board doesn't support 2GHz, this is why Amlogic > dropped the freq > 1.536 GHz for the GXBB family. > > But HardKernel still delivers the SCPI table with > 1.536 GHz which breaks > on most of the boards, but doesn't on 3.14 since they have a hack disabling > higher freqs with a cmdline set in boot.ini. Hi Neil, Hardkernel did update there firmware to restrict frequency to 1.536 back in 2017 back in this commit https://github.com/hardkernel/u-boot/commit/205c7b3259559283161703a1a200b787c2c445a5 Versions prior to this would runaway on boot up to 2Ghz and crash. They also added a hidden function to the SCPI_CMD_GET_DVFS_INFO call which works by changing the domain number in the call to pull back different OPP tables. Domain set to 0 will limit frequency to 1.536. They set the highest bit in the domain number to 1 which opens SCPI table to 2.016GHz. This is done in via BL301 so it might be possible for mainline kernel to check this bit and open up the table after boot using a special driver. Joy posted some details here https://forum.odroid.com/viewtopic.php?f=141&t=23044&start=350#p181017 Of course it would still cause problems for boards running an old version of the firmware but newer versions of the bootloader boot fine in mainline with DVFS enabled as its limited to 1.536 by default. > The various tests gave very little perf enhancement by going > 1,536 GHz, seriously > it's not worth the pain. > > Neil My tests showed my board (they may vary) was very stable up to 1.680Ghz, at 1.752Ghz could get it to crash if I tried to burn all 4 cores with heavy NEON stress test. At 1.896GHz I would get random freezes even with only 1 core enabled at boot. I must say I never tested with Mali enabled so it may influence things. I do agree though it might cause more pain that it is worth especially when old firmware is used. - Brad >> -Anand >> > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic