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: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>

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: NHeiko Stuebner <heiko@sntech.de>

In RK3288, APLL lock status bit is in GRF_SOC_STATUS1,
but in RK3188, is GRFSOC_STATUS0.
Signed-off-by: NJianqun <jay.xu@rock-chips.com>

Also name the constant accordingly as GRF_SOC_STATUS1
to prevent confusion.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>

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: NHeiko Stuebner <heiko@sntech.de>

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: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

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: NKiran Padwal <kiran.padwal@smartplayin.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

This patch add the clock node in PD_VIDEO
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

This patch use the new defined clock ID to initial the clock nodes.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike 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: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NKever Yang <kever.yang@rock-chips.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The rk3288 actually has 12 softresets, so fix the register count.
Signed-off-by: NMark yao <mark.yao@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMike 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: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike 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: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike 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: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMike 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: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMike 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: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMike 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: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NBryan Hundven <bryanhundven@gmail.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Use __initconst instead of __initdata for constant init data.
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NMike 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: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NTero Kristo <t-kristo@ti.com>
Reported-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NMike 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: NDoug Anderson <dianders@chromium.org>
Reported-by: NAddy Ke <addy.ke@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Test rate value before calculating the div value to avoid div by zero.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NGaël PORTAY <gael.portay@gmail.com>
Tested-by: NGaël PORTAY <gael.portay@gmail.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NGaël PORTAY <gael.portay@gmail.com>
Tested-by: NGaël PORTAY <gael.portay@gmail.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NGaël PORTAY <gael.portay@gmail.com>
Tested-by: NGaël PORTAY <gael.portay@gmail.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NGaël PORTAY <gael.portay@gmail.com>
Tested-by: NGaël PORTAY <gael.portay@gmail.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NGaël PORTAY <gael.portay@gmail.com>
Tested-by: NGaël PORTAY <gael.portay@gmail.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NKever Yang <kever.yang@rock-chips.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

It is only used locally in clk/rockchip/clk.c and thus can be static.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

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: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The slow clk block provided by at91sam9260 and derived SoCs should always
have 2 parents.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Kirkwood is unique among the mvebu SoCs for having a clock multiplexer
that feeds into the cpu. This multiplexer can select either the cpu pll
or the ddr clock as its input signal, allowing for a choice between
performance and power savings.

This patch introduces the code needed to register the clock multiplexer
on Kirkwood SoCs but does not include the clock data to actually
register the clock. That will be done in a follow-up patch which is
necessary to prevent breaking git bisect.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Refactor mvebu_clk_gating_setup() to use a common spinlock instead of a
unique lock for every instance of a struct clk_gating_ctrl object. This
will be used later for a separate mux clock type that shares a register
with gate clock types and needs to use the same lock to protect access
to the register.

Cc: Andrew Lunn <andrew@lunn.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Check for valid parameters in check rate. Else, we end up getting
errors.

This occurs as part of the inital clock tree update of child clock
nodes where new_rate could be 0 for non functional clocks.

Fixes: 9ac33b0c (" CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>

Check for valid parameters in check rate. Else, we end up getting errors
like:
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc1 #1
[    0.000000] [<c0015160>] (unwind_backtrace) from [<c0011978>] (show_stack+0x10/0x14)
[    0.000000] [<c0011978>] (show_stack) from [<c055f5f4>] (dump_stack+0x78/0x94)
[    0.000000] [<c055f5f4>] (dump_stack) from [<c02e17cc>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02e17cc>] (Ldiv0) from [<c047d228>] (ti_clk_divider_set_rate+0x14/0x14c)
[    0.000000] [<c047d228>] (ti_clk_divider_set_rate) from [<c047a938>] (clk_change_rate+0x138/0x180)
[    0.000000] [<c047a938>] (clk_change_rate) from [<c047a908>] (clk_change_rate+0x108/0x180)

This occurs as part of the inital clock tree update of child clock nodes
where new_rate could be 0 for non functional clocks.

Fixes: b4761198 ("CLK: ti: add support for ti divider-clock")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>

The of_clk_set_defaults() function is used in subsystems which can
be built as module. Add the missing symbol export entry so there
is no build errors like:
"ERROR: "of_clk_set_defaults" [drivers/i2c/i2c-core.ko] undefined!".

Fixes commit: 86be408b
"clk: Support for clock parents and rates assigned from device tree"
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NMike Turquette <mturquette@linaro.org>