Tree/Branch: master
Git describe: v3.16-rc6-75-g15ba223
Commit: 15ba2236f3 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Build Time: 2 min 43 sec
Passed: 1 / 1 (100.00 %)
Failed: 0 / 1 ( 0.00 %)
Errors: 0
Warnings: 3
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Users of the recently proposed extensions to the FIQ infrastructure
have reported a problem which causes the interrupt dispatcher in
irq-gic.c (running as a normal IRQ handler) to try to acknowledge
group 0 interrupts (group 0 should raise FIQ).
The problem occurs because the GICv1 found in Cortex A9 implementations
explicitly uses the security state (normal or trusted world) to
determine whether the interrupt controller should acknowledge group 0
interrupts. For FIQ to be useful as an NMI on Cortex A9 the kernel must
run in in trusted world hence by default the GIC allows the CPU to
acknowledge group 0 interrupts.
Two workarounds have been proposed, one which retrospectively corrects
the problem if it is observed and one which uses the ARM MMU section
flags to ensure the GIC driver can read INTACK from the current security
context. The later workaround, which is both more invasive and higher
performance[1], is presented in this patchset.
This patchset depends upon my own patchset for ARM providing additional
FIQ infrastructure but does contain the changes to the GIC driver
required to support FIQ. The effect of this is that workaround code
is found primarily in patches 5, 6 and 7.
[1]
http://thread.gmane.org/gmane.linux.ports.arm.kernel/331027/focus=1748892
Daniel Thompson (6):
irqchip: gic: Provide support for interrupt grouping
irqchip: gic: Add support for FIQ management
irqchip: gic: Remove spin locks from eoi_irq
arm: mm: Avoid ioremap_page_range() for non-secure mappings
irqchip: gic: Use non-secure aliased register set when FIQ is enabled
arm: imx: non-secure aliased mapping of GIC registers
Marek Vasut (3):
ARM: dump the status of NS bit in L1 PTE
ARM: Add L1 PTE non-secure mapping
ARM: socfpga: Map the GIC CPU registers as MT_DEVICE_NS
arch/arm/include/asm/io.h | 5 +-
arch/arm/include/asm/mach/map.h | 4 +-
arch/arm/include/asm/pgtable-2level-hwdef.h | 1 +
arch/arm/mach-imx/mach-imx6q.c | 11 ++
arch/arm/mach-socfpga/socfpga.c | 8 +
arch/arm/mm/dump.c | 5 +
arch/arm/mm/ioremap.c | 4 +
arch/arm/mm/mmu.c | 13 +-
drivers/irqchip/irq-gic.c | 240 ++++++++++++++++++++++++++--
include/linux/irqchip/arm-gic.h | 4 +-
10 files changed, 273 insertions(+), 22 deletions(-)
--
1.9.3
Tree/Branch: next-20140718
Git describe: next-20140718
Commit: 58e323c3ee Add linux-next specific files for 20140718
Build Time: 0 min 34 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 1 / 1 (100.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm64-defconfig
Errors:
arm64-defconfig
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: v3.16-rc6
Git describe: v3.16-rc6
Commit: 9a3c4145af Linux 3.16-rc6
Build Time: 1 min 3 sec
Passed: 1 / 1 (100.00 %)
Failed: 0 / 1 ( 0.00 %)
Errors: 0
Warnings: 3
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Hi All,
I find that in Linaro 13.07 Release With Linux Kernel 3.10.1 There is a feature ��Storage EXT4 journal in enhanced area of eMMC �C Club journal and metadata together in enhanced area��. But I did not find any code about it. Can anyone help me?
Thanks
Peter Pan
EBU APAC System Engineering
Tel: 86-021-38997413
Mobile: 86-18516211455
Email: peterpandong(a)micron.com
Address: No 601 Fasai Rd, Pudong, Shanghai, China, 200131
Tree/Branch: next-20140718
Git describe: next-20140718
Commit: 58e323c3ee Add linux-next specific files for 20140718
Build Time: 0 min 34 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 1 / 1 (100.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm64-defconfig
Errors:
arm64-defconfig
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: master
Git describe: v3.16-rc5-264-gd057190
Commit: d057190925 Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Build Time: 6 min 11 sec
Passed: 1 / 1 (100.00 %)
Failed: 0 / 1 ( 0.00 %)
Errors: 0
Warnings: 3
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: next-20140718
Git describe: next-20140718
Commit: 58e323c3ee Add linux-next specific files for 20140718
Build Time: 5 min 55 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 1 / 1 (100.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm64-defconfig
Errors:
arm64-defconfig
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: next-20140718
Git describe: next-20140718
Commit: 58e323c3ee Add linux-next specific files for 20140718
Build Time: 1 min 11 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 1 / 1 (100.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm64-defconfig
Errors:
arm64-defconfig
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: next-20140718
Git describe: next-20140718
Commit: 58e323c3ee Add linux-next specific files for 20140718
Build Time: 5 min 54 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 1 / 1 (100.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm64-defconfig
Errors:
arm64-defconfig
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 3
1 ../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
../arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
../arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Part of this patchset was previously part of the larger tasks packing patchset
[1]. I have splitted the latter in 3 different patchsets (at least) to make the
thing easier.
-configuration of sched_domain topology [2]
-update and consolidation of cpu_power (this patchset)
-tasks packing algorithm
SMT system is no more the only system that can have a CPUs with an original
capacity that is different from the default value. We need to extend the use of
cpu_power_orig to all kind of platform so the scheduler will have both the
maximum capacity (cpu_power_orig/power_orig) and the current capacity
(cpu_power/power) of CPUs and sched_groups. A new function arch_scale_cpu_power
has been created and replace arch_scale_smt_power, which is SMT specifc in the
computation of the capapcity of a CPU.
During load balance, the scheduler evaluates the number of tasks that a group
of CPUs can handle. The current method assumes that tasks have a fix load of
SCHED_LOAD_SCALE and CPUs have a default capacity of SCHED_POWER_SCALE.
This assumption generates wrong decision by creating ghost cores and by
removing real ones when the original capacity of CPUs is different from the
default SCHED_POWER_SCALE. We don't try anymore to evaluate the number of
available cores based on the group_capacity but instead we detect when the group
is fully utilized
Now that we have the original capacity of CPUS and their activity/utilization,
we can evaluate more accuratly the capacity and the level of utilization of a
group of CPUs.
This patchset mainly replaces the old capacity method by a new one and has kept
the policy almost unchanged whereas we could certainly take advantage of this
new statistic in several other places of the load balance.
Tests results:
I have put below results of 3 kind of tests:
- hackbench -l 500 -s 4096
- scp of 100MB file on the platform
- ebizzy with various number of threads
on 3 kernel
tip = tip/sched/core
patch = tip + this patchset
patch+irq = tip + this patchset + irq accounting
each test has been run 6 times and the figure below show the stdev and the
diff compared to the tip kernel
Dual cortex A7 tip | patch | patch+irq
stdev | diff stdev | diff stdev
hackbench (+/-)1.02% | +0.42%(+/-)1.29% | -0.65%(+/-)0.44%
scp (+/-)0.41% | +0.18%(+/-)0.10% | +78.05%(+/-)0.70%
ebizzy -t 1 (+/-)1.72% | +1.43%(+/-)1.62% | +2.58%(+/-)2.11%
ebizzy -t 2 (+/-)0.42% | +0.06%(+/-)0.45% | +1.45%(+/-)4.05%
ebizzy -t 4 (+/-)0.73% | +8.39%(+/-)13.25% | +4.25%(+/-)10.08%
ebizzy -t 6 (+/-)10.30% | +2.19%(+/-)3.59% | +0.58%(+/-)1.80%
ebizzy -t 8 (+/-)1.45% | -0.05%(+/-)2.18% | +2.53%(+/-)3.40%
ebizzy -t 10 (+/-)3.78% | -2.71%(+/-)2.79% | -3.16%(+/-)3.06%
ebizzy -t 12 (+/-)3.21% | +1.13%(+/-)2.02% | -1.13%(+/-)4.43%
ebizzy -t 14 (+/-)2.05% | +0.15%(+/-)3.47% | -2.08%(+/-)1.40%
uad cortex A15 tip | patch | patch+irq
stdev | diff stdev | diff stdev
hackbench (+/-)0.55% | -0.58%(+/-)0.90% | +0.62%(+/-)0.43%
scp (+/-)0.21% | -0.10%(+/-)0.10% | +5.70%(+/-)0.53%
ebizzy -t 1 (+/-)0.42% | -0.58%(+/-)0.48% | -0.29%(+/-)0.18%
ebizzy -t 2 (+/-)0.52% | -0.83%(+/-)0.20% | -2.07%(+/-)0.35%
ebizzy -t 4 (+/-)0.22% | -1.39%(+/-)0.49% | -1.78%(+/-)0.67%
ebizzy -t 6 (+/-)0.44% | -0.78%(+/-)0.15% | -1.79%(+/-)1.10%
ebizzy -t 8 (+/-)0.43% | +0.13%(+/-)0.92% | -0.17%(+/-)0.67%
ebizzy -t 10 (+/-)0.71% | +0.10%(+/-)0.93% | -0.36%(+/-)0.77%
ebizzy -t 12 (+/-)0.65% | -1.07%(+/-)1.13% | -1.13%(+/-)0.70%
ebizzy -t 14 (+/-)0.92% | -0.28%(+/-)1.25% | +2.84%(+/-)9.33%
I haven't been able to fully test the patchset for a SMT system to check that
the regression that has been reported by Preethi has been solved but the
various tests that i have done, don't show any regression so far.
The correction of SD_PREFER_SIBLING mode and the use of the latter at SMT level
should have fix the regression.
Change since V2:
- rebase on top of capacity renaming
- fix wake_affine statistic update
- rework nohz_kick_needed
- optimize the active migration of a task from CPU with reduced capacity
- rename group_activity by group_utilization and remove unused total_utilization
- repair SD_PREFER_SIBLING and use it for SMT level
- reorder patchset to gather patches with same topics
Change since V1:
- add 3 fixes
- correct some commit messages
- replace capacity computation by activity
- take into account current cpu capacity
[1] https://lkml.org/lkml/2013/10/18/121
[2] https://lkml.org/lkml/2014/3/19/377
Vincent Guittot (12):
sched: fix imbalance flag reset
sched: remove a wake_affine condition
sched: fix avg_load computation
sched: Allow all archs to set the power_orig
ARM: topology: use new cpu_power interface
sched: add per rq cpu_power_orig
sched: test the cpu's capacity in wake affine
sched: move cfs task on a CPU with higher capacity
Revert "sched: Put rq's sched_avg under CONFIG_FAIR_GROUP_SCHED"
sched: get CPU's utilization statistic
sched: replace capacity_factor by utilization
sched: add SD_PREFER_SIBLING for SMT level
arch/arm/kernel/topology.c | 4 +-
kernel/sched/core.c | 3 +-
kernel/sched/fair.c | 290 +++++++++++++++++++++++----------------------
kernel/sched/sched.h | 5 +-
4 files changed, 158 insertions(+), 144 deletions(-)
--
1.9.1
OPPs can be populated statically, via DT, or added at run time with
dev_pm_opp_add().
While this driver handles the first case correctly, it would fail to populate
OPPs added at runtime. Because call to of_init_opp_table() would fail as there
are no OPPs in DT and probe will return early.
To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table()
unconditionally.
Update bindings as well.
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)ti.com>
Suggested-by: Stephen Boyd <sboyd(a)codeaurora.org>
Tested-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi Rafael,
This was earlier sent as part of: https://lkml.org/lkml/2014/7/1/358 series. But
actually is an fix and can (should?) be pushed for 3.16.
Rest of the patches from that series are cleanups/updates and so can go in
3.17.
Please see if you can take it for 3.16.
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 6 ++++--
drivers/cpufreq/cpufreq-cpu0.c | 7 ++-----
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..366690c 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -8,10 +8,12 @@ Both required and optional properties listed below must be defined
under node /cpus/cpu@0.
Required properties:
-- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
- for details
+- None
Optional properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt for
+ details. OPPs *must* be supplied either via DT, i.e. this property, or
+ populated at runtime.
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ee1ae30..86beda9 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -152,11 +152,8 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_put_reg;
}
- ret = of_init_opp_table(cpu_dev);
- if (ret) {
- pr_err("failed to init OPP table: %d\n", ret);
- goto out_put_clk;
- }
+ /* OPPs might be populated at runtime, don't check for error here */
+ of_init_opp_table(cpu_dev);
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
if (ret) {
--
2.0.0.rc2
Hi Rafael,
As discussed here:
https://www.mail-archive.com/stable@vger.kernel.org/msg87645.html
This is another attempt to fix an important bug and cleanups around it.
First patch is the real fix (Accumulated all Reviewed/Tested-by's) and *should*
go in 3.16-rc*.
Others are useful cleanups around it to beautify the code, and can go later in
3.17.
Based over: 3.16-rc4
Viresh Kumar (4):
cpufreq: move policy kobj to policy->cpu at resume
cpufreq: don't restore policy->cpus on failure to move kobj
cpufreq: propagate error returned by kobject_move()
cpufreq: move policy kobj from update_policy_cpu()
drivers/cpufreq/cpufreq.c | 68 +++++++++++++++++++++--------------------------
1 file changed, 31 insertions(+), 37 deletions(-)
--
2.0.0.rc2
Tree/Branch: next-20140717
Git describe: next-20140717
Commit: b395397b3a Add linux-next specific files for 20140717
Build Time: 1 min 21 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 0 / 1 ( 0.00 %)
Unknown: 1 / 1 (100.00 %)
Errors: 1
Warnings: 5
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
6 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 /home/broonie/build/linux-next/arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings Summary: 5
2 /home/broonie/build/linux-next/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux-next/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux-next/fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux-next/fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux-next/arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : UNKNOWN, 1 errors, 6 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-next/arch/arm64/kernel/ptrace.c:1118:2: error: too many arguments to function ‘audit_syscall_entry’
Warnings:
/home/broonie/build/linux-next/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-next/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-next/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-next/arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-next/fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-next/fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: master
Git describe: v3.16-rc5-143-gb6603fe574af
Commit: b6603fe574 Merge tag 'for-linus-20140716' of git://git.infradead.org/linux-mtd
Build Time: 0 min 19 sec
Passed: 0 / 1 ( 0.00 %)
Failed: 0 / 1 ( 0.00 %)
Unknown: 1 / 1 (100.00 %)
Errors: 0
Warnings: 5
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
6 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 5
2 /home/broonie/build/linux/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux/fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux/fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux/arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-defconfig : UNKNOWN, 0 errors, 6 warnings, 0 section mismatches
Warnings:
/home/broonie/build/linux/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux/scripts/sortextable.h:176:3: warning: ‘relocs_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux/arch/arm64/include/asm/pgtable.h:363:50: warning: ‘start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux/fs/direct-io.c:920:9: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux/fs/direct-io.c:1034:9: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.
Consider a dual cluster platform with 2 cores per cluster. During suspend we
start offlining CPUs from 1 to 3. When CPU2 is remove, policy->kobj would be
moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj.
Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
We will recover the old policy and update policy->cpu from 3 to 2 from
update_policy_cpu().
But the kobj is still tied to CPU3 and wasn't moved to CPU2. We wouldn't create
a link for CPU2, but would try that while bringing CPU3 online. Which will
report errors as CPU3 already has kobj assigned to it.
This bug got introduced with commit 42f921a, which overlooked this scenario.
To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
cluster back. We already have update_policy_cpu() routine which can be updated
with this change. That would get rid of the cpufreq_nominate_new_policy_cpu() as
update_policy_cpu() is also called on CPU removal.
To achieve that we add another parameter to update_policy_cpu() as cpu_dev is
present with both the callers.
Fixes: ("42f921a cpufreq: remove sysfs files for CPUs which failed to come back after resume")
Cc: Stable <stable(a)vger.kernel.org> # 3.13+
Reported-by: Bu Yitian <ybu(a)qti.qualcomm.com>
Reported-by: Saravana Kannan <skannan(a)codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V1->V2: Move kobject_move() call to update_policy_cpu(), which makes
cpufreq_nominate_new_policy_cpu() almost empty. So we remove it completely.
@Yitian: Sorry, but you need to test this again as there were enough
modifications in V2.
drivers/cpufreq/cpufreq.c | 73 +++++++++++++++++++++++------------------------
1 file changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 62259d2..c81d9ec6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1076,10 +1076,20 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
kfree(policy);
}
-static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
+static int update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu,
+ struct device *cpu_dev)
{
+ int ret;
+
if (WARN_ON(cpu == policy->cpu))
- return;
+ return 0;
+
+ /* Move kobject to the new policy->cpu */
+ ret = kobject_move(&policy->kobj, &cpu_dev->kobj);
+ if (ret) {
+ pr_err("%s: Failed to move kobj: %d\n", __func__, ret);
+ return ret;
+ }
down_write(&policy->rwsem);
@@ -1090,6 +1100,8 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_UPDATE_POLICY_CPU, policy);
+
+ return 0;
}
static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
@@ -1154,7 +1166,7 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
* by invoking update_policy_cpu().
*/
if (recover_policy && cpu != policy->cpu)
- update_policy_cpu(policy, cpu);
+ WARN_ON(update_policy_cpu(policy, cpu, dev));
else
policy->cpu = cpu;
@@ -1307,38 +1319,11 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
return __cpufreq_add_dev(dev, sif);
}
-static int cpufreq_nominate_new_policy_cpu(struct cpufreq_policy *policy,
- unsigned int old_cpu)
-{
- struct device *cpu_dev;
- int ret;
-
- /* first sibling now owns the new sysfs dir */
- cpu_dev = get_cpu_device(cpumask_any_but(policy->cpus, old_cpu));
-
- sysfs_remove_link(&cpu_dev->kobj, "cpufreq");
- ret = kobject_move(&policy->kobj, &cpu_dev->kobj);
- if (ret) {
- pr_err("%s: Failed to move kobj: %d\n", __func__, ret);
-
- down_write(&policy->rwsem);
- cpumask_set_cpu(old_cpu, policy->cpus);
- up_write(&policy->rwsem);
-
- ret = sysfs_create_link(&cpu_dev->kobj, &policy->kobj,
- "cpufreq");
-
- return -EINVAL;
- }
-
- return cpu_dev->id;
-}
-
static int __cpufreq_remove_dev_prepare(struct device *dev,
struct subsys_interface *sif)
{
unsigned int cpu = dev->id, cpus;
- int new_cpu, ret;
+ int ret;
unsigned long flags;
struct cpufreq_policy *policy;
@@ -1378,14 +1363,28 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
if (cpu != policy->cpu) {
sysfs_remove_link(&dev->kobj, "cpufreq");
} else if (cpus > 1) {
- new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu);
- if (new_cpu >= 0) {
- update_policy_cpu(policy, new_cpu);
+ /* Nominate new CPU */
+ int new_cpu = cpumask_any_but(policy->cpus, cpu);
+ struct device *cpu_dev = get_cpu_device(new_cpu);
- if (!cpufreq_suspended)
- pr_debug("%s: policy Kobject moved to cpu: %d from: %d\n",
- __func__, new_cpu, cpu);
+ sysfs_remove_link(&cpu_dev->kobj, "cpufreq");
+ ret = update_policy_cpu(policy, new_cpu, cpu_dev);
+ if (ret) {
+ /*
+ * To supress compilation warning about return value of
+ * sysfs_create_link().
+ */
+ int temp;
+
+ /* Create link again if we failed. */
+ temp = sysfs_create_link(&cpu_dev->kobj, &policy->kobj,
+ "cpufreq");
+ return ret;
}
+
+ if (!cpufreq_suspended)
+ pr_debug("%s: policy Kobject moved to cpu: %d from: %d\n",
+ __func__, new_cpu, cpu);
} else if (cpufreq_driver->stop_cpu && cpufreq_driver->setpolicy) {
cpufreq_driver->stop_cpu(policy);
}
--
2.0.0.rc2
At present it is not possible to boot with the ttyNMI0 console treating
character input normally. To use the console requires that kdb be
entered and the nmi_console command be used to enable the console (or if
only kgdb is present then gdb must directly manipulate the value of
kgdb_nmi_tty_enabled).
Introducing a module parameter makes the console much more usable.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Jiri Slaby <jslaby(a)suse.cz>
Cc: linux-serial(a)vger.kernel.org
---
drivers/tty/serial/kgdb_nmi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c
index cfadf29..9361d69 100644
--- a/drivers/tty/serial/kgdb_nmi.c
+++ b/drivers/tty/serial/kgdb_nmi.c
@@ -43,6 +43,11 @@ module_param_named(magic, kgdb_nmi_magic, charp, 0600);
MODULE_PARM_DESC(magic, "magic sequence to enter NMI debugger (default $3#33)");
static bool kgdb_nmi_tty_enabled;
+module_param_named(tty, kgdb_nmi_tty_enabled, bool, 0600);
+MODULE_PARM_DESC(tty, "if set to false (default), characters received from "
+ "the UART will be passed exclusively to the knock "
+ "detector; when set to true characters will be passed "
+ "both to the knock detector and to the TTY layer");
static int kgdb_nmi_console_setup(struct console *co, char *options)
{
--
1.9.3
As part of the migration a couple of uart definitions have been copied
from of the platform specific header files.
Note that, in order to keep oldconfig working nicely we must defer the
removal of arch/arm/mach-ks8695/include/mach/debug-macro.S until
DEBUG_LL_UART_NONE has been removed.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
Cc: Russell King <linux(a)arm.linux.org.uk>
Cc: Greg Ungerer <gerg(a)uclinux.org>
Cc: Arnd Bergmann <arnd.bergmann(a)linaro.org>
---
Notes:
This is a contribution towards the removal of DEBUG_LL_UART_NONE, see
http://thread.gmane.org/gmane.linux.kernel/1712068/focus=1746065 for
details.
arch/arm/Kconfig.debug | 8 ++++++++
arch/arm/include/debug/ks8695.S | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
create mode 100644 arch/arm/include/debug/ks8695.S
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 8f90595..6f9664a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -340,6 +340,13 @@ choice
Say Y here if you want the debug print routines to direct
their output to UART1 serial port on KEYSTONE2 devices.
+ config DEBUG_KS8695_UART
+ bool "KS8695 Debug UART"
+ depends on ARCH_KS8695
+ help
+ Say Y here if you want kernel low-level debugging support
+ on KS8695.
+
config DEBUG_MMP_UART2
bool "Kernel low-level debugging message via MMP UART2"
depends on ARCH_MMP
@@ -1006,6 +1013,7 @@ config DEBUG_LL_INCLUDE
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART || \
DEBUG_IMX6SX_UART
+ default "debug/ks8695.S" if DEBUG_KS8695_UART
default "debug/msm.S" if DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
diff --git a/arch/arm/include/debug/ks8695.S b/arch/arm/include/debug/ks8695.S
new file mode 100644
index 0000000..961da1f
--- /dev/null
+++ b/arch/arm/include/debug/ks8695.S
@@ -0,0 +1,40 @@
+/*
+ * arch/arm/include/debug/ks8695.S
+ *
+ * Copyright (C) 2006 Ben Dooks <ben(a)simtec.co.uk>
+ * Copyright (C) 2006 Simtec Electronics
+ *
+ * KS8695 - Debug macros
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define KS8695_UART_PA 0x03ffe000
+#define KS8695_UART_VA 0xf00fe000
+#define KS8695_URTH (0x04)
+#define KS8695_URLS (0x14)
+#define URLS_URTE (1 << 6)
+#define URLS_URTHRE (1 << 5)
+
+ .macro addruart, rp, rv, tmp
+ ldr \rp, =KS8695_UART_PA @ physical base address
+ ldr \rv, =KS8695_UART_VA @ virtual base address
+ .endm
+
+ .macro senduart, rd, rx
+ str \rd, [\rx, #KS8695_URTH] @ Write to Transmit Holding Register
+ .endm
+
+ .macro busyuart, rd, rx
+1001: ldr \rd, [\rx, #KS8695_URLS] @ Read Line Status Register
+ tst \rd, #URLS_URTE @ Holding & Shift registers empty?
+ beq 1001b
+ .endm
+
+ .macro waituart, rd, rx
+1001: ldr \rd, [\rx, #KS8695_URLS] @ Read Line Status Register
+ tst \rd, #URLS_URTHRE @ Holding Register empty?
+ beq 1001b
+ .endm
--
1.9.3