Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1412158imu; Wed, 9 Jan 2019 18:17:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN6Ru3Rgn/A0KZRQD5BL2vBoT6ed/A597ATTLgfWCc/6VfoVSv2osi9ab3KKYIrDRD1Z+sH8 X-Received: by 2002:a63:ef47:: with SMTP id c7mr7784490pgk.386.1547086643080; Wed, 09 Jan 2019 18:17:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547086643; cv=none; d=google.com; s=arc-20160816; b=j1fjDCqaYlP97EPbQKIRNQTDynW2FkAQsgccH/5HotGBV2KUI6EskmdZMaeh1d4c1q r7blTLAMLquBvJrRh4Tqoh4xbOlve2ET3EyYnguOp/745uAU80CXyP5rAMpfgILrSVrA KS3xyQpRkzsyiNk5ndDjgWxN3Ccg9xj4yVutQAquMIPO2k2bIx+KT3Z+L0I7PYoYZNHm nF1JRfXjGEbGmJKpEnofnP/mi8Hecye0NDbQQFJcf04djdq7dl2C2ljQHT2835HpMN92 zcMgt77lu3gDlx6X1WWBM6oZ5LZ2d9CWCWfFJNOLFdQMKf+qe+OfoHaVnitVFfDfe0Wj PyNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=tWFDYhahir1R0mCqKfkSgNOuYf/yckRop+rHiVTpwdU=; b=v3LMhMDOBB4+5To+wlilf7Lo4pxZsbEhshw0p6AYcxXTB5jbTBqw/Ui0C9ed1M2tzF T0jPA251h1M6G5c46GatWy/QKDGmsMRfqGnQqEnpiS290R18XVJeLBU01XgOXu55NFAq rjc8T7bI3NQz1tDMbVVV10R+qRJ63i6K6qxRqd1l5Pf+3hrNgvJX0McpmUwSMK1Mwfac JVVKvgGB3QbUn17XtE9EeVeXNA3MQ1gWa5kRgLUhALlLZbm55E+Ye/hToner4UgcYSFN QT4UAlOLZ78MmcxZ2UXnE/yN+l3mMxX85lTWcCO+RkyQCDbF3bWg4Qzv8Gan+Ohg2rBO U9rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gP8T2mJx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q140si65461795pfc.20.2019.01.09.18.17.04; Wed, 09 Jan 2019 18:17:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=@chromium.org header.s=google header.b=gP8T2mJx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726881AbfAJCPZ (ORCPT + 99 others); Wed, 9 Jan 2019 21:15:25 -0500 Received: from mail-pf1-f193.google.com ([209.85.210.193]:41242 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726818AbfAJCPY (ORCPT ); Wed, 9 Jan 2019 21:15:24 -0500 Received: by mail-pf1-f193.google.com with SMTP id b7so4562749pfi.8 for ; Wed, 09 Jan 2019 18:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tWFDYhahir1R0mCqKfkSgNOuYf/yckRop+rHiVTpwdU=; b=gP8T2mJxzmxHl4wiumQraM/zazFd53+d5dpHi+xKNa5xkimR2nrejwaRBGsLBKEDAd D3N/EpNkWme8ImeZq3W10PKG6UJNxY4abp+nJd6lh3fbIcLJ7YuGcSFDjEyGoeelXl+f enmIdRHsouRf7C3OmrZZWdTZoGM8ASnK5yaqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tWFDYhahir1R0mCqKfkSgNOuYf/yckRop+rHiVTpwdU=; b=IgsMO+ncMvxgpcpcPoOgB5Lq6Oxs1MCcJjpbocnT+IOvTV1xMoekHRiXXhL07BPXfg 1LZmctdcXfU3C4hybasMkG3dmnoQ/Q8k3i8L+lAoYesiaUsNKI0CIj66txQksFCzuKPo rPbcTJpNTL6/abjd2Vt89YAKtW+L3pzzkyxaLBvmh2vmJeJ6KYIuLbEVV8OdIzm3s06q MATBXQMGucqQ5WC/lG87VfC0OEmAdVCvuB8o6rrdpcXoAoPDfMtnRy51CvDULeVQDoC5 70sG6lctipL7Eu+w04tC04uqwb8pdbqVJI+vHlW0YX7ObEozo9Vin8voiUX+S8nW/kEc zBbg== X-Gm-Message-State: AJcUukes++WfiNaAu+Xw3OOYCksl14Zflxz10jrXLx6jbWjg6TSzVqvL MaktaEX+jtUfUzV8HmnI3bpqNnIjZKQhNg== X-Received: by 2002:a63:f65:: with SMTP id 37mr7604550pgp.238.1547086523728; Wed, 09 Jan 2019 18:15:23 -0800 (PST) Received: from localhost ([2620:15c:202:1:75a:3f6e:21d:9374]) by smtp.gmail.com with ESMTPSA id f13sm102036262pfa.132.2019.01.09.18.15.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jan 2019 18:15:23 -0800 (PST) Date: Wed, 9 Jan 2019 18:15:22 -0800 From: Matthias Kaehlcke To: Amit Kucheria Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, bjorn.andersson@linaro.org, viresh.kumar@linaro.org, edubezval@gmail.com, andy.gross@linaro.org, tdas@codeaurora.org, swboyd@chromium.org, dianders@chromium.org, David Brown , Rob Herring , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Subject: Re: [PATCH v1 6/7] arm64: dts: sdm845: Increase alert trip point to 95 degrees Message-ID: <20190110021522.GW261387@google.com> References: <041258d65883df964890249a24d2a4788c419304.1547078153.git.amit.kucheria@linaro.org> <20190110011533.GV261387@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190110011533.GV261387@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 09, 2019 at 05:15:33PM -0800, Matthias Kaehlcke wrote: > Hi Amit, > > On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote: > > 75 degrees is too aggressive for throttling the CPU. After speaking to > > Qualcomm engineers, increase it to 95 degrees. > > > > Signed-off-by: Amit Kucheria > > --- > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 ++++++++-------- > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi > > index c27cbd3bcb0a..29e823b0caf4 100644 > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > > @@ -1692,7 +1692,7 @@ > > > > trips { > > cpu_alert0: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1713,7 +1713,7 @@ > > > > trips { > > cpu_alert1: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1734,7 +1734,7 @@ > > > > trips { > > cpu_alert2: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1755,7 +1755,7 @@ > > > > trips { > > cpu_alert3: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1776,7 +1776,7 @@ > > > > trips { > > cpu_alert4: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1797,7 +1797,7 @@ > > > > trips { > > cpu_alert5: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1818,7 +1818,7 @@ > > > > trips { > > cpu_alert6: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > @@ -1839,7 +1839,7 @@ > > > > trips { > > cpu_alert7: trip0 { > > - temperature = <75000>; > > + temperature = <95000>; > > hysteresis = <2000>; > > type = "passive"; > > }; > > The change itself looks good to me, however I wonder if it would be > worth to eliminate redundancy and merge the current 8 thermal zones > into 2, one for the Silver and one for the Gold cluster (as done by > http://crrev.com/c/1381752). There is a single cooling device for > each cluster, so it's not clear to me if there is any gain from having > a separate thermal zone for each CPU. If it is important to monitor > the temperatures of the individual cores this can still be done by > configuring the thermal zone of the cluster with multiple thermal > sensors. I see your idea is to have a cooling device per CPU ("arm64: dts: sdm845: wireup the thermal trip points to cpufreq" / https://lore.kernel.org/patchwork/patch/1030742/), however that doesn't work as intended. Only two cpufreq 'devices' are created, one for CPU0 and one for CPU4. In consequence cpufreq->ready() only runs for these cores and only two cooling devices are registered. Since the cores of a cluster all run at the same frequency I also doubt if having multiple cooling devices would bring any benefits. Cheers Matthias