devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Nicolas Chauvet <kwizart@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	"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, linux-tegra@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v2 00/13] thermal: tegra: Do not register cooling device
Date: Fri, 13 Oct 2023 17:45:17 +0200	[thread overview]
Message-ID: <ZSlmDTareNuAgX-r@orome.fritz.box> (raw)
In-Reply-To: <CABr+WTnP-JencnDt-u9emuc7knm1LSNDS5VRf-X9sZzQ0jrs1w@mail.gmail.com>

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

On Fri, Oct 13, 2023 at 03:55:43PM +0200, Nicolas Chauvet wrote:
> Le ven. 13 oct. 2023 à 15:13, Thierry Reding
> <thierry.reding@gmail.com> a écrit :
> >
> > On Fri, Oct 13, 2023 at 02:45:57PM +0200, Nicolas Chauvet wrote:
> > > Le ven. 13 oct. 2023 à 13:43, Thierry Reding
> > > <thierry.reding@gmail.com> a écrit :
> > > >
> > > > On Fri, Oct 13, 2023 at 11:14:25AM +0200, Nicolas Chauvet wrote:
> > > > > Le jeu. 12 oct. 2023 à 19:58, Thierry Reding
> > > > > <thierry.reding@gmail.com> a écrit :
> > > > > >
> > > > > > From: Thierry Reding <treding@nvidia.com>
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > this set of patches removes the registration of the SOCTHERM internal
> > > > > > throttling mechanism as cooling device. Since this throttling starts
> > > > > > automatically once a certain temperature threshold is crossed, it
> > > > > > doesn't make sense to represent it as a cooling device, which are
> > > > > > typically "manually" activated by the thermal framework when thermal
> > > > > > sensors report temperature thresholds being crossed.
> > > > > >
> > > > > > Instead of using the cooling device mechanism, this statically programs
> > > > > > the throttling mechanism when it is configured in device tree. In order
> > > > > > to do this, an additional device tree property is needed to replace the
> > > > > > information that was previously contained in trip points.
> > > > > >
> > > > > > There's a few preparatory patches to make the removal a bit simpler and
> > > > > > also some follow up cleanups included as well.
> > > > > >
> > > > > > Changes in v2:
> > > > > > - rework the device tree bindings:
> > > > > >   - add nvidia,thermal-zones property to attach throttling to zones
> > > > > >   - use -millicelsius suffix and add hysteresis
> > > > > > - add patch to store thermal zone device tree node for later use
> > > > > > - add patch to enforce self-encapsulation of the thermal core now that
> > > > > >   no drivers need to reach into it anymore
> > > > > >
> > > > > > This applies on top of Daniel's self-encapsulation hardening series:
> > > > > >
> > > > > >         https://lore.kernel.org/all/20231012102700.2858952-1-daniel.lezcano@linaro.org/
> > > > > >
> > > > > > Thierry
> > > > > >
> > > > > > Thierry Reding (13):
> > > > > >   thermal: Store device tree node for thermal zone devices
> > > > > >   dt-bindings: thermal: tegra: Document throttle temperature
> > > > > >   dt-bindings: thermal: tegra: Add nvidia,thermal-zones property
> > > > > >   thermal: tegra: Use driver-private data consistently
> > > > > >   thermal: tegra: Constify SoC-specific data
> > > > > >   thermal: tegra: Do not register cooling device
> > > > > >   thermal: tegra: Use unsigned int where appropriate
> > > > > >   thermal: tegra: Avoid over-allocation of temporary array
> > > > > >   thermal: tegra: Remove gratuitous error assignment
> > > > > >   thermal: tegra: Minor stylistic cleanups
> > > > > >   ARM: tegra: Rework SOCTHERM on Tegra124
> > > > > >   arm64: tegra: Rework SOCTHERM on Tegra132 and Tegra210
> > > > > >   thermal: Enforce self-encapsulation
> > > > > >
> > > > > >  .../thermal/nvidia,tegra124-soctherm.yaml     |  19 +
> > > > > >  arch/arm/boot/dts/nvidia/tegra124.dtsi        |  68 +--
> > > > > >  arch/arm64/boot/dts/nvidia/tegra132.dtsi      |  66 +--
> > > > > >  arch/arm64/boot/dts/nvidia/tegra210.dtsi      |  86 +--
> > > > > >  drivers/thermal/tegra/soctherm.c              | 525 ++++++++----------
> > > > > >  drivers/thermal/tegra/soctherm.h              |   1 +
> > > > > >  drivers/thermal/tegra/tegra124-soctherm.c     |   4 +
> > > > > >  drivers/thermal/tegra/tegra132-soctherm.c     |   4 +
> > > > > >  drivers/thermal/tegra/tegra210-soctherm.c     |   4 +
> > > > > >  drivers/thermal/thermal_core.h                |   2 +-
> > > > > >  drivers/thermal/thermal_of.c                  |   3 +
> > > > > >  11 files changed, 329 insertions(+), 453 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.42.0
> > > > > >
> > > > >
> > > > > I'm still experiencing the following message on jetson-tx1 with this
> > > > > serie applied on top of 6.6-rc5 (with iommu-next and tegra-next
> > > > > applied).
> > > > > oct. 13 10:53:16 jetson-tx1 kernel: max77620-thermal max77620-thermal:
> > > > > Failed to register thermal zone: -19
> > > >
> > > > Not sure about this one. I don't think I've seen it. Do you know if
> > > > that's somehow caused by this series, or is it preexisting?
> > >
> > > It's pre-existing from this serie.
> > >
> > > > > oct. 13 10:53:16 jetson-tx1 kernel: tegra_soctherm
> > > > > 700e2000.thermal-sensor: throttle-cfg: heavy: no throt prop or invalid
> > > > > prop
> > > > >
> > > > > Is this expected ?
> > > >
> > > > This one is definitely not expected. I have seen this before, and it
> > > > happens when the device tree doesn't contain all the properties that are
> > > > expected. Patch 12 in this series should take care of that. Have you
> > > > made sure that that's been applied and is what the kernel uses to boot
> > > > with?
> > >
> > > Yes, this dtb change in patch12 is propagated to the device (as seen
> > > in /boot/dtbs)
> > > But comparing with what's available at runtime in /proc/device-tree, I
> > > see some changes
> > >
> > >                         heavy {
> > > -                               hysteresis-millicelsius = <0xfa0>;
> > > +                               #cooling-cells = <0x02>;
> > >                                 nvidia,cpu-throt-percent = <0x55>;
> > >                                 nvidia,gpu-throt-level = <0x03>;
> > >                                 nvidia,priority = <0x64>;
> > > -                               nvidia,thermal-zones = <0x49 0x4a>;
> > > -                               temperature-millicelsius = <0x180c4>;
> > > +                               phandle = <0x130>;
> > >                         };
> >
> > Okay, that explains the error message.
> >
> > >
> > > I'm using u-boot 2023.07 with EFI boot (L4T 32.7.4).
> > > Could it be that the bootloader has changed these entries ? Can this
> > > be prevented ?
> >
> > I'm not aware of anything in the bootloader that would do this. Some
> > versions of U-Boot that ships with L4T can copy certain nodes in DTB but
> > I have never seen anything that would've touched thermal.
> >
> > Is it possible that you're not loading the DTB and end up receiving one
> > from UEFI or cboot?
> Seems like it: a previous copy was in /boot/dts that took over /boot/dtbs.
> With updated dtb, the warning disappeared.

Okay, great!

> Only remaining error is: kernel: max77620-thermal max77620-thermal:
> Failed to register thermal zone: -19

Looks like that's -ENODEV from devm_thermal_of_zone_register() via
max77620_thermal_probe(). Looking at thermal_of_zone_register(), the
-ENODEV case is treated specially, so perhaps we should be doing the
same thing in max77620_probe()?

Let me send out a patch.

Thierry

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

      reply	other threads:[~2023-10-13 15:45 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
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 [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=ZSlmDTareNuAgX-r@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=kwizart@gmail.com \
    --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).