summaryrefslogtreecommitdiff
path: root/drivers/irqchip/irq-gic-pm.c
AgeCommit message (Collapse)Author
2019-04-29irqchip/gic-pm: Fix suspend handlingSameer Pujar
If interrupts are enabled for a non-root GIC device that uses the gic-pm driver, when system suspend occurs, the current interrupt state is not saved and restored correctly and so interrupts do not work again on resuming the system. Add a late suspend handler to save and restore the state for these devices. Suggested-by: Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-29irqchip/gic-pm: Update driver to use clk_bulk APIsSameer Pujar
gic-pm driver is using pm-clk framework to manage clock resources, where clocks remain always ON. This happens on Tegra devices which use BPMP co-processor to manage the clocks. Calls to BPMP are always blocking and hence it is necessary to enable/disable clocks during prepare/unprepare phase respectively. When pm-clk is used, prepare count of clock is not balanced until pm_clk_remove() happens. Clock is prepared in the driver probe() and thus prepare count of clock remains non-zero, which in turn keeps clock ON always. Please note that above mentioned behavior is specific to Tegra devices using BPMP for clock management and this should not be seen on other devices. Though this patch uses clk_bulk APIs to address the mentioned behavior, this works fine for all devices. To simplify gic_get_clocks() API is removed and instead probe can do necessary setup. Suggested-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-09-12irqchip/gic-pm: Update driver to use of_pm_clk_add_clkJon Hunter
Commit 498b5fdd40dd ("PM / clk: Add support for adding a specific clock from device-tree") add a new helper function for adding a clock from device-tree to a device. Update the GIC-PM driver to use this new function to simplify the driver. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-06-13irqchip/gic: Add platform driver for non-root GICs that require RPMJon Hunter
Add a platform driver to support non-root GICs that require runtime power-management. Currently, only non-root GICs are supported because the functions, smp_cross_call() and set_handle_irq(), that need to be called for a root controller are located in the __init section and so cannot be called by the platform driver. The GIC platform driver re-uses many functions from the existing GIC driver including some functions to save and restore the GIC context during power transitions. The functions for saving and restoring the GIC context are currently only defined if CONFIG_CPU_PM is enabled and to ensure that these functions are always defined when the platform driver is enabled, a dependency on CONFIG_ARM_GIC_PM (which selects the platform driver) has been added. In order to re-use the private GIC initialisation code, a new public function, gic_of_init_child(), has been added which calls various private functions to initialise the GIC. This is different from the existing gic_of_init() because it only supports non-root GICs (ie. does not call smp_cross_call() is set_handle_irq()) and is not located in the __init section (so can be used by platform drivers). Furthermore, gic_of_init_child() dynamically allocates memory for the GIC chip data which is also different from gic_of_init(). There is no specific suspend handling for GICs registered as platform devices. Non-wakeup interrupts will be disabled by the kernel during late suspend, however, this alone will not power down the GIC if interrupts have been requested and not freed. Therefore, requestors of non-wakeup interrupts will need to free them on entering suspend in order to power-down the GIC. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>