[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241220051937.fbfbbvtd3yzu54kv@vireshk-i7>
Date: Fri, 20 Dec 2024 10:49:37 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Christian Marangi <ansuelsmth@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
upstream@...oha.com
Subject: Re: [PATCH v7 2/2] cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver
On 19-12-24, 16:23, Ulf Hansson wrote:
> The power-domain provider driver should use the compatible
> "airoha,en7581-cpufreq". This driver should be responsible for
> registering the genpd and the clock.
>
> Potentially, the power-domain provider driver could also register the
> "cpufreq-dt" platform-device. To make this work, we also need to
> extend the cpufreq-dt driver (maybe extend its platform-data too?) to
> be capable of attaching the corresponding cpu-devices to their
> power(perf)-domains. For the moment, this isn't supported, but I think
> it would be nice if it could. Another option, would be to use an
> additional separate name-based cpufreq-driver, as in the
> qcom-cpufreq-nvmem.c, that then becomes responsible for registering
> the cpufreq-dt device.
>
> Viresh, do you have a better approach in mind?
I am fine with any part of the kernel creating the cpufreq-dt device.. That
doesn't need to be in the cpufreq directory.
--
viresh
Powered by blists - more mailing lists