linux-kernel - Re: [PATCH v2] cpufreq: airoha: Add EN7581 Cpufreq SMC driver

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: <20241119104421.hqsil2uvklxok7lz@vireshk-i7>
Date: Tue, 19 Nov 2024 16:14:21 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, Lorenzo Bianconi <lorenzo@...nel.org>,
	upstream@...oha.com, ulf.hansson@...aro.org
Subject: Re: [PATCH v2] cpufreq: airoha: Add EN7581 Cpufreq SMC driver

On 19-11-24, 10:04, Christian Marangi wrote:
> On Tue, Nov 19, 2024 at 12:50:54PM +0530, Viresh Kumar wrote:
> > On 17-10-24, 21:07, Christian Marangi wrote:
> > > Add simple Cpufreq driver for Airoha EN7581 SoC that control CPU
> > > frequency scaling with SMC APIs.
> > > 
> > > All CPU share the same frequency and can't be controlled independently.
> > > Current shared CPU frequency is returned by the related SMC command.
> > > 
> > > Add SoC compatible to cpufreq-dt-plat block list as a dedicated cpufreq
> > > driver is needed with OPP v2 nodes declared in DTS.
> > > 
> > > Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> > > ---
> > > Changes v2:
> > > - Fix kernel bot error with missing slab.h and bitfield.h header
> > > - Limit COMPILE_TEST to ARM64 due to smcc 1.2
> > 
> > Hi,
> > 
> > Sorry for delay at my side to review this driver.
> > 
> > Now that I looked at it, I don't see a lot of special stuff happening in the
> > driver. There are many other platforms with similar situation. What we have done
> > for all them, which rely on OPPs coming from DT, is to add a clk for the CPUs
> > and do all this magically smcc stuff from clk_get_rate() and clk_set_rate().
> > Once that is done, you should be able to reuse the cpufreq-dt driver as is.
> > 
> > So a CPU clk is the only missing thing in your case I guess.
> >
> 
> Hi Viresh,
> 
> thanks a lot for the follow-up. I will see what I can do, 2 main problem
> I see is that, contrary to other driver, for this Airoha SoC, there are
> no parents or no clock to enable... It's really just entirely handled by
> ATF and smccc call.
> 
> And also the SMCCC requires an index and not the clock itself. This was
> handy for a cpufreq driver as it passed the OPP index

Right, but the OPP table for the CPU must contain frequencies too, isn't it ? So
you already have index to frequency conversion available ?

Can't you just add a clk driver for the CPU, which uses OPP core to parse the
OPP table of the CPU and set a clk-index table in the clk driver ? So once the
clk driver gets a request for a particular frequency, it just finds the
respective index and sets it ?

> problematic for a
> clock driver as set_rate pass the clock. So I guess I will have to
> define the OPP phandle also in the clock node struct. (and map it?)

I am not suggesting a clk in DT, but just in code, added by a cpufreq driver for
your platform, which at the end creates cpufreq-dt device. There are many which
are creating the device on the fly, like tegra20-cpufreq.c.

> The main problem in doing that is the performance hit on having to cycle
> every time the OPPs to find the correct index...

I think it would be traversing an array in the clk driver eventually and that
won't be that bad ?

> (yes they really implemented this thing with the ATF specifically with
> the cpufreq scenario in mind)

-- 
viresh