NVIDIA Tegra changes for v4.19-rc1

NVIDIA Tegra changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

Here's the set of Tegra-related pull requests for v4.19-rc1. I'm sending
these a week earlier than usual because I will be on vacation for the
next two weeks. During my absence, Jon Hunter will be taking the helm.
Unfortunately he doesn't have access to the kernel.org repository, so if
anything comes up he may have to send patches to you directly. That said
I don't expect any issues with these pull requests. They've all soaked
in linux-next for a little while and I've done my regular sanity builds
and didn't see any issues.

In the unlikely case that everything falls apart, I'll be back shortly
after v4.18-rc7, which should give us a little time to clean things up
before the merge window.

Thanks,
Thierry

[GIT PULL 1/5] dt-bindings: tegra: Changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-dt-bindings

for you to fetch changes up to 29aa59efc6bf91cfa5bfba8375fd730150a19d3f:

  dt-bindings: arm: Add compatible string for NVIDIA Carmel (2018-07-02 15:58:25 +0200)

Thanks,
Thierry

----------------------------------------------------------------
dt-bindings: tegra: Changes for v4.19-rc1

This contains a single update that adds the Carmel CPU found in Tegra194
SoCs to the arm/cpus.txt device tree bindings.

----------------------------------------------------------------
Mikko Perttunen (1):
      dt-bindings: arm: Add compatible string for NVIDIA Carmel

 Documentation/devicetree/bindings/arm/cpus.txt | 1 +
 1 file changed, 1 insertion(+)

[GIT PULL 1/5] dt-bindings: tegra: Changes for v4.19-rc1

[Olof Johansson]

On Thu, Jul 12, 2018 at 05:41:24PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-dt-bindings
> 
> for you to fetch changes up to 29aa59efc6bf91cfa5bfba8375fd730150a19d3f:
> 
>   dt-bindings: arm: Add compatible string for NVIDIA Carmel (2018-07-02 15:58:25 +0200)
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> dt-bindings: tegra: Changes for v4.19-rc1
> 
> This contains a single update that adds the Carmel CPU found in Tegra194
> SoCs to the arm/cpus.txt device tree bindings.

Merged, thanks.


-Olof

[GIT PULL 2/5] memory: tegra: Changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-memory

for you to fetch changes up to 1662dd641f596e5517c7b7a23e4f8ddf36741b5f:

  memory: tegra: Correct driver probe order (2018-07-10 17:29:15 +0200)

Thanks,
Thierry

----------------------------------------------------------------
memory: tegra: Changes for v4.19-rc1

This contains a single fix for the initialization order of the various
parts of the Tegra memory controller driver.

----------------------------------------------------------------
Dmitry Osipenko (1):
      memory: tegra: Correct driver probe order

 drivers/memory/tegra/mc.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

[GIT PULL 2/5] memory: tegra: Changes for v4.19-rc1

[Olof Johansson]

On Thu, Jul 12, 2018 at 05:41:25PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-memory
> 
> for you to fetch changes up to 1662dd641f596e5517c7b7a23e4f8ddf36741b5f:
> 
>   memory: tegra: Correct driver probe order (2018-07-10 17:29:15 +0200)
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.19-rc1
> 
> This contains a single fix for the initialization order of the various
> parts of the Tegra memory controller driver.

Merged, thanks.


-Olof

[GIT PULL 3/5] firmware: tegra: Changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-firmware

for you to fetch changes up to 4ea7bdc6b5b33427bbd3f41c333e21c1825462a3:

  ARM: trusted_foundations: do not use naked function (2018-07-11 14:40:43 +0200)

Thanks,
Thierry

----------------------------------------------------------------
firmware: tegra: Changes for v4.19-rc1

This contains a single fix for the Trusted Foundations firmware
implementation, used on some Tegra20 and Tegra30 platforms.

----------------------------------------------------------------
Stefan Agner (1):
      ARM: trusted_foundations: do not use naked function

 arch/arm/firmware/trusted_foundations.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

[GIT PULL 3/5] firmware: tegra: Changes for v4.19-rc1

[Olof Johansson]

On Thu, Jul 12, 2018 at 05:41:26PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-firmware
> 
> for you to fetch changes up to 4ea7bdc6b5b33427bbd3f41c333e21c1825462a3:
> 
>   ARM: trusted_foundations: do not use naked function (2018-07-11 14:40:43 +0200)
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> firmware: tegra: Changes for v4.19-rc1
> 
> This contains a single fix for the Trusted Foundations firmware
> implementation, used on some Tegra20 and Tegra30 platforms.

Merged, thanks.


-Olof

