public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Schaeckeler <schaecsn@gmx.net>
To: amit.kucheria@verdurent.com
Cc: heiko@sntech.de, linux-pm@vger.kernel.org,
	daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org,
	edubezval@gmail.com, linux-rockchip@lists.infradead.org,
	rui.zhang@intel.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RESEND PATCH] thermal: rockchip: enable hwmon
Date: Thu, 12 Dec 2019 15:28:59 -0800 (PST)	[thread overview]
Message-ID: <20191212232859.E09FC6E85603@corona.crabdance.com> (raw)
In-Reply-To: <CAHLCerOHjAEEA1BpUqPdZvFwHMy11SqC+ZtjdFyManu7iOpBXA@mail.gmail.com> (message from Amit Kucheria on Thu, 12 Dec 2019 13:58:52 +0530)

Hello Amit,

> On Thu, Dec 12, 2019 at 11:47 AM Stefan Schaeckeler <schaecsn@gmx.net> wrote:
> >
> > By default, of-based thermal drivers do not enable hwmon.
> > Explicitly enable hwmon for both, the soc and gpu temperature
> > sensor.
>
> Is there any reason you need to expose this in hwmon?

Why hwmon:

The soc embedds temperature sensors and hwmon is the standard way to expose
sensors.

Sensors exposed by hwmon are automagically found by userland clients. Users
want to run sensors(1) and expect them to show up.


Why in rockchip_thermal.c:

drivers/thermal/ provides a high-level hwmon api in thermal_hwmon.[hc] which is
used by at least these thermal drivers: rcar_gen3_thermal.c, rcar_thermal.c,
st/stm_thermal.c, and broadcom/bcm2835_thermal.c. I want to hook up
rockchip_thermal.c exactly the same way.

Apparently, other architectures hook up the cpu temperature sensors to hwmon
elsewhere. Most seem to do this in hwmon/, e.g. hwmon/coretemp.c. These drivers
are written from scratch. Utilizing thermal_hwmon.[ch] for chips which have
already drivers in drivers/thermal/ seems to be more elegant.

 Stefan

  reply	other threads:[~2019-12-12 23:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  6:17 [RESEND PATCH] thermal: rockchip: enable hwmon Stefan Schaeckeler
2019-12-12  8:28 ` Amit Kucheria
2019-12-12 23:28   ` Stefan Schaeckeler [this message]
2019-12-13  4:38     ` Amit Kucheria
2019-12-13  4:39       ` Amit Kucheria
2019-12-13 17:31         ` Guenter Roeck
2019-12-16 16:16 ` 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=20191212232859.E09FC6E85603@corona.crabdance.com \
    --to=schaecsn@gmx.net \
    --cc=amit.kucheria@verdurent.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=edubezval@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.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