summaryrefslogtreecommitdiffstats
path: root/drivers/soc/tegra
Commit message (Collapse)AuthorAgeFilesLines
* soc/tegra: fuse: Add missing semi-colonThierry Reding2017-08-231-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>
* soc/tegra: Restrict SoC device registration to TegraThierry Reding2017-08-231-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>
* soc/tegra: Register SoC deviceThierry Reding2017-08-172-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>
* soc/tegra: Fix bad of_node_put() in powergate initTuomas Tynkkynen2017-07-311-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>
* soc/tegra: flowctrl: Fix error handlingChristophe Jaillet2017-06-131-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>
* soc/tegra: bpmp: Implement generic PM domainsThierry Reding2017-06-133-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>
* soc/tegra: Add initial flowctrl support for Tegra132/210Jon Hunter2017-04-042-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>
* soc/tegra: flowctrl: Add basic platform driverJon Hunter2017-04-041-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>
* soc/tegra: Move Tegra flowctrl driverJon Hunter2017-04-043-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>
* soc: tegra: make fuse-tegra explicitly non-modularPaul Gortmaker2017-04-041-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>
* soc/tegra: Implement Tegra186 PMC supportThierry Reding2017-04-043-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>
* soc/tegra: pmc: Use consistent naming for PM domainsThierry Reding2016-11-151-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>
* soc/tegra: pmc: Remove genpd when adding provider failsJon Hunter2016-11-151-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>
* soc/tegra: pmc: Check return code for pm_genpd_init()Jon Hunter2016-11-151-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>
* soc/tegra: pmc: Clean-up I/O rail error messagesThierry Reding2016-11-151-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>
* soc/tegra: pmc: Simplify IO rail bit handlingJon Hunter2016-11-151-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>
* soc/tegra: pmc: Guard against uninitialised PMC clockJon Hunter2016-11-151-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>
* soc/tegra: pmc: Add I/O pad voltage supportLaxman Dewangan2016-11-151-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>
* soc/tegra: pmc: Use consistent ordering of bit definitionsThierry Reding2016-11-151-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>
* soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()Laxman Dewangan2016-11-151-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>
* soc/tegra: pmc: Use BIT macro for register field definitionLaxman Dewangan2016-11-151-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>
* soc/tegra: Add Tegra186 supportJoseph Lo2016-11-151-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>
* soc/tegra: pmc: Fix incorrect DPD requestVince Hsu2016-08-161-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>
* soc/tegra: pmc: Enable XUSB partitions on bootJon Hunter2016-06-301-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>
* soc/tegra: pmc: Initialise power partitions earlyJon Hunter2016-06-301-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>
* soc/tegra: pmc: Add specific error messagesJon Hunter2016-06-301-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>
* soc/tegra: pmc: Use whitespace more consistentlyThierry Reding2016-06-301-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>
* soc/tegra: pmc: Don't probe PMC if early initialisation failsJon Hunter2016-06-301-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>
* soc/tegra: pmc: Add missing of_node_put()Jon Hunter2016-06-301-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>
* soc/tegra: pmc: Ensure mutex is always initialisedJon Hunter2016-06-301-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>
* soc/tegra: pmc: Don't populate SoC data until register space is mappedJon Hunter2016-06-301-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>
* soc/tegra: pmc: Fix early initialisation of PMCJon Hunter2016-06-301-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>
* soc/tegra: pmc: Ensure powergate is available when powering onJon Hunter2016-06-301-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>
* soc/tegra: pmc: Initialise resets associated with a power partitionJon Hunter2016-06-301-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>
* soc/tegra: pmc: Use register definitions instead of magic valuesThierry Reding2016-06-101-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>
* Merge tag 'armsoc-drivers' of ↵Linus Torvalds2016-05-181-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 ...
| * soc/tegra: pmc: Add generic PM domain supportJon Hunter2016-04-291-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>
| * soc/tegra: pmc: Wait for powergate state to changeJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Ensure GPU partition can be toggled on/off by PMCJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Remove additional check for a valid partitionJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Fix verification of valid partitionsJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Fix testing of powergate stateJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Change powergate and rail IDs to be an unsigned typeJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Protect public functions from potential race conditionsJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Restore base address on probe failureJon Hunter2016-04-051-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>
| * soc/tegra: pmc: Remove non-existing L2 partition for Tegra124Jon Hunter2016-04-051-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>
| * soc/tegra: pmc: Remove non-existing power partitions for Tegra210Jon Hunter2016-04-051-4/+0
| | | | | | | | | | | | | | | | | | The power partitions L2, HEG, CELP and C1NC do not exist on Tegra210 but were incorrectly documented in the TRM. These will be removed from the TRM and so also remove their definitions. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
| * soc/tegra: pmc: Remove debugfs entry on probe failureJon Hunter2016-04-051-5/+6
| | | | | | | | | | | | | | | | | | | | The debugfs entry for the PMC device will not be removed if the probe of the device fails to register the restart handler. This leaves behind the dangling debugfs entry with no driver backing it. Remove the entry to avoid this. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
| * soc/tegra: pmc: Fix sparse warning for tegra_pmc_init_tsense_reset()Jon Hunter2016-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Sparse reports the following warning for tegra_pmc_init_tsense_reset(): drivers/soc/tegra/pmc.c:741:6: warning: symbol 'tegra_pmc_init_tsense_reset' was not declared. Should it be static? This function is only used internally by the PMC driver and so fix this by making it static. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
| * soc/tegra: pmc: Add missing structure members to kernel-docJon Hunter2016-04-051-0/+2
| | | | | | | | | | | | | | | | Some members of the tegra_pmc structure are missing from the kernel-doc comment for this structure. Add the missing members. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
OpenPOWER on IntegriCloud