Hi, this patchset implements basic polled thermal sensing support and
hardware initiated shutdown ("thermtrip") in an overheating situations
for the Tegra124 system-on-chip.
The driver uses the of-thermal framework to expose the sensors to the
thermal subsystem, and this works well for the simplest case of polled
sensors. However, there are two features I'd like to implement that
as far as I know the framework isn't really ready for:
- hardware based trip points, i.e., interrupts at a configured temperature
- hardware initiated cooling
Thermtrip is an example of the latter, but the hardware is also capable
of less drastic measures. Currently, the driver doesn't attempt to expose
thermtrip using the framework, instead opting to use custom device tree
properties, but this is something I'd like to move away from.
To implement hardware based trip points, the sensor - of-thermal interface
would need a new function, which the of-thermal framework would use to
tell the driver of a new trip point. I suppose the best way to do this
would be to have of-thermal manage trip points, and when one is reached,
tell the driver to prepare for the next one. The sensor driver should
be capable of managing two trip points, and below and one above the
current temperature.
Hardware initiated cooling is a bit more interesting. The hardware that
initiates the cooling procedure necessarily has some view of the thermal
sensors / thermal zones, so the thermal zones defined in the device tree
should map exactly to those ones. Hardware based cooling devices should
be defined in the device tree just like any other cooling devices.
The problematic part is binding a trip point to a hardware cooling device.
There would need some additional interface to tell the cooling device
the temperature of the trip point it is bound to.
Hardware cooling devices can also track multiple thermal zones (for example,
thermtrip can trigger based on cpu, gpu, memory and tsense sensors). To
distinguish between these in the device tree, I can think of two options:
1. Implement each tracked zone as a separate cooling device. (Probably by
having an additional cooling-cell) This would make the interface simpler
but allow impossible cooling mappings to be made in the device tree.
2. When telling the cooling device of a particular trip point, also tell it
which thermal zone it is related to. This would require the cooling device
to have some kind of ability to detect that a thermal zone object is a
specific thermal zone.
One more question related to hardware-initiated reset in an overheating
situation: the "critical" trip level is designed to initiate a controller
shutdown. Should there be a new trip level for an uncontrolled shutdown?
Any thoughts would be appreciated.
Thanks,
Mikko Perttunen
Mikko Perttunen (5):
ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree
ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
ARM: tegra: Add thermal reset (thermtrip) support to PMC
clk: tegra: Add soctherm and tsensor clocks to T124 initialization
table
thermal: Add Tegra SOCTHERM thermal management driver
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 5 +
arch/arm/boot/dts/tegra124.dtsi | 47 +++
arch/arm/mach-tegra/pmc.c | 95 +++++-
drivers/clk/tegra/clk-tegra124.c | 2 +
drivers/thermal/Kconfig | 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/tegra_soctherm.c | 502 ++++++++++++++++++++++++++++++
7 files changed, 654 insertions(+), 4 deletions(-)
create mode 100644 drivers/thermal/tegra_soctherm.c
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
