linux-stable.git/drivers/thermal, branch v5.16.4

thermal/drivers/imx8mm: Enable ADC when enabling monitor

2022-01-27T11:01:38+00:00

[ Upstream commit 3de89d8842a2b5d3dd22ebf97dd561ae0a330948 ]

The i.MX 8MP has a ADC_PD bit in the TMU_TER register that controls the
operating mode of the ADC:
* 0 means normal operating mode
* 1 means power down mode

When enabling/disabling the TMU, the ADC operating mode must be set
accordingly.

i.MX 8M Mini & Nano are lacking this bit.

Signed-off-by: Paul Gerber 
Signed-off-by: Alexander Stein 
Fixes: 2b8f1f0337c5 ("thermal: imx8mm: Add i.MX8MP support")
Link: https://lore.kernel.org/r/20211122114225.196280-1-alexander.stein@ew.tq-group.com
Signed-off-by: Daniel Lezcano 
Signed-off-by: Sasha Levin

thermal/drivers/imx: Implement runtime PM support

2022-01-27T11:01:37+00:00

[ Upstream commit 4cf2ddf16e175ee18c5c29865c32da7d6269cf44 ]

Starting with commit d92ed2c9d3ff ("thermal: imx: Use driver's local
data to decide whether to run a measurement") this driver stared using
irq_enabled flag to make decision to power on/off the thermal
core. This triggered a regression, where after reaching critical
temperature, alarm IRQ handler set irq_enabled to false, disabled
thermal core and was not able read temperature and disable cooling
sequence.

In case the cooling device is "CPU/GPU freq", the system will run with
reduce performance until next reboot.

To solve this issue, we need to move all parts implementing hand made
runtime power management and let it handle actual runtime PM framework.

Fixes: d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement")
Signed-off-by: Oleksij Rempel 
Tested-by: Petr Beneš 
Link: https://lore.kernel.org/r/20211117103426.81813-1-o.rempel@pengutronix.de
Signed-off-by: Daniel Lezcano 
Signed-off-by: Sasha Levin

thermal/drivers/int340x: Fix RFIM mailbox write commands

2022-01-27T11:01:23+00:00

commit 2685c77b80a80c57e2a25a726b82fb31e6e212ab upstream.

The existing mail mechanism only supports writing of workload types.

However, mailbox command for RFIM (cmd = 0x08) also requires write
operation which is ignored. This results in failing to store RFI
restriction.

Fixint this requires enhancing mailbox writes for non workload
commands too, so remove the check for MBOX_CMD_WORKLOAD_TYPE_WRITE
in mailbox write to allow this other write commands to be supoorted.

At the same time, however, we have to make sure that there is no
impact on read commands, by avoiding to write anything into the
mailbox data register.

To properly implement that, add two separate functions for mbox read
and write commands for the processor thermal workload command type.
This helps to distinguish the read and write workload command types
from each other while sending mbox commands.

Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes")
Signed-off-by: Sumeet Pawnikar 
Cc: 5.14+  # 5.14+
Acked-by: Srinivas Pandruvada 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

thermal: int340x: Fix VCoRefLow MMIO bit offset for TGL

2021-12-08T14:29:22+00:00

The VCoRefLow CPU FIVR register definition for Tiger Lake is incorrect.

Current implementation reads it from MMIO offset 0x5A18 and bit
offset [12:14], but the actual correct register definition is from
bit offset [11:13].

Update to fix the bit offset.

Fixes: 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM driver")
Signed-off-by: Sumeet Pawnikar 
Cc: 5.14+  # 5.14+
[ rjw: New subject, changelog edits ]
Signed-off-by: Rafael J. Wysocki

Merge branch 'thermal-int340x'

2021-11-18T19:40:28+00:00

Merge int340x thermal driver Kconfig fix for 5.16-rc2.

* thermal-int340x:
  thermal: int340x: Limit Kconfig to 64-bit

thermal: core: Reset previous low and high trip during thermal zone init

2021-11-16T19:29:27+00:00

During the suspend is in process, thermal_zone_device_update bails out
thermal zone re-evaluation for any sensor trip violation without
setting next valid trip to that sensor. It assumes during resume
it will re-evaluate same thermal zone and update trip. But when it is
in suspend temperature goes down and on resume path while updating
thermal zone if temperature is less than previously violated trip,
thermal zone set trip function evaluates the same previous high and
previous low trip as new high and low trip. Since there is no change
in high/low trip, it bails out from thermal zone set trip API without
setting any trip. It leads to a case where sensor high trip or low
trip is disabled forever even though thermal zone has a valid high
or low trip.

During thermal zone device init, reset thermal zone previous high
and low trip. It resolves above mentioned scenario.

Signed-off-by: Manaf Meethalavalappu Pallikunhi 
Reviewed-by: Thara Gopinath 
Signed-off-by: Rafael J. Wysocki

thermal: int340x: Limit Kconfig to 64-bit

2021-11-16T19:16:35+00:00

32-bit processors cannot generally access 64-bit MMIO registers
atomically, and it is unknown in which order the two halves of
this registers would need to be read:

drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c: In function 'send_mbox_cmd':
drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c:79:37: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration]
   79 |                         *cmd_resp = readq((void __iomem *) (proc_priv->mmio_base + MBOX_OFFSET_DATA));
      |                                     ^~~~~
      |                                     readl

The driver already does not build for anything other than x86,
so limit it further to x86-64.

Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Srinivas Pandruvada 
Reviewed-by: Randy Dunlap 
Signed-off-by: Rafael J. Wysocki

thermal: int340x: fix build on 32-bit targets

2021-11-12T18:56:25+00:00

Commit aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot
64 bit RFIM responses") started using 'readq()' to read 64-bit status
responses from the int340x hardware.

That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is
ambiguous, since it's no longer an atomic access.  Some hardware might
require 64-bit accesses, and other hardware might want low word first or
high word first.

It's quite likely that the driver isn't relevant in a 32-bit environment
any more, and there's a patch floating around to just make it depend on
X86_64, but let's make it buildable on x86-32 anyway.

The driver previously just read the low 32 bits, so the hardware
certainly is ok with 32-bit reads, and in a little-endian environment
the low word first model is the natural one.

So just add the include for the 'io-64-nonatomic-lo-hi.h' version.

Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses")
Reported-by: Jakub Kicinski 
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Linus Torvalds

Merge branch 'thermal-int340x'

2021-11-10T13:08:48+00:00

Merge int340x thermal driver fix for 5.16-rc1.

* thermal-int340x:
  thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses

thermal: Replace pr_warn() with pr_warn_once() in user_space_bind()

2021-11-05T16:47:14+00:00

Use pr_warn_once() instead of pr_warn() to print the user space
governor deprecation message in user_space_bind() to reduce the
kernel log noise.

Fixes: 0275c9fb0eff ("thermal/core: Make the userspace governor deprecated")
Reported-by: Linus Torvalds 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Daniel Lezcano