[GIT PULL 4/5] ARM: tegra: Device tree changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm-dt

for you to fetch changes up to 5def854e370ff5c52172fb185932fdbffbf15692:

  ARM: dts: tegra: enable NAND flash on Colibri T20 (2018-07-09 18:51:01 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Device tree changes for v4.19-rc1

This set of changes adds support for the memory client resets on Tegra20
and Tegra30, fixes a couple of issues on Cardhu and Tegra30 Apalis as
well as adds a unit-address to the memory node to avoid warnings from
DTC. To round things of, the NAND flash controller is enabled on the
Tegra20 Colibri.

----------------------------------------------------------------
Dmitry Osipenko (2):
      ARM: dts: tegra20: Add Memory Client reset to VDE
      ARM: dts: tegra30: Add Memory Client reset to VDE

Jon Hunter (1):
      ARM: tegra: Fix Tegra30 Cardhu PCA954x reset

Krzysztof Kozlowski (4):
      ARM: tegra: Remove usage of deprecated skeleton.dtsi
      ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory
      ARM: tegra: Fix unit_address_vs_reg and avoid_unnecessary_addr_size DTC warnings
      ARM: tegra: Work safely with 256 MB Colibri-T20 modules

Lucas Stach (1):
      ARM: dts: tegra: add Tegra20 NAND flash controller node

Marcel Ziswiler (1):
      ARM: tegra: Fix can2 on Tegra30 Apalis

Stefan Agner (1):
      ARM: dts: tegra: enable NAND flash on Colibri T20

 arch/arm/boot/dts/Makefile                         |  2 +-
 arch/arm/boot/dts/tegra114-dalmore.dts             |  2 +-
 arch/arm/boot/dts/tegra114-roth.dts                |  2 +-
 arch/arm/boot/dts/tegra114-tn7.dts                 |  2 +-
 arch/arm/boot/dts/tegra114.dtsi                    |  9 +++++--
 arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi        |  2 +-
 arch/arm/boot/dts/tegra124-apalis.dtsi             |  2 +-
 arch/arm/boot/dts/tegra124-jetson-tk1.dts          |  2 +-
 arch/arm/boot/dts/tegra124-nyan.dtsi               |  2 +-
 arch/arm/boot/dts/tegra124-venice2.dts             |  2 +-
 arch/arm/boot/dts/tegra124.dtsi                    |  7 +++--
 ...gra20-iris-512.dts => tegra20-colibri-iris.dts} |  4 +--
 ...gra20-colibri-512.dtsi => tegra20-colibri.dtsi} | 27 ++++++++++++++++---
 arch/arm/boot/dts/tegra20-harmony.dts              |  2 +-
 arch/arm/boot/dts/tegra20-paz00.dts                |  2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts             |  2 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi            |  2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts            |  2 +-
 arch/arm/boot/dts/tegra20-ventana.dts              |  2 +-
 arch/arm/boot/dts/tegra20.dtsi                     | 31 +++++++++++++++++++---
 arch/arm/boot/dts/tegra30-apalis.dtsi              |  9 ++++---
 arch/arm/boot/dts/tegra30-beaver.dts               |  5 +---
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |  3 ++-
 arch/arm/boot/dts/tegra30-colibri.dtsi             |  4 +--
 arch/arm/boot/dts/tegra30.dtsi                     | 13 ++++++---
 25 files changed, 100 insertions(+), 42 deletions(-)
 rename arch/arm/boot/dts/{tegra20-iris-512.dts => tegra20-colibri-iris.dts} (95%)
 rename arch/arm/boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} (96%)

[GIT PULL 4/5] ARM: tegra: Device tree changes for v4.19-rc1

[Olof Johansson]

On Thu, Jul 12, 2018 at 05:41:27PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm-dt
> 
> for you to fetch changes up to 5def854e370ff5c52172fb185932fdbffbf15692:
> 
>   ARM: dts: tegra: enable NAND flash on Colibri T20 (2018-07-09 18:51:01 +0200)
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.19-rc1
> 
> This set of changes adds support for the memory client resets on Tegra20
> and Tegra30, fixes a couple of issues on Cardhu and Tegra30 Apalis as
> well as adds a unit-address to the memory node to avoid warnings from
> DTC. To round things of, the NAND flash controller is enabled on the
> Tegra20 Colibri.

Merged, thanks.


-Olof

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm64-dt

for you to fetch changes up to 7780a03495e13cd2bef704bcbf8c727de9f65232:

  arm64: tegra: Add CPU nodes to Tegra194 device tree (2018-07-02 15:57:39 +0200)

Thanks,
Thierry

----------------------------------------------------------------
arm64: tegra: Device tree changes for v4.19-rc1

These changes enable the GPIO controllers on Tegra194 SoCs, which in
turn allows the SD card detection and ethernet controllers to be enabled
as well. The Tegra194 device tree is also extended with the list of CPUs
and a PSCI node to inform the kernel about the presence of PSCI capable
firmware.

----------------------------------------------------------------
Mikko Perttunen (4):
      arm64: tegra: Add GPIO controller on Tegra194
      arm64: tegra: Enable card detect for SD card on P2888
      arm64: tegra: Add ethernet controller on Tegra194
      arm64: tegra: Add CPU nodes to Tegra194 device tree

 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi |  22 ++++-
 arch/arm64/boot/dts/nvidia/tegra194.dtsi       | 106 +++++++++++++++++++++++++
 2 files changed, 126 insertions(+), 2 deletions(-)

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Olof Johansson]

On Thu, Jul 12, 2018 at 05:41:28PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm64-dt
> 
> for you to fetch changes up to 7780a03495e13cd2bef704bcbf8c727de9f65232:
> 
>   arm64: tegra: Add CPU nodes to Tegra194 device tree (2018-07-02 15:57:39 +0200)
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> arm64: tegra: Device tree changes for v4.19-rc1
> 
> These changes enable the GPIO controllers on Tegra194 SoCs, which in
> turn allows the SD card detection and ethernet controllers to be enabled
> as well. The Tegra194 device tree is also extended with the list of CPUs
> and a PSCI node to inform the kernel about the presence of PSCI capable
> firmware.

Merged, thanks. Are you planning on supporting 194 better than 186? That never
really made it to a useful level upstream I think? :(


-Olof

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Thierry Reding]

On Sat, Jul 14, 2018 at 02:22:10PM -0700, Olof Johansson wrote:
> On Thu, Jul 12, 2018 at 05:41:28PM +0200, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> > 
> > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> > 
> >   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> > 
> > are available in the Git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm64-dt
> > 
> > for you to fetch changes up to 7780a03495e13cd2bef704bcbf8c727de9f65232:
> > 
> >   arm64: tegra: Add CPU nodes to Tegra194 device tree (2018-07-02 15:57:39 +0200)
> > 
> > Thanks,
> > Thierry
> > 
> > ----------------------------------------------------------------
> > arm64: tegra: Device tree changes for v4.19-rc1
> > 
> > These changes enable the GPIO controllers on Tegra194 SoCs, which in
> > turn allows the SD card detection and ethernet controllers to be enabled
> > as well. The Tegra194 device tree is also extended with the list of CPUs
> > and a PSCI node to inform the kernel about the presence of PSCI capable
> > firmware.
> 
> Merged, thanks. Are you planning on supporting 194 better than 186? That never
> really made it to a useful level upstream I think? :(

I think we have pretty decent upstream support for Tegra186 at this
point. It took a little time because Tegra186 was a little work than
many previous chips because the changes were less incremental than
before.

Generally our goal is to provide at least feature parity with prior
chips for each new chip. Usually we manage to incrementally add new
features, too.

Perhaps the reason why it seems that Tegra186 is not well supported
upstream is because a lot of things have moved into BPMP firmware,
which deals with a lot of the nitty gritty details that prior chips
needed a driver for.

That said, I may be missing something. Do you have any specific features
in mind that aren't working upstream on Tegra186?

Tegra194 uses the same firmware as Tegra186 (well, a binary compatible
interface to the firmware, I should say), so we've been able to
bootstrap it much quicker than prior chips. That said, there are a slew
of new features in Tegra194, not all of which are easy to upstream. But
we're still aiming for at least feature parity with prior chips and get
as much of the new hardware supported as we can.

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/20180803/5cb38a47/attachment.sig>

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Anthony Eden]

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?

