summaryrefslogtreecommitdiffstats
path: root/drivers/soc/tegra
AgeCommit message (Collapse)AuthorFilesLines
2017-11-16Merge tag 'armsoc-drivers' of ↵Linus Torvalds1-2/+13
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Arnd Bergmann: "This branch contains platform-related driver updates for ARM and ARM64, these are the areas that bring the changes: New drivers: - driver support for Renesas R-Car V3M (R8A77970) - power management support for Amlogic GX - a new driver for the Tegra BPMP thermal sensor - a new bus driver for Technologic Systems NBUS Changes for subsystems that prefer to merge through arm-soc: - the usual updates for reset controller drivers from Philipp Zabel, with five added drivers for SoCs in the arc, meson, socfpa, uniphier and mediatek families - updates to the ARM SCPI and PSCI frameworks, from Sudeep Holla, Heiner Kallweit and Lorenzo Pieralisi Changes specific to some ARM-based SoC - the Freescale/NXP DPAA QBMan drivers from PowerPC can now work on ARM as well - several changes for power management on Broadcom SoCs - various improvements on Qualcomm, Broadcom, Amlogic, Atmel, Mediatek - minor Cleanups for Samsung, TI OMAP SoCs" [ NOTE! This doesn't work without the previous ARM SoC device-tree pull, because the R8A77970 driver is missing a header file that came from that pull. The fact that this got merged afterwards only fixes it at this point, and bisection of that driver will fail if/when you walk into the history of that driver. - Linus ] * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (96 commits) soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader bus: add driver for the Technologic Systems NBUS memory: omap-gpmc: Remove deprecated gpmc_update_nand_reg() soc: qcom: remove unused label soc: amlogic: gx pm domain: add PM and OF dependencies drivers/firmware: psci_checker: Add missing destroy_timer_on_stack() dt-bindings: power: add amlogic meson power domain bindings soc: amlogic: add Meson GX VPU Domains driver soc: qcom: Remote filesystem memory driver dt-binding: soc: qcom: Add binding for rmtfs memory of: reserved_mem: Accessor for acquiring reserved_mem of/platform: Generalize /reserved-memory handling soc: mediatek: pwrap: fix fatal compiler error soc: mediatek: pwrap: fix compiler errors arm64: mediatek: cleanup message for platform selection soc: Allow test-building of MediaTek drivers soc: mediatek: place Kconfig for all SoC drivers under menu soc: mediatek: pwrap: add support for MT7622 SoC soc: mediatek: pwrap: add common way for setup CS timing extenstion soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap ..
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2-0/+2
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-19soc/tegra: bpmp: Check BPMP response return codeTimo Alho1-2/+13
Add checks for the return code in BPMP response messages. Signed-off-by: Timo Alho <talho@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-08-23soc/tegra: fuse: Add missing semi-colonThierry Reding1-1/+1
Commit 8a46828e623c ("soc/tegra: Register SoC device") added a new initcall, but forgot to terminate the line with a semi-colon. Some recent versions of GCC seem to report this as an error. Fixes: 8a46828e623c ("soc/tegra: Register SoC device") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-08-23soc/tegra: Restrict SoC device registration to TegraThierry Reding1-0/+8
Commit 8a46828e623c ("soc/tegra: Register SoC device") added an initcall to register the SoC device on Tegra. However, that code is unrestricted and will run on all platforms, causing unwanted warnings. Fix this by first checking that we're running on hardware that supports the fuses block that we use to provide SoC information. Fixes: 8a46828e623c ("soc/tegra: Register SoC device") Reported-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-08-17soc/tegra: Register SoC deviceThierry Reding2-2/+51
Move this code from arch/arm/mach-tegra and make it common among 32-bit and 64-bit Tegra SoCs. This is slightly complicated by the fact that on 32-bit Tegra, the SoC device is used as the parent for all devices that are instantiated from device tree. Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-07-31soc/tegra: Fix bad of_node_put() in powergate initTuomas Tynkkynen1-3/+1
The for_each_child_of_node macro itself maintains the correct reference count of the nodes so the explicit of_node_put() call causes a warning: [ 0.098960] OF: ERROR: Bad of_node_put() on /pmc@7000e400/powergates/xusba [ 0.098981] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.3 #1-NixOS [ 0.098996] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) [ 0.099011] Call trace: [ 0.099034] [<ffff00000808a048>] dump_backtrace+0x0/0x2a0 [ 0.099051] [<ffff00000808a30c>] show_stack+0x24/0x30 [ 0.099069] [<ffff0000084a6494>] dump_stack+0x9c/0xc0 [ 0.099090] [<ffff000008992214>] of_node_release+0xa4/0xa8 [ 0.099107] [<ffff0000084a9270>] kobject_put+0x90/0x1f8 [ 0.099124] [<ffff0000089914ac>] of_node_put+0x24/0x30 [ 0.099140] [<ffff00000898cec4>] __of_get_next_child+0x4c/0x70 [ 0.099155] [<ffff00000898cf28>] of_get_next_child+0x40/0x68 [ 0.099173] [<ffff0000090a099c>] tegra_pmc_early_init+0x4e8/0x5ac [ 0.099189] [<ffff00000808399c>] do_one_initcall+0x5c/0x168 [ 0.099206] [<ffff000009050c98>] kernel_init_freeable+0xd4/0x240 [ 0.099224] [<ffff000008b2d658>] kernel_init+0x18/0x108 [ 0.099238] [<ffff0000080836c0>] ret_from_fork+0x10/0x50 (It's not very apparent from the OF documentation that of_node_put() is not needed; the macro itself has no docstring and of_get_next_child() used in the implementation begins with "Returns a node pointer with refcount incremented" but then only at the very end of the docstring the crucial part "Decrements the refcount of prev" is mentioned.) Fixes: a38045121bf42 ("soc/tegra: pmc: Add generic PM domain support") Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-06-13soc/tegra: flowctrl: Fix error handlingChristophe Jaillet1-1/+1
It is likely that returning returned by 'devm_ioremap_resource()' is expected here instead of something related to 'base' which should be a valid pointer at this point. Fixes: 841fd94c43a4 ("soc/tegra: flowctrl: Add basic platform driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-06-13soc/tegra: bpmp: Implement generic PM domainsThierry Reding3-0/+365
The BPMP firmware, found on Tegra186 and later, provides an ABI that can be used to enable and disable power to several power partitions in Tegra SoCs. The ABI allows for enumeration of the available power partitions, so the driver can be reused on future generations, provided the BPMP ABI remains stable. Based on work by Stefan Kristiansson <stefank@nvidia.com> and Mikko Perttunen <mperttunen@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-04-04soc/tegra: Add initial flowctrl support for Tegra132/210Jon Hunter2-10/+23
Tegra132 and Tegra210 support the flowctrl module and so add initial support for these devices. Please note that Tegra186 does not support the flowctrl module, so update the initialisation function such that we do not fall back and attempt to map the 'hardcoded' address range for Tegra186. Furthermore 64-bit Tegra devices have always had the flowctrl node defined in their device-tree and so only use the 'hardcoded' addresses for 32-bit Tegra devices. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-04-04soc/tegra: flowctrl: Add basic platform driverJon Hunter1-4/+30
Add a simple platform driver for the flowctrl module so that it gets registered as a proper device. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-04-04soc/tegra: Move Tegra flowctrl driverJon Hunter3-0/+195
The flowctrl driver is required for both ARM and ARM64 Tegra devices and in order to enable support for it for ARM64, move the Tegra flowctrl driver into drivers/soc/tegra. By moving the flowctrl driver, tegra_flowctrl_init() is now called by via an early initcall and to prevent this function from attempting to mapping IO space for a non-Tegra device, a test for 'soc_is_tegra()' is also added. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-04-04soc: tegra: make fuse-tegra explicitly non-modularPaul Gortmaker1-2/+2
The Makefiles currently controlling compilation of this code is: drivers/soc/tegra/Makefile:obj-y += fuse/ drivers/soc/tegra/fuse/Makefile:obj-y += fuse-tegra.o ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. Since module_platform_driver() uses the same init level priority as builtin_platform_driver() the init ordering remains unchanged with this commit. Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-04-04soc/tegra: Implement Tegra186 PMC supportThierry Reding3-1/+184
The power management controller on Tegra186 has changed in backwards- incompatible ways with respect to earlier generations. This implements a new driver that supports inversion of the PMU interrupt as well as the "recovery", "bootloader" and "forced-recovery" reboot commands. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Use consistent naming for PM domainsThierry Reding1-4/+4
The various error messages refer to the PM domains as "power domain", "genpd" and "PM domain". That's confusing, so convert all error messages to use the most prominent: "PM domain". Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Remove genpd when adding provider failsJon Hunter1-8/+15
Commit 3fe577107ccf ("PM / Domains: Add support for removing PM domains") add support for removing PM domains. Update the Tegra PMC driver to remove PM domains if we fail to add a provider for the PM domain. Please note that the code under 'power_on_cleanup' label does not really belong in the clean-up error path for tegra_powergate_add(). To keep the error path simple, remove this label and move the associated code to where it needs to be invoked. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Check return code for pm_genpd_init()Jon Hunter1-1/+6
Commit 7eb231c337e0 ("PM / Domains: Convert pm_genpd_init() to return an error code") updated pm_genpd_init() to return an error code. Update the Tegra PMC driver to check the return value from pm_genpd_init() and handle any errors returned. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> [treding@nvidia.com: use pr_err() instead of dev_err()] Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Clean-up I/O rail error messagesThierry Reding1-23/+20
Use pr_err() instead of dev_err() when the pmc->dev field has not been initialized yet and add a few missing error messages as well as remove duplicate ones. Based on work by Jon Hunter <jonathanh@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Simplify IO rail bit handlingJon Hunter1-10/+10
The function tegra_io_rail_prepare() converts the IO rail ID into a bit position that is used to check the status and control the IO rail in the PMC registers. However, rather than converting to a bit position it is more useful to convert to a bit-mask because this is what is actually used. By doing so the BIT() marco only needs to be used once and we can use the IO_DPD_REQ_CODE_MASK when checking for erroneous rail IDs. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> [treding@nvidia.com: rebase and rename bit -> mask] Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Guard against uninitialised PMC clockJon Hunter1-0/+2
It is possible for the public functions, tegra_io_rail_power_on/off() to be called before the PMC device has been probed. If this happens then the pmc->clk member will not be initialised and the call to clk_get_rate() in tegra_io_rail_prepare() will return zero and lead to a divide-by-zero exception. The function clk_get_rate() will return zero if a NULl clk pointer is passed. Therefore, rather that checking if pmc->clk is initialised, fix this by checking the return value for clk_get_rate() to make sure it is not zero. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Add I/O pad voltage supportLaxman Dewangan1-36/+237
I/O pins on Tegra SoCs are grouped into so-called I/O pads. Each such pad can be used to control the common voltage signal level and power state of the pins in the given pad. I/O pads can be powered down even if the system is active, which can save power from that I/O interface. For SoC generations prior to Tegra124 the I/O pad voltage is automatically detected and hence the system software doesn't need to configure it. However, starting with Tegra210 the detection logic has been removed, so explicit control of the I/O pad voltage by system software is required. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Use consistent ordering of bit definitionsThierry Reding1-6/+6
Bit definitions are sorted in decreasing order by offset. Apply the same ordering to all definitions. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()Laxman Dewangan1-3/+3
The function tegra_pmc_readl() returns the u32 type data and hence change the data type of variable where this data is stored to u32 type. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: pmc: Use BIT macro for register field definitionLaxman Dewangan1-26/+26
Use BIT macro for register field definition and make constant as U when using in shift operator like (3 << 30) to (3U << 30) Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-11-15soc/tegra: Add Tegra186 supportJoseph Lo1-0/+14
The Tegra186 features a combination of Denver and Cortex-A57 CPU cores and a GPU based on the Pascal architecture. It contains an ADSP with a Cortex-A9 CPU used for audio processing, hardware video encoders and decoders with multi-format support, ISP for image capture processing and BPMP for power management. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-08-16soc/tegra: pmc: Fix incorrect DPD requestVince Hsu1-20/+8
Reading the DPD_REQ & DPD2_REQ registers returns the previous requests. If we sets the current request bit with the returned value, then other pads will be turned on or off unexpectedly. Signed-off-by: Vince Hsu <vinceh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Enable XUSB partitions on bootJon Hunter1-0/+12
The Tegra XHCI driver does not currently manage the Tegra XUSB power partitions and so it these partitions have not been enabled by the bootloader then the system will crash when probing the XHCI device. While proper support for managing the power partitions is being developed to the XHCI driver for Tegra, for now power on all the XUSB partitions for USB host and super-speed on boot if the XHCI driver is enabled. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Initialise power partitions earlyJon Hunter1-9/+17
If CONFIG_PM_GENERIC_DOMAINS is not enabled, then power partitions associated with a device will not be enabled automatically by the PM core when the device is in use. To avoid situations where a device in a power partition is to be used but the partition is not enabled, initialise the power partitions for Tegra early in the boot process and if CONFIG_PM_GENERIC_DOMAINS is not enabled, then power on all partitions defined in the device-tree blob. Note that if CONFIG_PM_GENERIC_DOMAINS is not enabled, after the partitions are turned on, the clocks and resets used as part of the sequence for turning on the partition are released again as they are no longer needed by the PMC driver. Another benefit of this is that this avoids any issues of sharing resets between the PMC driver and other device drivers that may wish to independently control a particular reset. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Add specific error messagesJon Hunter1-9/+21
When initialising a powergate, only a single error message is shown if the initialisation fails. Add more error messages to give specific details of what failed if the initialisation failed and remove the generic failure message. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Use whitespace more consistentlyThierry Reding1-0/+6
Use blank lines after blocks and before labels for consistency with the existing code in the file. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Don't probe PMC if early initialisation failsJon Hunter1-0/+8
Commit 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') fixes an issue where the PMC base address pointer is not restored on probe failure. However, this fix creates another problem where if early initialisation of the PMC driver fails and an initial mapping for the PMC address space is not created, then when the PMC device is probed, the PMC base address pointer will not be valid and this will cause a crash when tegra_pmc_init() is called and attempts to access a register. Although the PMC address space is mapped a 2nd time during the probe and so this could be fixed by populating the base address pointer earlier during the probe, this adds more complexity to the code. Moreover, the PMC probe also assumes the the soc data pointer is also initialised when the device is probed and if not will also lead to a crash when calling tegra_pmc_init_tsense_reset(). Given that if the early initialisation does fail then something bad has happen, it seems acceptable to allow the PMC device probe to fail as well. Therefore, if the PMC base address pointer or soc data pointer are not valid when probing the PMC device, WARN and return an error. Fixes: 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Add missing of_node_put()Jon Hunter1-0/+4
Add missing of_node_put() in PMC early initialisation function to avoid leaking the device nodes. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> [treding@nvidia.com: squash in a couple more of_node_put() calls] Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Ensure mutex is always initialisedJon Hunter1-2/+2
The mutex used by the PMC driver may not be initialised if early initialisation of the driver fails. If this does happen, then it could be possible for callers of the public PMC functions to still attempt to acquire the mutex. Fix this by initialising the mutex as soon as possible to ensure it will always be initialised. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Don't populate SoC data until register space is mappedJon Hunter1-2/+2
The public functions exported by the PMC driver use the presence of the SoC data pointer to determine if the PMC device is configured and the registers can be accessed. However, the SoC data is populated before the PMC register space is mapped and this opens a window where the SoC data pointer is valid but the register space has not yet been mapped which could lead to a crash. Furthermore, if the mapping of the PMC register space fails, then the SoC data pointer is not cleared and so would expose a larger window where a crash could occur. Fix this by initialising the SoC data pointer after the PMC register space has been mapped. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Fix early initialisation of PMCJon Hunter1-16/+18
During early initialisation, the available power partitions for a given device is configured as well as the polarity of the PMC interrupt. Both of which should only be configured if there is a valid device node for the PMC device. This is because the soc data used for configuring the power partitions is only available if a device node for the PMC is found and the code to configure the interrupt polarity uses the device node pointer directly. Some early device-tree images may not have this device node and so fix this by ensuring the device node pointer is valid when configuring these items. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Ensure powergate is available when powering onJon Hunter1-0/+3
The function tegra_power_sequence_power_up() is a public function used to power on a partition. When this function is called, we do not check to see if the partition being powered up is valid/available. Fix this by checking to see that the partition is valid/available. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-30soc/tegra: pmc: Initialise resets associated with a power partitionJon Hunter1-4/+14
When registering the Tegra power partitions with the generic PM domain framework, the current state of the each partition is checked and used as the default state for the partition. However, the state of each reset associated with the partition is not initialised and so it is possible that the state of the resets are not in the expected state. For example, if a partition is on, then the resets should be de-asserted and if the partition is off, the resets should be asserted. There have been cases where the bootloader has powered on a partition and only de-asserted some of the resets to some of the devices in the partition. This can cause accesses to these devices to hang the system when the kernel boots and attempts to probe these devices. Ideally, the driver for the device should ensure the reset has been de-asserted when probing, but the resets cannot be shared between the PMC driver (that needs to de-assert/assert the reset when turning the partition on or off) and another driver because we cannot ensure the reset is in the correct state. To ensure the resets are in the correct state, when using the generic PM domain framework, put each reset associated with the partition in the correct state (based upon the partition's current state) when obtaining the resets for a partition. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-10soc/tegra: pmc: Use register definitions instead of magic valuesThierry Reding1-3/+13
Use register definitions for the main SoC reset operation instead of hard-coding magic values. Note that the PMC_RST_STATUS register isn't actually accessed, but since it is mentioned in a comment the definitions are added for completeness. Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-05-18Merge tag 'armsoc-drivers' of ↵Linus Torvalds1-105/+508
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Arnd Bergmann: "Driver updates for ARM SoCs, these contain various things that touch the drivers/ directory but got merged through arm-soc for practical reasons. For the most part, this is now related to power management controllers, which have not yet been abstracted into a separate subsystem, and typically require some code in drivers/soc or arch/arm to control the power domains. Another large chunk here is a rework of the NVIDIA Tegra USB3.0 support, which was surprisingly tricky and took a long time to get done. Finally, reset controller handling as always gets merged through here as well" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (97 commits) arm-ccn: Enable building as module soc/tegra: pmc: Add generic PM domain support usb: xhci: tegra: Add Tegra210 support usb: xhci: Add NVIDIA Tegra XUSB controller driver dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding PCI: tegra: Support per-lane PHYs dt-bindings: pci: tegra: Update for per-lane PHYs 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 drivers: firmware: psci: make two helper functions inline soc: renesas: rcar-sysc: Add support for R-Car H3 power areas soc: renesas: rcar-sysc: Add support for R-Car E2 power areas soc: renesas: rcar-sysc: Add support for R-Car M2-N power areas soc: renesas: rcar-sysc: Add support for R-Car M2-W power areas soc: renesas: rcar-sysc: Add support for R-Car H2 power areas ...
2016-04-29soc/tegra: pmc: Add generic PM domain supportJon Hunter1-61/+424
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>
2016-04-12ARM: tegra: Remove redundant ARM_L1_CACHE_SHIFT_6 selectMasahiro Yamada1-2/+0
These two are both ARMv7 SoCs. They need not explicitly select ARM_L1_CACHE_SHIFT_6 because it is enabled along with CPU_V7. Refer to commit a092f2b15399 ("ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Wait for powergate state to changeJon Hunter1-1/+8
Currently, the function tegra_powergate_set() simply sets the desired powergate state but does not wait for the state to change. In most cases we should wait for the state to change before proceeding. Currently, there is a case for Tegra114 and Tegra124 devices where we do not wait when starting the secondary CPU as this is not necessary. However, this is only done at boot time and so waiting here will only have a small impact on boot time. Therefore, update tegra_powergate_set() to wait when setting the powergate. By adding this feature, we can also eliminate the polling loop from tegra30_boot_secondary(). A function has been added for checking the status of the powergate and so update the tegra_powergate_is_powered() to use this macro as well. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Ensure GPU partition can be toggled on/off by PMCJon Hunter1-1/+7
For Tegra124 and Tegra210, the GPU partition cannot be toggled on and off via the APBDEV_PMC_PWRGATE_TOGGLE_0 register. For these devices, the partition is simply powered up and down via an external regulator. For these devices, there is a separate register for controlling the signal clamping of the partition and this is described in the PMC SoC data by the "has_gpu_clamp" variable. Use this variable to determine if the GPU partition can be controlled via the APBDEV_PMC_PWRGATE_TOGGLE_0 register and ensure that no one can incorrectly try to toggle the GPU partition via the APBDEV_PMC_PWRGATE_TOGGLE_0 register. Furthermore, we cannot use the APBDEV_PMC_PWRGATE_STATUS_0 register to determine if the GPU partition is powered for Tegra124 and Tegra210. However, if the GPU partition is powered, then the signal clamp for the GPU partition should be removed and so use bit 0 of the APBDEV_PMC_GPU_RG_CNTRL_0 register to determine if the clamp has been removed (bit[0] = 0) and the GPU partition is powered. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Remove additional check for a valid partitionJon Hunter1-2/+4
The function tegra_powergate_is_powered() verifies that the partition being queried is valid and so there is no need to check this before calling tegra_powergate_is_powered() in powergate_show(). So remove this extra check. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Fix verification of valid partitionsJon Hunter1-4/+9
The Tegra power partitions are referenced by numerical IDs which are the same values programmed into the PMC registers for controlling the partition. For a given device, the valid partition IDs may not be contiguous and so simply checking that an ID is not greater than the maximum ID supported may not mean it is valid. Fix this by checking if the powergate is defined in the list of powergates for the Tegra SoC. Add a helper function for checking valid powergates and use where we need to verify if the powergate ID is valid or not. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Fix testing of powergate stateJon Hunter1-8/+9
In tegra_powergate_set() the state of the powergates is read and OR'ed with the bit for the powergate of interest. This unsigned 32-bit value is then compared with a boolean value to test if the powergate is already in the desired state. When turning on a powergate, apart from the powergate that is represented by bit 0, this test will always return false and so we may attempt to turn on the powergate when it is already on. After OR'ing the bit for the powergate, check if the result is not equal to zero before comparing with the boolean value. Add a helper function to return the current state of a powergate and use this in both tegra_powergate_set() and tegra_powergate_is_powered() where we check the powergate status. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Change powergate and rail IDs to be an unsigned typeJon Hunter1-18/+18
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>
2016-04-05soc/tegra: pmc: Protect public functions from potential race conditionsJon Hunter1-14/+33
The PMC base address pointer is initialised during early boot so that early platform code may used the PMC public functions. During the probe of the PMC driver the base address pointer is mapped again and the initial mapping is freed. This exposes a window where a device accessing the PMC registers via one of the public functions, could race with the updating of the pointer and lead to a invalid access. Furthermore, the only protection between multiple devices attempting to access the PMC registers is when setting the powergate state to on or off. None of the other public functions that access the PMC registers are protected. Use the existing mutex to protect paths that may race with regard to accessing the PMC registers. Note that functions tegra_io_rail_prepare()/poll() either return a negative value on failure or zero on success. Therefore, it is not necessary to check if the return value is less than zero and so only test that the return value is not zero to test for failure. This simplifies the error handling with the mutex locking in place. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Restore base address on probe failureJon Hunter1-6/+8
During early initialisation, the PMC registers are mapped and the PMC SoC data is populated in the PMC data structure. This allows other drivers access the PMC register space, via the public Tegra PMC APIs, prior to probing the PMC device. When the PMC device is probed, the PMC registers are mapped again and if successful the initial mapping is freed. If the probing of the PMC device fails after the registers are remapped, then the registers will be unmapped and hence the pointer to the PMC registers will be invalid. This could lead to a potential crash, because once the PMC SoC data pointer is populated, the driver assumes that the PMC register mapping is also valid and a user calling any of the public Tegra PMC APIs could trigger an exception because these APIs don't check that the mapping is still valid. Fix this by updating the mapping and freeing the original mapping only if probing the PMC device is successful. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-04-05soc/tegra: pmc: Remove non-existing L2 partition for Tegra124Jon Hunter1-1/+0
Tegra124 does not have an L2 power partition and the L2 cache is part of the cluster 0 non-CPU (CONC) partition. Remove the L2 as a valid partition for Tegra124. The TRM also shows that there is no L2 partition for Tegra124. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>