user/sven/linux.git/drivers/cpufreq, branch v3.6.9

cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code

2012-10-31T17:10:22Z

commit e4df1cbcc1f329e53a1fff7450b2229e0addff20 upstream. Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU) causes powernow-k8 to trigger a preempt warning, e.g.: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776 caller is powernowk8_target+0x20/0x49 Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9 Call Trace: [] debug_smp_processor_id+0xc7/0xe0 [] powernowk8_target+0x20/0x49 [] __cpufreq_driver_target+0x82/0x8a [] cpufreq_governor_performance+0x4e/0x54 [] __cpufreq_governor+0x8c/0xc9 [] __cpufreq_set_policy+0x1a9/0x21e [] store_scaling_governor+0x16f/0x19b [] ? cpufreq_update_policy+0x124/0x124 [] ? _raw_spin_unlock_irqrestore+0x2c/0x49 [] store+0x60/0x88 [] sysfs_write_file+0xf4/0x130 [] vfs_write+0xb5/0x151 [] sys_write+0x4a/0x71 [] system_call_fastpath+0x16/0x1b Fix this by by always using work_on_cpu(). Signed-off-by: Andreas Herrmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2012-09-19T18:00:07Z

Pull workqueue / powernow-k8 fix from Tejun Heo: "This is the fix for the bug where cpufreq/powernow-k8 was tripping BUG_ON() in try_to_wake_up_local() by migrating workqueue worker to a different CPU. https://bugzilla.kernel.org/show_bug.cgi?id=47301 As discussed, the fix is now two parts - one to reimplement work_on_cpu() so that it doesn't create a new kthread each time and the actual fix which makes powernow-k8 use work_on_cpu() instead of performing manual migration. While pretty late in the merge cycle, both changes are on the safer side. Jiri and I verified two existing users of work_on_cpu() and Duncan confirmed that the powernow-k8 fix survived about 18 hours of testing." * 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU workqueue: reimplement work_on_cpu() using system_wq

cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU

2012-09-19T17:15:01Z

powernowk8_target() runs off a per-cpu work item and if the cpufreq_policy->cpu is different from the current one, it migrates the kworker to the target CPU by manipulating current->cpus_allowed. The function migrates the kworker back to the original CPU but this is still broken. Workqueue concurrency management requires the kworkers to stay on the same CPU and powernowk8_target() ends up triggerring BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on fidvid_mutex and sleeps. It is unclear why this bug is being reported now. Duncan says it appeared to be a regression of 3.6-rc1 and couldn't reproduce it on 3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool instead of @gcwq or @cpu where applicable" which is an non-functional change. Given that the reproduce case sometimes took upto days to trigger, it's easy to be misled while bisecting. Maybe something made contention on fidvid_mutex more likely? I don't know. This patch fixes the bug by using work_on_cpu() instead if @pol->cpu isn't the same as the current one. The code assumes that cpufreq_policy->cpu is kept online by the caller, which Rafael tells me is the case. stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using system_wq") should be applied before this; otherwise, the behavior could be horrible. Signed-off-by: Tejun Heo Reported-by: Duncan <1i5t5.duncan@cox.net> Tested-by: Duncan <1i5t5.duncan@cox.net> Cc: Rafael J. Wysocki Cc: Andreas Herrmann Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301

Merge branch 'imx/fixes-for-3.6' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

2012-08-23T15:02:42Z

* 'imx/fixes-for-3.6' of git://git.linaro.org/people/shawnguo/linux-2.6: ARM: dts: imx51-babbage: fix esdhc cd/wp properties ARM: imx6: spin the cpu until hardware takes it down ARM i.MX6q: Add virtual 1/3.5 dividers in the LDB clock path Also updates to Linux 3.6-rc2 Signed-off-by: Arnd Bergmann

cpufreq: OMAP: Handle missing frequency table on SMP systems

2012-08-09T15:07:47Z

On OMAP4, if the first CPU fails to get a valid frequency table (this could happen if the platform does not register any OPP table), the subsequent CPU instances end up dealing with a NULL freq_table and crash. Check for an already existing freq_table, before trying to create one, and increment the freq_table_users only if the table is sucessfully created. Signed-off-by: Rajendra Nayak Signed-off-by: Santosh Shilimkar Cc: Signed-off-by: Kevin Hilman

drivers/cpufreq/pcc-cpufreq.c: fix error return code

2012-08-08T18:49:25Z

Convert a 0 error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ identifier ret; expression e,e1,e2,e3,e4,x; @@ ( if (\(ret != 0\|ret < 0\) || ...) { ... return ...; } | ret = 0 ) ... when != ret = e1 *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...); ... when != x = e2 when != ret = e3 *if (x == NULL || ...) { ... when != ret = e4 * return ret; } // Signed-off-by: Julia Lawall Signed-off-by: Rafael J. Wysocki

Merge tag 'soc2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2012-07-30T16:45:53Z

