- 01 Oct, 2014 3 commits
-
-
Heiko Stübner authored
Add infrastructure to write the correct value to the restart register and register the restart notifier for both rk3188 (including rk3066) and rk3288. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Heiko Stuebner authored
Immutable branch with restart handler patches for v3.18
-
Jianqun authored
The relation of i2s nodes as follows: i2s_src 0 0 594000000 0 i2s_frac 0 0 11289600 0 i2s_pre 0 0 11289600 0 sclk_i2s0 0 0 11289600 0 i2s0_clkout 0 0 11289600 0 hclk_i2s0 1 1 99000000 0 sclk_i2s0 is the master clock, when to set rate of sclk_i2s0, should allow to set its parent's rate, by add flag CLK_SET_RATE_PARENT for "i2s_frac", "i2s_pre", "i2s0_clkout" and "sclk_i2s0". Tested on rk3288 board using max98090, with command "aplay <music.wav>" Change-Id: I12faad082566532b65a7de8c0a6845e1c17870e6 Signed-off-by:Jianqun <jay.xu@rock-chips.com> Signed-off-by:
-
- 27 Sep, 2014 9 commits
-
-
Heiko Stuebner authored
This adds the necessary soc-specific divider values and switches the armclk to use the newly introduced cpuclk type. Signed-off-by:
Doug Anderson <dianders@chromium.org> Tested-by:
-
Heiko Stuebner authored
When changing the armclk on Rockchip SoCs it is supposed to be reparented to an alternate parent before changing the underlying pll and back after the change. Additionally there exist clocks that are very tightly bound to the armclk whose divider values are set according to the armclk rate. Add a special clock-type to handle all that. The rate table and divider values will be supplied from the soc-specific clock controllers. Signed-off-by:
-
Heiko Stuebner authored
Rockchip SoCs contain clocks tightly bound to the armclk, where the best rate / divider is supplied by the vendor after careful measuring. Often this ideal rate may be greater than the current rate. Therefore prevent the ccf from trying to set these dividers itself by setting them to read-only. In the case of the rk3066, this also includes the aclk_cpu, which makes it necessary to also split its direct child-clocks (pclk_cpu, hclk_cpu, ...) into individual definitions for rk3066 and rk3188. Signed-off-by:
-
Heiko Stuebner authored
aclk_cpu_pre on the rk3188 can either be sourced from the armclk or the gpll. To reduce complexity on apll changes caused by cpufreq, reparent it always to the gpll source. If really necessary it could be reparented back on a per board level using the assigned-clocks mechanism. Signed-off-by: -
Jianqun authored
In RK3288, APLL lock status bit is in GRF_SOC_STATUS1, but in RK3188, is GRFSOC_STATUS0. Signed-off-by:
-
Heiko Stuebner authored
The register providing the pll lock status is at a different address on the rk3066. The error became apparent while working on cpufreq support for the rockchip SoCs. Signed-off-by: -
Doug Anderson authored
The Rockchip PLL code switches into slow mode (AKA bypass more AKA 24MHz mode) before actually changing the PLL. This keeps anyone from using the PLL while it's changing. However, in all known Rockchip SoCs nobody should ever see the 24MHz when changing the PLL supplying the armclk because we should reparent children to an alternate (faster than 24MHz) PLL. One problem is that the code to switch to an alternate parent was running in PRE_RATE_CHANGE. ...and the code to switch to slow mode was _also_ running in PRE_RATE_CHANGE. That meant there was no real guarantee that we would switch to an alternate parent before switching to 24MHz mode. Let's move the switch to "slow mode" straight into rockchip_rk3066_pll_set_rate(). That means we're guaranteed that the 24MHz is really a last-resort. Note that without this change on real systems we were the code to switch to an alternate parent at 24MHz. In some older versions of that code we'd appy a (temporary) / 5 to the 24MHz causing us to run at 4.8MHz. That wasn't enough to service USB interrupts in some cases and could lead to a system hang. Signed-off-by:
-
Heiko Stuebner authored
-
Heiko Stuebner authored
Signed-off-by:
-
- 26 Sep, 2014 10 commits
-
-
Guenter Roeck authored
Implementing a restart handler in a module don't make sense as there would be no guarantee that the module is loaded when a restart is needed. Unexport arm_pm_restart to ensure that no one gets the idea to do it anyway. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org>
-
Guenter Roeck authored
The kernel core now provides an API to trigger a system restart. Register with it instead of setting arm_pm_restart. Signed-off-by:
-
Guenter Roeck authored
The kernel core now provides an API to trigger a system restart. Register with it to restart the system instead of misusing the reboot notifier. Signed-off-by:
-
Guenter Roeck authored
The kernel now provides an API to trigger a system restart. Register with it instead of setting arm_pm_restart. Signed-off-by:
-
Guenter Roeck authored
The kernel core now supports a restart handler call chain for system restart functions. With this change, the arm_pm_restart callback is now optional, so drop its initialization and check if it is set before calling it. Only call the kernel restart handler if arm_pm_restart is not set. Signed-off-by:
-
Guenter Roeck authored
The kernel core now supports a restart handler call chain to restart the system. Call it if arm_pm_restart is not set. Signed-off-by:
-
Guenter Roeck authored
machine_restart is supported on non-ARM platforms, and and ultimately calls arm_pm_restart, so dont call arm_pm_restart directly but use the more generic function. Signed-off-by:
-
Guenter Roeck authored
Various drivers implement architecture and/or device specific means to restart (reset) the system. Various mechanisms have been implemented to support those schemes. The best known mechanism is arm_pm_restart, which is a function pointer to be set either from platform specific code or from drivers. Another mechanism is to use hardware watchdogs to issue a reset; this mechanism is used if there is no other method available to reset a board or system. Two examples are alim7101_wdt, which currently uses the reboot notifier to trigger a reset, and moxart_wdt, which registers the arm_pm_restart function. The existing mechanisms have a number of drawbacks. Typically only one scheme to restart the system is supported (at least if arm_pm_restart is used). At least in theory there can be multiple means to restart the system, some of which may be less desirable (for example one mechanism may only reset the CPU, while another may reset the entire system). Using arm_pm_restart can also be racy if the function pointer is set from a driver, as the driver may be in the process of being unloaded when arm_pm_restart is called. Using the reboot notifier is always racy, as it is unknown if and when other functions using the reboot notifier have completed execution by the time the watchdog fires. Introduce a system restart handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_restart() function. Drivers providing system restart functionality (such as the watchdog drivers mentioned above) are expected to register with this call chain. By using the priority field in the notifier block, callers can control restart handler execution sequence and thus ensure that the restart handler with the optimal restart capabilities for a given system is called first. Signed-off-by:
-
Mike Turquette authored
If CONFIG_COMMON_CLK is selected then __clk_get and __clk_put are defined in drivers/clk/clk.c and declared in include/linux/clkdev.h. Sylwester's series[0] to properly support clk_{get,put} in the common clock framework made changes to the asm-specific clkdev.h headers, but not the asm-generic version. Tomeu's recent changes[1] to introduce a provider/consumer split in the clock framework uncovered this problem, causing the following build error on any architecture using the asm-generic clkdev.h (e.g. x86 architecture and the ACPI LPSS driver): In file included from drivers/acpi/acpi_lpss.c:15:0: include/linux/clkdev.h:59:5: error: conflicting types for ‘__clk_get’ int __clk_get(struct clk_core *clk); ^ In file included from arch/x86/include/generated/asm/clkdev.h:1:0, from include/linux/clkdev.h:15, from drivers/acpi/acpi_lpss.c:15: include/asm-generic/clkdev.h:20:19: note: previous definition of ‘__clk_get’ was here static inline int __clk_get(struct clk *clk) { return 1; } ^ Fixed by only declarating __clk_get and __clk_put when CONFIG_COMMON_CLK is set. [0] http://lkml.kernel.org/r/<1386177127-2894-5-git-send-email-s.nawrocki@samsung.com> [1] http://lkml.kernel.org/r/<1409758148-20104-1-git-send-email-tomeu.vizoso@collabora.com> Signed-off-by:Mike Turquette <mturquette@linaro.org>
-
Kiran Padwal authored
There is no need to init .owner field. Based on the patch from Peter Griffin <peter.griffin@linaro.org> "mmc: remove .owner field for drivers using module_platform_driver" This patch removes the superflous .owner field for drivers which use the module_platform_driver API, as this is overriden in platform_driver_register anyway." Signed-off-by:
Kiran Padwal <kiran.padwal@smartplayin.com> Signed-off-by:
-
- 25 Sep, 2014 7 commits
-
-
Mike Turquette authored
-
Kever Yang authored
This patch add the clock node in PD_VIDEO Signed-off-by:
Kever Yang <kever.yang@rock-chips.com> Reviewed-by:
-
Kever Yang authored
This patch use the new defined clock ID to initial the clock nodes. Signed-off-by:
-
Kever Yang authored
This patch add some clock binding id for different modules that under development and going to send upstream. Signed-off-by:
-
Heiko Stübner authored
The npll on rk3288 is exactly the same pll type as the other 4. Yet it was missing the link to the rate table, making rate changes impossible. Change that by setting the table. Signed-off-by:
-
Mark yao authored
The rk3288 actually has 12 softresets, so fix the register count. Signed-off-by:
Mark yao <mark.yao@rock-chips.com> Reviewed-by:
-
Mark yao authored
The patch add the rest of the indices of the additional reset registers from the updated TRM. Signed-off-by:
-
- 17 Sep, 2014 1 commit
-
-
Mike Turquette authored
-
- 10 Sep, 2014 4 commits
-
-
Mike Turquette authored
-
Stephen Boyd authored
Rob Clark reports a lockdep splat that involves the prepare_lock chained with the mmap semaphore. ====================================================== [ INFO: possible circular locking dependency detected ] 3.17.0-rc1-00050-g07a489b #802 Tainted: G W ------------------------------------------------------- Xorg.bin/5413 is trying to acquire lock: (prepare_lock){+.+.+.}, at: [<c0781280>] clk_prepare_lock+0x88/0xfc but task is already holding lock: (qcom_iommu_lock){+.+...}, at: [<c079f664>] qcom_iommu_unmap+0x1c/0x1f0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (qcom_iommu_lock){+.+...}: [<c079f860>] qcom_iommu_map+0x28/0x450 [<c079eb50>] iommu_map+0xc8/0x12c [<c056c1fc>] msm_iommu_map+0xb4/0x130 [<c05697bc>] msm_gem_get_iova_locked+0x9c/0xe8 [<c0569854>] msm_gem_get_iova+0x4c/0x64 [<c0562208>] mdp4_kms_init+0x4c4/0x6c0 [<c056881c>] msm_load+0x2ac/0x34c [<c0545724>] drm_dev_register+0xac/0x108 [<c0547510>] drm_platform_init+0x50/0xf0 [<c0578a60>] try_to_bring_up_master.part.3+0xc8/0x108 [<c0578b48>] component_master_add_with_match+0xa8/0x104 [<c0568294>] msm_pdev_probe+0x64/0x70 [<c057e704>] platform_drv_probe+0x2c/0x60 [<c057cff8>] driver_probe_device+0x108/0x234 [<c057b65c>] bus_for_each_drv+0x64/0x98 [<c057cec0>] device_attach+0x78/0x8c [<c057c590>] bus_probe_device+0x88/0xac [<c057c9b8>] deferred_probe_work_func+0x68/0x9c [<c0259db4>] process_one_work+0x1a0/0x40c [<c025a710>] worker_thread+0x44/0x4d8 [<c025ec54>] kthread+0xd8/0xec [<c020e9a8>] ret_from_fork+0x14/0x2c -> #3 (&dev->struct_mutex){+.+.+.}: [<c0541188>] drm_gem_mmap+0x38/0xd0 [<c05695b8>] msm_gem_mmap+0xc/0x5c [<c02f0b6c>] mmap_region+0x35c/0x6c8 [<c02f11ec>] do_mmap_pgoff+0x314/0x398 [<c02de1e0>] vm_mmap_pgoff+0x84/0xb4 [<c02ef83c>] SyS_mmap_pgoff+0x94/0xbc [<c020e8e0>] ret_fast_syscall+0x0/0x48 -> #2 (&mm->mmap_sem){++++++}: [<c0321138>] filldir64+0x68/0x180 [<c0333fe0>] dcache_readdir+0x188/0x22c [<c0320ed0>] iterate_dir+0x9c/0x11c [<c03213b0>] SyS_getdents64+0x78/0xe8 [<c020e8e0>] ret_fast_syscall+0x0/0x48 -> #1 (&sb->s_type->i_mutex_key#3){+.+.+.}: [<c03fc544>] __create_file+0x58/0x1dc [<c03fc70c>] debugfs_create_dir+0x1c/0x24 [<c0781c7c>] clk_debug_create_subtree+0x20/0x170 [<c0be2af8>] clk_debug_init+0xec/0x14c [<c0208c70>] do_one_initcall+0x8c/0x1c8 [<c0b9cce4>] kernel_init_freeable+0x13c/0x1dc [<c0877bc4>] kernel_init+0x8/0xe8 [<c020e9a8>] ret_from_fork+0x14/0x2c -> #0 (prepare_lock){+.+.+.}: [<c087c408>] mutex_lock_nested+0x70/0x3e8 [<c0781280>] clk_prepare_lock+0x88/0xfc [<c0782c50>] clk_prepare+0xc/0x24 [<c079f474>] __enable_clocks.isra.4+0x18/0xa4 [<c079f614>] __flush_iotlb_va+0xe0/0x114 [<c079f6f4>] qcom_iommu_unmap+0xac/0x1f0 [<c079ea3c>] iommu_unmap+0x9c/0xe8 [<c056c2fc>] msm_iommu_unmap+0x64/0x84 [<c0569da4>] msm_gem_free_object+0x11c/0x338 [<c05413ec>] drm_gem_object_handle_unreference_unlocked+0xfc/0x130 [<c0541604>] drm_gem_object_release_handle+0x50/0x68 [<c0447a98>] idr_for_each+0xa8/0xdc [<c0541c10>] drm_gem_release+0x1c/0x28 [<c0540b3c>] drm_release+0x370/0x428 [<c031105c>] __fput+0x98/0x1e8 [<c025d73c>] task_work_run+0xb0/0xfc [<c02477ec>] do_exit+0x2ec/0x948 [<c0247ec0>] do_group_exit+0x4c/0xb8 [<c025180c>] get_signal+0x28c/0x6ac [<c0211204>] do_signal+0xc4/0x3e4 [<c02116cc>] do_work_pending+0xb4/0xc4 [<c020e938>] work_pending+0xc/0x20 other info that might help us debug this: Chain exists of: prepare_lock --> &dev->struct_mutex --> qcom_iommu_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(qcom_iommu_lock); lock(&dev->struct_mutex); lock(qcom_iommu_lock); lock(prepare_lock); *** DEADLOCK *** 3 locks held by Xorg.bin/5413: #0: (drm_global_mutex){+.+.+.}, at: [<c0540800>] drm_release+0x34/0x428 #1: (&dev->struct_mutex){+.+.+.}, at: [<c05413bc>] drm_gem_object_handle_unreference_unlocked+0xcc/0x130 #2: (qcom_iommu_lock){+.+...}, at: [<c079f664>] qcom_iommu_unmap+0x1c/0x1f0 stack backtrace: CPU: 1 PID: 5413 Comm: Xorg.bin Tainted: G W 3.17.0-rc1-00050-g07a489b #802 [<c0216290>] (unwind_backtrace) from [<c0211d8c>] (show_stack+0x10/0x14) [<c0211d8c>] (show_stack) from [<c087a078>] (dump_stack+0x98/0xb8) [<c087a078>] (dump_stack) from [<c027f024>] (print_circular_bug+0x218/0x340) [<c027f024>] (print_circular_bug) from [<c0283e08>] (__lock_acquire+0x1d24/0x20b8) [<c0283e08>] (__lock_acquire) from [<c0284774>] (lock_acquire+0x9c/0xbc) [<c0284774>] (lock_acquire) from [<c087c408>] (mutex_lock_nested+0x70/0x3e8) [<c087c408>] (mutex_lock_nested) from [<c0781280>] (clk_prepare_lock+0x88/0xfc) [<c0781280>] (clk_prepare_lock) from [<c0782c50>] (clk_prepare+0xc/0x24) [<c0782c50>] (clk_prepare) from [<c079f474>] (__enable_clocks.isra.4+0x18/0xa4) [<c079f474>] (__enable_clocks.isra.4) from [<c079f614>] (__flush_iotlb_va+0xe0/0x114) [<c079f614>] (__flush_iotlb_va) from [<c079f6f4>] (qcom_iommu_unmap+0xac/0x1f0) [<c079f6f4>] (qcom_iommu_unmap) from [<c079ea3c>] (iommu_unmap+0x9c/0xe8) [<c079ea3c>] (iommu_unmap) from [<c056c2fc>] (msm_iommu_unmap+0x64/0x84) [<c056c2fc>] (msm_iommu_unmap) from [<c0569da4>] (msm_gem_free_object+0x11c/0x338) [<c0569da4>] (msm_gem_free_object) from [<c05413ec>] (drm_gem_object_handle_unreference_unlocked+0xfc/0x130) [<c05413ec>] (drm_gem_object_handle_unreference_unlocked) from [<c0541604>] (drm_gem_object_release_handle+0x50/0x68) [<c0541604>] (drm_gem_object_release_handle) from [<c0447a98>] (idr_for_each+0xa8/0xdc) [<c0447a98>] (idr_for_each) from [<c0541c10>] (drm_gem_release+0x1c/0x28) [<c0541c10>] (drm_gem_release) from [<c0540b3c>] (drm_release+0x370/0x428) [<c0540b3c>] (drm_release) from [<c031105c>] (__fput+0x98/0x1e8) [<c031105c>] (__fput) from [<c025d73c>] (task_work_run+0xb0/0xfc) [<c025d73c>] (task_work_run) from [<c02477ec>] (do_exit+0x2ec/0x948) [<c02477ec>] (do_exit) from [<c0247ec0>] (do_group_exit+0x4c/0xb8) [<c0247ec0>] (do_group_exit) from [<c025180c>] (get_signal+0x28c/0x6ac) [<c025180c>] (get_signal) from [<c0211204>] (do_signal+0xc4/0x3e4) [<c0211204>] (do_signal) from [<c02116cc>] (do_work_pending+0xb4/0xc4) [<c02116cc>] (do_work_pending) from [<c020e938>] (work_pending+0xc/0x20) We can break this chain if we don't hold the prepare_lock while creating debugfs directories. We only hold the prepare_lock right now because we're traversing the clock tree recursively and we don't want the hierarchy to change during the traversal. Replacing this traversal with a simple linked list walk allows us to only grab a list lock instead of the prepare_lock, thus breaking the lock chain. Signed-off-by:Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Heiko Stübner authored
The dwc2 usb controller also uses agressive clock gating, which in this case leads to hclk_peri getting disabled and hanging the system. Therefore move it to the critical clocks until we also control that part of the system. Signed-off-by:
-
Heiko Stübner authored
On 32bit architectures, like ARM calculating the fractional rate will do the multiplication before converting the value to u64 when it gets assigned to ret, which can produce overflows. The error in question happened with a parent_rate of 386MHz, m = 3000, n = 60000, which resulted in a wrong rate value of 15812Hz. Therefore cast parent_rate to u64 to make sure the multiplication happens in a 64bit space and produces the correct 192MHz in the example. Signed-off-by:
-
- 09 Sep, 2014 6 commits
-
-
Javier Martinez Canillas authored
Add Device Tree binding documentation for the clocks outputs in the Maxim 77802 Power Management IC. Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by:
-
Javier Martinez Canillas authored
The MAX77802 PMIC has two 32.768kHz Buffered Clock Outputs with Low Jitter Mode. This patch adds support for these two clocks. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
Like most clock drivers, the Maxim 77686 PMIC clock binding follows the convention that the "#clock-cells" property is used to specify the number of cells in a clock provider. But the binding document is not clear enough that it shall be set to 1 since the PMIC support multiple clocks outputs. Also, explain that the clocks identifiers are defined in a header file that can be included by Device Tree source with client nodes to avoid using magic numbers. Finally, add "clock-output-names" as an optional property since now is supported by the clock driver. Signed-off-by:
-
Javier Martinez Canillas authored
Clocks drivers for Maxim PMIC are very similar so they can be converted to use the generic Maxim clock driver. Also, while being there use module_platform_driver() helper macro to eliminate more boilerplate code. Signed-off-by:
-
Javier Martinez Canillas authored
Maxim Integrated Power Management ICs are very similar with regard to their clock outputs. Most of the clock drivers for these chips are duplicating code and are simpler enough that can be converted to use a generic driver to consolidate code and avoid duplication. Signed-off-by:
-
Javier Martinez Canillas authored
This patch adds a dt-binding include for Maxim 77686 PMIC clock IDs that can be used by both the max77686 clock driver and Device Tree source files. Signed-off-by:
-
