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
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 <[email protected]>
Cc: Jerome Brunet <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Kevin Hilman <[email protected]>
Suggested-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Anand Moon <[email protected]>
---
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
Anand Moon <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>
> On 09/12/2019 23:12, Kevin Hilman wrote:
> > Anand Moon <[email protected]> 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 <[email protected]> writes:
> Hi Neil / Kevin,
>
> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
>>
>> On 09/12/2019 23:12, Kevin Hilman wrote:
>> > Anand Moon <[email protected]> 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 <[email protected]> wrote:
>
> Anand Moon <[email protected]> writes:
>
> > Hi Neil / Kevin,
> >
> > On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
> >>
> >> On 09/12/2019 23:12, Kevin Hilman wrote:
> >> > Anand Moon <[email protected]> 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 <[email protected]> writes:
> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
>>
>> Anand Moon <[email protected]> writes:
>>
>> > Hi Neil / Kevin,
>> >
>> > On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
>> >>
>> >> On 09/12/2019 23:12, Kevin Hilman wrote:
>> >> > Anand Moon <[email protected]> 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 <[email protected]> writes:
>
>> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
>>>
>>> Anand Moon <[email protected]> writes:
>>>
>>>> Hi Neil / Kevin,
>>>>
>>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
>>>>>
>>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
>>>>>> Anand Moon <[email protected]> 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 <[email protected]> wrote:
>
> On 10/12/2019 22:47, Kevin Hilman wrote:
> > Martin Blumenstingl <[email protected]> writes:
> >
> >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
> >>>
> >>> Anand Moon <[email protected]> writes:
> >>>
> >>>> Hi Neil / Kevin,
> >>>>
> >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
> >>>>>
> >>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
> >>>>>> Anand Moon <[email protected]> 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
<[email protected]> wrote:
>
> Hi Neil,
>
> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <[email protected]> wrote:
> >
> > On 10/12/2019 22:47, Kevin Hilman wrote:
> > > Martin Blumenstingl <[email protected]> writes:
> > >
> > >> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
> > >>>
> > >>> Anand Moon <[email protected]> writes:
> > >>>
> > >>>> Hi Neil / Kevin,
> > >>>>
> > >>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
> > >>>>>
> > >>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
> > >>>>>> Anand Moon <[email protected]> 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
On 13/12/2019 12:28, Anand Moon wrote:
> Hi Martin
>
> On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl
> <[email protected]> wrote:
>>
>> Hi Neil,
>>
>> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <[email protected]> wrote:
>>>
>>> On 10/12/2019 22:47, Kevin Hilman wrote:
>>>> Martin Blumenstingl <[email protected]> writes:
>>>>
>>>>> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
>>>>>>
>>>>>> Anand Moon <[email protected]> writes:
>>>>>>
>>>>>>> Hi Neil / Kevin,
>>>>>>>
>>>>>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
>>>>>>>>
>>>>>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
>>>>>>>>> Anand Moon <[email protected]> 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 <[email protected]> wrote:
>
> On 13/12/2019 12:28, Anand Moon wrote:
> > Hi Martin
> >
> > On Fri, 13 Dec 2019 at 01:40, Martin Blumenstingl
> > <[email protected]> wrote:
> >>
> >> Hi Neil,
> >>
> >> On Wed, Dec 11, 2019 at 9:49 AM Neil Armstrong <[email protected]> wrote:
> >>>
> >>> On 10/12/2019 22:47, Kevin Hilman wrote:
> >>>> Martin Blumenstingl <[email protected]> writes:
> >>>>
> >>>>> On Tue, Dec 10, 2019 at 7:13 PM Kevin Hilman <[email protected]> wrote:
> >>>>>>
> >>>>>> Anand Moon <[email protected]> writes:
> >>>>>>
> >>>>>>> Hi Neil / Kevin,
> >>>>>>>
> >>>>>>> On Tue, 10 Dec 2019 at 14:13, Neil Armstrong <[email protected]> wrote:
> >>>>>>>>
> >>>>>>>> On 09/12/2019 23:12, Kevin Hilman wrote:
> >>>>>>>>> Anand Moon <[email protected]> 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