devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 06/13] thermal: tegra: Do not register cooling device
Date: Fri, 10 Nov 2023 14:55:15 +0100	[thread overview]
Message-ID: <ZU42Qx0TbtEswEuA@orome.fritz.box> (raw)
In-Reply-To: <ea6c4056-9e7c-4aa3-b207-a97436682b8e@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

On Fri, Oct 13, 2023 at 05:57:13PM +0200, Daniel Lezcano wrote:
> On 12/10/2023 19:58, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > The SOCTHERM's built-in throttling mechanism doesn't map well to the
> > concept of a cooling device because it will automatically start to
> > throttle when the programmed temperature threshold is crossed.
> > 
> > Remove the cooling device implementation and instead unconditionally
> > program the throttling for the CPU and GPU thermal zones.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> 
> [ ... ]
> 
> > +	ret = of_property_read_u32(np, "temperature-millicelsius",
> > +				   &stc->temperature);
> > +	if (ret < 0)
> > +		goto err;
> > +
> > +	ret = of_property_read_u32(np, "hysteresis-millicelsius",
> > +				   &stc->hysteresis);
> > +	if (ret < 0)
> > +		goto err;
> > +
> > +	stc->num_zones = of_count_phandle_with_args(np, "nvidia,thermal-zones",
> > +						    NULL);
> > +	if (stc->num_zones > 0) {
> > +		struct device_node *zone;
> > +		unsigned int i;
> > +
> > +		stc->zones = devm_kcalloc(ts->dev, stc->num_zones, sizeof(zone),
> > +					  GFP_KERNEL);
> > +		if (!stc->zones)
> > +			return -ENOMEM;
> > +
> > +		for (i = 0; i < stc->num_zones; i++) {
> > +			zone = of_parse_phandle(np, "nvidia,thermal-zones", i);
> > +			stc->zones[i] = zone;
> > +		}
> > +	}
> 
> What is the connection between the temperature sensor and the hardware
> limiter?
> 
> I mean, one hand there is the hardware limiter which is not connected to the
> sensor neither a thermal zone and it could be self contained in a separate
> driver. And then there is the temperature sensor.
> 
> The thermal zone phandle things connected with the throttling bindings
> sounds like strange to me.
> 
> What prevents to split the throttling and the sensor into separate code?

Both the temperature sensor and the hardware throttle mechanism are part
of the same IP block, so it would be quite difficult (and unnecessary)
to split them into separate drivers.

The hardware throttler uses the temperature sensor's data to initiate
throttling automatically when certain (programmable) temperature
thresholds are reached.

The reason why we need to reference the thermal zone is because the
registers needed to program the throttler are contained within the
sensor group (which are effectively mapped to thermal zones).

I suppose there are a number of other ways how this could be described.
The thermal zones could be extended with extra information about the
throttling, or we could use just the sensor group ID instead of a full
phandle to reference this.

I was sort of trying to keep things somewhat aligned with the concept of
thermal zones and not rewrite the entire thing, but perhaps I should go
back to the drawing board and think about whether there's an even better
way to describe this in DT.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-11-10 13:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12 17:58 [PATCH v2 00/13] thermal: tegra: Do not register cooling device Thierry Reding
2023-10-12 17:58 ` [PATCH v2 01/13] thermal: Store device tree node for thermal zone devices Thierry Reding
2023-10-12 17:58 ` [PATCH v2 02/13] dt-bindings: thermal: tegra: Document throttle temperature Thierry Reding
2023-10-16 14:02   ` Rob Herring
2023-11-10 13:58     ` Thierry Reding
2023-10-12 17:58 ` [PATCH v2 03/13] dt-bindings: thermal: tegra: Add nvidia,thermal-zones property Thierry Reding
2023-10-13 15:59   ` Daniel Lezcano
2023-10-12 17:58 ` [PATCH v2 04/13] thermal: tegra: Use driver-private data consistently Thierry Reding
2023-10-13  8:04   ` Daniel Lezcano
2023-10-13 11:40     ` Thierry Reding
2023-10-12 17:58 ` [PATCH v2 05/13] thermal: tegra: Constify SoC-specific data Thierry Reding
2023-10-12 17:58 ` [PATCH v2 06/13] thermal: tegra: Do not register cooling device Thierry Reding
2023-10-13 15:57   ` Daniel Lezcano
2023-11-10 13:55     ` Thierry Reding [this message]
2023-11-10 14:52       ` Thierry Reding
2023-10-12 17:58 ` [PATCH v2 07/13] thermal: tegra: Use unsigned int where appropriate Thierry Reding
2023-10-12 17:58 ` [PATCH v2 08/13] thermal: tegra: Avoid over-allocation of temporary array Thierry Reding
2023-10-12 17:58 ` [PATCH v2 09/13] thermal: tegra: Remove gratuitous error assignment Thierry Reding
2023-10-12 17:58 ` [PATCH v2 10/13] thermal: tegra: Minor stylistic cleanups Thierry Reding
2023-10-12 17:58 ` [PATCH v2 11/13] arm64: tegra: Rework SOCTHERM on Tegra132 and Tegra210 Thierry Reding
2023-10-12 17:58 ` [PATCH v2 11/13] ARM: tegra: Rework SOCTHERM on Tegra124 Thierry Reding
2023-10-12 17:58 ` [PATCH v2 12/13] arm64: tegra: Rework SOCTHERM on Tegra132 and Tegra210 Thierry Reding
2023-10-12 17:58 ` [PATCH v2 12/13] ARM: tegra: Rework SOCTHERM on Tegra124 Thierry Reding
2023-10-12 17:58 ` [PATCH v2 13/13] thermal: Enforce self-encapsulation Thierry Reding
2023-10-13  9:14 ` [PATCH v2 00/13] thermal: tegra: Do not register cooling device Nicolas Chauvet
2023-10-13 11:43   ` Thierry Reding
2023-10-13 12:45     ` Nicolas Chauvet
2023-10-13 13:13       ` Thierry Reding
2023-10-13 13:55         ` Nicolas Chauvet
2023-10-13 15:45           ` Thierry Reding

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=ZU42Qx0TbtEswEuA@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=amitk@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@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).