All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <andy.gross@linaro.org>,
	David Brown <david.brown@linaro.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH v1 00/12] qcom: dts: thermal cleanups
Date: Wed, 20 Feb 2019 15:32:59 -0800	[thread overview]
Message-ID: <20190220233257.GA31479@localhost.localdomain> (raw)
In-Reply-To: <CAP245DXn3db27wMPSaZazRhprXD89JKQ5qEkc8r0DpSL9A847w@mail.gmail.com>

On Wed, Feb 20, 2019 at 03:09:36PM +0530, Amit Kucheria wrote:
> On Wed, Feb 20, 2019 at 6:56 AM Eduardo Valentin <edubezval@gmail.com> wrote:
> >
> > Hey
> > On Mon, Feb 18, 2019 at 06:05:14PM +0530, Amit Kucheria wrote:
> > > - Expose all temperature sensors on msm8916, msm996, msm8998, sdm845
> > > - split up the register address map for msm8998
> > > - standardize names of the various thermal-zones across boards to make it
> > >   easy for test scripts to parse
> > >
> >
> > I am generally fine with the effort but please fix the following
> > (applies for the whole series) wrt to required properties for DT
> > thermal:
> > a. Trip points for your zones
> 
> Thanks for the review.
> 
> In some cases, the temperatures are just exposed so something in
> userspace might read it and do something with it. We don't expect
> kernel trips for them.

Would a hwmon driver make more sense here?

> 
> Adding trip points also requires me to add cooling-maps (your point b. below).

Yes.

> 
> I guess I'm looking for an example of how to just expose sensor
> temperatures w/o any associated trips and cooling maps.
> 
> > b. Cooling Mappings for zones that have passive trips.
> >
> 
> From what I can see currently only CPUs and GPUs (among the major heat
> sources) can passively reduce heat by reducing frequencies.
> 
> Things like cameras, display, video might have a more ON/OFF approach
> to throttling that might be controlled from userspace. And we don't
> have a way to tell in DT that these zones are managed in userspace

You can always add a Hot trip point. To my understanding that is for
notifying userspace.




> (https://patchwork.kernel.org/patch/10259487/)

      reply	other threads:[~2019-02-20 23:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-18 12:35 [PATCH v1 00/12] qcom: dts: thermal cleanups Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 01/12] arm64: dts: msm8998: thermal: split address space into two Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 02/12] arm64: dts: msm8998: efficiency is not valid property Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 03/12] arm64: dts: msm8916: thermal: Add sensor for modem Amit Kucheria
2019-02-20  1:24   ` Eduardo Valentin
2019-02-18 12:35 ` [PATCH v1 04/12] arm64: dts: msm8996: thermal: Add temperature sensors near major peripherals Amit Kucheria
2019-02-20  1:24   ` Eduardo Valentin
2019-02-20  9:18     ` Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 05/12] arm64: dts: msm8998: thermal: Fix the cpu sensor numbers Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 06/12] arm64: dts: msm8998: thermal: Fix the gpu sensor number Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 07/12] arm64: dts: msm8998: thermal: GPU has two sensors, add the second Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 08/12] arm64: dts: msm8998: thermal: Add temperature sensors near major peripherals Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 09/12] arm64: dts: sdm845: " Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 10/12] arm64: dts: msm8998: thermal: Make trip names consistent Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 11/12] arm64: dts: msm8916: " Amit Kucheria
2019-02-18 12:35 ` [PATCH v1 12/12] arm64: dts: msm8996: " Amit Kucheria
2019-02-20  1:26 ` [PATCH v1 00/12] qcom: dts: thermal cleanups Eduardo Valentin
2019-02-20  9:39   ` Amit Kucheria
2019-02-20  9:39     ` Amit Kucheria
2019-02-20 23:32     ` Eduardo Valentin [this message]

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=20190220233257.GA31479@localhost.localdomain \
    --to=edubezval@gmail.com \
    --cc=amit.kucheria@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.