On 13/12/2019 12:28, Anand Moon wrote: > 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. 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 >
