Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Aug 2023 07:53:27 -0500
From:   Nishanth Menon <nm@ti.com>
To:     "Kumar, Udit" <u-kumar1@ti.com>
CC:     Apurva Nandan <a-nandan@ti.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Tero Kristo <kristo@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Rafael J Wysocki <rafael@kernel.org>,
        Daniel Lezcano <daniel.lezcano@linaro.org>,
        Amit Kucheria <amitk@kernel.org>,
        Zhang Rui <rui.zhang@intel.com>,
        <linux-arm-kernel@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-pm@vger.kernel.org>, Keerthy J <j-keerthy@ti.com>
Subject: Re: [PATCH 2/3] arm64: dts: ti: k3-j7200: Add the supported
 frequencies for A72
Message-ID: <20230810125327.pq2fxda7dpv2qf7t@seizing>
References: <20230809173905.1844132-1-a-nandan@ti.com>
 <20230809173905.1844132-3-a-nandan@ti.com>
 <20230809190943.unpcbrinyn5ppei7@hydrated>
 <ab69c4df-708f-8fff-a58b-a6531e15627b@ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ab69c4df-708f-8fff-a58b-a6531e15627b@ti.com>
Precedence: bulk

On 17:23-20230810, Kumar, Udit wrote:
[..]
> > > +		opp1-750000000 {
> > > +			opp-hz = /bits/ 64 <750000000>;
> > >   		};
> > >   	};
> > > -- 
> > > 2.34.1
> > > 
> > Are you sure this is correct to enable all OPPs without efuse bit checks?
> > 
> > https://www.ti.com/lit/ds/symlink/dra821u-q1.pdf
> > 7.5 Operating Performance Points
> > DRA821xC operates only upto 750MHz
> > DRA821xE at 1GHz
> > DRA821xL upto 1.5GHz and
> > DRA821xT upto 2GHz
> 
> Looks, top SKUs is considered here .
> 
> After detecting which SKU we are running (I hope TRM should have this
> information- through efuse or some other register)
> 
> I think, we can follow two approaches.

Both of these are wrong approaches.

> 
> 1) have OPP table for each SKU and select based SKUs type or

This proliferates cpu dtsi to make it hard to manage

> 
> 2) Do run time fixup by u-boot based upon SKU type

This wont work:

a) in u-boot's falcon boot mode and puts unrelated responsibility to
bootloader (u-boot is not the only bootloader in the party here).
b) Further, the reason for doing the opp detection in the kernel is
due to the severity of consequence of attempting to run a lower rated
chip at higher frequency - PoH (Power on Hours) or physical damage can
result.
c) Finally, in a virtualized environment: TISCI will get DM (Device
Manager) to arbitrate between the each of the VM's request, but if
the VM's are'nt self sufficient, we will have DM making wrong choices
resulting in (b) condition again.

This is the reason why drivers/cpufreq/ti-cpufreq.c exists and all SoCs
that have OPPs from TI is handled in the kernel itself.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D