[PATCH v4 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC
From: Will Deacon <hidden>
Date: 2015-05-07 11:25:38
Also in:
linux-devicetree
On Thu, May 07, 2015 at 10:29:03AM +0100, Bintian wrote:
On 2015/5/7 17:02, Will Deacon wrote:quoted
On Tue, May 05, 2015 at 01:06:34PM +0100, Bintian Wang wrote:quoted
Hi6220 is one mobile solution of Hisilicon, this patchset contains initial support for Hi6220 SoC and HiKey development board, which supports octal ARM Cortex A53 cores. Initial support is minimal and includes just the arch configuration, clock driver, device tree configuration. PSCI is enabled in device tree and there is no problem to boot all the octal cores, and the CPU hotplug is also working now, you can download and compile the latest firmware based on the following link to run this patch set: https://github.com/96boards/documentation/wiki/UEFI Changes v4: * Rebase to kernel 4.1-rc1 * Delete "arm,cortex-a15-gic" from the gic node in dtsI gave these patches a go on top of -rc2 using the ATF and UEFI you link to above. The good news is that the thing booted and all the cores entered at EL2. Thanks!Really thank you very much for testing this patch set.
Feel free to add my tested-by if you like.
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.
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?
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. Will