iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
linux/drivers/memory/tegra/tegra114.c

987 lines
16 KiB
C
Raw Normal View History

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 <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04 10:11:33 +02:00
// SPDX-License-Identifier: GPL-2.0-only
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
/*
* Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved.
*/
#include <linux/of.h>
#include <linux/mm.h>
#include <dt-bindings/memory/tegra114-mc.h>
#include "mc.h"
static const struct tegra_mc_client tegra114_mc_clients[] = {
{
.id = 0x00,
.name = "ptcr",
.swgroup = TEGRA_SWGROUP_PTC,
memory: tegra: Add missing latency allowness entry for Page Table Cache Add missing PTC memory client latency allowness entry to the Tegra MC drivers. This prevents erroneous clearing of MC_INTSTATUS 0x0 register during of the LA programming in tegra_mc_setup_latency_allowance() due to the missing entry. Note that this patch doesn't fix any known problems. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20201104164923.21238-32-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-11-04 19:49:07 +03:00
.la = {
.reg = 0x34c,
.shift = 0,
.mask = 0xff,
.def = 0x0,
},
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
}, {
.id = 0x01,
.name = "display0a",
.swgroup = TEGRA_SWGROUP_DC,
.smmu = {
.reg = 0x228,
.bit = 1,
},
.la = {
.reg = 0x2e8,
.shift = 0,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x02,
.name = "display0ab",
.swgroup = TEGRA_SWGROUP_DCB,
.smmu = {
.reg = 0x228,
.bit = 2,
},
.la = {
.reg = 0x2f4,
.shift = 0,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x03,
.name = "display0b",
.swgroup = TEGRA_SWGROUP_DC,
.smmu = {
.reg = 0x228,
.bit = 3,
},
.la = {
.reg = 0x2e8,
.shift = 16,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x04,
.name = "display0bb",
.swgroup = TEGRA_SWGROUP_DCB,
.smmu = {
.reg = 0x228,
.bit = 4,
},
.la = {
.reg = 0x2f4,
.shift = 16,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x05,
.name = "display0c",
.swgroup = TEGRA_SWGROUP_DC,
.smmu = {
.reg = 0x228,
.bit = 5,
},
.la = {
.reg = 0x2ec,
.shift = 0,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x06,
.name = "display0cb",
.swgroup = TEGRA_SWGROUP_DCB,
.smmu = {
.reg = 0x228,
.bit = 6,
},
.la = {
.reg = 0x2f8,
.shift = 0,
.mask = 0xff,
.def = 0x4e,
},
}, {
.id = 0x09,
.name = "eppup",
.swgroup = TEGRA_SWGROUP_EPP,
.smmu = {
.reg = 0x228,
.bit = 9,
},
.la = {
.reg = 0x300,
.shift = 0,
.mask = 0xff,
.def = 0x33,
},
}, {
.id = 0x0a,
.name = "g2pr",
.swgroup = TEGRA_SWGROUP_G2,
.smmu = {
.reg = 0x228,
.bit = 10,
},
.la = {
.reg = 0x308,
.shift = 0,
.mask = 0xff,
.def = 0x09,
},
}, {
.id = 0x0b,
.name = "g2sr",
.swgroup = TEGRA_SWGROUP_G2,
.smmu = {
.reg = 0x228,
.bit = 11,
},
.la = {
.reg = 0x308,
.shift = 16,
.mask = 0xff,
.def = 0x09,
},
}, {
.id = 0x0f,
.name = "avpcarm7r",
.swgroup = TEGRA_SWGROUP_AVPC,
.smmu = {
.reg = 0x228,
.bit = 15,
},
.la = {
.reg = 0x2e4,
.shift = 0,
.mask = 0xff,
.def = 0x04,
},
}, {
.id = 0x10,
.name = "displayhc",
.swgroup = TEGRA_SWGROUP_DC,
.smmu = {
.reg = 0x228,
.bit = 16,
},
.la = {
.reg = 0x2f0,
.shift = 0,
.mask = 0xff,
.def = 0x68,
},
}, {
.id = 0x11,
.name = "displayhcb",
.swgroup = TEGRA_SWGROUP_DCB,
.smmu = {
.reg = 0x228,
.bit = 17,
},
.la = {
.reg = 0x2fc,
.shift = 0,
.mask = 0xff,
.def = 0x68,
},
}, {
.id = 0x12,
.name = "fdcdrd",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x228,
.bit = 18,
},
.la = {
.reg = 0x334,
.shift = 0,
.mask = 0xff,
.def = 0x0c,
},
}, {
.id = 0x13,
.name = "fdcdrd2",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x228,
.bit = 19,
},
.la = {
.reg = 0x33c,
.shift = 0,
.mask = 0xff,
.def = 0x0c,
},
}, {
.id = 0x14,
.name = "g2dr",
.swgroup = TEGRA_SWGROUP_G2,
.smmu = {
.reg = 0x228,
.bit = 20,
},
.la = {
.reg = 0x30c,
.shift = 0,
.mask = 0xff,
.def = 0x0a,
},
}, {
.id = 0x15,
.name = "hdar",
.swgroup = TEGRA_SWGROUP_HDA,
.smmu = {
.reg = 0x228,
.bit = 21,
},
.la = {
.reg = 0x318,
.shift = 0,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x16,
.name = "host1xdmar",
.swgroup = TEGRA_SWGROUP_HC,
.smmu = {
.reg = 0x228,
.bit = 22,
},
.la = {
.reg = 0x310,
.shift = 0,
.mask = 0xff,
.def = 0x10,
},
}, {
.id = 0x17,
.name = "host1xr",
.swgroup = TEGRA_SWGROUP_HC,
.smmu = {
.reg = 0x228,
.bit = 23,
},
.la = {
.reg = 0x310,
.shift = 16,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x18,
.name = "idxsrd",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x228,
.bit = 24,
},
.la = {
.reg = 0x334,
.shift = 16,
.mask = 0xff,
.def = 0x0b,
},
}, {
.id = 0x1c,
.name = "msencsrd",
.swgroup = TEGRA_SWGROUP_MSENC,
.smmu = {
.reg = 0x228,
.bit = 28,
},
.la = {
.reg = 0x328,
.shift = 0,
.mask = 0xff,
.def = 0x80,
},
}, {
.id = 0x1d,
.name = "ppcsahbdmar",
.swgroup = TEGRA_SWGROUP_PPCS,
.smmu = {
.reg = 0x228,
.bit = 29,
},
.la = {
.reg = 0x344,
.shift = 0,
.mask = 0xff,
.def = 0x50,
},
}, {
.id = 0x1e,
.name = "ppcsahbslvr",
.swgroup = TEGRA_SWGROUP_PPCS,
.smmu = {
.reg = 0x228,
.bit = 30,
},
.la = {
.reg = 0x344,
.shift = 16,
.mask = 0xff,
.def = 0xe8,
},
}, {
.id = 0x20,
.name = "texl2srd",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x22c,
.bit = 0,
},
.la = {
.reg = 0x338,
.shift = 0,
.mask = 0xff,
.def = 0x0c,
},
}, {
.id = 0x22,
.name = "vdebsevr",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 2,
},
.la = {
.reg = 0x354,
.shift = 0,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x23,
.name = "vdember",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 3,
},
.la = {
.reg = 0x354,
.shift = 16,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x24,
.name = "vdemcer",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 4,
},
.la = {
.reg = 0x358,
.shift = 0,
.mask = 0xff,
.def = 0xb8,
},
}, {
.id = 0x25,
.name = "vdetper",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 5,
},
.la = {
.reg = 0x358,
.shift = 16,
.mask = 0xff,
.def = 0xee,
},
}, {
.id = 0x26,
.name = "mpcorelpr",
.swgroup = TEGRA_SWGROUP_MPCORELP,
.la = {
.reg = 0x324,
.shift = 0,
.mask = 0xff,
.def = 0x04,
},
}, {
.id = 0x27,
.name = "mpcorer",
.swgroup = TEGRA_SWGROUP_MPCORE,
.la = {
.reg = 0x320,
.shift = 0,
.mask = 0xff,
.def = 0x04,
},
}, {
.id = 0x28,
.name = "eppu",
.swgroup = TEGRA_SWGROUP_EPP,
.smmu = {
.reg = 0x22c,
.bit = 8,
},
.la = {
.reg = 0x300,
.shift = 16,
.mask = 0xff,
.def = 0x33,
},
}, {
.id = 0x29,
.name = "eppv",
.swgroup = TEGRA_SWGROUP_EPP,
.smmu = {
.reg = 0x22c,
.bit = 9,
},
.la = {
.reg = 0x304,
.shift = 0,
.mask = 0xff,
.def = 0x6c,
},
}, {
.id = 0x2a,
.name = "eppy",
.swgroup = TEGRA_SWGROUP_EPP,
.smmu = {
.reg = 0x22c,
.bit = 10,
},
.la = {
.reg = 0x304,
.shift = 16,
.mask = 0xff,
.def = 0x6c,
},
}, {
.id = 0x2b,
.name = "msencswr",
.swgroup = TEGRA_SWGROUP_MSENC,
.smmu = {
.reg = 0x22c,
.bit = 11,
},
.la = {
.reg = 0x328,
.shift = 16,
.mask = 0xff,
.def = 0x80,
},
}, {
.id = 0x2c,
.name = "viwsb",
.swgroup = TEGRA_SWGROUP_VI,
.smmu = {
.reg = 0x22c,
.bit = 12,
},
.la = {
.reg = 0x364,
.shift = 0,
.mask = 0xff,
.def = 0x47,
},
}, {
.id = 0x2d,
.name = "viwu",
.swgroup = TEGRA_SWGROUP_VI,
.smmu = {
.reg = 0x22c,
.bit = 13,
},
.la = {
.reg = 0x368,
.shift = 0,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x2e,
.name = "viwv",
.swgroup = TEGRA_SWGROUP_VI,
.smmu = {
.reg = 0x22c,
.bit = 14,
},
.la = {
.reg = 0x368,
.shift = 16,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x2f,
.name = "viwy",
.swgroup = TEGRA_SWGROUP_VI,
.smmu = {
.reg = 0x22c,
.bit = 15,
},
.la = {
.reg = 0x36c,
.shift = 0,
.mask = 0xff,
.def = 0x47,
},
}, {
.id = 0x30,
.name = "g2dw",
.swgroup = TEGRA_SWGROUP_G2,
.smmu = {
.reg = 0x22c,
.bit = 16,
},
.la = {
.reg = 0x30c,
.shift = 16,
.mask = 0xff,
.def = 0x9,
},
}, {
.id = 0x32,
.name = "avpcarm7w",
.swgroup = TEGRA_SWGROUP_AVPC,
.smmu = {
.reg = 0x22c,
.bit = 18,
},
.la = {
.reg = 0x2e4,
.shift = 16,
.mask = 0xff,
.def = 0x0e,
},
}, {
.id = 0x33,
.name = "fdcdwr",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x22c,
.bit = 19,
},
.la = {
.reg = 0x338,
.shift = 16,
.mask = 0xff,
.def = 0x10,
},
}, {
.id = 0x34,
memory: tegra: Fix a typos for "fdcdwr2" mc client Fix typo for fdcwr2 to fdcdwr2 to match the TRM. Signed-off-by: Edward Cragg <drq.11235@gmail.com> Signed-off-by: Kejia Hu <kejia.hu@codethink.co.uk> Acked-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-03-08 11:21:55 +00:00
.name = "fdcdwr2",
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x22c,
.bit = 20,
},
.la = {
.reg = 0x340,
.shift = 0,
.mask = 0xff,
.def = 0x10,
},
}, {
.id = 0x35,
.name = "hdaw",
.swgroup = TEGRA_SWGROUP_HDA,
.smmu = {
.reg = 0x22c,
.bit = 21,
},
.la = {
.reg = 0x318,
.shift = 16,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x36,
.name = "host1xw",
.swgroup = TEGRA_SWGROUP_HC,
.smmu = {
.reg = 0x22c,
.bit = 22,
},
.la = {
.reg = 0x314,
.shift = 0,
.mask = 0xff,
.def = 0x25,
},
}, {
.id = 0x37,
.name = "ispw",
.swgroup = TEGRA_SWGROUP_ISP,
.smmu = {
.reg = 0x22c,
.bit = 23,
},
.la = {
.reg = 0x31c,
.shift = 0,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x38,
.name = "mpcorelpw",
.swgroup = TEGRA_SWGROUP_MPCORELP,
.la = {
.reg = 0x324,
.shift = 16,
.mask = 0xff,
.def = 0x80,
},
}, {
.id = 0x39,
.name = "mpcorew",
.swgroup = TEGRA_SWGROUP_MPCORE,
.la = {
.reg = 0x320,
.shift = 16,
.mask = 0xff,
.def = 0x0e,
},
}, {
.id = 0x3b,
.name = "ppcsahbdmaw",
.swgroup = TEGRA_SWGROUP_PPCS,
.smmu = {
.reg = 0x22c,
.bit = 27,
},
.la = {
.reg = 0x348,
.shift = 0,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x3c,
.name = "ppcsahbslvw",
.swgroup = TEGRA_SWGROUP_PPCS,
.smmu = {
.reg = 0x22c,
.bit = 28,
},
.la = {
.reg = 0x348,
.shift = 16,
.mask = 0xff,
.def = 0xe8,
},
}, {
.id = 0x3e,
.name = "vdebsevw",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 30,
},
.la = {
.reg = 0x35c,
.shift = 0,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x3f,
.name = "vdedbgw",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x22c,
.bit = 31,
},
.la = {
.reg = 0x35c,
.shift = 16,
.mask = 0xff,
.def = 0xff,
},
}, {
.id = 0x40,
.name = "vdembew",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x230,
.bit = 0,
},
.la = {
.reg = 0x360,
.shift = 0,
.mask = 0xff,
.def = 0x89,
},
}, {
.id = 0x41,
.name = "vdetpmw",
.swgroup = TEGRA_SWGROUP_VDE,
.smmu = {
.reg = 0x230,
.bit = 1,
},
.la = {
.reg = 0x360,
.shift = 16,
.mask = 0xff,
.def = 0x59,
},
}, {
.id = 0x4a,
.name = "xusb_hostr",
.swgroup = TEGRA_SWGROUP_XUSB_HOST,
.smmu = {
.reg = 0x230,
.bit = 10,
},
.la = {
.reg = 0x37c,
.shift = 0,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x4b,
.name = "xusb_hostw",
.swgroup = TEGRA_SWGROUP_XUSB_HOST,
.smmu = {
.reg = 0x230,
.bit = 11,
},
.la = {
.reg = 0x37c,
.shift = 16,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x4c,
.name = "xusb_devr",
.swgroup = TEGRA_SWGROUP_XUSB_DEV,
.smmu = {
.reg = 0x230,
.bit = 12,
},
.la = {
.reg = 0x380,
.shift = 0,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x4d,
.name = "xusb_devw",
.swgroup = TEGRA_SWGROUP_XUSB_DEV,
.smmu = {
.reg = 0x230,
.bit = 13,
},
.la = {
.reg = 0x380,
.shift = 16,
.mask = 0xff,
.def = 0xa5,
},
}, {
.id = 0x4e,
.name = "fdcdwr3",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x230,
.bit = 14,
},
.la = {
.reg = 0x388,
.shift = 0,
.mask = 0xff,
.def = 0x10,
},
}, {
.id = 0x4f,
.name = "fdcdrd3",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x230,
.bit = 15,
},
.la = {
.reg = 0x384,
.shift = 0,
.mask = 0xff,
.def = 0x0c,
},
}, {
.id = 0x50,
.name = "fdcwr4",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x230,
.bit = 16,
},
.la = {
.reg = 0x388,
.shift = 16,
.mask = 0xff,
.def = 0x10,
},
}, {
.id = 0x51,
.name = "fdcrd4",
.swgroup = TEGRA_SWGROUP_NV,
.smmu = {
.reg = 0x230,
.bit = 17,
},
.la = {
.reg = 0x384,
.shift = 16,
.mask = 0xff,
.def = 0x0c,
},
}, {
.id = 0x52,
.name = "emucifr",
.swgroup = TEGRA_SWGROUP_EMUCIF,
.la = {
.reg = 0x38c,
.shift = 0,
.mask = 0xff,
.def = 0x04,
},
}, {
.id = 0x53,
.name = "emucifw",
.swgroup = TEGRA_SWGROUP_EMUCIF,
.la = {
.reg = 0x38c,
.shift = 16,
.mask = 0xff,
.def = 0x0e,
},
}, {
.id = 0x54,
.name = "tsecsrd",
.swgroup = TEGRA_SWGROUP_TSEC,
.smmu = {
.reg = 0x230,
.bit = 20,
},
.la = {
.reg = 0x390,
.shift = 0,
.mask = 0xff,
.def = 0x50,
},
}, {
.id = 0x55,
.name = "tsecswr",
.swgroup = TEGRA_SWGROUP_TSEC,
.smmu = {
.reg = 0x230,
.bit = 21,
},
.la = {
.reg = 0x390,
.shift = 16,
.mask = 0xff,
.def = 0x50,
},
},
};
static const struct tegra_smmu_swgroup tegra114_swgroups[] = {
memory: tegra: Add SWGROUP names Subsequent patches will add debugfs files that print the status of the SWGROUPs. Add a new names field and complement the SoC tables with the names of the individual SWGROUPs. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-23 09:45:35 +01:00
{ .name = "dc", .swgroup = TEGRA_SWGROUP_DC, .reg = 0x240 },
{ .name = "dcb", .swgroup = TEGRA_SWGROUP_DCB, .reg = 0x244 },
{ .name = "epp", .swgroup = TEGRA_SWGROUP_EPP, .reg = 0x248 },
{ .name = "g2", .swgroup = TEGRA_SWGROUP_G2, .reg = 0x24c },
{ .name = "avpc", .swgroup = TEGRA_SWGROUP_AVPC, .reg = 0x23c },
{ .name = "nv", .swgroup = TEGRA_SWGROUP_NV, .reg = 0x268 },
{ .name = "hda", .swgroup = TEGRA_SWGROUP_HDA, .reg = 0x254 },
{ .name = "hc", .swgroup = TEGRA_SWGROUP_HC, .reg = 0x250 },
{ .name = "msenc", .swgroup = TEGRA_SWGROUP_MSENC, .reg = 0x264 },
{ .name = "ppcs", .swgroup = TEGRA_SWGROUP_PPCS, .reg = 0x270 },
{ .name = "vde", .swgroup = TEGRA_SWGROUP_VDE, .reg = 0x27c },
{ .name = "vi", .swgroup = TEGRA_SWGROUP_VI, .reg = 0x280 },
{ .name = "isp", .swgroup = TEGRA_SWGROUP_ISP, .reg = 0x258 },
{ .name = "xusb_host", .swgroup = TEGRA_SWGROUP_XUSB_HOST, .reg = 0x288 },
{ .name = "xusb_dev", .swgroup = TEGRA_SWGROUP_XUSB_DEV, .reg = 0x28c },
{ .name = "tsec", .swgroup = TEGRA_SWGROUP_TSEC, .reg = 0x294 },
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
};
memory: tegra: Add gr2d and gr3d to DRM IOMMU group All of the devices making up the Tegra DRM device want to share a single IOMMU domain. Put them into a single group to allow them to do that. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28 13:37:07 +01:00
static const unsigned int tegra114_group_drm[] = {
memory: tegra: Create SMMU display groups Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210. This allows the display controllers on these devices to share the same IOMMU domain using the standard IOMMU group mechanism. Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-10-12 16:29:19 +02:00
TEGRA_SWGROUP_DC,
TEGRA_SWGROUP_DCB,
memory: tegra: Add gr2d and gr3d to DRM IOMMU group All of the devices making up the Tegra DRM device want to share a single IOMMU domain. Put them into a single group to allow them to do that. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28 13:37:07 +01:00
TEGRA_SWGROUP_G2,
TEGRA_SWGROUP_NV,
memory: tegra: Create SMMU display groups Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210. This allows the display controllers on these devices to share the same IOMMU domain using the standard IOMMU group mechanism. Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-10-12 16:29:19 +02:00
};
static const struct tegra_smmu_group_soc tegra114_groups[] = {
{
memory: tegra: Add gr2d and gr3d to DRM IOMMU group All of the devices making up the Tegra DRM device want to share a single IOMMU domain. Put them into a single group to allow them to do that. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28 13:37:07 +01:00
.name = "drm",
.swgroups = tegra114_group_drm,
.num_swgroups = ARRAY_SIZE(tegra114_group_drm),
memory: tegra: Create SMMU display groups Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210. This allows the display controllers on these devices to share the same IOMMU domain using the standard IOMMU group mechanism. Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-10-12 16:29:19 +02:00
},
};
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
static const struct tegra_smmu_soc tegra114_smmu_soc = {
.clients = tegra114_mc_clients,
.num_clients = ARRAY_SIZE(tegra114_mc_clients),
.swgroups = tegra114_swgroups,
.num_swgroups = ARRAY_SIZE(tegra114_swgroups),
memory: tegra: Create SMMU display groups Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210. This allows the display controllers on these devices to share the same IOMMU domain using the standard IOMMU group mechanism. Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-10-12 16:29:19 +02:00
.groups = tegra114_groups,
.num_groups = ARRAY_SIZE(tegra114_groups),
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
.supports_round_robin_arbitration = false,
.supports_request_limit = false,
iommu/tegra-smmu: Parameterize number of TLB lines The number of TLB lines was increased from 16 on Tegra30 to 32 on Tegra114 and later. Parameterize the value so that the initial default can be set accordingly. On Tegra30, initializing the value to 32 would effectively disable the TLB and hence cause massive latencies for memory accesses translated through the SMMU. This is especially noticeable for isochronuous clients such as display, whose FIFOs would continuously underrun. Fixes: 891846516317 ("memory: Add NVIDIA Tegra memory controller support") Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-08-06 14:20:31 +02:00
.num_tlb_lines = 32,
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
.num_asids = 4,
};
memory: tegra: Add Tegra114 memory controller hot resets Define the table of memory controller hot resets for Tegra114. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-13 14:33:52 +03:00
#define TEGRA114_MC_RESET(_name, _control, _status, _bit) \
{ \
.name = #_name, \
.id = TEGRA114_MC_RESET_##_name, \
.control = _control, \
.status = _status, \
.bit = _bit, \
}
static const struct tegra_mc_reset tegra114_mc_resets[] = {
TEGRA114_MC_RESET(AVPC, 0x200, 0x204, 1),
TEGRA114_MC_RESET(DC, 0x200, 0x204, 2),
TEGRA114_MC_RESET(DCB, 0x200, 0x204, 3),
TEGRA114_MC_RESET(EPP, 0x200, 0x204, 4),
TEGRA114_MC_RESET(2D, 0x200, 0x204, 5),
TEGRA114_MC_RESET(HC, 0x200, 0x204, 6),
TEGRA114_MC_RESET(HDA, 0x200, 0x204, 7),
TEGRA114_MC_RESET(ISP, 0x200, 0x204, 8),
TEGRA114_MC_RESET(MPCORE, 0x200, 0x204, 9),
TEGRA114_MC_RESET(MPCORELP, 0x200, 0x204, 10),
TEGRA114_MC_RESET(MPE, 0x200, 0x204, 11),
TEGRA114_MC_RESET(3D, 0x200, 0x204, 12),
TEGRA114_MC_RESET(3D2, 0x200, 0x204, 13),
TEGRA114_MC_RESET(PPCS, 0x200, 0x204, 14),
TEGRA114_MC_RESET(VDE, 0x200, 0x204, 16),
TEGRA114_MC_RESET(VI, 0x200, 0x204, 17),
};
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
const struct tegra_mc_soc tegra114_mc_soc = {
.clients = tegra114_mc_clients,
.num_clients = ARRAY_SIZE(tegra114_mc_clients),
.num_address_bits = 32,
.atom_size = 32,
memory: tegra: Add support for a variable-size client ID bitfield Recent versions of the Tegra MC hardware extend the size of the client ID bitfield in the MC_ERR_STATUS register by one bit. While one could simply extend the bitfield for older hardware, that would allow data from reserved bits into the driver code, which is generally a bad idea on principle. So this patch instead passes in the client ID mask from from the per-SoC MC data. There's no MC support for T210 (yet), but when that support winds up in the kernel, the appropriate soc->client_id_mask value for that chip will be 0xff. Based on an original patch by David Ung <davidu@nvidia.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Paul Walmsley <pwalmsley@nvidia.com> Cc: Thierry Reding <treding@nvidia.com> Cc: David Ung <davidu@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-06-04 19:33:48 +00:00
.client_id_mask = 0x7f,
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
.smmu = &tegra114_smmu_soc,
memory: tegra: Apply interrupts mask per SoC Currently we are enabling handling of interrupts specific to Tegra124+ which happen to overlap with previous generations. Let's specify interrupts mask per SoC generation for consistency and in a preparation of squashing of Tegra20 driver into the common one that will enable handling of GART faults which may be undesirable by newer generations. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-09 22:28:29 +03:00
.intmask = MC_INT_INVALID_SMMU_PAGE | MC_INT_SECURITY_VIOLATION |
MC_INT_DECERR_EMEM,
memory: tegra: Properly spell "tegra" Rename all occurrences of "terga" to "tegra". It's an easy typo to make and a difficult one to spot. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-11 10:48:25 +02:00
.reset_ops = &tegra_mc_reset_ops_common,
memory: tegra: Add Tegra114 memory controller hot resets Define the table of memory controller hot resets for Tegra114. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-13 14:33:52 +03:00
.resets = tegra114_mc_resets,
.num_resets = ARRAY_SIZE(tegra114_mc_resets),
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 09:24:44 +02:00
};
Reference in New Issue Copy Permalink