Hi Neil On Fri, 13 Dec 2019 at 18:54, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote: > > 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 > 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
