linux-kernel - RE: [PATCH 1/2] arm64: dts: imx8mq: Correct OPP table according to latest datasheet

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: <DB3PR0402MB39161C60DC780B693933F9EAF5FC0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Date:   Fri, 28 Jun 2019 06:16:00 +0000
From:   Anson Huang <anson.huang@....com>
To:     Leonard Crestez <leonard.crestez@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Jacky Bai <ping.bai@....com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
        Daniel Baluta <daniel.baluta@....com>,
        Abel Vesa <abel.vesa@....com>,
        "andrew.smirnov@...il.com" <andrew.smirnov@...il.com>,
        "ccaione@...libre.com" <ccaione@...libre.com>,
        "angus@...ea.ca" <angus@...ea.ca>,
        "agx@...xcpu.org" <agx@...xcpu.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH 1/2] arm64: dts: imx8mq: Correct OPP table according to
 latest datasheet

Hi, Leonard

> -----Original Message-----
> From: Leonard Crestez
> Sent: Friday, June 28, 2019 1:59 PM
> To: Anson Huang <anson.huang@....com>; shawnguo@...nel.org; Jacky
> Bai <ping.bai@....com>; l.stach@...gutronix.de
> Cc: robh+dt@...nel.org; mark.rutland@....com; s.hauer@...gutronix.de;
> kernel@...gutronix.de; festevam@...il.com; viresh.kumar@...aro.org;
> Daniel Baluta <daniel.baluta@....com>; Abel Vesa <abel.vesa@....com>;
> andrew.smirnov@...il.com; ccaione@...libre.com; angus@...ea.ca;
> agx@...xcpu.org; devicetree@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; dl-linux-imx
> <linux-imx@....com>
> Subject: Re: [PATCH 1/2] arm64: dts: imx8mq: Correct OPP table according to
> latest datasheet
> 
> On 28.06.2019 06:37, Anson.Huang@....com wrote:
> > From: Anson Huang <Anson.Huang@....com>
> >
> > According to latest datasheet (Rev.1, 10/2018) from below links, in
> > the consumer datasheet, 1.5GHz is mentioned as highest opp but depends
> > on speed grading fuse, and in the industrial datasheet, 1.3GHz is
> > mentioned as highest opp but depends on speed grading fuse. 1.5GHz and
> > 1.3GHz opp use same voltage, so no need for consumer part to support
> > 1.3GHz opp, with same voltage, CPU should run at highest frequency in
> > order to go into idle as quick as possible, this can save power.
> 
> I looked at the same datasheets and it's not clear to me that 1.3 Ghz should
> be disallowed for consumer parts. Power consumption increases with both
> voltage and frequency so having two OPPs with same voltage does make
> sense.

The consumer part datasheet does NOT mention 1.3GHz at all, so consumer part ONLY
support 1GHz/1.5GHz, and industrial part ONLY support 800MHz/1.3GHz, this is what
we did in our internal tree and NPI release, so better to make them aligned, otherwise,
we have to change it when kernel upgrade.

And normally, with same voltage, i.MX SoCs always run at highest frequency, so it is better
to keep the rule, otherwise customer may ask, how about using same voltage to run at 1.2GHz or
1.1GHz?

> 
> >   			opp-hz = /bits/ 64 <1300000000>;
> >   			opp-microvolt = <1000000>;
> > -			opp-supported-hw = <0xc>, <0x7>;
> > +			/* Industrial only but rely on speed grading */
> > +			opp-supported-hw = <0xc>, <0x4>;
> 
> Comment is false, you're explicitly excluding consumer parts via the second
> element.

Yes, that is what I meant to do, as we no need to support 1.3GHz for consumer
part, with 1.0V, consumer part can run up to 1.5GHz.

> 
> >   			opp-hz = /bits/ 64 <1500000000>;
> >   			opp-microvolt = <1000000>;
> >   			/* Consumer only but rely on speed grading */
> > -			opp-supported-hw = <0x8>, <0x7>;
> > +			opp-supported-hw = <0x8>, <0x3>;
> 
> If you don't want to rely on the fact that only consumer parts should be
> fused for 1.5 Ghz then please delete the comment.

Don't quite understand, 1.5GHz is indeed consumer ONLY, but if the consumer
part is fused to 1GHz, then 1.5GHz is also NOT available, so it also rely on speed
grading. So keep the comment there is OK?

Thanks,
Anson.