On Fri, Aug 3, 2018, 6:43 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Sat, Jul 14, 2018 at 02:22:10PM -0700, Olof Johansson wrote:
> > On Thu, Jul 12, 2018 at 05:41:28PM +0200, Thierry Reding wrote:
> > > Hi ARM SoC maintainers,
> > >
> > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> > >
> > >   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.19-arm64-dt
> > >
> > > for you to fetch changes up to 7780a03495e13cd2bef704bcbf8c727de9f65232:
> > >
> > >   arm64: tegra: Add CPU nodes to Tegra194 device tree (2018-07-02 15:57:39 +0200)
> > >
> > > Thanks,
> > > Thierry
> > >
> > > ----------------------------------------------------------------
> > > arm64: tegra: Device tree changes for v4.19-rc1
> > >
> > > These changes enable the GPIO controllers on Tegra194 SoCs, which in
> > > turn allows the SD card detection and ethernet controllers to be enabled
> > > as well. The Tegra194 device tree is also extended with the list of CPUs
> > > and a PSCI node to inform the kernel about the presence of PSCI capable
> > > firmware.
> >
> > Merged, thanks. Are you planning on supporting 194 better than 186? That never
> > really made it to a useful level upstream I think? :(
>
> I think we have pretty decent upstream support for Tegra186 at this
> point. It took a little time because Tegra186 was a little work than
> many previous chips because the changes were less incremental than
> before.
>
> Generally our goal is to provide at least feature parity with prior
> chips for each new chip. Usually we manage to incrementally add new
> features, too.
>
> Perhaps the reason why it seems that Tegra186 is not well supported
> upstream is because a lot of things have moved into BPMP firmware,
> which deals with a lot of the nitty gritty details that prior chips
> needed a driver for.
>
> That said, I may be missing something. Do you have any specific features
> in mind that aren't working upstream on Tegra186?
>
> Tegra194 uses the same firmware as Tegra186 (well, a binary compatible
> interface to the firmware, I should say), so we've been able to
> bootstrap it much quicker than prior chips. That said, there are a slew
> of new features in Tegra194, not all of which are easy to upstream. But
> we're still aiming for at least feature parity with prior chips and get
> as much of the new hardware supported as we can.
>
> Thierry

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Thierry Reding]

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.

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/abf0c033/attachment.sig>

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Mikko Perttunen]

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.

> 
> Thierry
> 

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Thierry Reding]

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>

[GIT PULL 5/5] arm64: tegra: Device tree changes for v4.19-rc1

[Anthony Eden]

Sorry for the late reply. Thank you for the helpful information and guidance.

But before I investigate the thermal hypothesis further, I thought I'd
send out a kernel panic that I captured today during one of these
hangs. At the time I was upgrading packages via pacman (ArchLinux).
Does this shed any light on the issue?

Best,
-Anthony

On Thu, Aug 9, 2018 at 10:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> 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 --------------
/usr/lib/systemd/systemd: error wh[    7.411931] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[    7.411931]
[    7.423817] CPU: 0 PID: 1 Comm: systemd Tainted: G S                4.19.0-22-ARCH #1
[    7.431661] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT)
[    7.438721] Call trace:
[    7.441176]  dump_backtrace+0x0/0x180
[    7.444845]  show_stack+0x24/0x30
[    7.448168]  dump_stack+0x9c/0xbc
[    7.451490]  panic+0x124/0x274
[    7.454551]  do_exit+0xa80/0xab0
[    7.457784]  do_group_exit+0x3c/0xd0
[    7.461365]  __arm64_sys_exit_group+0x24/0x28
[    7.465729]  el0_svc_common+0x94/0xe8
[    7.469397]  el0_svc_handler+0x38/0x80
[    7.473152]  el0_svc+0x8/0xc
[    7.476039] SMP: stopping secondary CPUs
[    7.479974] Kernel Offset: disabled
[    7.483469] CPU features: 0x0,20002000
[    7.487222] Memory Limit: none
[    7.490285] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[    7.490285]  ]---
ile loading shared libraries: /u[    7.500730] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:1163 set_task_cpu+0x1b8/0x1c8
[    7.511448] Modules linked in: nvme nvme_core broadcom max77620_wdt bcm_phy_lib max77620_thermal ina3221 tegra_drm drm_kms_helper drm drm_panel_orientation_quirks syscopyarea gpio_keys sysfillrect sysimgblt tegra_bpmp_thermal dwmac_dwc_qos_eth i2c_tegra_bpmp fb_sys_fops stmmac_platform stmmac i2c_tegra host1x
[    7.538902] CPU: 0 PID: 1 Comm: systemd Tainted: G S                4.19.0-22-ARCH #1
[    7.546748] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT)
[    7.553809] pstate: 20000085 (nzCv daIf -PAN -UAO)
[    7.558609] pc : set_task_cpu+0x1b8/0x1c8
[    7.562627] lr : try_to_wake_up+0x190/0x478
[    7.566815] sp : ffff000008003d10
[    7.570134] x29: ffff000008003d10 x28: ffff0000096160c0
[    7.575456] x27: ffff0000095fc000 x26: 0000000000000100
[    7.580779] x25: 0000000000000005 x24: ffff00000961a490
[    7.586102] x23: ffff0000096089c0 x22: 0000000000000000
[    7.593268] x21: 0000000000000004 x20: 0000000000000005
[    7.600426] x19: ffff8001ed1f5e80 x18: 0000000000000000
[    7.607584] x17: 0000000000000000 x16: 0000000000000000
[    7.614740] x15: 0000000000000000 x14: 0000000000000000
[    7.621866] x13: ffff000008ca2658 x12: 00000000ffffffff
[    7.629006] x11: 000000000000009c x10: 0000000000000001
[    7.636135] x9 : 0000000000000000 x8 : ffff8001f67412a8
[    7.643241] x7 : 0040000000000000 x6 : 0000000000000036
[    7.650358] x5 : 00008001ed140000 x4 : ffff00000961a490
[    7.657457] x3 : 00008001ed1b8000 x2 : 0000000000000005
[    7.664563] x1 : ffff000009619700 x0 : 0000000000000000
[    7.671641] Call trace:
[    7.675753]  set_task_cpu+0x1b8/0x1c8
[    7.681081]  try_to_wake_up+0x190/0x478
[    7.686593]  wake_up_process+0x28/0x38
[    7.691993]  process_timeout+0x20/0x30
[    7.697355]  call_timer_fn+0x34/0x170
[    7.702636]  expire_timers+0xc0/0x148
[    7.707908]  run_timer_softirq+0xbc/0x1d8
[    7.713515]  __do_softirq+0x120/0x300
[    7.718781]  irq_exit+0xc0/0xd0
[    7.723505]  __handle_domain_irq+0x70/0xc0
[    7.729138]  gic_handle_irq+0x58/0xa8
[    7.734332]  el1_irq+0xb0/0x140
[    7.739006]  panic+0x224/0x274
[    7.743561]  do_exit+0xa80/0xab0
[    7.748299]  do_group_exit+0x3c/0xd0
[    7.753361]  __arm64_sys_exit_group+0x24/0x28
[    7.759217]  el0_svc_common+0x94/0xe8
[    7.764357]  el0_svc_handler+0x38/0x80
[    7.769562]  el0_svc+0x8/0xc
[    7.773915] ---[ end trace 22e2a84658d004da ]---
sr/lib/libcryptsetup.so.12: file too short

