Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1609214rdd; Thu, 11 Jan 2024 04:31:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IFINVsGPg+a5s6eUW7G83Ru8w0DVB6b6FWVuIGZgaqMBbyWz88Dqf+AaO7jn1NSFXa5y13Z X-Received: by 2002:a05:6214:5b04:b0:680:d22d:7bb9 with SMTP id ma4-20020a0562145b0400b00680d22d7bb9mr1031022qvb.65.1704976292506; Thu, 11 Jan 2024 04:31:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704976292; cv=none; d=google.com; s=arc-20160816; b=G5bSTdyaAXcUlR6VZxav+rxfVEvizjEseRip0ip3KOM5P1cG3/nQM4el8kH/QrPXgR KyfyuwWJJTzfsYw475awaNxQ8F8B9cEMS1HVI8D/FqzRGjQybNrbuM0eae+wR+BHZMvt X8eTEACkRzkB/2Qyg5tROmyhpl48h1yqffdk12PooOKUl+a7VfCPvsZrwgzLteAZ5KfF 3zMo75zhTRX35q6AMIqrVIDlvpmCKTcOG9Qmy8y3c+nASt2F7gZv+7JRfFy8QKolzy3L 8vSjUi4xODtdDlrX5YTauOlunSrAeAAq86uOfl7cz3VktN8PUloem3jDJ7nN1wQypvnU WObw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=ctIIYZvHIf/z1bBBjSgX7uQONSF4UVhJIjS5ZL1i7uk=; fh=GGll9tLEaYtQ3SigP+/38wiew+Pt7GwPZ80bQsyo50g=; b=TFyczM/iqjpSNKBjrnpTtvphs0blUx8udHxwbsm43AsoY5QLDZ8BZBMNQVnL9xElMs WSbPxu8pJd4hko4X1Dw7Fz80whn6dQgK5UeNnK3TITI3kDJTQdaDqPVi+Yla7lc5nh4+ Y5yjLTF3abaMM06Uuk34N1Wq2lUQY7qwiqF1v6lfYpyZSIxkVzYGzVZaiDGc3f5gk8iv AX+M5HTrJF5xUMKIfm+BaeZcfPgzlCFKXDHRtv5qGoGqBB/DdllkiVLb6ywEY1gTXwQ3 7bsG0zdO0EpwTiX2Gd6KLXoBWcogJKjegDwUghUSYCJfDcFCHnRWfUDVzC2PV+e6vR4D 7k4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@collabora.com header.s=mail header.b=q4WNmi89; spf=pass (google.com: domain of linux-kernel+bounces-23590-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23590-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id w1-20020a0c8e41000000b0067f7b56d717si701761qvb.318.2024.01.11.04.31.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 04:31:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23590-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@collabora.com header.s=mail header.b=q4WNmi89; spf=pass (google.com: domain of linux-kernel+bounces-23590-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23590-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 38A101C20DE5 for ; Thu, 11 Jan 2024 12:31:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A38415AEF; Thu, 11 Jan 2024 12:31:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="q4WNmi89" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 798EF15AC2; Thu, 11 Jan 2024 12:31:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1704976278; bh=UUJgjJ0RgrkopwyiH7EhfQcUXFSjaBg0zxcp09P632c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=q4WNmi89YstZXiLPgOt1dwpk1nC+RqlIiraEbHug2sZN/WZv1iufJk2WCqLRpXyYi B81nVXtd3/nzdec2qroxhgcV+EJqtWUonK6E6foQttzg2pBk9B6BW0JaRBBCqrDgYm X0vyI5RPEaWF3GiJN469g6HspI/+mY+Mp98wrokyxjhuoLPHYUgnCcCx8CmPnc9inO YXz5FzclwA5pXybeydIGo5EtCtuTHJt1RYTYNphK8+3EIs+Q4009Ym/if2fnYEaYZ9 DYe47T0wwXrD70xruhhxEk8BKp2t9z9U9SL5itgunBQIBgQaUO4fmCYBVnJqrWCs9t UT6C+VfDSBB2A== Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 0CC873780F7F; Thu, 11 Jan 2024 12:31:17 +0000 (UTC) Message-ID: Date: Thu, 11 Jan 2024 13:31:17 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] arm64: dts: qcom: sm7225-fairphone-fp4: Add PM6150L thermals Content-Language: en-US To: Konrad Dybcio , Luca Weiss , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20240105-fp4-thermals-v1-0-f95875a536b7@fairphone.com> <20240105-fp4-thermals-v1-2-f95875a536b7@fairphone.com> <18dc5f88-6590-4e2d-948f-fd77f4713f8b@linaro.org> From: AngeloGioacchino Del Regno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Il 10/01/24 20:16, Konrad Dybcio ha scritto: > > > On 1/9/24 12:24, Luca Weiss wrote: >> On Tue Jan 9, 2024 at 11:09 AM CET, Konrad Dybcio wrote: >>> >>> >>> On 1/5/24 15:54, Luca Weiss wrote: >>>> Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0, >>>> RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermistors connected to >>>> PM6150L. >>>> >>>> Due to hardware constraints we can only register 4 zones with >>>> pm6150l_adc_tm, the other 2 we can register via generic-adc-thermal. >>> >>> Ugh.. so the ADC can support more inputs than the ADC_TM that was >>> designed to ship alongside it can? >>> >>> And that's why the "generic-adc-thermal"-provided zones need to >>> be polled? >> >> This part of the code from qcom-spmi-adc-tm5.c was trigerring if I >> define more than 4 channels, and looking at downstream I can also see >> that only 4 zones are registered properly with adc_tm, the rest is >> registered with "qcom,adc-tm5-iio" which skips from what I could tell >> basically all the HW bits and only registering the thermal zone. >> >> >>     ret = adc_tm5_read(chip, ADC_TM5_NUM_BTM, >>                &channels_available, sizeof(channels_available)); >>     if (ret) { >>         dev_err(chip->dev, "read failed for BTM channels\n"); >>         return ret; >>     } >> >>     for (i = 0; i < chip->nchannels; i++) { >>         if (chip->channels[i].channel >= channels_available) { >>             dev_err(chip->dev, "Invalid channel %d\n", chip->channels[i].channel); >>             return -EINVAL; >>         } >>     } >> >> >>> >>>> >>>> The trip points can really only be considered as placeholders, more >>>> configuration with cooling etc. can be added later. >>>> >>>> Signed-off-by: Luca Weiss >>>> --- >>> [...] >>> >>> I've read the sentence above, but.. >>>> +        sdm-skin-thermal { >>>> +            polling-delay-passive = <1000>; >>>> +            polling-delay = <5000>; >>>> +            thermal-sensors = <&msm_therm_sensor>; >>>> + >>>> +            trips { >>>> +                active-config0 { >>>> +                    temperature = <125000>; >>>> +                    hysteresis = <1000>; >>>> +                    type = "passive"; >>> >>> I don't fancy burnt fingers for dinner! >> >> With passive trip point it wouldn't even do anything now, but at what >> temp do you think it should do what? I'd definitely need more time to >> understand more of how the thermal setup works in downstream Android, >> and then replicate a sane configuration for mainline with proper >> temperatures, cooling, etc. > If "skin therm" means "the temperature of some part of the phone's > body that can be felt with a human hand", then definitely some > throttling should happen at 40ish with heavy throttling at 50 > and crit at 55 or so.. > > We should probably make this a broader topic and keep a single > policy for all supported phones. > > + CC AGdR, may be interested in where this leads > > Konrad A thermal trip at 125°C for *skin temperature* is useless... if a device's skin temperature (be it a smartphone, a SBC, a Chromebook, a non-specially-identified laptop, a car head unit, or whatever else you can imagine) reaches that kind of temperature, this means that something inside likely reached something along the lines of 150°C for a prolonged period of time. You will definitely agree with me that if something reached that temperature for a certain period of time, it is *highly unlikely* (not to say impossible) that Linux is even still running and that the green smoke that is naturally trapped in any chip didn't get released :-) Besides, keep in mind that if the SKIN temperature is 55°C, if your device has a -> lithium <- battery (li-ion/lifepo/others), your hands are "probably" in a kind of danger that I wouldn't be comfortable with (and neither you I'm sure). Strictly related to the trip temperature setting for "SKIN", for me this is a strong NAK. I'd go for stricter ranges too, something like... - critical: ~52/53 - heavy throttling: 49/50 - throttle: ~45 NOTE: this would be valid only if there are other throttling points for CPU/GPU/etc ---- Anyway, something else I have in my mind: ---- Konrad: "standardizing" skin temperature is too big of a bet, and will be wrong, because industrial-grade devices are permitted to reach higher skin temperatures. Some industrial grade smartphones (example: rugged stuff) may have sensors in the underside of the ruggedized shell... so in that case you want to set the skin temperature limit with delta-T ideally... Though! Making this easier for everyone: we can somehow dictate (unofficially, because of more of the many reasons I already explained) an acceptable temperature range for "skin" temperature, outside of which, reviews should follow manual testing. As for the concept of "skin temperature", and for some thermal framework work (sorry for the word game) that I'm bringing on the table, in this case we can imagine it as: Thermal zone type: SKIN Thermal zone name: shell-upper/shell-rightmost/shell....something Type SKIN would be defined as "a zone defining the temperature of the outer shell of a device"... ..and for example differently from type PCB, which fits different temperature probe points. Feel free to keep me in the loop, btw. Cheers, Angelo