From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF508C432BE for ; Mon, 16 Aug 2021 18:57:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A405760F35 for ; Mon, 16 Aug 2021 18:57:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229590AbhHPS5b (ORCPT ); Mon, 16 Aug 2021 14:57:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229721AbhHPS5a (ORCPT ); Mon, 16 Aug 2021 14:57:30 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A503C0613CF for ; Mon, 16 Aug 2021 11:56:58 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id u15so12180032wmj.1 for ; Mon, 16 Aug 2021 11:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=m7ZOM7cdRkICqtiyacBDNsj4qURRxO1sWw5i5EgJhx0=; b=HzJ75RUvClIBbqraulv6LCtCEKRyhF9l86bNICahsL0BMDn+tr2MAGedaCoiS/M7HI 3Ttln2ZDTzMQV/73OAgb5gWdhqVTcAfaMui/jwC/yGkqKyrWPECIE5BGB9wuRotTtJZR n8glPdDvrAkL6NsfQuijpU7NTf+EitF7KrlYHBWiagTBD87z3EiqPC6ePhyVfex4LW1R bzJOqbK5rRd2/pUmjgicupfKYa5CF6ZgyjklG6WR05kEG1tJglD4u63hsIct80uAMX0l mufsLlgPEG0x9jXY+YS8QfK1nmsTKOsGjQu5tgwNUmQkNLRKK/BFJRlM20iaJgIeqnG2 Ks6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m7ZOM7cdRkICqtiyacBDNsj4qURRxO1sWw5i5EgJhx0=; b=XHBWss9l3rMUXr96kgjn8lL+jypx9e8WU6E/JXrUP6Xt066QJe2lGbaMUOpd/9WHAZ 3zLmqi0adWRwE2F3hgiYF/qzak64BV/sTSIoDsXJI/pwq9KLOsCFk6Uv05rvSkv0mAhb Z0we9MOr1vZxGVelBDV32ZqSnqd8CVxPoa1V5/SsolUX69rx2rUfOpJmFotybvmQlJ8D KMD/VE+RsCdiAWZTCGq5ARrOYqsJjdhFyzoo7O4nDxcGt7kd4eFe8LkF29Kn3El/yH95 HZWvUMSZm+TgehN2+qBvhtLJWlhTHk4YMPT1ySP8q0LIn2VPtB4LAdjVsLhSR9wPnrH7 93Qg== X-Gm-Message-State: AOAM533tvh5rptdCSnPqSJjpMwx8gNBwPll9G+QltGdH49EFWe5+xwWS 6Y9reKOpaLUoCxfMXe6WXNp+sA== X-Google-Smtp-Source: ABdhPJzoBGbVSUBBJBd79CzIiBUvM5rY3Ebc57V8YSLGDbhAuaNana1b9dAMLW1tLEGIgbbn9dJJ0g== X-Received: by 2002:a1c:f414:: with SMTP id z20mr524519wma.94.1629140216638; Mon, 16 Aug 2021 11:56:56 -0700 (PDT) Received: from ?IPv6:2a01:e34:ed2f:f020:e1b0:48c1:6199:9cb4? ([2a01:e34:ed2f:f020:e1b0:48c1:6199:9cb4]) by smtp.googlemail.com with ESMTPSA id g9sm386690wmk.34.2021.08.16.11.56.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 11:56:56 -0700 (PDT) Subject: Re: [PATCH v5 2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones To: Ben Tseng , Fan Chen , Zhang Rui , linux-pm@vger.kernel.org, srv_heupstream@mediatek.com Cc: Eduardo Valentin , Rob Herring , Mark Rutland , Matthias Brugger , hsinyi@chromium.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com, Michael Kao , Yu-Chia Chang References: <20210617114707.10618-1-ben.tseng@mediatek.com> <20210617114707.10618-3-ben.tseng@mediatek.com> <06b1804c-4675-2997-8c5c-bcdffbcfc4a1@linaro.org> <1f92b245537d6390b7b2bde62ce8b99a3df9d445.camel@mediatek.com> From: Daniel Lezcano Message-ID: <8a38b9fe-0448-3ddc-9ffc-c43137b5ecaa@linaro.org> Date: Mon, 16 Aug 2021 20:56:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1f92b245537d6390b7b2bde62ce8b99a3df9d445.camel@mediatek.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi Ben, On 23/07/2021 08:17, Ben Tseng wrote: > On Mon, 2021-06-21 at 13:26 +0200, Daniel Lezcano wrote: >> On 17/06/2021 13:47, Ben Tseng wrote: >>> From: Michael Kao >>> >>> Add a LVTS (Low voltage thermal sensor) driver to report junction >>> temperatures in Mediatek SoC and register the maximum temperature >>> of sensors and each sensor as a thermal zone. >> >> I think we already talked about that. We don't want a thermal sensor >> driver to aggregate the temperatures but create some kindof virtual >> sensor with a property (min, max, avg, ...) which is usable by >> anyone. >> >> [ ... ] >> >> >> > > Dear Daniel, > > Sorry for the late reply. sorry too, missed to answer. Another thread pointed to this one and I figured out I forgot to answer. > After survey ,I'm not sure whether the patch[1] is the architecture of > virtual thermal sensor which you commented. Ah, yes that is kind of what it would be requested but really generic so anyone can use it. > Or, is there any existing framework on mainline already support virtual > sensor? No unfortunately, it is not done [yet]. > Could you help to provide reference to us? Ok, we had this discussion several times on the mailing list and at the different events like the Linux Plumbers conference. But I was not able to find out a pointer. Basically the idea is simple, we don't want drivers doing weird things in their get_temp callback. This callback must return the temperature associated to a physical sensor in a 1:1 manner. However, some people want to define a thermal zone but with an aggregation of different sensors. At this point, we are unsure how to do that. Having a virtual sensor would be more adequate as it won't impact anything except the DT for a configuration. And we can make it to evolve without having to change all the thermal framework internals. >From a DT point of view, a virtual sensor device cuold have phandles to the different sensors and let's say a property telling what do to (avg, min, max, ...). The thermal zone will point to the virtual device. In the driver itself, the get_temp will just call get_temp of all the sensors and do the operation specified in the property. With that, the drivers stay consistent and we have the flexibility to do whatever we want. Does it make sense ? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog