interconnect: constify of_phandle_args in xlate

The xlate callbacks are supposed to translate of_phandle_args to proper
provider without modifying the of_phandle_args. Make the argument
pointer to

interconnect: constify of_phandle_args in xlate

The xlate callbacks are supposed to translate of_phandle_args to proper
provider without modifying the of_phandle_args. Make the argument
pointer to const for code safety and readability.

Acked-by: Konrad Dybcio <[email protected]>
Acked-by: Thierry Reding <[email protected]> # Tegra
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Alim Akhtar <[email protected]> # Samsung
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>

show more ...

memory: tegra: Add SID override programming for MC clients

For some devices the bootloader/firmware may set up the device in
bypass. Memory clients like display needs kernel to program SID after
res

memory: tegra: Add SID override programming for MC clients

For some devices the bootloader/firmware may set up the device in
bypass. Memory clients like display needs kernel to program SID after
resume because bootloader/firmware programs the SID of display device to
bypass. In order to make sure that kernel IOMMU mappings for these
devices work after resume, add SID override programming support for all
memory clients on memory controller resume.

This partially reverts 'commit ef86b2c2807f ("memory: tegra: Remove
clients SID override programming")'

Signed-off-by: Ashish Mhetre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

iommu/tegra-gart: Remove tegra-gart

Thierry says this is not used anymore, and doesn't think it makes sense as
an iommu driver. The HW it supports is about 10 years old now and newer HW
uses differe

iommu/tegra-gart: Remove tegra-gart

Thierry says this is not used anymore, and doesn't think it makes sense as
an iommu driver. The HW it supports is about 10 years old now and newer HW
uses different IOMMU drivers.

As this is the only driver with a GART approach, and it doesn't really
meet the driver expectations from the IOMMU core, let's just remove it
so we don't have to think about how to make it fit in.

It has a number of identified problems:
- The assignment of iommu_groups doesn't match the HW behavior

- It claims to have an UNMANAGED domain but it is really an IDENTITY
domain with a translation aperture. This is inconsistent with the core
expectation for security sensitive operations

- It doesn't implement a SW page table under struct iommu_domain so
* It can't accept a map until the domain is attached
* It forgets about all maps after the domain is detached
* It doesn't clear the HW of maps once the domain is detached
(made worse by having the wrong groups)

Cc: Thierry Reding <[email protected]>
Cc: Dmitry Osipenko <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Reviewed-by: Lu Baolu <[email protected]>
Reviewed-by: Jerry Snitselaar <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

memory: tegra: Add dummy implementation on Tegra194

With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
interconnect support in Tegra234"), the PCI driver on Tegra194 and later
require

memory: tegra: Add dummy implementation on Tegra194

With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add
interconnect support in Tegra234"), the PCI driver on Tegra194 and later
requires an interconnect provider. However, a provider is currently only
exposed on Tegra234 and this causes PCI on Tegra194 to defer probe
indefinitely.

Fix this by adding a dummy implementation on Tegra194. This allows nodes
to be provided to interconnect consumers, but doesn't do any bandwidth
accounting or frequency scaling.

Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234")
Reported-by: Jon Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Reviewed-by: Sumit Gupta <[email protected]>
Tested-by: Sumit Gupta <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Make CPU cluster BW request a multiple of MC channels

Make CPU cluster's bandwidth (BW) request a multiple of MC channels.
CPU OPP tables have BW info per MC channel. But, the actual

memory: tegra: Make CPU cluster BW request a multiple of MC channels

Make CPU cluster's bandwidth (BW) request a multiple of MC channels.
CPU OPP tables have BW info per MC channel. But, the actual BW depends
on the number of MC channels which can change as per the boot config.
Get the number of MC channels which are actually enabled in current
boot configuration and multiply the BW request from a CPU cluster with
the number of enabled MC channels. This is not required to be done for
other MC clients.

Signed-off-by: Sumit Gupta <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

memory: tegra: Add interconnect support for DRAM scaling in Tegra234

Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. Both the MC and EMC drivers are

memory: tegra: Add interconnect support for DRAM scaling in Tegra234

Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. Both the MC and EMC drivers are
added as ICC providers. The path for any request is:
MC-Client[1-n] -> MC -> EMC -> EMEM/DRAM

MC client's request for bandwidth will go to the MC driver which
passes the client request info like BPMP Client ID, Client type
and the Bandwidth to the BPMP-FW. The final DRAM freq to achieve
the requested bandwidth is set by the BPMP-FW based on the passed
parameters.

Signed-off-by: Sumit Gupta <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

memory: tegra: Add API for retrieving carveout bounds

On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell it
th

memory: tegra: Add API for retrieving carveout bounds

On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell it
the address of this firmware, which we can determine by checking the
starting address of the carveout. As such, add an MC API to query the
bounds of carveouts, and add related information on Tegra234.

Signed-off-by: Mikko Perttunen <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

memory: tegra: Add MC error logging on Tegra186 onward

Add support for logging memory controller errors on Tegra186, Tegra194
and Tegra234. On these SoCs, interrupts can occur on multiple channels.

memory: tegra: Add MC error logging on Tegra186 onward

Add support for logging memory controller errors on Tegra186, Tegra194
and Tegra234. On these SoCs, interrupts can occur on multiple channels.
Add support required to read the status of interrupts across multiple
channels, log and clear them.

Also add new interrupts supported on these SoCs.

Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Ashish Mhetre <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Add memory controller channels support

From Tegra186 onwards, the memory controller supports multiple channels.
Add support for mapping the address spaces of these channels and specif

memory: tegra: Add memory controller channels support

From Tegra186 onwards, the memory controller supports multiple channels.
Add support for mapping the address spaces of these channels and specify
the number of channels supported by Tegra186, Tegra194 and Tegra234.

In case of old bindings, channels won't be present. If channels are not
present then print a warning and continue so that backward compatibility
will be preserved in driver.

During error interrupts from memory controller, appropriate registers
from these channels need to be accessed for logging error info.

Signed-off-by: Ashish Mhetre <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Add compile-test stub for tegra_mc_probe_device()

The tegra_mc_probe_device() symbol is only available when the TEGRA_MC
Kconfig option is enabled. Provide a stub if that's not the ca

memory: tegra: Add compile-test stub for tegra_mc_probe_device()

The tegra_mc_probe_device() symbol is only available when the TEGRA_MC
Kconfig option is enabled. Provide a stub if that's not the case so that
the driver can be compile-tested.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Implement SID override programming

Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
devic

memory: tegra: Implement SID override programming

Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and programs the SID specified in device tree, which corresponds
to the SID used for the SMMU context banks for the device.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Unify drivers

The Tegra210 (and earlier) driver now supports all the functionality
that the Tegra186 (and later) driver does, so they can be unified.

Note that previously the Tegra18

memory: tegra: Unify drivers

The Tegra210 (and earlier) driver now supports all the functionality
that the Tegra186 (and later) driver does, so they can be unified.

Note that previously the Tegra186 (and later) driver could be unloaded,
even if that was perhaps not very useful. Older chips don't support that
yet, but once they do this code can be reenabled.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Parameterize interrupt handler

Tegra20 requires a slightly different interrupt handler than Tegra30 and
later, so parameterize the handler, so that each SoC implementation can
provide

memory: tegra: Parameterize interrupt handler

Tegra20 requires a slightly different interrupt handler than Tegra30 and
later, so parameterize the handler, so that each SoC implementation can
provide its own.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Make per-SoC setup more generic

The current per-SoC setup code runs at a fairly arbitrary point during
probe, thereby making it less flexible for other SoC generations. Move
the call

memory: tegra: Make per-SoC setup more generic

The current per-SoC setup code runs at a fairly arbitrary point during
probe, thereby making it less flexible for other SoC generations. Move
the call around slightly (after only the very basic, common setup that
applies to all SoC generations has been performed), which will allow
it to be used for other implementations.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Push suspend/resume into SoC drivers

Continuing the scheme of unification, push suspend/resume callbacks into
per-SoC driver so that they can be properly parameterized.

Signed-off-by

