Linux-PM Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 0/5] Initialise thermal framework earlier during boot
@ 2019-09-11 22:32 Amit Kucheria
  2019-09-11 22:32 ` [PATCH 1/5] thermal: Initialize thermal subsystem earlier Amit Kucheria
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: Amit Kucheria @ 2019-09-11 22:32 UTC (permalink / raw)
  To: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Viresh Kumar, Zhang Rui
  Cc: linux-clk, linux-pm

Device boot needs to be as fast as possible while keeping under the thermal
envelope. Now that thermal framework is built-in to the kernel, we can
initialize it earlier to enable thermal mitigation during boot.

We also need the cpufreq HW drivers to be initialised earlier to act as the
cooling devices. This series only converts over the qcom-hw driver to
initialize earlier but can be extended to other platforms as well.


Amit Kucheria (4):
  cpufreq: Initialise the governors in core_initcall
  cpufreq: Initialize cpufreq-dt driver earlier
  clk: qcom: Initialise clock drivers earlier
  cpufreq: qcom-hw: Move driver initialisation earlier

Lina Iyer (1):
  thermal: Initialize thermal subsystem earlier

 drivers/clk/qcom/clk-rpmh.c            |  2 +-
 drivers/clk/qcom/gcc-qcs404.c          |  2 +-
 drivers/clk/qcom/gcc-sdm845.c          |  2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c   |  2 +-
 drivers/cpufreq/cpufreq_conservative.c |  2 +-
 drivers/cpufreq/cpufreq_ondemand.c     |  2 +-
 drivers/cpufreq/cpufreq_performance.c  |  2 +-
 drivers/cpufreq/cpufreq_powersave.c    |  2 +-
 drivers/cpufreq/cpufreq_userspace.c    |  2 +-
 drivers/cpufreq/qcom-cpufreq-hw.c      |  2 +-
 drivers/thermal/thermal_core.c         | 41 +++++++++++++++-----------
 11 files changed, 34 insertions(+), 27 deletions(-)

-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 1/5] thermal: Initialize thermal subsystem earlier
  2019-09-11 22:32 [PATCH 0/5] Initialise thermal framework earlier during boot Amit Kucheria
@ 2019-09-11 22:32 ` Amit Kucheria
  2019-09-16 20:00   ` Daniel Lezcano
  2019-09-11 22:32 ` [PATCH 2/5] cpufreq: Initialise the governors in core_initcall Amit Kucheria
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 20+ messages in thread
From: Amit Kucheria @ 2019-09-11 22:32 UTC (permalink / raw)
  To: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

From: Lina Iyer <ilina@codeaurora.org>

Now that the thermal framework is built-in, in order to facilitate
thermal mitigation as early as possible in the boot cycle, move the
thermal framework initialization to core_initcall.

However, netlink initialization happens only as part of subsys_initcall.
At this time in the boot process, the userspace is not available yet. So
initialize the netlink events later in fs_initcall.

Signed-off-by: Lina Iyer <ilina@codeaurora.org>
[Rebased, refactored and moved to core_initcall]
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 drivers/thermal/thermal_core.c | 41 ++++++++++++++++++++--------------
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 6bab66e84eb5..b13e8a9298cc 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1468,6 +1468,8 @@ static struct genl_family thermal_event_genl_family __ro_after_init = {
 	.n_mcgrps = ARRAY_SIZE(thermal_event_mcgrps),
 };
 
+static bool allow_netlink_events;
+
 int thermal_generate_netlink_event(struct thermal_zone_device *tz,
 				   enum events event)
 {
@@ -1482,6 +1484,9 @@ int thermal_generate_netlink_event(struct thermal_zone_device *tz,
 	if (!tz)
 		return -EINVAL;
 
+	if (!allow_netlink_events)
+		return -ENODEV;
+
 	/* allocate memory */
 	size = nla_total_size(sizeof(struct thermal_genl_event)) +
 	       nla_total_size(0);
@@ -1533,16 +1538,18 @@ EXPORT_SYMBOL_GPL(thermal_generate_netlink_event);
 
 static int __init genetlink_init(void)
 {
-	return genl_register_family(&thermal_event_genl_family);
-}
+	int ret;
 
-static void genetlink_exit(void)
-{
-	genl_unregister_family(&thermal_event_genl_family);
+	ret = genl_register_family(&thermal_event_genl_family);
+	if (!ret)
+		allow_netlink_events = true;
+	return ret;
 }
+
 #else /* !CONFIG_NET */
 static inline int genetlink_init(void) { return 0; }
-static inline void genetlink_exit(void) {}
+static inline int thermal_generate_netlink_event(struct thermal_zone_device *tz,
+						 enum events event) { return -ENODEV; }
 #endif /* !CONFIG_NET */
 
 static int thermal_pm_notify(struct notifier_block *nb,
@@ -1591,19 +1598,15 @@ static int __init thermal_init(void)
 	mutex_init(&poweroff_lock);
 	result = thermal_register_governors();
 	if (result)
-		goto error;
+		goto init_exit;
 
 	result = class_register(&thermal_class);
 	if (result)
 		goto unregister_governors;
 
-	result = genetlink_init();
-	if (result)
-		goto unregister_class;
-
 	result = of_parse_thermal_zones();
 	if (result)
-		goto exit_netlink;
+		goto exit_zone_parse;
 
 	result = register_pm_notifier(&thermal_pm_nb);
 	if (result)
@@ -1612,13 +1615,11 @@ static int __init thermal_init(void)
 
 	return 0;
 
-exit_netlink:
-	genetlink_exit();
-unregister_class:
+exit_zone_parse:
 	class_unregister(&thermal_class);
 unregister_governors:
 	thermal_unregister_governors();
-error:
+init_exit:
 	ida_destroy(&thermal_tz_ida);
 	ida_destroy(&thermal_cdev_ida);
 	mutex_destroy(&thermal_list_lock);
@@ -1626,4 +1627,10 @@ static int __init thermal_init(void)
 	mutex_destroy(&poweroff_lock);
 	return result;
 }
-fs_initcall(thermal_init);
+
+static int __init thermal_netlink_init(void)
+{
+	return genetlink_init();
+}
+core_initcall(thermal_init);
+fs_initcall(thermal_netlink_init);
-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 2/5] cpufreq: Initialise the governors in core_initcall
  2019-09-11 22:32 [PATCH 0/5] Initialise thermal framework earlier during boot Amit Kucheria
  2019-09-11 22:32 ` [PATCH 1/5] thermal: Initialize thermal subsystem earlier Amit Kucheria
@ 2019-09-11 22:32 ` Amit Kucheria
  2019-09-17  8:17   ` Viresh Kumar
  2019-09-11 22:32 ` [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier Amit Kucheria
  2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
  3 siblings, 1 reply; 20+ messages in thread
From: Amit Kucheria @ 2019-09-11 22:32 UTC (permalink / raw)
  To: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

Initialise the cpufreq governors earlier to allow for earlier
performance control during the boot process.

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 drivers/cpufreq/cpufreq_conservative.c | 2 +-
 drivers/cpufreq/cpufreq_ondemand.c     | 2 +-
 drivers/cpufreq/cpufreq_performance.c  | 2 +-
 drivers/cpufreq/cpufreq_powersave.c    | 2 +-
 drivers/cpufreq/cpufreq_userspace.c    | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index b66e81c06a57..737ff3b9c2c0 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -346,7 +346,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
 	return CPU_FREQ_GOV_CONSERVATIVE;
 }
 
-fs_initcall(cpufreq_gov_dbs_init);
+core_initcall(cpufreq_gov_dbs_init);
 #else
 module_init(cpufreq_gov_dbs_init);
 #endif
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index dced033875bf..82a4d37ddecb 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -483,7 +483,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
 	return CPU_FREQ_GOV_ONDEMAND;
 }
 
-fs_initcall(cpufreq_gov_dbs_init);
+core_initcall(cpufreq_gov_dbs_init);
 #else
 module_init(cpufreq_gov_dbs_init);
 #endif
diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c
index aaa04dfcacd9..def9afe0f5b8 100644
--- a/drivers/cpufreq/cpufreq_performance.c
+++ b/drivers/cpufreq/cpufreq_performance.c
@@ -50,5 +50,5 @@ MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
 MODULE_DESCRIPTION("CPUfreq policy governor 'performance'");
 MODULE_LICENSE("GPL");
 
-fs_initcall(cpufreq_gov_performance_init);
+core_initcall(cpufreq_gov_performance_init);
 module_exit(cpufreq_gov_performance_exit);
diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c
index c143dc237d87..1ae66019eb83 100644
--- a/drivers/cpufreq/cpufreq_powersave.c
+++ b/drivers/cpufreq/cpufreq_powersave.c
@@ -43,7 +43,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
 	return &cpufreq_gov_powersave;
 }
 
-fs_initcall(cpufreq_gov_powersave_init);
+core_initcall(cpufreq_gov_powersave_init);
 #else
 module_init(cpufreq_gov_powersave_init);
 #endif
diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index cbd81c58cb8f..b43e7cd502c5 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -147,7 +147,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
 	return &cpufreq_gov_userspace;
 }
 
-fs_initcall(cpufreq_gov_userspace_init);
+core_initcall(cpufreq_gov_userspace_init);
 #else
 module_init(cpufreq_gov_userspace_init);
 #endif
-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier
  2019-09-11 22:32 [PATCH 0/5] Initialise thermal framework earlier during boot Amit Kucheria
  2019-09-11 22:32 ` [PATCH 1/5] thermal: Initialize thermal subsystem earlier Amit Kucheria
  2019-09-11 22:32 ` [PATCH 2/5] cpufreq: Initialise the governors in core_initcall Amit Kucheria
@ 2019-09-11 22:32 ` Amit Kucheria
  2019-09-17  8:18   ` Viresh Kumar
  2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
  3 siblings, 1 reply; 20+ messages in thread
From: Amit Kucheria @ 2019-09-11 22:32 UTC (permalink / raw)
  To: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

This allows HW drivers that depend on cpufreq-dt to initialise earlier.

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 03dc4244ab00..12c79c92a2b8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -175,4 +175,4 @@ static int __init cpufreq_dt_platdev_init(void)
 			       -1, data,
 			       sizeof(struct cpufreq_dt_platform_data)));
 }
-device_initcall(cpufreq_dt_platdev_init);
+core_initcall(cpufreq_dt_platdev_init);
-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-11 22:32 [PATCH 0/5] Initialise thermal framework earlier during boot Amit Kucheria
                   ` (2 preceding siblings ...)
  2019-09-11 22:32 ` [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier Amit Kucheria
@ 2019-09-11 22:32 ` Amit Kucheria
  2019-09-17  8:17   ` Viresh Kumar
                     ` (2 more replies)
  3 siblings, 3 replies; 20+ messages in thread
From: Amit Kucheria @ 2019-09-11 22:32 UTC (permalink / raw)
  To: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

Allow qcom-hw driver to initialise right after the cpufreq and thermal
subsystems are initialised in core_initcall so we get earlier access to
thermal mitigation.

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 4b0b50403901..04676cc82ba6 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
 {
 	return platform_driver_register(&qcom_cpufreq_hw_driver);
 }
-device_initcall(qcom_cpufreq_hw_init);
+postcore_initcall(qcom_cpufreq_hw_init);
 
 static void __exit qcom_cpufreq_hw_exit(void)
 {
-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 1/5] thermal: Initialize thermal subsystem earlier
  2019-09-11 22:32 ` [PATCH 1/5] thermal: Initialize thermal subsystem earlier Amit Kucheria
@ 2019-09-16 20:00   ` Daniel Lezcano
  2019-09-17  9:18     ` Amit Kucheria
  0 siblings, 1 reply; 20+ messages in thread
From: Daniel Lezcano @ 2019-09-16 20:00 UTC (permalink / raw)
  To: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

On 12/09/2019 00:32, Amit Kucheria wrote:
> From: Lina Iyer <ilina@codeaurora.org>
> 
> Now that the thermal framework is built-in, in order to facilitate
> thermal mitigation as early as possible in the boot cycle, move the
> thermal framework initialization to core_initcall.
> 
> However, netlink initialization happens only as part of subsys_initcall.
> At this time in the boot process, the userspace is not available yet. So
> initialize the netlink events later in fs_initcall.

Why not kill directly the netlink part, no one is using it in the kernel?


> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
> [Rebased, refactored and moved to core_initcall]
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  drivers/thermal/thermal_core.c | 41 ++++++++++++++++++++--------------
>  1 file changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 6bab66e84eb5..b13e8a9298cc 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1468,6 +1468,8 @@ static struct genl_family thermal_event_genl_family __ro_after_init = {
>  	.n_mcgrps = ARRAY_SIZE(thermal_event_mcgrps),
>  };
>  
> +static bool allow_netlink_events;
> +
>  int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>  				   enum events event)
>  {
> @@ -1482,6 +1484,9 @@ int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>  	if (!tz)
>  		return -EINVAL;
>  
> +	if (!allow_netlink_events)
> +		return -ENODEV;
> +
>  	/* allocate memory */
>  	size = nla_total_size(sizeof(struct thermal_genl_event)) +
>  	       nla_total_size(0);
> @@ -1533,16 +1538,18 @@ EXPORT_SYMBOL_GPL(thermal_generate_netlink_event);
>  
>  static int __init genetlink_init(void)
>  {
> -	return genl_register_family(&thermal_event_genl_family);
> -}
> +	int ret;
>  
> -static void genetlink_exit(void)
> -{
> -	genl_unregister_family(&thermal_event_genl_family);
> +	ret = genl_register_family(&thermal_event_genl_family);
> +	if (!ret)
> +		allow_netlink_events = true;
> +	return ret;
>  }
> +
>  #else /* !CONFIG_NET */
>  static inline int genetlink_init(void) { return 0; }
> -static inline void genetlink_exit(void) {}
> +static inline int thermal_generate_netlink_event(struct thermal_zone_device *tz,
> +						 enum events event) { return -ENODEV; }
>  #endif /* !CONFIG_NET */
>  
>  static int thermal_pm_notify(struct notifier_block *nb,
> @@ -1591,19 +1598,15 @@ static int __init thermal_init(void)
>  	mutex_init(&poweroff_lock);
>  	result = thermal_register_governors();
>  	if (result)
> -		goto error;
> +		goto init_exit;
>  
>  	result = class_register(&thermal_class);
>  	if (result)
>  		goto unregister_governors;
>  
> -	result = genetlink_init();
> -	if (result)
> -		goto unregister_class;
> -
>  	result = of_parse_thermal_zones();
>  	if (result)
> -		goto exit_netlink;
> +		goto exit_zone_parse;
>  
>  	result = register_pm_notifier(&thermal_pm_nb);
>  	if (result)
> @@ -1612,13 +1615,11 @@ static int __init thermal_init(void)
>  
>  	return 0;
>  
> -exit_netlink:
> -	genetlink_exit();
> -unregister_class:
> +exit_zone_parse:
>  	class_unregister(&thermal_class);
>  unregister_governors:
>  	thermal_unregister_governors();
> -error:
> +init_exit:
>  	ida_destroy(&thermal_tz_ida);
>  	ida_destroy(&thermal_cdev_ida);
>  	mutex_destroy(&thermal_list_lock);
> @@ -1626,4 +1627,10 @@ static int __init thermal_init(void)
>  	mutex_destroy(&poweroff_lock);
>  	return result;
>  }
> -fs_initcall(thermal_init);
> +
> +static int __init thermal_netlink_init(void)
> +{
> +	return genetlink_init();
> +}
> +core_initcall(thermal_init);
> +fs_initcall(thermal_netlink_init);
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
@ 2019-09-17  8:17   ` Viresh Kumar
  2019-09-17  9:34   ` Sudeep Holla
  2019-09-17 12:48   ` Daniel Lezcano
  2 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2019-09-17  8:17 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Zhang Rui, linux-pm

On 12-09-19, 04:02, Amit Kucheria wrote:
> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> subsystems are initialised in core_initcall so we get earlier access to
> thermal mitigation.
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 4b0b50403901..04676cc82ba6 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
>  {
>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
>  }
> -device_initcall(qcom_cpufreq_hw_init);
> +postcore_initcall(qcom_cpufreq_hw_init);

Even core_initcall should work just fine because of the ordering in
the Makefile in cpufreq directory.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/5] cpufreq: Initialise the governors in core_initcall
  2019-09-11 22:32 ` [PATCH 2/5] cpufreq: Initialise the governors in core_initcall Amit Kucheria
@ 2019-09-17  8:17   ` Viresh Kumar
  0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2019-09-17  8:17 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Zhang Rui, linux-pm

On 12-09-19, 04:02, Amit Kucheria wrote:
> Initialise the cpufreq governors earlier to allow for earlier
> performance control during the boot process.
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  drivers/cpufreq/cpufreq_conservative.c | 2 +-
>  drivers/cpufreq/cpufreq_ondemand.c     | 2 +-
>  drivers/cpufreq/cpufreq_performance.c  | 2 +-
>  drivers/cpufreq/cpufreq_powersave.c    | 2 +-
>  drivers/cpufreq/cpufreq_userspace.c    | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier
  2019-09-11 22:32 ` [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier Amit Kucheria
@ 2019-09-17  8:18   ` Viresh Kumar
  0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2019-09-17  8:18 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Daniel Lezcano,
	Zhang Rui, linux-pm

On 12-09-19, 04:02, Amit Kucheria wrote:
> This allows HW drivers that depend on cpufreq-dt to initialise earlier.
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 1/5] thermal: Initialize thermal subsystem earlier
  2019-09-16 20:00   ` Daniel Lezcano
@ 2019-09-17  9:18     ` Amit Kucheria
  2019-09-19 14:13       ` Zhang Rui
  0 siblings, 1 reply; 20+ messages in thread
From: Amit Kucheria @ 2019-09-17  9:18 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Linux Kernel Mailing List, linux-arm-msm, Bjorn Andersson,
	Eduardo Valentin, Andy Gross, Taniya Das, Stephen Boyd,
	Lina Iyer, Rafael J. Wysocki, Viresh Kumar, Zhang Rui,
	Linux PM list

On Tue, Sep 17, 2019 at 1:30 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 12/09/2019 00:32, Amit Kucheria wrote:
> > From: Lina Iyer <ilina@codeaurora.org>
> >
> > Now that the thermal framework is built-in, in order to facilitate
> > thermal mitigation as early as possible in the boot cycle, move the
> > thermal framework initialization to core_initcall.
> >
> > However, netlink initialization happens only as part of subsys_initcall.
> > At this time in the boot process, the userspace is not available yet. So
> > initialize the netlink events later in fs_initcall.
>
> Why not kill directly the netlink part, no one is using it in the kernel?

That's a good point. I wasn't sure if anybody was using it, but I can
remove it completely since no driver seems to be using the
thermal_generate_netlink_event() api.

Regards,
Amit

$ git grep thermal_generate_netlink_event
Documentation/thermal/sysfs-api.rst:just need to call
thermal_generate_netlink_event() with two arguments viz
drivers/thermal/thermal_core.c:int
thermal_generate_netlink_event(struct thermal_zone_device *tz,
drivers/thermal/thermal_core.c:EXPORT_SYMBOL_GPL(thermal_generate_netlink_event);
include/linux/thermal.h:extern int
thermal_generate_netlink_event(struct thermal_zone_device *tz,
include/linux/thermal.h:static inline int
thermal_generate_netlink_event(struct thermal_zone_device *tz,

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
  2019-09-17  8:17   ` Viresh Kumar
@ 2019-09-17  9:34   ` Sudeep Holla
  2019-09-17 12:47     ` Daniel Lezcano
  2019-09-18  9:09     ` Viresh Kumar
  2019-09-17 12:48   ` Daniel Lezcano
  2 siblings, 2 replies; 20+ messages in thread
From: Sudeep Holla @ 2019-09-17  9:34 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Sudeep Holla,
	Daniel Lezcano, Viresh Kumar, Zhang Rui, linux-pm

On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> subsystems are initialised in core_initcall so we get earlier access to
> thermal mitigation.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 4b0b50403901..04676cc82ba6 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
>  {
>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
>  }
> -device_initcall(qcom_cpufreq_hw_init);
> +postcore_initcall(qcom_cpufreq_hw_init);

I am fine with core framework initcall pushed to earlier initcall levels
if required, but for individual/platform specific drivers I am not so
happy to see that.

This goes against the grand plan of single common kernel strategy by
Android moving all drivers as modules. We might decide to make this
a module. Also there are few cpufreq drivers that are modules. Will
they have issues ? If not, why do we need this change at all. Needing
thermal mitigation during boot this earlier is still too much of
expectation, I would rather boot slowly than relying on this feature.

--
Regards,
Sudeep

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-17  9:34   ` Sudeep Holla
@ 2019-09-17 12:47     ` Daniel Lezcano
  2019-09-17 13:05       ` Quentin Perret
  2019-09-17 13:20       ` Sudeep Holla
  2019-09-18  9:09     ` Viresh Kumar
  1 sibling, 2 replies; 20+ messages in thread
From: Daniel Lezcano @ 2019-09-17 12:47 UTC (permalink / raw)
  To: Sudeep Holla, Amit Kucheria
  Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval, agross,
	tdas, swboyd, ilina, Rafael J. Wysocki, Viresh Kumar, Zhang Rui,
	linux-pm


Hi Sudeep,

On 17/09/2019 11:34, Sudeep Holla wrote:
> On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
>> Allow qcom-hw driver to initialise right after the cpufreq and thermal
>> subsystems are initialised in core_initcall so we get earlier access to
>> thermal mitigation.
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
>> ---
>>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
>> index 4b0b50403901..04676cc82ba6 100644
>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
>>  {
>>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
>>  }
>> -device_initcall(qcom_cpufreq_hw_init);
>> +postcore_initcall(qcom_cpufreq_hw_init);
> 
> I am fine with core framework initcall pushed to earlier initcall levels
> if required, but for individual/platform specific drivers I am not so
> happy to see that.
> 
> This goes against the grand plan of single common kernel strategy by
> Android moving all drivers as modules. We might decide to make this
> a module. 

module = mounted file system = very late initialization

Is that the plan? Force every driver to load too late?

There are core drivers which must be loaded as soon as possible. If the
qcom driver is one of them, then what is the problem?

"The grand plan" will have to solve this first before doing the module
move.

> Also there are few cpufreq drivers that are modules. Will
> they have issues ? If not, why do we need this change at all.

Because some boards don't have thermal issues with the cpufreq drivers
as module, other boards have.

> Needing
> thermal mitigation during boot this earlier is still too much of
> expectation, I would rather boot slowly than relying on this feature.

And what if we want to boot faster? The boot time is one of a key point
of benchmark.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
  2019-09-17  8:17   ` Viresh Kumar
  2019-09-17  9:34   ` Sudeep Holla
@ 2019-09-17 12:48   ` Daniel Lezcano
  2 siblings, 0 replies; 20+ messages in thread
From: Daniel Lezcano @ 2019-09-17 12:48 UTC (permalink / raw)
  To: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Viresh Kumar, Zhang Rui
  Cc: linux-pm

On 12/09/2019 00:32, Amit Kucheria wrote:
> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> subsystems are initialised in core_initcall so we get earlier access to
> thermal mitigation.
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>

Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 4b0b50403901..04676cc82ba6 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
>  {
>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
>  }
> -device_initcall(qcom_cpufreq_hw_init);
> +postcore_initcall(qcom_cpufreq_hw_init);
>  
>  static void __exit qcom_cpufreq_hw_exit(void)
>  {
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-17 12:47     ` Daniel Lezcano
@ 2019-09-17 13:05       ` Quentin Perret
  2019-09-17 13:20       ` Sudeep Holla
  1 sibling, 0 replies; 20+ messages in thread
From: Quentin Perret @ 2019-09-17 13:05 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Sudeep Holla, Amit Kucheria, linux-kernel, linux-arm-msm,
	bjorn.andersson, edubezval, agross, tdas, swboyd, ilina,
	Rafael J. Wysocki, Viresh Kumar, Zhang Rui, linux-pm

Hi Daniel

On Tuesday 17 Sep 2019 at 14:47:22 (+0200), Daniel Lezcano wrote:
> 
> Hi Sudeep,
> 
> On 17/09/2019 11:34, Sudeep Holla wrote:
> > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> >> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> >> subsystems are initialised in core_initcall so we get earlier access to
> >> thermal mitigation.
> >>
> >> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> >> ---
> >>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> index 4b0b50403901..04676cc82ba6 100644
> >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
> >>  {
> >>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
> >>  }
> >> -device_initcall(qcom_cpufreq_hw_init);
> >> +postcore_initcall(qcom_cpufreq_hw_init);
> > 
> > I am fine with core framework initcall pushed to earlier initcall levels
> > if required, but for individual/platform specific drivers I am not so
> > happy to see that.
> > 
> > This goes against the grand plan of single common kernel strategy by
> > Android moving all drivers as modules. We might decide to make this
> > a module. 
> 
> module = mounted file system = very late initialization
> 
> Is that the plan? Force every driver to load too late?
> 
> There are core drivers which must be loaded as soon as possible. If the
> qcom driver is one of them, then what is the problem?
> 
> "The grand plan" will have to solve this first before doing the module
> move.
> 
> > Also there are few cpufreq drivers that are modules. Will
> > they have issues ? If not, why do we need this change at all.
> 
> Because some boards don't have thermal issues with the cpufreq drivers
> as module, other boards have.
> 
> > Needing
> > thermal mitigation during boot this earlier is still too much of
> > expectation, I would rather boot slowly than relying on this feature.
> 
> And what if we want to boot faster? The boot time is one of a key point
> of benchmark.

Could you share test results for this ? It'd be nice to see what if
the gains in boot time outweight the additional pain for android folks
...

Thanks,
Quentin

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-17 12:47     ` Daniel Lezcano
  2019-09-17 13:05       ` Quentin Perret
@ 2019-09-17 13:20       ` Sudeep Holla
  2019-09-20 20:03         ` Amit Kucheria
  1 sibling, 1 reply; 20+ messages in thread
From: Sudeep Holla @ 2019-09-17 13:20 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Sudeep Holla, Viresh Kumar, Zhang Rui, linux-pm

On Tue, Sep 17, 2019 at 02:47:22PM +0200, Daniel Lezcano wrote:
>
> Hi Sudeep,
>
> On 17/09/2019 11:34, Sudeep Holla wrote:
> > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> >> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> >> subsystems are initialised in core_initcall so we get earlier access to
> >> thermal mitigation.
> >>
> >> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> >> ---
> >>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> index 4b0b50403901..04676cc82ba6 100644
> >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
> >>  {
> >>  	return platform_driver_register(&qcom_cpufreq_hw_driver);
> >>  }
> >> -device_initcall(qcom_cpufreq_hw_init);
> >> +postcore_initcall(qcom_cpufreq_hw_init);
> >
> > I am fine with core framework initcall pushed to earlier initcall levels
> > if required, but for individual/platform specific drivers I am not so
> > happy to see that.
> >
> > This goes against the grand plan of single common kernel strategy by
> > Android moving all drivers as modules. We might decide to make this
> > a module.
>
> module = mounted file system = very late initialization
>
> Is that the plan? Force every driver to load too late?
>

Yes. Something similar to what we have on desktops/servers.

> There are core drivers which must be loaded as soon as possible. If the
> qcom driver is one of them, then what is the problem?
>

I am fine with that if it's really issue but it shouldn't become the
defacto trend.

> "The grand plan" will have to solve this first before doing the module
> move.
>

Sure, I just expressed my view as it looks to be going in different
direction for me.

> > Also there are few cpufreq drivers that are modules. Will
> > they have issues ? If not, why do we need this change at all.
>
> Because some boards don't have thermal issues with the cpufreq drivers
> as module, other boards have.
>

OK, so this platform boots with default high OPP and needs thermal
mitigation that early ? If so, that's fine.

> > Needing
> > thermal mitigation during boot this earlier is still too much of
> > expectation, I would rather boot slowly than relying on this feature.
>
> And what if we want to boot faster? The boot time is one of a key point
> of benchmark.
>

I understand the requirement, though for me it's really sounds stupid.

As Quentin pointed out, it would be good to get all those benchmark
details, and preferably in the commit log so that we can look back
whenever someone else take the same approach later.

--
Regards,
Sudeep

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-17  9:34   ` Sudeep Holla
  2019-09-17 12:47     ` Daniel Lezcano
@ 2019-09-18  9:09     ` Viresh Kumar
  2019-09-18  9:17       ` Sudeep Holla
  1 sibling, 1 reply; 20+ messages in thread
From: Viresh Kumar @ 2019-09-18  9:09 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, linux-pm

On 17-09-19, 10:34, Sudeep Holla wrote:
> On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> > -device_initcall(qcom_cpufreq_hw_init);
> > +postcore_initcall(qcom_cpufreq_hw_init);
> 
> I am fine with core framework initcall pushed to earlier initcall levels
> if required, but for individual/platform specific drivers I am not so
> happy to see that.
> 
> This goes against the grand plan of single common kernel strategy by
> Android moving all drivers as modules.

Its been long that I got the opportunity to work on drivers directly, but as far
as I remember (which should be incorrect based on your reply) we can still build
a driver as module even if it has some postcore_initcall() declarations. They
will execute at module insertion. Is that incorrect ? If not, then how is it
going to affect android effort ?

-- 
viresh

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-18  9:09     ` Viresh Kumar
@ 2019-09-18  9:17       ` Sudeep Holla
  2019-09-18  9:29         ` Viresh Kumar
  0 siblings, 1 reply; 20+ messages in thread
From: Sudeep Holla @ 2019-09-18  9:17 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, linux-pm

On Wed, Sep 18, 2019 at 02:39:38PM +0530, Viresh Kumar wrote:
> On 17-09-19, 10:34, Sudeep Holla wrote:
> > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> > > -device_initcall(qcom_cpufreq_hw_init);
> > > +postcore_initcall(qcom_cpufreq_hw_init);
> >
> > I am fine with core framework initcall pushed to earlier initcall levels
> > if required, but for individual/platform specific drivers I am not so
> > happy to see that.
> >
> > This goes against the grand plan of single common kernel strategy by
> > Android moving all drivers as modules.
>
> Its been long that I got the opportunity to work on drivers directly, but as far
> as I remember (which should be incorrect based on your reply) we can still build
> a driver as module even if it has some postcore_initcall() declarations. They
> will execute at module insertion. Is that incorrect ? If not, then how is it
> going to affect android effort ?
>

Ah no, I am not referring to building as module. As you mention, that may
work just fine. I was referring to timing dependency during boot. The idea
is minimize the number of such initcall dependency. They should all work
fine even as modules and should have least dependency on initcall sequence.

--
Regards,
Sudeep

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-18  9:17       ` Sudeep Holla
@ 2019-09-18  9:29         ` Viresh Kumar
  0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2019-09-18  9:29 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: Amit Kucheria, linux-kernel, linux-arm-msm, bjorn.andersson,
	edubezval, agross, tdas, swboyd, ilina, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, linux-pm

On 18-09-19, 10:17, Sudeep Holla wrote:
> Ah no, I am not referring to building as module. As you mention, that may
> work just fine. I was referring to timing dependency during boot. The idea
> is minimize the number of such initcall dependency. They should all work
> fine even as modules and should have least dependency on initcall sequence.

Yeah, so things work fine for them right now but that can be improved by
changing the sequence of boot here. And that's what Amit is trying to do here.

Even if android builds this as a module later, things will continue to work but
that may not be the best performance/boot-time wise.

When I had a discussion about this with Amit earlier, I asked him to send
patches even if he doesn't have any performance numbers for it as this is a
platform driver and I find it okay for them to decide the boot sequence that
they think is the best :)

-- 
viresh

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 1/5] thermal: Initialize thermal subsystem earlier
  2019-09-17  9:18     ` Amit Kucheria
@ 2019-09-19 14:13       ` Zhang Rui
  0 siblings, 0 replies; 20+ messages in thread
From: Zhang Rui @ 2019-09-19 14:13 UTC (permalink / raw)
  To: Amit Kucheria, Daniel Lezcano
  Cc: Linux Kernel Mailing List, linux-arm-msm, Bjorn Andersson,
	Eduardo Valentin, Andy Gross, Taniya Das, Stephen Boyd,
	Lina Iyer, Rafael J. Wysocki, Viresh Kumar, Linux PM list

On Tue, 2019-09-17 at 14:48 +0530, Amit Kucheria wrote:
> On Tue, Sep 17, 2019 at 1:30 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> > 
> > On 12/09/2019 00:32, Amit Kucheria wrote:
> > > From: Lina Iyer <ilina@codeaurora.org>
> > > 
> > > Now that the thermal framework is built-in, in order to
> > > facilitate
> > > thermal mitigation as early as possible in the boot cycle, move
> > > the
> > > thermal framework initialization to core_initcall.
> > > 
> > > However, netlink initialization happens only as part of
> > > subsys_initcall.
> > > At this time in the boot process, the userspace is not available
> > > yet. So
> > > initialize the netlink events later in fs_initcall.
> > 
> > Why not kill directly the netlink part, no one is using it in the
> > kernel?
> 
> That's a good point. I wasn't sure if anybody was using it, but I can
> remove it completely since no driver seems to be using the
> thermal_generate_netlink_event() api.

Interesting, I recalled that thermal_generate_netlink_event() is indeed
used by some thermal driver, but it's true that no one is using it now.

let's remove it and see if we get any complains.

thanks,
rui
> 
> Regards,
> Amit
> 
> $ git grep thermal_generate_netlink_event
> Documentation/thermal/sysfs-api.rst:just need to call
> thermal_generate_netlink_event() with two arguments viz
> drivers/thermal/thermal_core.c:int
> thermal_generate_netlink_event(struct thermal_zone_device *tz,
> drivers/thermal/thermal_core.c:EXPORT_SYMBOL_GPL(thermal_generate_net
> link_event);
> include/linux/thermal.h:extern int
> thermal_generate_netlink_event(struct thermal_zone_device *tz,
> include/linux/thermal.h:static inline int
> thermal_generate_netlink_event(struct thermal_zone_device *tz,


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
  2019-09-17 13:20       ` Sudeep Holla
@ 2019-09-20 20:03         ` Amit Kucheria
  0 siblings, 0 replies; 20+ messages in thread
From: Amit Kucheria @ 2019-09-20 20:03 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: Daniel Lezcano, Linux Kernel Mailing List, linux-arm-msm,
	Bjorn Andersson, Eduardo Valentin, Andy Gross, Taniya Das,
	Stephen Boyd, Lina Iyer, Rafael J. Wysocki, Viresh Kumar,
	Zhang Rui, Linux PM list

Hi Sudeep,

On Tue, Sep 17, 2019 at 6:20 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Tue, Sep 17, 2019 at 02:47:22PM +0200, Daniel Lezcano wrote:
> >
> > Hi Sudeep,
> >
> > On 17/09/2019 11:34, Sudeep Holla wrote:
> > > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> > >> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> > >> subsystems are initialised in core_initcall so we get earlier access to
> > >> thermal mitigation.
> > >>
> > >> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> > >> ---
> > >>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> > >> index 4b0b50403901..04676cc82ba6 100644
> > >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > >> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
> > >>  {
> > >>    return platform_driver_register(&qcom_cpufreq_hw_driver);
> > >>  }
> > >> -device_initcall(qcom_cpufreq_hw_init);
> > >> +postcore_initcall(qcom_cpufreq_hw_init);
> > >
> > > I am fine with core framework initcall pushed to earlier initcall levels
> > > if required, but for individual/platform specific drivers I am not so
> > > happy to see that.
> > >
> > > This goes against the grand plan of single common kernel strategy by
> > > Android moving all drivers as modules. We might decide to make this
> > > a module.
> >
> > module = mounted file system = very late initialization
> >
> > Is that the plan? Force every driver to load too late?
> >
>
> Yes. Something similar to what we have on desktops/servers.
>
> > There are core drivers which must be loaded as soon as possible. If the
> > qcom driver is one of them, then what is the problem?
> >
>
> I am fine with that if it's really issue but it shouldn't become the
> defacto trend.

I didn't convert other HW drivers on purpose since it's really up to
the platform to decide. I have tested with all drivers converted to
core_initcall and didn't find any boot issues on kernelci.

> > "The grand plan" will have to solve this first before doing the module
> > move.
> >
>
> Sure, I just expressed my view as it looks to be going in different
> direction for me.
>
> > > Also there are few cpufreq drivers that are modules. Will
> > > they have issues ? If not, why do we need this change at all.
> >
> > Because some boards don't have thermal issues with the cpufreq drivers
> > as module, other boards have.
> >
>
> OK, so this platform boots with default high OPP and needs thermal
> mitigation that early ? If so, that's fine.

That is indeed the case - 30-40 degree rise in under 50ms can be seen
on some of these platforms.

> > > Needing
> > > thermal mitigation during boot this earlier is still too much of
> > > expectation, I would rather boot slowly than relying on this feature.
> >
> > And what if we want to boot faster? The boot time is one of a key point
> > of benchmark.
> >
>
> I understand the requirement, though for me it's really sounds stupid.

Is it stupid if the SoC was being used in automotive with a 2s (or
less) startup requirement? :-)

> As Quentin pointed out, it would be good to get all those benchmark
> details, and preferably in the commit log so that we can look back
> whenever someone else take the same approach later.

I'm traveling for Connect this week but will try to post some logs
with initcall_debug turned on where changing these initcalls shaves
off several seconds. Just to reassure everyone that GKI isn't
forgotten, the next set of patches will actually add module support
for the tsens driver so AOSP can make them modules and things will
still work.

Regards,
Amit

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, back to index

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-11 22:32 [PATCH 0/5] Initialise thermal framework earlier during boot Amit Kucheria
2019-09-11 22:32 ` [PATCH 1/5] thermal: Initialize thermal subsystem earlier Amit Kucheria
2019-09-16 20:00   ` Daniel Lezcano
2019-09-17  9:18     ` Amit Kucheria
2019-09-19 14:13       ` Zhang Rui
2019-09-11 22:32 ` [PATCH 2/5] cpufreq: Initialise the governors in core_initcall Amit Kucheria
2019-09-17  8:17   ` Viresh Kumar
2019-09-11 22:32 ` [PATCH 3/5] cpufreq: Initialize cpufreq-dt driver earlier Amit Kucheria
2019-09-17  8:18   ` Viresh Kumar
2019-09-11 22:32 ` [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier Amit Kucheria
2019-09-17  8:17   ` Viresh Kumar
2019-09-17  9:34   ` Sudeep Holla
2019-09-17 12:47     ` Daniel Lezcano
2019-09-17 13:05       ` Quentin Perret
2019-09-17 13:20       ` Sudeep Holla
2019-09-20 20:03         ` Amit Kucheria
2019-09-18  9:09     ` Viresh Kumar
2019-09-18  9:17       ` Sudeep Holla
2019-09-18  9:29         ` Viresh Kumar
2019-09-17 12:48   ` Daniel Lezcano

Linux-PM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pm/0 linux-pm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pm linux-pm/ https://lore.kernel.org/linux-pm \
		linux-pm@vger.kernel.org linux-pm@archiver.kernel.org
	public-inbox-index linux-pm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox