linux-kernel - Re: [PATCH v5 3/3] soc: mediatek: mtk-svs: add thermal voltage compensation if needed

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fd62705e1abf8124706da6520fde5b77846bfd2c.camel@mediatek.com>
Date:   Sat, 11 Feb 2023 11:12:13 +0000
From:   Roger Lu (陸瑞傑) <Roger.Lu@...iatek.com>
To:     "eballetbo@...il.com" <eballetbo@...il.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...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

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. 

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