Re: [PATCHv1 0/3] Odroid c2 missing regulator linking

[Neil Armstrong]

On 30/08/2019 11:34, Anand Moon wrote:
> Hi Neil,
> 
> On Fri, 30 Aug 2019 at 13:01, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote:
>>
>> On 29/08/2019 20:35, Anand Moon wrote:
>>> Hi Neil,
>>>
>>> On Thu, 29 Aug 2019 at 13:58, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote:
>>>>
>>>> On 28/08/2019 22:27, Anand Moon wrote:
>>>>> Below small changes help re-configure or fix missing inter linking
>>>>> of regulator node.
>>>>>
>>>>> Changes based top on my prevoius series.
>>>>
>>>> For the serie:
>>>> Reviewed-by: Neil Armstrong <narmstrong@xxxxxxxxxxxx>
>>>>
>>>
>>> Thanks for your review.
>>>
>>>>>
>>>>> [0] https://patchwork.kernel.org/cover/11113091/
>>>>>
>>>>> TOOD: Add support for DVFS GXBB odroid board in next series.
>>>>
>>>> I'm curious how you will do this !
>>>
>>> I was just studying you previous series on how you have implemented
>>> this feature for C1, N2 and VIM3 boards.
>>>
>>> [0] https://patchwork.kernel.org/cover/11114125/
>>>
>>> I started gathering key inputs needed for this ie *clk / pwm*
>>> like VDDCPU and VDDE clk changes.
>>>
>>> But it looks like of the complex clk framework needed, so I leave this to the
>>> expert like your team of developers to do this much quick and efficiently.
>>
>> On GXBB, GXL, GXM and AXG SoCs, CPU Frequency setting and PWM Regulator setup is
>> done by the SCPI Co-processor via the SCPI protocol.
>>
>> Thus, we should not handle it from Linux, and even if we could, we don't have the
>> registers documentation of the CPU clusters clock tree.
>>
> 
> Ok thanks.
> 
>> SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel left
>> the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed with U-Boot.
>> Nowadays they have removed the bad frequencies, but still some devices uses the old
>> bootloader.
>>
>> But in the SCPI case we trust the table returned by the firmware and use it as-in,
>> and there is no (simple ?) way to override the table and set a max frequency.
>>
>> This is why we disabled SCPI.
>>
>> See https://patchwork.kernel.org/patch/9500175/
> 
> I have quickly enable this on my board and here the cpufreq info
> 
> [alarm@alarm ~]$  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 1.54 GHz.
>                   The governor "ondemand" may decide which speed to use
>                   within this range.
>   current CPU frequency: Unable to call hardware
>   current CPU frequency: 250 MHz (asserted by call to kernel)
> 
> I did some simple stress testing and observed the freq scaling is
> working fine when cpufreq governor is set to ondemand.
> 
> Powertop output.
>             Package |            CPU 0
>  100 MHz     5.2%   |  100 MHz     1.6%
>  250 MHz     4.4%   |  250 MHz     4.3%
>  500 MHz     2.6%   |  500 MHz     2.4%
> 1000 MHz     0.5%   | 1000 MHz     0.3%
> 1296 MHz     0.2%   | 1296 MHz     0.1%
> 1.54 GHz     0.2%   | 1.54 GHz     0.1%
> Idle        86.9%   | Idle        91.2%
> 
> Here the output on the linaro's pm-qa testing for cpufreq.
> 
> [1] https://pastebin.com/h880WATn
> Almost all the test case pass with this one as off now.

Thanks for passing the tests, no doubt it works with a recent
bootloader binary, but we can't leave alone the first Odroid-C2
devices loaded with an incorrect SCPI table.

I'll let Kevin decide for the following.

Neil

> 
> Best Regards
> -Anand
>