1. 27 Sep, 2014 7 commits
  2. 26 Sep, 2014 2 commits
    • Mike Turquette's avatar
      asm-generic: COMMON_CLK defines __clk_{get,put} · b52f4914
      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: default avatarMike Turquette <mturquette@linaro.org>
      b52f4914
    • Kiran Padwal's avatar
      clk: Remove .owner field for driver · 59c0621d
      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: default avatarKiran Padwal <kiran.padwal@smartplayin.com>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      59c0621d
  3. 25 Sep, 2014 7 commits
  4. 17 Sep, 2014 1 commit
  5. 10 Sep, 2014 4 commits
    • Mike Turquette's avatar
      0469a43b
    • Stephen Boyd's avatar
      clk: Don't hold prepare_lock across debugfs creation · 6314b679
      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: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      6314b679
    • Heiko Stübner's avatar
      clk: rockchip: also protect hclk_peri as critical · 2fed71e5
      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: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      2fed71e5
    • Heiko Stübner's avatar
      clk: fractional-divider: cast parent_rate to u64 before multiplying · feaefa0e
      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: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      feaefa0e
  6. 09 Sep, 2014 10 commits
  7. 03 Sep, 2014 3 commits
  8. 02 Sep, 2014 6 commits