linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Bailon <abailon@baylibre.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>,
	rui.zhang@intel.com, amitk@kernel.org
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	ben.tseng@mediatek.com, khilman@baylibre.com
Subject: Re: [RFC PATCH 0/2] Add a generic virtual thermal sensor
Date: Mon, 23 Aug 2021 09:35:13 +0200	[thread overview]
Message-ID: <df9ad6a9-4cf9-dd41-8876-d19bef03d6a5@baylibre.com> (raw)
In-Reply-To: <f7d1205b-e859-e059-c835-c09a85c8c480@linaro.org>

Hi Daniel,

On 20/08/2021 13:30, Daniel Lezcano wrote:
> Hi Alexandre,
>
> thanks for the proposal.
>
> On 19/08/2021 14:32, Alexandre Bailon wrote:
>> This series add a virtual thermal sensor that uses the hardware thermal sensors,
>> aggregate them to return a temperature.
>>
>> My first aptempt was to do the aggregation in the thermal zone but it was not
>> that easy to do, and, there were some case that would have been conflictual
>> such as setting differents trip for a regular zone and a multisensor zone.
>>
>> Instead, I made a virtual thermal sensor that could registered in a thermal
>> zone, and have its own properties.
>> It could be added in the device tree, with the list of sensors to aggregate,
>> and the type of aggregation to be done.
>>
>> As example:
>>    soc_max_sensor: soc_max_sensor {
>>      compatible = "generic,thermal-aggregator";
>>      #thermal-sensor-cells = <1>;
>>      type = "max";
>>      thermal-sensors = <&lvts 0>, <&lvts 1>, <&lvts 2>, <&lvts 3>,
>>            <&lvts 4>, <&lvts 5>, <&lvts 6>, <&lvts 7>,
>>            <&lvts 8>, <&lvts 9>, <&lvts 10>, <&lvts 11>,
>>            <&lvts 12>, <&lvts 13>, <&lvts 14>, <&lvts 15>,
>>            <&lvts 16>;
>>    };
>>
>> The current series build and work but it would require to be completed
>> aswell a lot of cleanup.
>> Before working on it, I would like to get some feedback and I know if that
>> would an acceptable solution and continue that way.
> Yes, I think it is going to the right direction.
>
> IMO, we can get rid of the thermal_of changes. From a design PoV, the
> patch itself should be the virtual thermal driver without any changes in
> the core code, including thermal_of.
I made that changes in order to be able to get the hw sensors from the 
virtual sensor.
I am not really satisfied of that patch but that the simplest way I 
found to do it.
How would you proceed to get the hw sensor from its device tree phandle 
and id ?

Thanks,
Alexandre

>
> I have some comments on patch 2/2
>
>
>> Follows the following discussion:
>> https://patchwork.kernel.org/project/linux-mediatek/patch/20210617114707.10618-3-ben.tseng@mediatek.com/
>>
>> Alexandre Bailon (2):
>>    thermal: provide a way to get thermal sensor from a device tree node
>>    thermal: add a virtual sensor to aggregate temperatures
>>
>>   drivers/thermal/Kconfig              |   8 ++
>>   drivers/thermal/Makefile             |   1 +
>>   drivers/thermal/thermal_aggregator.c | 134 +++++++++++++++++++++++++++
>>   drivers/thermal/thermal_of.c         |  43 +++++++++
>>   include/linux/thermal.h              |  12 +++
>>   5 files changed, 198 insertions(+)
>>   create mode 100644 drivers/thermal/thermal_aggregator.c
>>
>

  reply	other threads:[~2021-08-23  7:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 12:32 [RFC PATCH 0/2] Add a generic virtual thermal sensor Alexandre Bailon
2021-08-19 12:32 ` [RFC PATCH 1/2] thermal: provide a way to get thermal sensor from a device tree node Alexandre Bailon
2021-08-19 12:32 ` [RFC PATCH 2/2] thermal: add a virtual sensor to aggregate temperatures Alexandre Bailon
2021-08-20 12:52   ` Daniel Lezcano
2021-08-23  7:54     ` Alexandre Bailon
2021-08-20 11:30 ` [RFC PATCH 0/2] Add a generic virtual thermal sensor Daniel Lezcano
2021-08-23  7:35   ` Alexandre Bailon [this message]
2021-08-23  8:40     ` Daniel Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df9ad6a9-4cf9-dd41-8876-d19bef03d6a5@baylibre.com \
    --to=abailon@baylibre.com \
    --cc=amitk@kernel.org \
    --cc=ben.tseng@mediatek.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).