Linux Power Management development
 help / color / mirror / Atom feed
* Re: [PATCH v3 4/6] thermal: tsens: Add support for SDM845
From: Rob Herring @ 2018-06-14 14:21 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: linux-kernel@vger.kernel.org, Rajendra Nayak, linux-arm-msm,
	Bjorn Andersson, Eduardo Valentin, Siddartha Mohanadoss,
	Vivek Gautam, Andy Gross, Zhang Rui, Mark Rutland, David Brown,
	Catalin Marinas, Will Deacon, Kees Cook, open list:THERMAL,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <0cdd0957cf80c2f9921928755722a427c7309964.1528972165.git.amit.kucheria@linaro.org>

On Thu, Jun 14, 2018 at 4:43 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> SDM845 uses the TSENS v2 IP block
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 1 +
>  arch/arm64/boot/dts/qcom/msm8996.dtsi                    | 2 +-
>  drivers/thermal/qcom/tsens-v2.c                          | 9 ++++++++-
>  drivers/thermal/qcom/tsens.c                             | 3 +++
>  drivers/thermal/qcom/tsens.h                             | 5 ++++-
>  5 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 06195e8..84da3db 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
>   - "qcom,msm8916-tsens" : For 8916 Family of SoCs
>   - "qcom,msm8974-tsens" : For 8974 Family of SoCs
>   - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,tsens-v2"      : For any SoC with v2 version of the tsens IP

Stick with "qcom,sdm845-tsens". Though perhaps it should be
'"qcom,sdm845-tsens", "qcom,msm8996-tsens"' if there is compatibility.

>
>  - reg: Address range of the thermal registers
>  - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 6c8a857..28d4c08 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -460,7 +460,7 @@
>                 };
>
>                 tsens0: thermal-sensor@4a8000 {
> -                       compatible = "qcom,msm8996-tsens";
> +                       compatible = "qcom,msm8996-tsens", "qcom,tsens-v2";

There's no point to adding this now because you already have to
support "qcom,msm8996-tsens".

>                         reg = <0x4a9000 0x1000>, /* TM */
>                               <0x4a8000 0x1000>; /* SROT */
>                         #qcom,sensors = <13>;
> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index c981a40..abc8f13 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -69,8 +69,15 @@ static const struct tsens_ops ops_v2 = {
>         .get_temp       = get_temp_tsens_v2,
>  };
>
> +const struct tsens_data data_tsens_v2 = {
> +       .ops            = &ops_v2,
> +};
> +
> +/* Kept around for backward compatibility with old msm8996.dtsi.
> + * New platforms should use data_tsens_v2 if possible and define
> + * the #qcom,sensors property in DT.

Hum, I think this should just be implied by the compatible as it was.
If this was the *only* difference, then a property would be okay, but
as soon as you find some other difference you need yet another
property and have to do a DT update on all platforms.

> + */
>  const struct tsens_data data_8996 = {
>         .num_sensors    = 13,
>         .ops            = &ops_v2,
>  };
> -
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3440166c..a2c9bfa 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -72,6 +72,9 @@ static const struct of_device_id tsens_table[] = {
>         }, {
>                 .compatible = "qcom,msm8996-tsens",
>                 .data = &data_8996,
> +       }, {
> +               .compatible = "qcom,tsens-v2",
> +               .data = &data_tsens_v2,

Why different data if 8996 is compatible with v2?

>         },
>         {}
>  };
> diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
> index dc56e1e..69212cb 100644
> --- a/drivers/thermal/qcom/tsens.h
> +++ b/drivers/thermal/qcom/tsens.h
> @@ -87,6 +87,9 @@ void compute_intercept_slope(struct tsens_device *, u32 *, u32 *, u32);
>  int init_common(struct tsens_device *);
>  int get_temp_common(struct tsens_device *, int, int *);
>
> -extern const struct tsens_data data_8916, data_8974, data_8960, data_8996;
> +/* TSENS v1 targets */
> +extern const struct tsens_data data_8916, data_8974, data_8960;
> +/* TSENS v2 targets */
> +extern const struct tsens_data data_8996, data_tsens_v2;
>
>  #endif /* __QCOM_TSENS_H__ */
> --
> 2.7.4
>

^ permalink raw reply

* Re: [PATCH v6 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
From: Linus Walleij @ 2018-06-14 14:06 UTC (permalink / raw)
  To: Craig Tatlor
  Cc: linux-arm-msm, Sebastian Reichel, Rob Herring, Mark Rutland,
	Mauro Carvalho Chehab, David S. Miller, Andrew Morton,
	Greg Kroah-Hartman, Randy Dunlap, Linux PM list,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel@vger.kernel.org
In-Reply-To: <20180613160643.12638-2-ctatlor97@gmail.com>

On Wed, Jun 13, 2018 at 6:06 PM, Craig Tatlor <ctatlor97@gmail.com> wrote:

> This patch adds a driver for the BMS (Battery Monitoring System)
> block of the PM8941 PMIC, it uses a lookup table defined in the
> device tree to generate a capacity from the BMS supplied OCV, it
> then amends the coulomb counter to that to increase the accuracy
> of the estimated capacity.
>
> Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> ---
>
> * Changes from v5:
>   Uses select for REGMAP_SPMI.

Looks very nice to me!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH 4.9 19/30] serial: sh-sci: Stop using printk format %pCr
From: Greg Kroah-Hartman @ 2018-06-14 14:05 UTC (permalink / raw)
  To: linux-kernel, Jia-Ju Bai, Jonathan Corbet, Michael Turquette,
	Stephen Boyd, Zhang Rui, Eduardo Valentin, Eric Anholt,
	Stefan Wahren
  Cc: Greg Kroah-Hartman, stable, Sergey Senozhatsky, Petr Mladek,
	Linus Torvalds, Steven Rostedt, linux-doc, linux-clk, linux-pm,
	linux-serial, linux-arm-kernel, linux-renesas-soc,
	Geert Uytterhoeven
In-Reply-To: <20180614132600.255515394@linuxfoundation.org>

4.9-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/sh-sci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2626,8 +2626,8 @@ found:
 			dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
 				PTR_ERR(clk));
 		else
-			dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
-				clk, clk);
+			dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+				clk, clk_get_rate(clk));
 		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
 	}
 	return 0;

^ permalink raw reply

* [PATCH 4.14 18/36] serial: sh-sci: Stop using printk format %pCr
From: Greg Kroah-Hartman @ 2018-06-14 14:04 UTC (permalink / raw)
  To: linux-kernel, Jia-Ju Bai, Jonathan Corbet, Michael Turquette,
	Stephen Boyd, Zhang Rui, Eduardo Valentin, Eric Anholt,
	Stefan Wahren
  Cc: Petr Mladek, Sergey Senozhatsky, Geert Uytterhoeven, linux-doc,
	Greg Kroah-Hartman, linux-pm, Steven Rostedt, linux-renesas-soc,
	stable, linux-serial, Linus Torvalds, linux-clk, linux-arm-kernel
