linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH V4 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus glue

by Manjunath Goudar

Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. V3: -New patch 1/11 added, for generic ohci-hcd suspend code. V4: -Properly aligned "do_wakeup" and "ret" variables. Manjunath Goudar (11): USB: OHCI: Properly handle OHCI controller suspend USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 10 ++++++++-- drivers/usb/host/ohci-da8xx.c | 15 +++++++++++---- drivers/usb/host/ohci-ep93xx.c | 9 ++++++++- drivers/usb/host/ohci-exynos.c | 20 +++++--------------- drivers/usb/host/ohci-hcd.c | 9 ++++++++- drivers/usb/host/ohci-omap.c | 13 ++++++++++--- drivers/usb/host/ohci-platform.c | 9 ++++++++- drivers/usb/host/ohci-pxa27x.c | 8 +++++++- drivers/usb/host/ohci-s3c2410.c | 19 ++++--------------- drivers/usb/host/ohci-sm501.c | 11 +++++++++-- drivers/usb/host/ohci-spear.c | 12 +++++++++--- 11 files changed, 87 insertions(+), 48 deletions(-) -- 1.7.9.5

12 years

[PATCH 0/7] KVM: arm-vgic: Implement save/restore of VGIC state

by Christoffer Dall

This patch series adds support for user space save/restore of the VGIC state. Instead of expanding the ONE_REG interface, which works on VCPUs, we first introduce support for the new KVM device control API and the VGIC. Now, instead of calling KVM_CREATE_IRQCHIP, user space can call KVM_CREATE_DEVICE and perform operations on the device fd, such as KVM_SET_DEVICE_ATTR to set a device attribute. We leverage the KVM_{SET/GET}_DEVICE_ATTR API to export the state of the VGIC to user space. Instead of coming up with our own custom format for exporting the VGIC state, we simply export all the state visible to an emulated guest, which must contain the full GIC state to provide save/restore of the GIC state for power management purposes. This further provides the benefit of being able to re-use the MMIO emulation code for the distributor for save/restore. However, the need to save/restore cpu-specific state demands that user space can save/restore state accessible through the CPU interface, and we therefore add an emulation interface for the CPU-specific interface. This is considered a first attempt, and I am not married to the device control API. If there are good technical arguments to take another approach, I am of course willing to discuss this. However, my attempts with the ONE_REG interface did not look very nice. [ WARINING: The patch set core functionality is completely untested; the basic KVM system has been briefly tested on TC2 and it doesn't seem like I've broken existing functionality. ] I wanted to get this out early to get feedback on the overall API and idea, and I'm writing some user QEMU for the user space side to test the new functionality meanwhile. Patches are against kvm-arm-next and also available here: git://git.linaro.org/people/cdall/linux-kvm-arm.git vgic-migrate Christoffer Dall (7): KVM: arm-vgic: Support KVM_CREATE_DEVICE for VGIC KVM: arm-vgic: Set base addr through device API irqchip: arm-gic: Define additional MMIO offsets and masks KVM: arm-vgic: Make vgic mmio functions more generic KVM: arm-vgic: Add vgic reg access from dev attr KVM: arm-vgic: Add GICD_SPENDSGIR and GICD_CPENDSGIR handlers KVM: arm-vgic: Support CPU interface reg access Documentation/virtual/kvm/api.txt | 5 +- Documentation/virtual/kvm/devices/arm-vgic.txt | 52 +++ arch/arm/include/uapi/asm/kvm.h | 8 + arch/arm/kvm/arm.c | 3 +- include/kvm/arm_vgic.h | 2 +- include/linux/irqchip/arm-gic.h | 14 + include/linux/kvm_host.h | 1 + include/uapi/linux/kvm.h | 1 + virt/kvm/arm/vgic.c | 452 +++++++++++++++++++++++- virt/kvm/kvm_main.c | 4 + 10 files changed, 522 insertions(+), 20 deletions(-) create mode 100644 Documentation/virtual/kvm/devices/arm-vgic.txt -- 1.7.9.5

12 years

[PATCH V3 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus glue

by Manjunath Goudar

Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. V3: -New patch 1/11 added, for generic ohci-hcd suspend code. Manjunath Goudar (11): USB: OHCI: Properly handle OHCI controller suspend USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 10 ++++++++-- drivers/usb/host/ohci-da8xx.c | 17 ++++++++++++----- drivers/usb/host/ohci-ep93xx.c | 10 +++++++++- drivers/usb/host/ohci-exynos.c | 24 +++++++----------------- drivers/usb/host/ohci-hcd.c | 9 ++++++++- drivers/usb/host/ohci-omap.c | 13 ++++++++++--- drivers/usb/host/ohci-platform.c | 9 ++++++++- drivers/usb/host/ohci-pxa27x.c | 8 +++++++- drivers/usb/host/ohci-s3c2410.c | 19 ++++--------------- drivers/usb/host/ohci-sm501.c | 11 +++++++++-- drivers/usb/host/ohci-spear.c | 12 +++++++++--- 11 files changed, 91 insertions(+), 51 deletions(-) -- 1.7.9.5

12 years

[GIT PULL] CPUFreq Kconfig Fixes: Select CPU_FREQ_TABLE

by Viresh Kumar

Hi Rafael, The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.linaro.org/people/vireshk/linux.git cpufreq-kconfig-fixes for you to fetch changes up to dbcc9f845efc604564f34a5fa62f939c2bebfff6: cpufreq: X86_AMD_FREQ_SENSITIVITY: select CPU_FREQ_TABLE (2013-06-18 13:53:11 +0530) ---------------------------------------------------------------- Viresh Kumar (11): cpufreq: blackfin: enable driver for CONFIG_BFIN_CPU_FREQ cpufreq: cris: select CPU_FREQ_TABLE cpufreq: davinci: select CPU_FREQ_TABLE cpufreq: exynos: select CPU_FREQ_TABLE cpufreq: highbank: remove select CPU_FREQ_TABLE cpufreq: imx: select CPU_FREQ_TABLE cpufreq: powerpc: CBE_RAS: select CPU_FREQ_TABLE cpufreq: pxa: select CPU_FREQ_TABLE cpufreq: S3C2416/S3C64XX: select CPU_FREQ_TABLE cpufreq: tegra: create CONFIG_ARM_TEGRA_CPUFREQ cpufreq: X86_AMD_FREQ_SENSITIVITY: select CPU_FREQ_TABLE arch/arm/mach-davinci/Kconfig | 1 + arch/arm/mach-pxa/Kconfig | 3 +++ arch/arm/mach-tegra/Kconfig | 3 --- arch/cris/Kconfig | 2 ++ drivers/cpufreq/Kconfig.arm | 14 +++++++++++++- drivers/cpufreq/Kconfig.powerpc | 1 + drivers/cpufreq/Kconfig.x86 | 1 + drivers/cpufreq/Makefile | 4 ++-- 8 files changed, 23 insertions(+), 6 deletions(-) -- viresh

12 years

[PATCH 1/2] sched/nohz: add sysctl control over sched_tick_max_deferment

by Kevin Hilman

Allow sysctl override of sched_tick_max_deferment in order to ease finding/fixing the remaining issues with full nohz. The value to be written is in jiffies, and -1 means the max deferment is disabled (scheduler_tick_max_deferment() returns KTIME_MAX.) Cc: Frederic Weisbecker <fweisbec(a)gmail.com> Signed-off-by: Kevin Hilman <khilman(a)linaro.org> --- include/linux/sched/sysctl.h | 3 +++ kernel/sched/core.c | 6 +++++- kernel/sched/debug.c | 1 + kernel/sysctl.c | 9 +++++++++ 4 files changed, 18 insertions(+), 1 deletion(-) diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h index bf8086b..2ad07bb 100644 --- a/include/linux/sched/sysctl.h +++ b/include/linux/sched/sysctl.h @@ -57,6 +57,9 @@ extern unsigned int sysctl_sched_nr_migrate; extern unsigned int sysctl_sched_time_avg; extern unsigned int sysctl_timer_migration; extern unsigned int sysctl_sched_shares_window; +#ifdef CONFIG_NO_HZ_FULL +extern unsigned int sysctl_sched_tick_max_deferment; +#endif int sched_proc_update_handler(struct ctl_table *table, int write, void __user *buffer, size_t *length, diff --git a/kernel/sched/core.c b/kernel/sched/core.c index e1a27f9..b5d3f99 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2751,12 +2751,16 @@ void scheduler_tick(void) * balancing, etc... continue to move forward, even * with a very low granularity. */ +unsigned int sysctl_sched_tick_max_deferment = HZ; u64 scheduler_tick_max_deferment(void) { struct rq *rq = this_rq(); unsigned long next, now = ACCESS_ONCE(jiffies); - next = rq->last_sched_tick + HZ; + if (sysctl_sched_tick_max_deferment == -1) + return KTIME_MAX; + + next = rq->last_sched_tick + sysctl_sched_tick_max_deferment; if (time_before_eq(next, now)) return 0; diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 75024a6..f445ab9 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -374,6 +374,7 @@ static void sched_debug_header(struct seq_file *m) PN(sysctl_sched_wakeup_granularity); P(sysctl_sched_child_runs_first); P(sysctl_sched_features); + P(sysctl_sched_tick_max_deferment); #undef PN #undef P diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 9edcf45..fb0b7d8 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -393,6 +393,15 @@ static struct ctl_table kern_table[] = { .proc_handler = proc_dointvec, }, #endif /* CONFIG_NUMA_BALANCING */ +#ifdef CONFIG_NO_HZ_FULL + { + .procname = "sched_tick_max_deferment", + .data = &sysctl_sched_tick_max_deferment, + .maxlen = sizeof(unsigned int), + .mode = 0644, + .proc_handler = proc_dointvec, + }, +#endif /* CONFIG_NO_HZ_FULL */ #endif /* CONFIG_SCHED_DEBUG */ { .procname = "sched_rt_period_us", -- 1.8.3

12 years

[PATCH 00/16] Support for per policy instance of Interactive governor

by Viresh Kumar

Hi Todd and others, If we have a multi-package system, where we have multiple instances of struct policy (per package), currently we can't have multiple instances of same governor. i.e. We can't have multiple instances of Interactive governor for multiple packages. This is a bottleneck for multicluster system, where we want different packages to use Interactive governor, but with different tunables. ---------x------------x--------- Recently, I have upstreamed this support in 3.10-rc1 for cpufreq core, Ondemand and Conservative governor. Now is an attempt for Interactive Governor. I didn't had any clue on what kernel to rebase my patches over as I couldn't find a 3.10-rc based branch in your tree and so based it on experimental/android-3.9. So, this is what this patchset does: - Backports some important patches from v3.10-rc1/2 to v3.9: First 8 patches - Added few more supportive patches which might go in rc3: Next 4 patches - Finally updated Interactive governor: Last 4 patches So, Review is probably required only for last 4 patches. The last patch is a bit long, it is mostly rearrangement of the code rather then major update. It is based on the patchset which I wrote for Ondemand/Conservative governor. This has been tested on ARM big LITTLE platform which has multiple packages requiring separate tunables. Nathan Zimmer (1): cpufreq: Convert the cpufreq_driver_lock to a rwlock Stratos Karafotis (1): cpufreq: governors: Calculate iowait time only when necessary Viresh Kumar (14): cpufreq: Add per policy governor-init/exit infrastructure cpufreq: governor: Implement per policy instances of governors cpufreq: Call __cpufreq_governor() with correct policy->cpus mask cpufreq: Don't call __cpufreq_governor() for drivers without target() cpufreq: governors: Fix CPUFREQ_GOV_POLICY_{INIT|EXIT} notifiers cpufreq: Issue CPUFREQ_GOV_POLICY_EXIT notifier before dropping policy refcount cpufreq: Add EXPORT_SYMBOL_GPL for have_governor_per_policy cpufreq: governors: Move get_governor_parent_kobj() to cpufreq.c cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT cpufreq: Move get_cpu_idle_time() to cpufreq.c cpufreq: interactive: Use generic get_cpu_idle_time() from cpufreq.c cpufreq: interactive: Remove unnecessary cpu_online() check cpufreq: interactive: Move definition of cpufreq_gov_interactive downwards cpufreq: Interactive: Implement per policy instances of governor drivers/cpufreq/cpufreq.c | 157 ++++++-- drivers/cpufreq/cpufreq_conservative.c | 195 ++++++---- drivers/cpufreq/cpufreq_governor.c | 273 +++++++------- drivers/cpufreq/cpufreq_governor.h | 120 +++++- drivers/cpufreq/cpufreq_interactive.c | 663 +++++++++++++++++++-------------- drivers/cpufreq/cpufreq_ondemand.c | 274 ++++++++------ include/linux/cpufreq.h | 19 +- 7 files changed, 1043 insertions(+), 658 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years

[PATCH 0/3] sched: Sched Domains: Fixups - Part 3

by Viresh Kumar

Hi Peter/Ingo, This set contains few more minor fixes that I could find for code responsible for creating sched domains. They are rebased of my earlier fixes: Part 1: https://lkml.org/lkml/2013/6/4/253 Part 2: https://lkml.org/lkml/2013/6/10/141 They should be applied in this order to avoid conflicts. My study of "How scheduling domains are created" is almost over now and so probably this is my last patchset for fixes related to scheduling domains. Sorry for three separate sets, I sent them as soon as I had few of them sitting in my tree. Viresh Kumar (3): sched: Use cached value of span instead of calling sched_domain_span() sched: don't call get_group() for covered cpus sched: remove WARN_ON(!sd) from init_sched_groups_power() kernel/sched/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years

[PATCH] arm64: Define PTE_TYPE_HUGEPAGE

by Christoffer Dall

PTE_TYPE_HUGEPAGE is referenced by pte_huge, but because nobody uses this macro it doesn't fail yet. KVM will be using this when 32-bit support for huge pages is added so add it. Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- arch/arm64/include/asm/pgtable-hwdef.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h index 66367c6..0219523 100644 --- a/arch/arm64/include/asm/pgtable-hwdef.h +++ b/arch/arm64/include/asm/pgtable-hwdef.h @@ -54,6 +54,7 @@ #define PTE_TYPE_MASK (_AT(pteval_t, 3) << 0) #define PTE_TYPE_FAULT (_AT(pteval_t, 0) << 0) #define PTE_TYPE_PAGE (_AT(pteval_t, 3) << 0) +#define PTE_TYPE_HUGEPAGE (_AT(pteval_t, 1) << 0) #define PTE_USER (_AT(pteval_t, 1) << 6) /* AP[1] */ #define PTE_RDONLY (_AT(pteval_t, 1) << 7) /* AP[2] */ #define PTE_SHARED (_AT(pteval_t, 3) << 8) /* SH[1:0], inner shareable */ -- 1.8.1.2

12 years

Fwd: Re: Update on LP1097213

by Mathieu Poirier

Good day Jon, Please include the included patch in your tree. It is a fix for [1]. Thanks, Mathieu. [1]. https://bugs.launchpad.net/linaro-big-little-system/+bug/1097213 -------- Original Message -------- Subject: Re: Update on LP1097213 Date: Mon, 17 Jun 2013 16:31:47 +0100 From: Morten Rasmussen <morten.rasmussen(a)arm.com> To: Mathieu Poirier <mathieu.poirier(a)linaro.org> CC: Vincent Guittot <vincent.guittot(a)linaro.org>, Serge Broslavsky <serge.broslavsky(a)linaro.org>, Amit Kucheria <amit.kucheria(a)linaro.org>, Nicolas Pitre <nicolas.pitre(a)linaro.org>, Naresh Kamboju <naresh.kamboju(a)linaro.org> Hi Mathieu, I had a quick look at the hmp_next_{up,down}_delay() stuff. It is all introduced in the patch: "sched: SCHED_HMP multi-domain task migration control". Reverting it requires some manual conflict fixing and you will also need to remove the extra hmp_next_down_delay() added by a later patch. I've attached a revert patch for debugging purposes that should do it all. I'm not sure if this will just remove the symptom or if the sched_clock accesses are the true cause of the problem. I hope it helps, Morten On 17/06/13 14:26, Vincent Guittot wrote: > Mathieu, > > Please find below the mail we have discussed during the call > > Vincent > > On 14 June 2013 15:21, Vincent Guittot <vincent.guittot(a)linaro.org> wrote: >> On 14 June 2013 15:14, Vincent Guittot <vincent.guittot(a)linaro.org> wrote: >>> On 14 June 2013 14:39, Mathieu Poirier <mathieu.poirier(a)linaro.org> wrote: >>>> Anything on this ?!? Morten, Vincent ? >>> >>> Hi Mathieu, >>> >>> I haven't noticed that the problem can be reproduced on a snowball, >>> the 1st time i read your email. >>> It's means that the hmp specific function are also called on smp system ? >>> >>> I'm going to look more ddeplyin the code >>> >> >> for_each_online_cpu is used in hmp_force_up_migration but it's not >> protected against hotplug so it can used a cpu that is going to be >> unplugged >> >> We should probably protect the sequence with get/put_online_cpus >> >> Vincent >> >>> Vincent >>> >>>> >>>> On 13-06-12 03:13 PM, Mathieu Poirier wrote: >>>>> Good day gents, >>>>> >>>>> I have been working on [1] for a while now, on and off as time >>>>> permitted. The problem has always been very elusive but definitely >>>>> present. As some of the notes in the bug report indicate TC2 wasn't the >>>>> only ARM system I could reproduce this on - snowball suffered from the >>>>> exact same problem. >>>>> >>>>> I started looking at this again for 3.10 and I have good and bad news. >>>>> >>>>> The good news is that I can't reproduce the problem anymore if >>>>> CONFIG_SCHED_HMP is not enabled. I ran the attached script for more >>>>> than 16 hours without even the hint of a problem. Normally one would >>>>> get a crash [2] in less than a minute. I won't go so far as claiming >>>>> that upstream solved the problem. Maybe we are lucky and timing in 3.10 >>>>> simply doesn't allow for the fault to occur. In any case, all we can do >>>>> is continue monitoring the situation in upcoming versions. >>>>> >>>>> On the flip side we have a definite problem with hotplug when >>>>> CONFIG_SCHED_HMP is defined. The crash in [2] is consistent and can be >>>>> reproduced at will. Looking at the trace the problem happens in >>>>> 'select_task_rq_fair' where calls to 'hmp_next_up_delay' and >>>>> 'hmp_next_down_delay' end up referencing 'cfs_rq_clock_task' where >>>>> cfs-rq->rq point to a bogus address. >>>>> >>>>> Have a look at line 9 in [2] - this is a little bit of instrumentation I >>>>> started working on. It basically outputs the new and previous CPUs in >>>>> 'hmp_[up,down]_migration' conditional statements along with the >>>>> direction of the migration [3]. In every instances the system was going >>>>> from the A15 to the A7 cluster. I haven't found a single instance where >>>>> the opposite was be true. >>>>> >>>>> Since this is directly related to our efforts to make the scheduler >>>>> power aware and based on Ingo's latest rebuttal, I am not sure that it >>>>> wise for me to continue working on this - specifically if we end up >>>>> scrapping that portion of the code. I'm eager to hear your opinion. >>>>> >>>>> On the flip side it highlights (once again) that we need to invest >>>>> massively in the hotplug subsystem, more specifically in its relation to >>>>> the scheduler and the RCU subsystem. >>>>> >>>>> Mathieu. >>>>> >>>>> PS. I have purposely kept the audience to a minimum - forward as you >>>>> see fit. >>>>> >>>>> [1]. https://bugs.launchpad.net/linaro-big-little-system/+bug/1188778 >>>>> [2]. https://pastebin.linaro.org/view/0751c84b >>>>> [3]. https://pastebin.linaro.org/view/4491ee27 >>>>> >>>> > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

12 years

[PATCH] cpufreq: userspace: Simplify governor

by Viresh Kumar

Userspace governor has got more code than what it needs for its functioning. Lets simplify it. Over that it will fix issues in cpufreq_governor_userspace(), which isn't doing right things in START/STOP. It is working per-cpu currently whereas it just required to manage policy->cpu. Reported-by: Xiaoguang Chen <chenxg.marvell(a)gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- @Rafael: I don't know why this code was initially added. Please let me know if I am doing something stupid. Also, please apply it as a fix for 3.10 as it is broken recently in 3.9. drivers/cpufreq/cpufreq_userspace.c | 108 ++++-------------------------------- 1 file changed, 12 insertions(+), 96 deletions(-) diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c index bbeb9c0..5dc77b7 100644 --- a/drivers/cpufreq/cpufreq_userspace.c +++ b/drivers/cpufreq/cpufreq_userspace.c @@ -13,55 +13,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/smp.h> -#include <linux/init.h> -#include <linux/spinlock.h> -#include <linux/interrupt.h> #include <linux/cpufreq.h> -#include <linux/cpu.h> -#include <linux/types.h> -#include <linux/fs.h> -#include <linux/sysfs.h> +#include <linux/init.h> +#include <linux/module.h> #include <linux/mutex.h> -/** - * A few values needed by the userspace governor - */ -static DEFINE_PER_CPU(unsigned int, cpu_max_freq); -static DEFINE_PER_CPU(unsigned int, cpu_min_freq); -static DEFINE_PER_CPU(unsigned int, cpu_cur_freq); /* current CPU freq */ -static DEFINE_PER_CPU(unsigned int, cpu_set_freq); /* CPU freq desired by - userspace */ static DEFINE_PER_CPU(unsigned int, cpu_is_managed); - static DEFINE_MUTEX(userspace_mutex); -static int cpus_using_userspace_governor; - -/* keep track of frequency transitions */ -static int -userspace_cpufreq_notifier(struct notifier_block *nb, unsigned long val, - void *data) -{ - struct cpufreq_freqs *freq = data; - - if (!per_cpu(cpu_is_managed, freq->cpu)) - return 0; - - if (val == CPUFREQ_POSTCHANGE) { - pr_debug("saving cpu_cur_freq of cpu %u to be %u kHz\n", - freq->cpu, freq->new); - per_cpu(cpu_cur_freq, freq->cpu) = freq->new; - } - - return 0; -} - -static struct notifier_block userspace_cpufreq_notifier_block = { - .notifier_call = userspace_cpufreq_notifier -}; - /** * cpufreq_set - set the CPU frequency @@ -80,13 +38,6 @@ static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq) if (!per_cpu(cpu_is_managed, policy->cpu)) goto err; - per_cpu(cpu_set_freq, policy->cpu) = freq; - - if (freq < per_cpu(cpu_min_freq, policy->cpu)) - freq = per_cpu(cpu_min_freq, policy->cpu); - if (freq > per_cpu(cpu_max_freq, policy->cpu)) - freq = per_cpu(cpu_max_freq, policy->cpu); - /* * We're safe from concurrent calls to ->target() here * as we hold the userspace_mutex lock. If we were calling @@ -107,7 +58,7 @@ static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq) static ssize_t show_speed(struct cpufreq_policy *policy, char *buf) { - return sprintf(buf, "%u\n", per_cpu(cpu_cur_freq, policy->cpu)); + return sprintf(buf, "%u\n", policy->cur); } static int cpufreq_governor_userspace(struct cpufreq_policy *policy, @@ -119,66 +70,31 @@ static int cpufreq_governor_userspace(struct cpufreq_policy *policy, switch (event) { case CPUFREQ_GOV_START: BUG_ON(!policy->cur); - mutex_lock(&userspace_mutex); - - if (cpus_using_userspace_governor == 0) { - cpufreq_register_notifier( - &userspace_cpufreq_notifier_block, - CPUFREQ_TRANSITION_NOTIFIER); - } - cpus_using_userspace_governor++; + pr_debug("started managing cpu %u\n", cpu); + mutex_lock(&userspace_mutex); per_cpu(cpu_is_managed, cpu) = 1; - per_cpu(cpu_min_freq, cpu) = policy->min; - per_cpu(cpu_max_freq, cpu) = policy->max; - per_cpu(cpu_cur_freq, cpu) = policy->cur; - per_cpu(cpu_set_freq, cpu) = policy->cur; - pr_debug("managing cpu %u started " - "(%u - %u kHz, currently %u kHz)\n", - cpu, - per_cpu(cpu_min_freq, cpu), - per_cpu(cpu_max_freq, cpu), - per_cpu(cpu_cur_freq, cpu)); - mutex_unlock(&userspace_mutex); break; case CPUFREQ_GOV_STOP: - mutex_lock(&userspace_mutex); - cpus_using_userspace_governor--; - if (cpus_using_userspace_governor == 0) { - cpufreq_unregister_notifier( - &userspace_cpufreq_notifier_block, - CPUFREQ_TRANSITION_NOTIFIER); - } + pr_debug("managing cpu %u stopped\n", cpu); + mutex_lock(&userspace_mutex); per_cpu(cpu_is_managed, cpu) = 0; - per_cpu(cpu_min_freq, cpu) = 0; - per_cpu(cpu_max_freq, cpu) = 0; - per_cpu(cpu_set_freq, cpu) = 0; - pr_debug("managing cpu %u stopped\n", cpu); mutex_unlock(&userspace_mutex); break; case CPUFREQ_GOV_LIMITS: mutex_lock(&userspace_mutex); - pr_debug("limit event for cpu %u: %u - %u kHz, " - "currently %u kHz, last set to %u kHz\n", + pr_debug("limit event for cpu %u: %u - %u kHz, currently %u kHz\n", cpu, policy->min, policy->max, - per_cpu(cpu_cur_freq, cpu), - per_cpu(cpu_set_freq, cpu)); - if (policy->max < per_cpu(cpu_set_freq, cpu)) { + policy->cur); + + if (policy->max < policy->cur) __cpufreq_driver_target(policy, policy->max, CPUFREQ_RELATION_H); - } else if (policy->min > per_cpu(cpu_set_freq, cpu)) { + else if (policy->min > policy->cur) __cpufreq_driver_target(policy, policy->min, CPUFREQ_RELATION_L); - } else { - __cpufreq_driver_target(policy, - per_cpu(cpu_set_freq, cpu), - CPUFREQ_RELATION_L); - } - per_cpu(cpu_min_freq, cpu) = policy->min; - per_cpu(cpu_max_freq, cpu) = policy->max; - per_cpu(cpu_cur_freq, cpu) = policy->cur; mutex_unlock(&userspace_mutex); break; } -- 1.7.12.rc2.18.g61b472e

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel