The PCIe host controller found on Tegra20 has a hardware bug that causes
PCIe interrupts to get lost when LP2 is enabled. Stub out the workaround
on 64-bit ARM because none of the more recent Tegra SoC generations seem
to have this bug anymore.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implements generic PM domain support on top of the existing Tegra power-
gate API. Drivers are thus allowed to move away from the Tegra-specific
API and towards using generic power domains directly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXI3unAAoJEN0jrNd/PrOhdPIP/jOgS5Qf1u8QelFvPbsXouRf
xpBy9sa43oow8f+0RVjTrsWDikjniCYcGDPZbfgmXEN5sWYK2xBIZeaMysGezPXS
/g9VnxU0HZsQ+5AOWHS/vxYLfB9Q6g3w4P7XDDzKmJ9mFaLeyNR4ulGWwLxpeF/1
au38f/dXgjU9I+NwXJWhTEspQrXAshIwp6lsQkjcpLmAMeFBOjB7c92uTYmVXI9F
XtGcpGmIqDwRaieY1lqE0iGUMgox2XG2bKgNuwZ+Eng+ICz2ACuGfyH7hwCeWJpK
HByxL83aA9a+G8KIsPZgJYTCuQA7UVYjWp5A5UqpuhsP7Da4EagX3Bdvcwqy/sgk
rcLNSTuksbJyHT/yQO5cj9lPrdFckSglChZlSRX1J5FhQN2xHw/1CmfDgPmZ1Htt
D+66iLm3lJ+SZlwaZToofU89GYRc+GoZVPQrMBMCwTIBcYf6ACtG7hYIB6JrxHJg
xyiSbDKRYyHBWHoL534G2S8xtnTjMHG1RLD2SoI49Qsa9OTmJz50NainElPi2DX5
266zz87Fa+5WePEp0NjBIJ0Hgq4uoMJFpvkG2pzODb2fwHxzW7E/KB6pAV9/+1EZ
F+sPDHUnzTSLx76h7vs1v4ye9TXrcuKXXnhU7YBm6eWCgeM3GOf6V8u7z6BQDxxT
rAYhbGOeeAiORGdMUo4h
=oeBF
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.7-genpd' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
Merge "soc/tegra: Add generic PM domain support" from Thierry Reding:
Implements generic PM domain support on top of the existing Tegra power-
gate API. Drivers are thus allowed to move away from the Tegra-specific
API and towards using generic power domains directly.
* tag 'tegra-for-4.7-genpd' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: pmc: Add generic PM domain support
dt-bindings: Add power domain info for NVIDIA PMC
This set of patches adds support for the Tegra XUSB pad controller. The
controller provides a set of pads (lanes) that are used for I/O by other
IP blocks within Tegra SoCs (PCIe, SATA and XUSB).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXI3hiAAoJEN0jrNd/PrOhSeIP/0ziDYSAgTbB30L2CJNLnyp3
xnbn6YHLsZVcwD4Pxlu9TW2z4iqCz3BU7Glbv0zc8tGGW9OzaPPH2M/+Vl8neM5O
fRaP/hd2FlW9leiPU/xNU4gdGycRuk94clxObNtS8g3qKxl2KsQeZBWiMfIPsJRE
IvK57SmLtznDgigtV2xJjH90OkwycAWQBi6r7pcttnLWB5qAEkMl0EnVz35q6EOM
8EXOSjMATdrxRwE3FjRDzzSWPUpRHG61DC4krMpo8VgHXyqUdR1o5VwxEPIBcL3W
td/oPZrUNAa7z/IoSdH9SD9IEc1OIwZOmcwFkOsFjFRn118gx+RE7pd8QkvKaCGU
CDfqHS76pgOrnHOLWCtuYMagrPtwI2H8KOqx2VOLdKQghez1ykk0gCpKqp5CLGC1
G4VQp1jK7y4dB97K3C5/8WfntNSczE+kb61B3Q3gHKaP8GfvBtdhGfP+POXwp4bC
rrw8kienv3sws11GTZXMHhQWVGgbWxenPh+Fjj43fnI8YSoweC9xErWmxQyUYcov
xv+ryi+BoGyr36IbX2dng7peRzgxGadMRFwOJ0EVBw27nGZNuULwgtFSgYcCTZRY
6wJKxGX8EWpI034LVyhbrPy34cIFTSkzZCeYvENWzPNCw7y+bC7hjBewPMPDNF7U
63BEtuIczTyzgUjcav+s
=JRT5
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.7-phy' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
Merge "phy: tegra: Changes for v4.7-rc1" from Thierry Reding:
This set of patches adds support for the Tegra XUSB pad controller. The
controller provides a set of pads (lanes) that are used for I/O by other
IP blocks within Tegra SoCs (PCIe, SATA and XUSB).
* tag 'tegra-for-4.7-phy' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
phy: tegra: Add Tegra210 support
phy: Add Tegra XUSB pad controller support
dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
phy: core: Allow children node to be overridden
clk: tegra: Add interface to enable hardware control of SATA/XUSB PLLs
Adds generic PM domain support to the PMC driver where the PM domains
are populated from device-tree and the PM domain consumer devices are
bound to their relevant PM domains via device-tree as well.
Update the tegra_powergate_sequence_power_up() API so that internally
it calls the same tegra_powergate_xxx functions that are used by the
Tegra generic PM domain code for consistency.
To ensure that the Tegra power domains (a.k.a. powergates) cannot be
controlled via both the legacy tegra_powergate_xxx functions as well
as the generic PM domain framework, add a bit map for available
powergates that can be controlled via the legacy powergate functions.
Move the majority of the tegra_powergate_remove_clamping() function
to a sub-function, so that this can be used by both the legacy and
generic power domain code.
This is based upon work by Thierry Reding <treding@nvidia.com>
and Vince Hsu <vinceh@nvidia.com>.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for the XUSB pad controller found on Tegra210 SoCs. The
hardware is roughly the same, but some of the registers have been moved
around and the number and type of supported pads has changed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra powergate and rail IDs are always positive values and so change
the type to be unsigned and remove the tests to see if the ID is less
than zero. Update the Tegra DC powergate type to be an unsigned as well.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This time the IOMMU updates are mostly cleanups or fixes. No big new
features or drivers this time. In particular the changes include:
* Bigger cleanup of the Domain<->IOMMU data structures and the
code that manages them in the Intel VT-d driver. This makes
the code easier to understand and maintain, and also easier to
keep the data structures in sync. It is also a preparation
step to make use of default domains from the IOMMU core in the
Intel VT-d driver.
* Fixes for a couple of DMA-API misuses in ARM IOMMU drivers,
namely in the ARM and Tegra SMMU drivers.
* Fix for a potential buffer overflow in the OMAP iommu driver's
debug code
* A couple of smaller fixes and cleanups in various drivers
* One small new feature: Report domain-id usage in the Intel
VT-d driver to easier detect bugs where these are leaked.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJV7sCEAAoJECvwRC2XARrjz3YP/Au4IIfqykfPvmI0cmPhVnAV
Q72tltwkbK2u2iP+pHheveaMngJtAshsZrnhBon4KJRIt/KTLZQvsFplHDaRhPfY
yw3LIxhC5kLG/S6irY9Ozb0+uTMdQ3BU2uS23pyoFVfCz+RngBrAwDBcTKqZDCDG
8dNd+T21XlzxuyeGr58h9upz2VFtq6feoGFhLU5PNxTlf4JWZe77D7NlbSvx6Nwy
7Ai8dVRgpV9ciUP7w8FXrCUvbMZQDIoTMiWGNSlogVMgA0dllGES91UZYhWf3pil
abuX6DeFul/cOhEOnH2xa+j5zz2O/upe9stU4wAFw6IhPiAELTHc2NKlWAhwb0SY
bpDRf7dgLnUfqpmZLpWjTwN4jllc0qS2MIHj+eUu0uhdFi4Z0BuH2wSCdbR7xkqk
u5u0Jq7hDNKs5FmQTSsWSiAdjakMsRjIN7jMrBbOeZnBSmUnLx74KGPLTb63ncR3
WIOi4Iyu+LSXBIvZDiLu3lIIh7Atzd+y7IDnb8KXdyqfy+h53OZZOJNbP/qTWHgT
ZUdm/qrqjIQpTQfleOEadC7vY/y3fR5sBtOQHUamfntni3oYCc4AMRlNdf3eV9lb
Tyss6F699mU7d/vennTaIToBgVwaXdLYtmvGWjnoT/kqOMclyDf3cIUtZGtp2rJR
ddmzDA3vBUC5pGj8Hd8R
=yoGE
-----END PGP SIGNATURE-----
Merge tag 'iommu-updates-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu updates for from Joerg Roedel:
"This time the IOMMU updates are mostly cleanups or fixes. No big new
features or drivers this time. In particular the changes include:
- Bigger cleanup of the Domain<->IOMMU data structures and the code
that manages them in the Intel VT-d driver. This makes the code
easier to understand and maintain, and also easier to keep the data
structures in sync. It is also a preparation step to make use of
default domains from the IOMMU core in the Intel VT-d driver.
- Fixes for a couple of DMA-API misuses in ARM IOMMU drivers, namely
in the ARM and Tegra SMMU drivers.
- Fix for a potential buffer overflow in the OMAP iommu driver's
debug code
- A couple of smaller fixes and cleanups in various drivers
- One small new feature: Report domain-id usage in the Intel VT-d
driver to easier detect bugs where these are leaked"
* tag 'iommu-updates-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (83 commits)
iommu/vt-d: Really use upper context table when necessary
x86/vt-d: Fix documentation of DRHD
iommu/fsl: Really fix init section(s) content
iommu/io-pgtable-arm: Unmap and free table when overwriting with block
iommu/io-pgtable-arm: Move init-fn declarations to io-pgtable.h
iommu/msm: Use BUG_ON instead of if () BUG()
iommu/vt-d: Access iomem correctly
iommu/vt-d: Make two functions static
iommu/vt-d: Use BUG_ON instead of if () BUG()
iommu/vt-d: Return false instead of 0 in irq_remapping_cap()
iommu/amd: Use BUG_ON instead of if () BUG()
iommu/amd: Make a symbol static
iommu/amd: Simplify allocation in irq_remapping_alloc()
iommu/tegra-smmu: Parameterize number of TLB lines
iommu/tegra-smmu: Factor out tegra_smmu_set_pde()
iommu/tegra-smmu: Extract tegra_smmu_pte_get_use()
iommu/tegra-smmu: Use __GFP_ZERO to allocate zeroed pages
iommu/tegra-smmu: Remove PageReserved manipulation
iommu/tegra-smmu: Convert to use DMA API
iommu/tegra-smmu: smmu_flush_ptc() wants device addresses
...
Adds support for Tegra210, which allows the SMMU to be used on this new
SoC generation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVzfK2AAoJEN0jrNd/PrOhR2cP/RYqGcXQMbHPnDY4Za7dXtGW
nG+NFNLBdVsyPk7ol9p1WRNKVkWSObJ4RN669CyRbk6JvBf7xYXSp9i0mh7FSMow
WBCk3sraN8L8txXOYMnut2+b/3xNGrVxgh8RmQ4aRZY+UDMXlX+cAyuEBhGTDR1G
N0KhIO3SYDGRMCJ6w3sV0lT+Ac0I5+iG94kRxoqyaO/mi/EA3I3rOaYaiHujCQxJ
1LrQAY35NTC0Pwsdqq7ivPEHkL9Ki4/rvPnVocZea4H+MSZ/gTSHpe7rPOF4vGPS
imERpyN4eJwZlQnOC8ism3TQPHGiKux8xEtNBV76IHmB27O7A+cJhQWFzdKGQpGB
tMcqyr5aJGFwJ2Rba0NKo61xyIqXgE4pW85DKAuN6cnWlZ5+J8Mjv5788tMShwMI
aMPm3na6gtiH2zhkE0MEt0qizDM9BUnlF3be5gVQejr4jNDOFe62opvyzq42iO2z
8NQ9amgMQXfwql7Wr6T+Fa5VgTPRS2VEjf7knJaYFXVih5nP5SGK6fvkLIb2MN07
DKZ5rbrXBxx4kpZiftnE1wPwQC6EHg5FT+4MDW877Lw1dbDllM179cOgRJowLo0G
zkPOvHKiQFLx/32MZJfXp5vbDeX11Q2LOgNc+/D46dSm7ElnuEXylnc4vOuvFDU9
AkuPLVT4wos1SsvtL8v6
=H73u
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.3-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
ARM: tegra: Memory controller updates for v4.3-rc1
Adds support for Tegra210, which allows the SMMU to be used on this new
SoC generation.
* tag 'tegra-for-4.3-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
memory: tegra: Add Tegra210 support
memory: tegra: Add support for a variable-size client ID bitfield
memory: tegra: Expose supported rates via debugfs
Signed-off-by: Olof Johansson <olof@lixom.net>
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: 8918465163 ("memory: Add NVIDIA Tegra memory controller support")
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
Drivers should not be using __cpuc_* functions nor outer_cache_flush()
directly. This change partly cleans up tegra-smmu.c.
The only difference between cache handling of the tegra variants is
Denver, which omits the call to outer_cache_flush(). This is due to
Denver being an ARM64 CPU, and the ARM64 architecture does not provide
this function. (This, in itself, is a good reason why these should not
be used.)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[treding@nvidia.com: fix build failure on 64-bit ARM]
Signed-off-by: Thierry Reding <treding@nvidia.com>
There's a mixture of core_* and soc_* prefixes for variables storing
information related to the VDD_CORE rail. Choose one (soc_*) and use it
more consistently.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra210 uses a power management controller that is compatible with
earlier SoC generations but adds a couple of power partitions for new
hardware blocks.
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some of these are for drivers/soc, where we're now putting
SoC-specific drivers these days. Some are for other driver subsystems
where we have received acks from the appropriate maintainers.
Some highlights:
- simple-mfd: document DT bindings and misc updates
- migrate mach-berlin to simple-mfd for clock, pinctrl and reset
- memory: support for Tegra132 SoC
- memory: introduce tegra EMC driver for scaling memory frequency
- misc. updates for ARM CCI and CCN busses
Conflicts:
arch/arm64/boot/dts/arm/juno-motherboard.dtsi
Trivial add/add conflict with our dt branch.
Resolution: take both sides.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVi4RRAAoJEFk3GJrT+8ZljIcQAIsqxM/o0drd90xTJ6ex9h0B
RmqVLTDgesHmBacJ+SBsa9/ybFIM1uErByftc1dmKankEQVXW3wcH7keQnoStPT2
zTEjadHgZ/ARYjV/oG5oohjfDZpO1kECVHL8O8RmcWxgzRB3az1IW2eD+dzrga/Y
R7K6D8rDHMADIUmv0e0DzvQEbSUYdCx3rBND1qZznwZDP3NoivLkOG5MTraccLbQ
ouCRoZtyNYD5Lxk+BHLBepnxAa0Ggc6IjEmiUv8fF2OYdu0OruMliT4rcAtOSmzg
2Y7pP85h8u0CxbJDkOyc+2BELyKo7Hv97XtDNNbRYABTMXdskRIadXt4Sh4mwFtM
nvlhB4ovbIX7noECJToEkSAgmStLSUwA3R6+DVdLbeQY4uSuXuTRhiWHMyQB6va9
CdjJDk2RE0dZ77c5ZoUnUDtBe4cULU/n4agpYkKMf/HcpnqMUwZzP4KZbbPMBpgL
0CVTt3YrEcjoU7g0SFHhOGPSgl4yIXKU2eHEscokyFYLrS5zRWepmUEmlSoaWn+W
p7pJE65TvOGf2xbaWI+UBeK/3ZG7XAP8qUfhsi7NS4bV6oFCk/foqsWAuru0H7OW
2Gk8fuF0qLgE1eFWQp8BHZ4IUeytoWbnGhhHXh8zH39SKAVncOiAGDNfuEP9CyXJ
fZFfruYrnz2emOwj2v9m
=02Gm
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Kevin Hilman:
"Some of these are for drivers/soc, where we're now putting
SoC-specific drivers these days. Some are for other driver subsystems
where we have received acks from the appropriate maintainers.
Some highlights:
- simple-mfd: document DT bindings and misc updates
- migrate mach-berlin to simple-mfd for clock, pinctrl and reset
- memory: support for Tegra132 SoC
- memory: introduce tegra EMC driver for scaling memory frequency
- misc. updates for ARM CCI and CCN busses"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (48 commits)
drivers: soc: sunxi: Introduce SoC driver to map SRAMs
arm-cci: Add aliases for PMU events
arm-cci: Add CCI-500 PMU support
arm-cci: Sanitise CCI400 PMU driver specific code
arm-cci: Abstract handling for CCI events
arm-cci: Abstract out the PMU counter details
arm-cci: Cleanup PMU driver code
arm-cci: Do not enable CCI-400 PMU by default
firmware: qcom: scm: Add HDCP Support
ARM: berlin: add an ADC node for the BG2Q
ARM: berlin: remove useless chip and system ctrl compatibles
clk: berlin: drop direct of_iomap of nodes reg property
ARM: berlin: move BG2Q clock node
ARM: berlin: move BG2CD clock node
ARM: berlin: move BG2 clock node
clk: berlin: prepare simple-mfd conversion
pinctrl: berlin: drop SoC stub provided regmap
ARM: berlin: move pinctrl to simple-mfd nodes
pinctrl: berlin: prepare to use regmap provided by syscon
reset: berlin: drop arch_initcall initialization
...
The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVU1A5AAoJEN0jrNd/PrOhd9IP/iKCdG7BcPX5V+ae7u+12quN
iMvYQBW7z9g292XnFvrB7pOqJaZIp0qLGAWpqA8DqOmF2nLVt5yw8yBB9kEWeeJ6
0Il3xUneZ7NNpdN5NzCWkVfKdr2xFIvWfsl4LrW4fr7C0VaeMi9xq+cFBxK82Xpz
9z9PDDz02ZnVGbaNZJNR7Tc5Ub0dEKHeRlpCFi9wJi0DXrURIklXuLPCoCiEH4KV
K6AuC69ChR4m0nQqhkbeXK4395nfKEIgV+Rmlp6/spJoaQBFC5WELtEzzDLuPS2+
4asfoFZgqEI0tSbG7sczJ4wdPrissYTULfpMW7cVC98vtzMmZLTixoAsgTss9CxS
wmkKyrrgbHM7yxqMksIF7b1z385E7OgNaMMmNPKHfKbzyuoHo+qomFo3WfMLHoZt
2sNvg8qfD0ueCsrsy4zNLoBq+QgwXyDRRO8DnAlToUD7sadqBbPpb3gJd2tBUVjI
v29hf/k3TnMVJJo+uRcZfAaQMvhDr2SK1XDSTzJ3Emkvch70d9idlxmf2H+auSY7
Fbv+NHmdjQeoARicwKAR2ZMc9RVrtQ2/FCMxirX/lagnB3ky+3W3CkhRGuid3yNq
koxW15TY+4YIbgPXXxAwc5uL5IeBQ8YfR7kupSaGLL+FmDD2VBSw7bogc9Plb941
PKocKOFnw3/HRY3mOtjQ
=yv05
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
Merge "ARM: tegra: RAM code access for v4.2-rc1" from Thierry Reding:
The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.
* tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: fuse: Add RAM code reader helper
of: Document long-ram-code property in nvidia,tegra20-apbmisc
Implements functionality needed to change the rate of the memory bus
clock.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The EMC driver needs to know the number of external memory devices and
also needs to update the EMEM configuration based on the new rate of the
memory bus.
To know how to update the EMEM config, looks up the values of the burst
regs in the DT, for a given timing.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The pmc driver was previously exporting tegra_pmc_restart, which was
assigned to machine_desc.init_machine, taking precedence over the
restart handlers registered through register_restart_handler().
Signed-off-by: David Riley <davidriley@chromium.org>
[tomeu.vizoso@collabora.com: Rebased]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
[treding@nvidia.com: minor cleanups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Needed for the EMC and MC drivers to know what timings from the DT to
use.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide clients and swgroups files in debugfs. These files show for
which clients IOMMU translation is enabled and which ASID is associated
with each SWGROUP.
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Acked-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
Tegra SoCs with 64-bit ARM support don't currently support deep CPU
low-power states in mainline Linux. When this support is added in the
future, it will probably look rather different from the existing
32-bit ARM support, since the ARM64 maintainers' strong preference is
to use PSCI to implement it.
So, for the time being, prevent the CPU suspend-related code and data
in the Tegra PMC driver from compiling on ARM64.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Allen Martin <amartin@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
This commit converts the PMC support code to a platform driver. Because
the boot process needs to call into this driver very early, also set up
a minimal environment via an early initcall.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Rather than rely on explicit initialization order called from SoC setup
code, use a plain initcall and rely on initcall ordering to take care of
dependencies.
This driver exposes some functionality (querying the chip ID) needed at
very early stages of the boot process. An early initcall is good enough
provided that some of the dependencies are deferred to later stages. To
make sure any abuses are easily caught, output a warning message if the
chip ID is queried while it can't be read yet.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Subsequent patches will move some of the initialization code from SoC
setup code to regular initcalls. To prevent breakage on other SoCs in
multi-platform builds, these initcalls need to check that they indeed
run on Tegra.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra20 fuse driver is the only user of tegra_apb_readl_using_dma().
Therefore we can simply the code by incorporating the APB DMA handling into
the driver directly. tegra_apb_writel_using_dma() is dropped because there
are no users.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124. This
replaces functionality previously provided in arch/arm/mach-tegra, which
is removed in this patch.
While at it, move the only user of the global tegra_revision variable
over to tegra_sku_info.revision and export tegra_fuse_readl() to allow
drivers to read calibration fuses.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
All fuse related functionality will move to a driver in the following
patches. To prepare for this, export all the required functionality in a
global header file and move all users of fuse.h to soc/tegra/fuse.h.
While we're at it, remove tegra_bct_strapping, as its only user was
removed in Commit a7cbe92cef ("ARM: tegra: remove tegra EMC scaling
driver").
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Export APB DMA readl and writel. These are needed because we can't
access the fuses directly on Tegra20 without potentially causing a
system hang. Also have the APB DMA readl and writel return an error in
case of a read failure instead of just returning zero or ignore write
failures.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Instead of using a simple variable access to get at the Tegra chip ID,
use a function so that we can run additional code. This can be used to
determine where the chip ID is being accessed without being available.
That in turn will be handy for resolving boot sequence dependencies in
order to convert more code to regular initcalls rather than a sequence
fixed by Tegra SoC setup code.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In order to not clutter the include/linux directory with SoC specific
headers, move the Tegra-specific headers out into a separate directory.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding