| Age | Commit message (Collapse) | Author |
|---|
|
A common operation for a clock signal generator is to shift the phase of
that signal. This patch introduces a new function to the clk.h API to
dynamically adjust the phase of a clock signal. Additionally this patch
introduces support for the new function in the common clock framework
via the .set_phase call back in struct clk_ops.
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
|
|
clock changes for mvebu for v3.18
- correct timer drift caused by SSCG deviation
- fix typo in comment
|
|
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom into clk-next
qcom clock changes for 3.18
Some fixes for the IPQ driver and some code consolidation
and refactoring.
|
|
git://nv-tegra.nvidia.com/user/pdeschrijver/linux into clk-next
Tegra clk updates for 3.18
|
|
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>
|
|
|
|
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: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Pull "Second SoC batch for 3.18" from Nicolas Ferre:
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'at91-soc2' of git://github.com/at91linux/linux-at91:
ARM: at91: document Atmel SMART compatibles
ARM: at91: add sama5d4 support to sama5_defconfig
ARM: at91: dt: add device tree file for SAMA5D4ek board
ARM: at91: dt: add device tree file for SAMA5D4 SoC
ARM: at91: SAMA5D4 SoC detection code and low level routines
ARM: at91: introduce basic SAMA5D4 support
clk: at91: add a driver for the h32mx clock
|
|
This patch use the new defined clock ID to initial the clock nodes.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
The rk3288 actually has 12 softresets, so fix the register count.
Signed-off-by: Mark yao <mark.yao@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
The 'div_core2' clock and the 'arm_clk' divider clocks are instances of
the same divider clock. So remove the 'arm_clk' clock instance.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
[tomasz.figa@gmail.com: Fixed remaining occurences of 'arm_clk'.]
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
The banked MD RCGs in global clock control have a different
register layout than the ones implemented in multimedia clock
control. Add support for these types of clocks so we can change
the rates of the UBI32 clocks.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
Some PLLs may require changing their rate at runtime. Add support
for these PLLs.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
There are two find_freq() functions in clk-rcg.c and clk-rcg2.c
that are almost exactly the same. Consolidate them into one
function to save on some code space.
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
This patch adds the PLL0 that is required for the USB clocks to
work properly.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
sclk_g3d clock doesn't have enable/disable bits, but the driver hijacked
g3d gate clock bits for this purpose and didn't provide real g3d clock
at all. This patch fixes this issue by adding proper definition for g3d
clock and removing incorrect access to GATE_IP_G3D register in sclk_g3d.
In addition CLK_SET_RATE_PARENT flag is dropped from sclk_g3d, because
it does not make any sense and most likely has been added by mistake.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[tomasz.figa@gmail.com: Adjusted commit message.]
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
This patch adds support for exporting mout_hdmi and mout_mixer to device
tree. Access to those clocks is required to correctly setup HDMI module
on Exynos 4210 and 4x12 SoCs.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
CC: Mike Turquette <mturquette@linaro.org>
CC: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
This patch adds missing smmu_g2d clock implementation and updates
comment about Exynos4 clocks from 278-282 range. Those clocks are
available on all Exynos4 SoC series, so the misleading comment has been
removed.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
Add clock provider for clocks in DMC domain including EPLL and BPLL. The
DMC clocks are necessary for Exynos3 devfreq driver.
The DMC clock domain uses different address space (0x105C0000) than
standard clock domain (0x10030000 - 0x10050000). The difference is huge
enough to add new DT node for the clock provider, rather than extending
existing address space.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
The parent name added in parent list as
mout_phyclk_mipi_dphy_4l_m_txbyte_clkhs_p, is different
than the defined parent due to typo.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Chander Kashyap <k.chander@samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
As per Exynos3250 user manual mmc0/1 mux selection has 4 bit wide.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
Update shift and width field of div_spi0_isp clock as per Exynos3250
user manual.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
As per user manual of Exynos3250 SRC_CAM can select
div_cam_blk_320 if it's value is 0xC, so placing
div_cam_blk_320 at proper index in parent list of mout_cam_blk.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
|
|
Newer SoCs have two different AHB interconnect. The AHB 32 bits Matrix
interconnect (h32mx) has a clock that can be setup at the half of the h64mx
clock (which is mck). The h32mx clock can not exceed 90 MHz.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Don't abort clock initialization if we cannot match an entry in
tegra_clk_init_table to a valid entry in the clk array.
Also log a corresponding error message.
This was discovered when testing a patch that removed the EMC clock from
tegra124_clks but left a mention in tegra_clk_init_table.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
|
|
These clocks are used as parents for some EMC timings.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
|
|
|
|
Commit 15917b16022427c53755abff4dc7051f3076dd7a ("clk: mvebu: Fix clk
frequency value if SSCG is enabled") introduced some logic in the
common mvebu clock code to adjust the clock frequency according to the
configuration of the SSCG.
In order to do this, it looks up for a DT node called "sscg" and maps
it before accessing the SSCG configuration register.
However, the lookup is currently done using:
sscg_np = of_find_node_by_name(np, "sscg");
where "np" is a pointer to the DT node of the clock for which we are
calculating the adjusted frequency. This means that if the "sscg" node
is *after* the clock node in the Device Tree, it works fine (and
that's the case for Armada 370).
However, if it turns out that the "sscg" node is *before* the clock
node in the Device Tree, it won't work because the sscg node will not
be found.
What we really want here is a search of the entire Device Tree, not
only starting from the clock node, so instead of passing "np" as first
argument of of_find_node_by_name(), we simply need to pass
NULL. Passing a non-NULL argument is typically used in a loop, so that
the search for the next matching node starts right after the node that
was matched.
This makes the "np" argument to the kirkwood_fix_sscg_deviation()
function unnecessary, which leads to further cleanups.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 15917b1602242 ("clk: mvebu: Fix clk frequency value if SSCG is enabled")
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1410880503-2322-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
The sun4i-apb0 clock, as found on all platforms using it, is a
power-of-two-based divider clock, with a special divider of 2
for value 0.
This was causing the clock framework to incorrectly calculate
the clock rate for apb1 and related modules on sun6i and sun8i.
On sun[4/5/7]i, u-boot SPL configures the divider with value 1
for /2 divider, so no suprises there.
This patch adds a proper divider table for it, so the correct
clock rate can be calculated.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Emilio López <emilio@elopez.com.ar>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
|
|
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: Mike Turquette <mturquette@linaro.org>
|
|
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 Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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 <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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 <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
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: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Since commit 54196ccbe0ba (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: Mike Turquette <mturquette@linaro.org>
|
|
Use __initconst instead of __initdata for constant init data.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
As checkpatch suggests:
WARNING: Possible unnecessary 'out of memory' message,
remove an error message after failing kmalloc() from the PLL driver.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
For dealing with the code we use the SAR1 and not the SAR0. The code
was correct, and now the comments too.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Link: https://lkml.kernel.org/r/1409645719-20003-5-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
This commit activates the SSCG deviation correction for the Armada
370. It uses the optional function introduced by the commit "clk:
mvebu: Fix clk frequency value if SSCG is enabled".
Without this fix the deviation measured on a Mirabox was of a few
second each hour, whereas with this fix it was reduced at around
50ppm (around 4s per day).
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Link: https://lkml.kernel.org/r/1409645719-20003-3-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
When the SSCG (Spread Spectrum Clock Generator) is enabled, it shifts
the frequency of the clock. The percentage is no more than 1% but when
the clock is used for a timer it leads to a clock drift.
This patch allows to correct the affected clock when the SSCG is
enabled. The check is done in an new optional function related to each
SoC: is_sscg_enabled(). The fix is done with the other new optional
function related to each SoC: fix_sscg_deviation. If one these
functions are not present then no correction is done on the clock
frequency.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Link: https://lkml.kernel.org/r/1409645719-20003-2-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
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: 71472c0c06cf ("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: Mike Turquette <mturquette@linaro.org>
|
|
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: Doug Anderson <dianders@chromium.org>
Reported-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
into clk-fixes
|
|
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: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
