- 26 Sep, 2014 1 commit
-
-
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:
Mike Turquette <mturquette@linaro.org>
-
- 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:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Doug Anderson <dianders@chromium.org> Tested-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 10 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:
-
Uwe Kleine-König authored
Since commit 54196ccb (of: consolidate linker section OF match table declarations) which went into 3.16-rc1 the following compiler warning is generated: In file included from drivers/clk/clk-efm32gg.c:12:0: include/linux/of.h:772:20: warning: comparison of distinct pointer types lacks a cast [enabled by default] .data = (fn == (fn_type)NULL) ? fn : fn } ^ include/linux/of.h:785:3: note: in expansion of macro '_OF_DECLARE' _OF_DECLARE(table, name, compat, fn, of_init_fn_1) ^ include/linux/clk-provider.h:545:42: note: in expansion of macro 'OF_DECLARE_1' #define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, compat, fn) ^ drivers/clk/clk-efm32gg.c:81:1: note: in expansion of macro 'CLK_OF_DECLARE' CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init); ^ Fix it by making efm32gg_cmu_init return void. Cc: Rob Herring <robh@kernel.org> Reported-by:
Bryan Hundven <bryanhundven@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Soren Brinkmann authored
Use __initconst instead of __initdata for constant init data. Signed-off-by:
Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
Soren Brinkmann authored
Signed-off-by:
-
Soren Brinkmann authored
As checkpatch suggests: WARNING: Possible unnecessary 'out of memory' message, remove an error message after failing kmalloc() from the PLL driver. Signed-off-by:
-
- 03 Sep, 2014 3 commits
-
-
Tero Kristo authored
In some cases, clocks can switch their parent with clk_set_rate, for example clk_mux can do this in some cases. Current implementation of clk_change_rate uses un-safe list iteration on the clock children, which will cause wrong clocks to be parsed in case any of the clock children change their parents during the change rate operation. Fixed by using the safe list iterator instead. The problem was detected due to some divide by zero errors generated by clock init on dra7-evm board, see discussion under http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details. Fixes: 71472c0c ("clk: add support for clock reparent on set_rate") Signed-off-by:
Tero Kristo <t-kristo@ti.com> Reported-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Doug Anderson authored
The clocks for i2c1 and i2c2 are flipped. The clock tree matched the Technical Reference Manual (TRM) but the TRM was wrong. Swap them in the clock tree. This was determined experimentally (by Addy) and confirmed by the Rockchip IC team. Signed-off-by:
Addy Ke <addy.ke@rock-chips.com> Reviewed-by:
-
Mike Turquette authored
-
- 02 Sep, 2014 14 commits
-
-
Stephen Boyd authored
The pre-divider for the sdc clocks only has 2 bits in it, so we can't possibly divide by anything larger than 4 here. Furthermore, we program the value of ~(n - m) and the n value is larger than 8 bits (max of 256). Replace this entry with 200kHz which is close enough to 144kHz to be usable. Cc: Kumar Gala <galak@codeaurora.org> Cc: Andy Gross <agross@codeaurora.org> Fixes: 24d8fba4 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by:
-
Boris BREZILLON authored
Test rate value before calculating the div value to avoid div by zero. Signed-off-by:
Boris BREZILLON <boris.brezillon@free-electrons.com> Reported-by:
Gaël PORTAY <gael.portay@gmail.com> Tested-by:
-
Boris BREZILLON authored
The RM9200 USB clock is actually connected to a single parent (the PLLB) on which we can apply a specific divider. The USB clock divider does not allow for fine grained control on the USB clock frequency, hence propagating the set_rate request to the parent is the only choice we have to properly configure the USB clock rate. Signed-off-by:
-
Boris BREZILLON authored
Use the cached values to calculate PLL rate instead of the register values. This is required to prevent erroneous PLL rate return when the PLL rate has been configured but the PLL is not prepared yet. Signed-off-by:
-
Boris BREZILLON authored
The AT91 PLL rate configuration is done by configuring a multiplier/divider pair. The previous calculation was over-complicated (and apparently buggy). Simplify the implementation and add some comments to explain what is done here. Signed-off-by:
-
Boris BREZILLON authored
Signed-off-by:
-
Heiko Stübner authored
The clock-tree contains clocks that should never get disabled automatically. One example are the base ACLKs, the base supplies for all peripherals. Therefore add a structure similar to the sunxi clock-tree to protect these special clocks from being disabled. Signed-off-by:
-
Heiko Stübner authored
It is only used locally in clk/rockchip/clk.c and thus can be static. Signed-off-by:
-
Heiko Stübner authored
Rockchip SoCs may provide fraction dividers for some clocks, mostly for i2s and uarts. In contrast to the other registers, these do not use the hiword-mask paradigm, but instead split the register into the upper 16 bit for the nominator and the lower 16 bit for the denominator. The common clock framework got a generic fractional divider clock type recently that can accomodate this setting easily. All currently known fraction dividers have a separate gate too, therefore implement the divider as composite using the ops-struct from fractional_divider clock and add the gate if necessary. Signed-off-by:
-
Kuninori Morimoto authored
10cdfe9f (clk: shmobile: Add R-Car Gen2 clocks support) added R-Car Gen2 clock support via DT for v3.14. But, cpg_sd01_div_table is missing "0x0100: x 1/8" division ratio. This patch fixes hidden bug. It is based on R-Car H2 v0.7, R-Car M2 v0.9. Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Simon Horman <horms+renesas@verge.net.au> Reported-by:
Yusuke Goda <yusuke.goda.sx@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Ulrich Hecht authored
Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by:
-
Ulrich Hecht authored
Signed-off-by:
-
Mike Turquette authored
The powersave clock acts like a multiplexer for the cpu, selecting either the clock signal derived from the cpu pll or from the ddr clock. This patch changes powersave from a gate clock to a mux clock to better reflect this behavior. This is a cleaner approach whereby the frequency of the cpu always matches the rate of powersave_clk. The cpufreq driver for the kirkwood platform no longer must parse this behavior out of various calls to clk_enable and clk_disable, but can instead simply select the parent cpu it wants when changing rate. Likewise when requesting the cpu rate we need only query powersave_clk's rate through the usual call to clk_get_rate. The new clock data and corresponding changes to the cpufreq driver are combined into this single commit to avoid a git bisect issue where this cpufreq driver fails to work properly between the commit that updates the kirkwood clock driver and the commit that changes how the cpufreq driver uses that clock. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Tested-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Boris BREZILLON authored
The slow clk block provided by at91sam9260 and derived SoCs should always have 2 parents. Signed-off-by:
-
