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: <5a1b22cb-4597-8137-e802-ca81ceb99c7c@gmail.com>
Date:   Thu, 30 Mar 2023 11:31:41 +0200
From:   Matthias Brugger <matthias.bgg@...il.com>
To:     Roger Lu (陸瑞傑) <Roger.Lu@...iatek.com>,
        "eballetbo@...il.com" <eballetbo@...il.com>,
        "khilman@...nel.org" <khilman@...nel.org>,
        "drinkcat@...gle.com" <drinkcat@...gle.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Jia-wei Chang (張佳偉) 
        <Jia-wei.Chang@...iatek.com>,
        Fan Chen (陳凡) <fan.chen@...iatek.com>
Subject: Re: [PATCH v5 3/3] soc: mediatek: mtk-svs: add thermal voltage
 compensation if needed



On 11/02/2023 12:12, Roger Lu (陸瑞傑) wrote:
> Hi Matthias Sir,
> 
> Sorry for the late reply.
> 
> ... [snip] ...
> 
>>> @@ -2127,6 +2123,7 @@ static struct svs_bank svs_mt8192_banks[] = {
>>>    		.type			= SVSB_LOW,
>>>    		.set_freq_pct		= svs_set_bank_freq_pct_v3,
>>>    		.get_volts		= svs_get_bank_volts_v3,
>>> +		.tzone_name		= "gpu1",
>>>    		.volt_flags		= SVSB_REMOVE_DVTFIXED_VOLT,
>>>    		.mode_support		= SVSB_MODE_INIT02,
>>>    		.opp_count		= MAX_OPP_ENTRIES,
>>> @@ -2144,6 +2141,10 @@ static struct svs_bank svs_mt8192_banks[] = {
>>>    		.core_sel		= 0x0fff0100,
>>>    		.int_st			= BIT(0),
>>>    		.ctl0			= 0x00540003,
>>> +		.tzone_htemp		= 85000,
>>> +		.tzone_htemp_voffset	= 0,
>>> +		.tzone_ltemp		= 25000,
>>> +		.tzone_ltemp_voffset	= 7,
>>
>> Which is the exact same tzone then in the other bank. Which brings me to a
>> good
>> point:
>> Is the tzone bank specific or the same for all banks?
> 
> Thermal zone (tzone) isn't for all SVS banks. In other words, tzone is specific
> for corresponding DVFS domain like SVS GPU tzone is for GPU DVFS domain. Let's
> take MT8183 SVS and MT8192 SVS as examples.
> 
> MT8192 SVS applies 2-line HW design (High/low 2 banks optimize the same DVFS
> domain). So, SVS GPU High/low bank uses the same GPU tzone.
> 
> MT8183 SVS applies 1-line HW design (1 bank optimizes 1 DVFS domain)
> Therefore, SVS CPU/GPU/CCI bank use different tzone because they are different
> DVFS domain.
> 
>> At least for mt8192 they are not. I suppose with this change to the code
>> mt8183
>> could take advantage of this on all it's banks as well.
>> In that case, can we
>> start to restructure the struct svs_bank to only have the tzone values
>> declared
>> once?
> 
> Since tzone isn't for all banks, we cannot declare it once for all IC supports
> from this point of view.
> 

Thanks for clarification, applied now.

>>
>> Background is that I'm very unhappy with the svs_bank data strucutre. It
>> seems
>> like a "throw it all in here". It should be structured for functional parts
>> of
>> the banks. Maybe using structs, maybe unions where possible. In any case
>> having
>> a flat struct of over 50 members isn't really what we want.
> 
> My apology. We'll structure svs_bank for functional parts of them.
> 
>>
>> Regards,
>> Matthias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