* [PATCH v2 1/2] PM / devfreq: exynos: Use Use devm_clk_get_enabled() helpers
From: Anand Moon @ 2024-04-03 18:15 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar
Cc: Anand Moon, linux-pm, linux-samsung-soc, linux-arm-kernel,
linux-kernel
The devm_clk_get_enabled() helpers:
- call devm_clk_get()
- call clk_prepare_enable() and register what is needed in order to
call clk_disable_unprepare() when needed, as a managed resource.
This simplifies the code and avoids the calls to clk_disable_unprepare().
While at it, use dev_err_probe consistently, and use its return value
to return the error code.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v2: no changes
---
drivers/devfreq/exynos-bus.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 245898f1a88e..153340b6685f 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -160,7 +160,6 @@ static void exynos_bus_exit(struct device *dev)
platform_device_unregister(bus->icc_pdev);
dev_pm_opp_of_remove_table(dev);
- clk_disable_unprepare(bus->clk);
dev_pm_opp_put_regulators(bus->opp_token);
}
@@ -171,7 +170,6 @@ static void exynos_bus_passive_exit(struct device *dev)
platform_device_unregister(bus->icc_pdev);
dev_pm_opp_of_remove_table(dev);
- clk_disable_unprepare(bus->clk);
}
static int exynos_bus_parent_parse_of(struct device_node *np,
@@ -247,23 +245,15 @@ static int exynos_bus_parse_of(struct device_node *np,
int ret;
/* Get the clock to provide each bus with source clock */
- bus->clk = devm_clk_get(dev, "bus");
- if (IS_ERR(bus->clk)) {
- dev_err(dev, "failed to get bus clock\n");
- return PTR_ERR(bus->clk);
- }
-
- ret = clk_prepare_enable(bus->clk);
- if (ret < 0) {
- dev_err(dev, "failed to get enable clock\n");
- return ret;
- }
+ bus->clk = devm_clk_get_enabled(dev, "bus");
+ if (IS_ERR(bus->clk))
+ return dev_err_probe(dev, PTR_ERR(bus->clk), "failed to get bus clock\n");
/* Get the freq and voltage from OPP table to scale the bus freq */
ret = dev_pm_opp_of_add_table(dev);
if (ret < 0) {
dev_err(dev, "failed to get OPP table\n");
- goto err_clk;
+ return ret;
}
rate = clk_get_rate(bus->clk);
@@ -281,8 +271,6 @@ static int exynos_bus_parse_of(struct device_node *np,
err_opp:
dev_pm_opp_of_remove_table(dev);
-err_clk:
- clk_disable_unprepare(bus->clk);
return ret;
}
@@ -453,7 +441,6 @@ static int exynos_bus_probe(struct platform_device *pdev)
err:
dev_pm_opp_of_remove_table(dev);
- clk_disable_unprepare(bus->clk);
err_reg:
dev_pm_opp_put_regulators(bus->opp_token);
--
2.44.0
^ permalink raw reply related
* [PATCH v1 1/2] thermal: gov_step_wise: Simplify get_target_state()
From: Rafael J. Wysocki @ 2024-04-03 18:11 UTC (permalink / raw)
To: Linux PM; +Cc: LKML, Lukasz Luba, Daniel Lezcano
In-Reply-To: <5766468.DvuYhMxLoT@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The step-wise governor's get_target_state() function contains redundant
braces, redundant parens and a redundant next_target local variable, so
get rid of all that stuff.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/thermal/gov_step_wise.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
Index: linux-pm/drivers/thermal/gov_step_wise.c
===================================================================
--- linux-pm.orig/drivers/thermal/gov_step_wise.c
+++ linux-pm/drivers/thermal/gov_step_wise.c
@@ -32,7 +32,6 @@ static unsigned long get_target_state(st
{
struct thermal_cooling_device *cdev = instance->cdev;
unsigned long cur_state;
- unsigned long next_target;
/*
* We keep this instance the way it is by default.
@@ -40,32 +39,26 @@ static unsigned long get_target_state(st
* cdev in use to determine the next_target.
*/
cdev->ops->get_cur_state(cdev, &cur_state);
- next_target = instance->target;
dev_dbg(&cdev->device, "cur_state=%ld\n", cur_state);
if (!instance->initialized) {
- if (throttle) {
- next_target = clamp((cur_state + 1), instance->lower, instance->upper);
- } else {
- next_target = THERMAL_NO_TARGET;
- }
+ if (throttle)
+ return clamp(cur_state + 1, instance->lower, instance->upper);
- return next_target;
+ return THERMAL_NO_TARGET;
}
if (throttle) {
if (trend == THERMAL_TREND_RAISING)
- next_target = clamp((cur_state + 1), instance->lower, instance->upper);
- } else {
- if (trend == THERMAL_TREND_DROPPING) {
- if (cur_state <= instance->lower)
- next_target = THERMAL_NO_TARGET;
- else
- next_target = clamp((cur_state - 1), instance->lower, instance->upper);
- }
+ return clamp(cur_state + 1, instance->lower, instance->upper);
+ } else if (trend == THERMAL_TREND_DROPPING) {
+ if (cur_state <= instance->lower)
+ return THERMAL_NO_TARGET;
+
+ return clamp(cur_state - 1, instance->lower, instance->upper);
}
- return next_target;
+ return instance->target;
}
static void thermal_zone_trip_update(struct thermal_zone_device *tz,
^ permalink raw reply
* [PATCH v1 0/2] thermal: gov_step_wide: Two cleanups
From: Rafael J. Wysocki @ 2024-04-03 18:09 UTC (permalink / raw)
To: Linux PM; +Cc: LKML, Lukasz Luba, Daniel Lezcano
Hi Everyone,
The patches in this series clean up the step-wise thermal governor
and are not expected to alter its functionality.
Please see the changelogs of the patches for details.
The patches should apply directly on top of 6.9-rc2.
Thanks!
^ permalink raw reply
* [PATCH v1 2/2] thermal: gov_step_wise: Simplify checks related to passive trips
From: Rafael J. Wysocki @ 2024-04-03 18:12 UTC (permalink / raw)
To: Linux PM; +Cc: LKML, Lukasz Luba, Daniel Lezcano
In-Reply-To: <5766468.DvuYhMxLoT@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make it more clear from the code flow that the passive polling status
updates only take place for passive trip points.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/thermal/gov_step_wise.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-pm/drivers/thermal/gov_step_wise.c
===================================================================
--- linux-pm.orig/drivers/thermal/gov_step_wise.c
+++ linux-pm/drivers/thermal/gov_step_wise.c
@@ -92,15 +92,13 @@ static void thermal_zone_trip_update(str
if (instance->initialized && old_target == instance->target)
continue;
- if (old_target == THERMAL_NO_TARGET &&
- instance->target != THERMAL_NO_TARGET) {
- /* Activate a passive thermal instance */
- if (trip->type == THERMAL_TRIP_PASSIVE)
+ if (trip->type == THERMAL_TRIP_PASSIVE) {
+ /* If needed, update the status of passive polling. */
+ if (old_target == THERMAL_NO_TARGET &&
+ instance->target != THERMAL_NO_TARGET)
tz->passive++;
- } else if (old_target != THERMAL_NO_TARGET &&
- instance->target == THERMAL_NO_TARGET) {
- /* Deactivate a passive thermal instance */
- if (trip->type == THERMAL_TRIP_PASSIVE)
+ else if (old_target != THERMAL_NO_TARGET &&
+ instance->target == THERMAL_NO_TARGET)
tz->passive--;
}
^ permalink raw reply
* [PATCH AUTOSEL 6.1 09/15] thermal/of: Assume polling-delay(-passive) 0 when absent
From: Sasha Levin @ 2024-04-03 17:18 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Konrad Dybcio, Bjorn Andersson, Dmitry Baryshkov, Daniel Lezcano,
Sasha Levin, rafael, linux-pm
In-Reply-To: <20240403171909.345570-1-sashal@kernel.org>
From: Konrad Dybcio <konrad.dybcio@linaro.org>
[ Upstream commit 488164006a281986d95abbc4b26e340c19c4c85b ]
Currently, thermal zones associated with providers that have interrupts
for signaling hot/critical trips are required to set a polling-delay
of 0 to indicate no polling. This feels a bit backwards.
Change the code such that "no polling delay" also means "no polling".
Suggested-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-2-3c9d4dced138@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/thermal_of.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index 4104743dbc17e..202dce0d2e309 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -337,14 +337,18 @@ static int thermal_of_monitor_init(struct device_node *np, int *delay, int *pdel
int ret;
ret = of_property_read_u32(np, "polling-delay-passive", pdelay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay-passive property\n", np);
+ if (ret == -EINVAL) {
+ *pdelay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay-passive: %d\n", np, ret);
return ret;
}
ret = of_property_read_u32(np, "polling-delay", delay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay property\n", np);
+ if (ret == -EINVAL) {
+ *delay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay: %d\n", np, ret);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 11/20] thermal/of: Assume polling-delay(-passive) 0 when absent
From: Sasha Levin @ 2024-04-03 17:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Konrad Dybcio, Bjorn Andersson, Dmitry Baryshkov, Daniel Lezcano,
Sasha Levin, rafael, linux-pm
In-Reply-To: <20240403171815.342668-1-sashal@kernel.org>
From: Konrad Dybcio <konrad.dybcio@linaro.org>
[ Upstream commit 488164006a281986d95abbc4b26e340c19c4c85b ]
Currently, thermal zones associated with providers that have interrupts
for signaling hot/critical trips are required to set a polling-delay
of 0 to indicate no polling. This feels a bit backwards.
Change the code such that "no polling delay" also means "no polling".
Suggested-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-2-3c9d4dced138@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/thermal_of.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index 1e0655b63259f..d5174f11b91c2 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -225,14 +225,18 @@ static int thermal_of_monitor_init(struct device_node *np, int *delay, int *pdel
int ret;
ret = of_property_read_u32(np, "polling-delay-passive", pdelay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay-passive property\n", np);
+ if (ret == -EINVAL) {
+ *pdelay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay-passive: %d\n", np, ret);
return ret;
}
ret = of_property_read_u32(np, "polling-delay", delay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay property\n", np);
+ if (ret == -EINVAL) {
+ *delay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay: %d\n", np, ret);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 16/28] thermal/of: Assume polling-delay(-passive) 0 when absent
From: Sasha Levin @ 2024-04-03 17:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Konrad Dybcio, Bjorn Andersson, Dmitry Baryshkov, Daniel Lezcano,
Sasha Levin, rafael, linux-pm
In-Reply-To: <20240403171656.335224-1-sashal@kernel.org>
From: Konrad Dybcio <konrad.dybcio@linaro.org>
[ Upstream commit 488164006a281986d95abbc4b26e340c19c4c85b ]
Currently, thermal zones associated with providers that have interrupts
for signaling hot/critical trips are required to set a polling-delay
of 0 to indicate no polling. This feels a bit backwards.
Change the code such that "no polling delay" also means "no polling".
Suggested-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-2-3c9d4dced138@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/thermal_of.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index 4d6c22e0ed85b..61bbd42aa2cb4 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -225,14 +225,18 @@ static int thermal_of_monitor_init(struct device_node *np, int *delay, int *pdel
int ret;
ret = of_property_read_u32(np, "polling-delay-passive", pdelay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay-passive property\n", np);
+ if (ret == -EINVAL) {
+ *pdelay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay-passive: %d\n", np, ret);
return ret;
}
ret = of_property_read_u32(np, "polling-delay", delay);
- if (ret < 0) {
- pr_err("%pOFn: missing polling-delay property\n", np);
+ if (ret == -EINVAL) {
+ *delay = 0;
+ } else if (ret < 0) {
+ pr_err("%pOFn: Couldn't get polling-delay: %d\n", np, ret);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] cpufreq: scmi: Update Energy Model with allowed performance limits
From: Lukasz Luba @ 2024-04-03 16:23 UTC (permalink / raw)
To: linux-kernel, linux-pm
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sudeep.holla,
cristian.marussi, linux-samsung-soc, rafael, viresh.kumar,
quic_sibis
In-Reply-To: <20240403162315.1458337-1-lukasz.luba@arm.com>
The Energy Model (EM) supports performance limits updates. Use the SCMI
notifications to get information from FW about allowed frequency scope for
the CPUs.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
drivers/cpufreq/scmi-cpufreq.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index d946b7a082584..90c8448578cb1 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -185,12 +185,25 @@ static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event,
{
struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb);
struct scmi_perf_limits_report *limit_notify = data;
+ unsigned int limit_freq_max_khz, limit_freq_min_khz;
struct cpufreq_policy *policy = priv->policy;
- unsigned int limit_freq_khz;
+ struct em_perf_domain *pd;
+ int ret;
+
+ limit_freq_max_khz = limit_notify->range_max_freq / HZ_PER_KHZ;
+ limit_freq_min_khz = limit_notify->range_min_freq / HZ_PER_KHZ;
- limit_freq_khz = limit_notify->range_max_freq / HZ_PER_KHZ;
+ pd = em_cpu_get(policy->cpu);
+ if (pd) {
+ ret = em_update_performance_limits(pd, limit_freq_min_khz,
+ limit_freq_max_khz);
+ if (ret)
+ dev_warn(priv->cpu_dev,
+ "EM perf limits update failed\n");
+ }
- policy->max = clamp(limit_freq_khz, policy->cpuinfo.min_freq, policy->cpuinfo.max_freq);
+ policy->max = clamp(limit_freq_max_khz, policy->cpuinfo.min_freq,
+ policy->cpuinfo.max_freq);
cpufreq_update_pressure(policy);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] PM: EM: Add min/max available performance state limits
From: Lukasz Luba @ 2024-04-03 16:23 UTC (permalink / raw)
To: linux-kernel, linux-pm
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sudeep.holla,
cristian.marussi, linux-samsung-soc, rafael, viresh.kumar,
quic_sibis
In-Reply-To: <20240403162315.1458337-1-lukasz.luba@arm.com>
On some devices there are HW dependencies for shared frequency and voltage
between devices: CPUs and L3 cache. When the L3 cache frequency is
increased, the affected CPUs might run at higher voltage and frequency.
That higher voltage causes higher CPU power and thus more energy is used
for running the tasks.
Add performance state limits which are applied for the device. This allows
the Energy Model (EM) to better reflect the CPU's currently available
performance states. This information is used by Energy Aware Scheduler
(EAS) during task placement to avoid situation when a simulated energy
cost has error due to using wrong Power Domain (PD) frequency.
The function performs only bare minimum checks (and requires EM as
an argument) to reduce the overhead.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
include/linux/energy_model.h | 22 ++++++++++++++---
kernel/power/energy_model.c | 48 ++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index d30d67c2f07cf..feadd0fd6b356 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -55,6 +55,8 @@ struct em_perf_table {
* struct em_perf_domain - Performance domain
* @em_table: Pointer to the runtime modifiable em_perf_table
* @nr_perf_states: Number of performance states
+ * @min_ps: Minimum available performance state index
+ * @max_ps: Maximum available performance state index
* @flags: See "em_perf_domain flags"
* @cpus: Cpumask covering the CPUs of the domain. It's here
* for performance reasons to avoid potential cache
@@ -70,6 +72,8 @@ struct em_perf_table {
struct em_perf_domain {
struct em_perf_table __rcu *em_table;
int nr_perf_states;
+ int min_ps;
+ int max_ps;
unsigned long flags;
unsigned long cpus[];
};
@@ -173,6 +177,8 @@ void em_table_free(struct em_perf_table __rcu *table);
int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
int nr_states);
int em_dev_update_chip_binning(struct device *dev);
+int em_update_performance_limits(struct em_perf_domain *pd,
+ unsigned long freq_min_khz, unsigned long freq_max_khz);
/**
* em_pd_get_efficient_state() - Get an efficient performance state from the EM
@@ -189,12 +195,13 @@ int em_dev_update_chip_binning(struct device *dev);
*/
static inline int
em_pd_get_efficient_state(struct em_perf_state *table, int nr_perf_states,
- unsigned long max_util, unsigned long pd_flags)
+ unsigned long max_util, unsigned long pd_flags,
+ int min_ps, int max_ps)
{
struct em_perf_state *ps;
int i;
- for (i = 0; i < nr_perf_states; i++) {
+ for (i = min_ps; i <= max_ps; i++) {
ps = &table[i];
if (ps->performance >= max_util) {
if (pd_flags & EM_PERF_DOMAIN_SKIP_INEFFICIENCIES &&
@@ -204,7 +211,7 @@ em_pd_get_efficient_state(struct em_perf_state *table, int nr_perf_states,
}
}
- return nr_perf_states - 1;
+ return max_ps;
}
/**
@@ -255,7 +262,8 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
*/
em_table = rcu_dereference(pd->em_table);
i = em_pd_get_efficient_state(em_table->state, pd->nr_perf_states,
- max_util, pd->flags);
+ max_util, pd->flags, pd->min_ps,
+ pd->max_ps);
ps = &em_table->state[i];
/*
@@ -392,6 +400,12 @@ static inline int em_dev_update_chip_binning(struct device *dev)
{
return -EINVAL;
}
+static inline
+int em_update_performance_limits(struct em_perf_domain *pd,
+ unsigned long freq_min_khz, unsigned long freq_max_khz)
+{
+ return -EINVAL;
+}
#endif
#endif
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 927cc55ba0b3d..1a8b394251cb2 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -628,6 +628,8 @@ int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
goto unlock;
dev->em_pd->flags |= flags;
+ dev->em_pd->min_ps = 0;
+ dev->em_pd->max_ps = nr_states - 1;
em_cpufreq_update_efficiencies(dev, dev->em_pd->em_table->state);
@@ -856,3 +858,49 @@ int em_dev_update_chip_binning(struct device *dev)
return em_recalc_and_update(dev, pd, em_table);
}
EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
+
+
+/**
+ * em_update_performance_limits() - Update Energy Model with performance
+ * limits information.
+ * @pd : Performance Domain with EM that has to be updated.
+ * @freq_min_khz : New minimum allowed frequency for this device.
+ * @freq_max_khz : New maximum allowed frequency for this device.
+ *
+ * This function allows to update the EM with information about available
+ * performance levels. It takes the minimum and maximum frequency in kHz
+ * and does internal translation to performance levels.
+ * Returns 0 on success or -EINVAL when failed.
+ */
+int em_update_performance_limits(struct em_perf_domain *pd,
+ unsigned long freq_min_khz, unsigned long freq_max_khz)
+{
+ struct em_perf_state *table;
+ int min_ps = -1;
+ int max_ps = -1;
+ int i;
+
+ if (!pd)
+ return -EINVAL;
+
+ rcu_read_lock();
+ table = em_perf_state_from_pd(pd);
+
+ for (i = 0; i < pd->nr_perf_states; i++) {
+ if (freq_min_khz == table[i].frequency)
+ min_ps = i;
+ if (freq_max_khz == table[i].frequency)
+ max_ps = i;
+ }
+ rcu_read_unlock();
+
+ /* Only update when both are found and sane */
+ if (min_ps < 0 || max_ps < 0 || max_ps < min_ps)
+ return -EINVAL;
+
+ pd->min_ps = min_ps;
+ pd->max_ps = max_ps;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(em_update_performance_limits);
--
2.25.1
^ permalink raw reply related
* [PATCH 0/2] Update Energy Model with perfromance limits
From: Lukasz Luba @ 2024-04-03 16:23 UTC (permalink / raw)
To: linux-kernel, linux-pm
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sudeep.holla,
cristian.marussi, linux-samsung-soc, rafael, viresh.kumar,
quic_sibis
Hi all,
This patch set allows to specify in the EM the range of performance levels that
the device is allowed to operate. It will impact EAS decision, especially for
SoCs where CPUs share the voltage & frequency domain with other CPUs or devices
e.g.
- Mid CPUs + Big CPU
- Little CPU + L3 cache in DSU
The minimum allowed frequency will be taken into account while doing EAS task
placement simulation. When the min frequency is higher for the whole domain
and not driven by the CPUs in that PD utilization, than the energy for
computation in that PD will be higher. This patch helps to reflect that higher
cost.
More explanation can be found in my presentation on OSPM2023 [1].
I have shown experiments with Big CPU running high frequency and increasing
the L3 cache frequency (to reduce the latency), but that impacted Little
CPU which are in the same DVFS domain with L3 cache. It had bad impact for
total energy consumed by small tasks placed on Little CPU. The EAS was not
aware about the min frequency&voltage of the Little CPUs and energy estimation
was wrong.
Depends on:
patch 2/2:
- SCMI cpufreq performance limits notification support (w/ other
dependency) [2]
patch 1/2:
- EM recent patches for chip binning update - to avoid conflict [3]
Therefore, the patch 1/2 could go first and patch 2/2 can wait longer.
Regards,
Lukasz Luba
[1] https://www.youtube.com/watch?v=2C-5uikSbtM&list=PL0fKordpLTjKsBOUcZqnzlHShri4YBL1H
[2] https://lore.kernel.org/lkml/20240328074131.2839871-1-quic_sibis@quicinc.com/
[3] https://lore.kernel.org/lkml/20240403154907.1420245-1-lukasz.luba@arm.com/
Lukasz Luba (2):
PM: EM: Add min/max available performance state limits
cpufreq: scmi: Update Energy Model with allowed performance limits
drivers/cpufreq/scmi-cpufreq.c | 19 +++++++++++---
include/linux/energy_model.h | 22 +++++++++++++---
kernel/power/energy_model.c | 48 ++++++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 7 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Valentin Schneider @ 2024-04-03 16:17 UTC (permalink / raw)
To: Waiman Long, Michal Koutný
Cc: Tejun Heo, Zefan Li, Johannes Weiner, Thomas Gleixner,
Peter Zijlstra, Rafael J. Wysocki, Len Brown, Pavel Machek,
Shuah Khan, linux-kernel, cgroups, linux-pm, linux-kselftest,
Frederic Weisbecker, Paul E. McKenney, Ingo Molnar,
Anna-Maria Behnsen, Alex Shi, Vincent Guittot, Barry Song
In-Reply-To: <620d1b70-cfbc-4b76-ad04-b3be559afd56@redhat.com>
On 03/04/24 10:47, Waiman Long wrote:
> On 4/3/24 10:26, Valentin Schneider wrote:
>> IIUC that was Thomas' suggestion [1], but I can't tell yet how bad it would
>> be to change cgroup_lock() to also do a cpus_read_lock().
>
> Changing the locking order is certainly doable. I have taken a cursory
> look at it and at least the following files need to be changed:
>
> kernel/bpf/cgroup.c
> kernel/cgroup/cgroup.c
> kernel/cgroup/legacy_freezer.c
> mm/memcontrol.c
>
> That requires a lot more testing to make sure that there won't be a
> regression. Given that the call to cgroup_transfer_tasks() should be
> rare these days as it will only apply in the case of cgroup v1 under
> certain condtion, I am not sure this requirement justifies making such
> extensive changes. So I kind of defer it until we reach a consensus that
> it is the right thing to do.
>
Yeah if we can avoid it initially I'd be up for it.
Just one thing that came to mind - there's no flushing of the
cpuset_migrate_tasks_workfn() work, so the scheduler might move tasks
itself before the cpuset does via:
balance_push() ->__balance_push_cpu_stop() -> select_fallback_rq()
But, given the current placement of cpuset_wait_for_hotplug(), I believe
that's something we can already have, so we should be good.
> Cheers,
> Longman
^ permalink raw reply
* Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Valentin Schneider @ 2024-04-03 16:02 UTC (permalink / raw)
To: Michal Koutný
Cc: Waiman Long, Tejun Heo, Zefan Li, Johannes Weiner,
Thomas Gleixner, Peter Zijlstra, Rafael J. Wysocki, Len Brown,
Pavel Machek, Shuah Khan, linux-kernel, cgroups, linux-pm,
linux-kselftest, Frederic Weisbecker, Paul E. McKenney,
Ingo Molnar, Anna-Maria Behnsen, Alex Shi, Vincent Guittot,
Barry Song
In-Reply-To: <mhwbjfm3zsoinm2eozz6d7djtflf6tbpmfzsbbsscv3u5aijtr@p2edxl6voxoa>
On 03/04/24 16:54, Michal Koutný wrote:
> On Wed, Apr 03, 2024 at 04:26:38PM +0200, Valentin Schneider <vschneid@redhat.com> wrote:
>> Also, I gave Michal's patch a try and it looks like it's introducing a
>
> Thank you.
>
>> cgroup_threadgroup_rwsem -> cpuset_mutex
>> ordering from
>> cgroup_transfer_tasks_locked()
>> `\
>> percpu_down_write(&cgroup_threadgroup_rwsem);
>> cgroup_migrate()
>> `\
>> cgroup_migrate_execute()
>> `\
>> ss->can_attach() // cpuset_can_attach()
>> `\
>> mutex_lock(&cpuset_mutex);
>>
>> which is invalid, see below.
>
> _This_ should be the right order (cpuset_mutex inside
> cgroup_threadgroup_rwsem), at least in my mental model. Thus I missed
> that cpuset_mutex must have been taken somewhere higher up in the
> hotplug code (CPU 0 in the lockdep dump, I can't easily see where from)
> :-/.
>
If I got this right...
cpuset_hotplug_update_tasks()
`\
mutex_lock(&cpuset_mutex);
hotplug_update_tasks_legacy()
`\
remove_tasks_in_empty_cpuset()
`\
cgroup_transfer_tasks_locked()
`\
percpu_down_write(&cgroup_threadgroup_rwsem);
But then that is also followed by:
cgroup_migrate()
`\
cgroup_migrate_execute()
`\
ss->can_attach() // cpuset_can_attach()
`\
mutex_lock(&cpuset_mutex);
which doesn't look good...
Also, I missed that earlier, but this triggers:
cgroup_transfer_tasks_locked() ~> lockdep_assert_held(&cgroup_mutex);
[ 30.773092] WARNING: CPU: 2 PID: 24 at kernel/cgroup/cgroup-v1.c:112 cgroup_transfer_tasks_locked+0x39f/0x450
[ 30.773807] Modules linked in:
[ 30.774063] CPU: 2 PID: 24 Comm: cpuhp/2 Not tainted 6.9.0-rc1-00042-g844178b616c7-dirty #25
[ 30.774672] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 30.775457] RIP: 0010:cgroup_transfer_tasks_locked+0x39f/0x450
[ 30.775891] Code: 0f 85 70 ff ff ff 0f 1f 44 00 00 e9 6d ff ff ff be ff ff ff ff 48 c7 c7 48 82 d6 82 e8 5a 6a ec 00 85 c0 0f 85 6d fd ff ff 90 <0f> 0b 90 e9 64 fd ff ff 48 8b bd e8 fe ff ff be 01 00 00 00 e8 78
[ 30.777270] RSP: 0000:ffffc900000e7c20 EFLAGS: 00010246
[ 30.777813] RAX: 0000000000000000 RBX: ffffc900000e7cb0 RCX: 0000000000000000
[ 30.778443] RDX: 0000000000000000 RSI: ffffffff82d68248 RDI: ffff888004a9a300
[ 30.779142] RBP: ffffc900000e7d50 R08: 0000000000000001 R09: 0000000000000000
[ 30.779889] R10: ffffc900000e7d70 R11: 0000000000000001 R12: ffff8880057c6040
[ 30.780420] R13: ffff88800539f800 R14: 0000000000000001 R15: 0000000000000004
[ 30.780951] FS: 0000000000000000(0000) GS:ffff88801f500000(0000) knlGS:0000000000000000
[ 30.781561] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 30.781989] CR2: 00000000f7e6fe85 CR3: 00000000064ac000 CR4: 00000000000006f0
[ 30.782558] Call Trace:
[ 30.782783] <TASK>
[ 30.782982] ? __warn+0x87/0x180
[ 30.783250] ? cgroup_transfer_tasks_locked+0x39f/0x450
[ 30.783644] ? report_bug+0x164/0x190
[ 30.783970] ? handle_bug+0x3b/0x70
[ 30.784288] ? exc_invalid_op+0x17/0x70
[ 30.784641] ? asm_exc_invalid_op+0x1a/0x20
[ 30.784992] ? cgroup_transfer_tasks_locked+0x39f/0x450
[ 30.785375] ? __lock_acquire+0xe9d/0x16d0
[ 30.785707] ? cpuset_update_active_cpus+0x15a/0xca0
[ 30.786074] ? cpuset_update_active_cpus+0x782/0xca0
[ 30.786443] cpuset_update_active_cpus+0x782/0xca0
[ 30.786816] sched_cpu_deactivate+0x1ad/0x1d0
[ 30.787148] ? __pfx_sched_cpu_deactivate+0x10/0x10
[ 30.787509] cpuhp_invoke_callback+0x16b/0x6b0
[ 30.787859] ? cpuhp_thread_fun+0x56/0x240
[ 30.788175] cpuhp_thread_fun+0x1ba/0x240
[ 30.788485] smpboot_thread_fn+0xd8/0x1d0
[ 30.788823] ? __pfx_smpboot_thread_fn+0x10/0x10
[ 30.789229] kthread+0xce/0x100
[ 30.789526] ? __pfx_kthread+0x10/0x10
[ 30.789876] ret_from_fork+0x2f/0x50
[ 30.790200] ? __pfx_kthread+0x10/0x10
[ 30.792341] ret_from_fork_asm+0x1a/0x30
[ 30.792716] </TASK>
> Michal
^ permalink raw reply
* Re: kernel/sched/core.c:961:15: error: incompatible pointer to integer conversion passing 'typeof
From: Nathan Chancellor @ 2024-04-03 16:00 UTC (permalink / raw)
To: Vincent Guittot
Cc: Naresh Kamboju, open list, Linux Regressions, lkft-triage,
clang-built-linux, Linux PM, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Nick Desaulniers, linux-riscv, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Paul E. McKenney
In-Reply-To: <CAKfTPtC9YgbZgGNK82MhhzzsD3P6j64+w6oieJMDKQNOmrC4FQ@mail.gmail.com>
Hi all,
+ Paul McKenney
On Wed, Apr 03, 2024 at 03:26:05PM +0200, Vincent Guittot wrote:
> Hi Naresh,
>
> Adding riscv people
>
> On Wed, 3 Apr 2024 at 09:38, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > The riscv clang-17 defconfig build failed due to following warnings / errors
> > on the Linux next-20240402.
>
> Could you confirm that there is no problem with other arch and/or
> other toolchain ?
This is not a clang specific issue, it happens with GCC too:
$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- mrproper defconfig kernel/sched/core.o
kernel/sched/core.c: In function '__wake_q_add':
arch/riscv/include/asm/cmpxchg.h:175:62: warning: passing argument 2 of 'cmpxchg_emu_u8' makes integer from pointer without a cast [-Wint-conversion]
175 | __ret = cmpxchg_emu_u8((volatile u8 *)__ptr, __old, __new); \
| ^~~~~
| |
| struct wake_q_node *
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
In file included from arch/riscv/include/asm/cmpxchg.h:12,
from arch/riscv/include/asm/atomic.h:19,
from include/linux/atomic.h:7,
from include/linux/cpumask.h:14,
from include/linux/smp.h:13,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:63,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6:
include/linux/cmpxchg-emu.h:13:52: note: expected 'uintptr_t' {aka 'long unsigned int'} but argument is of type 'struct wake_q_node *'
13 | uintptr_t cmpxchg_emu_u8(volatile u8 *p, uintptr_t old, uintptr_t new);
| ~~~~~~~~~~^~~
arch/riscv/include/asm/cmpxchg.h:175:69: warning: passing argument 3 of 'cmpxchg_emu_u8' makes integer from pointer without a cast [-Wint-conversion]
175 | __ret = cmpxchg_emu_u8((volatile u8 *)__ptr, __old, __new); \
| ^~~~~
| |
| struct wake_q_node *
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
include/linux/cmpxchg-emu.h:13:67: note: expected 'uintptr_t' {aka 'long unsigned int'} but argument is of type 'struct wake_q_node *'
13 | uintptr_t cmpxchg_emu_u8(volatile u8 *p, uintptr_t old, uintptr_t new);
| ~~~~~~~~~~^~~
arch/riscv/include/asm/cmpxchg.h:175:23: warning: assignment to 'struct wake_q_node *' from 'uintptr_t' {aka 'long unsigned int'} makes pointer from integer without a cast [-Wint-conversion]
175 | __ret = cmpxchg_emu_u8((volatile u8 *)__ptr, __old, __new); \
| ^
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:179:64: warning: passing argument 2 of 'cmpxchg_emu_u16' makes integer from pointer without a cast [-Wint-conversion]
179 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ^~~~~
| |
| struct wake_q_node *
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
include/linux/cmpxchg-emu.h:14:54: note: expected 'uintptr_t' {aka 'long unsigned int'} but argument is of type 'struct wake_q_node *'
14 | uintptr_t cmpxchg_emu_u16(volatile u16 *p, uintptr_t old, uintptr_t new);
| ~~~~~~~~~~^~~
arch/riscv/include/asm/cmpxchg.h:179:71: warning: passing argument 3 of 'cmpxchg_emu_u16' makes integer from pointer without a cast [-Wint-conversion]
179 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ^~~~~
| |
| struct wake_q_node *
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
include/linux/cmpxchg-emu.h:14:69: note: expected 'uintptr_t' {aka 'long unsigned int'} but argument is of type 'struct wake_q_node *'
14 | uintptr_t cmpxchg_emu_u16(volatile u16 *p, uintptr_t old, uintptr_t new);
| ~~~~~~~~~~^~~
arch/riscv/include/asm/cmpxchg.h:179:23: warning: assignment to 'struct wake_q_node *' from 'uintptr_t' {aka 'long unsigned int'} makes pointer from integer without a cast [-Wint-conversion]
179 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ^
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:179:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
179 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:180:9: note: here
180 | case 4: \
| ^~~~
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4810:9: note: in expansion of macro 'raw_cmpxchg_relaxed'
4810 | raw_cmpxchg_relaxed(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:961:22: note: in expansion of macro 'cmpxchg_relaxed'
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~
kernel/sched/sched.h: In function 'mm_cid_put_lazy':
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/sched.h:3292:14: note: in expansion of macro 'try_cmpxchg'
3292 | !try_cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, &cid, MM_CID_UNSET))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/sched.h:3292:14: note: in expansion of macro 'try_cmpxchg'
3292 | !try_cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, &cid, MM_CID_UNSET))
| ^~~~~~~~~~~
kernel/sched/sched.h: In function 'mm_cid_get':
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/sched.h:3429:21: note: in expansion of macro 'try_cmpxchg'
3429 | if (try_cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, &cid, MM_CID_UNSET))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/sched.h:3429:21: note: in expansion of macro 'try_cmpxchg'
3429 | if (try_cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, &cid, MM_CID_UNSET))
| ^~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h: In function 'raw_atomic_cmpxchg_relaxed':
arch/riscv/include/asm/cmpxchg.h:179:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
179 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:2108:16: note: in expansion of macro 'raw_cmpxchg_relaxed'
2108 | return raw_cmpxchg_relaxed(&v->counter, old, new);
| ^~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:180:9: note: here
180 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:212:30: note: in expansion of macro '__cmpxchg_relaxed'
212 | (__typeof__(*(ptr))) __cmpxchg_relaxed((ptr), \
| ^~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:89:29: note: in expansion of macro 'arch_cmpxchg_relaxed'
89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
| ^~~~~~~~~~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:2108:16: note: in expansion of macro 'raw_cmpxchg_relaxed'
2108 | return raw_cmpxchg_relaxed(&v->counter, old, new);
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/core.c: In function '__sched_mm_cid_migrate_from_try_steal_cid':
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11724:14: note: in expansion of macro 'try_cmpxchg'
11724 | if (!try_cmpxchg(&src_pcpu_cid->cid, &src_cid, lazy_cid))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11724:14: note: in expansion of macro 'try_cmpxchg'
11724 | if (!try_cmpxchg(&src_pcpu_cid->cid, &src_cid, lazy_cid))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11760:14: note: in expansion of macro 'try_cmpxchg'
11760 | if (!try_cmpxchg(&src_pcpu_cid->cid, &lazy_cid, MM_CID_UNSET))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11760:14: note: in expansion of macro 'try_cmpxchg'
11760 | if (!try_cmpxchg(&src_pcpu_cid->cid, &lazy_cid, MM_CID_UNSET))
| ^~~~~~~~~~~
kernel/sched/core.c: In function 'task_mm_cid_work':
arch/riscv/include/asm/cmpxchg.h:333:25: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4788:9: note: in expansion of macro 'raw_cmpxchg'
4788 | raw_cmpxchg(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~
kernel/sched/core.c:11945:23: note: in expansion of macro 'cmpxchg'
11945 | res = cmpxchg(&mm->mm_cid_next_scan, old_scan, next_scan);
| ^~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4788:9: note: in expansion of macro 'raw_cmpxchg'
4788 | raw_cmpxchg(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~
kernel/sched/core.c:11945:23: note: in expansion of macro 'cmpxchg'
11945 | res = cmpxchg(&mm->mm_cid_next_scan, old_scan, next_scan);
| ^~~~~~~
arch/riscv/include/asm/cmpxchg.h:333:25: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11953:14: note: in expansion of macro 'try_cmpxchg'
11953 | if (!try_cmpxchg(&mm->mm_cid_next_scan, &old_scan, next_scan))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11953:14: note: in expansion of macro 'try_cmpxchg'
11953 | if (!try_cmpxchg(&mm->mm_cid_next_scan, &old_scan, next_scan))
| ^~~~~~~~~~~
kernel/sched/core.c: In function 'sched_mm_cid_remote_clear':
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11841:14: note: in expansion of macro 'try_cmpxchg'
11841 | if (!try_cmpxchg(&pcpu_cid->cid, &cid, lazy_cid))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11841:14: note: in expansion of macro 'try_cmpxchg'
11841 | if (!try_cmpxchg(&pcpu_cid->cid, &cid, lazy_cid))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11874:21: note: in expansion of macro 'try_cmpxchg'
11874 | if (try_cmpxchg(&pcpu_cid->cid, &lazy_cid, MM_CID_UNSET))
| ^~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:192:16: note: in expansion of macro 'raw_cmpxchg'
192 | ___r = raw_cmpxchg((_ptr), ___o, (_new)); \
| ^~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4880:9: note: in expansion of macro 'raw_try_cmpxchg'
4880 | raw_try_cmpxchg(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~~~~~~~~~~~~~
kernel/sched/core.c:11874:21: note: in expansion of macro 'try_cmpxchg'
11874 | if (try_cmpxchg(&pcpu_cid->cid, &lazy_cid, MM_CID_UNSET))
| ^~~~~~~~~~~
kernel/sched/sched.h: In function 'mm_cid_pcpu_unset':
arch/riscv/include/asm/cmpxchg.h:333:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
333 | __ret = cmpxchg_emu_u16((volatile u16 *)__ptr, __old, __new); \
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4788:9: note: in expansion of macro 'raw_cmpxchg'
4788 | raw_cmpxchg(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~
kernel/sched/sched.h:3310:23: note: in expansion of macro 'cmpxchg'
3310 | res = cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, cid, MM_CID_UNSET);
| ^~~~~~~
arch/riscv/include/asm/cmpxchg.h:334:9: note: here
334 | case 4: \
| ^~~~
arch/riscv/include/asm/cmpxchg.h:368:30: note: in expansion of macro '__cmpxchg'
368 | (__typeof__(*(ptr))) __cmpxchg((ptr), \
| ^~~~~~~~~
include/linux/atomic/atomic-arch-fallback.h:55:21: note: in expansion of macro 'arch_cmpxchg'
55 | #define raw_cmpxchg arch_cmpxchg
| ^~~~~~~~~~~~
include/linux/atomic/atomic-instrumented.h:4788:9: note: in expansion of macro 'raw_cmpxchg'
4788 | raw_cmpxchg(__ai_ptr, __VA_ARGS__); \
| ^~~~~~~~~~~
kernel/sched/sched.h:3310:23: note: in expansion of macro 'cmpxchg'
3310 | res = cmpxchg(&this_cpu_ptr(pcpu_cid)->cid, cid, MM_CID_UNSET);
| ^~~~~~~
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> >
> > riscv:
> > build:
> > * clang-17-lkftconfig - Failed
> > * rv32-clang-17-defconfig - Failed
> > * clang-17-tinyconfig - Failed
> > * rv32-clang-17-tinyconfig - Failed
> > * clang-17-defconfig - Failed
> > * clang-17-allnoconfig - Failed
> > * rv32-clang-17-allnoconfig - Failed
> >
> > Build log:
> > -------
> > kernel/sched/core.c:961:15: error: incompatible pointer to integer
> > conversion passing 'typeof (*((__ai_ptr)))' (aka 'struct wake_q_node
> > *') to parameter of type 'uintptr_t' (aka 'unsigned long')
> > [-Wint-conversion]
> > 961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> There is no recent change on this code. Could it be a change in
> cmpxchg_relaxed ?
Yes, it is caused by commit df35ee400e06 ("riscv: Emulate one-byte and
two-byte cmpxchg") in -next. There is another thread on this problem
with a suggested diff that resolves it for me (there are other issues
with that change as well such as break not being in the correct
location):
https://lore.kernel.org/Zgz98szFLLjTIZSO@yujie-X299/
Cheers,
Nathan
^ permalink raw reply
* [PATCH v5 4/4] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
From: Lukasz Luba @ 2024-04-03 15:49 UTC (permalink / raw)
To: linux-kernel, linux-pm, rafael
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sboyd, nm,
linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <20240403154907.1420245-1-lukasz.luba@arm.com>
When the voltage for OPPs is adjusted there is a need to also update
Energy Model framework. The EM data contains power values which depend
on voltage values. The EM structure is used for thermal (IPA governor)
and in scheduler task placement (EAS) so it should reflect the real HW
model as best as possible to operate properly.
Based on data on Exynos5422 ASV tables the maximum power difference might
be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery)
showed power difference for some OPPs ~20%. Therefore, it's worth to
update the EM.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
drivers/soc/samsung/exynos-asv.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
index d60af8acc3916..97006cc3b9461 100644
--- a/drivers/soc/samsung/exynos-asv.c
+++ b/drivers/soc/samsung/exynos-asv.c
@@ -11,6 +11,7 @@
#include <linux/cpu.h>
#include <linux/device.h>
+#include <linux/energy_model.h>
#include <linux/errno.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
@@ -97,9 +98,16 @@ static int exynos_asv_update_opps(struct exynos_asv *asv)
last_opp_table = opp_table;
ret = exynos_asv_update_cpu_opps(asv, cpu);
- if (ret < 0)
+ if (!ret) {
+ /*
+ * Update EM power values since OPP
+ * voltage values may have changed.
+ */
+ em_dev_update_chip_binning(cpu);
+ } else {
dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
cpuid);
+ }
}
dev_pm_opp_put_opp_table(opp_table);
--
2.25.1
^ permalink raw reply related
* [PATCH v5 3/4] PM: EM: Add em_dev_update_chip_binning()
From: Lukasz Luba @ 2024-04-03 15:49 UTC (permalink / raw)
To: linux-kernel, linux-pm, rafael
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sboyd, nm,
linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <20240403154907.1420245-1-lukasz.luba@arm.com>
Add a function which allows to modify easily the EM after the new voltage
information is available. The device drivers for the chip can adjust
the voltage values after setup. The voltage for the same frequency in OPP
can be different due to chip binning. The voltage impacts the power usage
and the EM power values can be updated to reflect that.
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
include/linux/energy_model.h | 5 ++++
kernel/power/energy_model.c | 48 ++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 770755df852f1..d30d67c2f07cf 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -172,6 +172,7 @@ struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd);
void em_table_free(struct em_perf_table __rcu *table);
int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
int nr_states);
+int em_dev_update_chip_binning(struct device *dev);
/**
* em_pd_get_efficient_state() - Get an efficient performance state from the EM
@@ -387,6 +388,10 @@ int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
{
return -EINVAL;
}
+static inline int em_dev_update_chip_binning(struct device *dev)
+{
+ return -EINVAL;
+}
#endif
#endif
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 6960dd7393b2d..927cc55ba0b3d 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -808,3 +808,51 @@ static void em_update_workfn(struct work_struct *work)
{
em_check_capacity_update();
}
+
+/**
+ * em_dev_update_chip_binning() - Update Energy Model after the new voltage
+ * information is present in the OPPs.
+ * @dev : Device for which the Energy Model has to be updated.
+ *
+ * This function allows to update easily the EM with new values available in
+ * the OPP framework and DT. It can be used after the chip has been properly
+ * verified by device drivers and the voltages adjusted for the 'chip binning'.
+ */
+int em_dev_update_chip_binning(struct device *dev)
+{
+ struct em_perf_table __rcu *em_table;
+ struct em_perf_domain *pd;
+ int i, ret;
+
+ if (IS_ERR_OR_NULL(dev))
+ return -EINVAL;
+
+ pd = em_pd_get(dev);
+ if (!pd) {
+ dev_warn(dev, "Couldn't find Energy Model\n");
+ return -EINVAL;
+ }
+
+ em_table = em_table_dup(pd);
+ if (!em_table) {
+ dev_warn(dev, "EM: allocation failed\n");
+ return -ENOMEM;
+ }
+
+ /* Update power values which might change due to new voltage in OPPs */
+ for (i = 0; i < pd->nr_perf_states; i++) {
+ unsigned long freq = em_table->state[i].frequency;
+ unsigned long power;
+
+ ret = dev_pm_opp_calc_power(dev, &power, &freq);
+ if (ret) {
+ em_table_free(em_table);
+ return ret;
+ }
+
+ em_table->state[i].power = power;
+ }
+
+ return em_recalc_and_update(dev, pd, em_table);
+}
+EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
--
2.25.1
^ permalink raw reply related
* [PATCH v5 2/4] PM: EM: Refactor em_adjust_new_capacity()
From: Lukasz Luba @ 2024-04-03 15:49 UTC (permalink / raw)
To: linux-kernel, linux-pm, rafael
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sboyd, nm,
linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <20240403154907.1420245-1-lukasz.luba@arm.com>
Extract em_table_dup() and em_recalc_and_update() from
em_adjust_new_capacity(). Both functions will be later reused by the
'update EM due to chip binning' functionality.
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
kernel/power/energy_model.c | 58 +++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 9e1c9aa399ea9..6960dd7393b2d 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -674,23 +674,15 @@ void em_dev_unregister_perf_domain(struct device *dev)
}
EXPORT_SYMBOL_GPL(em_dev_unregister_perf_domain);
-/*
- * Adjustment of CPU performance values after boot, when all CPUs capacites
- * are correctly calculated.
- */
-static void em_adjust_new_capacity(struct device *dev,
- struct em_perf_domain *pd,
- u64 max_cap)
+static struct em_perf_table __rcu *em_table_dup(struct em_perf_domain *pd)
{
struct em_perf_table __rcu *em_table;
struct em_perf_state *ps, *new_ps;
- int ret, ps_size;
+ int ps_size;
em_table = em_table_alloc(pd);
- if (!em_table) {
- dev_warn(dev, "EM: allocation failed\n");
- return;
- }
+ if (!em_table)
+ return NULL;
new_ps = em_table->state;
@@ -702,24 +694,52 @@ static void em_adjust_new_capacity(struct device *dev,
rcu_read_unlock();
- em_init_performance(dev, pd, new_ps, pd->nr_perf_states);
- ret = em_compute_costs(dev, new_ps, NULL, pd->nr_perf_states,
+ return em_table;
+}
+
+static int em_recalc_and_update(struct device *dev, struct em_perf_domain *pd,
+ struct em_perf_table __rcu *em_table)
+{
+ int ret;
+
+ ret = em_compute_costs(dev, em_table->state, NULL, pd->nr_perf_states,
pd->flags);
- if (ret) {
- dev_warn(dev, "EM: compute costs failed\n");
- return;
- }
+ if (ret)
+ goto free_em_table;
ret = em_dev_update_perf_domain(dev, em_table);
if (ret)
- dev_warn(dev, "EM: update failed %d\n", ret);
+ goto free_em_table;
/*
* This is one-time-update, so give up the ownership in this updater.
* The EM framework has incremented the usage counter and from now
* will keep the reference (then free the memory when needed).
*/
+free_em_table:
em_table_free(em_table);
+ return ret;
+}
+
+/*
+ * Adjustment of CPU performance values after boot, when all CPUs capacites
+ * are correctly calculated.
+ */
+static void em_adjust_new_capacity(struct device *dev,
+ struct em_perf_domain *pd,
+ u64 max_cap)
+{
+ struct em_perf_table __rcu *em_table;
+
+ em_table = em_table_dup(pd);
+ if (!em_table) {
+ dev_warn(dev, "EM: allocation failed\n");
+ return;
+ }
+
+ em_init_performance(dev, pd, em_table->state, pd->nr_perf_states);
+
+ em_recalc_and_update(dev, pd, em_table);
}
static void em_check_capacity_update(void)
--
2.25.1
^ permalink raw reply related
* [PATCH v5 1/4] OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
From: Lukasz Luba @ 2024-04-03 15:49 UTC (permalink / raw)
To: linux-kernel, linux-pm, rafael
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sboyd, nm,
linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <20240403154907.1420245-1-lukasz.luba@arm.com>
There are device drivers which can modify voltage values for OPPs. It
could be due to the chip binning and those drivers have specific chip
knowledge about it. This adjustment can happen after Energy Model is
registered, thus EM can have stale data about power.
Export dev_opp_pm_calc_power() which can be used by Energy Model to
calculate new power with the new voltage for OPPs.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
drivers/opp/of.c | 17 ++++++++++++-----
include/linux/pm_opp.h | 8 ++++++++
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index f9f0b22bccbb4..282eb5966fd03 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -1494,20 +1494,26 @@ _get_dt_power(struct device *dev, unsigned long *uW, unsigned long *kHz)
return 0;
}
-/*
- * Callback function provided to the Energy Model framework upon registration.
+/**
+ * dev_pm_opp_calc_power() - Calculate power value for device with EM
+ * @dev : Device for which an Energy Model has to be registered
+ * @uW : New power value that is calculated
+ * @kHz : Frequency for which the new power is calculated
+ *
* This computes the power estimated by @dev at @kHz if it is the frequency
* of an existing OPP, or at the frequency of the first OPP above @kHz otherwise
* (see dev_pm_opp_find_freq_ceil()). This function updates @kHz to the ceiled
* frequency and @uW to the associated power. The power is estimated as
* P = C * V^2 * f with C being the device's capacitance and V and f
* respectively the voltage and frequency of the OPP.
+ * It is also used as a callback function provided to the Energy Model
+ * framework upon registration.
*
* Returns -EINVAL if the power calculation failed because of missing
* parameters, 0 otherwise.
*/
-static int __maybe_unused _get_power(struct device *dev, unsigned long *uW,
- unsigned long *kHz)
+int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW,
+ unsigned long *kHz)
{
struct dev_pm_opp *opp;
struct device_node *np;
@@ -1544,6 +1550,7 @@ static int __maybe_unused _get_power(struct device *dev, unsigned long *uW,
return 0;
}
+EXPORT_SYMBOL_GPL(dev_pm_opp_calc_power);
static bool _of_has_opp_microwatt_property(struct device *dev)
{
@@ -1619,7 +1626,7 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus)
goto failed;
}
- EM_SET_ACTIVE_POWER_CB(em_cb, _get_power);
+ EM_SET_ACTIVE_POWER_CB(em_cb, dev_pm_opp_calc_power);
register_em:
ret = em_dev_register_perf_domain(dev, nr_opp, &em_cb, cpus, true);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 065a47382302c..dd7c8441af424 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -476,6 +476,8 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
int of_get_required_opp_performance_state(struct device_node *np, int index);
int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table);
int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus);
+int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW,
+ unsigned long *kHz);
static inline void dev_pm_opp_of_unregister_em(struct device *dev)
{
em_dev_unregister_perf_domain(dev);
@@ -539,6 +541,12 @@ static inline void dev_pm_opp_of_unregister_em(struct device *dev)
{
}
+static inline int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW,
+ unsigned long *kHz)
+{
+ return -EOPNOTSUPP;
+}
+
static inline int of_get_required_opp_performance_state(struct device_node *np, int index)
{
return -EOPNOTSUPP;
--
2.25.1
^ permalink raw reply related
* [PATCH v5 0/4] Update Energy Model after chip binning adjusted voltages
From: Lukasz Luba @ 2024-04-03 15:49 UTC (permalink / raw)
To: linux-kernel, linux-pm, rafael
Cc: lukasz.luba, dietmar.eggemann, linux-arm-kernel, sboyd, nm,
linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
Hi all,
This is a follow-up patch aiming to add EM modification due to chip binning.
The first RFC and the discussion can be found here [1].
It uses Exynos chip driver code as a 1st user. The EM framework has been
extended to handle this use case easily, when the voltage has been changed
after setup. On my Odroid-xu4 in some OPPs I can observe ~20% power difference.
According to that data in driver tables it could be up to ~29%.
This chip binning is applicable to a lot of SoCs, so the EM framework should
make it easy to update. It uses the existing OPP and DT information to
re-calculate the new power values.
It has dependency on Exynos SoC driver tree.
Changes:
v5:
- adjusted aligning of the function arguments in patch 1/4 (Dietmar)
- adjusted the in-code comment patch 4/4 (Dietmar)
- added Reviewed-by to all patches (Dietmar)
v4:
- added asterisk in the comment section (test robot)
- change the patch 2/4 header name and use 'Refactor'
v3:
- updated header description patch 2/4 (Dietmar)
- removed 2 sentences from comment and adjusted in patch 3/4 (Dietmar)
- patch 4/4 re-phrased code comment (Dietmar)
- collected tags (Krzysztof, Viresh)
v2:
- removed 'ret' from error message which wasn't initialized (Christian)
v1:
- exported the OPP calculation function from the OPP/OF so it can be
used from EM fwk (Viresh)
- refactored EM updating function to re-use common code
- added new EM function which can be used by chip device drivers which
modify the voltage in OPPs
RFC is at [1]
Regards,
Lukasz Luba
[1] https://lore.kernel.org/lkml/20231220110339.1065505-1-lukasz.luba@arm.com/
Lukasz Luba (4):
OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
PM: EM: Refactor em_adjust_new_capacity()
PM: EM: Add em_dev_update_chip_binning()
soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
drivers/opp/of.c | 17 +++--
drivers/soc/samsung/exynos-asv.c | 10 ++-
include/linux/energy_model.h | 5 ++
include/linux/pm_opp.h | 8 +++
kernel/power/energy_model.c | 106 +++++++++++++++++++++++++------
5 files changed, 121 insertions(+), 25 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v6 2/6] interconnect: icc-clk: Remove tristate from INTERCONNECT_CLK
From: kernel test robot @ 2024-04-03 15:42 UTC (permalink / raw)
To: Varadarajan Narayanan, andersson, konrad.dybcio, mturquette,
sboyd, robh, krzysztof.kozlowski+dt, conor+dt, djakov,
dmitry.baryshkov, quic_anusha, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm
Cc: oe-kbuild-all, kernel test robot
In-Reply-To: <20240402103406.3638821-3-quic_varada@quicinc.com>
Hi Varadarajan,
kernel test robot noticed the following build errors:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on robh/for-next linus/master v6.9-rc2 next-20240403]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Varadarajan-Narayanan/dt-bindings-interconnect-Add-Qualcomm-IPQ9574-support/20240402-223729
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
patch link: https://lore.kernel.org/r/20240402103406.3638821-3-quic_varada%40quicinc.com
patch subject: [PATCH v6 2/6] interconnect: icc-clk: Remove tristate from INTERCONNECT_CLK
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20240403/202404032328.7zrla6d9-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240403/202404032328.7zrla6d9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404032328.7zrla6d9-lkp@intel.com/
All errors (new ones prefixed by >>):
aarch64-linux-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-ld: drivers/clk/qcom/clk-cbf-8996.o: in function `qcom_msm8996_cbf_icc_remove':
>> drivers/clk/qcom/clk-cbf-8996.c:257:(.text+0x10): undefined reference to `icc_clk_unregister'
aarch64-linux-ld: drivers/clk/qcom/clk-cbf-8996.o: in function `qcom_msm8996_cbf_icc_register':
>> drivers/clk/qcom/clk-cbf-8996.c:244:(.text+0x360): undefined reference to `icc_clk_register'
vim +257 drivers/clk/qcom/clk-cbf-8996.c
12dc71953e664f Dmitry Baryshkov 2023-05-12 234
12dc71953e664f Dmitry Baryshkov 2023-05-12 235 static int qcom_msm8996_cbf_icc_register(struct platform_device *pdev, struct clk_hw *cbf_hw)
12dc71953e664f Dmitry Baryshkov 2023-05-12 236 {
12dc71953e664f Dmitry Baryshkov 2023-05-12 237 struct device *dev = &pdev->dev;
12dc71953e664f Dmitry Baryshkov 2023-05-12 238 struct clk *clk = devm_clk_hw_get_clk(dev, cbf_hw, "cbf");
12dc71953e664f Dmitry Baryshkov 2023-05-12 239 const struct icc_clk_data data[] = {
12dc71953e664f Dmitry Baryshkov 2023-05-12 240 { .clk = clk, .name = "cbf", },
12dc71953e664f Dmitry Baryshkov 2023-05-12 241 };
12dc71953e664f Dmitry Baryshkov 2023-05-12 242 struct icc_provider *provider;
12dc71953e664f Dmitry Baryshkov 2023-05-12 243
12dc71953e664f Dmitry Baryshkov 2023-05-12 @244 provider = icc_clk_register(dev, CBF_MASTER_NODE, ARRAY_SIZE(data), data);
12dc71953e664f Dmitry Baryshkov 2023-05-12 245 if (IS_ERR(provider))
12dc71953e664f Dmitry Baryshkov 2023-05-12 246 return PTR_ERR(provider);
12dc71953e664f Dmitry Baryshkov 2023-05-12 247
12dc71953e664f Dmitry Baryshkov 2023-05-12 248 platform_set_drvdata(pdev, provider);
12dc71953e664f Dmitry Baryshkov 2023-05-12 249
12dc71953e664f Dmitry Baryshkov 2023-05-12 250 return 0;
12dc71953e664f Dmitry Baryshkov 2023-05-12 251 }
12dc71953e664f Dmitry Baryshkov 2023-05-12 252
abaf59c470a7c9 Uwe Kleine-König 2023-09-11 253 static void qcom_msm8996_cbf_icc_remove(struct platform_device *pdev)
12dc71953e664f Dmitry Baryshkov 2023-05-12 254 {
12dc71953e664f Dmitry Baryshkov 2023-05-12 255 struct icc_provider *provider = platform_get_drvdata(pdev);
12dc71953e664f Dmitry Baryshkov 2023-05-12 256
12dc71953e664f Dmitry Baryshkov 2023-05-12 @257 icc_clk_unregister(provider);
12dc71953e664f Dmitry Baryshkov 2023-05-12 258 }
12dc71953e664f Dmitry Baryshkov 2023-05-12 259 #define qcom_msm8996_cbf_icc_sync_state icc_sync_state
12dc71953e664f Dmitry Baryshkov 2023-05-12 260 #else
12dc71953e664f Dmitry Baryshkov 2023-05-12 261 static int qcom_msm8996_cbf_icc_register(struct platform_device *pdev, struct clk_hw *cbf_hw)
12dc71953e664f Dmitry Baryshkov 2023-05-12 262 {
12dc71953e664f Dmitry Baryshkov 2023-05-12 263 dev_warn(&pdev->dev, "CONFIG_INTERCONNECT is disabled, CBF clock is fixed\n");
12dc71953e664f Dmitry Baryshkov 2023-05-12 264
12dc71953e664f Dmitry Baryshkov 2023-05-12 265 return 0;
12dc71953e664f Dmitry Baryshkov 2023-05-12 266 }
abaf59c470a7c9 Uwe Kleine-König 2023-09-11 267 #define qcom_msm8996_cbf_icc_remove(pdev) { }
12dc71953e664f Dmitry Baryshkov 2023-05-12 268 #define qcom_msm8996_cbf_icc_sync_state NULL
12dc71953e664f Dmitry Baryshkov 2023-05-12 269 #endif
12dc71953e664f Dmitry Baryshkov 2023-05-12 270
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Waiman Long @ 2024-04-03 15:10 UTC (permalink / raw)
To: Michal Koutný
Cc: Valentin Schneider, Tejun Heo, Zefan Li, Johannes Weiner,
Thomas Gleixner, Peter Zijlstra, Rafael J. Wysocki, Len Brown,
Pavel Machek, Shuah Khan, linux-kernel, cgroups, linux-pm,
linux-kselftest, Frederic Weisbecker, Paul E. McKenney,
Ingo Molnar, Anna-Maria Behnsen, Alex Shi, Vincent Guittot,
Barry Song
In-Reply-To: <tm5kvzgn2g5yv63zoyqvd2bdrgl7l3ytffu4cq4ybxyq5irp76@hpmq3zfbtmlp>
On 4/3/24 10:56, Michal Koutný wrote:
> On Wed, Apr 03, 2024 at 10:47:33AM -0400, Waiman Long <longman@redhat.com> wrote:
>> should be rare these days as it will only apply in the case of cgroup
>> v1 under certain condtion,
> Could the migration be simply omitted it those special cases?
>
> (Tasks remain in cpusets with empty cpusets -- that already happens in
> with the current patch before workqueue is dispatched.)
The tasks should not be runnable if there is no CPUs left in their v1
cpuset. Migrating them to a parent with runnable CPUs is the current way
which I don't want to break. Alternatively, we could force it to fall
back to cgroup v2 behavior using the CPUs in their parent cpuset.
Cheers,
Longman
>
> Michal
^ permalink raw reply
* Re: [PATCH v2 1/3] thermal: gov_power_allocator: Allow binding without cooling devices
From: Lukasz Luba @ 2024-04-03 15:03 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, linux-pm, Nikita Travkin, Daniel Lezcano,
linux-kernel, Zhang Rui
In-Reply-To: <CAJZ5v0gU+a60EvKKnGsgS32YoaQE8RffwPSrbbV2APSFKgn+UA@mail.gmail.com>
On 4/3/24 15:41, Rafael J. Wysocki wrote:
> On Wed, Apr 3, 2024 at 2:44 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>>
>>
>> On 4/3/24 12:31, Nikita Travkin via B4 Relay wrote:
>>> From: Nikita Travkin <nikita@trvn.ru>
>>>
>>> IPA was recently refactored to split out memory allocation into a
>>> separate funciton. That funciton was made to return -EINVAL if there is
>>> zero power_actors and thus no memory to allocate. This causes IPA to
>>> fail probing when the thermal zone has no attached cooling devices.
>>>
>>> Since cooling devices can attach after the thermal zone is created and
>>> the governer is attached to it, failing probe due to the lack of cooling
>>> devices is incorrect.
>>>
>>> Change the allocate_actors_buffer() to return success when there is no
>>> cooling devices present.
>>>
>>> Fixes: 912e97c67cc3 ("thermal: gov_power_allocator: Move memory allocation out of throttle()")
>>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>>> ---
>>> drivers/thermal/gov_power_allocator.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c
>>> index 1b17dc4c219c..ec637071ef1f 100644
>>> --- a/drivers/thermal/gov_power_allocator.c
>>> +++ b/drivers/thermal/gov_power_allocator.c
>>> @@ -606,7 +606,7 @@ static int allocate_actors_buffer(struct power_allocator_params *params,
>>>
>>> /* There might be no cooling devices yet. */
>>> if (!num_actors) {
>>> - ret = -EINVAL;
>>> + ret = 0;
>>> goto clean_state;
>>> }
>>>
>>>
>>
>> LGTM
>>
>> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
>
> Applied as 6.9-rc material along with the [2/3], thanks!
>
Thank you Rafael!
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Krzysztof Kozlowski @ 2024-04-03 14:59 UTC (permalink / raw)
To: Varadarajan Narayanan, andersson, konrad.dybcio, mturquette,
sboyd, robh, krzk+dt, conor+dt, djakov, dmitry.baryshkov,
quic_anusha, linux-arm-msm, linux-clk, devicetree, linux-kernel,
linux-pm
In-Reply-To: <20240403104220.1092431-2-quic_varada@quicinc.com>
On 03/04/2024 12:42, Varadarajan Narayanan wrote:
> Add interconnect-cells to clock provider so that it can be
> used as icc provider.
>
> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
> interfaces. This will be used by the gcc-ipq9574 driver
> that will for providing interconnect services using the
> icc-clk framework.
>
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> ---
> v7:
> Fix macro names to be consistent with other bindings
> v6:
> Removed Reviewed-by: Krzysztof Kozlowski
> Redefine the bindings such that driver and DT can share them
>
> v3:
> Squash Documentation/ and include/ changes into same patch
>
> qcom,ipq9574.h
> Move 'first id' to clock driver
>
> ---
> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
> 2 files changed, 90 insertions(+)
> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> index 944a0ea79cd6..824781cbdf34 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> @@ -33,6 +33,9 @@ properties:
> - description: PCIE30 PHY3 pipe clock source
> - description: USB3 PHY pipe clock source
>
> + '#interconnect-cells':
> + const: 1
> +
> required:
> - compatible
> - clocks
> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
> new file mode 100644
> index 000000000000..0b076b0cf880
> --- /dev/null
> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
> @@ -0,0 +1,87 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +#ifndef INTERCONNECT_QCOM_IPQ9574_H
> +#define INTERCONNECT_QCOM_IPQ9574_H
> +
> +#define ICC_ANOC_PCIE0 0
> +#define ICC_SNOC_PCIE0 1
> +#define ICC_ANOC_PCIE1 2
> +#define ICC_SNOC_PCIE1 3
> +#define ICC_ANOC_PCIE2 4
> +#define ICC_SNOC_PCIE2 5
> +#define ICC_ANOC_PCIE3 6
> +#define ICC_SNOC_PCIE3 7
> +#define ICC_SNOC_USB 8
> +#define ICC_ANOC_USB_AXI 9
> +#define ICC_NSSNOC_NSSCC 10
> +#define ICC_NSSNOC_SNOC_0 11
> +#define ICC_NSSNOC_SNOC_1 12
> +#define ICC_NSSNOC_PCNOC_1 13
> +#define ICC_NSSNOC_QOSGEN_REF 14
> +#define ICC_NSSNOC_TIMEOUT_REF 15
> +#define ICC_NSSNOC_XO_DCD 16
> +#define ICC_NSSNOC_ATB 17
> +#define ICC_MEM_NOC_NSSNOC 18
> +#define ICC_NSSNOC_MEMNOC 19
> +#define ICC_NSSNOC_MEM_NOC_1 20
> +
> +#define ICC_NSSNOC_PPE 0
> +#define ICC_NSSNOC_PPE_CFG 1
> +#define ICC_NSSNOC_NSS_CSR 2
> +#define ICC_NSSNOC_IMEM_QSB 3
> +#define ICC_NSSNOC_IMEM_AHB 4
> +
> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
Which existing Qualcomm platform has such code?
This is the third time I am asking for consistent headers. Open
existing, recently added headers and look how it is done there. Why?
Because I am against such calculations and see no reason for them.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Michal Koutný @ 2024-04-03 14:56 UTC (permalink / raw)
To: Waiman Long
Cc: Valentin Schneider, Tejun Heo, Zefan Li, Johannes Weiner,
Thomas Gleixner, Peter Zijlstra, Rafael J. Wysocki, Len Brown,
Pavel Machek, Shuah Khan, linux-kernel, cgroups, linux-pm,
linux-kselftest, Frederic Weisbecker, Paul E. McKenney,
Ingo Molnar, Anna-Maria Behnsen, Alex Shi, Vincent Guittot,
Barry Song
In-Reply-To: <620d1b70-cfbc-4b76-ad04-b3be559afd56@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Wed, Apr 03, 2024 at 10:47:33AM -0400, Waiman Long <longman@redhat.com> wrote:
> should be rare these days as it will only apply in the case of cgroup
> v1 under certain condtion,
Could the migration be simply omitted it those special cases?
(Tasks remain in cpusets with empty cpusets -- that already happens in
with the current patch before workqueue is dispatched.)
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Bartosz Golaszewski @ 2024-04-03 14:56 UTC (permalink / raw)
To: Kalle Valo
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <87msqm8l6q.fsf@kernel.org>
On Mon, Mar 25, 2024 at 3:01 PM Kalle Valo <kvalo@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > +
> > +maintainers:
> > + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> IMHO it would be better to have just driver maintainers listed here.
>
Why? What's wrong with having the author of the bindings in the Cc list?
> > +required:
> > + - compatible
> > + - reg
> > + - vddaon-supply
> > + - vddwlcx-supply
> > + - vddwlmx-supply
> > + - vddrfacmn-supply
> > + - vddrfa0p8-supply
> > + - vddrfa1p2-supply
> > + - vddrfa1p8-supply
> > + - vddpcie0p9-supply
> > + - vddpcie1p8-supply
>
> Same comment here as in patch 4. There are also ath12k PCI devices which
> don't need DT at all. I don't know if that should be reflected in the
> bindings doc but I want to point out this.
>
But DT bindings don't apply to devices that don't have DT nodes. This
isn't an issue at all.
Bart
^ permalink raw reply
* Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Michal Koutný @ 2024-04-03 14:54 UTC (permalink / raw)
To: Valentin Schneider
Cc: Waiman Long, Tejun Heo, Zefan Li, Johannes Weiner,
Thomas Gleixner, Peter Zijlstra, Rafael J. Wysocki, Len Brown,
Pavel Machek, Shuah Khan, linux-kernel, cgroups, linux-pm,
linux-kselftest, Frederic Weisbecker, Paul E. McKenney,
Ingo Molnar, Anna-Maria Behnsen, Alex Shi, Vincent Guittot,
Barry Song
In-Reply-To: <xhsmhedbmbjz5.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Wed, Apr 03, 2024 at 04:26:38PM +0200, Valentin Schneider <vschneid@redhat.com> wrote:
> Also, I gave Michal's patch a try and it looks like it's introducing a
Thank you.
> cgroup_threadgroup_rwsem -> cpuset_mutex
> ordering from
> cgroup_transfer_tasks_locked()
> `\
> percpu_down_write(&cgroup_threadgroup_rwsem);
> cgroup_migrate()
> `\
> cgroup_migrate_execute()
> `\
> ss->can_attach() // cpuset_can_attach()
> `\
> mutex_lock(&cpuset_mutex);
>
> which is invalid, see below.
_This_ should be the right order (cpuset_mutex inside
cgroup_threadgroup_rwsem), at least in my mental model. Thus I missed
that cpuset_mutex must have been taken somewhere higher up in the
hotplug code (CPU 0 in the lockdep dump, I can't easily see where from)
:-/.
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox