Re: [PATCH] cpufreq: acpi_cpufreq: base frequency attribute support

From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: acpi_cpufreq: base frequency attribute support
Date: Mon, 29 Feb 2016 09:11:32 -0800	[thread overview]
Message-ID: <1456765892.21069.18.camel@linux.intel.com> (raw)
In-Reply-To: <20160229031601.GI5823@vireshk-i7>

On Mon, 2016-02-29 at 08:46 +0530, Viresh Kumar wrote:
> On 26-02-16, 12:21, Srinivas Pandruvada wrote:
> > We are setting a cpufreq global variable in cpufreq_driver->attr
> > with
> > this for each cpu. This feature can be absent in certain cpus. So
> > unlike boost it is not system wide, so I have to reset the attr to
> > NULL
> > for some cpus.
> 
> Ahh, I see..
> 
> What about always creating this file in sysfs, but allowing
> read/write only if
> it is applicable to a CPU.
> 
> > Can we assume that cpufreq_driver->init(policy) calls are always
> > serialized from cpu online/offline and subsys_interface callback
> > path?
> 
> It is called from these paths but only on poilcy creation. So, if you
> are going
> to have a single CPU for each policy, then yes.
> 
This depends on ACPI configuration, so not guaranteed to have one cpu
per policy. Since this is not guaranteed, I can't change mode to Read
only on some as after I set the cpufreq_driver->attr, the other call to
init may change the mode before the actual attribute creation.
So safe bet is to implement like boost for all CPUs and fail on read
for some CPUs, where this is not present. If this becomes a problem,
then we can revisit.

Thanks,
Srinivas