[PATCH AUTOSEL 5.2 066/249] cpupower : frequency-set -r option misses the last cpu in related cpu list

[PATCH AUTOSEL 5.2 066/249] cpupower : frequency-set -r option misses the last cpu in related cpu list

[Sasha Levin]

From: Abhishek Goel <huntbag@linux.vnet.ibm.com>

[ Upstream commit 04507c0a9385cc8280f794a36bfff567c8cc1042 ]

To set frequency on specific cpus using cpupower, following syntax can
be used :
cpupower -c #i frequency-set -f #f -r

While setting frequency using cpupower frequency-set command, if we use
'-r' option, it is expected to set frequency for all cpus related to
cpu #i. But it is observed to be missing the last cpu in related cpu
list. This patch fixes the problem.

Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 tools/power/cpupower/utils/cpufreq-set.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/power/cpupower/utils/cpufreq-set.c b/tools/power/cpupower/utils/cpufreq-set.c
index f49bc4aa2a08..6ed82fba5aaa 100644
--- a/tools/power/cpupower/utils/cpufreq-set.c
+++ b/tools/power/cpupower/utils/cpufreq-set.c
@@ -305,6 +305,8 @@ int cmd_freq_set(int argc, char **argv)
 				bitmask_setbit(cpus_chosen, cpus->cpu);
 				cpus = cpus->next;
 			}
+			/* Set the last cpu in related cpus list */
+			bitmask_setbit(cpus_chosen, cpus->cpu);
 			cpufreq_put_related_cpus(cpus);
 		}
 	}
-- 
2.20.1

[PATCH AUTOSEL 5.2 099/249] x86/cpu: Add Ice Lake NNPI to Intel family

[Sasha Levin]

From: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>

[ Upstream commit e32d045cd4ba06b59878323e434bad010e78e658 ]

Add the CPUID model number of Ice Lake Neural Network Processor for Deep
Learning Inference (ICL-NNPI) to the Intel family list. Ice Lake NNPI uses
model number 0x9D and this will be documented in a future version of Intel
Software Development Manual.

Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@suse.de
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linux PM <linux-pm@vger.kernel.org>
Link: https://lkml.kernel.org/r/20190606012419.13250-1-rajneesh.bhardwaj@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/include/asm/intel-family.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 310118805f57..f60ddd655c78 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -56,6 +56,7 @@
 #define INTEL_FAM6_ICELAKE_XEON_D	0x6C
 #define INTEL_FAM6_ICELAKE_DESKTOP	0x7D
 #define INTEL_FAM6_ICELAKE_MOBILE	0x7E
+#define INTEL_FAM6_ICELAKE_NNPI		0x9D
 
 /* "Small Core" Processors (Atom) */
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 102/249] perf/x86: Add Intel Ice Lake NNPI uncore support

[Sasha Levin]

From: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>

[ Upstream commit 5f4318c1b1d23a9290e4def78ee76017c288bf60 ]

Intel Ice Lake uncore support already included IMC PCI ID but ICL-NNPI
CPUID is missing so add it to fix the probe function.

Fixes: e39875d15ad6 ("perf/x86: add Intel Icelake uncore support")
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: alexander.shishkin@linux.intel.com
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linux PM <linux-pm@vger.kernel.org>
Link: https://lkml.kernel.org/r/20190614081701.13828-1-rajneesh.bhardwaj@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/events/intel/uncore.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 9e3fbd47cb56..089bfcdf2f7f 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1400,6 +1400,7 @@ static const struct x86_cpu_id intel_uncore_match[] __initconst = {
 	X86_UNCORE_MODEL_MATCH(INTEL_FAM6_KABYLAKE_MOBILE, skl_uncore_init),
 	X86_UNCORE_MODEL_MATCH(INTEL_FAM6_KABYLAKE_DESKTOP, skl_uncore_init),
 	X86_UNCORE_MODEL_MATCH(INTEL_FAM6_ICELAKE_MOBILE, icl_uncore_init),
+	X86_UNCORE_MODEL_MATCH(INTEL_FAM6_ICELAKE_NNPI, icl_uncore_init),
 	{},
 };
 
-- 
2.20.1

[PATCH AUTOSEL 5.2 190/249] cpufreq: Avoid calling cpufreq_verify_current_freq() from handle_update()

[Sasha Levin]

From: Viresh Kumar <viresh.kumar@linaro.org>

[ Upstream commit 70a59fde6e69d1d8579f84bf4555bfffb3ce452d ]

On some occasions cpufreq_verify_current_freq() schedules a work whose
callback is handle_update(), which further calls cpufreq_update_policy()
which may end up calling cpufreq_verify_current_freq() again.

On the other hand, when cpufreq_update_policy() is called from
handle_update(), the pointer to the cpufreq policy is already
available, but cpufreq_cpu_acquire() is still called to get it in
cpufreq_update_policy(), which should be avoided as well.

To fix these issues, create a new helper, refresh_frequency_limits(),
and make both handle_update() call it cpufreq_update_policy().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Rename reeval_frequency_limits() as refresh_frequency_limits() ]
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e84bf0eb7239..876a4cb09de3 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1114,13 +1114,25 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int cp
 	return ret;
 }
 
+static void refresh_frequency_limits(struct cpufreq_policy *policy)
+{
+	struct cpufreq_policy new_policy = *policy;
+
+	pr_debug("updating policy for CPU %u\n", policy->cpu);
+
+	new_policy.min = policy->user_policy.min;
+	new_policy.max = policy->user_policy.max;
+
+	cpufreq_set_policy(policy, &new_policy);
+}
+
 static void handle_update(struct work_struct *work)
 {
 	struct cpufreq_policy *policy =
 		container_of(work, struct cpufreq_policy, update);
-	unsigned int cpu = policy->cpu;
-	pr_debug("handle_update for cpu %u called\n", cpu);
-	cpufreq_update_policy(cpu);
+
+	pr_debug("handle_update for cpu %u called\n", policy->cpu);
+	refresh_frequency_limits(policy);
 }
 
 static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
@@ -2392,7 +2404,6 @@ int cpufreq_set_policy(struct cpufreq_policy *policy,
 void cpufreq_update_policy(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_acquire(cpu);
-	struct cpufreq_policy new_policy;
 
 	if (!policy)
 		return;
@@ -2405,12 +2416,7 @@ void cpufreq_update_policy(unsigned int cpu)
 	    (cpufreq_suspended || WARN_ON(!cpufreq_update_current_freq(policy))))
 		goto unlock;
 
-	pr_debug("updating policy for CPU %u\n", cpu);
-	memcpy(&new_policy, policy, sizeof(*policy));
-	new_policy.min = policy->user_policy.min;
-	new_policy.max = policy->user_policy.max;
-
-	cpufreq_set_policy(policy, &new_policy);
+	refresh_frequency_limits(policy);
 
 unlock:
 	cpufreq_cpu_release(policy);
-- 
2.20.1

[PATCH AUTOSEL 5.2 191/249] cpufreq: Don't skip frequency validation for has_target() drivers

[Sasha Levin]

From: Viresh Kumar <viresh.kumar@linaro.org>

[ Upstream commit 9801522840cc1073f8064b4c979b7b6995c74bca ]

CPUFREQ_CONST_LOOPS was introduced in a very old commit from pre-2.6
kernel release by commit 6a4a93f9c0d5 ("[CPUFREQ] Fix 'out of sync'
issue").

Basically, that commit does two things:

 - It adds the frequency verification code (which is quite similar to
   what we have today as well).

 - And it sets the CPUFREQ_CONST_LOOPS flag only for setpolicy drivers,
   rightly so based on the code we had then. The idea was to avoid
   frequency validation for setpolicy drivers as the cpufreq core doesn't
   know what frequency the hardware is running at and so no point in
   doing frequency verification.

The problem happened when we started to use the same CPUFREQ_CONST_LOOPS
flag for constant loops-per-jiffy thing as well and many has_target()
drivers started using the same flag and unknowingly skipped the
verification of frequency. There is no logical reason behind skipping
frequency validation because of the presence of CPUFREQ_CONST_LOOPS
flag otherwise.

Fix this issue by skipping frequency validation only for setpolicy
drivers and always doing it for has_target() drivers irrespective of
the presence or absence of CPUFREQ_CONST_LOOPS flag.

cpufreq_notify_transition() is only called for has_target() type driver
and not for set_policy type, and the check is simply redundant. Remove
it as well.

Also remove () around freq comparison statement as they aren't required
and checkpatch also warns for them.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/cpufreq/cpufreq.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 876a4cb09de3..7d37efb43621 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -356,12 +356,10 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy,
 		 * which is not equal to what the cpufreq core thinks is
 		 * "old frequency".
 		 */
-		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
-			if (policy->cur && (policy->cur != freqs->old)) {
-				pr_debug("Warning: CPU frequency is %u, cpufreq assumed %u kHz\n",
-					 freqs->old, policy->cur);
-				freqs->old = policy->cur;
-			}
+		if (policy->cur && policy->cur != freqs->old) {
+			pr_debug("Warning: CPU frequency is %u, cpufreq assumed %u kHz\n",
+				 freqs->old, policy->cur);
+			freqs->old = policy->cur;
 		}
 
 		srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
@@ -1627,8 +1625,7 @@ static unsigned int __cpufreq_get(struct cpufreq_policy *policy)
 	if (policy->fast_switch_enabled)
 		return ret_freq;
 
-	if (ret_freq && policy->cur &&
-		!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+	if (has_target() && ret_freq && policy->cur) {
 		/* verify no discrepancy between actual and
 					saved value exists */
 		if (unlikely(ret_freq != policy->cur)) {
-- 
2.20.1

Re: [PATCH AUTOSEL 5.2 190/249] cpufreq: Avoid calling cpufreq_verify_current_freq() from handle_update()

[Rafael J. Wysocki]

On 7/15/2019 3:45 PM, Sasha Levin wrote:
> From: Viresh Kumar <viresh.kumar@linaro.org>
>
> [ Upstream commit 70a59fde6e69d1d8579f84bf4555bfffb3ce452d ]
>
> On some occasions cpufreq_verify_current_freq() schedules a work whose
> callback is handle_update(), which further calls cpufreq_update_policy()
> which may end up calling cpufreq_verify_current_freq() again.
>
> On the other hand, when cpufreq_update_policy() is called from
> handle_update(), the pointer to the cpufreq policy is already
> available, but cpufreq_cpu_acquire() is still called to get it in
> cpufreq_update_policy(), which should be avoided as well.
>
> To fix these issues, create a new helper, refresh_frequency_limits(),
> and make both handle_update() call it cpufreq_update_policy().
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> [ rjw: Rename reeval_frequency_limits() as refresh_frequency_limits() ]
> [ rjw: Changelog ]
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>   drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++----------
>   1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e84bf0eb7239..876a4cb09de3 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1114,13 +1114,25 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int cp
>   	return ret;
>   }
>   
> +static void refresh_frequency_limits(struct cpufreq_policy *policy)
> +{
> +	struct cpufreq_policy new_policy = *policy;
> +
> +	pr_debug("updating policy for CPU %u\n", policy->cpu);
> +
> +	new_policy.min = policy->user_policy.min;
> +	new_policy.max = policy->user_policy.max;
> +
> +	cpufreq_set_policy(policy, &new_policy);
> +}
> +
>   static void handle_update(struct work_struct *work)
>   {
>   	struct cpufreq_policy *policy =
>   		container_of(work, struct cpufreq_policy, update);
> -	unsigned int cpu = policy->cpu;
> -	pr_debug("handle_update for cpu %u called\n", cpu);
> -	cpufreq_update_policy(cpu);
> +
> +	pr_debug("handle_update for cpu %u called\n", policy->cpu);
> +	refresh_frequency_limits(policy);
>   }
>   
>   static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
> @@ -2392,7 +2404,6 @@ int cpufreq_set_policy(struct cpufreq_policy *policy,
>   void cpufreq_update_policy(unsigned int cpu)
>   {
>   	struct cpufreq_policy *policy = cpufreq_cpu_acquire(cpu);
> -	struct cpufreq_policy new_policy;
>   
>   	if (!policy)
>   		return;
> @@ -2405,12 +2416,7 @@ void cpufreq_update_policy(unsigned int cpu)
>   	    (cpufreq_suspended || WARN_ON(!cpufreq_update_current_freq(policy))))
>   		goto unlock;
>   
> -	pr_debug("updating policy for CPU %u\n", cpu);
> -	memcpy(&new_policy, policy, sizeof(*policy));
> -	new_policy.min = policy->user_policy.min;
> -	new_policy.max = policy->user_policy.max;
> -
> -	cpufreq_set_policy(policy, &new_policy);
> +	refresh_frequency_limits(policy);
>   
>   unlock:
>   	cpufreq_cpu_release(policy);

I don't think this is suitable for -stable.

Re: [PATCH AUTOSEL 5.2 190/249] cpufreq: Avoid calling cpufreq_verify_current_freq() from handle_update()

[Sasha Levin]

On Tue, Jul 16, 2019 at 11:25:00AM +0200, Rafael J. Wysocki wrote:
>On 7/15/2019 3:45 PM, Sasha Levin wrote:
>>From: Viresh Kumar <viresh.kumar@linaro.org>
>>
>>[ Upstream commit 70a59fde6e69d1d8579f84bf4555bfffb3ce452d ]
>>
>>On some occasions cpufreq_verify_current_freq() schedules a work whose
>>callback is handle_update(), which further calls cpufreq_update_policy()
>>which may end up calling cpufreq_verify_current_freq() again.
>>
>>On the other hand, when cpufreq_update_policy() is called from
>>handle_update(), the pointer to the cpufreq policy is already
>>available, but cpufreq_cpu_acquire() is still called to get it in
>>cpufreq_update_policy(), which should be avoided as well.
>>
>>To fix these issues, create a new helper, refresh_frequency_limits(),
>>and make both handle_update() call it cpufreq_update_policy().
>>
>>Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>[ rjw: Rename reeval_frequency_limits() as refresh_frequency_limits() ]
>>[ rjw: Changelog ]
>>Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>Signed-off-by: Sasha Levin <sashal@kernel.org>
>>---
>>  drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++----------
>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>
>>diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>index e84bf0eb7239..876a4cb09de3 100644
>>--- a/drivers/cpufreq/cpufreq.c
>>+++ b/drivers/cpufreq/cpufreq.c
>>@@ -1114,13 +1114,25 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int cp
>>  	return ret;
>>  }
>>+static void refresh_frequency_limits(struct cpufreq_policy *policy)
>>+{
>>+	struct cpufreq_policy new_policy = *policy;
>>+
>>+	pr_debug("updating policy for CPU %u\n", policy->cpu);
>>+
>>+	new_policy.min = policy->user_policy.min;
>>+	new_policy.max = policy->user_policy.max;
>>+
>>+	cpufreq_set_policy(policy, &new_policy);
>>+}
>>+
>>  static void handle_update(struct work_struct *work)
>>  {
>>  	struct cpufreq_policy *policy =
>>  		container_of(work, struct cpufreq_policy, update);
>>-	unsigned int cpu = policy->cpu;
>>-	pr_debug("handle_update for cpu %u called\n", cpu);
>>-	cpufreq_update_policy(cpu);
>>+
>>+	pr_debug("handle_update for cpu %u called\n", policy->cpu);
>>+	refresh_frequency_limits(policy);
>>  }
>>  static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
>>@@ -2392,7 +2404,6 @@ int cpufreq_set_policy(struct cpufreq_policy *policy,
>>  void cpufreq_update_policy(unsigned int cpu)
>>  {
>>  	struct cpufreq_policy *policy = cpufreq_cpu_acquire(cpu);
>>-	struct cpufreq_policy new_policy;
>>  	if (!policy)
>>  		return;
>>@@ -2405,12 +2416,7 @@ void cpufreq_update_policy(unsigned int cpu)
>>  	    (cpufreq_suspended || WARN_ON(!cpufreq_update_current_freq(policy))))
>>  		goto unlock;
>>-	pr_debug("updating policy for CPU %u\n", cpu);
>>-	memcpy(&new_policy, policy, sizeof(*policy));
>>-	new_policy.min = policy->user_policy.min;
>>-	new_policy.max = policy->user_policy.max;
>>-
>>-	cpufreq_set_policy(policy, &new_policy);
>>+	refresh_frequency_limits(policy);
>>  unlock:
>>  	cpufreq_cpu_release(policy);
>
>I don't think this is suitable for -stable.

I've dropped it, thanks!

--
Thanks,
Sasha