In-Reply-To: <20180614132157.333004166@linuxfoundation.org>

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/sh-sci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2669,8 +2669,8 @@ found:
 			dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
 				PTR_ERR(clk));
 		else
-			dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
-				clk, clk);
+			dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+				clk, clk_get_rate(clk));
 		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
 	}
 	return 0;

^ permalink raw reply

* [PATCH 4.16 25/43] serial: sh-sci: Stop using printk format %pCr
From: Greg Kroah-Hartman @ 2018-06-14 14:04 UTC (permalink / raw)
  To: linux-kernel, Jia-Ju Bai, Jonathan Corbet, Michael Turquette,
	Stephen Boyd, Zhang Rui, Eduardo Valentin, Eric Anholt,
	Stefan Wahren
  Cc: Petr Mladek, Sergey Senozhatsky, Geert Uytterhoeven, linux-doc,
	Greg Kroah-Hartman, linux-pm, Steven Rostedt, linux-renesas-soc,
	stable, linux-serial, Linus Torvalds, linux-clk, linux-arm-kernel
In-Reply-To: <20180614132135.111973468@linuxfoundation.org>

4.16-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/sh-sci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2691,8 +2691,8 @@ found:
 			dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
 				PTR_ERR(clk));
 		else
-			dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
-				clk, clk);
+			dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+				clk, clk_get_rate(clk));
 		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
 	}
 	return 0;

^ permalink raw reply

* [PATCH 4.17 25/45] serial: sh-sci: Stop using printk format %pCr
From: Greg Kroah-Hartman @ 2018-06-14 14:04 UTC (permalink / raw)
  To: linux-kernel, Jia-Ju Bai, Jonathan Corbet, Michael Turquette,
	Stephen Boyd, Zhang Rui, Eduardo Valentin, Eric Anholt,
	Stefan Wahren
  Cc: Greg Kroah-Hartman, stable, Sergey Senozhatsky, Petr Mladek,
	Linus Torvalds, Steven Rostedt, linux-doc, linux-clk, linux-pm,
	linux-serial, linux-arm-kernel, linux-renesas-soc,
	Geert Uytterhoeven
In-Reply-To: <20180614132126.797006529@linuxfoundation.org>

4.17-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/sh-sci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2704,8 +2704,8 @@ found:
 			dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
 				PTR_ERR(clk));
 		else
-			dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
-				clk, clk);
+			dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+				clk, clk_get_rate(clk));
 		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
 	}
 	return 0;

^ permalink raw reply

* [PATCH] PM / OPP: Update voltage in case freq == old_freq
From: Waldemar Rymarkiewicz @ 2018-06-14 13:56 UTC (permalink / raw)
  To: Viresh Kumar, Nishanth Menon, Stephen Boyd
  Cc: Waldemar Rymarkiewicz, linux-pm, linux-kernel

This commit fixes a rare but possible case when the clk rate is updated
without update of the regulator voltage.

At boot up, CPUfreq checks if the system is running at the right freq. This
is a sanity check in case a bootloader set clk rate that is outside of freq
table present with cpufreq core. In such cases system can be unstable so
better to change it to a freq that is preset in freq-table.

The CPUfreq takes next freq that is >= policy->cur and this is our
target_freq that needs to be set now.

dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
old_freq (a current rate). If these are equal it returns early. If not,
it searches for OPP (old_opp) that fits best to old_freq (not listed in
the table) and updates old_freq (!).

Here, we can end up with old_freq = old_opp.rate = target_freq, which
is not handled in _generic_set_opp_regulator(). It's supposed to update
voltage only when freq > old_freq  || freq > old_freq.

if (freq > old_freq) {
		ret = _set_opp_voltage(dev, reg, new_supply);
[...]
if (freq < old_freq) {
		ret = _set_opp_voltage(dev, reg, new_supply);
		if (ret)

It results in, no voltage update while clk rate is updated.

Example:
freq-table = {
	1000MHz   1.15V
	 666MHZ   1.10V
	 333MHz   1.05V
}
boot-up-freq        = 800MHz   # not listed in freq-table
freq = target_freq  = 1GHz
old_freq            = 800Mhz
old_opp = _find_freq_ceil(opp_table, &old_freq);  #(old_freq is modified!)
old_freq            = 1GHz

Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
---
 drivers/opp/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index ab2f3fe..31ff03d 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -598,7 +598,7 @@ static int _generic_set_opp_regulator(const struct opp_table *opp_table,
 	}
 
 	/* Scaling up? Scale voltage before frequency */
-	if (freq > old_freq) {
+	if (freq >= old_freq) {
 		ret = _set_opp_voltage(dev, reg, new_supply);
 		if (ret)
 			goto restore_voltage;
-- 
2.10.1

^ permalink raw reply related

* Re: [PATCH v4 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Sudeep Holla @ 2018-06-14 10:47 UTC (permalink / raw)
  To: Taniya Das, linux-kernel, linux-pm
  Cc: Sudeep Holla, Rafael J. Wysocki, Viresh Kumar, Stephen Boyd,
	Rajendra Nayak, devicetree, robh, skannan
In-Reply-To: <7abb2da6-c130-117a-5404-d07bb132d915@codeaurora.org>



On 13/06/18 19:13, Taniya Das wrote:
> Hello Sudeep,
> 
> Thanks for review comments.
> 
> On 6/13/2018 4:56 PM, Sudeep Holla wrote:
>>
>>

[...]

>> You are bit inconsistent on the wordings. Some places you refer this as
>> hardware engine. If so, please drop all references to firmware/FW. If
>> it's firmware then update accordingly.
>>
> 
> It is a hardware engine which has a firmware to take care of the
> managing the frequency request from OS. That is reason to refer it as a
> firmware.
> 

Yes I did guess that initially, but I failed to understand when
different bindings were posted to deal with devfreq and cpufreq with the
same firmware. Ideally if it's the firmware you are talking to, place
all these under /firmware node and align all those with single binding.

Is there anything else that this firmware deals with ? If so all those
need to be put in one place.

>>> +Properties:
>>> +- compatible
>>> +    Usage:        required
>>> +    Value type:    <string>
>>> +    Definition:    must be "qcom,cpufreq-fw".
>>> +
>>> +* Property qcom,freq-domain
>>> +Devices supporting freq-domain must set their "qcom,freq-domain"
>>> property with
>>> +phandle to a freq_domain_table in their DT node.
>>> +
>>> +* Frequency Domain Table Node
>>> +
>>> +This describes the frequency domain belonging to a device.
>>> +This node can have following properties:
>>> +
>>> +- reg
>>> +    Usage:        required
>>> +    Value type:    <prop-encoded-array>
>>> +    Definition:    Addresses and sizes for the memory of the perf
>>> +            , lut and enable bases.
>>> +            perf - indicates the base address for the desired
>>> +            performance state to be set.
>>> +            lut - indicates the look up table base address for the
>>> +            cpufreq    driver to read frequencies.
>>> +            enable - indicates the enable register for firmware.
>>
>>
>> You still didn't answer my earlier question.
>>
>> OS might touch one or 2 registers in lots of IP blocks. I am not sure
>> why those are any different from these. Are you trying to align with any
>> other bindings or specification. Are you trying to make this binding
>> generic here ? I understand if it was trying to generalize the firmware
>> interface, but you also state it's a hardware engine. So I fail to see
>> the need for such specificity here. Why not define the whole IP block
>> and the driver knows where to access these specific ones as they are
>> specific to this hardware block. In that way if you decide to add more
>> data, it's extensible easily without the need for patching DT.
>>
> 
> Sorry Sudeep I missed replying to your earlier query.
> The High level OS(HLOS) would require to access only these specific
> registers from this IP block and just mapping the whole block(huge
> region) is unnecessary from the OS point of View. As of now it is a
> generic binding for all using this IP block to manage frequency
> requests. The OS would only have to know the frequencies supported i.e
> to read the lookup table registers and put across the OS request using
> the performance state register.
> 

I am not sure if you need to defining bindings to save OSPM IO mapping.
In-fact you may be adding more mapping unnecessarily. The mappings are
page aligned and spiting the registers and mapping them individually may
result in more mappings.

I just need to know the rational for such specific choice of registers.
I assume it's aligned to some other standard specifications like CPPC
though not identical.

>> Eg. Suppose you need some information on power curve for EAS energy
>> model, I really hate to update DT for that or even do a mix with DT just
>> because f/w is no longer modifiable.
>>
> 
> For now we are safe.
> 

What do you mean by that ? It should be easily extensible is what I am
trying to say. You can add more info and alter the information in the
driver with compatibles if you keep the register info as minimum as
possible. For now, you have enable, set and lut registers. What if you
want to provide power numbers ?

-- 
Regards,
Sudeep

^ permalink raw reply

* [PATCH v3 5/6] thermal: tsens: Check if we have valid data before reading
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: rnayak, linux-arm-msm, bjorn.andersson, edubezval, smohanad,
	vivek.gautam, andy.gross, Zhang Rui, open list:THERMAL
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/thermal/qcom/tsens-v2.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index abc8f13..76fb668 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -7,6 +7,9 @@
 #include <linux/regmap.h>
 #include "tsens.h"
 
+#define TRDY_OFFSET            0xe4
+#define TRDY_READY_BIT         BIT(0)
+
 #define STATUS_OFFSET		0xa0
 #define LAST_TEMP_MASK		0xfff
 #define STATUS_VALID_BIT	BIT(21)
@@ -19,6 +22,12 @@ static int get_temp_tsens_v2(struct tsens_device *tmdev, int id, int *temp)
 	unsigned int sensor_addr;
 	int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
 
+	ret = regmap_read(tmdev->map, TRDY_OFFSET, &code);
+	if (ret)
+		return ret;
+	if (code & TRDY_READY_BIT)
+		return -ENODATA;
+
 	sensor_addr = STATUS_OFFSET + s->hw_id * 4;
 	ret = regmap_read(tmdev->map, sensor_addr, &code);
 	if (ret)
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 4/6] thermal: tsens: Add support for SDM845
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: rnayak, linux-arm-msm, bjorn.andersson, edubezval, smohanad,
	vivek.gautam, andy.gross, Zhang Rui, Rob Herring, Mark Rutland,
	David Brown, Catalin Marinas, Will Deacon, Kees Cook,
	open list:THERMAL,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list:ARM/QUALCOMM SUPPORT,
	moderated list:ARM64 PORT AARCH64 ARCHITECTURE
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>

SDM845 uses the TSENS v2 IP block

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 1 +
 arch/arm64/boot/dts/qcom/msm8996.dtsi                    | 2 +-
 drivers/thermal/qcom/tsens-v2.c                          | 9 ++++++++-
 drivers/thermal/qcom/tsens.c                             | 3 +++
 drivers/thermal/qcom/tsens.h                             | 5 ++++-
 5 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
index 06195e8..84da3db 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
@@ -5,6 +5,7 @@ Required properties:
  - "qcom,msm8916-tsens" : For 8916 Family of SoCs
  - "qcom,msm8974-tsens" : For 8974 Family of SoCs
  - "qcom,msm8996-tsens" : For 8996 Family of SoCs
+ - "qcom,tsens-v2"      : For any SoC with v2 version of the tsens IP
 
 - reg: Address range of the thermal registers
 - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 6c8a857..28d4c08 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -460,7 +460,7 @@
 		};
 
 		tsens0: thermal-sensor@4a8000 {
-			compatible = "qcom,msm8996-tsens";
+			compatible = "qcom,msm8996-tsens", "qcom,tsens-v2";
 			reg = <0x4a9000 0x1000>, /* TM */
 			      <0x4a8000 0x1000>; /* SROT */
 			#qcom,sensors = <13>;
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index c981a40..abc8f13 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -69,8 +69,15 @@ static const struct tsens_ops ops_v2 = {
 	.get_temp	= get_temp_tsens_v2,
 };
 
+const struct tsens_data data_tsens_v2 = {
+	.ops            = &ops_v2,
+};
+
+/* Kept around for backward compatibility with old msm8996.dtsi.
+ * New platforms should use data_tsens_v2 if possible and define
+ * the #qcom,sensors property in DT.
+ */
 const struct tsens_data data_8996 = {
 	.num_sensors	= 13,
 	.ops		= &ops_v2,
 };
-
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 3440166c..a2c9bfa 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -72,6 +72,9 @@ static const struct of_device_id tsens_table[] = {
 	}, {
 		.compatible = "qcom,msm8996-tsens",
 		.data = &data_8996,
+	}, {
+		.compatible = "qcom,tsens-v2",
+		.data = &data_tsens_v2,
 	},
 	{}
 };
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index dc56e1e..69212cb 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -87,6 +87,9 @@ void compute_intercept_slope(struct tsens_device *, u32 *, u32 *, u32);
 int init_common(struct tsens_device *);
 int get_temp_common(struct tsens_device *, int, int *);
 
-extern const struct tsens_data data_8916, data_8974, data_8960, data_8996;
+/* TSENS v1 targets */
+extern const struct tsens_data data_8916, data_8974, data_8960;
+/* TSENS v2 targets */
+extern const struct tsens_data data_8996, data_tsens_v2;
 
 #endif /* __QCOM_TSENS_H__ */
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 3/6] thermal: tsens: Rename tsens-8996 to tsens-v2 for reuse
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: rnayak, linux-arm-msm, bjorn.andersson, edubezval, smohanad,
	vivek.gautam, andy.gross, Zhang Rui, open list:THERMAL
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>

The TSENS block inside the 8996 is internally classified as version 2 of
the IP. Several other SoC families use this block and can share this code.

Also, rename get_temp() to reflect that it can be used across the v2 family.

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
 drivers/thermal/qcom/Makefile                     |  2 +-
 drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} | 26 ++++++++---------------
 2 files changed, 10 insertions(+), 18 deletions(-)
 rename drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} (66%)

diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
index 2cc2193..a821929 100644
--- a/drivers/thermal/qcom/Makefile
+++ b/drivers/thermal/qcom/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_QCOM_TSENS)	+= qcom_tsens.o
-qcom_tsens-y			+= tsens.o tsens-common.o tsens-8916.o tsens-8974.o tsens-8960.o tsens-8996.o
+qcom_tsens-y			+= tsens.o tsens-common.o tsens-8916.o tsens-8974.o tsens-8960.o tsens-v2.o
diff --git a/drivers/thermal/qcom/tsens-8996.c b/drivers/thermal/qcom/tsens-v2.c
similarity index 66%
rename from drivers/thermal/qcom/tsens-8996.c
rename to drivers/thermal/qcom/tsens-v2.c
index e1f7781..c981a40 100644
--- a/drivers/thermal/qcom/tsens-8996.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -1,27 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (c) 2015, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
+ * Copyright (c) 2018, Linaro Limited
  */
 
-#include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include "tsens.h"
 
-#define STATUS_OFFSET	0x10a0
-#define LAST_TEMP_MASK	0xfff
+#define STATUS_OFFSET		0xa0
+#define LAST_TEMP_MASK		0xfff
 #define STATUS_VALID_BIT	BIT(21)
 #define CODE_SIGN_BIT		BIT(11)
 
-static int get_temp_8996(struct tsens_device *tmdev, int id, int *temp)
+static int get_temp_tsens_v2(struct tsens_device *tmdev, int id, int *temp)
 {
 	struct tsens_sensor *s = &tmdev->sensor[id];
 	u32 code;
@@ -73,12 +64,13 @@ static int get_temp_8996(struct tsens_device *tmdev, int id, int *temp)
 	return 0;
 }
 
-static const struct tsens_ops ops_8996 = {
+static const struct tsens_ops ops_v2 = {
 	.init		= init_common,
-	.get_temp	= get_temp_8996,
+	.get_temp	= get_temp_tsens_v2,
 };
 
 const struct tsens_data data_8996 = {
 	.num_sensors	= 13,
-	.ops		= &ops_8996,
+	.ops		= &ops_v2,
 };
+
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 1/6] thermal: tsens: Get rid of unused fields in structure
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: rnayak, linux-arm-msm, bjorn.andersson, edubezval, smohanad,
	vivek.gautam, andy.gross, Zhang Rui, open list:THERMAL
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>

status_field and trdy are unused in any of the tsens drivers. Remove them.

Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Rajendra Nayak <rnayak@codeaurora.org>
---
 drivers/thermal/qcom/tsens.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index 911c197..dc56e1e 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -77,9 +77,7 @@ struct tsens_device {
 	struct device			*dev;
 	u32				num_sensors;
 	struct regmap			*map;
-	struct regmap_field		*status_field;
 	struct tsens_context		ctx;
-	bool				trdy;
 	const struct tsens_ops		*ops;
 	struct tsens_sensor		sensor[0];
 };
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 0/6] thermal: tsens: Refactoring for TSENSv2 IP
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: rnayak, linux-arm-msm, bjorn.andersson, edubezval, smohanad,
	vivek.gautam, andy.gross, Kees Cook, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	moderated list:ARM64 PORT AARCH64 ARCHITECTURE, open list:THERMAL,
	open list:ARM/QUALCOMM SUPPORT

This series is a mixed bag: Some code moves to deal with v2 of the
TSENS IP into common functions, a new qcom,tsens-v2 DT property to cover
all v2 platforms, new platform support (sdm845), a cleanup
patch and a DT change to have a common way to deal with the SROT and TM
registers despite slightly different features across the IP family and
different register offsets.

Rob, I haven't added your Ack to patch 4 because it changed a bit.

Regards,
Amit

Changes since v2:
- Based on review, moved tsens-8996.c to tsens-v2.c and changed
  corresponding function names, struct names to allow for generic tsensv2
  platforms
- All v2 platforms will now only need to use the qcom,tsen-v2 property
- Added a DT patch to initialize tsens driver on sdm845, now that 4.18-rc1
  will contain an sdm845.dtsi

Changes since v1:
- Move get_temp() from tsens-8996 to tsens-common and rename
- Change 8996 DT entry to allow init_common() to work across sdm845 and
  8996 due to different offsets


Amit Kucheria (6):
  thermal: tsens: Get rid of unused fields in structure
  dt: qcom: 8996: thermal: Move to DT initialisation
  thermal: tsens: Rename tsens-8996 to tsens-v2 for reuse
  thermal: tsens: Add support for SDM845
  thermal: tsens: Check if we have valid data before reading
  arm64: dts: sdm845: Add tsens nodes

 .../devicetree/bindings/thermal/qcom-tsens.txt     |  1 +
 arch/arm64/boot/dts/qcom/msm8996.dtsi              | 12 ++++++-
 arch/arm64/boot/dts/qcom/sdm845.dtsi               | 16 +++++++++
 drivers/thermal/qcom/Makefile                      |  2 +-
 drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c}  | 42 +++++++++++++---------
 drivers/thermal/qcom/tsens.c                       |  3 ++
 drivers/thermal/qcom/tsens.h                       |  7 ++--
 7 files changed, 61 insertions(+), 22 deletions(-)
 rename drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} (65%)

-- 
2.7.4

^ permalink raw reply

* Re: [PATCH v2 4/5] thermal: tsens: Add support for SDM845
From: Amit Kucheria @ 2018-06-14 10:24 UTC (permalink / raw)
  To: Vivek Gautam
  Cc: open list, Rajendra Nayak, linux-arm-msm, Bjorn Andersson,
	Eduardo Valentin, Zhang Rui, Rob Herring, Mark Rutland,
	open list:THERMAL,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAFp+6iEnep3ogEkdfmaSOn_2w+09huae2NOwBF1o7-vn3iQMCA@mail.gmail.com>

On Thu, Jun 14, 2018 at 9:48 AM, Vivek Gautam
<vivek.gautam@codeaurora.org> wrote:
> Hi Amit,
>
> On Tue, Jun 12, 2018 at 4:24 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>> SDM845 uses the TSENS v2 IP block
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
>> ---

<snip>

>> +
>> +static const struct tsens_ops ops_sdm845 = {
>> +       .init           = init_common,
>> +       .get_temp       = get_temp_tsens_v2,
>> +};
>> +
>> +const struct tsens_data data_sdm845 = {
>
> Just a minor nit. 'static' here?

Thanks for the review.

This file just went away in favour of a common tsens-v2.c that will
support all v2 SoCs. I'll be sending out an updated patchset soon.

>
>> +       .ops            = &ops_sdm845,
>> +};
>
> [snip]
>
> Thanks & Regards
> Vivek

^ permalink raw reply

* Re: [RFC PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Roger Pau Monné @ 2018-06-14  8:43 UTC (permalink / raw)
  To: Anchal Agarwal
  Cc: tglx, mingo, hpa, x86, boris.ostrovsky, konrad.wilk, netdev,
	jgross, xen-devel, linux-kernel, kamatam, eduval, vallish,
	fllinden, guruanb, rjw, pavel, len.brown, linux-pm, cyberax
In-Reply-To: <20180613222048.GB33296@kaos-source-ops-60001.pdx1.amazon.com>

Please try to avoid top posting.

On Wed, Jun 13, 2018 at 10:20:48PM +0000, Anchal Agarwal wrote:
> Hi Roger,
> To answer your question, due to the lack of mentioned commit
> (commit 12ea729645ac ("xen/blkback: unmap all persistent grants when
> frontend gets disconnected") in the older dom0 kernels(<3.2),resume from

This fix that you mention is only present in kernels >= 3.18 AFAICT,
and persistent grants where introduced in 3.8 (0a8704a51f38), so
anything < 3.8 should work fine. Not sure why you mention 3.2 here.

> hibernation can fail on guest side. In the absence of the commit,
> Persistant Grants are not unmapped immediately when frontend is 
> disconnected from backend and hence leave the block device in an 
> inconsistent state. To avoid this unstability and work with larger set 
> of kernel versions, this approach had been used. Once you don't have 
> any pending req/resp it is safer for guest to resume from hibernation.

I think the fix should be backported (if it hasn't been done yet) to
kernels between 3.8 and 3.18. I don't like to add all this code just
to work around a Linux backend kernel bug.

AFAICT if persistent grants work as expected you could use almost the
same path that's used for migration, greatly reducing the amount of
code that you need to add.

Thanks, Roger.

^ permalink raw reply

* Re: [PATCH 2/2] PM / Domains: Fix return value of of_genpd_opp_to_performance_state()
From: Ulf Hansson @ 2018-06-14  7:14 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Rafael Wysocki, Kevin Hilman, Linux PM, Vincent Guittot,
	Rajendra Nayak, Linux Kernel Mailing List
In-Reply-To: <3d3687c030535189885d84c57dbffb034c4461c2.1528953706.git.viresh.kumar@linaro.org>

On 14 June 2018 at 07:23, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> of_genpd_opp_to_performance_state() should return 0 for errors, but the
> dummy routine isn't doing that. Fix it.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  include/linux/pm_domain.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 9206a4fef9ac..139f79c8477a 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -276,7 +276,7 @@ static inline unsigned int
>  of_genpd_opp_to_performance_state(struct device *dev,
>                                   struct device_node *opp_node)
>  {
> -       return -ENODEV;
> +       return 0;
>  }
>
>  static inline int genpd_dev_pm_attach(struct device *dev)
> --
> 2.18.0.rc1.242.g61856ae69a2c
>

^ permalink raw reply

* Re: [PATCH 1/2] PM / Domains: Rename opp_node to np
From: Ulf Hansson @ 2018-06-14  7:12 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Rafael Wysocki, Kevin Hilman, Len Brown, Pavel Machek, Linux PM,
	Vincent Guittot, Rajendra Nayak, Linux Kernel Mailing List
In-Reply-To: <b90f44d35e8e0fa9c81b3a88d05449a580be5567.1528953706.git.viresh.kumar@linaro.org>

On 14 June 2018 at 07:23, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> The DT node passed here isn't necessarily an OPP node, as this routine
> can also be used for cases where the "required-opps" property is present
> directly in the device's node. Rename it.
>
> This also removes a stale comment.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  drivers/base/power/domain.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 4925af5c4cf0..c298de8a8308 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2487,10 +2487,9 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
>   * power domain corresponding to a DT node's "required-opps" property.
>   *
>   * @dev: Device for which the performance-state needs to be found.
> - * @opp_node: DT node where the "required-opps" property is present. This can be
> + * @np: DT node where the "required-opps" property is present. This can be
>   *     the device node itself (if it doesn't have an OPP table) or a node
>   *     within the OPP table of a device (if device has an OPP table).
> - * @state: Pointer to return performance state.
>   *
>   * Returns performance state corresponding to the "required-opps" property of
>   * a DT node. This calls platform specific genpd->opp_to_performance_state()
> @@ -2499,7 +2498,7 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
>   * Returns performance state on success and 0 on failure.
>   */
>  unsigned int of_genpd_opp_to_performance_state(struct device *dev,
> -                                              struct device_node *opp_node)
> +                                              struct device_node *np)
>  {
>         struct generic_pm_domain *genpd;
>         struct dev_pm_opp *opp;
> @@ -2514,7 +2513,7 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
>
>         genpd_lock(genpd);
>
> -       opp = of_dev_pm_opp_find_required_opp(&genpd->dev, opp_node);
> +       opp = of_dev_pm_opp_find_required_opp(&genpd->dev, np);
>         if (IS_ERR(opp)) {
>                 dev_err(dev, "Failed to find required OPP: %ld\n",
>                         PTR_ERR(opp));
> --
> 2.18.0.rc1.242.g61856ae69a2c
>

^ permalink raw reply

* Re: [PATCH v2 4/5] thermal: tsens: Add support for SDM845
From: Vivek Gautam @ 2018-06-14  6:48 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: open list, Rajendra Nayak, linux-arm-msm, Bjorn Andersson,
	edubezval, Zhang Rui, Rob Herring, Mark Rutland,
	open list:THERMAL,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <f048a97d1599a54aef3d00126a379f4e5c937057.1528799892.git.amit.kucheria@linaro.org>

Hi Amit,

On Tue, Jun 12, 2018 at 4:24 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> SDM845 uses the TSENS v2 IP block
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  Documentation/devicetree/bindings/thermal/qcom-tsens.txt |  1 +
>  drivers/thermal/qcom/Makefile                            |  2 +-
>  drivers/thermal/qcom/tsens-sdm845.c                      | 15 +++++++++++++++
>  drivers/thermal/qcom/tsens.c                             |  3 +++
>  drivers/thermal/qcom/tsens.h                             |  5 ++++-
>  5 files changed, 24 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89..8652499 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
>   - "qcom,msm8916-tsens" : For 8916 Family of SoCs
>   - "qcom,msm8974-tsens" : For 8974 Family of SoCs
>   - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,sdm845-tsens"  : For SDM845 Family of SoCs
>
>  - reg: Address range of the thermal registers
>  - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 2cc2193..dc9f169 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_QCOM_TSENS)       += qcom_tsens.o
> -qcom_tsens-y                   += tsens.o tsens-common.o tsens-8916.o tsens-8974.o tsens-8960.o tsens-8996.o
> +qcom_tsens-y                   += tsens.o tsens-common.o tsens-8916.o tsens-8974.o tsens-8960.o tsens-8996.o tsens-sdm845.o
> diff --git a/drivers/thermal/qcom/tsens-sdm845.c b/drivers/thermal/qcom/tsens-sdm845.c
> new file mode 100644
> index 0000000..a647265
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-sdm845.c
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include "tsens.h"
> +
> +static const struct tsens_ops ops_sdm845 = {
> +       .init           = init_common,
> +       .get_temp       = get_temp_tsens_v2,
> +};
> +
> +const struct tsens_data data_sdm845 = {

Just a minor nit. 'static' here?

> +       .ops            = &ops_sdm845,
> +};

[snip]

Thanks & Regards
Vivek


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply

* [PATCH 2/2] PM / Domains: Fix return value of of_genpd_opp_to_performance_state()
From: Viresh Kumar @ 2018-06-14  5:23 UTC (permalink / raw)
  To: Rafael Wysocki, Kevin Hilman, Ulf Hansson
  Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rajendra Nayak,
	linux-kernel
In-Reply-To: <b90f44d35e8e0fa9c81b3a88d05449a580be5567.1528953706.git.viresh.kumar@linaro.org>

of_genpd_opp_to_performance_state() should return 0 for errors, but the
dummy routine isn't doing that. Fix it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 include/linux/pm_domain.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9206a4fef9ac..139f79c8477a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -276,7 +276,7 @@ static inline unsigned int
 of_genpd_opp_to_performance_state(struct device *dev,
 				  struct device_node *opp_node)
 {
-	return -ENODEV;
+	return 0;
 }
 
 static inline int genpd_dev_pm_attach(struct device *dev)
-- 
2.18.0.rc1.242.g61856ae69a2c

^ permalink raw reply related

* [PATCH 1/2] PM / Domains: Rename opp_node to np
From: Viresh Kumar @ 2018-06-14  5:23 UTC (permalink / raw)
  To: Rafael Wysocki, Kevin Hilman, Ulf Hansson, Len Brown,
	Pavel Machek
  Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rajendra Nayak,
	linux-kernel

The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.

This also removes a stale comment.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/power/domain.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4925af5c4cf0..c298de8a8308 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2487,10 +2487,9 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
  * power domain corresponding to a DT node's "required-opps" property.
  *
  * @dev: Device for which the performance-state needs to be found.
- * @opp_node: DT node where the "required-opps" property is present. This can be
+ * @np: DT node where the "required-opps" property is present. This can be
  *	the device node itself (if it doesn't have an OPP table) or a node
  *	within the OPP table of a device (if device has an OPP table).
- * @state: Pointer to return performance state.
  *
  * Returns performance state corresponding to the "required-opps" property of
  * a DT node. This calls platform specific genpd->opp_to_performance_state()
@@ -2499,7 +2498,7 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
  * Returns performance state on success and 0 on failure.
  */
 unsigned int of_genpd_opp_to_performance_state(struct device *dev,
-					       struct device_node *opp_node)
+					       struct device_node *np)
 {
 	struct generic_pm_domain *genpd;
 	struct dev_pm_opp *opp;
@@ -2514,7 +2513,7 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
 
 	genpd_lock(genpd);
 
-	opp = of_dev_pm_opp_find_required_opp(&genpd->dev, opp_node);
+	opp = of_dev_pm_opp_find_required_opp(&genpd->dev, np);
 	if (IS_ERR(opp)) {
 		dev_err(dev, "Failed to find required OPP: %ld\n",
 			PTR_ERR(opp));
-- 
2.18.0.rc1.242.g61856ae69a2c

^ permalink raw reply related

* Re: [PATCH v6 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
From: Matthias Kaehlcke @ 2018-06-13 22:53 UTC (permalink / raw)
  To: Craig Tatlor
  Cc: linux-arm-msm, Sebastian Reichel, Rob Herring, Mark Rutland,
	Mauro Carvalho Chehab, David S. Miller, Andrew Morton,
	Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-pm,
	devicetree, linux-kernel
In-Reply-To: <20180613160643.12638-3-ctatlor97@gmail.com>

(sorry if you receive two variants of this mail, I sent one earlier
today but for some reason it didn't make it to the lists)

On Wed, Jun 13, 2018 at 05:06:24PM +0100, Craig Tatlor wrote:
> Add bindings for the Qualcomm Battery Monitoring system.
> 
> Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> ---
> 
> * Changes from v5:
>   Mentions which values are 8 bit.
> 
> * Changes from v4:
>   Uses proper units and expands some definitions,
>   along with changing vadc@ to adc@.
>  .../bindings/power/supply/qcom_bms.txt        | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> new file mode 100644
> index 000000000000..9a29a2eb9f04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> @@ -0,0 +1,92 @@
> +Qualcomm Battery Monitoring System
> +
> +The Qualcomm Battery Monitoring System is found inside of Qualcomm PM8941
> +PMICs. It provides open circuit voltage (OCV) and coulomb counter registers
> +that allow the OS to infer a capacity level.
> +
> +Required properties:
> +- compatible:                   Should contain "qcom,pm8941-bms".
> +- reg:                          Specifies the SPMI address and length of the
> +				controller's registers.
> +- interrupts:                   OCV threshold interrupt.
> +- io-channels:                  Should contain IIO channel specifier for the
> +				ADC channel that reports battery temperature.
> +- io-channel-names:             Should contain "temp".
> +- qcom,fcc-temp-legend-celcius: An 8 bit array containing the temperature,
> +				in degC, for each column of the full charge
> +				capacity lookup table.

s/celcius/celsius/

same for qcom,ocv-temp-legend-celcius

> +- qcom,fcc-lut-microamp-hours:  An array of full charge capacity values in uah,
> +				one entry for each temperature defined in in

nit: s/uah/uAh/

Thanks

Matthias

^ permalink raw reply

* Re: [RFC PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Anchal Agarwal @ 2018-06-13 22:20 UTC (permalink / raw)
  To: Roger Pau Monn??
  Cc: jgross, len.brown, kamatam, eduval, vallish, netdev, fllinden,
	x86, rjw, linux-kernel, anchalag, cyberax, mingo, pavel, hpa,
	linux-pm, xen-devel, boris.ostrovsky, guruanb, tglx
In-Reply-To: <20180613082428.bjdko4k6cnq6eid3@mac>

Hi Roger,
To answer your question, due to the lack of mentioned commit
(commit 12ea729645ac ("xen/blkback: unmap all persistent grants when
frontend gets disconnected") in the older dom0 kernels(<3.2),resume from
hibernation can fail on guest side. In the absence of the commit,
Persistant Grants are not unmapped immediately when frontend is 
disconnected from backend and hence leave the block device in an 
inconsistent state. To avoid this unstability and work with larger set 
of kernel versions, this approach had been used. Once you don't have 
any pending req/resp it is safer for guest to resume from hibernation.

Thanks,
Anchal

On Wed, Jun 13, 2018 at 10:24:28AM +0200, Roger Pau Monn?? wrote:
> On Tue, Jun 12, 2018 at 08:56:13PM +0000, Anchal Agarwal wrote:
> > From: Munehisa Kamata <kamatam@amazon.com>
> > 
> > Add freeze and restore callbacks for PM suspend and hibernation support.
> > The freeze handler stops a block-layer queue and disconnect the frontend
> > from the backend while freeing ring_info and associated resources. The
> > restore handler re-allocates ring_info and re-connect to the backedend,
> > so the rest of the kernel can continue to use the block device
> > transparently.Also, the handlers are used for both PM
> > suspend and hibernation so that we can keep the existing suspend/resume
> > callbacks for Xen suspend without modification.
> > If a backend doesn't have commit 12ea729645ac ("xen/blkback: unmap all
> > persistent grants when frontend gets disconnected"), the frontend may see
> > massive amount of grant table warning when freeing resources.
> > 
> >  [   36.852659] deferring g.e. 0xf9 (pfn 0xffffffffffffffff)
> >  [   36.855089] xen:grant_table: WARNING: g.e. 0x112 still in use!
> > 
> > In this case, persistent grants would need to be disabled.
> > 
> > Ensure no reqs/rsps in rings before disconnecting. When disconnecting
> > the frontend from the backend in blkfront_freeze(), there still may be
> > unconsumed requests or responses in the rings, especially when the
> > backend is backed by network-based device. If the frontend gets
> > disconnected with such reqs/rsps remaining there, it can cause
> > grant warnings and/or losing reqs/rsps by freeing pages afterward.
> 
> I'm not sure why having pending requests can cause grant warnings or
> lose of requests. If handled properly this shouldn't be an issue.
> Linux blkfront already does live migration (which also involves a
> reconnection of the frontend) with pending requests and that doesn't
> seem to be an issue.
> 
> > This can lead resumed kernel into unrecoverable state like unexpected
> > freeing of grant page and/or hung task due to the lost reqs or rsps.
> > Therefore we have to ensure that there is no unconsumed requests or
> > responses before disconnecting.
> 
> Given that we have multiqueue, plus multipage rings, I'm not sure
> waiting for the requests on the rings to complete is a good idea.
> 
> Why can't you just disconnect the frontend and requeue all the
> requests in flight? When the frontend connects on resume those
> requests will be queued again.
> 
> Thanks, Roger.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
From: Rafael J. Wysocki @ 2018-06-13 21:27 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Pandruvada, Srinivas, viresh.kumar@linaro.org, rjw@rjwysocki.net,
	linux-kernel@vger.kernel.org, peterz@infradead.org, Zhang, Rui,
	edubezval@gmail.com, linux-pm@vger.kernel.org,
	andrea.parri@amarulasolutions.com, kevin.wangtao@linaro.org,
	leo.yan@linaro.org, daniel.thompson@linaro.org,
	javi.merino@kernel.org, vincent.guittot@linaro.org
In-Reply-To: <55e8799f-9af2-f311-72fd-3f52439b5b97@linaro.org>

On Wed, Jun 13, 2018 at 10:35 PM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On 13/06/2018 22:32, Pandruvada, Srinivas wrote:
>> On Wed, 2018-06-13 at 22:19 +0200, Daniel Lezcano wrote:
>>> On 13/06/2018 22:07, Pandruvada, Srinivas wrote:
>>>> On Wed, 2018-06-13 at 22:00 +0200, Daniel Lezcano wrote:
>>>>> On 13/06/2018 17:54, Pandruvada, Srinivas wrote:
>>>>>> On Tue, 2018-06-12 at 14:00 +0200, Daniel Lezcano wrote:
>>>>>>> Initially, the cpu_cooling device for ARM was changed by
>>>>>>> adding a
>>>>>>> new
>>>>>>> policy inserting idle cycles. The intel_powerclamp driver
>>>>>>> does a
>>>>>>> similar action.
>>>>>>>
>>>>>>> Instead of implementing idle injections privately in the
>>>>>>> cpu_cooling
>>>>>>> device, move the idle injection code in a dedicated framework
>>>>>>> and
>>>>>>> give
>>>>>>> the opportunity to other frameworks to make use of it.
>>>>>>>
>>>>>>> The framework relies on the smpboot kthreads which handles
>>>>>>> via
>>>>>>> its
>>>>>>> main loop the common code for hotplugging and [un]parking.
>>>>>>>
>>>>>>> This code was previously tested with the cpu cooling device
>>>>>>> and
>>>>>>> went
>>>>>>> through several iterations. It results now in split code and
>>>>>>> API
>>>>>>> exported in the header file. It was tested with the cpu
>>>>>>> cooling
>>>>>>> device
>>>>>>> with success.
>>>>>>>
>>>>>>
>>>>>> May be I have missed, but I don't see any use of powercap
>>>>>> sysfs.
>>>>>>
>>>>>> We created powercap sys that user space is presented a common
>>>>>> interface
>>>>>> for power capping. The RAPL driver was also submitted as
>>>>>> cooling
>>>>>> device
>>>>>> before, but suggestion was to create this powercap.
>>>>>>
>>>>>> So if powercap interface is not enough then may be we should
>>>>>> enhance
>>>>>> that.
>>>>>
>>>>> We are creating a framework for idle injection. This framework
>>>>> can
>>>>> then
>>>>> be used by the cpu_cooling device, the power_clamp and in
>>>>> addition a
>>>>> power capping for ARM (if it makes sense).
>>>>
>>>> But in this case, why in drivers/powercap folder as this is another
>>>> framework?
>>>
>>> I presented at OSPM 2nd the cpu idle cooling device. It is ARM
>>> specific
>>> but has some similarities with the power clamp driver.
>>>
>>> Some board come with power numbers defined in their DT and from there
>>> we
>>> are able to compute a targeted power by injecting idle cycles.
>>>
>>> As the idle injection allows to do also power capping, Rafael told me
>>> to
>>> move that to a framework (may be better say a component with exported
>>> services or library) and put it in drivers/powercap.
>> So Rafael wants it to be in powercap.
>
> That is what I understood.

While this is not exactly power capping, the purpose of this mechanism
is to prevent too much power from being drawn by the system, so IMO it
falls under the same broad category.

^ permalink raw reply

* Re: [PATCH 00/11] Add support for Hygon's Dhyana Family 18h processor
From: Borislav Petkov @ 2018-06-13 20:51 UTC (permalink / raw)
  To: Pu Wen
  Cc: tglx, mingo, hpa, x86, thomas.lendacky, peterz, tony.luck,
	pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
	viresh.kumar, mchehab, trenn, shuah, zhangpanyong, linux-kernel,
	linux-arch, linux-x86_64, linux-pci, linux-acpi, linux-edac,
	linux-pm, kvm, xen-devel
In-Reply-To: <1528550410-28080-1-git-send-email-puwen@hygon.cn>

On Sat, Jun 09, 2018 at 09:20:10PM +0800, Pu Wen wrote:
> As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
> is a Joint Venture between AMD and Haiguang Information Technology Co.,
> Ltd., and aims at providing high performance x86 processor for China
> server market.
> 
> The first generation Hygon's processor(Dhyana) originates from AMD
> technology and shares most of the architecture with AMD's family 17h,
> but with different CPU Vendor ID("HygonGenuine")/PCIE Device Vendor ID
> (0x1D94)/Family series number(Family 18h).
> 
> To enable the support of Linux kernel to Hygon's CPU, we added a new
> vendor type (X86_VENDOR_HYGON, with value of 9) in arch/x86/include/
> asm/processor.h, and shared most of kernel support codes with AMD
> family 17h.
> 
> These patches have been applied and tested successfully in Hygon's
> Dhyana SoC silicon. Also tested on AMD's EPYC (Family 17h) processor
> works fine and makes no harm to existing codes.

Well, I don't like this diffstat:

 37 files changed, 183 insertions(+), 56 deletions(-)

which adds a lot of code checking this new vendor. But then it adds in
the AMD paths and I don't see it being any different from an AMD CPU. So
it does the same a Zen does but then it is Hygon.

So I'd prefer to *not* sprinkle those X86_VENDOR_HYGON checks everywhere
but simply have the vendor be X86_VENDOR_AMD and only the user-visible
reporting to show that it is Hygon. Because to the kernel it is an AMD
CPU - only the superficial attributes are something else. Oh well, and
PCI device IDs but that's like another CPU revision.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply

* Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
From: Daniel Lezcano @ 2018-06-13 20:35 UTC (permalink / raw)
  To: Pandruvada, Srinivas, viresh.kumar@linaro.org, rjw@rjwysocki.net
  Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, Zhang, Rui,
	edubezval@gmail.com, linux-pm@vger.kernel.org,
	andrea.parri@amarulasolutions.com, kevin.wangtao@linaro.org,
	leo.yan@linaro.org, daniel.thompson@linaro.org,
	javi.merino@kernel.org, vincent.guittot@linaro.org
In-Reply-To: <1528921968.48473.15.camel@intel.com>

On 13/06/2018 22:32, Pandruvada, Srinivas wrote:
> On Wed, 2018-06-13 at 22:19 +0200, Daniel Lezcano wrote:
>> On 13/06/2018 22:07, Pandruvada, Srinivas wrote:
>>> On Wed, 2018-06-13 at 22:00 +0200, Daniel Lezcano wrote:
>>>> On 13/06/2018 17:54, Pandruvada, Srinivas wrote:
>>>>> On Tue, 2018-06-12 at 14:00 +0200, Daniel Lezcano wrote:
>>>>>> Initially, the cpu_cooling device for ARM was changed by
>>>>>> adding a
>>>>>> new
>>>>>> policy inserting idle cycles. The intel_powerclamp driver
>>>>>> does a
>>>>>> similar action.
>>>>>>
>>>>>> Instead of implementing idle injections privately in the
>>>>>> cpu_cooling
>>>>>> device, move the idle injection code in a dedicated framework
>>>>>> and
>>>>>> give
>>>>>> the opportunity to other frameworks to make use of it.
>>>>>>
>>>>>> The framework relies on the smpboot kthreads which handles
>>>>>> via
>>>>>> its
>>>>>> main loop the common code for hotplugging and [un]parking.
>>>>>>
>>>>>> This code was previously tested with the cpu cooling device
>>>>>> and
>>>>>> went
>>>>>> through several iterations. It results now in split code and
>>>>>> API
>>>>>> exported in the header file. It was tested with the cpu
>>>>>> cooling
>>>>>> device
>>>>>> with success.
>>>>>>
>>>>>
>>>>> May be I have missed, but I don't see any use of powercap
>>>>> sysfs.
>>>>>
>>>>> We created powercap sys that user space is presented a common
>>>>> interface
>>>>> for power capping. The RAPL driver was also submitted as
>>>>> cooling
>>>>> device
>>>>> before, but suggestion was to create this powercap.
>>>>>
>>>>> So if powercap interface is not enough then may be we should
>>>>> enhance
>>>>> that.
>>>>
>>>> We are creating a framework for idle injection. This framework
>>>> can
>>>> then
>>>> be used by the cpu_cooling device, the power_clamp and in
>>>> addition a
>>>> power capping for ARM (if it makes sense).
>>>
>>> But in this case, why in drivers/powercap folder as this is another
>>> framework?
>>
>> I presented at OSPM 2nd the cpu idle cooling device. It is ARM
>> specific
>> but has some similarities with the power clamp driver.
>>
>> Some board come with power numbers defined in their DT and from there
>> we
>> are able to compute a targeted power by injecting idle cycles.
>>
>> As the idle injection allows to do also power capping, Rafael told me
>> to
>> move that to a framework (may be better say a component with exported
>> services or library) and put it in drivers/powercap.
> So Rafael wants it to be in powercap.

That is what I understood.




-- 
 <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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox