From: Thierry Reding <thierry.reding@gmail.com>
To: Mikko Perttunen <cyndis@kapsi.fi>
Cc: Jon Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org, Anthony Eden <aeden@csail.mit.edu>,
arm@kernel.org, Olof Johansson <olof@lixom.net>,
Mikko Perttunen <mperttunen@nvidia.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1
Date: Thu, 9 Aug 2018 16:07:53 +0200 [thread overview]
Message-ID: <20180809140753.GH21639@ulmo> (raw)
In-Reply-To: <51a19ec3-8b34-56f5-d9c7-69397d3d11ff@kapsi.fi>
[-- Attachment #1.1: Type: text/plain, Size: 1965 bytes --]
On Thu, Aug 09, 2018 at 01:34:37PM +0300, Mikko Perttunen wrote:
> On 09.08.2018 13:21, Thierry Reding wrote:
> > On Fri, Aug 03, 2018 at 07:26:04AM -0400, Anthony Eden wrote:
> > > Mesa support aside- if I start a computationally intensive job on the
> > > Jetson TX2 like building the Linux kernel on all cores, it will lock
> > > up. My only work around has been to disable the Denver CPU's. I don't
> > > think the tegra186 has upstream support to control the fan on the
> > > Jetson TX2, could this be a thermal problem?
> >
> > Yes, I suppose this could be a thermal problem. Or it could be something
> > else entirely. We do support CPU frequency scaling on Tegra X2, so what
> > you could do is keep the Denver CPUs enabled, but set the powersave CPU
> > frequency governor. That way it should use all the CPUs but at a lower
> > clock rate, which should also be able to avoid any thermal issues. This
> > could help determine whether or not the problem is thermal or something
> > else.
> >
> > Also adding Mikko on Cc who wrote the Tegra186 driver, maybe he's aware
> > of any issues.
>
> I haven't seen any issues myself, though I haven't stressed the CPU too
> heavily. We also have a thermal driver for Tegra186, so we could set up
> thermal throttling with a device tree change.
Do you have an example of how that would work? The DT bindings are a
little sparse on the specifics. It seems like something similar to what
we did on Tegra124 could be done on Tegra186.
Anthony: do you think you could come up with something suitable based on
what arch/arm/boot/dts/tegra124{.dtsi,-jetson-tk1.dts} and the device
tree bindings for Tegra186 contain in
Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt
as well as
include/dt-bindings/thermal/tegra186-bpmp-thermal.h
? That's provided that reducing the CPU frequency does indeed prevent
the lock up that you were seeing.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1
Date: Thu, 9 Aug 2018 16:07:53 +0200 [thread overview]
Message-ID: <20180809140753.GH21639@ulmo> (raw)
In-Reply-To: <51a19ec3-8b34-56f5-d9c7-69397d3d11ff@kapsi.fi>
On Thu, Aug 09, 2018 at 01:34:37PM +0300, Mikko Perttunen wrote:
> On 09.08.2018 13:21, Thierry Reding wrote:
> > On Fri, Aug 03, 2018 at 07:26:04AM -0400, Anthony Eden wrote:
> > > Mesa support aside- if I start a computationally intensive job on the
> > > Jetson TX2 like building the Linux kernel on all cores, it will lock
> > > up. My only work around has been to disable the Denver CPU's. I don't
> > > think the tegra186 has upstream support to control the fan on the
> > > Jetson TX2, could this be a thermal problem?
> >
> > Yes, I suppose this could be a thermal problem. Or it could be something
> > else entirely. We do support CPU frequency scaling on Tegra X2, so what
> > you could do is keep the Denver CPUs enabled, but set the powersave CPU
> > frequency governor. That way it should use all the CPUs but at a lower
> > clock rate, which should also be able to avoid any thermal issues. This
> > could help determine whether or not the problem is thermal or something
> > else.
> >
> > Also adding Mikko on Cc who wrote the Tegra186 driver, maybe he's aware
> > of any issues.
>
> I haven't seen any issues myself, though I haven't stressed the CPU too
> heavily. We also have a thermal driver for Tegra186, so we could set up
> thermal throttling with a device tree change.
Do you have an example of how that would work? The DT bindings are a
little sparse on the specifics. It seems like something similar to what
we did on Tegra124 could be done on Tegra186.
Anthony: do you think you could come up with something suitable based on
what arch/arm/boot/dts/tegra124{.dtsi,-jetson-tk1.dts} and the device
tree bindings for Tegra186 contain in
Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt
as well as
include/dt-bindings/thermal/tegra186-bpmp-thermal.h
? That's provided that reducing the CPU frequency does indeed prevent
the lock up that you were seeing.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180809/f71f237b/attachment.sig>
next prev parent reply other threads:[~2018-08-09 14:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 15:41 NVIDIA Tegra changes for v4.19-rc1 Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-12 15:41 ` [GIT PULL 1/5] dt-bindings: tegra: Changes " Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-14 21:20 ` Olof Johansson
2018-07-14 21:20 ` Olof Johansson
2018-07-12 15:41 ` [GIT PULL 2/5] memory: " Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-14 21:40 ` Olof Johansson
2018-07-14 21:40 ` Olof Johansson
2018-07-12 15:41 ` [GIT PULL 3/5] firmware: " Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-14 21:45 ` Olof Johansson
2018-07-14 21:45 ` Olof Johansson
2018-07-12 15:41 ` [GIT PULL 4/5] ARM: tegra: Device tree changes " Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-14 21:21 ` Olof Johansson
2018-07-14 21:21 ` Olof Johansson
2018-07-12 15:41 ` [GIT PULL 5/5] arm64: " Thierry Reding
2018-07-12 15:41 ` Thierry Reding
2018-07-14 21:22 ` Olof Johansson
2018-07-14 21:22 ` Olof Johansson
2018-08-03 10:43 ` Thierry Reding
2018-08-03 10:43 ` Thierry Reding
2018-08-03 11:26 ` Anthony Eden
2018-08-03 11:26 ` Anthony Eden
2018-08-09 10:21 ` Thierry Reding
2018-08-09 10:21 ` Thierry Reding
2018-08-09 10:34 ` Mikko Perttunen
2018-08-09 10:34 ` Mikko Perttunen
2018-08-09 14:07 ` Thierry Reding [this message]
2018-08-09 14:07 ` Thierry Reding
2018-11-03 20:08 ` Anthony Eden
2018-11-03 20:08 ` Anthony Eden
2018-07-12 16:01 ` NVIDIA Tegra " Olof Johansson
2018-07-12 16:01 ` Olof Johansson
2018-07-13 14:09 ` Jon Hunter
2018-07-13 14:09 ` Jon Hunter
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=20180809140753.GH21639@ulmo \
--to=thierry.reding@gmail.com \
--cc=aeden@csail.mit.edu \
--cc=arm@kernel.org \
--cc=cyndis@kapsi.fi \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mperttunen@nvidia.com \
--cc=olof@lixom.net \
/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.