[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a38b9fe-0448-3ddc-9ffc-c43137b5ecaa@linaro.org>
Date: Mon, 16 Aug 2021 20:56:54 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Ben Tseng <ben.tseng@...iatek.com>,
Fan Chen <fan.chen@...iatek.com>,
Zhang Rui <rui.zhang@...el.com>, linux-pm@...r.kernel.org,
srv_heupstream@...iatek.com
Cc: Eduardo Valentin <edubezval@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Matthias Brugger <matthias.bgg@...il.com>, hsinyi@...omium.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Project_Global_Chrome_Upstream_Group@...iatek.com,
Michael Kao <michael.kao@...iatek.com>,
Yu-Chia Chang <ethan.chang@...iatek.com>
Subject: Re: [PATCH v5 2/3] thermal: mediatek: Add LVTS drivers for SoC
theraml zones
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 <michael.kao@...iatek.com>
>>>
>>> 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 ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists