lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4ab6ce42-4769-8a8b-495a-8a7edda91dea@collabora.com>
Date:   Mon, 5 Dec 2022 11:37:14 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Nick <vincent@...temli.org>, viresh.kumar@...aro.org
Cc:     rafael@...nel.org, matthias.bgg@...il.com,
        jia-wei.chang@...iatek.com, rex-bc.chen@...iatek.com,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, frank-w@...lic-files.de,
        daniel@...rotopia.org
Subject: Re: [PATCH] cpufreq: mediatek: Raise proc and sram max voltage for
 MT7622/7623

Il 02/12/22 13:37, Nick ha scritto:
> It now starts, however, with a lot of those messages (I applied the patch to 
> linux/master and not to linux-next, because next is currently not compiling anymore 
> for me):
> 
>> [   10.777041] cpufreq: __target_index: Failed to change cpu frequency: -22
>> [   10.791577] cpu cpu0: cpu0: failed to scale up voltage!
> The complete log:
> https://gist.githubusercontent.com/PolynomialDivision/267c83c7a21a359cbb4e8d99d0303201/raw/28d3568a26634bebef2d91ebe37fc5f76ae58add/mt7622-patch-cpufreq.log
> 

Thanks for the feedback!

I am totally sure that the platform_data is correct as that's based on datasheets.

Checking mt6380-regulator.c and mt6380.dtsi also confirms that the min/max volt
shift and proc/sram max voltage that I've specified is currently supported.

That "failed to scale up voltage!" is a bit strange, as this means that
the regulator_set_voltage() call returns -EINVAL for .. reasons, and that's a bit
strange, since the constraints look good in the code, unless there's anything that
I'm missing here.

Can you please try a vanilla kernel?

Also, since I don't have any MT7622/7623 board to test with, if the issue persists,
it would be helpful if you could place some debugging prints in mediatek-cpufreq.c
to specifically check which regulator_set_voltage() call fails, as to try to make
me have a better overview on the problem that you're facing.

Alternatively, we can eventually setup a debugging session on IRC to make things
a bit faster.

Cheers,
Angelo

> Bests
> Nick
> 
> On 12/2/22 10:52, AngeloGioacchino Del Regno wrote:
>> During the addition of SRAM voltage tracking for CCI scaling, this
>> driver got some voltage limits set for the vtrack algorithm: these
>> were moved to platform data first, then enforced in a later commit
>> 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
>> using these as max values for the regulator_set_voltage() calls.
>>
>> In this case, the vsram/vproc constraints for MT7622 and MT7623
>> were supposed to be the same as MT2701 (and a number of other SoCs),
>> but that turned out to be a mistake because the aforementioned two
>> SoCs' maximum voltage for both VPROC and VPROC_SRAM is 1.36V.
>>
>> Fix that by adding new platform data for MT7622/7623 declaring the
>> right {proc,sram}_max_volt parameter.
>>
>> Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data")
>> Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> ---
>>   drivers/cpufreq/mediatek-cpufreq.c | 13 +++++++++++--
>>   1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
>> index 7f2680bc9a0f..f9a9f08c75c4 100644
>> --- a/drivers/cpufreq/mediatek-cpufreq.c
>> +++ b/drivers/cpufreq/mediatek-cpufreq.c
>> @@ -695,6 +695,15 @@ static const struct mtk_cpufreq_platform_data 
>> mt2701_platform_data = {
>>       .ccifreq_supported = false,
>>   };
>> +static const struct mtk_cpufreq_platform_data mt7622_platform_data = {
>> +    .min_volt_shift = 100000,
>> +    .max_volt_shift = 200000,
>> +    .proc_max_volt = 1360000,
>> +    .sram_min_volt = 0,
>> +    .sram_max_volt = 1360000,
>> +    .ccifreq_supported = false,
>> +};
>> +
>>   static const struct mtk_cpufreq_platform_data mt8183_platform_data = {
>>       .min_volt_shift = 100000,
>>       .max_volt_shift = 200000,
>> @@ -717,8 +726,8 @@ static const struct mtk_cpufreq_platform_data 
>> mt8186_platform_data = {
>>   static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
>>       { .compatible = "mediatek,mt2701", .data = &mt2701_platform_data },
>>       { .compatible = "mediatek,mt2712", .data = &mt2701_platform_data },
>> -    { .compatible = "mediatek,mt7622", .data = &mt2701_platform_data },
>> -    { .compatible = "mediatek,mt7623", .data = &mt2701_platform_data },
>> +    { .compatible = "mediatek,mt7622", .data = &mt7622_platform_data },
>> +    { .compatible = "mediatek,mt7623", .data = &mt7622_platform_data },
>>       { .compatible = "mediatek,mt8167", .data = &mt2701_platform_data },
>>       { .compatible = "mediatek,mt817x", .data = &mt2701_platform_data },
>>       { .compatible = "mediatek,mt8173", .data = &mt2701_platform_data },

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