memory: tegra: Push suspend/resume into SoC drivers

Continuing the scheme of unification, push suspend/resume callbacks into
per-SoC driver so that they can be properly parameterized.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Introduce struct tegra_mc_ops

Subsequent patches will introduce further callbacks, so create a new
struct tegra_mc_ops to collect all of them in a single place. Move the
existing ->in

memory: tegra: Introduce struct tegra_mc_ops

Subsequent patches will introduce further callbacks, so create a new
struct tegra_mc_ops to collect all of them in a single place. Move the
existing ->init() callback into the new structure.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Unify struct tegra_mc across SoC generations

As another step towards unifying both the Tegra210 (and earlier) and
Tegra186 (and later) memory controller drivers, unify the structures

memory: tegra: Unify struct tegra_mc across SoC generations

As another step towards unifying both the Tegra210 (and earlier) and
Tegra186 (and later) memory controller drivers, unify the structures
that are used to represent them.

Note that this comes at a slight space penalty since some fields are
not used on all generations, but the benefits of unifying the driver
outweigh the downsides.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Consolidate register fields

Subsequent patches will add more register fields to the tegra_mc_client
structure, so consolidate all register field definitions into a common
sub-structur

memory: tegra: Consolidate register fields

Subsequent patches will add more register fields to the tegra_mc_client
structure, so consolidate all register field definitions into a common
sub-structure for coherency.

Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra20: Add debug statistics

Add debug statistics collection support. The statistics is available
via debugfs in '/sys/kernel/debug/mc/stats', it shows percent of memory
controller utilizat

memory: tegra20: Add debug statistics

Add debug statistics collection support. The statistics is available
via debugfs in '/sys/kernel/debug/mc/stats', it shows percent of memory
controller utilization for each memory client. This information is
intended to help with debugging of memory performance issues, it already
was proven to be useful by helping to improve memory bandwidth management
of the display driver.

Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

memory: tegra: Correct stub of devm_tegra_memory_controller_get()

Correct typo in a stub of devm_tegra_memory_controller_get() to fix a
non-ARM kernel compile-testing.

Reported-by: Stephen Rothwell

memory: tegra: Correct stub of devm_tegra_memory_controller_get()

Correct typo in a stub of devm_tegra_memory_controller_get() to fix a
non-ARM kernel compile-testing.

Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra-mc: Add interconnect framework

Add common SoC-agnostic ICC framework which turns Tegra Memory Controller
into a memory interconnection provider. This allows us to use interconnect
API

memory: tegra-mc: Add interconnect framework

Add common SoC-agnostic ICC framework which turns Tegra Memory Controller
into a memory interconnection provider. This allows us to use interconnect
API for tuning of memory configurations.

Signed-off-by: Dmitry Osipenko <[email protected]>
Tested-by: Peter Geis <[email protected]>
Tested-by: Nicolas Chauvet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Add and use devm_tegra_memory_controller_get()

Multiple Tegra drivers need to retrieve Memory Controller and there is
duplication of the retrieval code among the drivers.

Add new dev

memory: tegra: Add and use devm_tegra_memory_controller_get()

Multiple Tegra drivers need to retrieve Memory Controller and there is
duplication of the retrieval code among the drivers.

Add new devm_tegra_memory_controller_get() helper to remove the code's
duplication and to fix put_device() which was missed in the duplicated
code. Make EMC drivers to use the new helper.

Signed-off-by: Dmitry Osipenko <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: tegra: Introduce Tegra30 EMC driver

Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver i

memory: tegra: Introduce Tegra30 EMC driver

Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.

Acked-by: Peter De Schrijver <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Tested-by: Peter Geis <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

iommu/tegra: gart: Integrate with Memory Controller driver

The device-tree binding has been changed. There is no separate GART device
anymore, it is squashed into the Memory Controller. Integrate GA

iommu/tegra: gart: Integrate with Memory Controller driver

The device-tree binding has been changed. There is no separate GART device
anymore, it is squashed into the Memory Controller. Integrate GART module
with the MC in a way it is done for the SMMU on Tegra30+.

Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...