From patchwork Tue Jul 28 15:01:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jon Nettleton X-Patchwork-Id: 6887191 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0763EC05AC for ; Tue, 28 Jul 2015 15:04:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DE0AC201CE for ; Tue, 28 Jul 2015 15:04:13 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BB27C20623 for ; Tue, 28 Jul 2015 15:04:12 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZK6OJ-0000R2-KR; Tue, 28 Jul 2015 15:02:03 +0000 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZK6O6-0000Cp-VY for linux-arm-kernel@lists.infradead.org; Tue, 28 Jul 2015 15:01:53 +0000 Received: by wibxm9 with SMTP id xm9so165025543wib.1 for ; Tue, 28 Jul 2015 08:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D8nhElvlF67Z5Dqnd+Me4Awl7eEbucxtJGR/mnGRCcI=; b=Iv92L3Pe1HSGwxTsSmNwnUj/7Vnvc8kvJnsiLCWGjcnLy8BeC8nrQ8MaCej0ybAHy7 iratyNeytJF6PtjxwgZFZMkjBE3VvhrMyYZJyN7JjGfMihFloIjHN6r4FyuScAooUIyI 7xLmoOgtxLPbuLVFgTovQpYOi0np71jtfhqN/6fl6dztInpnWCWOPzr5UmoQ+lZgOT9s vmwYSW9y3x731BiOImYh51eLVVdLZwhyeK8HYSU0V5/DKVQi7jIgB1YxurGgFH706B96 mBzS4fYhNaj6DecGGelIRI2FdX2TBMT9puwoCkRIZpAONYpki0Qvr0aUqF4m5oYPKsuI UEFg== MIME-Version: 1.0 X-Received: by 10.194.171.200 with SMTP id aw8mr48655599wjc.62.1438095688352; Tue, 28 Jul 2015 08:01:28 -0700 (PDT) Received: by 10.28.138.74 with HTTP; Tue, 28 Jul 2015 08:01:28 -0700 (PDT) In-Reply-To: References: <1430409757-16195-1-git-send-email-tharvey@gateworks.com> <1432251947-13335-1-git-send-email-tharvey@gateworks.com> <20150524024836.GA3264@dragon> Date: Tue, 28 Jul 2015 17:01:28 +0200 Message-ID: Subject: Re: [PATCH v2] imx: thermal: use CPU temperature grade info for thresholds From: Jon Nettleton To: Tim Harvey X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150728_080151_272098_E88BA0BA X-CRM114-Status: GOOD ( 26.98 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fabio Estevam , Eduardo Valentin , Anson Huang , Shawn Guo , Zhang Rui , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP These changes need to be made to enable the canbus in the device-tree. By default we have those pins assigned as GPIO. As soon as I have the device-tree overlay patches pushed this configuration will be more dynamic, however now you must disable and enable the different iomux pin functionality by hand in the device-tree. On Tue, Jul 28, 2015 at 4:50 PM, Tim Harvey wrote: > On Tue, May 26, 2015 at 11:08 PM, Jon Nettleton wrote: >> On Tue, May 26, 2015 at 11:24 PM, Tim Harvey wrote: >>> On Sat, May 23, 2015 at 10:19 PM, Jon Nettleton wrote: >>>> On Sun, May 24, 2015 at 4:48 AM, Shawn Guo wrote: >>>>> On Thu, May 21, 2015 at 04:45:47PM -0700, Tim Harvey wrote: >>>>>> The IMX6Q/IMX6DL SoC's have a 2-bit temperature grade stored in OTP which >>>>>> is valid for all IMX6 SoC's (despite the fact that the IMXSDLRM and >>>>>> IMXSXRM do not document this - this has been proven via tests as well as >>>>>> verified by Freescale FAE). >>>>>> >>>>>> Instead of assuming a fixed 85C for passive cooling threshold and 105C for >>>>>> critical use the thermal grade for these configurations. >>>>>> >>>>>> We will set the critical to maxT - 5C and passive to maxT - 10C. >>>> >>>> I would like to chime in here if you don't mind. I have been carrying >>>> a patch similar to this in the SolidRun repo to fix cooling issues >>>> that we have had. I would recommend keeping the passive temp at maxT >>>> - 20C due to the thermal properties of the chip. I have found that >>>> around 85-90C we can maintain a relatively steady thermal state with >>>> only passive cooling. Generally with a hard non-NEON based cpu >>>> workload the iMX6 will level off at about 87C with all the cores >>>> clocked to 1Ghz, and sometimes dipping down to 800Mhz periodically. >>>> With a NEON based workload on all the cores it will push beyond this >>>> and generally end up finding steady state at about 800Mhz right around >>>> 90C. >>>> >>>> If you raise the initial passive threshold by 10C it will allow enough >>>> heat to build up in the chip that the only way to avoid reaching >>>> critical temps is by dropping the CPU down to its lowest frequency. >>>> This is not the best experience as then you have a much warmer chip >>>> and if the workload doesn't change you will just be switching between >>>> running at the highest cpu frequency or lowest which makes for a >>>> choppy experience. A longer passive cooling zone allows the >>>> temperature of the chip to be regulated using only passive methods but >>>> without drastic performance drops. >>>> >>>> I am doing things a bit differently in my implementation as I setup a >>>> passive cooling zone for each cpu frequency, but that is just so you >>>> can have more control from userspace by changing the different passive >>>> trip points. >>>> >>>> -Jon >>> >>> Jon, >>> >>> I can agree with leaving a Max-20C passive delta. What do you think >>> about the critical threshold of Max-5C and rule of not allowing it to >>> be changed? >>> >> >> Tim, >> >> I definitely agree that the Critical temp should be a fixed point. Is >> the purpose of lowering the critical threshold from the hardware >> default, to allow Linux to shutdown more cleanly rather than just have >> the hardware shutting down? If that is the case then I think that is >> fine. If it is to protect the SOC then that is unnecessary. We have >> heated the SOCs to well beyond the critical threshold and they have >> survived just fine. >> >> This is a bit out of context but here is the formula I am using to >> figure out my trip points. By default I use a linear set of trip >> points for passive cooling. >> https://github.com/linux4kix/linux-linaro-stable-mx6/commit/212c17d543739a5fe0bd75b66c10f05177e8bcb0 >> >> The short of it is I set a trip delta of 6C and then figure out the >> lowest passive trip point as Critical - (#passive trip points * trip >> delta), where each cpu frequency stage is a passive trip point. This >> will allow an 800Mhz SOC with 2 trip points to run at full speed >> longer than a 1.2Ghz with 4 trip points. The idea being that the >> higher the clock rate means we will generate more heat and have more >> passive cooling levels so it is better to drop the top speed of the >> CPU earlier in order to let the passive cooling be effective and find >> a steady state. >> >> This may be a bit over the top but has fixed problems where long >> running processes would build up heat and eventually cause a thermal >> shutdown, but doesn't completely cripple the faster SOCs. > > Jon, > > Yes - the purpose of lowering the critical threshold from the hardware > default is to allow Linux to shutdown more cleanly. > > If you agree with the fact that the patch here offers the improvement > of using OTG temperature grade as a basis can you ack it and if you > feel that the thresholds need to be adjusted perhaps propose a > follow-on patch? I feel people can debate the temperature delta's > endlessly but what I was really after here was to fix the fact that > all the processors are not temperature graded equally because they are > packaged differently (metal case on automotive offering better thermal > conductivity vs plastic case on consumer) > > Regards, > > Tim diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi index 7dcae42..308de69 100644 --- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi @@ -168,7 +168,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hummingboard_flexcan1>; - status = "disabled"; + status = "okay"; }; &hdmi_core { @@ -278,8 +278,9 @@ MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x400130b1 MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x400130b1 MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x400130b1 - MX6QDL_PAD_SD3_CMD__GPIO7_IO02 0x400130b1 - MX6QDL_PAD_SD3_CLK__GPIO7_IO03 0x400130b1 +/* MX6QDL_PAD_SD3_CMD__GPIO7_IO02 0x400130b1 + * MX6QDL_PAD_SD3_CLK__GPIO7_IO03 0x400130b1 + */ MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x400130b1 >; };