NVIDIA Tegra changes for v4.19-rc1

[Olof Johansson]

Hi,

On Thu, Jul 12, 2018 at 8:41 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> Hi ARM SoC maintainers,
>
> Here's the set of Tegra-related pull requests for v4.19-rc1. I'm sending
> these a week earlier than usual because I will be on vacation for the
> next two weeks. During my absence, Jon Hunter will be taking the helm.
> Unfortunately he doesn't have access to the kernel.org repository, so if
> anything comes up he may have to send patches to you directly. That said
> I don't expect any issues with these pull requests. They've all soaked
> in linux-next for a little while and I've done my regular sanity builds
> and didn't see any issues.

Sounds good. Jon, we're OK with merging from a github repo or similar
as well, if you have more than a few patches. Please re-send them to
arm at kernel.org with your sign-off when you have something (it's a lot
easier than if you just cc us on an acked-by, since gmail+imap doesn't
pop the whole thread over into my arm@ folder. :)

We can even host a rebasing/staging/temporary branch for you in case
you want something to be in -next but might not be 100% that it should
go in, if needed -- just let us know.

> In the unlikely case that everything falls apart, I'll be back shortly
> after v4.18-rc7, which should give us a little time to clean things up
> before the merge window.

Yeah, hopefully not much. And thanks a lot for communicating your
vacation schedules, it's useful for us to know!


-Olof

NVIDIA Tegra changes for v4.19-rc1

[Jon Hunter]

On 12/07/18 17:01, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 12, 2018 at 8:41 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> Hi ARM SoC maintainers,
>>
>> Here's the set of Tegra-related pull requests for v4.19-rc1. I'm sending
>> these a week earlier than usual because I will be on vacation for the
>> next two weeks. During my absence, Jon Hunter will be taking the helm.
>> Unfortunately he doesn't have access to the kernel.org repository, so if
>> anything comes up he may have to send patches to you directly. That said
>> I don't expect any issues with these pull requests. They've all soaked
>> in linux-next for a little while and I've done my regular sanity builds
>> and didn't see any issues.
> 
> Sounds good. Jon, we're OK with merging from a github repo or similar
> as well, if you have more than a few patches. Please re-send them to
> arm at kernel.org with your sign-off when you have something (it's a lot
> easier than if you just cc us on an acked-by, since gmail+imap doesn't
> pop the whole thread over into my arm@ folder. :)
> 
> We can even host a rebasing/staging/temporary branch for you in case
> you want something to be in -next but might not be 100% that it should
> go in, if needed -- just let us know.

Great. Thanks. Probably unlikely but you never know.

Cheers!
Jon

-- 
nvpublic