memory: tegra-mc: simplify with scoped for each OF child loop

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Reviewed-by: Jonathan Cameron <

memory: tegra-mc: simplify with scoped for each OF child loop

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Reviewed-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/20240816-cleanup-h-of-node-put-memory-v2-7-9eed0ee16b78@linaro.org
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

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 ...

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: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that

memory: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[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: fix interconnect registration race

The current interconnect provider registration interface is inherently
racy as nodes are not added until the after adding the provider. This
can spe

memory: tegra: fix interconnect registration race

The current interconnect provider registration interface is inherently
racy as nodes are not added until the after adding the provider. This
can specifically cause racing DT lookups to fail.

Switch to using the new API where the provider is not registered until
after it has been fully initialised.

Fixes: 06f079816d4c ("memory: tegra-mc: Add interconnect framework")
Cc: [email protected] # 5.11
Cc: Dmitry Osipenko <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>

show more ...

memory: tegra: remove MODULE_LICENSE in non-modules

Since commit 8b41fc4454e3 ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to

memory: tegra: remove MODULE_LICENSE in non-modules

Since commit 8b41fc4454e3 ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <[email protected]>
Suggested-by: Luis Chamberlain <[email protected]>
Cc: Hitomi Hasegawa <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Jonathan Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[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 Tegra234 support

The memory controller and external memory controller found on Tegra234
is similar to the version found on earlier SoCs but supports a number of
new memory clients

memory: tegra: Add Tegra234 support

The memory controller and external memory controller found on Tegra234
is similar to the version found on earlier SoCs but supports a number of
new memory clients.

Add initial memory client definitions for the Tegra234 so that the SMMU
stream ID override registers can be properly programmed at boot time.

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: mc: simplify platform_get_resource()

Use devm_platform_ioremap_resource() instead of platform_get_resource()
and devm_ioremap_resource().

Signed-off-by: Krzysztof Kozlowski <krzyszto

memory: tegra: mc: simplify platform_get_resource()

Use devm_platform_ioremap_resource() instead of platform_get_resource()
and devm_ioremap_resource().

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

show more ...

memory: tegra: Make use of the helper function devm_add_action_or_reset()

Use devm_add_action_or_reset() instead of devm_add_action() to simplify
the error handling.

Signed-off-by: Cai Huoqing <cai

memory: tegra: Make use of the helper function devm_add_action_or_reset()

Use devm_add_action_or_reset() instead of devm_add_action() to simplify
the error handling.

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

show more ...

memory: tegra: Remove interconnect state syncing hack

State syncing works properly now, previously the sync callback was never
invoked. Apparently it was fixed in drivers core, so let's remove the
h

memory: tegra: Remove interconnect state syncing hack

State syncing works properly now, previously the sync callback was never
invoked. Apparently it was fixed in drivers core, so let's remove the
hack. The state won't be synced until all consumer drivers of devices
that reference memory controller in a device-tree are probed, i.e. keeping
bandwidth at maximum until both display and devfreq drivers are probed.

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: 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: Only initialize reset controller if available

The memory controller hot resets are implemented in the BPMP on Tegra186
and later, so there's no need to provide an implementation via t

memory: tegra: Only initialize reset controller if available

The memory controller hot resets are implemented in the BPMP on Tegra186
and later, so there's no need to provide an implementation via the
memory controller driver. Conditionally register the reset controller
only if needed.

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 IRQ support opitonal

Make IRQ support optional to help unify the Tegra186 memory controller
driver with this one.

Signed-off-by: Thierry Reding <[email protected]>
Link: https:

memory: tegra: Make IRQ support opitonal

Make IRQ support optional to help unify the Tegra186 memory controller
driver with this one.

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: Extract setup code into callback

Separate the setup code for Tegra30 and later into a ->setup() callback
and set it for all applicable chips.

Signed-off-by: Thierry Reding <treding@n

memory: tegra: Extract setup code into callback

Separate the setup code for Tegra30 and later into a ->setup() callback
and set it for all applicable chips.

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: 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 ...