Pull arm-soc soc updates from Olof Johansson: "This is the second batch of SoC updates for the 3.6 merge window, containing parts that arrived close to the merge window opening and thus needed to sit in linux-next for a while. Most contents is updates of Renesas shmobile, with a couple of Samsung Exynos patches in the mix." * tag 'soc2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (39 commits) ARM: S3C64XX: Add header file protection macros in pm-core.h [CPUFREQ] EXYNOS5250: Add support max 1.7GHz for EXYNOS5250 ARM: EXYNOS: Add G2D related clock entries for SMDK4X12 ARM: EXYNOS: Move G2D clock entries to clock-exynos4210.c file ARM: shmobile: Fix build problem in pm-sh7372.c for unusual .config ARM: shmobile: Take cpuidle dependencies into account correctly ARM: mach-shmobile: sh7377 generic board support via DT ARM: mach-shmobile: r8a7740 generic board support via DT ARM: shmobile: sh7372: completely switch over to using pm-rmobile API ARM: shmobile: ap4evb: switch to using pm-rmobile API ARM: shmobile: mackerel: switch to using pm-rmobile API ARM: shmobile: sh7372: add pm-rmobile domain support ARM: shmobile: r8a7740: add A4LC pm domain support ARM: shmobile: r8a7740: add A3SP pm domain support ARM: shmobile: r8a7740: add A4S pm domain support ARM: shmobile: r8a7740: fixup: MSEL1CR 7bit control ARM: shmobile: soc-core: add R-mobile PM domain common APIs ARM: shmobile: sh7372 A3SM CPUIdle support ARM: shmobile: Use INTCA with sh7372 A3SM power domain ARM: mach-shmobile: Convert sh_clk_mstp32_register to sh_clk_mstp_register ...

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial

2012-07-24T20:34:56Z

Pull trivial tree from Jiri Kosina: "Trivial updates all over the place as usual." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (29 commits) Fix typo in include/linux/clk.h . pci: hotplug: Fix typo in pci iommu: Fix typo in iommu video: Fix typo in drivers/video Documentation: Add newline at end-of-file to files lacking one arm,unicore32: Remove obsolete "select MISC_DEVICES" module.c: spelling s/postition/position/g cpufreq: Fix typo in cpufreq driver trivial: typo in comment in mksysmap mach-omap2: Fix typo in debug message and comment scsi: aha152x: Fix sparse warning and make printing pointer address more portable. Change email address for Steve Glendinning Btrfs: fix typo in convert_extent_bit via: Remove bogus if check netprio_cgroup.c: fix comment typo backlight: fix memory leak on obscure error path Documentation: asus-laptop.txt references an obsolete Kconfig item Documentation: ManagementStyle: fixed typo mm/vmscan: cleanup comment error in balance_pgdat mm: cleanup on the comments of zone_reclaim_stat ...

cpufreq: Fix sysfs deadlock with concurrent hotplug/frequency switch

2012-07-20T19:39:25Z

Running one program that continuously hotplugs and replugs a cpu concurrently with another program that continuously writes to the scaling_setspeed node eventually deadlocks with: ============================================= [ INFO: possible recursive locking detected ] 3.4.0 #37 Tainted: G W --------------------------------------------- filemonkey/122 is trying to acquire lock: (s_active#13){++++.+}, at: [] sysfs_remove_dir+0x9c/0xb4 but task is already holding lock: (s_active#13){++++.+}, at: [] sysfs_write_file+0xe8/0x140 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(s_active#13); lock(s_active#13); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by filemonkey/122: #0: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x28/0x140 #1: (s_active#13){++++.+}, at: [] sysfs_write_file+0xe8/0x140 stack backtrace: [] (unwind_backtrace+0x0/0x120) from [] (validate_chain+0x6f8/0x1054) [] (validate_chain+0x6f8/0x1054) from [] (__lock_acquire+0x81c/0x8d8) [] (__lock_acquire+0x81c/0x8d8) from [] (lock_acquire+0x18c/0x1e8) [] (lock_acquire+0x18c/0x1e8) from [] (sysfs_addrm_finish+0xd0/0x180) [] (sysfs_addrm_finish+0xd0/0x180) from [] (sysfs_remove_dir+0x9c/0xb4) [] (sysfs_remove_dir+0x9c/0xb4) from [] (kobject_del+0x10/0x38) [] (kobject_del+0x10/0x38) from [] (kobject_release+0xf0/0x194) [] (kobject_release+0xf0/0x194) from [] (cpufreq_cpu_put+0xc/0x24) [] (cpufreq_cpu_put+0xc/0x24) from [] (store+0x6c/0x74) [] (store+0x6c/0x74) from [] (sysfs_write_file+0x10c/0x140) [] (sysfs_write_file+0x10c/0x140) from [] (vfs_write+0xb0/0x128) [] (vfs_write+0xb0/0x128) from [] (sys_write+0x3c/0x68) [] (sys_write+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c) This is because store() in cpufreq.c indirectly calls kobject_get() via cpufreq_cpu_get() and is the last one to call kobject_put() via cpufreq_cpu_put(). Sysfs code should not call kobject_get() or kobject_put() directly (see the comment around sysfs_schedule_callback() for more information). Fix this deadlock by introducing two new functions: struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu) void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data) which do the same thing as cpufreq_cpu_{get,put}() but don't call kobject functions. To easily trigger this deadlock you can insert an msleep() with a reasonably large value right after the fail label at the bottom of the store() function in cpufreq.c and then write scaling_setspeed in one task and offline the cpu in another. The first task will hang and be detected by the hung task detector. Signed-off-by: Stephen Boyd Signed-off-by: Rafael J. Wysocki

EXYNOS: bugfix on retrieving old_index from freqs.old

2012-07-20T09:58:34Z

The policy might have been changed since last call of target(). Thus, using cpufreq_frequency_table_target(), which depends on policy to find the corresponding index from a frequency, may return inconsistent index for freqs.old. Thus, old_index should be calculated not based on the current policy. We have been observing such issue when scaling_min/max_freq were updated and sometimes cuased system lockups deu to incorrectly configured voltages. Signed-off-by: MyungJoo Ham Signed-off-by: Rafael J. Wysocki