* Re: [PATCH v2 3/3] thermal: gov_power_allocator: Suppress sustainable_power warning without trip_points
From: Lukasz Luba @ 2024-04-03 12:52 UTC (permalink / raw)
To: Nikita Travkin
Cc: Rafael J. Wysocki, Rafael J. Wysocki, linux-pm, Zhang Rui,
Daniel Lezcano, linux-kernel
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-3-79bdd8439449@trvn.ru>
On 4/3/24 12:31, Nikita Travkin via B4 Relay wrote:
> From: Nikita Travkin <nikita@trvn.ru>
>
> IPA warns if the thermal zone it was attached to doesn't define
> sustainable_power value. In some cases though IPA may be bound to an
> "empty" TZ, in which case the lack of sustainable_power doesn't matter.
>
> Suppress the warning in case when IPA is bound to an empty TZ to make it
> easier to see the warnings that actually matter.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
>
> I've decided to add this along to supress those warnings for some TZ on
> sc7180. Feel free to drop this patch if you think the warning should
> always appear.
That warning should stay, since in the development or integration phase
quite a lot of stuff is missing. This will warn that there is an issue.
The case with 'empty' TZ is an exception only to 'work' with IPA.
Thanks for the patches!
Regards,
Lukasz
> ---
> 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 e25e48d76aa7..05a40f6b5928 100644
> --- a/drivers/thermal/gov_power_allocator.c
> +++ b/drivers/thermal/gov_power_allocator.c
> @@ -704,7 +704,7 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
> params->allocated_tzp = true;
> }
>
> - if (!tz->tzp->sustainable_power)
> + if (!tz->tzp->sustainable_power && params->trip_max)
> dev_warn(&tz->device, "power_allocator: sustainable_power will be estimated\n");
> else
> params->sustainable_power = tz->tzp->sustainable_power;
>
^ permalink raw reply
* Re: [PATCH v2 2/3] thermal: gov_power_allocator: Allow binding without trip points
From: Lukasz Luba @ 2024-04-03 12:48 UTC (permalink / raw)
To: Nikita Travkin
Cc: Rafael J. Wysocki, Rafael J. Wysocki, Daniel Lezcano, linux-pm,
linux-kernel, Zhang Rui
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-2-79bdd8439449@trvn.ru>
On 4/3/24 12:31, Nikita Travkin via B4 Relay wrote:
> From: Nikita Travkin <nikita@trvn.ru>
>
> IPA probe function was recently refactored to perform extra error checks
> and make sure the thermal zone has trip points necessary for the IPA
> operation. With this change, if a thermal zone is probed such that it
> has no trip points that IPA can use, IPA will fail and the TZ won't be
> created. This is the case if a platform defines a TZ without cooling
> devices and only with "hot"/"critical" trip points, often found on some
> Qualcomm devices [1].
>
> Documentation across IPA code (notably get_governor_trips() kerneldoc)
> suggests that IPA is supposed to handle such TZ even if it won't
> actually do anything.
>
> This commit partially reverts the previous change to allow IPA to bind
> to such "empty" thermal zones.
>
> [1] arch/arm64/boot/dts/qcom/sc7180.dtsi#n4776
>
> Fixes: e83747c2f8e3 ("thermal: gov_power_allocator: Set up trip points earlier")
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
> drivers/thermal/gov_power_allocator.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c
> index ec637071ef1f..e25e48d76aa7 100644
> --- a/drivers/thermal/gov_power_allocator.c
> +++ b/drivers/thermal/gov_power_allocator.c
> @@ -679,11 +679,6 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
> return -ENOMEM;
>
> get_governor_trips(tz, params);
> - if (!params->trip_max) {
> - dev_warn(&tz->device, "power_allocator: missing trip_max\n");
> - kfree(params);
> - return -EINVAL;
> - }
>
> ret = check_power_actors(tz, params);
> if (ret < 0) {
> @@ -714,9 +709,10 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
> else
> params->sustainable_power = tz->tzp->sustainable_power;
>
> - estimate_pid_constants(tz, tz->tzp->sustainable_power,
> - params->trip_switch_on,
> - params->trip_max->temperature);
> + if (params->trip_max)
> + estimate_pid_constants(tz, tz->tzp->sustainable_power,
> + params->trip_switch_on,
> + params->trip_max->temperature);
>
> reset_pid_controller(params);
>
>
LGTM
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
^ permalink raw reply
* Re: [PATCH v2 1/3] thermal: gov_power_allocator: Allow binding without cooling devices
From: Lukasz Luba @ 2024-04-03 12:43 UTC (permalink / raw)
To: Nikita Travkin
Cc: Rafael J. Wysocki, Rafael J. Wysocki, linux-pm, Daniel Lezcano,
linux-kernel, Zhang Rui
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-1-79bdd8439449@trvn.ru>
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>
^ permalink raw reply
* Re: [PATCH v4 0/4] Update Energy Model after chip binning adjusted voltages
From: Lukasz Luba @ 2024-04-03 12:36 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: linux-arm-kernel, sboyd, rafael, linux-pm, nm, linux-samsung-soc,
daniel.lezcano, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel
In-Reply-To: <045fa6db-4f76-46aa-85ba-c9e698c7e390@arm.com>
Hi Dietmar,
On 4/3/24 13:07, Dietmar Eggemann wrote:
> On 02/04/2024 17:58, Lukasz Luba wrote:
>> 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:
>> 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 | 11 +++-
>> include/linux/energy_model.h | 5 ++
>> include/linux/pm_opp.h | 8 +++
>> kernel/power/energy_model.c | 106 +++++++++++++++++++++++++------
>> 5 files changed, 122 insertions(+), 25 deletions(-)
>
> LGTM.
>
> Just two very minor things which I mentioned in the individual patches.
>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
>
>
Thank you for the review. I will send the v5 with those.
Regards,
Lukasz
^ permalink raw reply
* Re: [PATCH v4 4/4] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
From: Dietmar Eggemann @ 2024-04-03 12:07 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, rafael
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
viresh.kumar, krzysztof.kozlowski, alim.akhtar, m.szyprowski,
mhiramat
In-Reply-To: <20240402155822.505491-5-lukasz.luba@arm.com>
On 02/04/2024 17:58, Lukasz Luba wrote:
[...]
> @@ -97,9 +98,17 @@ 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) {
> + /*
> + * When the voltage for OPPs could be changed,
> + * make sure to update the EM power values, to
> + * reflect the reality and not use stale data.
> + */
Maybe shorter?
/*
* Update EM power values since OPP
* voltage values may have changed.
*/
[...]
^ permalink raw reply
* Re: [PATCH v4 1/4] OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
From: Dietmar Eggemann @ 2024-04-03 12:07 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, rafael
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
viresh.kumar, krzysztof.kozlowski, alim.akhtar, m.szyprowski,
mhiramat
In-Reply-To: <20240402155822.505491-2-lukasz.luba@arm.com>
On 02/04/2024 17:58, Lukasz Luba wrote:
[...]
> @@ -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)
This looks like a weird alignment comparing to the adjacent functions.
[...]
^ permalink raw reply
* Re: [PATCH v4 0/4] Update Energy Model after chip binning adjusted voltages
From: Dietmar Eggemann @ 2024-04-03 12:07 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, rafael
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
viresh.kumar, krzysztof.kozlowski, alim.akhtar, m.szyprowski,
mhiramat
In-Reply-To: <20240402155822.505491-1-lukasz.luba@arm.com>
On 02/04/2024 17:58, Lukasz Luba wrote:
> 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:
> 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 | 11 +++-
> include/linux/energy_model.h | 5 ++
> include/linux/pm_opp.h | 8 +++
> kernel/power/energy_model.c | 106 +++++++++++++++++++++++++------
> 5 files changed, 122 insertions(+), 25 deletions(-)
LGTM.
Just two very minor things which I mentioned in the individual patches.
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
^ permalink raw reply
* Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous
From: Michal Koutný @ 2024-04-03 12:02 UTC (permalink / raw)
To: Waiman Long
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,
Valentin Schneider, Anna-Maria Behnsen, Alex Shi, Vincent Guittot,
Barry Song
In-Reply-To: <548efd52-e45f-41fa-a477-bc5112d7b00c@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]
On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long <longman@redhat.com> wrote:
> Yes, there is a potential that a cpus_read_lock() may be called leading to
> deadlock. So unless we reverse the current cgroup_mutex --> cpu_hotplug_lock
> ordering, it is not safe to call cgroup_transfer_tasks() directly.
I see that cgroup_transfer_tasks() has the only user -- cpuset. What
about bending it for the specific use like:
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 34aaf0e87def..64deb7212c5c 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -109,7 +109,7 @@ struct cgroup *cgroup_get_from_fd(int fd);
struct cgroup *cgroup_v1v2_get_from_fd(int fd);
int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
-int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
+int cgroup_transfer_tasks_locked(struct cgroup *to, struct cgroup *from);
int cgroup_add_dfl_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 520a11cb12f4..f97025858c7a 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -91,7 +91,8 @@ EXPORT_SYMBOL_GPL(cgroup_attach_task_all);
*
* Return: %0 on success or a negative errno code on failure
*/
-int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
+int cgroup_transfer_tasks_locked(struct cgroup *to, struct cgroup *from)
{
DEFINE_CGROUP_MGCTX(mgctx);
struct cgrp_cset_link *link;
@@ -106,9 +106,11 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
if (ret)
return ret;
- cgroup_lock();
-
- cgroup_attach_lock(true);
+ /* The locking rules serve specific purpose of v1 cpuset hotplug
+ * migration, see hotplug_update_tasks_legacy() and
+ * cgroup_attach_lock() */
+ lockdep_assert_held(&cgroup_mutex);
+ lockdep_assert_cpus_held();
+ percpu_down_write(&cgroup_threadgroup_rwsem);
/* all tasks in @from are being moved, all csets are source */
spin_lock_irq(&css_set_lock);
@@ -144,8 +146,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
} while (task && !ret);
out_err:
cgroup_migrate_finish(&mgctx);
- cgroup_attach_unlock(true);
- cgroup_unlock();
+ percpu_up_write(&cgroup_threadgroup_rwsem);
return ret;
}
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 13d27b17c889..94fb8b26f038 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -4331,7 +4331,7 @@ static void remove_tasks_in_empty_cpuset(struct cpuset *cs)
nodes_empty(parent->mems_allowed))
parent = parent_cs(parent);
- if (cgroup_transfer_tasks(parent->css.cgroup, cs->css.cgroup)) {
+ if (cgroup_transfer_tasks_locked(parent->css.cgroup, cs->css.cgroup)) {
pr_err("cpuset: failed to transfer tasks out of empty cpuset ");
pr_cont_cgroup_name(cs->css.cgroup);
pr_cont("\n");
@@ -4376,21 +4376,9 @@ hotplug_update_tasks_legacy(struct cpuset *cs,
/*
* Move tasks to the nearest ancestor with execution resources,
- * This is full cgroup operation which will also call back into
- * cpuset. Execute it asynchronously using workqueue.
*/
- if (is_empty && css_tryget_online(&cs->css)) {
- struct cpuset_remove_tasks_struct *s;
-
- s = kzalloc(sizeof(*s), GFP_KERNEL);
- if (WARN_ON_ONCE(!s)) {
- css_put(&cs->css);
- return;
- }
-
- s->cs = cs;
- INIT_WORK(&s->work, cpuset_migrate_tasks_workfn);
- schedule_work(&s->work);
+ if (is_empty)
+ remove_tasks_in_empty_cpuset(cs);
}
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* [PATCH v2 2/3] thermal: gov_power_allocator: Allow binding without trip points
From: Nikita Travkin via B4 Relay @ 2024-04-03 11:31 UTC (permalink / raw)
To: Lukasz Luba, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui
Cc: Rafael J. Wysocki, linux-pm, linux-kernel, Nikita Travkin,
Nikita Travkin
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-0-79bdd8439449@trvn.ru>
From: Nikita Travkin <nikita@trvn.ru>
IPA probe function was recently refactored to perform extra error checks
and make sure the thermal zone has trip points necessary for the IPA
operation. With this change, if a thermal zone is probed such that it
has no trip points that IPA can use, IPA will fail and the TZ won't be
created. This is the case if a platform defines a TZ without cooling
devices and only with "hot"/"critical" trip points, often found on some
Qualcomm devices [1].
Documentation across IPA code (notably get_governor_trips() kerneldoc)
suggests that IPA is supposed to handle such TZ even if it won't
actually do anything.
This commit partially reverts the previous change to allow IPA to bind
to such "empty" thermal zones.
[1] arch/arm64/boot/dts/qcom/sc7180.dtsi#n4776
Fixes: e83747c2f8e3 ("thermal: gov_power_allocator: Set up trip points earlier")
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
---
drivers/thermal/gov_power_allocator.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c
index ec637071ef1f..e25e48d76aa7 100644
--- a/drivers/thermal/gov_power_allocator.c
+++ b/drivers/thermal/gov_power_allocator.c
@@ -679,11 +679,6 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
return -ENOMEM;
get_governor_trips(tz, params);
- if (!params->trip_max) {
- dev_warn(&tz->device, "power_allocator: missing trip_max\n");
- kfree(params);
- return -EINVAL;
- }
ret = check_power_actors(tz, params);
if (ret < 0) {
@@ -714,9 +709,10 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
else
params->sustainable_power = tz->tzp->sustainable_power;
- estimate_pid_constants(tz, tz->tzp->sustainable_power,
- params->trip_switch_on,
- params->trip_max->temperature);
+ if (params->trip_max)
+ estimate_pid_constants(tz, tz->tzp->sustainable_power,
+ params->trip_switch_on,
+ params->trip_max->temperature);
reset_pid_controller(params);
--
2.44.0
^ permalink raw reply related
* [PATCH v2 3/3] thermal: gov_power_allocator: Suppress sustainable_power warning without trip_points
From: Nikita Travkin via B4 Relay @ 2024-04-03 11:31 UTC (permalink / raw)
To: Lukasz Luba, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui
Cc: Rafael J. Wysocki, linux-pm, linux-kernel, Nikita Travkin,
Nikita Travkin
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-0-79bdd8439449@trvn.ru>
From: Nikita Travkin <nikita@trvn.ru>
IPA warns if the thermal zone it was attached to doesn't define
sustainable_power value. In some cases though IPA may be bound to an
"empty" TZ, in which case the lack of sustainable_power doesn't matter.
Suppress the warning in case when IPA is bound to an empty TZ to make it
easier to see the warnings that actually matter.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
---
I've decided to add this along to supress those warnings for some TZ on
sc7180. Feel free to drop this patch if you think the warning should
always appear.
---
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 e25e48d76aa7..05a40f6b5928 100644
--- a/drivers/thermal/gov_power_allocator.c
+++ b/drivers/thermal/gov_power_allocator.c
@@ -704,7 +704,7 @@ static int power_allocator_bind(struct thermal_zone_device *tz)
params->allocated_tzp = true;
}
- if (!tz->tzp->sustainable_power)
+ if (!tz->tzp->sustainable_power && params->trip_max)
dev_warn(&tz->device, "power_allocator: sustainable_power will be estimated\n");
else
params->sustainable_power = tz->tzp->sustainable_power;
--
2.44.0
^ permalink raw reply related
* [PATCH v2 0/3] gov_power_allocator: Allow binding before cooling devices
From: Nikita Travkin via B4 Relay @ 2024-04-03 11:31 UTC (permalink / raw)
To: Lukasz Luba, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui
Cc: Rafael J. Wysocki, linux-pm, linux-kernel, Nikita Travkin,
Nikita Travkin
Recent changes in IPA made it fail probing if the TZ has no cooling
devices attached on probe or no trip points defined.
This series restores prior behavior to:
- allow IPA to probe before cooling devices have attached;
- allow IPA to probe when the TZ has no passive/active trip points.
I've noticed that all thermal zones fail probing with -EINVAL on my
sc7180 based Acer Aspire 1 since 6.8. This series allows me to bring
them back.
Additionally there is a commit that supresses the "sustainable_power
will be estimated" warning on TZ that have no trip points (and thus IPA
will not be able to do anything for them anyway). This allowed me to
notice that some of the TZ with cooling_devices on my platform actually
lack the sustainable_power value.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
---
Changes in v2:
- Split to two changes (Lukasz)
- Return 0 in allocate_actors_buffer() instead of suppressing -EINVAL
(Lukasz)
- Add a change to supress "sustainable_power will be estimated" warning
on "empty" TZ
- Link to v1: https://lore.kernel.org/r/20240321-gpa-no-cooling-devs-v1-1-5c9e0ef2062e@trvn.ru
---
Nikita Travkin (3):
thermal: gov_power_allocator: Allow binding without cooling devices
thermal: gov_power_allocator: Allow binding without trip points
thermal: gov_power_allocator: Suppress sustainable_power warning without trip_points
drivers/thermal/gov_power_allocator.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
---
base-commit: 727900b675b749c40ba1f6669c7ae5eb7eb8e837
change-id: 20240321-gpa-no-cooling-devs-c79ee3288325
Best regards,
--
Nikita Travkin <nikita@trvn.ru>
^ permalink raw reply
* [PATCH v2 1/3] thermal: gov_power_allocator: Allow binding without cooling devices
From: Nikita Travkin via B4 Relay @ 2024-04-03 11:31 UTC (permalink / raw)
To: Lukasz Luba, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui
Cc: Rafael J. Wysocki, linux-pm, linux-kernel, Nikita Travkin,
Nikita Travkin
In-Reply-To: <20240403-gpa-no-cooling-devs-v2-0-79bdd8439449@trvn.ru>
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;
}
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v7 3/5] clk: qcom: common: Add interconnect clocks support
From: Dmitry Baryshkov @ 2024-04-03 11:06 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, quic_anusha, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-4-quic_varada@quicinc.com>
On Wed, 3 Apr 2024 at 13:42, Varadarajan Narayanan
<quic_varada@quicinc.com> wrote:
>
> Unlike MSM platforms that manage NoC related clocks and scaling
> from RPM, IPQ SoCs dont involve RPM in managing NoC related
> clocks and there is no NoC scaling.
>
> However, there is a requirement to enable some NoC interface
> clocks for accessing the peripheral controllers present on
> these NoCs. Though exposing these as normal clocks would work,
> having a minimalistic interconnect driver to handle these clocks
> would make it consistent with other Qualcomm platforms resulting
> in common code paths. This is similar to msm8996-cbf's usage of
> icc-clk framework.
>
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> ---
> v7: Restore clk_get
> v6: first_id -> icc_first_node_id
> Remove clock get so that the peripheral that uses the clock
> can do the clock get
> v5: Split changes in common.c to separate patch
> Fix error handling
> Use devm_icc_clk_register instead of icc_clk_register
> v4: Use clk_hw instead of indices
> Do icc register in qcom_cc_probe() call stream
> Add icc clock info to qcom_cc_desc structure
> v3: Use indexed identifiers here to avoid confusion
> Fix error messages and move to common.c
> v2: Move DTS to separate patch
> Update commit log
> Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK to fix build error
> ---
> drivers/clk/qcom/common.c | 31 ++++++++++++++++++++++++++++++-
> drivers/clk/qcom/common.h | 3 +++
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index 8b6080eb43a7..fa4ec89c04c4 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -8,6 +8,7 @@
> #include <linux/regmap.h>
> #include <linux/platform_device.h>
> #include <linux/clk-provider.h>
> +#include <linux/interconnect-clk.h>
> #include <linux/reset-controller.h>
> #include <linux/of.h>
>
> @@ -252,6 +253,34 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
> return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL;
> }
>
> +static int qcom_cc_icc_register(struct device *dev,
> + const struct qcom_cc_desc *desc)
> +{
> + struct icc_clk_data *icd;
> + int i;
> +
> + if (!IS_ENABLED(CONFIG_INTERCONNECT_CLK))
> + return 0;
> +
> + if (!desc->icc_hws)
> + return 0;
> +
> + icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL);
> + if (!icd)
> + return -ENOMEM;
> +
> + for (i = 0; i < desc->num_icc_hws; i++) {
> + icd[i].clk = devm_clk_hw_get_clk(dev, desc->icc_hws[i], "icc");
> + if (!icd[i].clk)
> + return dev_err_probe(dev, -ENOENT,
> + "(%d) clock entry is null\n", i);
> + icd[i].name = clk_hw_get_name(desc->icc_hws[i]);
> + }
> +
> + return devm_icc_clk_register(dev, desc->icc_first_node_id,
> + desc->num_icc_hws, icd);
> +}
> +
> int qcom_cc_really_probe(struct platform_device *pdev,
> const struct qcom_cc_desc *desc, struct regmap *regmap)
> {
> @@ -327,7 +356,7 @@ int _qcom_cc_really_probe(struct device *dev,
> if (ret)
> return ret;
>
> - return 0;
> + return qcom_cc_icc_register(dev, desc);
> }
> EXPORT_SYMBOL_GPL(_qcom_cc_really_probe);
>
> diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
> index 8657257d56d3..43073d2ef32a 100644
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -29,6 +29,9 @@ struct qcom_cc_desc {
> size_t num_gdscs;
> struct clk_hw **clk_hws;
> size_t num_clk_hws;
> + struct clk_hw **icc_hws;
Still we are passing hws here. We already have all the hws in a
different array. Can we just pass the indices?
> + size_t num_icc_hws;
> + unsigned int icc_first_node_id;
> };
>
> /**
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 2/5] interconnect: icc-clk: Add devm_icc_clk_register
From: Dmitry Baryshkov @ 2024-04-03 11:04 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, quic_anusha, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-3-quic_varada@quicinc.com>
On Wed, 3 Apr 2024 at 13:42, Varadarajan Narayanan
<quic_varada@quicinc.com> wrote:
>
> Wrap icc_clk_register to create devm_icc_clk_register to be
> able to release the resources properly.
>
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> ---
> v7: Simplify devm_icc_clk_register implementation as suggested in review
> v5: Introduced devm_icc_clk_register
> ---
> drivers/interconnect/icc-clk.c | 18 ++++++++++++++++++
> include/linux/interconnect-clk.h | 2 ++
> 2 files changed, 20 insertions(+)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 3/6] interconnect: icc-clk: Add devm_icc_clk_register
From: Varadarajan Narayanan @ 2024-04-03 10:45 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <CAA8EJprN3TuMF-v5PeFW_JUKk+a+MxB7poccZbi9biZNniRnTQ@mail.gmail.com>
On Tue, Apr 02, 2024 at 03:12:04PM +0300, Dmitry Baryshkov wrote:
> On Tue, 2 Apr 2024 at 14:23, Varadarajan Narayanan
> <quic_varada@quicinc.com> wrote:
> >
> > On Tue, Apr 02, 2024 at 02:16:56PM +0300, Dmitry Baryshkov wrote:
> > > On Tue, 2 Apr 2024 at 14:02, Varadarajan Narayanan
> > > <quic_varada@quicinc.com> wrote:
> > > >
> > > > On Tue, Apr 02, 2024 at 01:48:08PM +0300, Dmitry Baryshkov wrote:
> > > > > On Tue, 2 Apr 2024 at 13:40, Dmitry Baryshkov
> > > > > <dmitry.baryshkov@linaro.org> wrote:
> > > > > >
> > > > > > On Tue, 2 Apr 2024 at 13:34, Varadarajan Narayanan
> > > > > > <quic_varada@quicinc.com> wrote:
> > > > > > >
> > > > > > > Wrap icc_clk_register to create devm_icc_clk_register to be
> > > > > > > able to release the resources properly.
> > > > > > >
> > > > > > > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> > > > > > > ---
> > > > > > > v5: Introduced devm_icc_clk_register
> > > > > > > ---
> > > > > > > drivers/interconnect/icc-clk.c | 29 +++++++++++++++++++++++++++++
> > > > > > > include/linux/interconnect-clk.h | 4 ++++
> > > > > > > 2 files changed, 33 insertions(+)
> > > > > >
> > > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > >
> > > > > Wait. Actually,
> > > > >
> > > > > Unreviewed-by: me
> > > > >
> > > > > Please return int from devm_icc_clk_register instead of returning the pointer.
> > > >
> > > > Wouldn't returning int break the general assumption that
> > > > devm_foo(), returns the same type as foo(). For example
> > > > devm_clk_hw_get_clk and clk_hw_get_clk return struct clk *?
> > >
> > > Not always. The only reason to return icc_provider was to make it
> > > possible to destroy it. With devres-managed function you don't have to
> > > do anything.
> >
> > Ok. Will change as follows
> >
> > return prov; -> return PTR_ERR_OR_ZERO(prov);
> >
>
> I think the code might become simpler if you first allocate the ICC
> provider and then just 'return devm_add_action_or_reset(dev,
> your_icc_clk_release, provider)'
Have posted v7 incorporating these and other feedback.
Please review.
Thanks
Varada
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-03 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: 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
In-Reply-To: <1a6fccd3-452c-423f-b73e-cef5f9d01633@linaro.org>
On Wed, Apr 03, 2024 at 09:09:15AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 12:34, Varadarajan Narayanan wrote:
> > +#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(x) ((ICC_ ## x) * 2)
> > +#define SLAVE(x) (MASTER(x) + 1)
>
> You already received comment to make your bindings consistent with other
> Qualcomm bindings. Now you repeat the same mistake.
>
> No, that is neither consistent nor greppble.
Sorry. Have restored the naming and posted v7.
Kindly take a look.
Thanks
Varada
^ permalink raw reply
* [PATCH v7 5/5] arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
IPQ SoCs dont involve RPM in managing NoC related clocks and
there is no NoC scaling. Linux itself handles these clocks.
However, these should not be exposed as just clocks and align
with other Qualcomm SoCs that handle these clocks from a
interconnect provider.
Hence include icc provider capability to the gcc node so that
peripherals can use the interconnect facility to enable these
clocks.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
index c5abadf94975..0aba4c60e850 100644
--- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/qcom,apss-ipq.h>
#include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+#include <dt-bindings/interconnect/qcom,ipq9574.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/qcom,ipq9574-gcc.h>
#include <dt-bindings/clock/qcom,ipq9574-nsscc.h>
@@ -457,6 +458,7 @@ gcc: clock-controller@1800000 {
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
+ #interconnect-cells = <1>;
};
tcsr_mutex: hwlock@1905000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v7 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Use the icc-clk framework to enable few clocks to be able to
create paths and use the peripherals connected on those NoCs.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Auto select INTERCONNECT & INTERCONNECT_CLK in COMMON_CLK_QCOM
to address build break with random config build test, with the
following combination
CONFIG_COMMON_CLK_QCOM=y
and
CONFIG_INTERCONNECT_CLK=m
the following error is seen as devm_icc_clk_register is in a
module and being referenced from vmlinux.
powerpc64-linux-ld: drivers/clk/qcom/common.o: in function `qcom_cc_really_probe':
>> common.c:(.text+0x980): undefined reference to `devm_icc_clk_register'
v6: Move enum to dt-bindings and share between here and DT
first_id -> icc_first_node_id
v5: Split from common.c changes into separate patch
No functional changes
---
drivers/clk/qcom/Kconfig | 2 ++
drivers/clk/qcom/gcc-ipq9574.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index b0e0eeb1604e..e51328bbd146 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -17,6 +17,8 @@ menuconfig COMMON_CLK_QCOM
select RATIONAL
select REGMAP_MMIO
select RESET_CONTROLLER
+ select INTERCONNECT
+ select INTERCONNECT_CLK
if COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/gcc-ipq9574.c b/drivers/clk/qcom/gcc-ipq9574.c
index 43da03e4c2dd..0ede625777c9 100644
--- a/drivers/clk/qcom/gcc-ipq9574.c
+++ b/drivers/clk/qcom/gcc-ipq9574.c
@@ -12,6 +12,7 @@
#include <dt-bindings/clock/qcom,ipq9574-gcc.h>
#include <dt-bindings/reset/qcom,ipq9574-gcc.h>
+#include <dt-bindings/interconnect/qcom,ipq9574.h>
#include "clk-alpha-pll.h"
#include "clk-branch.h"
@@ -4067,6 +4068,32 @@ static const struct qcom_reset_map gcc_ipq9574_resets[] = {
[GCC_WCSS_Q6_TBU_BCR] = { 0x12054, 0 },
};
+#define IPQ_APPS_ID 9574 /* some unique value */
+
+static struct clk_hw *icc_ipq9574_hws[] = {
+ [ICC_ANOC_PCIE0] = &gcc_anoc_pcie0_1lane_m_clk.clkr.hw,
+ [ICC_SNOC_PCIE0] = &gcc_anoc_pcie1_1lane_m_clk.clkr.hw,
+ [ICC_ANOC_PCIE1] = &gcc_anoc_pcie2_2lane_m_clk.clkr.hw,
+ [ICC_SNOC_PCIE1] = &gcc_anoc_pcie3_2lane_m_clk.clkr.hw,
+ [ICC_ANOC_PCIE2] = &gcc_snoc_pcie0_1lane_s_clk.clkr.hw,
+ [ICC_SNOC_PCIE2] = &gcc_snoc_pcie1_1lane_s_clk.clkr.hw,
+ [ICC_ANOC_PCIE3] = &gcc_snoc_pcie2_2lane_s_clk.clkr.hw,
+ [ICC_SNOC_PCIE3] = &gcc_snoc_pcie3_2lane_s_clk.clkr.hw,
+ [ICC_SNOC_USB] = &gcc_snoc_usb_clk.clkr.hw,
+ [ICC_ANOC_USB_AXI] = &gcc_anoc_usb_axi_clk.clkr.hw,
+ [ICC_NSSNOC_NSSCC] = &gcc_nssnoc_nsscc_clk.clkr.hw,
+ [ICC_NSSNOC_SNOC_0] = &gcc_nssnoc_snoc_clk.clkr.hw,
+ [ICC_NSSNOC_SNOC_1] = &gcc_nssnoc_snoc_1_clk.clkr.hw,
+ [ICC_NSSNOC_PCNOC_1] = &gcc_nssnoc_pcnoc_1_clk.clkr.hw,
+ [ICC_NSSNOC_QOSGEN_REF] = &gcc_nssnoc_qosgen_ref_clk.clkr.hw,
+ [ICC_NSSNOC_TIMEOUT_REF] = &gcc_nssnoc_timeout_ref_clk.clkr.hw,
+ [ICC_NSSNOC_XO_DCD] = &gcc_nssnoc_xo_dcd_clk.clkr.hw,
+ [ICC_NSSNOC_ATB] = &gcc_nssnoc_atb_clk.clkr.hw,
+ [ICC_MEM_NOC_NSSNOC] = &gcc_mem_noc_nssnoc_clk.clkr.hw,
+ [ICC_NSSNOC_MEMNOC] = &gcc_nssnoc_memnoc_clk.clkr.hw,
+ [ICC_NSSNOC_MEM_NOC_1] = &gcc_nssnoc_mem_noc_1_clk.clkr.hw,
+};
+
static const struct of_device_id gcc_ipq9574_match_table[] = {
{ .compatible = "qcom,ipq9574-gcc" },
{ }
@@ -4089,6 +4116,9 @@ static const struct qcom_cc_desc gcc_ipq9574_desc = {
.num_resets = ARRAY_SIZE(gcc_ipq9574_resets),
.clk_hws = gcc_ipq9574_hws,
.num_clk_hws = ARRAY_SIZE(gcc_ipq9574_hws),
+ .icc_hws = icc_ipq9574_hws,
+ .num_icc_hws = ARRAY_SIZE(icc_ipq9574_hws),
+ .icc_first_node_id = IPQ_APPS_ID,
};
static int gcc_ipq9574_probe(struct platform_device *pdev)
--
2.34.1
^ permalink raw reply related
* [PATCH v7 3/5] clk: qcom: common: Add interconnect clocks support
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Unlike MSM platforms that manage NoC related clocks and scaling
from RPM, IPQ SoCs dont involve RPM in managing NoC related
clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for accessing the peripheral controllers present on
these NoCs. Though exposing these as normal clocks would work,
having a minimalistic interconnect driver to handle these clocks
would make it consistent with other Qualcomm platforms resulting
in common code paths. This is similar to msm8996-cbf's usage of
icc-clk framework.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Restore clk_get
v6: first_id -> icc_first_node_id
Remove clock get so that the peripheral that uses the clock
can do the clock get
v5: Split changes in common.c to separate patch
Fix error handling
Use devm_icc_clk_register instead of icc_clk_register
v4: Use clk_hw instead of indices
Do icc register in qcom_cc_probe() call stream
Add icc clock info to qcom_cc_desc structure
v3: Use indexed identifiers here to avoid confusion
Fix error messages and move to common.c
v2: Move DTS to separate patch
Update commit log
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK to fix build error
---
drivers/clk/qcom/common.c | 31 ++++++++++++++++++++++++++++++-
drivers/clk/qcom/common.h | 3 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index 8b6080eb43a7..fa4ec89c04c4 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -8,6 +8,7 @@
#include <linux/regmap.h>
#include <linux/platform_device.h>
#include <linux/clk-provider.h>
+#include <linux/interconnect-clk.h>
#include <linux/reset-controller.h>
#include <linux/of.h>
@@ -252,6 +253,34 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL;
}
+static int qcom_cc_icc_register(struct device *dev,
+ const struct qcom_cc_desc *desc)
+{
+ struct icc_clk_data *icd;
+ int i;
+
+ if (!IS_ENABLED(CONFIG_INTERCONNECT_CLK))
+ return 0;
+
+ if (!desc->icc_hws)
+ return 0;
+
+ icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL);
+ if (!icd)
+ return -ENOMEM;
+
+ for (i = 0; i < desc->num_icc_hws; i++) {
+ icd[i].clk = devm_clk_hw_get_clk(dev, desc->icc_hws[i], "icc");
+ if (!icd[i].clk)
+ return dev_err_probe(dev, -ENOENT,
+ "(%d) clock entry is null\n", i);
+ icd[i].name = clk_hw_get_name(desc->icc_hws[i]);
+ }
+
+ return devm_icc_clk_register(dev, desc->icc_first_node_id,
+ desc->num_icc_hws, icd);
+}
+
int qcom_cc_really_probe(struct platform_device *pdev,
const struct qcom_cc_desc *desc, struct regmap *regmap)
{
@@ -327,7 +356,7 @@ int _qcom_cc_really_probe(struct device *dev,
if (ret)
return ret;
- return 0;
+ return qcom_cc_icc_register(dev, desc);
}
EXPORT_SYMBOL_GPL(_qcom_cc_really_probe);
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 8657257d56d3..43073d2ef32a 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -29,6 +29,9 @@ struct qcom_cc_desc {
size_t num_gdscs;
struct clk_hw **clk_hws;
size_t num_clk_hws;
+ struct clk_hw **icc_hws;
+ size_t num_icc_hws;
+ unsigned int icc_first_node_id;
};
/**
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/5] interconnect: icc-clk: Add devm_icc_clk_register
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Wrap icc_clk_register to create devm_icc_clk_register to be
able to release the resources properly.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Simplify devm_icc_clk_register implementation as suggested in review
v5: Introduced devm_icc_clk_register
---
drivers/interconnect/icc-clk.c | 18 ++++++++++++++++++
include/linux/interconnect-clk.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
index d787f2ea36d9..bce946592c98 100644
--- a/drivers/interconnect/icc-clk.c
+++ b/drivers/interconnect/icc-clk.c
@@ -148,6 +148,24 @@ struct icc_provider *icc_clk_register(struct device *dev,
}
EXPORT_SYMBOL_GPL(icc_clk_register);
+static void devm_icc_release(void *res)
+{
+ icc_clk_unregister(res);
+}
+
+int devm_icc_clk_register(struct device *dev, unsigned int first_id,
+ unsigned int num_clocks, const struct icc_clk_data *data)
+{
+ struct icc_provider *prov;
+
+ prov = icc_clk_register(dev, first_id, num_clocks, data);
+ if (IS_ERR(prov))
+ return PTR_ERR(prov);
+
+ return devm_add_action_or_reset(dev, devm_icc_release, prov);
+}
+EXPORT_SYMBOL_GPL(devm_icc_clk_register);
+
/**
* icc_clk_unregister() - unregister a previously registered clk interconnect provider
* @provider: provider returned by icc_clk_register()
diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h
index 0cd80112bea5..5c611a8b0892 100644
--- a/include/linux/interconnect-clk.h
+++ b/include/linux/interconnect-clk.h
@@ -17,6 +17,8 @@ struct icc_provider *icc_clk_register(struct device *dev,
unsigned int first_id,
unsigned int num_clocks,
const struct icc_clk_data *data);
+int devm_icc_clk_register(struct device *dev, unsigned int first_id,
+ unsigned int num_clocks, const struct icc_clk_data *data);
void icc_clk_unregister(struct icc_provider *provider);
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
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)
+#define MASTER_SNOC_PCIE0 (ICC_SNOC_PCIE0 * 2)
+#define SLAVE_SNOC_PCIE0 ((ICC_SNOC_PCIE0 * 2) + 1)
+#define MASTER_ANOC_PCIE1 (ICC_ANOC_PCIE1 * 2)
+#define SLAVE_ANOC_PCIE1 ((ICC_ANOC_PCIE1 * 2) + 1)
+#define MASTER_SNOC_PCIE1 (ICC_SNOC_PCIE1 * 2)
+#define SLAVE_SNOC_PCIE1 ((ICC_SNOC_PCIE1 * 2) + 1)
+#define MASTER_ANOC_PCIE2 (ICC_ANOC_PCIE2 * 2)
+#define SLAVE_ANOC_PCIE2 ((ICC_ANOC_PCIE2 * 2) + 1)
+#define MASTER_SNOC_PCIE2 (ICC_SNOC_PCIE2 * 2)
+#define SLAVE_SNOC_PCIE2 ((ICC_SNOC_PCIE2 * 2) + 1)
+#define MASTER_ANOC_PCIE3 (ICC_ANOC_PCIE3 * 2)
+#define SLAVE_ANOC_PCIE3 ((ICC_ANOC_PCIE3 * 2) + 1)
+#define MASTER_SNOC_PCIE3 (ICC_SNOC_PCIE3 * 2)
+#define SLAVE_SNOC_PCIE3 ((ICC_SNOC_PCIE3 * 2) + 1)
+#define MASTER_USB (ICC_USB * 2)
+#define SLAVE_USB ((ICC_USB * 2) + 1)
+#define MASTER_USB_AXI (ICC_USB_AXI * 2)
+#define SLAVE_USB_AXI ((ICC_USB_AXI * 2) + 1)
+#define MASTER_NSSNOC_NSSCC (ICC_NSSNOC_NSSCC * 2)
+#define SLAVE_NSSNOC_NSSCC ((ICC_NSSNOC_NSSCC * 2) + 1)
+#define MASTER_NSSNOC_SNOC_0 (ICC_NSSNOC_SNOC_0 * 2)
+#define SLAVE_NSSNOC_SNOC_0 ((ICC_NSSNOC_SNOC_0 * 2) + 1)
+#define MASTER_NSSNOC_SNOC_1 (ICC_NSSNOC_SNOC_1 * 2)
+#define SLAVE_NSSNOC_SNOC_1 ((ICC_NSSNOC_SNOC_1 * 2) + 1)
+#define MASTER_NSSNOC_PCNOC_1 (ICC_NSSNOC_PCNOC_1 * 2)
+#define SLAVE_NSSNOC_PCNOC_1 ((ICC_NSSNOC_PCNOC_1 * 2) + 1)
+#define MASTER_NSSNOC_QOSGEN_REF (ICC_NSSNOC_QOSGEN_REF * 2)
+#define SLAVE_NSSNOC_QOSGEN_REF ((ICC_NSSNOC_QOSGEN_REF * 2) + 1)
+#define MASTER_NSSNOC_TIMEOUT_REF (ICC_NSSNOC_TIMEOUT_REF * 2)
+#define SLAVE_NSSNOC_TIMEOUT_REF ((ICC_NSSNOC_TIMEOUT_REF * 2) + 1)
+#define MASTER_NSSNOC_XO_DCD (ICC_NSSNOC_XO_DCD * 2)
+#define SLAVE_NSSNOC_XO_DCD ((ICC_NSSNOC_XO_DCD * 2) + 1)
+#define MASTER_NSSNOC_ATB (ICC_NSSNOC_ATB * 2)
+#define SLAVE_NSSNOC_ATB ((ICC_NSSNOC_ATB * 2) + 1)
+#define MASTER_MEM_NOC_NSSNOC (ICC_MEM_NOC_NSSNOC * 2)
+#define SLAVE_MEM_NOC_NSSNOC ((ICC_MEM_NOC_NSSNOC * 2) + 1)
+#define MASTER_NSSNOC_MEMNOC (ICC_NSSNOC_MEMNOC * 2)
+#define SLAVE_NSSNOC_MEMNOC ((ICC_NSSNOC_MEMNOC * 2) + 1)
+#define MASTER_NSSNOC_MEM_NOC_1 (ICC_NSSNOC_MEM_NOC_1 * 2)
+#define SLAVE_NSSNOC_MEM_NOC_1 ((ICC_NSSNOC_MEM_NOC_1 * 2) + 1)
+
+#define MASTER_NSSNOC_PPE (ICC_NSSNOC_PPE * 2)
+#define SLAVE_NSSNOC_PPE ((ICC_NSSNOC_PPE * 2) + 1)
+#define MASTER_NSSNOC_PPE_CFG (ICC_NSSNOC_PPE_CFG * 2)
+#define SLAVE_NSSNOC_PPE_CFG ((ICC_NSSNOC_PPE_CFG * 2) + 1)
+#define MASTER_NSSNOC_NSS_CSR (ICC_NSSNOC_NSS_CSR * 2)
+#define SLAVE_NSSNOC_NSS_CSR ((ICC_NSSNOC_NSS_CSR * 2) + 1)
+#define MASTER_NSSNOC_IMEM_QSB (ICC_NSSNOC_IMEM_QSB * 2)
+#define SLAVE_NSSNOC_IMEM_QSB ((ICC_NSSNOC_IMEM_QSB * 2) + 1)
+#define MASTER_NSSNOC_IMEM_AHB (ICC_NSSNOC_IMEM_AHB * 2)
+#define SLAVE_NSSNOC_IMEM_AHB ((ICC_NSSNOC_IMEM_AHB * 2) + 1)
+
+#endif /* INTERCONNECT_QCOM_IPQ9574_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v7 0/5] Add interconnect driver for IPQ9574 SoC
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
MSM platforms manage NoC related clocks and scaling from RPM.
However, in IPQ SoCs, RPM is not involved in managing NoC
related clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for the accessing the peripherals present in the
system. Hence add a minimalistic interconnect driver that
establishes a path from the processor/memory to those peripherals
and vice versa.
---
v7: Fix macro names in dt-bindings header
Do clock get in icc driver
v6: Removed 'Reviewed-by: Krzysztof' from dt-bindings patch
Remove clock get from ICC driver as suggested by Stephen Boyd
so that the actual peripheral can do the clock get
first_id -> icc_first_node_id
Remove tristate from INTERCONNECT_CLK
v5:
Split gcc-ipq9574.c and common.c changes into separate patches
Introduce devm_icc_clk_register
Fix error handling
v4:
gcc-ipq9574.c
Use clk_hw instead of indices
common.c
Do icc register in qcom_cc_probe() call stream
common.h
Add icc clock info to qcom_cc_desc structure
v3:
qcom,ipq9574.h
Move 'first id' define to clock driver
gcc-ipq9574.c:
Use indexed identifiers here to avoid confusion
Fix error messages and move code to common.c as it can be
shared with future SoCs
v2:
qcom,ipq9574.h
Fix license identifier
Rename macros
qcom,ipq9574-gcc.yaml
Include interconnect-cells
gcc-ipq9574.c
Update commit log
Remove IS_ENABLED(CONFIG_INTERCONNECT) and auto select it from Kconfig
ipq9574.dtsi
Moved to separate patch
Include interconnect-cells to clock controller node
drivers/clk/qcom/Kconfig:
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK
Varadarajan Narayanan (5):
dt-bindings: interconnect: Add Qualcomm IPQ9574 support
interconnect: icc-clk: Add devm_icc_clk_register
clk: qcom: common: Add interconnect clocks support
clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
.../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 +
drivers/clk/qcom/Kconfig | 2 +
drivers/clk/qcom/common.c | 31 ++++++-
drivers/clk/qcom/common.h | 3 +
drivers/clk/qcom/gcc-ipq9574.c | 30 +++++++
drivers/interconnect/icc-clk.c | 18 ++++
.../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
include/linux/interconnect-clk.h | 2 +
9 files changed, 177 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH] ARM: dts: n900: set charge current limit to 950mA
From: Tony Lindgren @ 2024-04-03 9:03 UTC (permalink / raw)
To: Sicelo A. Mhlongo
Cc: devicetree, Benoît Cousson, Krzysztof Kozlowski,
Conor Dooley, linux-pm, pali, sre, spinal.by, maemo-leste,
linux-omap
In-Reply-To: <20240228083846.2401108-2-absicsz@gmail.com>
* Sicelo A. Mhlongo <absicsz@gmail.com> [240228 10:40]:
> From: Arthur Demchenkov <spinal.by@gmail.com>
>
> The vendor kernel used 950mA as the default. The same value works fine on
> the mainline Linux kernel, and has been tested extensively under Maemo
> Leste [1] and postmarketOS, who have been using it for a number of years.
Thanks applying into omap-for-v6.10/dt.
Tony
> [1] https://github.com/maemo-leste/n9xx-linux/commit/fbc4ce7a84e59215914a8981afe918002b191493
^ permalink raw reply
* Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support
From: Odelu Kukatla @ 2024-04-03 8:45 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Georgi Djakov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <d59896bb-a559-4013-a615-37bb43278b2e@linaro.org>
On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>> It adds QoS support for QNOC device and includes support for
>> configuring priority, priority forward disable, urgency forwarding.
>> This helps in priortizing the traffic originating from different
>> interconnect masters at NoC(Network On Chip).
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>> ---
>
> [...]
>
>>
>> + if (desc->config) {
>> + struct resource *res;
>> + void __iomem *base;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto skip_qos_config;
>> +
>> + base = devm_ioremap_resource(dev, res);
>
> You were asked to substitute this call like 3 times already..
>
> devm_platform_get_and_ioremap_resource
>
> or even better, devm_platform_ioremap_resource
>
> [...]
>
>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>> u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>> struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>> size_t num_bcms;
>> + const struct qcom_icc_qosbox *qosbox;
>
> I believe I came up with a better approach for storing this.. see [1]
>
> Konrad
>
> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>
I see in this series, QoS parameters are moved into struct qcom_icc_desc.
Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.
It will be easier later to know which master's QoS we are programming if we add in node data.
Readability point of view, it might be good to keep QoS parameters in node data.
Thanks,
Odelu
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS acc71791e32e8c9a8fbe04ced8b00c49dfbcc52b
From: kernel test robot @ 2024-04-03 8:20 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, devel, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: acc71791e32e8c9a8fbe04ced8b00c49dfbcc52b Merge branch 'acpi-thermal' into bleeding-edge
elapsed time: 729m
configs tested: 162
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc nsimosci_hs_smp_defconfig gcc
arc randconfig-001-20240403 gcc
arc randconfig-002-20240403 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm integrator_defconfig clang
arm randconfig-001-20240403 gcc
arm randconfig-002-20240403 gcc
arm randconfig-003-20240403 clang
arm randconfig-004-20240403 gcc
arm realview_defconfig clang
arm s5pv210_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240403 clang
arm64 randconfig-002-20240403 clang
arm64 randconfig-003-20240403 gcc
arm64 randconfig-004-20240403 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240403 gcc
csky randconfig-002-20240403 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240403 clang
hexagon randconfig-002-20240403 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240403 gcc
i386 buildonly-randconfig-002-20240403 clang
i386 buildonly-randconfig-003-20240403 clang
i386 buildonly-randconfig-004-20240403 clang
i386 buildonly-randconfig-005-20240403 gcc
i386 buildonly-randconfig-006-20240403 clang
i386 defconfig clang
i386 randconfig-001-20240403 gcc
i386 randconfig-002-20240403 clang
i386 randconfig-003-20240403 gcc
i386 randconfig-004-20240403 gcc
i386 randconfig-005-20240403 clang
i386 randconfig-006-20240403 gcc
i386 randconfig-011-20240403 gcc
i386 randconfig-012-20240403 clang
i386 randconfig-013-20240403 gcc
i386 randconfig-014-20240403 clang
i386 randconfig-015-20240403 gcc
i386 randconfig-016-20240403 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240403 gcc
loongarch randconfig-002-20240403 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240403 gcc
nios2 randconfig-002-20240403 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
openrisc or1ksim_defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240403 gcc
parisc randconfig-002-20240403 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc cm5200_defconfig clang
powerpc eiger_defconfig clang
powerpc ep8248e_defconfig gcc
powerpc kmeter1_defconfig gcc
powerpc mpc8315_rdb_defconfig clang
powerpc randconfig-001-20240403 gcc
powerpc randconfig-002-20240403 gcc
powerpc randconfig-003-20240403 clang
powerpc tqm8555_defconfig clang
powerpc64 randconfig-001-20240403 gcc
powerpc64 randconfig-002-20240403 clang
powerpc64 randconfig-003-20240403 gcc
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240403 clang
riscv randconfig-002-20240403 clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240403 clang
s390 randconfig-002-20240403 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh kfr2r09-romimage_defconfig gcc
sh kfr2r09_defconfig gcc
sh lboxre2_defconfig gcc
sh randconfig-001-20240403 gcc
sh randconfig-002-20240403 gcc
sh se7724_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240403 gcc
sparc64 randconfig-002-20240403 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240403 gcc
um randconfig-002-20240403 clang
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240403 gcc
x86_64 buildonly-randconfig-002-20240403 gcc
x86_64 buildonly-randconfig-003-20240403 clang
x86_64 buildonly-randconfig-004-20240403 gcc
x86_64 buildonly-randconfig-005-20240403 clang
x86_64 buildonly-randconfig-006-20240403 gcc
x86_64 defconfig gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa audio_kc705_defconfig gcc
xtensa randconfig-001-20240403 gcc
xtensa randconfig-002-20240403 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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