linux-stable.git/include/linux/clk-private.h, branch master

clk: remove clk-private.h

2015-02-02T22:23:41+00:00

Private clock framework data structures should be private, surprisingly.

Now that all platforms and drivers have been updated to remove static
initializations of struct clk and struct clk_core objects and all
references to clk-private.h have been removed we can move the
definitions of these structures into drivers/clk/clk.c and delete the
header.

Additionally the ugly DEFINE_CLK macros have been removed. Those were
used for static definitions of struct clk objects. That practice is no
longer allowed.

Finally __clk_init is staticized as it is no longer declared in any
header.

Reviewed-by: Stephen Boyd 
Signed-off-by: Michael Turquette

clk: Make clk API return per-user struct clk instances

2015-02-02T22:22:19+00:00

Moves clock state to struct clk_core, but takes care to change as little API as
possible.

struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.

The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.

Because some boards in mach-omap2 still register clocks statically, their clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Stephen Boyd 
Tested-by: Tony Lindgren 
Signed-off-by: Michael Turquette 
[mturquette@linaro.org: adapted clk_has_parent to struct clk_core
                        applied OMAP3+ DPLL fix from Tero & Tony]

clk: Remove __clk_register

2015-01-28T18:40:18+00:00

As it has never been used.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Stephen Boyd 
Signed-off-by: Michael Turquette

Merge tag 'sunxi-clocks-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into clk-next

2014-09-27T19:52:33+00:00

Allwinner Clocks Additions for 3.18

The most important part of this serie is the addition of the phase API to
handle the MMC clocks in the Allwinner SoCs.

Apart from that, the A23 gained a new mbus driver, and there's a fix for a
incorrect divider table on the APB0 clock.

clk: introduce clk_set_phase function & callback

2014-09-27T06:57:38+00:00

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 
Signed-off-by: Maxime Ripard 
Reviewed-by: Heiko Stuebner 
Acked-by: Hans de Goede

clk: Don't hold prepare_lock across debugfs creation

2014-09-10T21:36:20+00:00

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: [] clk_prepare_lock+0x88/0xfc

but task is already holding lock:
 (qcom_iommu_lock){+.+...}, at: [] 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){+.+...}:
       [] qcom_iommu_map+0x28/0x450
       [] iommu_map+0xc8/0x12c
       [] msm_iommu_map+0xb4/0x130
       [] msm_gem_get_iova_locked+0x9c/0xe8
       [] msm_gem_get_iova+0x4c/0x64
       [] mdp4_kms_init+0x4c4/0x6c0
       [] msm_load+0x2ac/0x34c
       [] drm_dev_register+0xac/0x108
       [] drm_platform_init+0x50/0xf0
       [] try_to_bring_up_master.part.3+0xc8/0x108
       [] component_master_add_with_match+0xa8/0x104
       [] msm_pdev_probe+0x64/0x70
       [] platform_drv_probe+0x2c/0x60
       [] driver_probe_device+0x108/0x234
       [] bus_for_each_drv+0x64/0x98
       [] device_attach+0x78/0x8c
       [] bus_probe_device+0x88/0xac
       [] deferred_probe_work_func+0x68/0x9c
       [] process_one_work+0x1a0/0x40c
       [] worker_thread+0x44/0x4d8
       [] kthread+0xd8/0xec
       [] ret_from_fork+0x14/0x2c

-> #3 (&dev->struct_mutex){+.+.+.}:
       [] drm_gem_mmap+0x38/0xd0
       [] msm_gem_mmap+0xc/0x5c
       [] mmap_region+0x35c/0x6c8
       [] do_mmap_pgoff+0x314/0x398
       [] vm_mmap_pgoff+0x84/0xb4
       [] SyS_mmap_pgoff+0x94/0xbc
       [] ret_fast_syscall+0x0/0x48

-> #2 (&mm->mmap_sem){++++++}:
       [] filldir64+0x68/0x180
       [] dcache_readdir+0x188/0x22c
       [] iterate_dir+0x9c/0x11c
       [] SyS_getdents64+0x78/0xe8
       [] ret_fast_syscall+0x0/0x48

-> #1 (&sb->s_type->i_mutex_key#3){+.+.+.}:
       [] __create_file+0x58/0x1dc
       [] debugfs_create_dir+0x1c/0x24
       [] clk_debug_create_subtree+0x20/0x170
       [] clk_debug_init+0xec/0x14c
       [] do_one_initcall+0x8c/0x1c8
       [] kernel_init_freeable+0x13c/0x1dc
       [] kernel_init+0x8/0xe8
       [] ret_from_fork+0x14/0x2c

-> #0 (prepare_lock){+.+.+.}:
       [] mutex_lock_nested+0x70/0x3e8
       [] clk_prepare_lock+0x88/0xfc
       [] clk_prepare+0xc/0x24
       [] __enable_clocks.isra.4+0x18/0xa4
       [] __flush_iotlb_va+0xe0/0x114
       [] qcom_iommu_unmap+0xac/0x1f0
       [] iommu_unmap+0x9c/0xe8
       [] msm_iommu_unmap+0x64/0x84
       [] msm_gem_free_object+0x11c/0x338
       [] drm_gem_object_handle_unreference_unlocked+0xfc/0x130
       [] drm_gem_object_release_handle+0x50/0x68
       [] idr_for_each+0xa8/0xdc
       [] drm_gem_release+0x1c/0x28
       [] drm_release+0x370/0x428
       [] __fput+0x98/0x1e8
       [] task_work_run+0xb0/0xfc
       [] do_exit+0x2ec/0x948
       [] do_group_exit+0x4c/0xb8
       [] get_signal+0x28c/0x6ac
       [] do_signal+0xc4/0x3e4
       [] do_work_pending+0xb4/0xc4
       [] 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: [] drm_release+0x34/0x428
 #1:  (&dev->struct_mutex){+.+.+.}, at: [] drm_gem_object_handle_unreference_unlocked+0xcc/0x130
 #2:  (qcom_iommu_lock){+.+...}, at: [] qcom_iommu_unmap+0x1c/0x1f0

stack backtrace:
CPU: 1 PID: 5413 Comm: Xorg.bin Tainted: G        W      3.17.0-rc1-00050-g07a489b #802
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x98/0xb8)
[] (dump_stack) from [] (print_circular_bug+0x218/0x340)
[] (print_circular_bug) from [] (__lock_acquire+0x1d24/0x20b8)
[] (__lock_acquire) from [] (lock_acquire+0x9c/0xbc)
[] (lock_acquire) from [] (mutex_lock_nested+0x70/0x3e8)
[] (mutex_lock_nested) from [] (clk_prepare_lock+0x88/0xfc)
[] (clk_prepare_lock) from [] (clk_prepare+0xc/0x24)
[] (clk_prepare) from [] (__enable_clocks.isra.4+0x18/0xa4)
[] (__enable_clocks.isra.4) from [] (__flush_iotlb_va+0xe0/0x114)
[] (__flush_iotlb_va) from [] (qcom_iommu_unmap+0xac/0x1f0)
[] (qcom_iommu_unmap) from [] (iommu_unmap+0x9c/0xe8)
[] (iommu_unmap) from [] (msm_iommu_unmap+0x64/0x84)
[] (msm_iommu_unmap) from [] (msm_gem_free_object+0x11c/0x338)
[] (msm_gem_free_object) from [] (drm_gem_object_handle_unreference_unlocked+0xfc/0x130)
[] (drm_gem_object_handle_unreference_unlocked) from [] (drm_gem_object_release_handle+0x50/0x68)
[] (drm_gem_object_release_handle) from [] (idr_for_each+0xa8/0xdc)
[] (idr_for_each) from [] (drm_gem_release+0x1c/0x28)
[] (drm_gem_release) from [] (drm_release+0x370/0x428)
[] (drm_release) from [] (__fput+0x98/0x1e8)
[] (__fput) from [] (task_work_run+0xb0/0xfc)
[] (task_work_run) from [] (do_exit+0x2ec/0x948)
[] (do_exit) from [] (do_group_exit+0x4c/0xb8)
[] (do_group_exit) from [] (get_signal+0x28c/0x6ac)
[] (get_signal) from [] (do_signal+0xc4/0x3e4)
[] (do_signal) from [] (do_work_pending+0xb4/0xc4)
[] (do_work_pending) from [] (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 
Signed-off-by: Mike Turquette

Merge branch 'clk-next-unregister' into clk-next

2013-12-31T19:35:12+00:00

Conflicts:
	drivers/clk/clk.c

clk: remove CONFIG_COMMON_CLK_DEBUG

2013-12-28T01:45:08+00:00

Populate ${DEBUGS_MOUNT_POINT}/clk if CONFIG_DEBUG_FS is set. This
eliminates the extra (annoying) step of enabling the config option
manually.

Signed-off-by: Mike Turquette

clk: add clk accuracy retrieval support

2013-12-23T07:14:27+00:00

The clock accuracy is expressed in ppb (parts per billion) and represents
the possible clock drift.
Say you have a clock (e.g. an oscillator) which provides a fixed clock of
20MHz with an accuracy of +- 20Hz. This accuracy expressed in ppb is
20Hz/20MHz = 1000 ppb (or 1 ppm).

Clock users may need the clock accuracy information in order to choose
the best clock (the one with the best accuracy) across several available
clocks.

This patch adds clk accuracy retrieval support for common clk framework by
means of a new function called clk_get_accuracy.
This function returns the given clock accuracy expressed in ppb.

In order to get the clock accuracy, this implementation adds one callback
called recalc_accuracy to the clk_ops structure.
This callback is given the parent clock accuracy (if the clock is not a
root clock) and should recalculate the given clock accuracy.

This callback is optional and may be implemented if the clock is not
a perfect clock (accuracy != 0 ppb).

Signed-off-by: Boris BREZILLON 
Signed-off-by: Mike Turquette

clk: Implement clk_unregister

2013-12-04T16:19:52+00:00

clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park