On Thu, May 07, 2015 at 12:25:38PM +0100, Will Deacon wrote:

On Thu, May 07, 2015 at 10:29:03AM +0100, Bintian wrote:

quoted

On 2015/5/7 17:02, Will Deacon wrote:

quoted

On Tue, May 05, 2015 at 01:06:34PM +0100, Bintian Wang wrote:

[...]

quoted

quoted

The bad news is that running hackbench quickly got the *heatsink*
temperature to 73 degress C and rising (measured with an infrared
thermometer).

This patch set is just for booting the small system, if you want to
test the temperature, I think you should using the HiKey released
version (https://www.96boards.org/).

I'm not really interested in the temperature numbers, but I am interested
in the board not melting and potentially setting fire to my desk.

All cpus will be initialized w/t 800MHz, suppose the dynamic leakage is high;
w/t Bintian's patches, suppose the cpuidle also has not been enabled;
so there also have static leakage even cpus run into "wfi" state.

I also have not exactly power data for SoC, but suppose the leakage is
high.

quoted

This patch is just for the small system, and not include those drivers
for adjusting the CPU frequency, thermal control and so on. After this
patch is merged, all those drivers will be submitted later.

Should those drivers *really* exist only in the kernel? What happens if
the kernel panics for some other reason? You'll basically have 8 spinning
cores and no sensible way to handle the thermal interrupt.

Shouldn't there be something in the secure firmware as a last resort?

We are integrate Hisilicon's MCU firmware, which is the similiar
module w/t Juno's SCP. It will support mainly two functionality:

- CPU Frequency Scaling;

  CPUFreq driver has been merged yet. [2]

  For CPU frequency scaling part, Due MCU FW has some updating from
  hisilicon, so we need re-work cpu clock driver. [1]

- CPUIdle and system's low power state;

  This part need integrate ARM-TF w/t MCU FW to support PSCI;

quoted

quoted

So my question is, does this SoC have an automatic thermal cut out? Whilst
I'm all for merging enabling code into the kernel, if it really relies on
the kernel to stop it from catching fire, maybe it's not a great idea
putting these patches into people's hands just yet.

Hikey is a low cost board, I think it doesn't have an automatic thermal
cut out; I always use HiKey to test my patch, in the normal case, 
temperature is not a problem.

I don't see why the cost has anything to do with this issue; any money I
save on the board will quickly be re-invested in my increased insurance
premium.

All I think we need is for secure software to keep an eye on the temperature
and hit the power controller if it goes over some `fatal' threshold.
Ideally, you'd be able to use a secure interrupt for this, but I suspect
that you don't have the right hardware features for that (please correct me
if I'm wrong). An alternative would be to hang something off a secure timer
and get the firmware to check the board temperature on some low-frequency
periodic tick.

Now we are using thermal framework to monitor thermal and if
temperature hit the trip point it will take cpu as cooling device and
set limitation for cpu's max frequency. [3]

[1] http://archive.arm.linux.org.uk/lurker/message/20150326.111335.0d484b89.en.html
[2] http://archive.arm.linux.org.uk/lurker/message/20150330.052637.16e0f3f4.en.html
[3] http://archive.arm.linux.org.uk/lurker/message/20150424.035121.80e0e24b.en.html

Thanks,
Leo Yan