We do report driver's successful {un}registration from cpufreq core, but is done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 62259d2..63d8f8f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2468,7 +2468,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
}
register_hotcpu_notifier(&cpufreq_cpu_notifier);
- pr_debug("driver %s up and running\n", driver_data->name);
+ pr_info("driver %s up and running\n", driver_data->name);
return 0;
err_if_unreg:
@@ -2499,7 +2499,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
if (!cpufreq_driver || (driver != cpufreq_driver))
return -EINVAL;
- pr_debug("unregistering driver %s\n", driver->name);
+ pr_info("unregistering driver %s\n", driver->name);
subsys_interface_unregister(&cpufreq_interface);
if (cpufreq_boost_supported())
--
2.0.0.rc2
Lorenzo and Mark agreed on the following updated patch from Lorenzo:
http://www.spinics.net/lists/arm-kernel/msg336998.html
W.r.t. cluster numbering, we're now back to where we were with the
the original patch sent out in April:
https://lkml.org/lkml/2014/4/22/951
Were there any other objections to this approach?
AFAICT, this patch should be good to go for 3.16.
------->8--------
Create cpu topology based on MPIDR. When hardware sets MPIDR to sane
values, this method will always work. Therefore it should also work well
as the fallback method. [1]
When we have multiple processing elements in the system, we create
the cpu topology by mapping each affinity level (from lowest to highest)
to threads (if they exist), cores, and clusters.
[1] http://www.spinics.net/lists/arm-kernel/msg317445.html
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Zi Shen Lim <zlim(a)broadcom.com>
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
arch/arm64/kernel/topology.c | 47 ++++++++++++++++++++++++++++------------
2 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index c404fb0..7639e8b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -18,6 +18,8 @@
#define INVALID_HWID ULONG_MAX
+#define MPIDR_UP_BITMASK (0x1 << 30)
+#define MPIDR_MT_BITMASK (0x1 << 24)
#define MPIDR_HWID_BITMASK 0xff00ffffff
#define MPIDR_LEVEL_BITS_SHIFT 3
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 43514f9..b6ee26b 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/sched.h>
+#include <asm/cputype.h>
#include <asm/topology.h>
static int __init get_cpu_for_node(struct device_node *node)
@@ -188,13 +189,9 @@ static int __init parse_dt_topology(void)
* Check that all cores are in the topology; the SMP code will
* only mark cores described in the DT as possible.
*/
- for_each_possible_cpu(cpu) {
- if (cpu_topology[cpu].cluster_id == -1) {
- pr_err("CPU%d: No topology information specified\n",
- cpu);
+ for_each_possible_cpu(cpu)
+ if (cpu_topology[cpu].cluster_id == -1)
ret = -EINVAL;
- }
- }
out_map:
of_node_put(map);
@@ -219,14 +216,6 @@ static void update_siblings_masks(unsigned int cpuid)
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
int cpu;
- if (cpuid_topo->cluster_id == -1) {
- /*
- * DT does not contain topology information for this cpu.
- */
- pr_debug("CPU%u: No topology information configured\n", cpuid);
- return;
- }
-
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
@@ -249,6 +238,36 @@ static void update_siblings_masks(unsigned int cpuid)
void store_cpu_topology(unsigned int cpuid)
{
+ struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
+ u64 mpidr;
+
+ if (cpuid_topo->cluster_id != -1)
+ goto topology_populated;
+
+ mpidr = read_cpuid_mpidr();
+
+ /* Uniprocessor systems can rely on default topology values */
+ if (mpidr & MPIDR_UP_BITMASK)
+ return;
+
+ /* Create cpu topology mapping based on MPIDR. */
+ if (mpidr & MPIDR_MT_BITMASK) {
+ /* Multiprocessor system : Multi-threads per core */
+ cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
+ } else {
+ /* Multiprocessor system : Single-thread per core */
+ cpuid_topo->thread_id = -1;
+ cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ }
+
+ pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
+ cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+ cpuid_topo->thread_id, mpidr);
+
+topology_populated:
update_siblings_masks(cpuid);
}
--
1.8.4
Implement and enable context tracking for arm64 (which is
a prerequisite for FULL_NOHZ support). This patchset
builds upon earlier work by Kevin Hilman and is based on
Will Deacon's tree.
Changes v7 to v8:
* Fix bug where el1_irq was calling ct_user_exit rather than el0_irq
Changes v6 to v7:
* Rename parameter of ct_user_exit from restore to syscall
Changes v5 to v6:
* Don't save far_el1 in x26 in el0_dbg path (not needed)
* TIF_NOHZ processes go through the slow path (so no register
save/restore is needed in ct_user_enter)
Changes v4 to v5:
* Improvement to code restoring far_el1 (suggested by Christopher Covington)
* Improvement to register save/restore in ct_user_enter
Changes v3 to v4:
* Rename parameter of ct_user_exit from save to restore
* Rebased patch to Will Deacon's tree (branch remotes/origin/aarch64
of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git)
Changes v2 to v3:
* Save/restore necessary registers in ct_user_enter and ct_user_exit
* Annotate "error paths" out of el0_sync with ct_user_exit
Changes v1 to v2:
* Save far_el1 in x26 temporarily
Larry Bassel (2):
arm64: adjust el0_sync so that a function can be called
arm64: enable context tracking
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/thread_info.h | 4 +++
arch/arm64/kernel/entry.S | 58 +++++++++++++++++++++++++++++++-----
3 files changed, 56 insertions(+), 7 deletions(-)
--
1.8.3.2
I'm dropping the RFC tag now as I have the feeling that we are starting to have something in
a good shape that can be pushed for more testing in near future.
This is v7 of my attempt to add support for a generic pci_host_bridge controller created
from a description passed in the device tree.
Changes from v6:
- Made pci_register_io_range() return an error if PCI_IOBASE is not defined. When the
cleanup of PCI_IOBASE use is going to happen, that will catch all those architectures
that don't use virtual mapping of I/O ranges (like x86) or don't support PCI at all.
- Improved the error handling in of_pci_range_to_resource() and made it propagate the
error as well.
- Bail out of the parsing of PCI ranges if of_pci_range_to_resource() fails.
Changes from v5:
- Tested by Tanmay Inamdar, thanks Tanmay!
- dropped v5 5/7 pci: Use parent domain number when allocating child busses.
- Added weak implementation of pcibios_fixup_bridge_ranges() in drivers/pci/host-bridge.c
so that architectures that enable CONFIG_OF and CONFIG_PCI don't suddenly get compilation
errors. While at this, changed the signature of the function so that an error can be
returned.
- With the new error code in pcibios_fixup_bridge_ranges(), reworked the error handling
in pci_host_bridge_of_get_ranges() and of_create_pci_host_bridge().
- Add linux/slab.h to the #include list
- Revisit the error path in pci_create_root_bus[_in_domain]() and fixed the case where
failing to allocate the bus will not return an error.
Changes from v4:
- Export pci_find_host_bridge() to be used by arch code. There is scope for
making the arch/arm64 version of pci_domain_nr the default weak implementation
but that would double the size of this series in order to handle all #define
versions of the pci_domain_nr() function, so I suggest keeping that for a separate
cleanup series.
Changes from v3:
- Dynamically allocate bus_range resource in of_create_pci_host_bridge()
- Fix the domain number used when creating child busses.
- Changed domain number allocator to use atomic operations.
- Use ERR_PTR() to propagate the error out of pci_create_root_bus_in_domain()
and of_create_pci_host_bridge().
Changes from v2:
- Use range->cpu_addr when calling pci_address_to_pio()
- Introduce pci_register_io_range() helper function in order to register
io ranges ahead of their conversion to PIO values. This is needed as no
information is being stored yet regarding the range mapping, making
pci_address_to_pio() fail. Default weak implementation does nothing,
to cover the default weak implementation of pci_address_to_pio() that
expects direct mapping of physical addresses into PIO values (x86 view).
Changes from v1:
- Add patch to fix conversion of IO ranges into IO resources.
- Added a domain_nr member to pci_host_bridge structure, and a new function
to create a root bus in a given domain number. In order to facilitate that
I propose changing the order of initialisation between pci_host_bridge and
it's related bus in pci_create_root_bus() as sort of a rever of 7b5436635800.
This is done in patch 1/4 and 2/4.
- Added a simple allocator of domain numbers in drivers/pci/host-bridge.c. The
code will first try to get a domain id from of_alias_get_id(..., "pci-domain")
and if that fails assign the next unallocated domain id.
- Changed the name of the function that creates the generic host bridge from
pci_host_bridge_of_init to of_create_pci_host_bridge and exported as GPL symbol.
v6 thread here: https://lkml.org/lkml/2014/3/5/179
v5 thread here: https://lkml.org/lkml/2014/3/4/318
v4 thread here: https://lkml.org/lkml/2014/3/3/301
v3 thread here: https://lkml.org/lkml/2014/2/28/216
v2 thread here: https://lkml.org/lkml/2014/2/27/245
v1 thread here: https://lkml.org/lkml/2014/2/3/380
Best regards,
Liviu
Liviu Dudau (6):
pci: Introduce pci_register_io_range() helper function.
pci: OF: Fix the conversion of IO ranges into IO resources.
pci: Create pci_host_bridge before its associated bus in pci_create_root_bus.
pci: Introduce a domain number for pci_host_bridge.
pci: Export find_pci_host_bridge() function.
pci: Add support for creating a generic host_bridge from device tree
drivers/of/address.c | 49 +++++++++++
drivers/pci/host-bridge.c | 161 ++++++++++++++++++++++++++++++++++-
drivers/pci/probe.c | 73 ++++++++++------
include/linux/of_address.h | 14 +--
include/linux/pci.h | 17 ++++
5 files changed, 278 insertions(+), 36 deletions(-)
--
1.9.0
Hello,
On Linaro Android 14.04, with custom compiled kernel (config file attached),
I am facing a kernel crash (details log attached).
I am running on Samsung Arndale Board with Exynos 5250.
Output from my /sys/kernel/debug/gpio looks as below -
root@arndale:/ # cat /sys/kernel/debug/gpio
GPIOs 0-7, GPA0:
gpio-0 (s3c24xx-uart ) in hi
gpio-1 (s3c24xx-uart ) in hi
gpio-2 (s3c24xx-uart ) in lo
gpio-3 (s3c24xx-uart ) in hi
gpio-6 (i2c-bus ) in hi
gpio-7 (i2c-bus ) in hi
GPIOs 9-14, GPA1:
gpio-9 (s3c24xx-uart ) in hi
gpio-10 (s3c24xx-uart ) in hi
gpio-11 (s3c24xx-uart ) in hi
gpio-12 (s3c24xx-uart ) in hi
gpio-13 (s3c24xx-uart ) in lo
gpio-14 (s3c24xx-uart ) in hi
GPIOs 16-23, GPA2:
GPIOs 25-29, GPB0:
GPIOs 31-35, GPB1:
GPIOs 37-40, GPB2:
GPIOs 42-45, GPB3:
gpio-42 (i2c-bus ) in hi
gpio-43 (i2c-bus ) in hi
GPIOs 47-53, GPC0:
gpio-47 (dw-mci-bus ) in lo
gpio-48 (dw-mci-bus ) in hi
gpio-50 (dw-mci-bus ) in hi
gpio-51 (dw-mci-bus ) in hi
gpio-52 (dw-mci-bus ) in hi
gpio-53 (dw-mci-bus ) in hi
GPIOs 55-58, GPC1:
gpio-55 (dw-mci-bus ) in hi
gpio-56 (dw-mci-bus ) in hi
gpio-57 (dw-mci-bus ) in hi
gpio-58 (dw-mci-bus ) in hi
GPIOs 60-66, GPC2:
GPIOs 68-74, GPC3:
gpio-68 (dw-mci-bus ) in lo
gpio-69 (dw-mci-bus ) in hi
gpio-70 (dw-mci-cd ) in lo
gpio-71 (dw-mci-bus ) in lo
gpio-72 (dw-mci-bus ) in hi
gpio-73 (dw-mci-bus ) in hi
gpio-74 (dw-mci-bus ) in hi
GPIOs 76-82, GPC4:
GPIOs 84-87, GPD0:
gpio-84 (s3c24xx-uart ) in lo
gpio-85 (s3c24xx-uart ) in hi
gpio-86 (s3c24xx-uart ) in lo
gpio-87 (s3c24xx-uart ) in hi
GPIOs 89-96, GPD1:
GPIOs 98-103, GPY0:
GPIOs 105-108, GPY1:
GPIOs 110-115, GPY2:
GPIOs 117-124, GPY3:
GPIOs 126-133, GPY4:
GPIOs 135-142, GPY5:
GPIOs 144-151, GPY6:
GPIOs 153-160, GPX0:
GPIOs 162-169, GPX1:
gpio-163 (VDD_33ON_2.8V ) out hi
GPIOs 171-178, GPX2:
gpio-174 (S5M8767 DS2 ) out lo
gpio-175 (S5M8767 DS3 ) out lo
gpio-176 (S5M8767 DS4 ) out lo
GPIOs 180-187, GPX3:
gpio-187 (HPD ) in lo
GPIOs 189-196, GPE0:
GPIOs 198-199, GPE1:
GPIOs 201-204, GPF0:
GPIOs 206-209, GPF1:
GPIOs 211-218, GPG0:
GPIOs 220-227, GPG1:
GPIOs 229-230, GPG2:
GPIOs 232-235, GPH0:
GPIOs 237-244, GPH1:
GPIOs 246-253, GPV0:
GPIOs 255-262, GPV1:
GPIOs 264-271, GPV2:
GPIOs 273-280, GPV3:
GPIOs 282-283, GPV4:
GPIOs 285-291, GPZ:
While trying to export gpio 8, the crash happens -
root@arndale:/ # echo 8 > /sys/class/gpio/export
1Unable to handle kernel NULL pointer dereference at virtual address 00000044
[ 26.700000] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
1pgd = e8848000
[ 26.700000] pgd = e8848000
[00000044] *pgd=00000000[ 26.720000] [00000044] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 26.730000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>From above, I noted that gpio 0 - 7 are associated with GPA0 and gpio
9 - 14 with GPA1.
gpio 8 is not existent in /sys/kernel/debug/gpio file.
On the same board, I ran Linaro Saucy server, and there the crash does
not happen. /sys/kernel/debug/gpio
on saucy server looks as below -
GPIOs 0-7, platform/11400000.pinctrl, gpa0:
GPIOs 8-13, platform/11400000.pinctrl, gpa1:
GPIOs 14-21, platform/11400000.pinctrl, gpa2:
GPIOs 22-26, platform/11400000.pinctrl, gpb0:
GPIOs 27-31, platform/11400000.pinctrl, gpb1:
GPIOs 32-35, platform/11400000.pinctrl, gpb2:
GPIOs 36-39, platform/11400000.pinctrl, gpb3:
GPIOs 40-46, platform/11400000.pinctrl, gpc0:
GPIOs 47-50, platform/11400000.pinctrl, gpc1:
GPIOs 51-57, platform/11400000.pinctrl, gpc2:
GPIOs 58-64, platform/11400000.pinctrl, gpc3:
GPIOs 65-68, platform/11400000.pinctrl, gpd0:
GPIOs 69-76, platform/11400000.pinctrl, gpd1:
gpio-76 (usb3503 connect ) out hi
GPIOs 77-83, platform/11400000.pinctrl, gpc4:
GPIOs 84-89, platform/11400000.pinctrl, gpy0:
GPIOs 90-93, platform/11400000.pinctrl, gpy1:
GPIOs 94-99, platform/11400000.pinctrl, gpy2:
GPIOs 100-107, platform/11400000.pinctrl, gpy3:
GPIOs 108-115, platform/11400000.pinctrl, gpy4:
GPIOs 116-123, platform/11400000.pinctrl, gpy5:
GPIOs 124-131, platform/11400000.pinctrl, gpy6:
GPIOs 132-139, platform/11400000.pinctrl, gpx0:
GPIOs 140-147, platform/11400000.pinctrl, gpx1:
gpio-141 (VDD_33ON_2.8V ) out hi
gpio-144 (SW-TACT2 ) in hi
gpio-145 (SW-TACT3 ) in hi
gpio-146 (SW-TACT4 ) in hi
gpio-147 (SW-TACT5 ) in hi
GPIOs 148-155, platform/11400000.pinctrl, gpx2:
gpio-148 (SW-TACT6 ) in hi
gpio-149 (SW-TACT7 ) in hi
gpio-151 (S5M8767 DS2 ) out lo
gpio-152 (S5M8767 DS3 ) out lo
gpio-153 (S5M8767 DS4 ) out lo
GPIOs 156-163, platform/11400000.pinctrl, gpx3:
gpio-161 (usb3503 reset ) out hi
gpio-163 (HPD ) in lo
GPIOs 164-171, platform/13400000.pinctrl, gpe0:
GPIOs 172-173, platform/13400000.pinctrl, gpe1:
GPIOs 174-177, platform/13400000.pinctrl, gpf0:
GPIOs 178-181, platform/13400000.pinctrl, gpf1:
GPIOs 182-189, platform/13400000.pinctrl, gpg0:
GPIOs 190-197, platform/13400000.pinctrl, gpg1:
GPIOs 198-199, platform/13400000.pinctrl, gpg2:
GPIOs 200-203, platform/13400000.pinctrl, gph0:
GPIOs 204-211, platform/13400000.pinctrl, gph1:
GPIOs 212-219, platform/10d10000.pinctrl, gpv0:
GPIOs 220-227, platform/10d10000.pinctrl, gpv1:
GPIOs 228-235, platform/10d10000.pinctrl, gpv2:
GPIOs 236-243, platform/10d10000.pinctrl, gpv3:
GPIOs 244-245, platform/10d10000.pinctrl, gpv4:
GPIOs 246-252, platform/3860000.pinctrl, gpz:
Questions -
1. Is it kernel bug?
2. Why are some gpios (8, 15, 24, etc) not mapped to any device on android?
--
Thanks,
- Meraj
- Robustify the user backtrace code, as done on other architectures.
- Provide the symbols resolution when triggering from tracepoints.
Tested with perf record and tracepoints triggering (-e <tracepoint>), with
unwinding using fp (--call-graph fp) and dwarf info (--call-graph dwarf).
Jean Pihet (3):
ARM: perf: Check that current->mm is alive before getting user
callchain
ARM: perf: disable the pagefault handler when reading from user space
ARM: perf: allow tracing with kernel tracepoints events
arch/arm/include/asm/perf_event.h | 19 +++++++++++++++++++
arch/arm/kernel/perf_event.c | 13 +++++++++++--
2 files changed, 30 insertions(+), 2 deletions(-)
--
1.8.1.2
Commit 64c862a83... added new alloc variants to the devres managed
API. These should be included in the list of managed API found in
devres.txt.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Grant Likely <grant.likely(a)linaro.org>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: linux-doc(a)vger.kernel.org
---
Documentation/driver-model/devres.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 1525e30..91f5633 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -234,7 +234,10 @@ certainly invest a bit more effort into libata core layer).
-----------------------------
MEM
+ devm_kmalloc()
devm_kzalloc()
+ devm_kmalloc_array()
+ devm_kcalloc()
devm_kfree()
devm_kmemdup()
devm_get_free_pages()
--
1.9.3
When expiry is set to KTIME_MAX, we cancel the 'tick-sched' hrtimer in highres
mode and skip reprogramming clockevent device in lowres mode. But, the
clockevent device is already reprogrammed from tick-handler.
We will get interrupted atleast one more time.
In highres mode, as there is no hrtimer to service, hrtimer_interrupt() will
return without calling tick-handler.
But the problem is somewhat bigger in lowres mode. We unconditionally reschedule
tick everytime tick_nohz_handler() is called and so even if tick_stopped is set,
we never enter full dynticks mode.
To fix this, skip rescheduling next tick from tick-handler when we are running
tickless.
OTOH, when expires isn't equal to KTIME_MAX, we avoid reprogramming the clkdev
from the tick when it is stopped because it's going to be reprogrammed from
irq_exit() anyway. So we could avoid one useless device write.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-sched.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6558b7a..a4a45e0 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -956,6 +956,12 @@ static void tick_nohz_handler(struct clock_event_device *dev)
tick_sched_do_timer(now);
tick_sched_handle(ts, regs);
+ /*
+ * Skip reprogramming next event if we are running tickless.
+ */
+ if (ts->tick_stopped)
+ return;
+
while (tick_nohz_reprogram(ts, now)) {
now = ktime_get();
tick_do_update_jiffies64(now);
--
2.0.0.rc2
Stephen Boyd sent few patches today around a new cpufreq driver for Qualcomm's
Krait SoC: https://lkml.org/lkml/2014/6/24/918.
Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support for
SoC's with multiple clusters or SoC's which don't share clock line for all CPUs.
And I thought about trying updating cpu0 driver to see if we can get rid of this
limitation easily and use it for Krait as well.
It took me longer than I thought, around 4 hours to get this working on my dual
A15 exynos board.
First patch adds some space for driver specific data in 'struct cpufreq_policy'
and second one updates cpufreq-cpu0..
@Stephen: Can you please test this on Krait and see if it works?
Pushed here:
Rebased over rc2:
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait
For guys looking to test on exynos, rebased over linux-next + some patches from
Thomas Abraham to use cpufreq-cpu0 for exynos:
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-exynos
In case this is acceptable and bug free, next step would be to get cpufreq-cpu0
renamed a bit as its not about CPU0 anymore. Any suggestions on that would be
great :), cpufreq_generic.c ?
Thanks.
Viresh Kumar (2):
cpufreq: Add support for per-policy driver data
cpufreq: cpu0: Extend support beyond CPU0
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 8 +-
drivers/cpufreq/Kconfig | 5 +-
drivers/cpufreq/cpufreq-cpu0.c | 280 +++++++++++++--------
include/linux/cpufreq.h | 3 +
4 files changed, 193 insertions(+), 103 deletions(-)
--
2.0.0.rc2