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

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

[Anand Moon]

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

Patch based on my next-20191031 for 5.5.x kernel.
Hope this is not late entry.

Best Regards
-Anand

Anand Moon (1):
  arm64: dts: meson: odroid-c2: Enable SCPI DVFS for cpu

 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.23.0


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[RFC-next 1/1] arm64: dts: meson: odroid-c2: Enable SCPI DVFS for cpu

[Anand Moon]

Enable System Control and Power Interface, DVFS for cpu
with setting 1.54 GHz as max freq in the initial SCPI tables
loaded by the BL2, i.e. packed with U-Boot.

Fixes: f7bcd4b6f698 (ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS)
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Suggested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
In discuss on other mailing list thread below.
[0] https://lkml.org/lkml/2019/8/30/186

Tested on mainline U-Boot 2019.07-1 (Aug 01 2019 - 23:58:01 +0000) Arch Linux ARM
on archlinux distro.
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6ded279c40c8..9678784aa1a9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -307,7 +307,7 @@
 };
 
 &scpi_clocks {
-	status = "disabled";
+	status = "okay";
 };
 
 /* SD */
-- 
2.23.0


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Kevin Hilman]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Neil Armstrong]

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
> 


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Anand Moon]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Kevin Hilman]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Martin Blumenstingl]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Kevin Hilman]

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



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Neil Armstrong]

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


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Martin Blumenstingl]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Anand Moon]

[-- Attachment #1: Type: text/plain, Size: 5304 bytes --]

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

[-- Attachment #2: cpufreq_odroid_c2_3.16.78-48.txt --]
[-- Type: text/plain, Size: 4998 bytes --]

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:~#

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Neil Armstrong]

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
> 


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Anand Moon]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

[Brad]

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic