Re: [RFC PATCH v6 2/8] drivers: thermal: tsens: Add VER_0 tsens version
On Thu, Nov 26, 2020 at 2:16 AM Ansuel Smith wrote:
> > > };
> > > @@ -441,6 +442,10 @@ enum regfield_ids {
> > > CRIT_THRESH_14,
> > > CRIT_THRESH_15,
> > >
> > > + /* VER_0 MIN MAX THRESH */
> > > + MIN_THRESH_0,
> > > + MAX_THRESH_0,
> > > +
> >
> > Consider reusing LOW_THRESH_0 and UP_THRESH_0 for these?
> >
>
> As we already have defined LOW_THRESH and UP how can we reuse that
> regfield to define MIN and MAX?
>
We are using MIN and MAX THRESH on the apq8064 to mean LOW and UP
THRESOLD, isn't it? IIUC, It was just named differently earlier.
When the driver is loaded on the apq8064, only that one field will be
use since v0 has a single threshold for all sensors. When the driver
is loaded on new IPs, all fields will be used.
Re: [RFC PATCH v6 2/8] drivers: thermal: tsens: Add VER_0 tsens version
Hi Ansuel,
See comments inline.
On Fri, Aug 14, 2020 at 7:12 PM Ansuel Smith wrote:
>
> VER_0 is used to describe device based on tsens version before v0.1.
> These device are devices based on msm8960 for example apq8064 or
> ipq806x.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens.c | 122 +++
> drivers/thermal/qcom/tsens.h | 7 +-
> 2 files changed, 114 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 9fe9a2b26705..965c4799918a 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -516,6 +516,15 @@ static irqreturn_t tsens_irq_thread(int irq, void *data)
> dev_dbg(priv->dev, "[%u] %s: no violation: %d\n",
> hw_id, __func__, temp);
> }
> +
> + if (tsens_version(priv) < VER_0_1) {
> + /* Constraint: There is only 1 interrupt control
> register for all
> +* 11 temperature sensor. So monitoring more than 1
> sensor based
> +* on interrupts will yield inconsistent result. To
> overcome this
> +* issue we will monitor only sensor 0 which is the
> master sensor.
> +*/
> + break;
> + }
> }
>
> return IRQ_HANDLED;
> @@ -531,6 +540,13 @@ static int tsens_set_trips(void *_sensor, int low, int
> high)
> int high_val, low_val, cl_high, cl_low;
> u32 hw_id = s->hw_id;
>
> + if (tsens_version(priv) < VER_0_1) {
> + /* Pre v0.1 IP had a single register for each type of
> interrupt
> +* and thresholds
> +*/
> + hw_id = 0;
> + }
> +
> dev_dbg(dev, "[%u] %s: proposed thresholds: (%d:%d)\n",
> hw_id, __func__, low, high);
>
> @@ -584,18 +600,21 @@ int get_temp_tsens_valid(const struct tsens_sensor *s,
> int *temp)
> u32 valid;
> int ret;
>
> - ret = regmap_field_read(priv->rf[valid_idx], );
> - if (ret)
> - return ret;
> - while (!valid) {
> - /* Valid bit is 0 for 6 AHB clock cycles.
> -* At 19.2MHz, 1 AHB clock is ~60ns.
> -* We should enter this loop very, very rarely.
> -*/
> - ndelay(400);
> + /* VER_0 doesn't have VALID bit */
> + if (tsens_version(priv) >= VER_0_1) {
> ret = regmap_field_read(priv->rf[valid_idx], );
> if (ret)
> return ret;
> + while (!valid) {
> + /* Valid bit is 0 for 6 AHB clock cycles.
> +* At 19.2MHz, 1 AHB clock is ~60ns.
> +* We should enter this loop very, very rarely.
> +*/
> + ndelay(400);
> + ret = regmap_field_read(priv->rf[valid_idx], );
> + if (ret)
> + return ret;
> + }
Let's revisit this after fixing patch 1.
> }
>
> /* Valid bit is set, OK to read the temperature */
> @@ -763,6 +782,10 @@ int __init init_common(struct tsens_priv *priv)
> goto err_put_device;
> }
>
> + /* VER_0 have only tm_map */
> + if (!priv->srot_map)
> + priv->srot_map = priv->tm_map;
> +
> if (tsens_version(priv) > VER_0_1) {
> for (i = VER_MAJOR; i <= VER_STEP; i++) {
> priv->rf[i] = devm_regmap_field_alloc(dev,
> priv->srot_map,
> @@ -781,6 +804,10 @@ int __init init_common(struct tsens_priv *priv)
> ret = PTR_ERR(priv->rf[TSENS_EN]);
> goto err_put_device;
> }
> + /* in VER_0 TSENS need to be explicitly enabled */
> + if (tsens_version(priv) == VER_0)
> + regmap_field_write(priv->rf[TSENS_EN], 1);
> +
> ret = regmap_field_read(priv->rf[TSENS_EN], );
> if (ret)
> goto err_put_device;
> @@ -803,6 +830,61 @@ int __init init_common(struct tsens_priv *priv)
> goto err_put_device;
> }
>
> + priv->rf[TSENS_EN] = devm_regmap_field_alloc(dev, priv->tm_map,
> +priv->fields[TSENS_EN]);
> + if (IS_ERR(priv->rf[TSENS_EN])) {
> + ret = PTR_ERR(priv->rf[TSENS_EN]);
> + goto err_put_device;
> + }
> +
> + priv->rf[TSENS_SW_RST] = devm_regmap_field_alloc(
> + dev, priv->tm_map, priv->fields[TSENS_EN]);
> + if (IS_ERR(priv->rf[TSENS_EN])) {
> + ret = PTR_ERR(priv->rf[TSENS_EN]);
> + goto err_put_device;
> + }
> +
> + priv->rf[LOW_INT_CLEAR_0] = devm_regmap_field_alloc(
> + dev, priv->tm_map,
Re: [RFC PATCH v6 1/8] drivers: thermal: tsens: use get_temp for tsens_valid
Hi Ansuel,
My apologies for being tardy in reviewing this series. Career changes...
On Fri, Aug 14, 2020 at 7:12 PM Ansuel Smith wrote:
>
> Use the driver get_temp function instead of force to use the generic get
> temp function. This is needed as tsens v0 version use a custom function
> to get the real temperature.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 9af6f71ab640..9fe9a2b26705 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -580,7 +580,6 @@ int get_temp_tsens_valid(const struct tsens_sensor *s,
> int *temp)
> {
> struct tsens_priv *priv = s->priv;
> int hw_id = s->hw_id;
> - u32 temp_idx = LAST_TEMP_0 + hw_id;
> u32 valid_idx = VALID_0 + hw_id;
> u32 valid;
> int ret;
> @@ -600,9 +599,9 @@ int get_temp_tsens_valid(const struct tsens_sensor *s,
> int *temp)
> }
>
> /* Valid bit is set, OK to read the temperature */
> - *temp = tsens_hw_to_mC(s, temp_idx);
> + ret = priv->ops->get_temp(s, temp);
This is wrong.
.get_temp is set to get_temp_tsens_valid() for v1 and v2 platforms. So
you've just broken all those platforms by creating a recursive loop.
I assume you were trying to use the common interrupt code which
currently uses get_temp_tsens_valid()? I suggest trying to add 8960
support to tsens_hw_to_mC().
>
> - return 0;
> + return ret;
> }
>
> int get_temp_common(const struct tsens_sensor *s, int *temp)
> --
> 2.27.0
>
Re: [RFC PATCH v6 0/8] Add support for ipq8064 tsens
Hi Ansuel, Just a quick note to say that I'm not ignoring this, just on vacations. I'll be back to review this in a few days. Regards, Amit On Fri, Aug 14, 2020 at 7:12 PM Ansuel Smith wrote: > > This patchset convert msm8960 to reg_filed, use int_common instead > of a custom function and fix wrong tsens get_temp function for msm8960. > Ipq8064 SoCs tsens driver is based on 8960 tsens driver. Ipq8064 needs > to be registered as a gcc child as the tsens regs on this platform are > shared with the controller. > This is based on work and code here > https://git.linaro.org/people/amit.kucheria/kernel.git/log/?h=wrk3/tsens-8960-breakage > > v6: > * Fix spelling error (can't find the problem with variable misallignment) > * Rework big if-else > * Remove extra comments > * Add description about different interrupts > v5: > * Conver driver to use reg_fiedl > * Use init_common > * Drop custom set_trip and set_interrupt > * Use common set_trip and set_interrupt > * Fix bad get_temp function > * Add missing hardcoded slope > v4: > * Fix compilation error and warning reported by the bot > v3: > * Change driver to register as child instead of use phandle > v2: > * Fix dt-bindings problems > > Ansuel Smith (8): > drivers: thermal: tsens: use get_temp for tsens_valid > drivers: thermal: tsens: Add VER_0 tsens version > drivers: thermal: tsens: Convert msm8960 to reg_field > drivers: thermal: tsens: Use init_common for msm8960 > drivers: thermal: tsens: Fix wrong get_temp for msm8960 > drivers: thermal: tsens: Change calib_backup name for msm8960 > drivers: thermal: tsens: Add support for ipq8064-tsens > dt-bindings: thermal: tsens: Document ipq8064 bindings > > .../bindings/thermal/qcom-tsens.yaml | 50 - > drivers/thermal/qcom/tsens-8960.c | 172 +++--- > drivers/thermal/qcom/tsens.c | 130 +++-- > drivers/thermal/qcom/tsens.h | 7 +- > 4 files changed, 270 insertions(+), 89 deletions(-) > > -- > 2.27.0 >
[PATCH] powercap: make documentation reflect code
Fix up documentation of the struct members to reflect reality. Also
fixup a stray whitespace.
Signed-off-by: Amit Kucheria
---
include/linux/powercap.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/linux/powercap.h b/include/linux/powercap.h
index 4537f57f9e42f..3d557bbcd2c71 100644
--- a/include/linux/powercap.h
+++ b/include/linux/powercap.h
@@ -44,19 +44,18 @@ struct powercap_control_type_ops {
};
/**
- * struct powercap_control_type- Defines a powercap control_type
- * @name: name of control_type
+ * struct powercap_control_type - Defines a powercap control_type
* @dev: device for this control_type
* @idr: idr to have unique id for its child
- * @root_node: Root holding power zones for this control_type
+ * @nr_zones: counter for number of zones of this type
* @ops: Pointer to callback struct
- * @node_lock: mutex for control type
+ * @lock: mutex for control type
* @allocated: This is possible that client owns the memory
* used by this structure. In this case
* this flag is set to false by framework to
* prevent deallocation during release process.
* Otherwise this flag is set to true.
- * @ctrl_inst: link to the control_type list
+ * @node: linked-list node
*
* Defines powercap control_type. This acts as a container for power
* zones, which use same method to control power. E.g. RAPL, RAPL-PCI etc.
@@ -129,7 +128,7 @@ struct powercap_zone_ops {
* this flag is set to false by framework to
* prevent deallocation during release process.
* Otherwise this flag is set to true.
- * @constraint_ptr:List of constraints for this zone.
+ * @constraints: List of constraints for this zone.
*
* This defines a power zone instance. The fields of this structure are
* private, and should not be used by client drivers.
--
2.25.1
[PATCH 1/1] arm64: dts: qcom: sm8250: Add thermal zones and throttling support
sm8250 has 24 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle on
crossing passive temperature thresholds.
Signed-off-by: Amit Kucheria
---
Depends on
https://lore.kernel.org/r/20200908075716.30357-1-manivannan.sadhasi...@linaro.org
arch/arm64/boot/dts/qcom/sm8250.dtsi | 766 +++
1 file changed, 766 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 88b46f8619954..db092959dd156 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -88,6 +89,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <_0>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -104,6 +106,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <_100>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -117,6 +120,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <_200>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -130,6 +134,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <_300>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -143,6 +148,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <_400>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -156,6 +162,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <_500>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -170,6 +177,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <_600>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -183,6 +191,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <_700>;
qcom,freq-domain = <_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -1284,6 +1293,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sm8250-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1ff>, /* TM */
+ <0 0x0c222000 0 0x1ff>; /* SROT */
+ #qcom,sensors = <16>;
+ interrupts = ,
+;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sm8250-tsens", "qcom
Re: [PATCH RFC] powercap/drivers/energy_model: protocode: Add powercap energy model based
Hi Daniel, On Tue, Jul 7, 2020 at 10:45 PM Daniel Lezcano wrote: > > On the embedded world, the complexity of the SoC leads to an > increasing number of hotspots which need to be monitored and mitigated > as a whole in order to prevent the temperature to go above the > normative and legally stated 'skin temperature'. > > Another aspect is to sustain the performance for a given power budget, > for example virtual reality where the user can feel dizziness if the > GPU performance is capped while a big CPU is processing something > else. Or reduce the battery charging because the dissipated power is > too high compared with the power consumed by other devices. > > Nowadays, the current thermal daemons are abusing the thermal > framework cooling device state to force a specific and arbitraty state typo: arbitrary > without taking care of the governor decisions. Given the closed loop > of some governors that can confuse the logic or directly enter in > a decision conflict. > > As the number of cooling device support is limited today to the CPU > and the GPU, the thermal daemons have little control on the power > dissipation of the system. The out of tree solutions are hacking > around here and there in the drivers, in the frameworks to have > control on the devices. > > The recent introduction of the energy model allows to get power > information related to a gpu or a cpu device with a limited support. > > Thanks of the current work of Lukasz Luba: > >https://lkml.org/lkml/2020/5/27/406 > > The energy model is now being improved to be generic and extended to > all devices, so giving the opportunity to SoC vendor to define the > device energy model. > > On the other side, the powercap infrastructure is a perfect fit to define > power constraints in a hierarchical way. > > The proposal is to use the powercap framework with the energy model in > order to create a hierarchy of constraints the SoC vendor is able to > define and assign a power budget on some nodes to cap the power. > > Example of constraints hierarchy: > > Soc > | > |-- gpu > | > `-- package > | > |-- perfdomain0 > | | > | |-- cpu0 > | | > | |-- cpu1 > | | > | |-- cpu2 > | | > | `-- cpu3 > | > `-- perfdomain1 > | > |-- cpu4 > | > `-- cpu5 > > The leaves of the tree are the real devices, the intermediate nodes > are virtual, aggregating the children constraints and power Consider rephrasing as: aggregating the constraints and power characteristics of their children. > characteristics. > > For example: cpu[0-3] have 179mW max, 'perfdomain0' has 716mW max, > cpu[4-5] have 1130mw max each, 'perfordomain1' has 2260mW. It results > 'package' has 2260 + 716 = 2976mW max. > > Each node have a weight on a 2^10 basis, in order to reflect the Consider rephrasing as: node has a weight on a scale of 0 to 1024 > percentage of power distribution of the children's node. This > percentage is used to dispatch the power limit to the children. > > For example: package has 2976mW max, the weigths for the children are: typo: weights > > perfdomain0: (716 * 1024) / 2976 = 246 > perfdomain1: (2260 * 1024) / 2976 = 778 > > If we want to apply a power limit constraint of 1500mW at the package > level, the power limit will be distributed along the children as: > > perfdomain0: (1500 * 246) / 1024 = 360mW > perfdomain1: (1500 * 778) / 1024 = 1140mW > > This simple approach allows to do a fair distribution of the power > limit but it will be replaced by a more complex mechanism where the > power limit will be dynamically adjusted depending on the power > consumption of the different devices. This is an algorithm with auto > power balancing with unused power. When an allocated power budget is > not used by a device, the siblings can share this free power until the > device needs more power. > > The algorithm was presented during the ELC: > > https://ossna2020.sched.com/event/c3Wf/ideas-for-finer-grained-control-over-your-heat-budget-amit-kucheria-daniel-lezcano-linaro > > Given the complexity of the code, it sounds reasonable to provide a > first stone of the edifice allowing at least the thermal daemons to > stop abusing the thermal framework where the primary goal is to > protect the silicone, not cap the power. typo: silicon > > However, one question remains: how do we describe the hierarchy? > Signed-off-by: Daniel Lezcano > --- > drivers/powercap/Kconfig | 8 + > dr
Re: [PATCH 7/7] cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify code
On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
wrote:
>
> devm_platform_ioremap_resource() is the combination of
> platform_get_resource() and devm_ioremap_resource(). Hence, use it to
> simplify the code a bit.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Amit Kucheria
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> b/drivers/cpufreq/qcom-cpufreq-hw.c
> index c3c397cc3dc6..6eeeb2bd4dfa 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -307,7 +307,6 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
> *policy)
> struct of_phandle_args args;
> struct device_node *cpu_np;
> struct device *cpu_dev;
> - struct resource *res;
> void __iomem *base;
> struct qcom_cpufreq_data *data;
> const struct of_device_id *match;
> @@ -333,13 +332,9 @@ static int qcom_cpufreq_hw_cpu_init(struct
> cpufreq_policy *policy)
>
> index = args.args[0];
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> - if (!res)
> - return -ENODEV;
> -
> - base = devm_ioremap(dev, res->start, resource_size(res));
> - if (!base)
> - return -ENOMEM;
> + base = devm_platform_ioremap_resource(pdev, index);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data) {
> --
> 2.17.1
>
Re: [PATCH 4/7] cpufreq: qcom-hw: Make use of of_match data for offsets and row size
On Tue, Sep 8, 2020 at 8:40 PM Manivannan Sadhasivam
wrote:
>
> On 0908, Amit Kucheria wrote:
> > On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
> > wrote:
> > >
> > > For preparing the driver to handle further SoC revisions, let's use the
> > > of_match data for getting the device specific offsets and row size instead
> > > of defining them globally.
> > >
> > > Signed-off-by: Manivannan Sadhasivam
> >
> >
> >
> > > ---
> > > drivers/cpufreq/qcom-cpufreq-hw.c | 96 +--
> > > 1 file changed, 66 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > index ccea34f61152..41853db7c9b8 100644
> > > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > @@ -19,15 +19,21 @@
> > > #define LUT_L_VAL GENMASK(7, 0)
> > > #define LUT_CORE_COUNT GENMASK(18, 16)
> > > #define LUT_VOLT GENMASK(11, 0)
> > > -#define LUT_ROW_SIZE 32
> > > #define CLK_HW_DIV 2
> > > #define LUT_TURBO_IND 1
> > >
> > > -/* Register offsets */
> > > -#define REG_ENABLE 0x0
> > > -#define REG_FREQ_LUT 0x110
> > > -#define REG_VOLT_LUT 0x114
> > > -#define REG_PERF_STATE 0x920
> > > +struct qcom_cpufreq_soc_data {
> > > + u32 reg_enable;
> > > + u32 reg_freq_lut;
> > > + u32 reg_volt_lut;
> > > + u32 reg_perf_state;
> > > + u8 lut_row_size;
> > > +};
> > > +
> > > +struct qcom_cpufreq_data {
> > > + void __iomem *base;
> > > + const struct qcom_cpufreq_soc_data *soc_data;
> > > +};
> > >
> > > static unsigned long cpu_hw_rate, xo_rate;
> > > static bool icc_scaling_enabled;
> > > @@ -76,10 +82,11 @@ static int qcom_cpufreq_update_opp(struct device
> > > *cpu_dev,
> > > static int qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
> > > unsigned int index)
> > > {
> > > - void __iomem *perf_state_reg = policy->driver_data;
> > > + struct qcom_cpufreq_data *data = policy->driver_data;
> > > + const struct qcom_cpufreq_soc_data *soc_data = data->soc_data;
> > > unsigned long freq = policy->freq_table[index].frequency;
> > >
> > > - writel_relaxed(index, perf_state_reg);
> > > + writel_relaxed(index, data->base + soc_data->reg_perf_state);
> > >
> > > if (icc_scaling_enabled)
> > > qcom_cpufreq_set_bw(policy, freq);
> > > @@ -91,7 +98,8 @@ static int qcom_cpufreq_hw_target_index(struct
> > > cpufreq_policy *policy,
> > >
> > > static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
> > > {
> > > - void __iomem *perf_state_reg;
> > > + struct qcom_cpufreq_data *data;
> > > + const struct qcom_cpufreq_soc_data *soc_data;
> > > struct cpufreq_policy *policy;
> > > unsigned int index;
> > >
> > > @@ -99,9 +107,10 @@ static unsigned int qcom_cpufreq_hw_get(unsigned int
> > > cpu)
> > > if (!policy)
> > > return 0;
> > >
> > > - perf_state_reg = policy->driver_data;
> > > + data = policy->driver_data;
> > > + soc_data = data->soc_data;
> > >
> > > - index = readl_relaxed(perf_state_reg);
> > > + index = readl_relaxed(data->base + soc_data->reg_perf_state);
> > > index = min(index, LUT_MAX_ENTRIES - 1);
> > >
> > > return policy->freq_table[index].frequency;
> > > @@ -110,12 +119,13 @@ static unsigned int qcom_cpufreq_hw_get(unsigned
> > > int cpu)
> > > static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy
> > > *policy,
> > > unsigned int target_freq)
> > > {
> > > - void __iomem *perf_state_reg = policy->driver_data;
> > > + struct qcom_cpufreq_data *data = policy->driver_data;
> > > + const struct qcom_cpufreq_soc_data *soc_data = data->soc_data;
> > >
Re: [PATCH 2/7] arm64: dts: qcom: sm8250: Add cpufreq hw node
On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
wrote:
>
> From: Bjorn Andersson
>
> Add cpufreq HW device node to scale 4-Silver/3-Gold/1-Gold+ cores
> on SM8250 SoCs.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index e7d139e1a6ce..aafb46a26a9c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -87,6 +87,7 @@
> reg = <0x0 0x0>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + qcom,freq-domain = <_hw 0>;
> L2_0: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -102,6 +103,7 @@
> reg = <0x0 0x100>;
> enable-method = "psci";
> next-level-cache = <_100>;
> + qcom,freq-domain = <_hw 0>;
> L2_100: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -114,6 +116,7 @@
> reg = <0x0 0x200>;
> enable-method = "psci";
> next-level-cache = <_200>;
> + qcom,freq-domain = <_hw 0>;
> L2_200: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -126,6 +129,7 @@
> reg = <0x0 0x300>;
> enable-method = "psci";
> next-level-cache = <_300>;
> + qcom,freq-domain = <_hw 0>;
> L2_300: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -138,6 +142,7 @@
> reg = <0x0 0x400>;
> enable-method = "psci";
> next-level-cache = <_400>;
> + qcom,freq-domain = <_hw 1>;
> L2_400: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -150,6 +155,7 @@
> reg = <0x0 0x500>;
> enable-method = "psci";
> next-level-cache = <_500>;
> + qcom,freq-domain = <_hw 1>;
> L2_500: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -163,6 +169,7 @@
> reg = <0x0 0x600>;
> enable-method = "psci";
> next-level-cache = <_600>;
> + qcom,freq-domain = <_hw 1>;
> L2_600: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -175,6 +182,7 @@
> reg = <0x0 0x700>;
> enable-method = "psci";
> next-level-cache = <_700>;
> + qcom,freq-domain = <_hw 2>;
> L2_700: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> @@ -2076,6 +2084,20 @@
> };
> };
> };
> +
> + cpufreq_hw: cpufreq@18591000 {
> + compatible = "qcom,sm8250-epss";
> + reg = <0 0x18591000 0 0x1000>,
> + <0 0x18592000 0 0x1000>,
> + <0 0x18593000 0 0x1000>;
> + reg-names = "freq-domain0", "freq-domain1",
> + "freq-domain2";
> +
> + clocks = < RPMH_CXO_CLK>, < GPLL0>;
> + clock-names = "xo", "alternate";
> +
> + #freq-domain-cells = <1>;
> + };
> };
>
> timer {
> --
> 2.17.1
>
Re: [PATCH 5/7] cpufreq: qcom-hw: Use regmap for accessing hardware registers
On Tue, Sep 8, 2020 at 5:18 PM Amit Kucheria wrote: > > On Tue, Sep 8, 2020 at 4:48 PM Viresh Kumar wrote: > > > > On 08-09-20, 16:41, Manivannan Sadhasivam wrote: > > > On 0908, Viresh Kumar wrote: > > > > On 08-09-20, 13:27, Manivannan Sadhasivam wrote: > > > > > Use regmap for accessing cpufreq registers in hardware. > > > > > > > > Why ? Please mention why a change is required in the log. > > > > > > > > > > Only because it is recommended to use regmap for abstracting the hw > > > access. > > > > Yes it can be very useful in abstracting the hw access in case of > > busses like SPI/I2C, others, but in this case there is only one way of > > doing it with the exact same registers. I am not sure it is worth it > > here. FWIW, I have never played with regmaps personally, and so every > > chance I can be wrong here. > > One could handle the reg offsets through a struct initialisation, but > then you end up with lots of #defines for bitmasks and bits for each > version of the IP. And the core code becomes a bit convoluted IMO, > trying to handle the differences. > > regmap hides the differences of the bit positions and register offsets > between several IP versions. > > > > Moreover it handles the proper locking for us in the core (spinlock vs > > > mutex). > > > > What locking do you need here ? > > Right, locking isn't the main reason here. Having said this, perhaps this patch can be held back for now, since we're not yet using some of the features of regmap to abstract away bit fields and such. We don't strictly need it for just different register offsets. Regards, Amit
Re: [PATCH 1/7] dt-bindings: cpufreq: cpufreq-qcom-hw: Document SM8250 compatible
On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam wrote: > > Document the SM8250 SoC specific compatible for Qualcomm Cpufreq HW. The > hardware block which carries out CPUFreq operations on SM8250 SoC is > called EPSS. > > Signed-off-by: Manivannan Sadhasivam Reviewed-by: Amit Kucheria > --- > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > index 33856947c561..aea4ddb2b9e8 100644 > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > @@ -8,7 +8,7 @@ Properties: > - compatible > Usage: required > Value type: > - Definition: must be "qcom,cpufreq-hw". > + Definition: must be "qcom,cpufreq-hw" or "qcom,sm8250-epss". > > - clocks > Usage: required > -- > 2.17.1 >
Re: [PATCH 4/7] cpufreq: qcom-hw: Make use of of_match data for offsets and row size
On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
wrote:
>
> For preparing the driver to handle further SoC revisions, let's use the
> of_match data for getting the device specific offsets and row size instead
> of defining them globally.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 96 +--
> 1 file changed, 66 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> b/drivers/cpufreq/qcom-cpufreq-hw.c
> index ccea34f61152..41853db7c9b8 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -19,15 +19,21 @@
> #define LUT_L_VAL GENMASK(7, 0)
> #define LUT_CORE_COUNT GENMASK(18, 16)
> #define LUT_VOLT GENMASK(11, 0)
> -#define LUT_ROW_SIZE 32
> #define CLK_HW_DIV 2
> #define LUT_TURBO_IND 1
>
> -/* Register offsets */
> -#define REG_ENABLE 0x0
> -#define REG_FREQ_LUT 0x110
> -#define REG_VOLT_LUT 0x114
> -#define REG_PERF_STATE 0x920
> +struct qcom_cpufreq_soc_data {
> + u32 reg_enable;
> + u32 reg_freq_lut;
> + u32 reg_volt_lut;
> + u32 reg_perf_state;
> + u8 lut_row_size;
> +};
> +
> +struct qcom_cpufreq_data {
> + void __iomem *base;
> + const struct qcom_cpufreq_soc_data *soc_data;
> +};
>
> static unsigned long cpu_hw_rate, xo_rate;
> static bool icc_scaling_enabled;
> @@ -76,10 +82,11 @@ static int qcom_cpufreq_update_opp(struct device *cpu_dev,
> static int qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
> unsigned int index)
> {
> - void __iomem *perf_state_reg = policy->driver_data;
> + struct qcom_cpufreq_data *data = policy->driver_data;
> + const struct qcom_cpufreq_soc_data *soc_data = data->soc_data;
> unsigned long freq = policy->freq_table[index].frequency;
>
> - writel_relaxed(index, perf_state_reg);
> + writel_relaxed(index, data->base + soc_data->reg_perf_state);
>
> if (icc_scaling_enabled)
> qcom_cpufreq_set_bw(policy, freq);
> @@ -91,7 +98,8 @@ static int qcom_cpufreq_hw_target_index(struct
> cpufreq_policy *policy,
>
> static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
> {
> - void __iomem *perf_state_reg;
> + struct qcom_cpufreq_data *data;
> + const struct qcom_cpufreq_soc_data *soc_data;
> struct cpufreq_policy *policy;
> unsigned int index;
>
> @@ -99,9 +107,10 @@ static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
> if (!policy)
> return 0;
>
> - perf_state_reg = policy->driver_data;
> + data = policy->driver_data;
> + soc_data = data->soc_data;
>
> - index = readl_relaxed(perf_state_reg);
> + index = readl_relaxed(data->base + soc_data->reg_perf_state);
> index = min(index, LUT_MAX_ENTRIES - 1);
>
> return policy->freq_table[index].frequency;
> @@ -110,12 +119,13 @@ static unsigned int qcom_cpufreq_hw_get(unsigned int
> cpu)
> static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy
> *policy,
> unsigned int target_freq)
> {
> - void __iomem *perf_state_reg = policy->driver_data;
> + struct qcom_cpufreq_data *data = policy->driver_data;
> + const struct qcom_cpufreq_soc_data *soc_data = data->soc_data;
> unsigned int index;
> unsigned long freq;
>
> index = policy->cached_resolved_idx;
> - writel_relaxed(index, perf_state_reg);
> + writel_relaxed(index, data->base + soc_data->reg_perf_state);
>
> freq = policy->freq_table[index].frequency;
> arch_set_freq_scale(policy->related_cpus, freq,
> @@ -125,8 +135,7 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct
> cpufreq_policy *policy,
> }
>
> static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
> - struct cpufreq_policy *policy,
> - void __iomem *base)
> + struct cpufreq_policy *policy)
> {
> u32 data, src, lval, i, core_count, prev_freq = 0, freq;
> u32 volt;
> @@ -134,6 +143,8 @@ static int qcom_cpufreq_hw_read_lut(struct device
> *cpu_dev,
> struct dev_pm_opp *opp;
> unsigned long rate;
> int ret;
> + struct qcom_cpufreq_data *drv_data = policy->driver_data;
> + const struct qcom_cpufreq_soc_data *soc_data = drv_data->soc_data;
>
> table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
> if (!table)
> @@ -160,14 +171,14 @@ static int qcom_cpufreq_hw_read_lut(struct device
> *cpu_dev,
> }
>
> for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> - data = readl_relaxed(base +
Re: [PATCH 6/7] cpufreq: qcom-hw: Add cpufreq support for SM8250 SoC
On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
wrote:
>
> SM8250 SoC uses EPSS block for carrying out the cpufreq duties. Hence, add
> support for it in the driver with relevant of_match data.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Amit Kucheria
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> b/drivers/cpufreq/qcom-cpufreq-hw.c
> index de816bcafd33..c3c397cc3dc6 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -285,8 +285,17 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data
> = {
> .lut_row_size = 32,
> };
>
> +static const struct qcom_cpufreq_soc_data sm8250_soc_data = {
> + .reg_enable = 0x0,
> + .reg_freq_lut = 0x100,
> + .reg_volt_lut = 0x200,
> + .reg_perf_state = 0x320,
> + .lut_row_size = 4,
> +};
> +
> static const struct of_device_id qcom_cpufreq_hw_match[] = {
> { .compatible = "qcom,cpufreq-hw", .data = _soc_data },
> + { .compatible = "qcom,sm8250-epss", .data = _soc_data },
> {}
> };
> MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> --
> 2.17.1
>
Re: [PATCH 5/7] cpufreq: qcom-hw: Use regmap for accessing hardware registers
On Tue, Sep 8, 2020 at 4:48 PM Viresh Kumar wrote: > > On 08-09-20, 16:41, Manivannan Sadhasivam wrote: > > On 0908, Viresh Kumar wrote: > > > On 08-09-20, 13:27, Manivannan Sadhasivam wrote: > > > > Use regmap for accessing cpufreq registers in hardware. > > > > > > Why ? Please mention why a change is required in the log. > > > > > > > Only because it is recommended to use regmap for abstracting the hw access. > > Yes it can be very useful in abstracting the hw access in case of > busses like SPI/I2C, others, but in this case there is only one way of > doing it with the exact same registers. I am not sure it is worth it > here. FWIW, I have never played with regmaps personally, and so every > chance I can be wrong here. One could handle the reg offsets through a struct initialisation, but then you end up with lots of #defines for bitmasks and bits for each version of the IP. And the core code becomes a bit convoluted IMO, trying to handle the differences. regmap hides the differences of the bit positions and register offsets between several IP versions. > > Moreover it handles the proper locking for us in the core (spinlock vs > > mutex). > > What locking do you need here ? Right, locking isn't the main reason here. > > > I've seen many subsystem maintainers prefer regmap over plain readl/writel > > calls. I'll add the reason in commit log. > > I am not sure if it is worth it here.
Re: [PATCH] thermal: sysfs: Fall back to vmalloc() for cooling device's statistics
On Fri, Aug 21, 2020 at 8:14 AM Yue Hu wrote:
>
> From: Yue Hu
>
> We observed warning about kzalloc() when register thermal cooling device
> in backlight_device_register(). backlight display can be a cooling device
> since reducing screen brightness will can help reduce temperature.
>
> However, ->get_max_state of backlight will assign max brightness of 1024
> to states. The memory size can be getting 1MB+ due to states * states.
> That is so large to trigger kmalloc() warning.
>
> So, let's use kvzalloc() to avoid the issue, also change kfree -> kvfree.
>
> Suggested-by: Amit Kucheria
> Signed-off-by: Yue Hu
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/thermal_sysfs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb..d1703ee 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -919,7 +920,7 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
> var += sizeof(*stats->time_in_state) * states;
> var += sizeof(*stats->trans_table) * states * states;
>
> - stats = kzalloc(var, GFP_KERNEL);
> + stats = kvzalloc(var, GFP_KERNEL);
> if (!stats)
> return;
>
> @@ -938,7 +939,7 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
>
> static void cooling_device_stats_destroy(struct thermal_cooling_device *cdev)
> {
> - kfree(cdev->stats);
> + kvfree(cdev->stats);
> cdev->stats = NULL;
> }
>
> --
> 1.9.1
>
Re: [PATCH 2/2 v2] arm64: dts: ls208xa: add more thermal zone support
On Wed, Jul 15, 2020 at 12:25 PM wrote:
>
> From: Yuantian Tang
>
> There are 7 thermal zones in ls208xa soc. Add the other thermal zone
> nodes to enable them.
>
> Signed-off-by: Yuantian Tang
Reviewed-by: Amit Kucheria
> ---
> v2:
> - remove useless alert trip
> - add cooling-map to core cluster zones.
>
> .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 141 --
> 1 file changed, 132 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 41102dacc2e1..cc36c969dd9d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -79,20 +79,62 @@
> };
>
> thermal-zones {
> - cpu_thermal: cpu-thermal {
> + ddr-controller1 {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> + thermal-sensors = < 1>;
>
> + trips {
> + ddr-ctrler1-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + ddr-controller2 {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 2>;
> +
> + trips {
> + ddr-ctrler2-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + ddr-controller3 {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 3>;
> +
> + trips {
> + ddr-ctrler3-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + core-cluster1 {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> thermal-sensors = < 4>;
>
> trips {
> - cpu_alert: cpu-alert {
> - temperature = <75000>;
> + core_cluster1_alert: core-cluster1-alert {
> + temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
> - cpu_crit: cpu-crit {
> - temperature = <85000>;
> +
> + core-cluster1-crit {
> + temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> };
> @@ -100,14 +142,95 @@
>
> cooling-maps {
> map0 {
> - trip = <_alert>;
> + trip = <_cluster1_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> - < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +
> + core-cluster2 {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> +
Re: [PATCH 1/2 v2] arm64: dts: ls1088a: add more thermal zone support
On Wed, Jul 15, 2020 at 12:25 PM wrote:
>
> From: Yuantian Tang
>
> There are 2 thermal zones in ls1088a soc. Add the other thermal zone
> node to enable it.
> Also update the values in calibration table to make the temperatures
> monitored more precise.
>
> Signed-off-by: Yuantian Tang
Reviewed-by: Amit Kucheria
> ---
> v2:
> - remove useless alert trip
>
> .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 94 +++
> 1 file changed, 56 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 169f4742ae3b..b961a896ede7 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -130,19 +130,19 @@
> };
>
> thermal-zones {
> - cpu_thermal: cpu-thermal {
> + core-cluster {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 0>;
>
> trips {
> - cpu_alert: cpu-alert {
> + core_cluster_alert: core-cluster-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - cpu_crit: cpu-crit {
> + core-cluster-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> @@ -151,7 +151,7 @@
>
> cooling-maps {
> map0 {
> - trip = <_alert>;
> + trip = <_cluster_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> @@ -164,6 +164,20 @@
> };
> };
> };
> +
> + soc {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 1>;
> +
> + trips {
> + soc-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> };
>
> timer {
> @@ -210,45 +224,49 @@
> compatible = "fsl,qoriq-tmu";
> reg = <0x0 0x1f8 0x0 0x1>;
> interrupts = <0 23 0x4>;
> - fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
> + fsl,tmu-range = <0xb 0x9002a 0x6004c 0x70062>;
> fsl,tmu-calibration =
> /* Calibration data group 1 */
> - <0x 0x0026
> - 0x0001 0x002d
> - 0x0002 0x0032
> - 0x0003 0x0039
> - 0x0004 0x003f
> - 0x0005 0x0046
> - 0x0006 0x004d
> - 0x0007 0x0054
> - 0x0008 0x005a
> - 0x0009 0x0061
> - 0x000a 0x006a
> - 0x000b 0x0071
> + <0x 0x0023
> + 0x0001 0x002a
> + 0x0002 0x0030
> + 0x0003 0x0037
> + 0x0004 0x003d
> + 0x0005 0x0044
> + 0x0006 0x004a
> +
Re: [PATCH] thermal: sysfs: fall back to vzalloc for cooling device's statistics
On Tue, Aug 18, 2020 at 12:00 PM Yue Hu wrote:
>
> From: Yue Hu
>
> We observed warning about kzalloc() when register thermal cooling device
> in backlight_device_register(). backlight display can be a cooling device
> since reducing screen brightness will can help reduce temperature.
>
> However, ->get_max_state of backlight will assign max brightness of 1024
> to states. The memory size can be getting 1MB+ due to states * states.
> That is so large to trigger kmalloc() warning.
>
> So, let's remove it and try vzalloc() if kzalloc() fails.
>
> Signed-off-by: Yue Hu
> ---
> drivers/thermal/thermal_sysfs.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb..9bae0b6 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -919,7 +921,9 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
> var += sizeof(*stats->time_in_state) * states;
> var += sizeof(*stats->trans_table) * states * states;
>
> - stats = kzalloc(var, GFP_KERNEL);
> + stats = kzalloc(var, GFP_KERNEL | __GFP_NOWARN);
> + if (!stats)
> + stats = vzalloc(var);
Couldn't this be replaced by kvzalloc()?
> if (!stats)
> return;
>
> @@ -938,7 +942,7 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
>
> static void cooling_device_stats_destroy(struct thermal_cooling_device *cdev)
> {
> - kfree(cdev->stats);
> + kvfree(cdev->stats);
> cdev->stats = NULL;
> }
>
> --
> 1.9.1
>
Re: [PATCH] thermal: sysfs: fall back to vzalloc for cooling device's statistics
On Tue, Aug 18, 2020 at 12:00 PM Yue Hu wrote:
>
> From: Yue Hu
>
> We observed warning about kzalloc() when register thermal cooling device
> in backlight_device_register(). backlight display can be a cooling device
> since reducing screen brightness will can help reduce temperature.
>
> However, ->get_max_state of backlight will assign max brightness of 1024
> to states. The memory size can be getting 1MB+ due to states * states.
> That is so large to trigger kmalloc() warning.
>
> So, let's remove it and try vzalloc() if kzalloc() fails.
If we can do with vzalloc()'ed memory i.e. we don't need contiguous
physical memory, why even attempt kzalloc?
>
> Signed-off-by: Yue Hu
> ---
> drivers/thermal/thermal_sysfs.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb..9bae0b6 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -919,7 +921,9 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
> var += sizeof(*stats->time_in_state) * states;
> var += sizeof(*stats->trans_table) * states * states;
>
> - stats = kzalloc(var, GFP_KERNEL);
> + stats = kzalloc(var, GFP_KERNEL | __GFP_NOWARN);
> + if (!stats)
> + stats = vzalloc(var);
> if (!stats)
> return;
>
> @@ -938,7 +942,7 @@ static void cooling_device_stats_setup(struct
> thermal_cooling_device *cdev)
>
> static void cooling_device_stats_destroy(struct thermal_cooling_device *cdev)
> {
> - kfree(cdev->stats);
> + kvfree(cdev->stats);
> cdev->stats = NULL;
> }
>
> --
> 1.9.1
>
Re: [RFC PATCH v5 1/7] drivers: thermal: tsens: Add VER_0 tsens version
On Tue, Aug 11, 2020 at 6:48 PM wrote:
>
>
>
> > -Messaggio originale-----
> > Da: Amit Kucheria
> >
> > > if (IS_ERR(priv->rf[i]))
> > > return PTR_ERR(priv->rf[i]);
> > > }
> > > @@ -775,12 +800,80 @@ int __init init_common(struct tsens_priv
> > *priv)
> > > goto err_put_device;
> > > }
> > >
> > > - priv->rf[TSENS_EN] = devm_regmap_field_alloc(dev, priv->srot_map,
> > > -
> > > priv->fields[TSENS_EN]);
> > > - if (IS_ERR(priv->rf[TSENS_EN])) {
> > > - ret = PTR_ERR(priv->rf[TSENS_EN]);
> > > - goto err_put_device;
> > > + if (tsens_version(priv) >= VER_0_1) {
> > > + priv->rf[TSENS_EN] = devm_regmap_field_alloc(
> > > + dev, priv->srot_map, priv->fields[TSENS_EN]);
> > > + if (IS_ERR(priv->rf[TSENS_EN])) {
> > > + ret = PTR_ERR(priv->rf[TSENS_EN]);
> > > + goto err_put_device;
> > > + }
> > > +
> > > + priv->rf[SENSOR_EN] = devm_regmap_field_alloc(
> > > + dev, priv->srot_map, priv->fields[SENSOR_EN]);
> > > + if (IS_ERR(priv->rf[SENSOR_EN])) {
> > > + ret = PTR_ERR(priv->rf[SENSOR_EN]);
> > > + goto err_put_device;
> > > + }
> > > + priv->rf[INT_EN] = devm_regmap_field_alloc(
> > > + dev, priv->tm_map, priv->fields[INT_EN]);
> > > + if (IS_ERR(priv->rf[INT_EN])) {
> > > + ret = PTR_ERR(priv->rf[INT_EN]);
> > > + goto err_put_device;
> > > + }
> > > + } else {
> >
> > Let's not create two big sections with if-else for 8960 and everything
> > else. For example, what is wrong with using common code for TSENS_EN?
> >
> > If the concern is memory wasted trying to allocate fields not present
> > on this older platform, perhaps consider adding a check in the loop to
> > break early in case of 8960?
> >
>
> About TSENS_EN the old platform doesn't have SROT so I need to use TM_MAP.
> Should I set the srot map to match the tm map so we can use the common
> function?
> Aside from this problem, I will try to remove the big if-else.
Ick. I guess srot_map and tm_map pointing to the same region is the
lesser of two evils? It makes it so this will be constrained to a
single place in init_common().
Re: [RFC PATCH v5 2/7] drivers: thermal: tsens: Convert msm8960 to reg_field
On Sat, Jul 25, 2020 at 11:44 PM Ansuel Smith wrote:
>
> Covert msm9860 driver to reg_filed to use the init_common
typo: field
> function.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens-8960.c | 74 +++
> 1 file changed, 74 insertions(+)
>
> diff --git a/drivers/thermal/qcom/tsens-8960.c
> b/drivers/thermal/qcom/tsens-8960.c
> index 2a28a5af209e..45cd0cdff2f5 100644
> --- a/drivers/thermal/qcom/tsens-8960.c
> +++ b/drivers/thermal/qcom/tsens-8960.c
> @@ -56,6 +56,18 @@
> #define TRDY_MASK BIT(7)
> #define TIMEOUT_US 100
>
> +#define S0_STATUS_OFF 0x3628
> +#define S1_STATUS_OFF 0x362c
> +#define S2_STATUS_OFF 0x3630
> +#define S3_STATUS_OFF 0x3634
> +#define S4_STATUS_OFF 0x3638
> +#define S5_STATUS_OFF 0x3664 /* Sensors 5 thru 10 found on
> apq8064/msm8960 */
Run checkpatch and fix spelling. :-) Or just say 'sensor 5-10'
> +#define S6_STATUS_OFF 0x3668
> +#define S7_STATUS_OFF 0x366c
> +#define S8_STATUS_OFF 0x3670
> +#define S9_STATUS_OFF 0x3674
> +#define S10_STATUS_OFF 0x3678
> +
> static int suspend_8960(struct tsens_priv *priv)
> {
> int ret;
> @@ -269,6 +281,66 @@ static int get_temp_8960(const struct tsens_sensor *s,
> int *temp)
> return -ETIMEDOUT;
> }
>
> +static struct tsens_features tsens_8960_feat = {
> + .ver_major = VER_0,
> + .crit_int = 0,
> + .adc= 1,
> + .srot_split = 0,
> + .max_sensors= 11,
Align the equal to like in other files please.
> +};
> +
> +static const struct reg_field tsens_8960_regfields[MAX_REGFIELDS] = {
> + /* - SROT -- */
> + /* No VERSION information */
> +
> + /* CNTL */
> + [TSENS_EN] = REG_FIELD(CNTL_ADDR, 0, 0),
> + [TSENS_SW_RST] = REG_FIELD(CNTL_ADDR, 1, 1),
> + /* 8960 has 5 sensors, 8660 has 11, we only handle 5 */
> + [SENSOR_EN]= REG_FIELD(CNTL_ADDR, 3, 7),
> +
> + /* - TM -- */
> + /* INTERRUPT ENABLE */
> + // [INT_EN] = REG_FIELD(TM_INT_EN_OFF, 0, 0),
Get rid of these comments and at the very least use C-style comments.
> +
> + /* Single UPPER/LOWER TEMPERATURE THRESHOLD for all sensors */
> + [LOW_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 0, 7),
> + [UP_THRESH_0]= REG_FIELD(THRESHOLD_ADDR, 8, 15),
> + [MIN_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 16, 23),
> + [MAX_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 24, 31),
> +
> + // /* UPPER/LOWER INTERRUPT [CLEAR/STATUS] */
> + // /* 1 == clear, 0 == normal operation */
Get rid of these comments and at the very least use C-style comments.
> + [LOW_INT_CLEAR_0] = REG_FIELD(CNTL_ADDR, 9, 9),
> + [UP_INT_CLEAR_0]= REG_FIELD(CNTL_ADDR, 10, 10),
> +
> + /* NO CRITICAL INTERRUPT SUPPORT on 8960 */
> +
> + /* Sn_STATUS */
> + [LAST_TEMP_0] = REG_FIELD(S0_STATUS_OFF, 0, 7),
> + [LAST_TEMP_1] = REG_FIELD(S1_STATUS_OFF, 0, 7),
> + [LAST_TEMP_2] = REG_FIELD(S2_STATUS_OFF, 0, 7),
> + [LAST_TEMP_3] = REG_FIELD(S3_STATUS_OFF, 0, 7),
> + [LAST_TEMP_4] = REG_FIELD(S4_STATUS_OFF, 0, 7),
> + [LAST_TEMP_5] = REG_FIELD(S5_STATUS_OFF, 0, 7),
> + [LAST_TEMP_6] = REG_FIELD(S6_STATUS_OFF, 0, 7),
> + [LAST_TEMP_7] = REG_FIELD(S7_STATUS_OFF, 0, 7),
> + [LAST_TEMP_8] = REG_FIELD(S8_STATUS_OFF, 0, 7),
> + [LAST_TEMP_9] = REG_FIELD(S9_STATUS_OFF, 0, 7),
> + [LAST_TEMP_10] = REG_FIELD(S10_STATUS_OFF, 0, 7),
> +
> + /* No VALID field on 8960 */
> + /* TSENS_INT_STATUS bits: 1 == threshold violated */
> + [MIN_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 0, 0),
> + [LOWER_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 1, 1),
> + [UPPER_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 2, 2),
> + /* No CRITICAL field on 8960 */
> + [MAX_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 3, 3),
> +
> + /* TRDY: 1=ready, 0=in progress */
> + [TRDY] = REG_FIELD(INT_STATUS_ADDR, 7, 7),
> +};
> +
> static const struct tsens_ops ops_8960 = {
> .init = init_8960,
> .calibrate = calibrate_8960,
> @@ -282,4 +354,6 @@ static const struct tsens_ops ops_8960 = {
> struct tsens_plat_data data_8960 = {
> .num_sensors= 11,
> .ops= _8960,
> + .feat = _8960_feat,
> + .fields = tsens_8960_regfields,
> };
> --
> 2.27.0
>
Re: [RFC PATCH v5 1/7] drivers: thermal: tsens: Add VER_0 tsens version
On Sat, Jul 25, 2020 at 11:44 PM Ansuel Smith wrote:
>
> VER_0 is used to describe device based on tsens version before v0.1.
> These device are devices based on msm8960 for example apq8064 or
> ipq806x.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens.c | 160 +++
> drivers/thermal/qcom/tsens.h | 7 +-
> 2 files changed, 132 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 9fe9a2b26705..78840c1bc5d2 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -516,6 +516,15 @@ static irqreturn_t tsens_irq_thread(int irq, void *data)
> dev_dbg(priv->dev, "[%u] %s: no violation: %d\n",
> hw_id, __func__, temp);
> }
> +
> + if (tsens_version(priv) < VER_0_1) {
> + /* Constraint: There is only 1 interrupt control
> register for all
> +* 11 temperature sensor. So monitoring more than 1
> sensor based
> +* on interrupts will yield inconsistent result. To
> overcome this
> +* issue we will monitor only sensor 0 which is the
> master sensor.
> +*/
> + break;
> + }
> }
>
> return IRQ_HANDLED;
> @@ -531,6 +540,13 @@ static int tsens_set_trips(void *_sensor, int low, int
> high)
> int high_val, low_val, cl_high, cl_low;
> u32 hw_id = s->hw_id;
>
> + if (tsens_version(priv) < VER_0_1) {
> + /* Pre v0.1 IP had a single register for each type of
> interrupt
> +* and thresholds
> +*/
> + hw_id = 0;
> + }
> +
> dev_dbg(dev, "[%u] %s: proposed thresholds: (%d:%d)\n",
> hw_id, __func__, low, high);
>
> @@ -550,6 +566,12 @@ static int tsens_set_trips(void *_sensor, int low, int
> high)
> tsens_set_interrupt(priv, hw_id, LOWER, true);
> tsens_set_interrupt(priv, hw_id, UPPER, true);
>
> + /* VER_0 require to set MIN and MAX THRESH */
> + if (tsens_version(priv) < VER_0_1) {
> + regmap_field_write(priv->rf[MIN_THRESH_0], 0);
> + regmap_field_write(priv->rf[MAX_THRESH_0], 12);
Since MIN_THRESH_0 and MAX_THRESH_0 are the only two threshold on pre
0.1 IP, just (mis)use the already predefined LOW_THRESH_0 and
UP_THRESH_0 in regfield_ids in init_common() below? Then we won't need
this special casing here. All the special casing ugliness can then
stay in init_common() with comments.
> + }
> +
> spin_unlock_irqrestore(>ul_lock, flags);
>
> dev_dbg(dev, "[%u] %s: (%d:%d)->(%d:%d)\n",
> @@ -584,18 +606,21 @@ int get_temp_tsens_valid(const struct tsens_sensor *s,
> int *temp)
> u32 valid;
> int ret;
>
> - ret = regmap_field_read(priv->rf[valid_idx], );
> - if (ret)
> - return ret;
> - while (!valid) {
> - /* Valid bit is 0 for 6 AHB clock cycles.
> -* At 19.2MHz, 1 AHB clock is ~60ns.
> -* We should enter this loop very, very rarely.
> -*/
> - ndelay(400);
> + /* VER_0 doesn't have VALID bit */
> + if (tsens_version(priv) >= VER_0_1) {
Since 8960 needs a custom get_temp function, is this change really needed?
> ret = regmap_field_read(priv->rf[valid_idx], );
> if (ret)
> return ret;
> + while (!valid) {
> + /* Valid bit is 0 for 6 AHB clock cycles.
> +* At 19.2MHz, 1 AHB clock is ~60ns.
> +* We should enter this loop very, very rarely.
> +*/
> + ndelay(400);
> + ret = regmap_field_read(priv->rf[valid_idx], );
> + if (ret)
> + return ret;
> + }
> }
>
> /* Valid bit is set, OK to read the temperature */
> @@ -765,8 +790,8 @@ int __init init_common(struct tsens_priv *priv)
>
> if (tsens_version(priv) > VER_0_1) {
> for (i = VER_MAJOR; i <= VER_STEP; i++) {
> - priv->rf[i] = devm_regmap_field_alloc(dev,
> priv->srot_map,
> -
> priv->fields[i]);
> + priv->rf[i] = devm_regmap_field_alloc(
> + dev, priv->srot_map, priv->fields[i]);
This doesn't change any code, simply reformats the code to 80 columns.
Avoid adding such lines to other features, makes it harder to review
changes.
Please ignore the 80 column warning here and elsewhere below when it
is only going over by a few characters. Run checkpatch on your patches
which has now increased the number of columns to 100
Re: [PATCH] cpufreq: cached_resolved_idx can not be negative
On Thu, Jul 30, 2020 at 11:40 AM Viresh Kumar wrote:
>
> On 30-07-20, 11:29, Amit Kucheria wrote:
> > On Thu, Jul 30, 2020 at 9:38 AM Viresh Kumar
> > wrote:
> > >
> > > It is not possible for cached_resolved_idx to be invalid here as the
> > > cpufreq core always sets index to a positive value.
> > >
> > > Change its type to unsigned int and fix qcom usage a bit.
> >
> > Shouldn't you fix up idx in cpufreq_driver_resolve_freq() to be
> > unsigned int too?
>
> Yes, merged this into the patch.
Looking at this more closely, I found another call site for
cpufreq_frequency_table_target() in cpufreq.c that needs the index to
be unsigned int.
But then cpufreq_frequency_table_target() returns -EINVAL, so we
should be able to handle int values.
I think you will need to fix the unconditional assignment of
policy->cached_resolved_idx = idx
in cpufreq_driver_resolve_freq(). It doesn't check for -EINVAL, so the
qcom driver is write in checking for a negative value.
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 0128de3603df..053d72e52a31 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -538,7 +538,7 @@ unsigned int cpufreq_driver_resolve_freq(struct
> cpufreq_policy *policy,
> policy->cached_target_freq = target_freq;
>
> if (cpufreq_driver->target_index) {
> - int idx;
> + unsigned int idx;
>
> idx = cpufreq_frequency_table_target(policy, target_freq,
> CPUFREQ_RELATION_L);
>
> --
> viresh
Re: [PATCH] cpufreq: cached_resolved_idx can not be negative
On Thu, Jul 30, 2020 at 9:38 AM Viresh Kumar wrote:
>
> It is not possible for cached_resolved_idx to be invalid here as the
> cpufreq core always sets index to a positive value.
>
> Change its type to unsigned int and fix qcom usage a bit.
Shouldn't you fix up idx in cpufreq_driver_resolve_freq() to be
unsigned int too?
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 5 +
> include/linux/cpufreq.h | 2 +-
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 0a04b6f03b9a..8c0842bd6c5a 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -66,13 +66,10 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct
> cpufreq_policy *policy,
> unsigned int target_freq)
> {
> void __iomem *perf_state_reg = policy->driver_data;
> - int index;
> + unsigned int index;
> unsigned long freq;
>
> index = policy->cached_resolved_idx;
> - if (index < 0)
> - return 0;
> -
> writel_relaxed(index, perf_state_reg);
>
> freq = policy->freq_table[index].frequency;
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index e62b022cb07e..58687a5bf9c8 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -127,7 +127,7 @@ struct cpufreq_policy {
>
> /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
> unsigned int cached_target_freq;
> - int cached_resolved_idx;
> + unsigned int cached_resolved_idx;
>
> /* Synchronization for frequency transitions */
> booltransition_ongoing; /* Tracks transition
> status */
> --
> 2.14.1
>
Re: [PATCH] thermal: core: Add thermal zone enable/disable notification
On Tue, Jul 28, 2020 at 4:40 AM Daniel Lezcano wrote: > > Now the calls to enable/disable a thermal zone are centralized in a > call to a function, we can add in these the corresponding netlink > notifications. > > Signed-off-by: Daniel Lezcano Reviewed-by: Amit Kucheria > --- > drivers/thermal/thermal_core.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 9748fbb9a3a1..72bf159bcecc 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -509,6 +509,11 @@ static int thermal_zone_device_set_mode(struct > thermal_zone_device *tz, > > thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED); > > + if (mode == THERMAL_DEVICE_ENABLED) > + thermal_notify_tz_enable(tz->id); > + else > + thermal_notify_tz_disable(tz->id); > + > return ret; > } > > -- > 2.17.1 >
Re: [PATCH] MAINTAINERS: update entry to thermal governors file name prefixing
On Tue, Jul 28, 2020 at 10:29 AM Lukas Bulwahn wrote:
>
> Commit 0015d9a2a727 ("thermal/governors: Prefix all source files with
> gov_") renamed power_allocator.c to gov_power_allocator.c in
> ./drivers/thermal amongst some other file renames, but missed to adjust
> the MAINTAINERS entry.
>
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matchesF:drivers/thermal/power_allocator.c
>
> Update the file entry in MAINTAINERS to the new file name.
>
> Signed-off-by: Lukas Bulwahn
Acked-by: Amit Kucheria
> ---
> Amit, please ack.
>
> Daniel, please pick this non-urgent minor patch for your -next tree.
>
> applies cleanly on next-20200727
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aad65cc8f35d..aa5a11d71f71 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17164,7 +17164,7 @@ M: Lukasz Luba
> L: linux...@vger.kernel.org
> S: Maintained
> F: Documentation/driver-api/thermal/power_allocator.rst
> -F: drivers/thermal/power_allocator.c
> +F: drivers/thermal/gov_power_allocator.c
> F: include/trace/events/thermal_power_allocator.h
>
> THINKPAD ACPI EXTRAS DRIVER
> --
> 2.17.1
>
Re: [PATCH v4 5/7] drivers: thermal: tsens: add interrupt support for 9860 driver
On Wed, Jul 22, 2020 at 12:52 AM wrote: > > > > > -Messaggio originale----- > > Da: Amit Kucheria > > Inviato: lunedì 20 luglio 2020 11:41 > > A: Ansuel Smith > > Cc: Rob Herring ; Andy Gross ; > > Bjorn Andersson ; Zhang Rui > > ; Daniel Lezcano ; > > Michael Turquette ; Stephen Boyd > > ; Linux PM list ; linux-arm- > > msm ; DTML > > ; Linux Kernel Mailing List > ker...@vger.kernel.org>; linux-clk > > Oggetto: Re: [PATCH v4 5/7] drivers: thermal: tsens: add interrupt support > > for 9860 driver > > > > Hi Ansuel, > > > > Thanks for this patch. > > > > On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith > > wrote: > > > > > > Add interrupt support for 9860 tsens driver used to set thermal trip > > > point for the system. > > > > typo: 8960 > > > > You've used the names 8960 and ipq8064 interchangeably throughout the > > series. AFAICT, msm8960, ipq8064 and apq8064 use the same IP version > > of tsens. Please use 8960 in all patches, descriptions and dt-binding. > > to reflect the filename for the driver. > > Then add ipq8064 and apq8064 in a comment in the driver like here to > > show that the driver also supports these other SoCs: > > https://elixir.bootlin.com/linux/v5.8- > > rc4/source/drivers/thermal/qcom/tsens-v0_1.c#L328 > > > > You can also add a new compatible string for ipq8064 as a separate > > patch at the end of the series. > > > > > Signed-off-by: Ansuel Smith > > > --- > > > drivers/thermal/qcom/tsens-8960.c | 197 > > +++--- > > > drivers/thermal/qcom/tsens.h | 3 + > > > 2 files changed, 186 insertions(+), 14 deletions(-) > > > > > > diff --git a/drivers/thermal/qcom/tsens-8960.c > > b/drivers/thermal/qcom/tsens-8960.c > > > index 45788eb3c666..20d0bfb10f1f 100644 > > > --- a/drivers/thermal/qcom/tsens-8960.c > > > +++ b/drivers/thermal/qcom/tsens-8960.c > > > @@ -8,6 +8,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include "tsens.h" > > > > > > @@ -27,7 +28,6 @@ > > > /* CNTL_ADDR bitmasks */ > > > #define EN BIT(0) > > > #define SW_RST BIT(1) > > > -#define SENSOR0_EN BIT(3) > > > #define SLP_CLK_ENABIT(26) > > > #define SLP_CLK_ENA_8660 BIT(24) > > > #define MEASURE_PERIOD 1 > > > @@ -41,14 +41,26 @@ > > > > > > #define THRESHOLD_ADDR 0x3624 > > > /* THRESHOLD_ADDR bitmasks */ > > > +#define THRESHOLD_MAX_CODE 0x2 > > > +#define THRESHOLD_MIN_CODE 0 > > > #define THRESHOLD_MAX_LIMIT_SHIFT 24 > > > #define THRESHOLD_MIN_LIMIT_SHIFT 16 > > > #define THRESHOLD_UPPER_LIMIT_SHIFT8 > > > #define THRESHOLD_LOWER_LIMIT_SHIFT0 > > > +#define THRESHOLD_MAX_LIMIT_MASK (THRESHOLD_MAX_CODE > > << \ > > > + THRESHOLD_MAX_LIMIT_SHIFT) > > > +#define THRESHOLD_MIN_LIMIT_MASK (THRESHOLD_MAX_CODE << > > \ > > > + THRESHOLD_MIN_LIMIT_SHIFT) > > > +#define THRESHOLD_UPPER_LIMIT_MASK (THRESHOLD_MAX_CODE > > << \ > > > + > > > THRESHOLD_UPPER_LIMIT_SHIFT) > > > +#define THRESHOLD_LOWER_LIMIT_MASK (THRESHOLD_MAX_CODE > > << \ > > > + > > > THRESHOLD_LOWER_LIMIT_SHIFT) > > > > > > /* Initial temperature threshold values */ > > > -#define LOWER_LIMIT_TH 0x50 > > > -#define UPPER_LIMIT_TH 0xdf > > > +#define LOWER_LIMIT_TH_89600x50 > > > +#define UPPER_LIMIT_TH_89600xdf > > > +#define LOWER_LIMIT_TH_80640x9d /* 95C */ > > > +#define UPPER_LIMIT_TH_80640xa6 /* 105C */ > > > #define MIN_LIMIT_TH 0x0 > > > #define MAX_LIMIT_TH 0xff > > > > > > @@ -57,6 +69,170 @@ > > > #define TRDY_MASK BIT(7) > > > #define TIMEOUT_US 100 > > > > > > +#define TSENS_EN BIT(0) > > > +#define TSENS_SW_RST BIT(1) > > > +#define TSENS_ADC_CLK_SEL BIT(2) > > > +#define SENSOR0_EN
Re: [PATCH] thermal: netlink: Fix compilation error when CONFIG_NET=n
On Tue, Jul 7, 2020 at 2:32 PM Daniel Lezcano wrote:
>
> When the network is not configured, the netlink are disabled on all
> the system. The thermal framework assumed the netlink are always
nit: s/are/is/ in both places above
> opt-in.
>
> Fix this by adding a Kconfig option for the netlink notification,
> defaulting to yes and depending on CONFIG_NET.
>
> As the change implies multiple stubs and in order to not pollute the
> internal thermal header, the thermal_nelink.h has been added and
> included in the thermal_core.h, so this one regain some kind of
> clarity.
>
> Reported-by: Randy Dunlap
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/Kconfig | 10
> drivers/thermal/Makefile | 5 +-
> drivers/thermal/thermal_core.h| 20 +--
> drivers/thermal/thermal_netlink.h | 98 +++
> 4 files changed, 114 insertions(+), 19 deletions(-)
> create mode 100644 drivers/thermal/thermal_netlink.h
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 3eb2348e5242..07983bef8d6a 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -17,6 +17,16 @@ menuconfig THERMAL
>
> if THERMAL
>
> +config THERMAL_NETLINK
> + bool "Thermal netlink management"
> + depends on NET
> + default y
> + help
> + The thermal framework has a netlink interface to do thermal
> + zones discovery, temperature readings and events such as
> + trip point crossed, cooling device update or governor
> + change. It is recommended to enable the feature.
> +
> config THERMAL_STATISTICS
> bool "Thermal state transition statistics"
> help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 1bbf0805fb04..589f6fb0d381 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,10 @@
>
> obj-$(CONFIG_THERMAL) += thermal_sys.o
> thermal_sys-y += thermal_core.o thermal_sysfs.o \
> - thermal_helpers.o thermal_netlink.o
> + thermal_helpers.o
> +
> +# netlink interface to manage the thermal framework
> +thermal_sys-$(CONFIG_THERMAL_NETLINK) += thermal_netlink.o
>
> # interface to/from other layers providing sensors
> thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index b44969d50ec0..99d065e6ed08 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -12,6 +12,8 @@
> #include
> #include
>
> +#include "thermal_netlink.h"
> +
> /* Default Thermal Governor */
> #if defined(CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE)
> #define DEFAULT_THERMAL_GOVERNOR "step_wise"
> @@ -52,24 +54,6 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>
> struct thermal_zone_device *thermal_zone_get_by_id(int id);
>
> -/* Netlink notification function */
> -int thermal_notify_tz_create(int tz_id, const char *name);
> -int thermal_notify_tz_delete(int tz_id);
> -int thermal_notify_tz_enable(int tz_id);
> -int thermal_notify_tz_disable(int tz_id);
> -int thermal_notify_tz_trip_down(int tz_id, int id);
> -int thermal_notify_tz_trip_up(int tz_id, int id);
> -int thermal_notify_tz_trip_delete(int tz_id, int id);
> -int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> - int temp, int hyst);
> -int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> - int temp, int hyst);
> -int thermal_notify_cdev_state_update(int cdev_id, int state);
> -int thermal_notify_cdev_add(int cdev_id, const char *name, int max_state);
> -int thermal_notify_cdev_delete(int cdev_id);
> -int thermal_notify_tz_gov_change(int tz_id, const char *name);
> -int thermal_genl_sampling_temp(int id, int temp);
> -
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.h
> b/drivers/thermal/thermal_netlink.h
> new file mode 100644
> index ..0ec28d105da5
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.h
> @@ -0,0 +1,98 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Linaro Ltd 2020
> + * Author: Daniel Lezcano
> + */
> +
> +/* Netlink notification function */
> +#ifdef CONFIG_THERMAL_NETLINK
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz
Re: [PATCH v4 1/7] ipq806x: gcc: add support for child probe
On Tue, Jul 21, 2020 at 11:27 AM Amit Kucheria wrote: > > > > On Tue, 21 Jul, 2020, 05:06 Stephen Boyd, wrote: >> >> Quoting Amit Kucheria (2020-07-20 02:41:44) >> > On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote: >> > > >> > > Add support for child probing needed for tsens driver that share the >> > > seme regs of gcc for this platform. >> > >> > Typo: same >> > >> >> Otherwise reviewed-by? Because I can throw this into the clk tree with >> the typo fixed. > > > Yes, the rest of the series need work imo, but this patch looks ok to > populate the child nodes in OF. > > Reviewed-by: Amit Kucheria Replied earlier from a phone, which resulted in HTML email. Resending. The rest of the series need work imo, but this patch looks ok to populate the child nodes in OF. Reviewed-by: Amit Kucheria
Re: [PATCH] dt-bindings: thermal: Get rid of thermal.txt and replace references
On Mon, Jul 20, 2020 at 5:13 PM Amit Kucheria wrote: > > Now that we have yaml bindings for the thermal subsystem, get rid of the > old bindings (thermal.txt). > > Replace all references to thermal.txt in the Documentation with a link > to the appropriate YAML bindings using the following search and replace > pattern: > - If the reference is specific to the thermal-sensor-cells property, > replace with a pointer to thermal-sensor.yaml > - If the reference is to the cooling-cells property, replace with a > pointer to thermal-cooling-devices.yaml > - If the reference is generic thermal bindings, replace with a > reference to thermal*.yaml. > > Signed-off-by: Amit Kucheria Please ignore. Forgot to add Rob's Ack and annotate with v2. Will resend. > --- > Changes since v1: > - Rebase onto v.5.8-rc6 to make it apply again > - Fix cpufreq/nvidia,tegra20-cpufreq.txt > - Fix bindings/arm/freescale/fsl,scu.txt > > > .../devicetree/bindings/arm/arm,scmi.txt | 2 +- > .../devicetree/bindings/arm/arm,scpi.txt | 2 +- > .../bindings/arm/freescale/fsl,scu.txt| 2 +- > .../arm/marvell/ap80x-system-controller.txt | 2 +- > .../arm/marvell/cp110-system-controller.txt | 2 +- > .../bindings/cpufreq/cpufreq-dt.txt | 3 +- > .../bindings/cpufreq/cpufreq-mediatek.txt | 4 +- > .../cpufreq/nvidia,tegra20-cpufreq.txt| 2 +- > .../devicetree/bindings/hwmon/gpio-fan.txt| 3 +- > .../devicetree/bindings/hwmon/lm90.txt| 4 +- > .../thermal/allwinner,sun8i-a83t-ths.yaml | 2 +- > .../bindings/thermal/amazon,al-thermal.txt| 2 +- > .../bindings/thermal/brcm,avs-ro-thermal.yaml | 2 +- > .../bindings/thermal/brcm,bcm2835-thermal.txt | 2 +- > .../bindings/thermal/hisilicon-thermal.txt| 2 +- > .../bindings/thermal/max77620_thermal.txt | 6 +- > .../bindings/thermal/mediatek-thermal.txt | 2 +- > .../thermal/nvidia,tegra124-soctherm.txt | 10 +- > .../thermal/nvidia,tegra186-bpmp-thermal.txt | 2 +- > .../bindings/thermal/qcom-spmi-temp-alarm.txt | 2 +- > .../bindings/thermal/rockchip-thermal.txt | 2 +- > .../bindings/thermal/tango-thermal.txt| 2 +- > .../bindings/thermal/thermal-generic-adc.txt | 2 +- > .../devicetree/bindings/thermal/thermal.txt | 586 -- > 24 files changed, 34 insertions(+), 616 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt > > diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt > b/Documentation/devicetree/bindings/arm/arm,scmi.txt > index 1f293ea24cd85..55deb68230ebb 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt > @@ -102,7 +102,7 @@ Required sub-node properties: > [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html > [1] Documentation/devicetree/bindings/clock/clock-bindings.txt > [2] Documentation/devicetree/bindings/power/power-domain.yaml > -[3] Documentation/devicetree/bindings/thermal/thermal.txt > +[3] Documentation/devicetree/bindings/thermal/thermal*.yaml > [4] Documentation/devicetree/bindings/sram/sram.yaml > [5] Documentation/devicetree/bindings/reset/reset.txt > > diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt > b/Documentation/devicetree/bindings/arm/arm,scpi.txt > index dd04d9d9a1b8e..bcd6c3ec471e6 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt > @@ -108,7 +108,7 @@ Required properties: > > [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html > [1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/thermal/thermal.txt > +[2] Documentation/devicetree/bindings/thermal/thermal*.yaml > [3] Documentation/devicetree/bindings/sram/sram.yaml > [4] Documentation/devicetree/bindings/power/power-domain.yaml > > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > index 10b8459e49f8c..6064d98b10314 100644 > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > @@ -176,7 +176,7 @@ Required properties: > "fsl,imx8qxp-sc-thermal" > followed by "fsl,imx-sc-thermal"; > > -- #thermal-sensor-cells: See > Documentation/devicetree/bindings/thermal/thermal.txt > +- #thermal-sensor-cells: See > Documentation/devicetree/bindings/thermal/thermal-sensor.yaml >
[PATCH] dt-bindings: thermal: Get rid of thermal.txt and replace references
Now that we have yaml bindings for the thermal subsystem, get rid of the old bindings (thermal.txt). Replace all references to thermal.txt in the Documentation with a link to the appropriate YAML bindings using the following search and replace pattern: - If the reference is specific to the thermal-sensor-cells property, replace with a pointer to thermal-sensor.yaml - If the reference is to the cooling-cells property, replace with a pointer to thermal-cooling-devices.yaml - If the reference is generic thermal bindings, replace with a reference to thermal*.yaml. Signed-off-by: Amit Kucheria --- Changes since v1: - Rebase onto v.5.8-rc6 to make it apply again - Fix cpufreq/nvidia,tegra20-cpufreq.txt - Fix bindings/arm/freescale/fsl,scu.txt .../devicetree/bindings/arm/arm,scmi.txt | 2 +- .../devicetree/bindings/arm/arm,scpi.txt | 2 +- .../bindings/arm/freescale/fsl,scu.txt| 2 +- .../arm/marvell/ap80x-system-controller.txt | 2 +- .../arm/marvell/cp110-system-controller.txt | 2 +- .../bindings/cpufreq/cpufreq-dt.txt | 3 +- .../bindings/cpufreq/cpufreq-mediatek.txt | 4 +- .../cpufreq/nvidia,tegra20-cpufreq.txt| 2 +- .../devicetree/bindings/hwmon/gpio-fan.txt| 3 +- .../devicetree/bindings/hwmon/lm90.txt| 4 +- .../thermal/allwinner,sun8i-a83t-ths.yaml | 2 +- .../bindings/thermal/amazon,al-thermal.txt| 2 +- .../bindings/thermal/brcm,avs-ro-thermal.yaml | 2 +- .../bindings/thermal/brcm,bcm2835-thermal.txt | 2 +- .../bindings/thermal/hisilicon-thermal.txt| 2 +- .../bindings/thermal/max77620_thermal.txt | 6 +- .../bindings/thermal/mediatek-thermal.txt | 2 +- .../thermal/nvidia,tegra124-soctherm.txt | 10 +- .../thermal/nvidia,tegra186-bpmp-thermal.txt | 2 +- .../bindings/thermal/qcom-spmi-temp-alarm.txt | 2 +- .../bindings/thermal/rockchip-thermal.txt | 2 +- .../bindings/thermal/tango-thermal.txt| 2 +- .../bindings/thermal/thermal-generic-adc.txt | 2 +- .../devicetree/bindings/thermal/thermal.txt | 586 -- 24 files changed, 34 insertions(+), 616 deletions(-) delete mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 1f293ea24cd85..55deb68230ebb 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -102,7 +102,7 @@ Required sub-node properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal.txt +[3] Documentation/devicetree/bindings/thermal/thermal*.yaml [4] Documentation/devicetree/bindings/sram/sram.yaml [5] Documentation/devicetree/bindings/reset/reset.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index dd04d9d9a1b8e..bcd6c3ec471e6 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -108,7 +108,7 @@ Required properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/thermal/thermal.txt +[2] Documentation/devicetree/bindings/thermal/thermal*.yaml [3] Documentation/devicetree/bindings/sram/sram.yaml [4] Documentation/devicetree/bindings/power/power-domain.yaml diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 10b8459e49f8c..6064d98b10314 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -176,7 +176,7 @@ Required properties: "fsl,imx8qxp-sc-thermal" followed by "fsl,imx-sc-thermal"; -- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt +- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example (imx8qxp): diff --git a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt index 098d932fc9630..e31511255d8e3 100644 --- a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt @@ -111,7 +111,7 @@ Thermal: For common binding part and usage, refer to -Documentation/devicetree/bindings/thermal/thermal.txt +Documentation/devicet
Re: [PATCH v4 4/7] dt-bindings: thermal: tsens: document ipq8064 bindings
On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote:
>
> Document the use of bindings used for ipq8064 SoCs tsens.
> ipq8064 use the same gcc regs and is set as a child of the qcom gcc.
>
> Signed-off-by: Ansuel Smith
> ---
> .../bindings/thermal/qcom-tsens.yaml | 50 ---
> 1 file changed, 43 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index d7be931b42d2..9d480e3943a2 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -19,6 +19,11 @@ description: |
> properties:
>compatible:
> oneOf:
> + - description: msm9860 TSENS based
Another variant of the number here: I've seen 8960, 8064 (correct) and
8060, 9860 (wrong) so far.
Just use 8960 throughout this series and then add a new patch at the
end of the series for a compatible for ipq8064.
> +items:
> + - enum:
> +- qcom,ipq8064-tsens
> +
>- description: v0.1 of TSENS
> items:
>- enum:
> @@ -85,12 +90,18 @@ properties:
>Number of cells required to uniquely identify the thermal sensors.
> Since
>we have multiple sensors this is set to 1
>
> +required:
> + - compatible
> + - interrupts
> + - "#thermal-sensor-cells"
> +
> allOf:
>- if:
>properties:
> compatible:
>contains:
> enum:
> + - qcom,ipq8064-tsens
>- qcom,msm8916-tsens
>- qcom,msm8974-tsens
>- qcom,msm8976-tsens
> @@ -111,17 +122,42 @@ allOf:
> interrupt-names:
>minItems: 2
>
> -required:
> - - compatible
> - - reg
> - - "#qcom,sensors"
> - - interrupts
> - - interrupt-names
> - - "#thermal-sensor-cells"
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - qcom,tsens-v0_1
> + - qcom,tsens-v1
> + - qcom,tsens-v2
> +
> +then:
> + required:
> +- reg
> +- interrupt-names
> +- "#qcom,sensors"
>
> additionalProperties: false
>
> examples:
> + - |
> +#include
> +// Example msm9860 based SoC (ipq8064):
> +gcc: clock-controller {
> +
> + /* ... */
> +
> + tsens: thermal-sensor {
> +compatible = "qcom,ipq8064-tsens";
> +
> + nvmem-cells = <_calib>, <_calsel>;
> + nvmem-cell-names = "calib", "calib_sel";
> + interrupts = ;
> +
> + #thermal-sensor-cells = <1>;
> + };
> +};
> +
>- |
> #include
> // Example 1 (legacy: for pre v1 IP):
> --
> 2.27.0
>
Re: [PATCH v4 7/7] drivers: thermal: tsens: add set_trip support for 8960
Hi Ansuel,
On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote:
>
> Add custom set_trip function for 8960 needed to set trip point to the
> tsens driver for 8960 driver.
Please describe why it needs a custom function please.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens-8960.c | 78 +++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/thermal/qcom/tsens-8960.c
> b/drivers/thermal/qcom/tsens-8960.c
> index 20d0bfb10f1f..4ad65ab3fd18 100644
> --- a/drivers/thermal/qcom/tsens-8960.c
> +++ b/drivers/thermal/qcom/tsens-8960.c
> @@ -93,6 +93,15 @@
> TSENS_8064_SENSOR9_EN | \
> TSENS_8064_SENSOR10_EN)
>
> +/* Trips: from very hot to very cold */
> +enum tsens_trip_type {
> + TSENS_TRIP_STAGE3 = 0,
> + TSENS_TRIP_STAGE2,
> + TSENS_TRIP_STAGE1,
> + TSENS_TRIP_STAGE0,
> + TSENS_TRIP_NUM,
> +};
> +
> u32 tsens_8960_slope[] = {
> 1176, 1176, 1154, 1176,
> , 1132, 1132, 1199,
> @@ -110,6 +119,16 @@ static inline int code_to_mdegC(u32 adc_code, const
> struct tsens_sensor *s)
> return adc_code * slope + offset;
> }
>
> +static int mdegC_to_code(int degC, const struct tsens_sensor *s)
> +{
> + int slope, offset;
> +
> + slope = thermal_zone_get_slope(s->tzd);
> + offset = CAL_MDEGC - slope * s->offset;
> +
> + return degC / slope - offset;
> +}
> +
> static void notify_uspace_tsens_fn(struct work_struct *work)
> {
> struct tsens_sensor *s = container_of(work, struct tsens_sensor,
> @@ -448,6 +467,64 @@ static int get_temp_8960(const struct tsens_sensor *s,
> int *temp)
> return -ETIMEDOUT;
> }
>
> +static int set_trip_temp_ipq8064(void *data, int trip, int temp)
> +{
> + unsigned int reg_th, reg_cntl;
> + int ret, code, code_chk, hi_code, lo_code;
> + const struct tsens_sensor *s = data;
> + struct tsens_priv *priv = s->priv;
> +
> + code = mdegC_to_code(temp, s);
> + code_chk = code;
> +
> + if (code < THRESHOLD_MIN_CODE || code > THRESHOLD_MAX_CODE)
> + return -EINVAL;
> +
> + ret = regmap_read(priv->tm_map, STATUS_CNTL_ADDR_8064, _cntl);
> + if (ret)
> + return ret;
> +
> + ret = regmap_read(priv->tm_map, THRESHOLD_ADDR, _th);
> + if (ret)
> + return ret;
> +
> + hi_code = (reg_th & THRESHOLD_UPPER_LIMIT_MASK)
> + >> THRESHOLD_UPPER_LIMIT_SHIFT;
> + lo_code = (reg_th & THRESHOLD_LOWER_LIMIT_MASK)
> + >> THRESHOLD_LOWER_LIMIT_SHIFT;
> +
> + switch (trip) {
> + case TSENS_TRIP_STAGE3:
> + code <<= THRESHOLD_MAX_LIMIT_SHIFT;
> + reg_th &= ~THRESHOLD_MAX_LIMIT_MASK;
> + break;
> + case TSENS_TRIP_STAGE2:
> + if (code_chk <= lo_code)
> + return -EINVAL;
> + code <<= THRESHOLD_UPPER_LIMIT_SHIFT;
> + reg_th &= ~THRESHOLD_UPPER_LIMIT_MASK;
> + break;
> + case TSENS_TRIP_STAGE1:
> + if (code_chk >= hi_code)
> + return -EINVAL;
> + code <<= THRESHOLD_LOWER_LIMIT_SHIFT;
> + reg_th &= ~THRESHOLD_LOWER_LIMIT_MASK;
> + break;
> + case TSENS_TRIP_STAGE0:
> + code <<= THRESHOLD_MIN_LIMIT_SHIFT;
> + reg_th &= ~THRESHOLD_MIN_LIMIT_MASK;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = regmap_write(priv->tm_map, THRESHOLD_ADDR, reg_th | code);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> static const struct tsens_ops ops_8960 = {
> .init = init_8960,
> .calibrate = calibrate_8960,
> @@ -456,6 +533,7 @@ static const struct tsens_ops ops_8960 = {
> .disable= disable_8960,
> .suspend= suspend_8960,
> .resume = resume_8960,
> + .set_trip_temp = set_trip_temp_ipq8064,
> };
>
> struct tsens_plat_data data_8960 = {
> --
> 2.27.0
>
Re: [PATCH v4 2/7] drivers: thermal: tsens: try load regmap from parent for 8960
On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote:
>
> Devices based on 8060 tsens driver (ipq8064) use the reg of the gcc
typo: 8960
> driver. Try to load the regmap of the parent as they share the same
> regs.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens-8960.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/qcom/tsens-8960.c
> b/drivers/thermal/qcom/tsens-8960.c
> index 2a28a5af209e..45788eb3c666 100644
> --- a/drivers/thermal/qcom/tsens-8960.c
> +++ b/drivers/thermal/qcom/tsens-8960.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "tsens.h"
>
> @@ -168,8 +169,17 @@ static int init_8960(struct tsens_priv *priv)
> u32 reg_cntl;
>
> priv->tm_map = dev_get_regmap(priv->dev, NULL);
> - if (!priv->tm_map)
> + if (!priv->tm_map) {
> + struct device *parent = priv->dev->parent;
> +
> + if (parent)
> + priv->tm_map = syscon_node_to_regmap(parent->of_node);
> + }
> +
> + if (!priv->tm_map || IS_ERR(priv->tm_map)) {
> + dev_err(priv->dev, "failed to get tsens regmap\n");
> return -ENODEV;
> + }
>
> /*
> * The status registers for each sensor are discontiguous
> --
> 2.27.0
>
Re: [PATCH v4 1/7] ipq806x: gcc: add support for child probe
On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote:
>
> Add support for child probing needed for tsens driver that share the
> seme regs of gcc for this platform.
Typo: same
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/clk/qcom/gcc-ipq806x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
> index a8456e09c44d..d6b7adb4be38 100644
> --- a/drivers/clk/qcom/gcc-ipq806x.c
> +++ b/drivers/clk/qcom/gcc-ipq806x.c
> @@ -3089,7 +3089,7 @@ static int gcc_ipq806x_probe(struct platform_device
> *pdev)
> regmap_write(regmap, 0x3cf8, 8);
> regmap_write(regmap, 0x3d18, 8);
>
> - return 0;
> + return of_platform_populate(pdev->dev.of_node, NULL, NULL,
> >dev);
> }
>
> static struct platform_driver gcc_ipq806x_driver = {
> --
> 2.27.0
>
Re: [PATCH v4 5/7] drivers: thermal: tsens: add interrupt support for 9860 driver
Hi Ansuel,
Thanks for this patch.
On Thu, Jul 16, 2020 at 7:58 AM Ansuel Smith wrote:
>
> Add interrupt support for 9860 tsens driver used to set thermal trip
> point for the system.
typo: 8960
You've used the names 8960 and ipq8064 interchangeably throughout the
series. AFAICT, msm8960, ipq8064 and apq8064 use the same IP version
of tsens. Please use 8960 in all patches, descriptions and dt-binding.
to reflect the filename for the driver.
Then add ipq8064 and apq8064 in a comment in the driver like here to
show that the driver also supports these other SoCs:
https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/thermal/qcom/tsens-v0_1.c#L328
You can also add a new compatible string for ipq8064 as a separate
patch at the end of the series.
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens-8960.c | 197 +++---
> drivers/thermal/qcom/tsens.h | 3 +
> 2 files changed, 186 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-8960.c
> b/drivers/thermal/qcom/tsens-8960.c
> index 45788eb3c666..20d0bfb10f1f 100644
> --- a/drivers/thermal/qcom/tsens-8960.c
> +++ b/drivers/thermal/qcom/tsens-8960.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "tsens.h"
>
> @@ -27,7 +28,6 @@
> /* CNTL_ADDR bitmasks */
> #define EN BIT(0)
> #define SW_RST BIT(1)
> -#define SENSOR0_EN BIT(3)
> #define SLP_CLK_ENABIT(26)
> #define SLP_CLK_ENA_8660 BIT(24)
> #define MEASURE_PERIOD 1
> @@ -41,14 +41,26 @@
>
> #define THRESHOLD_ADDR 0x3624
> /* THRESHOLD_ADDR bitmasks */
> +#define THRESHOLD_MAX_CODE 0x2
> +#define THRESHOLD_MIN_CODE 0
> #define THRESHOLD_MAX_LIMIT_SHIFT 24
> #define THRESHOLD_MIN_LIMIT_SHIFT 16
> #define THRESHOLD_UPPER_LIMIT_SHIFT8
> #define THRESHOLD_LOWER_LIMIT_SHIFT0
> +#define THRESHOLD_MAX_LIMIT_MASK (THRESHOLD_MAX_CODE << \
> + THRESHOLD_MAX_LIMIT_SHIFT)
> +#define THRESHOLD_MIN_LIMIT_MASK (THRESHOLD_MAX_CODE << \
> + THRESHOLD_MIN_LIMIT_SHIFT)
> +#define THRESHOLD_UPPER_LIMIT_MASK (THRESHOLD_MAX_CODE << \
> + THRESHOLD_UPPER_LIMIT_SHIFT)
> +#define THRESHOLD_LOWER_LIMIT_MASK (THRESHOLD_MAX_CODE << \
> + THRESHOLD_LOWER_LIMIT_SHIFT)
>
> /* Initial temperature threshold values */
> -#define LOWER_LIMIT_TH 0x50
> -#define UPPER_LIMIT_TH 0xdf
> +#define LOWER_LIMIT_TH_89600x50
> +#define UPPER_LIMIT_TH_89600xdf
> +#define LOWER_LIMIT_TH_80640x9d /* 95C */
> +#define UPPER_LIMIT_TH_80640xa6 /* 105C */
> #define MIN_LIMIT_TH 0x0
> #define MAX_LIMIT_TH 0xff
>
> @@ -57,6 +69,170 @@
> #define TRDY_MASK BIT(7)
> #define TIMEOUT_US 100
>
> +#define TSENS_EN BIT(0)
> +#define TSENS_SW_RST BIT(1)
> +#define TSENS_ADC_CLK_SEL BIT(2)
> +#define SENSOR0_EN BIT(3)
> +#define SENSOR1_EN BIT(4)
> +#define SENSOR2_EN BIT(5)
> +#define SENSOR3_EN BIT(6)
> +#define SENSOR4_EN BIT(7)
> +#define SENSORS_EN (SENSOR0_EN | SENSOR1_EN | \
> + SENSOR2_EN | SENSOR3_EN | SENSOR4_EN)
> +#define TSENS_8064_SENSOR5_EN BIT(8)
> +#define TSENS_8064_SENSOR6_EN BIT(9)
> +#define TSENS_8064_SENSOR7_EN BIT(10)
> +#define TSENS_8064_SENSOR8_EN BIT(11)
> +#define TSENS_8064_SENSOR9_EN BIT(12)
> +#define TSENS_8064_SENSOR10_EN BIT(13)
> +#define TSENS_8064_SENSORS_EN (SENSORS_EN | \
> + TSENS_8064_SENSOR5_EN | \
> + TSENS_8064_SENSOR6_EN | \
> + TSENS_8064_SENSOR7_EN | \
> + TSENS_8064_SENSOR8_EN | \
> + TSENS_8064_SENSOR9_EN | \
> + TSENS_8064_SENSOR10_EN)
> +
> +u32 tsens_8960_slope[] = {
> + 1176, 1176, 1154, 1176,
> + , 1132, 1132, 1199,
> + 1132, 1199, 1132
> + };
> +
> +/* Temperature on y axis and ADC-code on x-axis */
> +static inline int code_to_mdegC(u32 adc_code, const struct tsens_sensor *s)
> +{
> + int slope, offset;
> +
> + slope = thermal_zone_get_slope(s->tzd);
> + offset = CAL_MDEGC - slope * s->offset;
> +
> + return adc_code * slope + offset;
> +}
> +
> +static void notify_uspace_tsens_fn(struct
Re: [PATCH 1/2] thermal: netlink: Improve the initcall ordering
On Fri, Jul 17, 2020 at 10:12 PM Daniel Lezcano
wrote:
>
> The initcalls like to play joke. In our case, the thermal-netlink
> initcall is called after the thermal-core initcall but this one sends
> a notification before the former is initialzed. No issue was spotted,
typo: initialized
> but it could lead to a memory corruption, so instead of relying on the
> core_initcall for the thermal-netlink, let's initialize directly from
> the thermal-core init routine, so we have full control of the init
> ordering.
> Reported-by: Marek Szyprowski
> Tested-by: Marek Szyprowski
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/thermal_core.c| 4
> drivers/thermal/thermal_netlink.c | 3 +--
> drivers/thermal/thermal_netlink.h | 6 ++
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 25ef29123f72..c2e7d7aaa354 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1581,6 +1581,10 @@ static int __init thermal_init(void)
> {
> int result;
>
> + result = thermal_netlink_init();
> + if (result)
> + goto error;
> +
> mutex_init(_lock);
> result = thermal_register_governors();
> if (result)
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> index dd0a3b889674..42eace7401da 100644
> --- a/drivers/thermal/thermal_netlink.c
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -641,8 +641,7 @@ static struct genl_family thermal_gnl_family
> __ro_after_init = {
> .n_mcgrps = ARRAY_SIZE(thermal_genl_mcgrps),
> };
>
> -static int __init thermal_netlink_init(void)
> +int __init thermal_netlink_init(void)
> {
> return genl_register_family(_gnl_family);
> }
> -core_initcall(thermal_netlink_init);
> diff --git a/drivers/thermal/thermal_netlink.h
> b/drivers/thermal/thermal_netlink.h
> index 0ec28d105da5..828d1dddfa98 100644
> --- a/drivers/thermal/thermal_netlink.h
> +++ b/drivers/thermal/thermal_netlink.h
> @@ -6,6 +6,7 @@
>
> /* Netlink notification function */
> #ifdef CONFIG_THERMAL_NETLINK
> +int __init thermal_netlink_init(void);
> int thermal_notify_tz_create(int tz_id, const char *name);
> int thermal_notify_tz_delete(int tz_id);
> int thermal_notify_tz_enable(int tz_id);
> @@ -23,6 +24,11 @@ int thermal_notify_cdev_delete(int cdev_id);
> int thermal_notify_tz_gov_change(int tz_id, const char *name);
> int thermal_genl_sampling_temp(int id, int temp);
> #else
> +static inline int thermal_netlink_init(void)
> +{
> + return 0;
> +}
> +
> static inline int thermal_notify_tz_create(int tz_id, const char *name)
> {
> return 0;
> --
> 2.17.1
>
Re: [PATCH 2/2] thermal: core: Move initialization after core initcall
On Fri, Jul 17, 2020 at 10:12 PM Daniel Lezcano wrote: > > The generic netlink is initialized at subsys_initcall, so far after > the thermal init routine and the thermal generic netlink family > initialization. > > On ŝome platforms, that leads to a memory corruption. > > The fix was sent to netdev@ to move the genetlink framework > initialization at core_initcall. > > Move the thermal core initialization to postcore level which is very > close to core level. > > Reported-by: Marek Szyprowski > Tested-by: Marek Szyprowski > Signed-off-by: Daniel Lezcano > --- > drivers/thermal/thermal_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index c2e7d7aaa354..79551bb6cd4c 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1617,4 +1617,4 @@ static int __init thermal_init(void) > mutex_destroy(_lock); > return result; > } > -core_initcall(thermal_init); > +postcore_initcall(thermal_init); For posterity, we moved to core_initcall from fs_initcall since we had removed netlink support from the thermal framework and we wanted to initialise it as quickly as possible after cpufreq to allow early mitigation possibility. Given the addition of the new netlink-based API to thermal framework, I think moving to postcore_initcall is an acceptable compromise. Reviewed-by: Amit Kucheria > -- > 2.17.1 >
Re: [PATCH] net: genetlink: Move initialization to core_initcall
On Wed, Jul 15, 2020 at 1:11 PM Daniel Lezcano
wrote:
>
> The generic netlink is initialized far after the netlink protocol
> itself at subsys_initcall. The devlink is initialized at the same
> level, but after, as shown by a disassembly of the vmlinux:
>
> [ ... ]
> 374 8000115f22c0 <__initcall_devlink_init4>:
> 375 8000115f22c4 <__initcall_genl_init4>:
> [ ... ]
>
> The function devlink_init() calls genl_register_family() before the
> generic netlink subsystem is initialized.
>
> As the generic netlink initcall level is set since 2005, it seems that
> was not a problem, but now we have the thermal framework initialized
> at the core_initcall level which creates the generic netlink family
> and sends a notification which leads to a subtle memory corruption
> only detectable when the CONFIG_INIT_ON_ALLOC_DEFAULT_ON option is set
> with the earlycon at init time.
>
> The thermal framework needs to be initialized early in order to begin
> the mitigation as soon as possible. Moving it to postcore_initcall is
> acceptable.
>
> This patch changes the initialization level for the generic netlink
> family to the core_initcall and comes after the netlink protocol
> initialization.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> net/netlink/genetlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 55ee680e9db1..36b8a1909826 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -1263,7 +1263,7 @@ static int __init genl_init(void)
> panic("GENL: Cannot register controller: %d\n", err);
> }
>
> -subsys_initcall(genl_init);
> +core_initcall(genl_init);
>
> static int genlmsg_mcast(struct sk_buff *skb, u32 portid, unsigned long
> group,
> gfp_t flags)
> --
> 2.17.1
>
Re: [PATCH v3 4/4] thermal: core: Add notifications call in the framework
On Fri, Jul 3, 2020 at 2:23 PM Daniel Lezcano wrote:
>
> The generic netlink protocol is implemented but the different
> notification functions are not yet connected to the core code.
>
> These changes add the notification calls in the different
> corresponding places.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/thermal_core.c| 21 +
> drivers/thermal/thermal_helpers.c | 11 +--
> drivers/thermal/thermal_sysfs.c | 15 ++-
> 3 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 5fae1621fb01..25ef29123f72 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -215,6 +215,8 @@ int thermal_zone_device_set_policy(struct
> thermal_zone_device *tz,
> mutex_unlock(>lock);
> mutex_unlock(_governor_lock);
>
> + thermal_notify_tz_gov_change(tz->id, policy);
> +
> return ret;
> }
>
> @@ -406,12 +408,25 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> static void handle_thermal_trip(struct thermal_zone_device *tz, int trip)
> {
> enum thermal_trip_type type;
> + int trip_temp, hyst = 0;
>
> /* Ignore disabled trip points */
> if (test_bit(trip, >trips_disabled))
> return;
>
> + tz->ops->get_trip_temp(tz, trip, _temp);
> tz->ops->get_trip_type(tz, trip, );
> + if (tz->ops->get_trip_hyst)
> + tz->ops->get_trip_hyst(tz, trip, );
> +
> + if (tz->last_temperature != THERMAL_TEMP_INVALID) {
> + if (tz->last_temperature < trip_temp &&
> + tz->temperature >= trip_temp)
> + thermal_notify_tz_trip_up(tz->id, trip);
> + if (tz->last_temperature >= trip_temp &&
> + tz->temperature < (trip_temp - hyst))
> + thermal_notify_tz_trip_down(tz->id, trip);
> + }
>
> if (type == THERMAL_TRIP_CRITICAL || type == THERMAL_TRIP_HOT)
> handle_critical_trips(tz, trip, type);
> @@ -443,6 +458,8 @@ static void update_temperature(struct thermal_zone_device
> *tz)
> mutex_unlock(>lock);
>
> trace_thermal_temperature(tz);
> +
> + thermal_genl_sampling_temp(tz->id, temp);
> }
>
> static void thermal_zone_device_init(struct thermal_zone_device *tz)
> @@ -1405,6 +1422,8 @@ thermal_zone_device_register(const char *type, int
> trips, int mask,
> if (atomic_cmpxchg(>need_update, 1, 0))
> thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
>
> + thermal_notify_tz_create(tz->id, tz->type);
> +
> return tz;
>
> unregister:
> @@ -1476,6 +1495,8 @@ void thermal_zone_device_unregister(struct
> thermal_zone_device *tz)
> ida_destroy(>ida);
> mutex_destroy(>lock);
> device_unregister(>device);
> +
> + thermal_notify_tz_delete(tz->id);
> }
> EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
>
> diff --git a/drivers/thermal/thermal_helpers.c
> b/drivers/thermal/thermal_helpers.c
> index 87b1256fa2f2..53dd92ccfd19 100644
> --- a/drivers/thermal/thermal_helpers.c
> +++ b/drivers/thermal/thermal_helpers.c
> @@ -175,6 +175,14 @@ void thermal_zone_set_trips(struct thermal_zone_device
> *tz)
> mutex_unlock(>lock);
> }
>
> +void thermal_cdev_set_cur_state(struct thermal_cooling_device *cdev, int
> target)
> +{
> + if (cdev->ops->set_cur_state(cdev, target))
> + return;
> + thermal_notify_cdev_update(cdev->id, target);
> + thermal_cooling_device_stats_update(cdev, target);
> +}
> +
> void thermal_cdev_update(struct thermal_cooling_device *cdev)
> {
> struct thermal_instance *instance;
> @@ -197,8 +205,7 @@ void thermal_cdev_update(struct thermal_cooling_device
> *cdev)
> target = instance->target;
> }
>
> - if (!cdev->ops->set_cur_state(cdev, target))
> - thermal_cooling_device_stats_update(cdev, target);
> + thermal_cdev_set_cur_state(cdev, target);
>
> cdev->updated = true;
> mutex_unlock(>lock);
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb4dff7..ff449943f757 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -124,7 +124,8 @@ trip_point_temp_store(struct
Re: [PATCH v3 3/4] thermal: core: genetlink support for events/cmd/sampling
On Fri, Jul 3, 2020 at 2:23 PM Daniel Lezcano wrote:
>
> Initially the thermal framework had a very simple notification
> mechanism to send generic netlink messages to the userspace.
>
> The notification function was never called from anywhere and the
> corresponding dead code was removed. It was probably a first attempt
> to introduce the netlink notification.
>
> At LPC2018, the presentation "Linux thermal: User kernel interface",
> proposed to create the notifications to the userspace via a kfifo.
>
> The advantage of the kfifo is the performance. It is usually used from
> a 1:1 communication channel where a driver captures data and sends it
> as fast as possible to a userspace process.
>
> The drawback is that only one process uses the notification channel
> exclusively, thus no other process is allowed to use the channel to
> get temperature or notifications.
>
> This patch defines a generic netlink API to discover the current
> thermal setup and adds event notifications as well as temperature
> sampling. As any genetlink protocol, it can evolve and the versioning
> allows to keep the backward compatibility.
>
> In order to prevent the user from getting flooded with data on a
> single channel, there are two multicast channels, one for the
> temperature sampling when the thermal zone is updated and another one
> for the events, so the user can get the events only without the
> thermal zone temperature sampling.
>
> Also, a list of commands to discover the thermal setup is added and
> can be extended when needed.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> v3:
> - Fixed changelog from Amit Kucheria suggestions
> - Prefixed fields in the parameter structure (trip_*, cdev_*)
> - Fixed leading whitespaces errors
> - Replaced id by trip_id
> - s/THERMAL_GENL_CMD_TZ_GET/THERMAL_GENL_CMD_TZ_GET_ID/
> - Added the cdev max state in the cdev change event
> - Removed min state
> - Fixed checkpatch warnings
> ---
> ---
> drivers/thermal/Makefile | 2 +-
> drivers/thermal/thermal_core.h| 18 +
> drivers/thermal/thermal_netlink.c | 650 ++
> include/linux/thermal.h | 17 -
> include/uapi/linux/thermal.h | 90 -
> 5 files changed, 742 insertions(+), 35 deletions(-)
> create mode 100644 drivers/thermal/thermal_netlink.c
>
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 0c8b84a09b9a..1bbf0805fb04 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,7 @@
>
> obj-$(CONFIG_THERMAL) += thermal_sys.o
> thermal_sys-y += thermal_core.o thermal_sysfs.o \
> - thermal_helpers.o
> + thermal_helpers.o thermal_netlink.o
>
> # interface to/from other layers providing sensors
> thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 4f8389efaa62..12bca87fb709 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -52,6 +52,24 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>
> struct thermal_zone_device *thermal_zone_get_by_id(int id);
>
> +/* Netlink notification function */
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz_delete(int tz_id);
> +int thermal_notify_tz_enable(int tz_id);
> +int thermal_notify_tz_disable(int tz_id);
> +int thermal_notify_tz_trip_down(int tz_id, int id);
> +int thermal_notify_tz_trip_up(int tz_id, int id);
> +int thermal_notify_tz_trip_delete(int tz_id, int id);
> +int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> + int temp, int hyst);
> +int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> + int temp, int hyst);
> +int thermal_notify_cdev_update(int cdev_id, int state);
> +int thermal_notify_cdev_add(int cdev_id, const char *name, int max_state);
> +int thermal_notify_cdev_delete(int cdev_id);
> +int thermal_notify_tz_gov_change(int tz_id, const char *name);
> +int thermal_genl_sampling_temp(int id, int temp);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> new file mode 100644
> index ..d3c48bbcd269
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -0,0 +1,650 @@
> +// SPDX-License-Identifier: GPL-2
Re: [PATCH v3 1/4] thermal: core: Add helpers to browse the cdev, tz and governor list
On Fri, Jul 3, 2020 at 2:23 PM Daniel Lezcano wrote:
>
> The cdev, tz and governor list, as well as their respective locks are
> statically defined in the thermal_core.c file.
>
> In order to give a sane access to these list, like browsing all the
> thermal zones or all the cooling devices, let's define a set of
> helpers where we pass a callback as a parameter to be called for each
> thermal entity.
>
> We keep the self-encapsulation and ensure the locks are correctly
> taken when looking at the list.
>
> Acked-by: Zhang Rui
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/thermal_core.c | 51 ++
> drivers/thermal/thermal_core.h | 9 ++
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index b71196eaf90e..9caaa0b6d662 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -617,6 +617,57 @@ void thermal_zone_device_rebind_exception(struct
> thermal_zone_device *tz,
> mutex_unlock(_list_lock);
> }
>
> +int for_each_thermal_governor(int (*cb)(struct thermal_governor *, void *),
> + void *data)
> +{
> + struct thermal_governor *gov;
> + int ret = 0;
> +
> + mutex_lock(_governor_lock);
> + list_for_each_entry(gov, _governor_list, governor_list) {
> + ret = cb(gov, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_governor_lock);
> +
> + return ret;
> +}
> +
> +int for_each_thermal_cooling_device(int (*cb)(struct thermal_cooling_device
> *,
> + void *), void *data)
> +{
> + struct thermal_cooling_device *cdev;
> + int ret = 0;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(cdev, _cdev_list, node) {
> + ret = cb(cdev, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_list_lock);
> +
> + return ret;
> +}
> +
> +int for_each_thermal_zone(int (*cb)(struct thermal_zone_device *, void *),
> + void *data)
> +{
> + struct thermal_zone_device *tz;
> + int ret = 0;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(tz, _tz_list, node) {
> + ret = cb(tz, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_list_lock);
> +
> + return ret;
> +}
> +
> void thermal_zone_device_unbind_exception(struct thermal_zone_device *tz,
> const char *cdev_type, size_t size)
> {
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index c95689586e19..71d88dac0791 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -41,6 +41,15 @@ extern struct thermal_governor
> *__governor_thermal_table_end[];
> __governor < __governor_thermal_table_end; \
> __governor++)
>
> +int for_each_thermal_zone(int (*cb)(struct thermal_zone_device *, void *),
> + void *);
> +
> +int for_each_thermal_cooling_device(int (*cb)(struct thermal_cooling_device
> *,
> + void *), void *);
> +
> +int for_each_thermal_governor(int (*cb)(struct thermal_governor *, void *),
> + void *thermal_governor);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> --
> 2.17.1
>
[PATCH] thermal: Remove clock_cooling code
clock_cooling has no in-kernel users. It has never found any use in
drivers as far as I can tell.
Remove the code.
Signed-off-by: Amit Kucheria
---
drivers/thermal/Kconfig | 10 -
drivers/thermal/Makefile| 3 -
drivers/thermal/clock_cooling.c | 445
include/linux/clock_cooling.h | 57
4 files changed, 515 deletions(-)
delete mode 100644 drivers/thermal/clock_cooling.c
delete mode 100644 include/linux/clock_cooling.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 3eb2348e52427..b2250d3be9e18 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -180,16 +180,6 @@ config CPU_IDLE_THERMAL
idle cycle.
endif
-config CLOCK_THERMAL
- bool "Generic clock cooling support"
- depends on COMMON_CLK
- depends on PM_OPP
- help
- This entry implements the generic clock cooling mechanism through
- frequency clipping. Typically used to cool off co-processors. The
- device that is configured to use this cooling mechanism will be
- controlled to reduce clock frequency whenever temperature is high.
-
config DEVFREQ_THERMAL
bool "Generic device cooling support"
depends on PM_DEVFREQ
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 0c8b84a09b9aa..11c1768b12273 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -22,9 +22,6 @@ thermal_sys-$(CONFIG_THERMAL_GOV_POWER_ALLOCATOR) +=
gov_power_allocator.o
thermal_sys-$(CONFIG_CPU_FREQ_THERMAL) += cpufreq_cooling.o
thermal_sys-$(CONFIG_CPU_IDLE_THERMAL) += cpuidle_cooling.o
-# clock cooling
-thermal_sys-$(CONFIG_CLOCK_THERMAL)+= clock_cooling.o
-
# devfreq cooling
thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
diff --git a/drivers/thermal/clock_cooling.c b/drivers/thermal/clock_cooling.c
deleted file mode 100644
index 56cb1f46a428e..0
--- a/drivers/thermal/clock_cooling.c
+++ /dev/null
@@ -1,445 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * drivers/thermal/clock_cooling.c
- *
- * Copyright (C) 2014 Eduardo Valentin
- *
- * Copyright (C) 2013 Texas Instruments Inc.
- * Contact: Eduardo Valentin
- *
- * Highly based on cpufreq_cooling.c.
- * Copyright (C) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
- * Copyright (C) 2012 Amit Daniel
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/**
- * struct clock_cooling_device - data for cooling device with clock
- * @id: unique integer value corresponding to each clock_cooling_device
- * registered.
- * @dev: struct device pointer to the device being used to cool off using
- * clock frequencies.
- * @cdev: thermal_cooling_device pointer to keep track of the
- * registered cooling device.
- * @clk_rate_change_nb: reference to notifier block used to receive clock
- * rate changes.
- * @freq_table: frequency table used to keep track of available frequencies.
- * @clock_state: integer value representing the current state of clock
- * cooling devices.
- * @clock_val: integer value representing the absolute value of the clipped
- * frequency.
- * @clk: struct clk reference used to enforce clock limits.
- * @lock: mutex lock to protect this struct.
- *
- * This structure is required for keeping information of each
- * clock_cooling_device registered. In order to prevent corruption of this a
- * mutex @lock is used.
- */
-struct clock_cooling_device {
- int id;
- struct device *dev;
- struct thermal_cooling_device *cdev;
- struct notifier_block clk_rate_change_nb;
- struct cpufreq_frequency_table *freq_table;
- unsigned long clock_state;
- unsigned long clock_val;
- struct clk *clk;
- struct mutex lock; /* lock to protect the content of this struct */
-};
-#define to_clock_cooling_device(x) \
- container_of(x, struct clock_cooling_device, clk_rate_change_nb)
-static DEFINE_IDA(clock_ida);
-
-/* Below code defines functions to be used for clock as cooling device */
-
-enum clock_cooling_property {
- GET_LEVEL,
- GET_FREQ,
- GET_MAXL,
-};
-
-/**
- * clock_cooling_get_property - fetch a property of interest for a give cpu.
- * @ccdev: clock cooling device reference
- * @input: query parameter
- * @output: query return
- * @property: type of query (frequency, level, max level)
- *
- * This is the common function to
- * 1. get maximum clock cooling states
- * 2. translate frequency to cooling state
- * 3. translate cooling state to frequency
- * Note that the code may be not in good shape
- * but it is written in this way in order to:
- * a) reduce duplicate code as most of the code can be shared.
- * b) make sure the logic is consistent when translating between
- *cooling states and frequencies.
- *
- * Return: 0 on s
Re: [PATCH v2 3/5] thermal: core: Remove old uapi generic netlink
On Wed, Jul 1, 2020 at 3:15 PM Daniel Lezcano wrote: > > On 01/07/2020 11:33, Amit Kucheria wrote: > > On Wed, Jul 1, 2020 at 2:56 PM Daniel Lezcano > > wrote: > >> > >> On 30/06/2020 13:47, Amit Kucheria wrote: > >>> On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano > >>> wrote: > >>>> > >>>> /* Adding event notification support elements */ > >>>> #define THERMAL_GENL_FAMILY_NAME"thermal_event" > >>>> -#define THERMAL_GENL_VERSION0x01 > >>>> +#define THERMAL_GENL_VERSION0x02 > >>> > >>> This hunk should be removed since you set version back to 1 in the > >>> next patch and we don't actually intend to bump the version yet. > >> > >> Well, I've been very strict here for git-bisecting. > >> > >> I move to V2 because of the removal, but when adding the new genetlink > >> code, the family name changed, so we returned back to the V1 as it is a > >> new genetlink thermal brand. > > > > I don't understand the move to v2 for an empty skeleton UAPI. For the > > purposes of bisection, couldn't you just remove all the v1 UAPI (w/o > > bumping to v2) and then add a new UAPI in the next patch? > > > >> The name is change because it is no longer event based but also sampling > >> and commands. > > > > In this case, just to avoid any confusion, the new UAPI could be v2 > > making the transition clear in case of bisection. > > > > I'm afraid the v1->v2->v1 is a bit more confusing. > > Let me elaborate a bit: > > Why there is this patch ? > - By removing this code first, the next patch will just contain > additions, I thought it would be clearer > > Why increase the version here ? > - Code must continue to compile and as the 'thermal_event' family is now > different from V1, the version is changed > > Why the version goes to V1 in the next patch ? > - The family name is changed as it is not doing event only, so it is a > new netlink thermal protocol and we begin at V1 > > So the main reason of this patch is to be very strict in the iteration > changes. May be it is too much, in this case I can merge this patch with > 4/5, the old netlink protocol removal will be lost in the addition of > the new protocol. I'm fine with that if you think it is simpler. Considering that there are no users of v1 currently, it feels a bit over engineered, IMHO. Also, the new UAPI doesn't need to begin at v1. Just having it start at v2 will avoid this confusion, no?
Re: [PATCH v2 3/5] thermal: core: Remove old uapi generic netlink
On Wed, Jul 1, 2020 at 2:56 PM Daniel Lezcano wrote:
>
> On 30/06/2020 13:47, Amit Kucheria wrote:
> > On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
> > wrote:
> >>
> >> In order to set the scene for the new generic netlink thermal
> >> management and notifications, let remove the old dead code remaining
> >
> > s/management/management api/
> >
> > s/let/let's/
> >
> >> in the uapi headers.
> >>
> >> Signed-off-by: Daniel Lezcano
> >> ---
> >> include/linux/thermal.h | 5 -
> >> include/uapi/linux/thermal.h | 12 +---
> >> 2 files changed, 1 insertion(+), 16 deletions(-)
> >>
> >> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> >> index faf7ad031e42..fc93a6348082 100644
> >> --- a/include/linux/thermal.h
> >> +++ b/include/linux/thermal.h
> >> @@ -302,11 +302,6 @@ struct thermal_zone_params {
> >> int offset;
> >> };
> >>
> >> -struct thermal_genl_event {
> >> - u32 orig;
> >> - enum events event;
> >> -};
> >> -
> >> /**
> >> * struct thermal_zone_of_device_ops - scallbacks for handling DT based
> >> zones
> >> *
> >> diff --git a/include/uapi/linux/thermal.h b/include/uapi/linux/thermal.h
> >> index 96218378dda8..22df67ed9e9c 100644
> >> --- a/include/uapi/linux/thermal.h
> >> +++ b/include/uapi/linux/thermal.h
> >> @@ -6,21 +6,12 @@
> >>
> >> /* Adding event notification support elements */
> >> #define THERMAL_GENL_FAMILY_NAME"thermal_event"
> >> -#define THERMAL_GENL_VERSION0x01
> >> +#define THERMAL_GENL_VERSION0x02
> >
> > This hunk should be removed since you set version back to 1 in the
> > next patch and we don't actually intend to bump the version yet.
>
> Well, I've been very strict here for git-bisecting.
>
> I move to V2 because of the removal, but when adding the new genetlink
> code, the family name changed, so we returned back to the V1 as it is a
> new genetlink thermal brand.
I don't understand the move to v2 for an empty skeleton UAPI. For the
purposes of bisection, couldn't you just remove all the v1 UAPI (w/o
bumping to v2) and then add a new UAPI in the next patch?
> The name is change because it is no longer event based but also sampling
> and commands.
In this case, just to avoid any confusion, the new UAPI could be v2
making the transition clear in case of bisection.
I'm afraid the v1->v2->v1 is a bit more confusing.
/Amit
Re: [PATCH v2 1/5] thermal: core: Add helpers to browse the cdev, tz and governor list
On Wed, Jul 1, 2020 at 1:27 PM Zhang Rui wrote:
>
> On Wed, 2020-07-01 at 09:35 +0200, Daniel Lezcano wrote:
> > On 30/06/2020 17:09, Zhang Rui wrote:
> > > Hi, Daniel,
> > >
> > > seems that you forgot to cc linux-pm mailing list.
> > >
> > > On Tue, 2020-06-30 at 17:16 +0530, Amit Kucheria wrote:
> > > > On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
> > > > wrote:
> > > > >
> > > > > The cdev, tz and governor list, as well as their respective
> > > > > locks
> > > > > are
> > > > > statically defined in the thermal_core.c file.
> > > > >
> > > > > In order to give a sane access to these list, like browsing all
> > > > > the
> > > > > thermal zones or all the cooling devices, let's define a set of
> > > > > helpers where we pass a callback as a parameter to be called
> > > > > for
> > > > > each
> > > > > thermal entity.
> > > > >
> > > > > We keep the self-encapsulation and ensure the locks are
> > > > > correctly
> > > > > taken when looking at the list.
> > > > >
> > > > > Signed-off-by: Daniel Lezcano
> > > > > ---
> > > > > drivers/thermal/thermal_core.c | 51
> > > > > ++
> > > >
> > > > Is the idea to not use thermal_helpers.c from now on? It fits
> > > > perfectly with a patch I have to merge all its contents to
> > > > thermal_core.c :-)
> > >
> > > I agree these changes should be in thermal_helper.c
> >
> > Oh, actually I remind put those functions in the thermal_core.c file
> > because they need the locks which are statically defined in there.
> >
> > If the functions are moved to thermal_helper.c that will imply to
> > export
> > the locks outside of the file, thus breaking the self-encapsulation.
> >
> > Do you want to move them out?
>
> Then no. I don't have any objection of removing thermal_helper.c, so
> you can just leave these functions in thermal_core.c
In that case, Daniel, please find attached a patch to move the
contents of thermal_helpers into thermal_core.c
Feel free to include it at the top of this series and modify as you see fit.
Regards,
Amit
From e09befc6c6717c3e4554b0688c7d83b0696d2554 Mon Sep 17 00:00:00 2001
Message-Id:
From: Amit Kucheria
Date: Wed, 1 Jul 2020 14:48:47 +0530
Subject: [PATCH] thermal/core: Merge thermal_helpers.c into thermal_core.c
Moving several helper functions to this file require unnecessarily
exposing locks outside thermal_core.c.
It is better to simply move the few functions in there directly into
thermal_core.c.
Signed-off-by: Amit Kucheria
---
drivers/thermal/Makefile | 3 +-
drivers/thermal/thermal_core.c| 216 +++
drivers/thermal/thermal_helpers.c | 238 --
3 files changed, 217 insertions(+), 240 deletions(-)
delete mode 100644 drivers/thermal/thermal_helpers.c
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 0c8b84a09b9aa..ed2fc83fe2128 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,8 +4,7 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
-thermal_sys-y += thermal_core.o thermal_sysfs.o \
- thermal_helpers.o
+thermal_sys-y += thermal_core.o thermal_sysfs.o
# interface to/from other layers providing sensors
thermal_sys-$(CONFIG_THERMAL_HWMON) += thermal_hwmon.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index b71196eaf90e8..a9e927f7224e9 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -43,6 +43,222 @@ static bool power_off_triggered;
static struct thermal_governor *def_governor;
+/* Various helper functions */
+
+int get_tz_trend(struct thermal_zone_device *tz, int trip)
+{
+ enum thermal_trend trend;
+
+ if (tz->emul_temperature || !tz->ops->get_trend ||
+ tz->ops->get_trend(tz, trip, )) {
+ if (tz->temperature > tz->last_temperature)
+ trend = THERMAL_TREND_RAISING;
+ else if (tz->temperature < tz->last_temperature)
+ trend = THERMAL_TREND_DROPPING;
+ else
+ trend = THERMAL_TREND_STABLE;
+ }
+
+ return trend;
+}
+EXPORT_SYMBOL(get_tz_trend);
+
+struct thermal_instance *
+get_thermal_instance(struct thermal_zone_device *tz,
+ struct thermal_cooling_device *cdev, int trip)
+{
+ struct thermal_instance *pos = NULL;
+ struct thermal_instance *target_instance = NULL;
+
+ mutex_lock(>lock);
+ mutex_lock(>lock);
+
+ list_for_each_entry(pos, >thermal_instances, tz_node) {
+ if (pos->tz == tz &&am
Re: [PATCH v2 1/5] thermal: core: Add helpers to browse the cdev, tz and governor list
On Tue, Jun 30, 2020 at 8:40 PM Zhang Rui wrote: > > Hi, Daniel, > > seems that you forgot to cc linux-pm mailing list. > > On Tue, 2020-06-30 at 17:16 +0530, Amit Kucheria wrote: > > On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano > > wrote: > > > > > > The cdev, tz and governor list, as well as their respective locks > > > are > > > statically defined in the thermal_core.c file. > > > > > > In order to give a sane access to these list, like browsing all the > > > thermal zones or all the cooling devices, let's define a set of > > > helpers where we pass a callback as a parameter to be called for > > > each > > > thermal entity. > > > > > > We keep the self-encapsulation and ensure the locks are correctly > > > taken when looking at the list. > > > > > > Signed-off-by: Daniel Lezcano > > > --- > > > drivers/thermal/thermal_core.c | 51 > > > ++ > > > > Is the idea to not use thermal_helpers.c from now on? It fits > > perfectly with a patch I have to merge all its contents to > > thermal_core.c :-) > > I agree these changes should be in thermal_helper.c I was actually serious about killing thermal_helper.c :-) What is the reason for those 5-6 functions to live outside thermal_core.c? Functions in thermal_helper.c are called by governors and drivers, just like the functions in thermal_core.c. I couldn't find a pattern. Regards, Amit
Re: [PATCH v2 2/5] thermal: core: Get thermal zone by id
On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
wrote:
>
> The next patch will introduce the generic netlink protocol to handle
> events, sampling and command from the thermal framework. In order to
> deal with the thermal zone, it uses its unique identifier to
> characterize it in the message. Passing an integer is more efficient
> than passing an entire string.
>
> This change provides a function returning back a thermal zone pointer
> corresponding to the identifier passed as parameter.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/thermal_core.c | 14 ++
> drivers/thermal/thermal_core.h | 2 ++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index e2f8d2550ecd..58c95aeafb7f 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -662,6 +662,20 @@ int for_each_thermal_zone(int (*cb)(struct
> thermal_zone_device *, void *),
> return ret;
> }
>
> +struct thermal_zone_device *thermal_zone_get_by_id(int id)
> +{
> + struct thermal_zone_device *tz = NULL;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(tz, _tz_list, node) {
> + if (tz->id == id)
> + break;
> + }
> + mutex_unlock(_list_lock);
> +
> + return tz;
> +}
> +
> void thermal_zone_device_unbind_exception(struct thermal_zone_device *tz,
> const char *cdev_type, size_t size)
> {
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index bb8f8aee79eb..7e8f45db6bbf 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -50,6 +50,8 @@ int for_each_thermal_cooling_device(int (*cb)(struct
> thermal_cooling_device *,
> int for_each_thermal_governor(int (*cb)(struct thermal_governor *, void *),
> void *thermal_governor);
>
> +struct thermal_zone_device *thermal_zone_get_by_id(int id);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> --
> 2.17.1
>
Re: [PATCH v2 5/5] thermal: core: Add notifications call in the framework
On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
wrote:
>
> The generic netlink protocol is implemented but the different
> notification functions are not yet connected to the core code.
>
> These changes add the notification calls in the different
> corresponding places.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/thermal_core.c| 21 +
> drivers/thermal/thermal_helpers.c | 11 +--
> drivers/thermal/thermal_sysfs.c | 15 ++-
> 3 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 58c95aeafb7f..1388c03d1190 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -215,6 +215,8 @@ int thermal_zone_device_set_policy(struct
> thermal_zone_device *tz,
> mutex_unlock(>lock);
> mutex_unlock(_governor_lock);
>
> + thermal_notify_tz_gov_change(tz->id, policy);
> +
> return ret;
> }
>
> @@ -406,12 +408,25 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> static void handle_thermal_trip(struct thermal_zone_device *tz, int trip)
> {
> enum thermal_trip_type type;
> + int trip_temp, hyst = 0;
>
> /* Ignore disabled trip points */
> if (test_bit(trip, >trips_disabled))
> return;
>
> + tz->ops->get_trip_temp(tz, trip, _temp);
> tz->ops->get_trip_type(tz, trip, );
> + if (tz->ops->get_trip_hyst)
> + tz->ops->get_trip_hyst(tz, trip, );
> +
> + if (tz->last_temperature != THERMAL_TEMP_INVALID) {
> + if (tz->last_temperature < trip_temp &&
> + tz->temperature >= trip_temp)
> + thermal_notify_tz_trip_up(tz->id, trip);
> + if (tz->last_temperature >= trip_temp &&
> + tz->temperature < (trip_temp - hyst))
> + thermal_notify_tz_trip_down(tz->id, trip);
> + }
>
> if (type == THERMAL_TRIP_CRITICAL || type == THERMAL_TRIP_HOT)
> handle_critical_trips(tz, trip, type);
> @@ -443,6 +458,8 @@ static void update_temperature(struct thermal_zone_device
> *tz)
> mutex_unlock(>lock);
>
> trace_thermal_temperature(tz);
> +
> + thermal_genl_sampling_temp(tz->id, temp);
Does this need any rate limiting? How many times is update_temperature
called on a platform with a dozen sensors?
> }
>
> static void thermal_zone_device_init(struct thermal_zone_device *tz)
> @@ -1398,6 +1415,8 @@ thermal_zone_device_register(const char *type, int
> trips, int mask,
> if (atomic_cmpxchg(>need_update, 1, 0))
> thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
>
> + thermal_notify_tz_create(tz->id, tz->type);
> +
> return tz;
>
> unregister:
> @@ -1469,6 +1488,8 @@ void thermal_zone_device_unregister(struct
> thermal_zone_device *tz)
> ida_destroy(>ida);
> mutex_destroy(>lock);
> device_unregister(>device);
> +
> + thermal_notify_tz_delete(tz->id);
> }
> EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
>
> diff --git a/drivers/thermal/thermal_helpers.c
> b/drivers/thermal/thermal_helpers.c
> index 6ed24b4e23d3..7893ace1d90f 100644
> --- a/drivers/thermal/thermal_helpers.c
> +++ b/drivers/thermal/thermal_helpers.c
> @@ -175,6 +175,14 @@ void thermal_zone_set_trips(struct thermal_zone_device
> *tz)
> mutex_unlock(>lock);
> }
>
> +void thermal_cdev_set_cur_state(struct thermal_cooling_device *cdev, int
> target)
> +{
> + if (cdev->ops->set_cur_state(cdev, target))
> + return;
> + thermal_notify_cdev_update(cdev->id, target);
> + thermal_cooling_device_stats_update(cdev, target);
> +}
> +
> void thermal_cdev_update(struct thermal_cooling_device *cdev)
> {
> struct thermal_instance *instance;
> @@ -192,8 +200,7 @@ void thermal_cdev_update(struct thermal_cooling_device
> *cdev)
> target = instance->target;
> }
>
> - if (!cdev->ops->set_cur_state(cdev, target))
> - thermal_cooling_device_stats_update(cdev, target);
> + thermal_cdev_set_cur_state(cdev, target);
>
> mutex_unlock(>lock);
> trace_cdev_update(cdev, target);
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb4dff7..ff449943f757 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -124,7 +124,8 @@ trip_point_temp_store(struct device *dev, struct
> device_attribute *attr,
> {
> struct thermal_zone_device *tz = to_thermal_zone(dev);
> int trip, ret;
> - int temperature;
> + int temperature, hyst = 0;
> + enum thermal_trip_type type;
>
> if (!tz->ops->set_trip_temp)
> return -EPERM;
> @@ -139,6 +140,18 @@ trip_point_temp_store(struct device *dev, struct
> device_attribute *attr,
>
Re: [PATCH v2 3/5] thermal: core: Remove old uapi generic netlink
On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
wrote:
>
> In order to set the scene for the new generic netlink thermal
> management and notifications, let remove the old dead code remaining
s/management/management api/
s/let/let's/
> in the uapi headers.
>
> Signed-off-by: Daniel Lezcano
> ---
> include/linux/thermal.h | 5 -
> include/uapi/linux/thermal.h | 12 +---
> 2 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index faf7ad031e42..fc93a6348082 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -302,11 +302,6 @@ struct thermal_zone_params {
> int offset;
> };
>
> -struct thermal_genl_event {
> - u32 orig;
> - enum events event;
> -};
> -
> /**
> * struct thermal_zone_of_device_ops - scallbacks for handling DT based zones
> *
> diff --git a/include/uapi/linux/thermal.h b/include/uapi/linux/thermal.h
> index 96218378dda8..22df67ed9e9c 100644
> --- a/include/uapi/linux/thermal.h
> +++ b/include/uapi/linux/thermal.h
> @@ -6,21 +6,12 @@
>
> /* Adding event notification support elements */
> #define THERMAL_GENL_FAMILY_NAME"thermal_event"
> -#define THERMAL_GENL_VERSION0x01
> +#define THERMAL_GENL_VERSION0x02
This hunk should be removed since you set version back to 1 in the
next patch and we don't actually intend to bump the version yet.
> #define THERMAL_GENL_MCAST_GROUP_NAME "thermal_mc_grp"
>
> -/* Events supported by Thermal Netlink */
> -enum events {
> - THERMAL_AUX0,
> - THERMAL_AUX1,
> - THERMAL_CRITICAL,
> - THERMAL_DEV_FAULT,
> -};
> -
> /* attributes of thermal_genl_family */
> enum {
> THERMAL_GENL_ATTR_UNSPEC,
> - THERMAL_GENL_ATTR_EVENT,
> __THERMAL_GENL_ATTR_MAX,
> };
> #define THERMAL_GENL_ATTR_MAX (__THERMAL_GENL_ATTR_MAX - 1)
> @@ -28,7 +19,6 @@ enum {
> /* commands supported by the thermal_genl_family */
> enum {
> THERMAL_GENL_CMD_UNSPEC,
> - THERMAL_GENL_CMD_EVENT,
> __THERMAL_GENL_CMD_MAX,
> };
> #define THERMAL_GENL_CMD_MAX (__THERMAL_GENL_CMD_MAX - 1)
> --
> 2.17.1
>
Re: [PATCH v2 4/5] thermal: core: genetlink support for events/cmd/sampling
On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
wrote:
>
> Initially the thermal framework had a very simple notification
> mechanism to send generic netlink messages to the userspace.
>
> The notification function was never called from anywhere and the
> corresponding dead code was removed. It was probably a first attempt
> to introduce the netlink notification.
>
> At LPC2018, the presentation "Linux thermal: User kernel interface",
> proposed to create the notifications to the userspace via a kfifo.
>
> The advantage of the kfifo is the performance. It is usually used from
> a 1:1 communication channel where a driver captures data and send them
s/send them/sends it/
> as fast as possible to an userspace process.
s/an/a/
>
> The inconvenient is the process uses the notification channel
> exclusively, thus no other process is allowed to use the channel to
Suggest rephrasing to "The drawback is that only one process uses the
notification channel exclusively,"
> get temperature or notifications.
>
> The purpose of this series is to provide a fully netlink featured
> thermal management.
Suggest getting rid of this sentence, probably more appropriate for
the cover letter and instead
>
> This patch is defining a generic netlink API to discover the current
s/defining/defines/
s/generic/fully-featured generic/
> thermal setup, get events and temperature sampling. As any genetlink
s/setup, get events/setup, and adds event notifications/
> protocol, it can evolve and the versionning allows to keep the backward
Spell check: versioning
> compatibility.
>
> In order to not flood the user with a single channel data, there are
Consider rephrasing to "In order to prevent the user from getting
flooded with data on a single channel"
> two multicast channels, one for the temperature sampling when the
> thermal zone is updated and another one for the events, so the user
> can get the events only without the thermal zone temperature
> sampling. All these events are from the ones presented at the LPC2018.
We should remove this reference to LPC2018 here and just list the
events here, or remove this sentence and leave it for the code.
>
> Also, a list of commands to discover the thermal setup is given and
s/given/added/
> can be extended on purpose.
s/on purpose/when needed/
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/Makefile | 2 +-
> drivers/thermal/thermal_core.h| 19 +
> drivers/thermal/thermal_netlink.c | 645 ++
> include/linux/thermal.h | 12 -
> include/uapi/linux/thermal.h | 80 +++-
> 5 files changed, 738 insertions(+), 20 deletions(-)
> create mode 100644 drivers/thermal/thermal_netlink.c
>
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 0c8b84a09b9a..1bbf0805fb04 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,7 @@
>
> obj-$(CONFIG_THERMAL) += thermal_sys.o
> thermal_sys-y += thermal_core.o thermal_sysfs.o \
> - thermal_helpers.o
> + thermal_helpers.o thermal_netlink.o
>
> # interface to/from other layers providing sensors
> thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 7e8f45db6bbf..08eb03fe4f69 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -52,6 +52,25 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>
> struct thermal_zone_device *thermal_zone_get_by_id(int id);
>
> +/* Netlink notification function */
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz_delete(int tz_id);
> +int thermal_notify_tz_enable(int tz_id);
> +int thermal_notify_tz_disable(int tz_id);
> +int thermal_notify_tz_trip_down(int tz_id, int id);
> +int thermal_notify_tz_trip_up(int tz_id, int id);
> +int thermal_notify_tz_trip_delete(int tz_id, int id);
> +int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> + int temp, int hyst);
> +int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> + int temp, int hyst);
> +int thermal_notify_cdev_update(int cdev_id, int state);
> +int thermal_notify_cdev_add(int cdev_id, const char *name,
> + int min_state, int max_state);
> +int thermal_notify_cdev_delete(int cdev_id);
> +int thermal_notify_tz_gov_change(int tz_id, const char *name);
> +int thermal_genl_sampling_temp(int id, int temp);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> new file mode 100644
> index ..a8d6a815a21d
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -0,0 +1,645 @@
>
Re: [PATCH v2 1/5] thermal: core: Add helpers to browse the cdev, tz and governor list
On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano
wrote:
>
> The cdev, tz and governor list, as well as their respective locks are
> statically defined in the thermal_core.c file.
>
> In order to give a sane access to these list, like browsing all the
> thermal zones or all the cooling devices, let's define a set of
> helpers where we pass a callback as a parameter to be called for each
> thermal entity.
>
> We keep the self-encapsulation and ensure the locks are correctly
> taken when looking at the list.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/thermal_core.c | 51 ++
Is the idea to not use thermal_helpers.c from now on? It fits
perfectly with a patch I have to merge all its contents to
thermal_core.c :-)
> drivers/thermal/thermal_core.h | 9 ++
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 2a3f83265d8b..e2f8d2550ecd 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -611,6 +611,57 @@ void thermal_zone_device_rebind_exception(struct
> thermal_zone_device *tz,
> mutex_unlock(_list_lock);
> }
>
> +int for_each_thermal_governor(int (*cb)(struct thermal_governor *, void *),
> + void *data)
> +{
> + struct thermal_governor *gov;
> + int ret = 0;
> +
> + mutex_lock(_governor_lock);
> + list_for_each_entry(gov, _governor_list, governor_list) {
> + ret = cb(gov, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_governor_lock);
> +
> + return ret;
> +}
> +
> +int for_each_thermal_cooling_device(int (*cb)(struct thermal_cooling_device
> *,
> + void *), void *data)
> +{
> + struct thermal_cooling_device *cdev;
> + int ret = 0;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(cdev, _cdev_list, node) {
> + ret = cb(cdev, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_list_lock);
> +
> + return ret;
> +}
> +
> +int for_each_thermal_zone(int (*cb)(struct thermal_zone_device *, void *),
> + void *data)
> +{
> + struct thermal_zone_device *tz;
> + int ret = 0;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(tz, _tz_list, node) {
> + ret = cb(tz, data);
> + if (ret)
> + break;
> + }
> + mutex_unlock(_list_lock);
> +
> + return ret;
> +}
> +
> void thermal_zone_device_unbind_exception(struct thermal_zone_device *tz,
> const char *cdev_type, size_t size)
> {
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 4e271016b7a9..bb8f8aee79eb 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -41,6 +41,15 @@ extern struct thermal_governor
> *__governor_thermal_table_end[];
> __governor < __governor_thermal_table_end; \
> __governor++)
>
> +int for_each_thermal_zone(int (*cb)(struct thermal_zone_device *, void *),
> + void *);
> +
> +int for_each_thermal_cooling_device(int (*cb)(struct thermal_cooling_device
> *,
> + void *), void *);
> +
> +int for_each_thermal_governor(int (*cb)(struct thermal_governor *, void *),
> + void *thermal_governor);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> --
> 2.17.1
>
Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support
On Tue, Jun 30, 2020 at 12:07 PM Andy Tang wrote:
>
>
>
> > -Original Message-
> > From: Amit Kucheria
> > Sent: 2020年6月30日 13:37
> > To: Andy Tang
> > Cc: Shawn Guo ; Leo Li ; Rob
> > Herring ; lakml ;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; LKML
> > Subject: Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> > zone support
> >
> > Caution: EXT Email
> >
> > On Tue, Jun 30, 2020 at 10:58 AM Andy Tang wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Amit Kucheria
> > > > Sent: 2020年6月30日 13:12
> > > > To: Andy Tang
> > > > Cc: Shawn Guo ; Leo Li ;
> > > > Rob Herring ; lakml
> > > > ;
> > > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > > ; LKML
> > > > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> > > > zone support
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Tue, Jun 30, 2020 at 8:56 AM wrote:
> > > > >
> > > > > From: Yuantian Tang
> > > > >
> > > > > There are 2 thermal zones in ls1088a soc. Add the other thermal
> > > > > zone node to enable it.
> > > > > Also update the values in calibration table to make the
> > > > > temperatures monitored more precise.
> > > > >
> > > > > Signed-off-by: Yuantian Tang
> > > > > ---
> > > > > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > > > +++---
> > > > > 1 file changed, 62 insertions(+), 38 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > index 36a799554620..ccbbc23e6c85 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > @@ -129,19 +129,19 @@
> > > > > };
> > > > >
> > > > > thermal-zones {
> > > > > - cpu_thermal: cpu-thermal {
> > > > > + core-cluster {
> > > > > polling-delay-passive = <1000>;
> > > > > polling-delay = <5000>;
> > > > > thermal-sensors = < 0>;
> > > > >
> > > > > trips {
> > > > > - cpu_alert: cpu-alert {
> > > > > + core_cluster_alert:
> > > > core-cluster-alert
> > > > > + {
> > > > > temperature =
> > <85000>;
> > > > > hysteresis = <2000>;
> > > > > type = "passive";
> > > > > };
> > > > >
> > > > > - cpu_crit: cpu-crit {
> > > > > + core_cluster_crit:
> > > > > + core-cluster-crit {
> > > > > temperature =
> > <95000>;
> > > > > hysteresis = <2000>;
> > > > > type = "critical"; @@
> > > > -150,7
> > > > > +150,7 @@
> > > > >
> > > > > cooling-maps {
> > > > > map0 {
> > > > > - trip = <_alert>;
> > > > > + trip =
> > > > <_cluster_alert>;
> > > > > cooling-device =
> > > > > <
> > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > > > <
> > > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26 @@
> > > > > };
> > > > > };
> > > > >
[PATCH] MAINTAINERS: update Amit Kucheria's email to a single email address
Emails currently go to different mailboxes. Switch to the kernel.org address so I can forward them to a single mailbox. Signed-off-by: Amit Kucheria --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 2 +- MAINTAINERS | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index d7be931b42d22..0985e65a9d871 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: QCOM SoC Temperature Sensor (TSENS) maintainers: - - Amit Kucheria + - Amit Kucheria description: | QCOM SoCs have TSENS IP to allow temperature measurement. There are currently diff --git a/MAINTAINERS b/MAINTAINERS index 496fd4eafb68c..f80cb6185662f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14230,7 +14230,7 @@ F: drivers/net/ethernet/qualcomm/rmnet/ F: include/linux/if_rmnet.h QUALCOMM TSENS THERMAL DRIVER -M: Amit Kucheria +M: Amit Kucheria L: linux...@vger.kernel.org L: linux-arm-...@vger.kernel.org S: Maintained @@ -16930,7 +16930,7 @@ F: drivers/media/radio/radio-raremono.c THERMAL M: Zhang Rui M: Daniel Lezcano -R: Amit Kucheria +R: Amit Kucheria L: linux...@vger.kernel.org S: Supported Q: https://patchwork.kernel.org/project/linux-pm/list/ -- 2.25.1
Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support
On Tue, Jun 30, 2020 at 10:58 AM Andy Tang wrote:
>
>
>
> > -Original Message-
> > From: Amit Kucheria
> > Sent: 2020年6月30日 13:12
> > To: Andy Tang
> > Cc: Shawn Guo ; Leo Li ; Rob
> > Herring ; lakml ;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; LKML
> > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone
> > support
> >
> > Caution: EXT Email
> >
> > On Tue, Jun 30, 2020 at 8:56 AM wrote:
> > >
> > > From: Yuantian Tang
> > >
> > > There are 2 thermal zones in ls1088a soc. Add the other thermal zone
> > > node to enable it.
> > > Also update the values in calibration table to make the temperatures
> > > monitored more precise.
> > >
> > > Signed-off-by: Yuantian Tang
> > > ---
> > > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > +++---
> > > 1 file changed, 62 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > index 36a799554620..ccbbc23e6c85 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > @@ -129,19 +129,19 @@
> > > };
> > >
> > > thermal-zones {
> > > - cpu_thermal: cpu-thermal {
> > > + core-cluster {
> > > polling-delay-passive = <1000>;
> > > polling-delay = <5000>;
> > > thermal-sensors = < 0>;
> > >
> > > trips {
> > > - cpu_alert: cpu-alert {
> > > + core_cluster_alert:
> > core-cluster-alert
> > > + {
> > > temperature = <85000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > >
> > > - cpu_crit: cpu-crit {
> > > + core_cluster_crit: core-cluster-crit {
> > > temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "critical"; @@
> > -150,7
> > > +150,7 @@
> > >
> > > cooling-maps {
> > > map0 {
> > > - trip = <_alert>;
> > > + trip =
> > <_cluster_alert>;
> > > cooling-device =
> > > <
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > <
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26 @@
> > > };
> > > };
> > > };
> > > +
> > > + soc {
> > > + polling-delay-passive = <1000>;
> > > + polling-delay = <5000>;
> > > + thermal-sensors = < 1>;
> > > +
> > > + trips {
> > > + soc-alert {
> > > + temperature = <85000>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> > > + };
> > > +
> > > + soc-crit {
> > > + temperature = <95000>;
> > > + hysteresis = <2000>;
> > > + type = "critical";
> > > + };
> > > + };
> > > + };
> >
> > You should also add a cooling-maps section for this thermal zone given that
> > it
> > has a passive trip type. Otherwise there is no use for a passive trip type.
> It is better to have a cooling device. But there is only one cooling device
> on this platform
> which is used by core-cluster. So there is no extra cooling device for it.
> This zone can take action when critical temp is reached. So it is still
> useful.
> What do you suggest?
If the action taken by the core-cluster cooling-maps is the only one
that can be taken, I suggest getting rid of the the soc-alert passive
trip completely. It is not of any use.
If there is a chance that your soc thermal-zone can heat up before
your cpu-cluster zone (unlikely), you could use the same cooling
device (cpu0, cpu1) for soc thermal zone too.
Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support
On Tue, Jun 30, 2020 at 8:56 AM wrote:
>
> From: Yuantian Tang
>
> There are 2 thermal zones in ls1088a soc. Add the other thermal zone
> node to enable it.
> Also update the values in calibration table to make the temperatures
> monitored more precise.
>
> Signed-off-by: Yuantian Tang
> ---
> .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100 +++---
> 1 file changed, 62 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 36a799554620..ccbbc23e6c85 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -129,19 +129,19 @@
> };
>
> thermal-zones {
> - cpu_thermal: cpu-thermal {
> + core-cluster {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 0>;
>
> trips {
> - cpu_alert: cpu-alert {
> + core_cluster_alert: core-cluster-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - cpu_crit: cpu-crit {
> + core_cluster_crit: core-cluster-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> @@ -150,7 +150,7 @@
>
> cooling-maps {
> map0 {
> - trip = <_alert>;
> + trip = <_cluster_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> @@ -163,6 +163,26 @@
> };
> };
> };
> +
> + soc {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 1>;
> +
> + trips {
> + soc-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + soc-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
You should also add a cooling-maps section for this thermal zone given
that it has a passive trip type. Otherwise there is no use for a
passive trip type.
> };
>
> timer {
> @@ -209,45 +229,49 @@
> compatible = "fsl,qoriq-tmu";
> reg = <0x0 0x1f8 0x0 0x1>;
> interrupts = <0 23 0x4>;
> - fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
> + fsl,tmu-range = <0xb 0x9002a 0x6004c 0x70062>;
> fsl,tmu-calibration =
> /* Calibration data group 1 */
> - <0x 0x0026
> - 0x0001 0x002d
> - 0x0002 0x0032
> - 0x0003 0x0039
> - 0x0004 0x003f
> - 0x0005 0x0046
> - 0x0006 0x004d
> - 0x0007 0x0054
> - 0x0008 0x005a
> - 0x0009 0x0061
> - 0x000a 0x006a
> - 0x000b 0x0071
> + <0x 0x0023
> + 0x0001 0x002a
> + 0x0002 0x0030
> + 0x0003 0x0037
> + 0x0004 0x003d
> + 0x0005 0x0044
> + 0x0006 0x004a
> + 0x0007 0x0051
> + 0x0008 0x0057
> + 0x0009 0x005e
> +
Re: [PATCH] thermal: sprd: Fix return value of sprd_thm_probe()
On Fri, May 29, 2020 at 7:55 PM Baolin Wang wrote:
>
> Hi,
>
> On Mon, May 25, 2020 at 10:00 AM Tiezhu Yang wrote:
> >
> > When call function devm_platform_ioremap_resource(), we should use IS_ERR()
> > to check the return value and return PTR_ERR() if failed.
> >
> > Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support")
> > Signed-off-by: Tiezhu Yang
>
> Good catch. Thanks.
> Reviewed-by: Baolin Wang
Reviewed-by: Amit Kucheria
> > ---
> > drivers/thermal/sprd_thermal.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/sprd_thermal.c b/drivers/thermal/sprd_thermal.c
> > index a340374..4cde70d 100644
> > --- a/drivers/thermal/sprd_thermal.c
> > +++ b/drivers/thermal/sprd_thermal.c
> > @@ -348,8 +348,8 @@ static int sprd_thm_probe(struct platform_device *pdev)
> >
> > thm->var_data = pdata;
> > thm->base = devm_platform_ioremap_resource(pdev, 0);
> > - if (!thm->base)
> > - return -ENOMEM;
> > + if (IS_ERR(thm->base))
> > + return PTR_ERR(thm->base);
> >
> > thm->nr_sensors = of_get_child_count(np);
> > if (thm->nr_sensors == 0 || thm->nr_sensors > SPRD_THM_MAX_SENSOR) {
> > --
> > 2.1.0
> >
>
>
> --
> Baolin Wang
Re: [RFC PATCH linus] drivers: thermal: tsens: tsens_critical_irq_thread() can be static
Hi,
A patch to fix this was already submitted on 27th May.
I believe Daniel plans to send it as fixes for -rc4.
Regards,
Amit
On Sun, Jun 28, 2020 at 11:34 AM kernel test robot wrote:
>
>
> Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into
> tsens.c")
> Signed-off-by: kernel test robot
> ---
> tsens.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 8d3e94d2a9ed4..39c4462e38f62 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -382,7 +382,7 @@ static inline u32 masked_irq(u32 hw_id, u32 mask, enum
> tsens_ver ver)
> *
> * Return: IRQ_HANDLED
> */
> -irqreturn_t tsens_critical_irq_thread(int irq, void *data)
> +static irqreturn_t tsens_critical_irq_thread(int irq, void *data)
> {
> struct tsens_priv *priv = data;
> struct tsens_irq_data d;
> @@ -452,7 +452,7 @@ irqreturn_t tsens_critical_irq_thread(int irq, void *data)
> *
> * Return: IRQ_HANDLED
> */
> -irqreturn_t tsens_irq_thread(int irq, void *data)
> +static irqreturn_t tsens_irq_thread(int irq, void *data)
> {
> struct tsens_priv *priv = data;
> struct tsens_irq_data d;
> @@ -520,7 +520,7 @@ irqreturn_t tsens_irq_thread(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -int tsens_set_trips(void *_sensor, int low, int high)
> +static int tsens_set_trips(void *_sensor, int low, int high)
> {
> struct tsens_sensor *s = _sensor;
> struct tsens_priv *priv = s->priv;
> @@ -557,7 +557,7 @@ int tsens_set_trips(void *_sensor, int low, int high)
> return 0;
> }
>
> -int tsens_enable_irq(struct tsens_priv *priv)
> +static int tsens_enable_irq(struct tsens_priv *priv)
> {
> int ret;
> int val = tsens_version(priv) > VER_1_X ? 7 : 1;
> @@ -570,7 +570,7 @@ int tsens_enable_irq(struct tsens_priv *priv)
> return ret;
> }
>
> -void tsens_disable_irq(struct tsens_priv *priv)
> +static void tsens_disable_irq(struct tsens_priv *priv)
> {
> regmap_field_write(priv->rf[INT_EN], 0);
> }
Re: [PATCH 3/8] arm64: dts: qcom: sdm630: Add tsens node
On Wed, Jun 24, 2020 at 8:32 PM Konrad Dybcio wrote: > > Interesting, the downstream DTS only mentions the 0x010AD one.. > Are you sure you're not looking at 636/660? > I looked a bit closer. So there are two instances of the controller but the platform doesn't have as many sensors. So using just one controller is fine. I suspect the other controller might be disabled in firmware. Regards, Amit
Re: [PATCH 3/8] arm64: dts: qcom: sdm630: Add tsens node
On Tue, Jun 23, 2020 at 11:39 PM Konrad Dybcio wrote:
>
> Enable tsens on this SoC using tsens-v2 driver.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
> arch/arm64/boot/dts/qcom/sdm630.dtsi | 11 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index d7be931b42d2..d89d5acd6e2a 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -39,6 +39,7 @@ properties:
>- qcom,msm8996-tsens
>- qcom,msm8998-tsens
>- qcom,sc7180-tsens
> + - qcom,sdm630-tsens
>- qcom,sdm845-tsens
>- const: qcom,tsens-v2
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index ea85f28032d2..92bf4ae6a590 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -566,6 +566,17 @@ anoc2_smmu: iommu@16c {
> ;
> };
>
> + tsens: thermal-sensor@10ae000 {
> + compatible = "qcom,sdm630-tsens", "qcom,tsens-v2";
> + reg = <0x010ae000 0x1000>, /* TM */
> + <0x010ad000 0x1000>; /* SROT */
> + #qcom,sensors = <12>;
> + interrupts = ,
> +;
> + interrupt-names = "uplow", "critical";
> + #thermal-sensor-cells = <1>;
> + };
> +
There should be 2 tsens controllers on this platform, the first at
0x010AA000, the other at 0x010AD000.
> tcsr_mutex_regs: syscon@1f4 {
> compatible = "syscon";
> reg = <0x01f4 0x2>;
> --
> 2.27.0
>
Re: [PATCH] dt-bindings: thermal: Get rid of thermal.txt and replace references
On Tue, Apr 14, 2020 at 10:14 PM Rob Herring wrote: > > On Wed, 1 Apr 2020 20:35:50 +0530, Amit Kucheria wrote: > > Now that we have yaml bindings for the thermal subsystem, get rid of the > > old bindings (thermal.txt). > > > > Replace all references to thermal.txt in the Documentation with a link > > to the appropriate YAML bindings using the following search and replace > > pattern: > > - If the reference is specific to the thermal-sensor-cells property, > > replace with a pointer to thermal-sensor.yaml > > - If the reference is to the cooling-cells property, replace with a > > pointer to thermal-cooling-devices.yaml > > - If the reference is generic thermal bindings, replace with a > > reference to thermal*.yaml. > > > > Signed-off-by: Amit Kucheria > > --- > > .../devicetree/bindings/arm/arm,scmi.txt | 2 +- > > .../devicetree/bindings/arm/arm,scpi.txt | 2 +- > > .../arm/marvell/ap80x-system-controller.txt | 2 +- > > .../arm/marvell/cp110-system-controller.txt | 2 +- > > .../bindings/cpufreq/cpufreq-dt.txt | 3 +- > > .../bindings/cpufreq/cpufreq-mediatek.txt | 4 +- > > .../devicetree/bindings/hwmon/gpio-fan.txt| 3 +- > > .../devicetree/bindings/hwmon/lm90.txt| 4 +- > > .../thermal/allwinner,sun8i-a83t-ths.yaml | 2 +- > > .../bindings/thermal/amazon,al-thermal.txt| 2 +- > > .../bindings/thermal/brcm,avs-ro-thermal.yaml | 2 +- > > .../bindings/thermal/brcm,bcm2835-thermal.txt | 2 +- > > .../bindings/thermal/hisilicon-thermal.txt| 2 +- > > .../bindings/thermal/max77620_thermal.txt | 6 +- > > .../bindings/thermal/mediatek-thermal.txt | 2 +- > > .../thermal/nvidia,tegra124-soctherm.txt | 10 +- > > .../thermal/nvidia,tegra186-bpmp-thermal.txt | 2 +- > > .../bindings/thermal/qcom-spmi-temp-alarm.txt | 2 +- > > .../bindings/thermal/rockchip-thermal.txt | 2 +- > > .../bindings/thermal/tango-thermal.txt| 2 +- > > .../bindings/thermal/thermal-generic-adc.txt | 2 +- > > .../devicetree/bindings/thermal/thermal.txt | 586 -- > > .../bindings/thermal/uniphier-thermal.txt | 2 +- > > 23 files changed, 33 insertions(+), 615 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt > > > > Reviewed-by: Rob Herring Daniel, Rob, This seems to have been missed in the 5.8 merge window. I suspect this should go in through the thermal tree. Regards, Amit
Re: [PATCH] drivers/thermal: Use kobj_to_dev() instead
On Mon, Jun 15, 2020 at 2:37 PM Wang Qing wrote:
>
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
Acked-by: Amit Kucheria
> ---
> drivers/thermal/thermal_sysfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> mode change 100644 => 100755 drivers/thermal/thermal_sysfs.c
>
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa99edb..3e92ff9
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -438,7 +438,7 @@ static umode_t thermal_zone_mode_is_visible(struct
> kobject *kobj,
> struct attribute *attr,
> int attrno)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct thermal_zone_device *tz;
>
> tz = container_of(dev, struct thermal_zone_device, device);
> @@ -464,7 +464,7 @@ static umode_t thermal_zone_passive_is_visible(struct
> kobject *kobj,
>struct attribute *attr,
>int attrno)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct thermal_zone_device *tz;
> enum thermal_trip_type trip_type;
> int count, passive = 0;
> --
> 2.7.4
>
Re: [PATCH] thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
Hi Finley,
Please use versioning (v2) when resending a patch.
On Fri, Jun 19, 2020 at 2:39 PM Finley Xiao wrote:
>
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the power to be converted is 80mW, and the em table is as follow.
> struct em_cap_state table[] = {
> /* KHz mW */
> { 1008000, 36, 0 },
> { 120, 49, 0 },
> { 1296000, 59, 0 },
> { 1416000, 72, 0 },
> { 1512000, 86, 0 },
> };
> The target frequency should be 1416000KHz, not 1512000KHz.
>
> Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables")
> Cc: # v4.13+
> Signed-off-by: Finley Xiao
> Acked-by: Viresh Kumar
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/cpufreq_cooling.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/cpufreq_cooling.c
> b/drivers/thermal/cpufreq_cooling.c
> index 9e124020519f..6c0e1b053126 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -123,12 +123,12 @@ static u32 cpu_power_to_freq(struct
> cpufreq_cooling_device *cpufreq_cdev,
> {
> int i;
>
> - for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> - if (power > cpufreq_cdev->em->table[i].power)
> + for (i = cpufreq_cdev->max_level; i >= 0; i--) {
> + if (power >= cpufreq_cdev->em->table[i].power)
> break;
> }
>
> - return cpufreq_cdev->em->table[i + 1].frequency;
> + return cpufreq_cdev->em->table[i].frequency;
> }
>
> /**
> --
> 2.11.0
>
>
>
Re: [PATCH] thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
On Fri, Jun 19, 2020 at 7:21 AM Finley Xiao wrote:
>
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the power to be converted is 80mW, and the em table is as follow.
> struct em_cap_state table[] = {
> /* KHz mW */
> { 1008000, 36, 0 },
> { 120, 49, 0 },
> { 1296000, 59, 0 },
> { 1416000, 72, 0 },
> { 1512000, 86, 0 },
> };
> The target frequency should be 1416000KHz, not 1512000KHz.
>
> Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables")
> Signed-off-by: Finley Xiao
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/cpufreq_cooling.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/cpufreq_cooling.c
> b/drivers/thermal/cpufreq_cooling.c
> index 9e124020519f..6c0e1b053126 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -123,12 +123,12 @@ static u32 cpu_power_to_freq(struct
> cpufreq_cooling_device *cpufreq_cdev,
> {
> int i;
>
> - for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> - if (power > cpufreq_cdev->em->table[i].power)
> + for (i = cpufreq_cdev->max_level; i >= 0; i--) {
> + if (power >= cpufreq_cdev->em->table[i].power)
> break;
> }
>
> - return cpufreq_cdev->em->table[i + 1].frequency;
> + return cpufreq_cdev->em->table[i].frequency;
> }
>
> /**
> --
> 2.11.0
>
>
>
Re: [PATCH v3 0/5] mfd: Add support for Khadas Microcontroller
On Thu, Jun 18, 2020 at 1:49 PM Lee Jones wrote: > > On Mon, 08 Jun 2020, Neil Armstrong wrote: > > > The new Khadas VIM2, VIM3 and Edge boards embeds an on-board microcontroller > > connected via I2C. > > > > This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge > > boards. > > > > It has multiple boot control features like password check, power-on > > options, power-off control and system FAN control on recent boards. > > > > Thie serie adds : > > - the bindings > > - the MFD driver > > - the Thermal Cooling cell driver > > - updates MAINTAINERS > > - add support into the Khadas VIM3/VIM3L DT > > > > Changes since v2 at [3]: > > - Removed NVMEM driver for separate submission > > - fixed MFD driver, header and Kconfig > > - fixed Thermal Kconfig > > - fixed MAINTAINERS files and path > > > > Changes since RFC v1 at [2]: > > - moved hwmon driver to thermal-only > > - moved the SM1 thermal nodes in a separate serie > > - added the bindings review tag from rob > > > > [1] http://lore.kernel.org/r/20200512093916.19676-1-narmstr...@baylibre.com > > [2] http://lore.kernel.org/r/20200421080102.22796-1-narmstr...@baylibre.com > > [3] http://lore.kernel.org/r/20200512132613.31507-1-narmstr...@baylibre.com > > > > Neil Armstrong (5): > > dt-bindings: mfd: add Khadas Microcontroller bindings > > mfd: add support for the Khadas System control Microcontroller > > thermal: add support for the MCU controlled FAN on Khadas boards > > MAINTAINERS: add myself as maintainer for Khadas MCU drivers > > arm64: dts: meson-khadas-vim3: add Khadas MCU nodes > > I'm a bit concerned by the missing patches from my inbox. > > Looks like you omitted to send me patch 3 and 5. > > Hopefully the Thermal patch doesn't depend on the MFD one! Neil did mention that it depends on include/linux/mfd/khadas-mcu.h. So I think we should just merge this through the MFD tree. > > > .../devicetree/bindings/mfd/khadas,mcu.yaml | 44 + > > MAINTAINERS | 9 + > > .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 23 +++ > > drivers/mfd/Kconfig | 21 +++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/khadas-mcu.c | 142 ++ > > drivers/thermal/Kconfig | 11 ++ > > drivers/thermal/Makefile | 1 + > > drivers/thermal/khadas_mcu_fan.c | 174 ++ > > include/linux/mfd/khadas-mcu.h| 91 + > > 10 files changed, 517 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/khadas,mcu.yaml > > create mode 100644 drivers/mfd/khadas-mcu.c > > create mode 100644 drivers/thermal/khadas_mcu_fan.c > > create mode 100644 include/linux/mfd/khadas-mcu.h > > > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 1/2] thermal: add support for the MCU controlled FAN on Khadas boards
On Thu, Jun 18, 2020 at 9:58 PM Lee Jones wrote: > > On Thu, 18 Jun 2020, Neil Armstrong wrote: > > > The new Khadas VIM2 and VIM3 boards controls the cooling fan via the > > on-board microcontroller. > > > > This implements the FAN control as thermal devices and as cell of the Khadas > > MCU MFD driver. > > > > Signed-off-by: Neil Armstrong > > Reviewed-by: Amit Kucheria > > Is this an Ack? Acked-by: Amit Kucheria > If so, do you require a pull-request? I'll let Daniel comment about the PR but AFAICT, this can get merged through the MFD tree. > > --- > > Hi Lee, > > > > Could you apply this patch via the MFD tree since it depends on > > the linux/mfd/khadas-mcu.h header ? > > > > This patch is unchanged from the v3 serie. > > > > Thanks, > > Neil > > > > drivers/thermal/Kconfig | 11 ++ > > drivers/thermal/Makefile | 1 + > > drivers/thermal/khadas_mcu_fan.c | 174 +++ > > 3 files changed, 186 insertions(+) > > create mode 100644 drivers/thermal/khadas_mcu_fan.c > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 3/3] arm64: dts: qcom: sm8250: Add thermal zones and throttling support
On Sun, Jun 21, 2020 at 12:51 PM Bjorn Andersson
wrote:
>
> On Mon 08 Jun 23:44 PDT 2020, Amit Kucheria wrote:
>
> > sm8250 has 24 thermal sensors split across two tsens controllers. Add
> > the thermal zones to expose them and wireup the cpus to throttle on
> > crossing passive temperature thresholds.
> >
> > Update the comment in the drivers to list the SoCs it supports.
> >
> > Signed-off-by: Amit Kucheria
> > ---
> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 766 +++
> > drivers/thermal/qcom/tsens-v2.c | 2 +-
> > 2 files changed, 767 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > index deaa8415c7b72..5cd18cd8a675b 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > / {
> > interrupt-parent = <>;
> > @@ -86,6 +87,7 @@ CPU0: cpu@0 {
> > enable-method = "psci";
> > next-level-cache = <_0>;
> > qcom,freq-domain = <_hw 0>;
> > + #cooling-cells = <2>;
>
> This doesn't apply to linux-next.
>
> The problem seems to be that, as pointed out when I submitted that
> patch, the previously anonymous "cpufreq hardware" is now replaced by
> the "EPSS" hardware block.
I'll take a look.
> So we need a new driver (or update the existing one) to support this new
> hardware block.
>
> Presumably though, without this there's not much cooling anyways - which
> is sad, as your patch looks good.
>
> > L2_0: l2-cache {
> > compatible = "cache";
> > next-level-cache = <_0>;
> [..]
> > diff --git a/drivers/thermal/qcom/tsens-v2.c
> > b/drivers/thermal/qcom/tsens-v2.c
> > index b293ed32174b5..58cac8f2a358c 100644
> > --- a/drivers/thermal/qcom/tsens-v2.c
> > +++ b/drivers/thermal/qcom/tsens-v2.c
> > @@ -26,7 +26,7 @@
> > #define TM_TRDY_OFF 0x00e4
> > #define TM_WDOG_LOG_OFF 0x013c
> >
> > -/* v2.x: 8996, 8998, sdm845 */
> > +/* v2.x: 8996, 8998, sc7180, sdm845, sm8150, sm8250 */
>
> Even though it's trivial, can you please send this through the tsens
> tree instead, so we don't end up having unnecessary merge conflicts.
>
Will do. Thanks for the review.
Re: [PATCH v3 3/5] thermal: add support for the MCU controlled FAN on Khadas boards
On Mon, Jun 8, 2020 at 2:47 PM Neil Armstrong wrote:
>
> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
> on-board microcontroller.
>
> This implements the FAN control as thermal devices and as cell of the Khadas
> MCU MFD driver.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/Kconfig | 11 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/khadas_mcu_fan.c | 174 +++
> 3 files changed, 186 insertions(+)
> create mode 100644 drivers/thermal/khadas_mcu_fan.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 91af271e9bb0..53efd381f434 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -490,4 +490,15 @@ config SPRD_THERMAL
> help
> Support for the Spreadtrum thermal sensor driver in the Linux
> thermal
> framework.
> +
> +config KHADAS_MCU_FAN_THERMAL
> + tristate "Khadas MCU controller FAN cooling support"
> + depends on OF || COMPILE_TEST
> + depends on MFD_KHADAS_MCU
> + select MFD_CORE
> + select REGMAP
> + help
> + If you say yes here you get support for the FAN controlled
> + by the Microcontroller found on the Khadas VIM boards.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..460428c2122c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
> +obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
> diff --git a/drivers/thermal/khadas_mcu_fan.c
> b/drivers/thermal/khadas_mcu_fan.c
> new file mode 100644
> index ..6995b443cad4
> --- /dev/null
> +++ b/drivers/thermal/khadas_mcu_fan.c
> @@ -0,0 +1,174 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Khadas MCU Controlled FAN driver
> + *
> + * Copyright (C) 2020 BayLibre SAS
> + * Author(s): Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_LEVEL 3
> +
> +struct khadas_mcu_fan_ctx {
> + struct khadas_mcu *mcu;
> + unsigned int level;
> + struct thermal_cooling_device *cdev;
> +};
> +
> +static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> + unsigned int level)
> +{
> + int ret;
> +
> + ret = regmap_write(ctx->mcu->regmap,
> KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + level);
> + if (ret)
> + return ret;
> +
> + ctx->level = level;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = MAX_LEVEL;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = ctx->level;
> +
> + return 0;
> +}
> +
> +static int
> +khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
> +unsigned long state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx || (state > MAX_LEVEL))
> + return -EINVAL;
> +
> + if (state == ctx->level)
> + return 0;
> +
> + return khadas_mcu_fan_set_level(ctx, state);
> +}
> +
> +static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
> + .get_max_state = khadas_mcu_fan_get_max_state,
> + .get_cur_state = khadas_mcu_fan_get_cur_state,
> + .set_cur_state = khadas_mcu_fan_set_cur_state,
> +};
> +
> +static int khadas_mcu_fan_probe(struct platform_device *pdev)
> +{
> + struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
> + struct thermal_cooling_device *cdev;
> + struct device *dev = >dev;
> + struct khadas_mcu_fan_ctx *ctx;
> + int ret;
Re: [PATCH v3 5/5] arm64: dts: meson-khadas-vim3: add Khadas MCU nodes
On Mon, Jun 8, 2020 at 2:47 PM Neil Armstrong wrote:
>
> Add the Khadas MCU node with active FAN thermal nodes for all the
> Khadas VIM3 variants.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Amit Kucheria
> ---
> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> index 094ecfbb..3325e54ea690 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> @@ -183,6 +183,23 @@
> hdmi-phandle = <_tx>;
> };
>
> +_thermal {
> + trips {
> + cpu_active: cpu-active {
> + temperature = <8>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map {
> + trip = <_active>;
> + cooling-device = <_mcu THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> _mdio {
> external_phy: ethernet-phy@0 {
> /* Realtek RTL8211F (0x001cc916) */
> @@ -222,6 +239,12 @@
> pinctrl-0 = <_ao_sck_pins>, <_ao_sda_pins>;
> pinctrl-names = "default";
>
> + khadas_mcu: system-controller@18 {
> + compatible = "khadas,mcu";
> + reg = <0x18>;
> + #cooling-cells = <2>;
> + };
> +
> gpio_expander: gpio-controller@20 {
> compatible = "ti,tca6408";
> reg = <0x20>;
> --
> 2.22.0
>
[PATCH 1/3] dt-bindings: thermal: qcom-tsens: Add compatible for sm8150, sm8250
Added tsens bindings for sm8150 and sm8250 Signed-off-by: Amit Kucheria --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 2ddd39d967662..dee3836a82854 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -40,6 +40,8 @@ properties: - qcom,msm8998-tsens - qcom,sc7180-tsens - qcom,sdm845-tsens + - qcom,sm8150-tsens + - qcom,sm8250-tsens - const: qcom,tsens-v2 reg: -- 2.25.1
[PATCH 3/3] arm64: dts: qcom: sm8250: Add thermal zones and throttling support
sm8250 has 24 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle on
crossing passive temperature thresholds.
Update the comment in the drivers to list the SoCs it supports.
Signed-off-by: Amit Kucheria
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 766 +++
drivers/thermal/qcom/tsens-v2.c | 2 +-
2 files changed, 767 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index deaa8415c7b72..5cd18cd8a675b 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -86,6 +87,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <_0>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -102,6 +104,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <_100>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -115,6 +118,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <_200>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -128,6 +132,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <_300>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -141,6 +146,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <_400>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -154,6 +160,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <_500>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -168,6 +175,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <_600>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -181,6 +189,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <_700>;
qcom,freq-domain = <_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -991,6 +1000,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sm8250-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1ff>, /* TM */
+ <0 0x0c222000 0 0x1ff>; /* SROT */
+ #qcom,sensors = <16>;
+ interrupts = ,
+;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sm8250-tsens"
[PATCH 2/3] arm64: dts: qcom: sm8150: Add thermal zones and throttling support
sm8150 has 27 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle their
frequencies on crossing passive temperature thresholds.
Signed-off-by: Amit Kucheria
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 811 +++
1 file changed, 811 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 141c21dfa68c0..e3658711e 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -46,6 +47,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <_0>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -62,6 +64,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <_100>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -76,6 +79,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <_200>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -89,6 +93,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <_300>;
qcom,freq-domain = <_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -102,6 +107,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <_400>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -115,6 +121,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <_500>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -128,6 +135,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <_600>;
qcom,freq-domain = <_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -141,6 +149,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <_700>;
qcom,freq-domain = <_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
@@ -631,6 +640,28 @@ aoss_qmp: power-controller@c30 {
#power-domain-cells = <1>;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sm8150-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1ff>, /* TM */
+ <0 0x0c222000 0 0x1ff>; /* SROT */
+ #qcom,sensors = <16>;
+ interrupts = ,
+;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sm8150-tsens", "qcom,tsens-v2";
+ reg = <0 0
[PATCH 0/3] Add thermal support for SM8150, SM8250
Add two new compatibles, the devicetree entries for the thermal zones and wire it up to the cpufreq cooling device. Amit Kucheria (3): dt-bindings: thermal: qcom-tsens: Add compatible for sm8150, sm8250 arm64: dts: qcom: sm8150: Add thermal zones and throttling support arm64: dts: qcom: sm8250: Add thermal zones and throttling support .../bindings/thermal/qcom-tsens.yaml | 2 + arch/arm64/boot/dts/qcom/sm8150.dtsi | 811 ++ arch/arm64/boot/dts/qcom/sm8250.dtsi | 766 + drivers/thermal/qcom/tsens-v2.c | 2 +- 4 files changed, 1580 insertions(+), 1 deletion(-) -- 2.25.1
Re: [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics
On Tue, May 5, 2020 at 3:07 AM David Rientjes wrote: > > On Mon, 4 May 2020, Emanuele Giuseppe Esposito wrote: > > > There is currently no common way for Linux kernel subsystems to expose > > statistics to userspace shared throughout the Linux kernel; subsystems > > have to take care of gathering and displaying statistics by themselves, > > for example in the form of files in debugfs. For example KVM has its own > > code section that takes care of this in virt/kvm/kvm_main.c, where it sets > > up debugfs handlers for displaying values and aggregating them from > > various subfolders to obtain information about the system state (i.e. > > displaying the total number of exits, calculated by summing all exits of > > all cpus of all running virtual machines). > > > > Allowing each section of the kernel to do so has two disadvantages. First, > > it will introduce redundant code. Second, debugfs is anyway not the right > > place for statistics (for example it is affected by lockdown) > > > > In this patch series I introduce statsfs, a synthetic ram-based virtual > > filesystem that takes care of gathering and displaying statistics for the > > Linux kernel subsystems. > > > > This is exciting, we have been looking in the same area recently. Adding > Jonathan Adams . > > In your diffstat, one thing I notice that is omitted: an update to > Documentation/* :) Any chance of getting some proposed Documentation/ > updates with structure of the fs, the per subsystem breakdown, and best > practices for managing the stats from the kernel level? > > > The file system is mounted on /sys/kernel/stats and would be already used > > by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. > > > > Statsfs offers a generic and stable API, allowing any kind of > > directory/file organization and supporting multiple kind of aggregations > > (not only sum, but also average, max, min and count_zero) and data types > > (all unsigned and signed types plus boolean). The implementation, which is > > a generalization of KVM’s debugfs statistics code, takes care of gathering > > and displaying information at run time; users only need to specify the > > values to be included in each source. > > > > Statsfs would also be a different mountpoint from debugfs, and would not > > suffer from limited access due to the security lock down patches. Its main > > function is to display each statistics as a file in the desired folder > > hierarchy defined through the API. Statsfs files can be read, and possibly > > cleared if their file mode allows it. > > > > Statsfs has two main components: the public API defined by > > include/linux/statsfs.h, and the virtual file system which should end up > > in /sys/kernel/stats. > > > > The API has two main elements, values and sources. Kernel subsystems like > > KVM can use the API to create a source, add child > > sources/values/aggregates and register it to the root source (that on the > > virtual fs would be /sys/kernel/statsfs). > > > > Sources are created via statsfs_source_create(), and each source becomes a > > directory in the file system. Sources form a parent-child relationship; > > root sources are added to the file system via statsfs_source_register(). > > Every other source is added to or removed from a parent through the > > statsfs_source_add_subordinate and statsfs_source_remote_subordinate APIs. > > Once a source is created and added to the tree (via add_subordinate), it > > will be used to compute aggregate values in the parent source. > > > > Values represent quantites that are gathered by the statsfs user. Examples > > of values include the number of vm exits of a given kind, the amount of > > memory used by some data structure, the length of the longest hash table > > chain, or anything like that. Values are defined with the > > statsfs_source_add_values function. Each value is defined by a struct > > statsfs_value; the same statsfs_value can be added to many different > > sources. A value can be considered "simple" if it fetches data from a > > user-provided location, or "aggregate" if it groups all values in the > > subordinates sources that include the same statsfs_value. > > > > This seems like it could have a lot of overhead if we wanted to > periodically track the totality of subsystem stats as a form of telemetry > gathering from userspace. To collect telemetry for 1,000 different stats, > do we need to issue lseek()+read() syscalls for each of them individually > (or, worse, open()+read()+close())? > > Any thoughts on how that can be optimized? A couple of ideas: > > - an interface that allows gathering of all stats for a particular >interface through a single file that would likely be encoded in binary >and the responsibility of userspace to disseminate, or > > - an interface that extends beyond this proposal and allows the reader to >specify which stats they are interested in collecting and then the >kernel will only provide these stats in a well formed
Re: [RFC][PATCH 3/5] thermal: Add support for setting notification thresholds
Hi Srinivas, On Wed, May 20, 2020 at 11:46 PM Srinivas Pandruvada wrote: > > On Wed, 2020-05-20 at 09:58 +0530, Amit Kucheria wrote: > > On Tue, May 19, 2020 at 5:10 AM Srinivas Pandruvada > > wrote: > > > On Mon, 2020-05-18 at 18:37 +0200, Daniel Lezcano wrote: > > > > On 04/05/2020 20:16, Srinivas Pandruvada wrote: > > > > > Add new attributes in thermal syfs when a thermal drivers > > > > > provides > > > > > callbacks for them and CONFIG_THERMAL_USER_EVENT_INTERFACE is > > > > > defined. > > > > > > > > > > These attribute allow user space to stop polling for > > > > > temperature. > > > > > > > > > > These attributes are: > > > > > - temp_thres_low: Specify a notification temperature for a low > > > > > temperature threshold event. > > > > > temp_thres_high: Specify a notification temperature for a high > > > > > temperature threshold event. > > > > > temp_thres_hyst: Specify a change in temperature to send > > > > > notification > > > > > again. > > > > > > > > > > This is implemented by adding additional sysfs attribute group. > > > > > The > > > > > changes in this patch are trivial to add new attributes in > > > > > thermal > > > > > sysfs as done for other attributes. > > > > > > > > Isn't it duplicate with the trip point? > > > A trip point is where an in-kernel governor takes some action. This > > > is > > > not same as a notification temperature. For example at trip point > > > configured by ACPI at 85C, the thermal governor may start > > > aggressive > > > throttling. > > > But a user space can set a notification threshold at 80C and start > > > some > > > active controls like activate some fan to reduce the impact of > > > passive > > > control on performance. > > > > Then what is the use of thermal trip type "ACTIVE" ? > This is an example. > The defaults are set by the OEMs via ACPI. User can't modify that if > they want to optimize for their usage on Linux. There are fan control > daemon's which user use on top. -ENOPARSE. Are you saying users "can" modify these? In any case, how is what you described earlier not possible with an ACTIVE trip point directly wired to the fan as a cooling device or with a HOT trip point that causes the platform driver to send notification to userspace where a fan control daemon can do what it needs to? Basically, I think the issue of polling is orthogonal to the introduction of the new attributes introduced in this patch and I don't understand the reason for these attributes from your commit description. > > > We need a way to distinguish between temperature notification > > > threshold > > > and actual trip point. Changing a trip point means that user wants > > > kernel to throttle at temperature. >
Re: [PATCH v2 1/2] drivers: thermal: tsens: Add zeroc interrupt support
On Sun, May 17, 2020 at 4:17 PM Manaf Meethalavalappu Pallikunhi
wrote:
>
> TSENS IP v2.6+ adds zeroc interrupt support. It triggers set
As I re-read through these patches, shouldn't we just call it the
"cold" interrupt?
> interrupt when aggregated minimum temperature of all TSENS falls
> below zeroc preset threshold and triggers reset interrupt when
Again, cold would just capture the intent much better given that it
doesn't even triggered at zero but at 5 degrees. And this value could
change in firmware.
> aggregated minimum temperature of all TSENS crosses above reset
> threshold. Add support for this interrupt in the driver.
>
> It adds another sensor to the of-thermal along with all individual
> TSENS. It enables to add any mitigation for zeroc interrupt.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi
> ---
> drivers/thermal/qcom/tsens-v2.c | 5 ++
> drivers/thermal/qcom/tsens.c| 107 +++-
> drivers/thermal/qcom/tsens.h| 10 +++
> 3 files changed, 120 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index b293ed32174b..8f30b859ab22 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -23,6 +23,7 @@
> #define TM_Sn_UPPER_LOWER_THRESHOLD_OFF 0x0020
> #define TM_Sn_CRITICAL_THRESHOLD_OFF 0x0060
> #define TM_Sn_STATUS_OFF 0x00a0
> +#define TM_ZEROC_INT_STATUS_OFF0x00e0
> #define TM_TRDY_OFF0x00e4
> #define TM_WDOG_LOG_OFF0x013c
>
> @@ -86,6 +87,9 @@ static const struct reg_field
> tsens_v2_regfields[MAX_REGFIELDS] = {
> REG_FIELD_FOR_EACH_SENSOR16(CRITICAL_STATUS, TM_Sn_STATUS_OFF, 19,
> 19),
> REG_FIELD_FOR_EACH_SENSOR16(MAX_STATUS, TM_Sn_STATUS_OFF, 20,
> 20),
>
> + /* ZEROC INTERRUPT STATUS */
> + [ZEROC_STATUS] = REG_FIELD(TM_ZEROC_INT_STATUS_OFF, 0, 0),
> +
> /* TRDY: 1=ready, 0=in progress */
> [TRDY] = REG_FIELD(TM_TRDY_OFF, 0, 0),
> };
> @@ -93,6 +97,7 @@ static const struct reg_field
> tsens_v2_regfields[MAX_REGFIELDS] = {
> static const struct tsens_ops ops_generic_v2 = {
> .init = init_common,
> .get_temp = get_temp_tsens_valid,
> + .get_zeroc_status = get_tsens_zeroc_status,
> };
>
> struct tsens_plat_data data_tsens_v2 = {
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 8d3e94d2a9ed..dd0172f05eb6 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -205,7 +205,8 @@ static void tsens_set_interrupt_v1(struct tsens_priv
> *priv, u32 hw_id,
> index = LOW_INT_CLEAR_0 + hw_id;
> break;
> case CRITICAL:
> - /* No critical interrupts before v2 */
> + case ZEROC:
> + /* No critical and zeroc interrupts before v2 */
> return;
> }
> regmap_field_write(priv->rf[index], enable ? 0 : 1);
> @@ -236,6 +237,9 @@ static void tsens_set_interrupt_v2(struct tsens_priv
> *priv, u32 hw_id,
> index_mask = CRIT_INT_MASK_0 + hw_id;
> index_clear = CRIT_INT_CLEAR_0 + hw_id;
> break;
> + case ZEROC:
> + /* Nothing to handle for zeroc interrupt */
> + return;
> }
>
> if (enable) {
> @@ -367,6 +371,35 @@ static inline u32 masked_irq(u32 hw_id, u32 mask, enum
> tsens_ver ver)
> return 0;
> }
>
> +/**
> + * tsens_zeroc_irq_thread - Threaded interrupt handler for zeroc interrupt
> + * @irq: irq number
> + * @data: tsens controller private data
> + *
> + * Whenever interrupt triggers notify thermal framework using
> + * thermal_zone_device_update().
> + *
> + * Return: IRQ_HANDLED
> + */
> +
> +irqreturn_t tsens_zeroc_irq_thread(int irq, void *data)
> +{
> + struct tsens_priv *priv = data;
> + struct tsens_sensor *s = >sensor[priv->num_sensors];
> + int temp, ret;
> +
> + ret = regmap_field_read(priv->rf[ZEROC_STATUS], );
> + if (ret)
> + return ret;
> +
> + dev_dbg(priv->dev, "[%u] %s: zeroc interrupt is %s\n",
> + s->hw_id, __func__, temp ? "triggered" : "cleared");
Rename temp to cold or something similar since you're not really
returning temperature but a boolean state on whether we're in cold
zone or not.
> +
> + thermal_zone_device_update(s->tzd, THERMAL_EVENT_UNSPECIFIED);
> +
> + return IRQ_HANDLED;
> +}
> +
> /**
> * tsens_critical_irq_thread() - Threaded handler for critical interrupts
> * @irq: irq number
> @@ -575,6 +608,20 @@ void tsens_disable_irq(struct tsens_priv *priv)
> regmap_field_write(priv->rf[INT_EN], 0);
> }
>
> +int get_tsens_zeroc_status(const struct tsens_sensor *s, int *temp)
> +{
> + struct tsens_priv *priv = s->priv;
> + int last_temp = 0, ret;
> +
> + ret =
Re: [RFC][PATCH 5/5] thermal: int340x: Use new device interface
On Mon, May 4, 2020 at 11:47 PM Srinivas Pandruvada
wrote:
>
> Use the new framework to send notifications for:
> - Setting temperature threshold for notification to avoid polling
> - Send THERMAL_TRIP_REACHED event on reaching threshold
> - Send THERMAL_TRIP_UPDATE when firmware change the the existing trip
> temperature
I am a little confused here. I would've expected the thermal core to
send the THERMAL_TRIP_* notifications, not platform drivers. Why
shouldn't this be done in thermal core?
>
> Signed-off-by: Srinivas Pandruvada
> ---
> .../intel/int340x_thermal/int3403_thermal.c | 3 ++
> .../int340x_thermal/int340x_thermal_zone.c| 29 +++
> .../int340x_thermal/int340x_thermal_zone.h| 7 +
> .../processor_thermal_device.c| 1 +
> 4 files changed, 40 insertions(+)
>
> diff --git a/drivers/thermal/intel/int340x_thermal/int3403_thermal.c
> b/drivers/thermal/intel/int340x_thermal/int3403_thermal.c
> index f86cbb125e2f..77c014a113a4 100644
> --- a/drivers/thermal/intel/int340x_thermal/int3403_thermal.c
> +++ b/drivers/thermal/intel/int340x_thermal/int3403_thermal.c
> @@ -63,15 +63,18 @@ static void int3403_notify(acpi_handle handle,
>
> switch (event) {
> case INT3403_PERF_CHANGED_EVENT:
> + int340x_thermal_send_user_event(obj->int340x_zone,
> THERMAL_PERF_CHANGED, 0);
> break;
> case INT3403_THERMAL_EVENT:
> int340x_thermal_zone_device_update(obj->int340x_zone,
>THERMAL_TRIP_VIOLATED);
> + int340x_thermal_send_user_event(obj->int340x_zone,
> THERMAL_TRIP_REACHED, 0);
> break;
> case INT3403_PERF_TRIP_POINT_CHANGED:
> int340x_thermal_read_trips(obj->int340x_zone);
> int340x_thermal_zone_device_update(obj->int340x_zone,
>THERMAL_TRIP_CHANGED);
> + int340x_thermal_send_user_event(obj->int340x_zone,
> THERMAL_TRIP_UPDATE, 0);
> break;
> default:
> dev_err(>pdev->dev, "Unsupported event [0x%x]\n",
> event);
> diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> index 432213272f1e..9568a2db7afd 100644
> --- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> +++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> @@ -146,12 +146,41 @@ static int int340x_thermal_get_trip_hyst(struct
> thermal_zone_device *zone,
> return 0;
> }
>
> +static int int340x_thermal_get_thres_low(struct thermal_zone_device *zone,
> int *temp)
> +{
> + struct int34x_thermal_zone *d = zone->devdata;
> +
> + *temp = d->aux_trips[0];
> +
> + return 0;
> +}
> +
> +static int int340x_thermal_set_thres_low(struct thermal_zone_device *zone,
> int temp)
> +{
> + struct int34x_thermal_zone *d = zone->devdata;
> + acpi_status status;
> +
> + if (d->override_ops && d->override_ops->set_trip_temp)
> + return d->override_ops->set_trip_temp(zone, 0, temp);
> +
> + status = acpi_execute_simple_method(d->adev->handle, "PAT0",
> + millicelsius_to_deci_kelvin(temp));
> + if (ACPI_FAILURE(status))
> + return -EIO;
> +
> + d->aux_trips[0] = temp;
> +
> + return 0;
> +}
> +
> static struct thermal_zone_device_ops int340x_thermal_zone_ops = {
> .get_temp = int340x_thermal_get_zone_temp,
> .get_trip_temp = int340x_thermal_get_trip_temp,
> .get_trip_type = int340x_thermal_get_trip_type,
> .set_trip_temp = int340x_thermal_set_trip_temp,
> .get_trip_hyst = int340x_thermal_get_trip_hyst,
> + .set_temp_thres_low = int340x_thermal_set_thres_low,
> + .get_temp_thres_low = int340x_thermal_get_thres_low,
> };
>
> static int int340x_thermal_get_trip_config(acpi_handle handle, char *name,
> diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
> b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
> index 3b4971df1b33..142027e4955f 100644
> --- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
> +++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
> @@ -58,4 +58,11 @@ static inline void int340x_thermal_zone_device_update(
> thermal_zone_device_update(tzone->zone, event);
> }
>
> +static inline void int340x_thermal_send_user_event(
> + struct int34x_thermal_zone *tzone,
> + enum thermal_device_events event,
> + u64 data)
> +{
> + thermal_dev_send_event(tzone->zone->id, event, data);
> +}
> #endif
> diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
>
Re: [RFC][PATCH 1/5] thermal: Add support for /dev/thermal_notify
On Mon, May 4, 2020 at 11:47 PM Srinivas Pandruvada
wrote:
>
> This change adds an optional feature to add a new device entry
> /dev/thermal_notify.
>
> When config CONFIG_THERMAL_USER_EVENT_INTERFACE is selected, this new
> device entry is created.
>
> Thermal core or any thermal driver can use thermal_dev_send_event() interface
Do you have any particular use case in mind where a platform driver
will use this interface to send platform-specific events?
IMO, we should probably try to keep this restricted to messages from
thermal core if we are to have any hope of having a standard library
in userspace capable of parsing these thermal events.
> to send events. Each user events follows a standard format:
> - zone_id
> - event_id
> - event_data
> - reserved for future, currently 0s
>
> User space can basically:
> fd = open ("/dev/thermal_notify")
> In a loop
> read (fd)
> read and process event
>
> or
> fd = open ("/dev/thermal_notify")
> Set the fs as non blocking
> In a loop
> Use poll() and wait
> read and process event
>
> There are predefined events added to thermal.h. Based on need they can
> be extended.
>
> Signed-off-by: Srinivas Pandruvada
> ---
> drivers/thermal/Kconfig | 9 ++
> drivers/thermal/Makefile | 3 +
> drivers/thermal/thermal_dev_if.c | 195 +++
> include/linux/thermal.h | 24
> 4 files changed, 231 insertions(+)
> create mode 100644 drivers/thermal/thermal_dev_if.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 91af271e9bb0..27d05d62458e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -78,6 +78,15 @@ config THERMAL_WRITABLE_TRIPS
> Say 'Y' here if you would like to allow userspace tools to
> change trip temperatures.
>
> +config THERMAL_USER_EVENT_INTERFACE
> + bool "Allow user space to read thermal events from a dev file"
> + help
> + This option allows a user space program to read thermal events
> + via /dev/thermal_notify file.
> +
> + Say 'Y' here if you would like to allow userspace programs to
> + read thermal events.
> +
> choice
> prompt "Default Thermal governor"
> default THERMAL_DEFAULT_GOV_STEP_WISE
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..8f65832d755a 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -11,6 +11,9 @@ thermal_sys-y += thermal_core.o
> thermal_sysfs.o \
> thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
> thermal_sys-$(CONFIG_THERMAL_OF) += of-thermal.o
>
> +# Thermal user space events
> +obj-$(CONFIG_THERMAL_USER_EVENT_INTERFACE) += thermal_dev_if.o
> +
> # governors
> thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
> thermal_sys-$(CONFIG_THERMAL_GOV_BANG_BANG)+= gov_bang_bang.o
> diff --git a/drivers/thermal/thermal_dev_if.c
> b/drivers/thermal/thermal_dev_if.c
> new file mode 100644
> index ..763bfe9eef9d
> --- /dev/null
> +++ b/drivers/thermal/thermal_dev_if.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal device file interface
> + * Copyright (c) 2020, Intel Corporation.
> + * All rights reserved.
> + *
> + * Author: Srinivas Pandruvada
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define THERMAL_DEV_FIFO_SIZE 1024
> +
> +struct thermal_chdev_sample {
> + int zone_id;
> + int event;
> + u64 event_data;
> + u64 reserved;
> +};
> +
> +struct thermal_chdev {
> + struct miscdevice therm_dev;
> + struct kfifo data_fifo;
> + unsigned long misc_opened;
> + wait_queue_head_t wait;
> +};
> +
> +static DEFINE_MUTEX(thermal_chdev_mutex);
> +static struct thermal_chdev *thermal_chdev;
> +
> +static int thermal_chdev_open(struct inode *inode, struct file *file)
> +{
> + struct thermal_chdev *chdev;
> +
> + chdev = container_of(file->private_data, struct thermal_chdev,
> therm_dev);
> +
> + /* We essentially have single reader and writer */
> + if (test_and_set_bit(0, >misc_opened))
> + return -EBUSY;
> +
> + return stream_open(inode, file);
> +}
> +
> +static int thermal_chdev_release(struct inode *inode, struct file *file)
> +{
> + struct thermal_chdev *chdev;
> +
> + chdev = container_of(file->private_data, struct thermal_chdev,
> therm_dev);
> +
> + clear_bit(0, >misc_opened);
> +
> + return 0;
> +}
> +
> +static __poll_t thermal_chdev_poll(struct file *file, struct
> poll_table_struct *wait)
> +{
> + struct thermal_chdev *chdev;
> + __poll_t mask = 0;
> +
> + chdev = container_of(file->private_data, struct thermal_chdev,
> therm_dev);
> +
> +
Re: [RFC][PATCH 4/5] thermal: Add support for setting polling interval
On Mon, May 4, 2020 at 11:47 PM Srinivas Pandruvada
wrote:
>
> Add new attribute in the thermal syfs for setting temperature sampling
> interval when CONFIG_THERMAL_USER_EVENT_INTERFACE is defined. The default
> value is 0, which means no polling.
>
> At this interval user space will get an event THERMAL_TEMP_SAMPLE with
> temperature sample. This reuses existing polling mecahnism when polling
> or passive delay is specified during zone registry. To avoid interference
> with passive and polling delay, this new polling attribute can't be used
> for those zones.
Why should the kernel periodically emit events for userspace when the
userspace is perfectly capable of deciding how frequently it wants to
poll a file for changes?
>
> Signed-off-by: Srinivas Pandruvada
> ---
> drivers/thermal/thermal_core.c | 7 +++
> drivers/thermal/thermal_sysfs.c | 36 +++--
> include/linux/thermal.h | 1 +
> 3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 14770d882d42..17cd799b0073 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -313,6 +313,8 @@ static void monitor_thermal_zone(struct
> thermal_zone_device *tz)
> thermal_zone_device_set_polling(tz, tz->passive_delay);
> else if (tz->polling_delay)
> thermal_zone_device_set_polling(tz, tz->polling_delay);
> + else if (tz->temp_polling_delay)
> + thermal_zone_device_set_polling(tz, tz->temp_polling_delay);
> else
> thermal_zone_device_set_polling(tz, 0);
>
> @@ -446,6 +448,11 @@ static void update_temperature(struct
> thermal_zone_device *tz)
> tz->temperature = temp;
> mutex_unlock(>lock);
>
> + if (tz->temp_polling_delay) {
> + thermal_dev_send_event(tz->id, THERMAL_TEMP_SAMPLE, temp);
> + monitor_thermal_zone(tz);
> + }
> +
> trace_thermal_temperature(tz);
> if (tz->last_temperature == THERMAL_TEMP_INVALID)
> dev_dbg(>device, "last_temperature N/A,
> current_temperature=%d\n",
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index aa85424c3ac4..0df7997993fe 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -248,6 +248,36 @@ create_thres_attr(temp_thres_low);
> create_thres_attr(temp_thres_high);
> create_thres_attr(temp_thres_hyst);
>
> +static ssize_t
> +temp_polling_delay_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct thermal_zone_device *tz = to_thermal_zone(dev);
> + int val;
> +
> + if (kstrtoint(buf, 10, ))
> + return -EINVAL;
> +
> + if (val && val < 1000)
> + return -EINVAL;
> +
> + tz->temp_polling_delay = val;
> + thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
> +
> + return count;
> +}
> +
> +static ssize_t
> +temp_polling_delay_show(struct device *dev, struct device_attribute *attr,
> +char *buf)
> +{
> + struct thermal_zone_device *tz = to_thermal_zone(dev);
> +
> + return sprintf(buf, "%d\n", tz->temp_polling_delay);
> +}
> +
> +static DEVICE_ATTR_RW(temp_polling_delay);
> +
> static int create_user_events_attrs(struct thermal_zone_device *tz)
> {
> struct attribute **attrs;
> @@ -260,8 +290,8 @@ static int create_user_events_attrs(struct
> thermal_zone_device *tz)
> if (tz->ops->get_temp_thres_high)
> ++index;
>
> - /* One additional space for NULL */
> - attrs = kcalloc(index + 1, sizeof(*attrs), GFP_KERNEL);
> + /* One additional space for NULL and temp_pollling_delay */
> + attrs = kcalloc(index + 2, sizeof(*attrs), GFP_KERNEL);
> if (!attrs)
> return -ENOMEM;
>
> @@ -312,6 +342,8 @@ static int create_user_events_attrs(struct
> thermal_zone_device *tz)
> attrs[index] = >threshold_attrs[index].attr.attr;
> ++index;
> }
> + if (!tz->polling_delay && !tz->passive_delay)
> + attrs[index++] = _attr_temp_polling_delay.attr;
> attrs[index] = NULL;
> tz->threshold_attribute_group.attrs = attrs;
>
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index ee9d79ace7ce..0ec4bd8c9c5c 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -216,6 +216,7 @@ struct thermal_zone_device {
> enum thermal_notify_event notify_event;
> struct attribute_group threshold_attribute_group;
> struct thermal_attr *threshold_attrs;
> + int temp_polling_delay;
> };
>
> /**
> --
> 2.25.4
>
Re: [RFC][PATCH 3/5] thermal: Add support for setting notification thresholds
On Tue, May 19, 2020 at 5:10 AM Srinivas Pandruvada wrote: > > On Mon, 2020-05-18 at 18:37 +0200, Daniel Lezcano wrote: > > On 04/05/2020 20:16, Srinivas Pandruvada wrote: > > > Add new attributes in thermal syfs when a thermal drivers provides > > > callbacks for them and CONFIG_THERMAL_USER_EVENT_INTERFACE is > > > defined. > > > > > > These attribute allow user space to stop polling for temperature. > > > > > > These attributes are: > > > - temp_thres_low: Specify a notification temperature for a low > > > temperature threshold event. > > > temp_thres_high: Specify a notification temperature for a high > > > temperature threshold event. > > > temp_thres_hyst: Specify a change in temperature to send > > > notification > > > again. > > > > > > This is implemented by adding additional sysfs attribute group. The > > > changes in this patch are trivial to add new attributes in thermal > > > sysfs as done for other attributes. > > > > Isn't it duplicate with the trip point? > A trip point is where an in-kernel governor takes some action. This is > not same as a notification temperature. For example at trip point > configured by ACPI at 85C, the thermal governor may start aggressive > throttling. > But a user space can set a notification threshold at 80C and start some > active controls like activate some fan to reduce the impact of passive > control on performance. Then what is the use of thermal trip type "ACTIVE" ? > We need a way to distinguish between temperature notification threshold > and actual trip point. Changing a trip point means that user wants > kernel to throttle at temperature.
Re: [PATCH 1/2] drivers: thermal: tsens: Add 0C (zeorC) interrupt support
On Sun, May 17, 2020 at 3:58 PM wrote:
>
> On 2020-05-05 17:39, Amit Kucheria wrote:
> > Hi Manaf,
> >
> > Typo: fix zeorC in subject line.
> Done
> >
> > Please rebase this patch[1] on top of my patch merging tsens-common.c
> > and tsens.c.
> >
> > [1]
> > https://lore.kernel.org/linux-arm-msm/e30e2ba6fa5c007983afd4d7d4e0311c0b57917a.1588183879.git.amit.kuche...@linaro.org/
> Done
> >
> > On Tue, May 5, 2020 at 4:42 PM Manaf Meethalavalappu Pallikunhi
> > wrote:
> >>
> >> TSENS IP v2.6+ adds 0C interrupt support. It triggers set
> >> interrupt when aggregated minimum temperature of all TSENS falls
> >> below 0C preset threshold and triggers reset interrupt when aggregate
> >> minimum temperature of all TSENS crosses above reset threshold.
> >> Add support for this interrupt in the driver.
> >>
> >> It adds another sensor to the of-thermal along with all individual
> >> TSENS. It enables to add any mitigation for 0C interrupt.
> >>
> >> Signed-off-by: Manaf Meethalavalappu Pallikunhi
> >>
> >> ---
> >> drivers/thermal/qcom/tsens-common.c | 72
> >> -
> >> drivers/thermal/qcom/tsens-v2.c | 7 +++
> >> drivers/thermal/qcom/tsens.c| 51 ++--
> >> drivers/thermal/qcom/tsens.h| 11 +
> >> 4 files changed, 135 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/thermal/qcom/tsens-common.c
> >> b/drivers/thermal/qcom/tsens-common.c
> >> index 172545366636..44e7edeb9a90 100644
> >> --- a/drivers/thermal/qcom/tsens-common.c
> >> +++ b/drivers/thermal/qcom/tsens-common.c
> >> @@ -198,7 +198,8 @@ static void tsens_set_interrupt_v1(struct
> >> tsens_priv *priv, u32 hw_id,
> >> index = LOW_INT_CLEAR_0 + hw_id;
> >> break;
> >> case CRITICAL:
> >> - /* No critical interrupts before v2 */
> >> + case ZEROC:
> >> + /* No critical and 0c interrupts before v2 */
> >> return;
> >> }
> >> regmap_field_write(priv->rf[index], enable ? 0 : 1);
> >> @@ -229,6 +230,9 @@ static void tsens_set_interrupt_v2(struct
> >> tsens_priv *priv, u32 hw_id,
> >> index_mask = CRIT_INT_MASK_0 + hw_id;
> >> index_clear = CRIT_INT_CLEAR_0 + hw_id;
> >> break;
> >> + case ZEROC:
> >> + /* Nothing to handle for 0c interrupt */
> >> + return;
> >> }
> >>
> >> if (enable) {
> >> @@ -360,6 +364,34 @@ static inline u32 masked_irq(u32 hw_id, u32 mask,
> >> enum tsens_ver ver)
> >> return 0;
> >> }
> >>
> >> +/**
> >> + * tsens_0c_irq_thread - Threaded interrupt handler for 0c interrupt
> >
> > Let's use zeroc instead of 0c in the function and variable names and
> > comments everywhere. Easier to grep and better consistency too.
> Done
> >
> >> + * @irq: irq number
> >> + * @data: tsens controller private data
> >> + *
> >> + * Whenever interrupt triggers notify thermal framework using
> >> + * thermal_zone_device_update() to update cold temperature
> >> mitigation.
> >
> > How is this mitigation updated?
> Updated comment section
> >> + *
> >> + * Return: IRQ_HANDLED
> >> + */
> >> +irqreturn_t tsens_0c_irq_thread(int irq, void *data)
> >> +{
> >> + struct tsens_priv *priv = data;
> >> + struct tsens_sensor *s = >sensor[priv->num_sensors];
> >> + int temp, ret;
> >> +
> >> + ret = regmap_field_read(priv->rf[TSENS_0C_STATUS], );
> >> + if (ret)
> >> + return ret;
> >> +
> >> + dev_dbg(priv->dev, "[%u] %s: 0c interrupt is %s\n",
> >> + s->hw_id, __func__, temp ? "triggered" : "cleared");
> >
> > So triggered is printed for non-zero (including negative) values?
> This zeroc hardware generates each interrupt when any of the TSENS that
> it monitors goes below 5C or above 10c. These thresholds are not
> configurable. Hence we don't expect this to be changed from kernel side.
> So this sensor (status register) will read 0 or 1. 1 means soc
> temperature is in cold condition and 0 means it is in normal
> temperature.
All thi
Re: [PATCH v2 1/6] dt-bindings: mfd: add Khadas Microcontroller bindings
On Tue, May 12, 2020 at 6:56 PM Neil Armstrong wrote:
>
> This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
> boards.
>
> It has multiple boot control features like password check, power-on
> options, power-off control and system FAN control on recent boards.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Rob Herring
Reviewed-by: Amit Kucheria
> ---
> .../devicetree/bindings/mfd/khadas,mcu.yaml | 44 +++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> new file mode 100644
> index ..a3b976f101e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/khadas,mcu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Khadas on-board Microcontroller Device Tree Bindings
> +
> +maintainers:
> + - Neil Armstrong
> +
> +description: |
> + Khadas embeds a microcontroller on their VIM and Edge boards adding some
> + system feature as PWM Fan control (for VIM2 rev14 or VIM3), User memory
> + storage, IR/Key resume control, system power LED control and more.
> +
> +properties:
> + compatible:
> +enum:
> + - khadas,mcu # MCU revision is discoverable
> +
> + "#cooling-cells": # Only needed for boards having FAN control feature
> +const: 2
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + khadas_mcu: system-controller@18 {
> +compatible = "khadas,mcu";
> +reg = <0x18>;
> +#cooling-cells = <2>;
> + };
> +};
> --
> 2.22.0
>
Re: [PATCH v2 3/6] thermal: add support for the MCU controlled FAN on Khadas boards
On Tue, May 12, 2020 at 6:56 PM Neil Armstrong wrote:
>
> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
> on-board microcontroller.
>
> This implements the FAN control as thermal devices and as cell of the Khadas
> MCU MFD driver.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/thermal/Kconfig | 10 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/khadas_mcu_fan.c | 174 +++
> 3 files changed, 185 insertions(+)
> create mode 100644 drivers/thermal/khadas_mcu_fan.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 91af271e9bb0..72b3960cc5ac 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -490,4 +490,14 @@ config SPRD_THERMAL
> help
> Support for the Spreadtrum thermal sensor driver in the Linux
> thermal
> framework.
> +
> +config KHADAS_MCU_FAN_THERMAL
> + tristate "Khadas MCU controller FAN cooling support"
> + depends on OF || COMPILE_TEST
Could you add a depends on the some board/SoC Kconfig option here so
this doesn't show up for non-Amlogic/non-Khadas boards?
Looks OK otherwise.
> + select MFD_CORE
> + select REGMAP
> + help
> + If you say yes here you get support for the FAN controlled
> + by the Microcontroller found on the Khadas VIM boards.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..460428c2122c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
> +obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
> diff --git a/drivers/thermal/khadas_mcu_fan.c
> b/drivers/thermal/khadas_mcu_fan.c
> new file mode 100644
> index ..044d4aba8be2
> --- /dev/null
> +++ b/drivers/thermal/khadas_mcu_fan.c
> @@ -0,0 +1,174 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Khadas MCU Controlled FAN driver
> + *
> + * Copyright (C) 2020 BayLibre SAS
> + * Author(s): Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_LEVEL 3
> +
> +struct khadas_mcu_fan_ctx {
> + struct khadas_mcu *mcu;
> + unsigned int level;
> + struct thermal_cooling_device *cdev;
> +};
> +
> +static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> + unsigned int level)
> +{
> + int ret;
> +
> + ret = regmap_write(ctx->mcu->map, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + level);
> + if (ret)
> + return ret;
> +
> + ctx->level = level;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = MAX_LEVEL;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = ctx->level;
> +
> + return 0;
> +}
> +
> +static int
> +khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
> +unsigned long state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx || (state > MAX_LEVEL))
> + return -EINVAL;
> +
> + if (state == ctx->level)
> + return 0;
> +
> + return khadas_mcu_fan_set_level(ctx, state);
> +}
> +
> +static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
> + .get_max_state = khadas_mcu_fan_get_max_state,
> + .get_cur_state = khadas_mcu_fan_get_cur_state,
> + .set_cur_state = khadas_mcu_fan_set_cur_state,
> +};
> +
> +static int khadas_mcu_fan_probe(struct platform_device *pdev)
> +{
> + struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
> + struct thermal_cooling_device *cdev;
> + struct device *dev = >dev;
> + struct khadas_mcu_fan_ctx *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> + ctx->mcu = mcu;
> + platform_set_drvdata(pdev, ctx);
> +
> + cdev = devm_thermal_of_cooling_device_register(dev->parent,
> + dev->parent->of_node, "khadas-mcu-fan", ctx,
> + _mcu_fan_cooling_ops);
> + if (IS_ERR(cdev)) {
> + ret =
Re: [PATCH] net: stmmac: fix num_por initialization
On Thu, May 14, 2020 at 11:59 AM Vinod Koul wrote:
>
> Driver missed initializing num_por which is por values that driver
Nit: s/is/is one of the/ ?
> configures to hardware. In order to get this values, add a new structure
Nit: s/this/these
> ethqos_emac_driver_data which holds por and num_por values and populate
> that in driver probe.
>
> Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
> Reported-by: Rahul Ankushrao Kawadgave
> Signed-off-by: Vinod Koul
Otherwise,
Reviewed-by: Amit Kucheria
> ---
> .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index e0a5fe83d8e0..bfc4a92f1d92 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -75,6 +75,11 @@ struct ethqos_emac_por {
> unsigned int value;
> };
>
> +struct ethqos_emac_driver_data {
> + const struct ethqos_emac_por *por;
> + unsigned int num_por;
> +};
> +
> struct qcom_ethqos {
> struct platform_device *pdev;
> void __iomem *rgmii_base;
> @@ -171,6 +176,11 @@ static const struct ethqos_emac_por emac_v2_3_0_por[] = {
> { .offset = RGMII_IO_MACRO_CONFIG2, .value = 0x2060 },
> };
>
> +static const struct ethqos_emac_driver_data emac_v2_3_0_data = {
> + .por = emac_v2_3_0_por,
> + .num_por = ARRAY_SIZE(emac_v2_3_0_por),
> +};
> +
> static int ethqos_dll_configure(struct qcom_ethqos *ethqos)
> {
> unsigned int val;
> @@ -442,6 +452,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> struct device_node *np = pdev->dev.of_node;
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> + const struct ethqos_emac_driver_data *data;
> struct qcom_ethqos *ethqos;
> struct resource *res;
> int ret;
> @@ -471,7 +482,9 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> goto err_mem;
> }
>
> - ethqos->por = of_device_get_match_data(>dev);
> + data = of_device_get_match_data(>dev);
> + ethqos->por = data->por;
> + ethqos->num_por = data->num_por;
>
> ethqos->rgmii_clk = devm_clk_get(>dev, "rgmii");
> if (IS_ERR(ethqos->rgmii_clk)) {
> @@ -526,7 +539,7 @@ static int qcom_ethqos_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id qcom_ethqos_match[] = {
> - { .compatible = "qcom,qcs404-ethqos", .data = _v2_3_0_por},
> + { .compatible = "qcom,qcs404-ethqos", .data = _v2_3_0_data},
> { }
> };
> MODULE_DEVICE_TABLE(of, qcom_ethqos_match);
> --
> 2.25.4
>
[PATCH] firmware: qcom_scm: Prefer initialisation during the descriptor declaration
qcom_scm_iommu_secure_ptbl_init() initialises the args twice, once while
declaring the struct, and then again by assignment. Remove the duplicate
assignment.
Similarly, move arginfo initialisation to the declaration in
__qcom_scm_is_call_available for consistency with other .arginfo
initialisation in the file.
Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy
conventions")
Signed-off-by: Amit Kucheria
---
drivers/firmware/qcom_scm.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 6ba132be1b6e..eae9c28679cc 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -228,10 +228,10 @@ static int __qcom_scm_is_call_available(struct device
*dev, u32 svc_id,
.svc = QCOM_SCM_SVC_INFO,
.cmd = QCOM_SCM_INFO_IS_CALL_AVAIL,
.owner = ARM_SMCCC_OWNER_SIP,
+ .arginfo = QCOM_SCM_ARGS(1),
};
struct qcom_scm_res res;
- desc.arginfo = QCOM_SCM_ARGS(1);
switch (__get_convention()) {
case SMC_CONVENTION_ARM_32:
case SMC_CONVENTION_ARM_64:
@@ -742,12 +742,6 @@ int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size,
u32 spare)
};
int ret;
- desc.args[0] = addr;
- desc.args[1] = size;
- desc.args[2] = spare;
- desc.arginfo = QCOM_SCM_ARGS(3, QCOM_SCM_RW, QCOM_SCM_VAL,
-QCOM_SCM_VAL);
-
ret = qcom_scm_call(__scm->dev, , NULL);
/* the pg table has been initialized already, ignore the error */
--
2.20.1
[PATCH 12/14] thermal/drivers/user_space: Sort headers alphabetically
Sort headers to make it easier to read and find duplicate headers. Signed-off-by: Amit Kucheria --- drivers/thermal/user_space.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/user_space.c b/drivers/thermal/user_space.c index 293cffd9c8ad..82a7198bbe71 100644 --- a/drivers/thermal/user_space.c +++ b/drivers/thermal/user_space.c @@ -10,8 +10,8 @@ * ~~ */ -#include #include +#include #include "thermal_core.h" -- 2.20.1
[PATCH 13/14] thermal/governors: Prefix all source files with gov_
Bang-bang governor source file is prefixed with gov_. Do the same for
other governors for consistency so they're easy to find in the sources.
Signed-off-by: Amit Kucheria
---
drivers/thermal/Makefile | 8
drivers/thermal/{fair_share.c => gov_fair_share.c}| 0
.../thermal/{power_allocator.c => gov_power_allocator.c} | 0
drivers/thermal/{step_wise.c => gov_step_wise.c} | 0
drivers/thermal/{user_space.c => gov_user_space.c}| 0
5 files changed, 4 insertions(+), 4 deletions(-)
rename drivers/thermal/{fair_share.c => gov_fair_share.c} (100%)
rename drivers/thermal/{power_allocator.c => gov_power_allocator.c} (100%)
rename drivers/thermal/{step_wise.c => gov_step_wise.c} (100%)
rename drivers/thermal/{user_space.c => gov_user_space.c} (100%)
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 8c8ed7b79915..09ff0e259d46 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -12,11 +12,11 @@ thermal_sys-$(CONFIG_THERMAL_HWMON) +=
thermal_hwmon.o
thermal_sys-$(CONFIG_THERMAL_OF) += of-thermal.o
# governors
-thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
+thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += gov_fair_share.o
thermal_sys-$(CONFIG_THERMAL_GOV_BANG_BANG)+= gov_bang_bang.o
-thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
-thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE) += user_space.o
-thermal_sys-$(CONFIG_THERMAL_GOV_POWER_ALLOCATOR) += power_allocator.o
+thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= gov_step_wise.o
+thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE) += gov_user_space.o
+thermal_sys-$(CONFIG_THERMAL_GOV_POWER_ALLOCATOR) += gov_power_allocator.o
# cpufreq cooling
thermal_sys-$(CONFIG_CPU_FREQ_THERMAL) += cpufreq_cooling.o
diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/gov_fair_share.c
similarity index 100%
rename from drivers/thermal/fair_share.c
rename to drivers/thermal/gov_fair_share.c
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/gov_power_allocator.c
similarity index 100%
rename from drivers/thermal/power_allocator.c
rename to drivers/thermal/gov_power_allocator.c
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/gov_step_wise.c
similarity index 100%
rename from drivers/thermal/step_wise.c
rename to drivers/thermal/gov_step_wise.c
diff --git a/drivers/thermal/user_space.c b/drivers/thermal/gov_user_space.c
similarity index 100%
rename from drivers/thermal/user_space.c
rename to drivers/thermal/gov_user_space.c
--
2.20.1
[PATCH 10/14] thermal/drivers/cpufreq_cooling: Replace module.h with export.h
cpufreq_cooling cannot be modular, remove the unnecessary module.h include and replace with export.h to handle EXPORT_SYMBOL family of macros. Signed-off-by: Amit Kucheria --- drivers/thermal/cpufreq_cooling.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c index 1b5a63b4763d..9e124020519f 100644 --- a/drivers/thermal/cpufreq_cooling.c +++ b/drivers/thermal/cpufreq_cooling.c @@ -10,12 +10,12 @@ * Viresh Kumar * */ -#include #include #include #include #include #include +#include #include #include #include -- 2.20.1
[PATCH 04/14] thermal/drivers/thermal_helpers: Include export.h
It is preferable to include export.h when you are using EXPORT_SYMBOL family of macros. Signed-off-by: Amit Kucheria --- drivers/thermal/thermal_helpers.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/thermal_helpers.c b/drivers/thermal/thermal_helpers.c index 8ea0a05404f7..e47da80daf3a 100644 --- a/drivers/thermal/thermal_helpers.c +++ b/drivers/thermal/thermal_helpers.c @@ -14,6 +14,7 @@ #include #include +#include #include #include #include -- 2.20.1
[PATCH 09/14] thermal/drivers/cpufreq_cooling: Sort headers alphabetically
Sort headers to make it easier to read and find duplicate headers. Signed-off-by: Amit Kucheria --- drivers/thermal/cpufreq_cooling.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c index e297e135c031..1b5a63b4763d 100644 --- a/drivers/thermal/cpufreq_cooling.c +++ b/drivers/thermal/cpufreq_cooling.c @@ -11,16 +11,16 @@ * */ #include -#include +#include #include +#include +#include #include #include #include #include #include -#include -#include -#include +#include #include -- 2.20.1
[PATCH 14/14] thermal/of: Rename of-thermal.c
Core thermal framework code files should start with thermal_*.
of-thermal.c does not follow this pattern and can easily be confused
with platform driver.
Fix this by renaming it to thermal_of.c
Signed-off-by: Amit Kucheria
---
drivers/thermal/Makefile | 2 +-
drivers/thermal/{of-thermal.c => thermal_of.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/thermal/{of-thermal.c => thermal_of.c} (100%)
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 09ff0e259d46..d7969dd553cb 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -9,7 +9,7 @@ thermal_sys-y += thermal_core.o
thermal_sysfs.o \
# interface to/from other layers providing sensors
thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
-thermal_sys-$(CONFIG_THERMAL_OF) += of-thermal.o
+thermal_sys-$(CONFIG_THERMAL_OF) += thermal_of.o
# governors
thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += gov_fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/thermal_of.c
similarity index 100%
rename from drivers/thermal/of-thermal.c
rename to drivers/thermal/thermal_of.c
--
2.20.1
[PATCH 11/14] thermal/drivers/of-thermal: Sort headers alphabetically
Sort headers to make it easier to read and find duplicate headers. Signed-off-by: Amit Kucheria --- drivers/thermal/of-thermal.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index 874a47d6923f..ddf88dbe7ba2 100644 --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -8,13 +8,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include -#include -#include -#include -#include #include #include +#include +#include +#include +#include +#include #include #include "thermal_core.h" -- 2.20.1
[PATCH 03/14] thermal/drivers/thermal_helpers: Sort headers alphabetically
Sort headers to make it easier to read and find duplicate headers. Signed-off-by: Amit Kucheria --- drivers/thermal/thermal_helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_helpers.c b/drivers/thermal/thermal_helpers.c index 2ba756af76b7..8ea0a05404f7 100644 --- a/drivers/thermal/thermal_helpers.c +++ b/drivers/thermal/thermal_helpers.c @@ -12,11 +12,11 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include #include #include #include #include +#include #include -- 2.20.1
[PATCH 06/14] thermal/drivers/thermal_hwmon: Include export.h
It is preferable to include export.h when you are using EXPORT_SYMBOL family of macros. Signed-off-by: Amit Kucheria --- drivers/thermal/thermal_hwmon.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c index e43ae551592d..8b92e00ff236 100644 --- a/drivers/thermal/thermal_hwmon.c +++ b/drivers/thermal/thermal_hwmon.c @@ -11,6 +11,7 @@ * Copyright (C) 2013 Eduardo Valentin */ #include +#include #include #include #include -- 2.20.1
[PATCH 01/14] thermal/core: Get rid of MODULE_* tags
The thermal framework can no longer be compiled as a module as of
commit 554b3529fe01 ("thermal/drivers/core: Remove the module Kconfig's
option"). Remove the MODULE_* tags.
Rui is mentioned in the copyright line at the top of the file and the
license is mentioned in the SPDX tags. So no loss of information.
Signed-off-by: Amit Kucheria
---
drivers/thermal/thermal_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9a321dc548c8..286920e06277 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -27,10 +27,6 @@
#include "thermal_core.h"
#include "thermal_hwmon.h"
-MODULE_AUTHOR("Zhang Rui");
-MODULE_DESCRIPTION("Generic thermal management sysfs support");
-MODULE_LICENSE("GPL v2");
-
static DEFINE_IDA(thermal_tz_ida);
static DEFINE_IDA(thermal_cdev_ida);
--
2.20.1
[PATCH 08/14] thermal/drivers/clock_cooling: Include export.h
It is preferrable to include export.h when you are using EXPORT_SYMBOL family of macros. Signed-off-by: Amit Kucheria --- drivers/thermal/clock_cooling.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/clock_cooling.c b/drivers/thermal/clock_cooling.c index fd6bc6eefc88..56cb1f46a428 100644 --- a/drivers/thermal/clock_cooling.c +++ b/drivers/thermal/clock_cooling.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include -- 2.20.1
[PATCH 00/14] thermal core include cleanups
I noticed some remnants from when thermal core could be modular. While
cleaning that up, I fixed up the includes to be sorted alphabetically and
included export.h in files that were using EXPORT_SYMBOL* or THIS_MODULE
while at the same time removing inclusion of module.h from core files.
Finally, the names of the source files for the governors and core have some
inconsistencies and the last couple of patches rename them.
Build and boot tested on some ARM boards.
Amit Kucheria (14):
thermal/core: Get rid of MODULE_* tags
thermal/core: Replace module.h with export.h
thermal/drivers/thermal_helpers: Sort headers alphabetically
thermal/drivers/thermal_helpers: Include export.h
thermal/drivers/thermal_hwmon: Sort headers alphabetically
thermal/drivers/thermal_hwmon: Include export.h
thermal/drivers/clock_cooling: Sort headers alphabetically
thermal/drivers/clock_cooling: Include export.h
thermal/drivers/cpufreq_cooling: Sort headers alphabetically
thermal/drivers/cpufreq_cooling: Replace module.h with export.h
thermal/drivers/of-thermal: Sort headers alphabetically
thermal/drivers/user_space: Sort headers alphabetically
thermal/governors: Prefix all source files with gov_
thermal/of: Rename of-thermal.c
drivers/thermal/Makefile | 10 +-
drivers/thermal/clock_cooling.c| 3 ++-
drivers/thermal/cpufreq_cooling.c | 10 +-
drivers/thermal/{fair_share.c => gov_fair_share.c} | 0
.../{power_allocator.c => gov_power_allocator.c} | 0
drivers/thermal/{step_wise.c => gov_step_wise.c} | 0
drivers/thermal/{user_space.c => gov_user_space.c} | 2 +-
drivers/thermal/thermal_core.c | 6 +-
drivers/thermal/thermal_helpers.c | 3 ++-
drivers/thermal/thermal_hwmon.c| 6 --
drivers/thermal/{of-thermal.c => thermal_of.c} | 10 +-
11 files changed, 25 insertions(+), 25 deletions(-)
rename drivers/thermal/{fair_share.c => gov_fair_share.c} (100%)
rename drivers/thermal/{power_allocator.c => gov_power_allocator.c} (100%)
rename drivers/thermal/{step_wise.c => gov_step_wise.c} (100%)
rename drivers/thermal/{user_space.c => gov_user_space.c} (100%)
rename drivers/thermal/{of-thermal.c => thermal_of.c} (100%)
--
2.20.1
[PATCH 02/14] thermal/core: Replace module.h with export.h
Thermal core cannot be modular, remove the unnecessary module.h include and replace with export.h to handle EXPORT_SYMBOL family of macros. Signed-off-by: Amit Kucheria --- drivers/thermal/thermal_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 286920e06277..bed4a7bea7bb 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -9,9 +9,9 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include #include #include +#include #include #include #include -- 2.20.1
[PATCH 05/14] thermal/drivers/thermal_hwmon: Sort headers alphabetically
Sort headers to make it easier to read and find duplicate headers. Signed-off-by: Amit Kucheria --- drivers/thermal/thermal_hwmon.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c index c8d2620f2e42..e43ae551592d 100644 --- a/drivers/thermal/thermal_hwmon.c +++ b/drivers/thermal/thermal_hwmon.c @@ -10,10 +10,11 @@ * Copyright (C) 2013 Texas Instruments * Copyright (C) 2013 Eduardo Valentin */ +#include #include -#include #include -#include +#include + #include "thermal_hwmon.h" /* hwmon sys I/F */ -- 2.20.1
