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 7111BC4320E for ; Mon, 16 Aug 2021 18:57:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A42560F22 for ; Mon, 16 Aug 2021 18:57:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229763AbhHPS5b (ORCPT ); Mon, 16 Aug 2021 14:57:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbhHPS5a (ORCPT ); Mon, 16 Aug 2021 14:57:30 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DC67C061764 for ; Mon, 16 Aug 2021 11:56:58 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id c129-20020a1c35870000b02902e6b6135279so620351wma.0 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=pQbj6itOMaKos8i59Rmm0reVDu21krjlnAeCBhrnmQyKGRSg91s03yJVTDP9p1B2nO VNRvE4gr76/dvZLB7dXXZc5+6ZbraFtTj3CWemEkeB2i5OXNLLt8h5EfVDUNtOL2PKzN nATyIAWyOfvLV29/g0BXWfdOfs6LptPM6EVIRm9jCD3nj+ZzszqeT+E1wnxBbxP3m8RA rCPjhwROUv9uwEnUFIidyMkdALNvfK0VRXO0HvmRQW8qFc0klVeoR0vi/LlCgKKI3bva AmsOjyUSlek7W5UA3GMyEIdQZNJOvkbAa9obzknQmYyv42zbF4MkRp4utpwaJZWDNu36 OCJw== X-Gm-Message-State: AOAM531t1yEtRVyxcikVVcqYsii7dD7HxUYRHCxBqXmsZCwiXDyi49bq L9q1Yrj8OJLenKXTIiA/mJG4tg== 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-kernel@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