From patchwork Wed Sep 6 06:58:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Lezcano X-Patchwork-Id: 111759 Delivered-To: patch@linaro.org Received: by 10.140.94.166 with SMTP id g35csp425200qge; Wed, 6 Sep 2017 00:00:04 -0700 (PDT) X-Received: by 10.84.129.193 with SMTP id b59mr7001461plb.64.1504681204799; Wed, 06 Sep 2017 00:00:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504681204; cv=none; d=google.com; s=arc-20160816; b=oirsyvLWewqCbQlJ3cYhA8FahYvjDtuHzZvsxz9YtxQgCx+a/U8sMxfcSuskM2Ta8p 16iH4FLU1P8X8BQp9JJHbYzT9aLyVRwF8Lb4TKXL2dgs6TXqTyKJrkdhZDWAzMOYwBlJ XkL1sl359V0EHLGzMmLho7+ZcQeQSdPFxHpwwJVfiyUHj4FMSs2Dw8Hb5QjX8vHHpruJ ogugnjjWejf4X2VUlXTQfnNu8p6i8wE565xzd8AXoRnTbcOZxLp+Az9nFy+o8sHC7LAR fmcM3yLN/+qNdrqxNP84y39bmhRuAg9PAvjQCrR0YQosYwvV7lb8EWtYFPAZJAIyT88e 4IWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=W6BMl2M8Nsw/tMoR4vWLOmdcUCtRqKmv8ps0CjTeMsI=; b=C+ZFSrD4mJRM8olOdDdTtYpbxl0S4Yt39h4pwyCEb8SWPv6nIyoqJEZY2giVPZl6K5 2ZvabQwl3EmGJUzmjhcZcTUwntKKv213x6CYaxhlBAAkdkdeZfIGZlF9C8G4eEQFGI6y oKh2Lx7fUMCwfBi8Bla7BgxLYM8peQ32JDn0tVOSAiW0Y98FC8fKpq0m9OPcCHtJq/r9 qq9PG8KECmdfc0TnOUZt/IL6JcksK2Oqr6DIcHZPJdT/DfepxX9ukGwyo1fQIMn72Q3j hV6UMftYZg2ykLsBiCiSiAaqm8xZB9RVNWav+EdfqHn483SJn93VW0iBMtAV2/QXVSOa 8zrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cKN6Jxa+; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w19si698905pfa.173.2017.09.06.00.00.01; Wed, 06 Sep 2017 00:00:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cKN6Jxa+; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751008AbdIFG77 (ORCPT + 12 others); Wed, 6 Sep 2017 02:59:59 -0400 Received: from mail-wr0-f179.google.com ([209.85.128.179]:35268 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbdIFG76 (ORCPT ); Wed, 6 Sep 2017 02:59:58 -0400 Received: by mail-wr0-f179.google.com with SMTP id y15so12060495wrc.2 for ; Tue, 05 Sep 2017 23:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=W6BMl2M8Nsw/tMoR4vWLOmdcUCtRqKmv8ps0CjTeMsI=; b=cKN6Jxa+wfhPlm1tGKnKkfno3Uw1aGg5D/Wlr1XmwgtGi0RWTep7ZYbDq/jZrEDDZK ZdXSTeFnhoOms76qlIaNzEhD2Bio77kSeaaPrXcnCCLsJUYScUGonzwWRzsonD/iWFGi HmncDw20qTwvSUuZPpQgnfrvRc0Aw5zSZlEvQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=W6BMl2M8Nsw/tMoR4vWLOmdcUCtRqKmv8ps0CjTeMsI=; b=tC34lp6roFBDUildTya6wEMrn+4gHyHQUbXGdCkLOn18a/surQZvlCePcJiynhMsfR KKk/u0YMzuUjz3rTLRr2H1deO9FwTCTkwzNz1ajQCKCKGC0sHr+cAdkw6hyrhPWER+o7 MFACx+GM3MXwll2p3qs0ClODWVTyGziy00IQtdZ5jbjfHcDuqeo6jg9fr+W06arORSgP XVhcVx4HDSOcNQdwLNBKmXJ4++CKzGagGBM+G0t74DrJQYtudWFVIU+yTs4H9Qf12bmn 5zHhK2TKLc7vWAygizsdw04GjL4I9u3zMloz+ulpDMcjAeNtdrTVHT+pFN5lOb/5otZx 0G3w== X-Gm-Message-State: AHPjjUgbxW4JBboN0rgtFX6FlrPFhA5U5ebhXh8aM6jV2JSsCW6OhYEH v3xfsrqDPdmQK1wA X-Google-Smtp-Source: ADKCNb7pWVZ0M1fjJ5q8EYAFz07plVf5FNktXppzl0+BqucgSHmlOEVdHboesLBC926lZgNQgNj7WQ== X-Received: by 10.223.197.67 with SMTP id s3mr879689wrf.323.1504681197022; Tue, 05 Sep 2017 23:59:57 -0700 (PDT) Received: from localhost.localdomain ([2a01:e35:879a:6cd0:f185:6cbb:48ea:5ada]) by smtp.gmail.com with ESMTPSA id 25sm4132849wrv.8.2017.09.05.23.59.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Sep 2017 23:59:56 -0700 (PDT) From: Daniel Lezcano To: rui.zhang@intel.com, edubezval@gmail.com Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, john.stultz@linaro.org, leo.yan@linaro.org Subject: [PATCH] thermal/drivers/step_wise: Fix temperature regulation misbehavior Date: Wed, 6 Sep 2017 08:58:46 +0200 Message-Id: <1504681126-30751-1-git-send-email-daniel.lezcano@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. Signed-off-by: Daniel Lezcano --- drivers/thermal/step_wise.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 2.7.4 diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c index be95826..a01259a 100644 --- a/drivers/thermal/step_wise.c +++ b/drivers/thermal/step_wise.c @@ -94,9 +94,11 @@ static unsigned long get_target_state(struct thermal_instance *instance, if (!throttle) next_target = THERMAL_NO_TARGET; } else { - next_target = cur_state - 1; - if (next_target > instance->upper) - next_target = instance->upper; + if (!throttle) { + next_target = cur_state - 1; + if (next_target > instance->upper) + next_target = instance->upper; + } } break; case THERMAL_TREND_DROP_FULL: