[v4][PATCH 6/8] book3e/kexec/kdump: implement ppc64 kexec specfic
ppc64 kexec mechanism has a different implementation with ppc32.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/platforms/85xx/smp.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 549948a..137ad10 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -277,6 +277,7 @@ struct smp_ops_t smp_85xx_ops = {
};
#ifdef CONFIG_KEXEC
+#ifdef CONFIG_PPC32
atomic_t kexec_down_cpus = ATOMIC_INIT(0);
void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
@@ -295,6 +296,14 @@ static void mpc85xx_smp_kexec_down(void *arg)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0,1);
}
+#else
+void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
+{
+ local_irq_disable();
+ hard_irq_disable();
+ mpic_teardown_this_cpu(secondary);
+}
+#endif
static void map_and_flush(unsigned long paddr)
{
@@ -346,11 +355,14 @@ static void mpc85xx_smp_flush_dcache_kexec(struct kimage
*image)
static void mpc85xx_smp_machine_kexec(struct kimage *image)
{
+#ifdef CONFIG_PPC32
int timeout = INT_MAX;
int i, num_cpus = num_present_cpus();
+#endif
mpc85xx_smp_flush_dcache_kexec(image);
+#ifdef CONFIG_PPC32
if (image-type == KEXEC_TYPE_DEFAULT)
smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
@@ -368,6 +380,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
if ( i == smp_processor_id() ) continue;
mpic_reset_core(i);
}
+#endif
default_machine_kexec(image);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v4][PATCH 7/8] book3e/kexec/kdump: redefine VIRT_PHYS_OFFSET
Book3e is always aligned 1GB to create TLB so we should use (KERNELBASE - MEMORY_START) as VIRT_PHYS_OFFSET to get __pa/__va properly while boot kdump. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/include/asm/page.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 988c812..5b00081 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -112,6 +112,8 @@ extern long long virt_phys_offset; /* See Description below for VIRT_PHYS_OFFSET */ #ifdef CONFIG_RELOCATABLE_PPC32 #define VIRT_PHYS_OFFSET virt_phys_offset +#elif defined(CONFIG_PPC_BOOK3E_64) +#define VIRT_PHYS_OFFSET (KERNELBASE - MEMORY_START) #else #define VIRT_PHYS_OFFSET (KERNELBASE - PHYSICAL_START) #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v4][PATCH 5/8] book3e/kexec/kdump: introduce a kexec kernel flag
We need to introduce a flag to indicate we're already running
a kexec kernel then we can go proper path. For example, We
shouldn't access spin_table from the bootloader to up any secondary
cpu for kexec kernel, and kexec kernel already know how to jump to
generic_secondary_smp_init.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/smp.h|1 +
arch/powerpc/kernel/head_64.S | 10 ++
arch/powerpc/kernel/misc_64.S |6 ++
arch/powerpc/platforms/85xx/smp.c | 20 +++-
4 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 98da78e..92f7e61 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -207,6 +207,7 @@ extern void generic_secondary_thread_init(void);
extern unsigned long __secondary_hold_spinloop;
extern unsigned long __secondary_hold_acknowledge;
extern char __secondary_hold;
+extern unsigned long __run_at_kexec;
extern void __early_start(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index fd42f8a..fa74d20 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -89,6 +89,10 @@ __secondary_hold_spinloop:
__secondary_hold_acknowledge:
.llong 0x0
+ .globl __run_at_kexec
+__run_at_kexec:
+ .llong 0x0 /* Flag for the secondary kernel from kexec. */
+
#ifdef CONFIG_RELOCATABLE
/* This flag is set to 1 by a loader if the kernel should run
* at the loaded address instead of the linked address. This
@@ -426,6 +430,7 @@ _STATIC(__after_prom_start)
add r25,r25,r26
1: mr r3,r25
bl .relocate
+
#if defined(CONFIG_PPC_BOOK3E)
/* In relocatable case we always have to load the address of label
'name'
* to set IVPR. So after .relocate we have to update IVPR with current
@@ -463,6 +468,11 @@ _STATIC(__after_prom_start)
#if defined(CONFIG_PPC_BOOK3E)
tovirt(r26,r26) /* on booke, we already run at
PAGE_OFFSET */
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
+ /* If relocated we need to restore this flag on that relocated address.
*/
+ ld r7,__run_at_kexec-_stext(r3)
+ std r7,__run_at_kexec-_stext(r26)
+#endif
lwz r7,__run_at_load-_stext(r26)
#if defined(CONFIG_PPC_BOOK3E)
tophys(r26,r26) /* Restore for the remains. */
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 049be29..adf60b6 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -639,6 +639,12 @@ _GLOBAL(kexec_sequence)
bl .copy_and_flush /* (dest, src, copy limit, start offset) */
1: /* assume normal blr return */
+ /* notify we're going into kexec kernel for SMP. */
+ LOAD_REG_ADDR(r3,__run_at_kexec)
+ li r4,1
+ std r4,0(r3)
+ sync
+
/* release other cpus to the new kernel secondary start at 0x60 */
mflrr5
li r6,1
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index ea9c626..549948a 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -150,6 +150,9 @@ static int smp_85xx_kick_cpu(int nr)
int hw_cpu = get_hard_smp_processor_id(nr);
int ioremappable;
int ret = 0;
+#ifdef CONFIG_PPC64
+ unsigned long *ptr = NULL;
+#endif
WARN_ON(nr 0 || nr = NR_CPUS);
WARN_ON(hw_cpu 0 || hw_cpu = NR_CPUS);
@@ -238,11 +241,18 @@ out:
#else
smp_generic_kick_cpu(nr);
- flush_spin_table(spin_table);
- out_be32(spin_table-pir, hw_cpu);
- out_be64((u64 *)(spin_table-addr_h),
- __pa((u64)*((unsigned long long *)generic_secondary_smp_init)));
- flush_spin_table(spin_table);
+ ptr = (unsigned long *)((unsigned long)__run_at_kexec);
+ /* We shouldn't access spin_table from the bootloader to up any
+* secondary cpu for kexec kernel, and kexec kernel already
+* know how to jump to generic_secondary_smp_init.
+*/
+ if (!*ptr) {
+ flush_spin_table(spin_table);
+ out_be32(spin_table-pir, hw_cpu);
+ out_be64((u64 *)(spin_table-addr_h),
+__pa((u64)*((unsigned long long
*)generic_secondary_smp_init)));
+ flush_spin_table(spin_table);
+ }
#endif
local_irq_restore(flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v4][PATCH 8/8] book3e/kexec/kdump: recover r4 = 0 to create the initial TLB
In commit 96f013f, powerpc/kexec: Add kexec hold support for Book3e processors, requires that GPR4 survive the hold process, for IBM Blue Gene/Q with with some very strange firmware. But for FSL Book3E, r4 = 1 to indicate that the initial TLB entry for this core already exists so we still should set r4 with 0 to create that initial TLB. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/kernel/head_64.S |4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index fa74d20..001b112 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -127,6 +127,10 @@ __secondary_hold: /* Grab our physical cpu number */ mr r24,r3 /* stash r4 for book3e */ +#ifdef CONFIG_PPC_FSL_BOOK3E + /* we need to setup initial TLB entry. */ + li r4,0 +#endif mr r25,r4 /* Tell the master cpu we're here */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v4][PATCH 2/8] powerpc/book3e: support CONFIG_RELOCATABLE
book3e is different with book3s since 3s includes the exception vectors code in head_64.S as it relies on absolute addressing which is only possible within this compilation unit. So we have to get that label address with got. And when boot a relocated kernel, we should reset ipvr properly again after .relocate. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/include/asm/exception-64e.h | 11 +++ arch/powerpc/kernel/exceptions-64e.S | 18 +- arch/powerpc/kernel/head_64.S| 25 + 3 files changed, 53 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/exception-64e.h b/arch/powerpc/include/asm/exception-64e.h index 51fa43e..371a77f 100644 --- a/arch/powerpc/include/asm/exception-64e.h +++ b/arch/powerpc/include/asm/exception-64e.h @@ -214,10 +214,21 @@ exc_##label##_book3e: #define TLB_MISS_STATS_SAVE_INFO_BOLTED #endif +#ifndef CONFIG_RELOCATABLE #define SET_IVOR(vector_number, vector_offset) \ li r3,vector_offset@l; \ ori r3,r3,interrupt_base_book3e@l; \ mtspr SPRN_IVOR##vector_number,r3; +#else /* !CONFIG_RELOCATABLE */ +/* In relocatable case the value of the constant expression 'expr' is only + * offset. So instead, we should loads the address of label 'name'. + */ +#define SET_IVOR(vector_number, vector_offset) \ + LOAD_REG_ADDR(r3,interrupt_base_book3e);\ + rlwinm r3,r3,0,15,0; \ + ori r3,r3,vector_offset@l; \ + mtspr SPRN_IVOR##vector_number,r3; +#endif /* CONFIG_RELOCATABLE */ #endif /* _ASM_POWERPC_EXCEPTION_64E_H */ diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 99cb68e..e71511c 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -1097,7 +1097,15 @@ skpinv: addir6,r6,1 /* Increment */ * r4 = MAS0 w/TLBSEL ESEL for the temp mapping */ /* Now we branch the new virtual address mapped by this entry */ +#ifdef CONFIG_RELOCATABLE + /* We have to find out address from lr. */ + bl 1f /* Find our address */ +1: mflrr6 + addir6,r6,(2f - 1b) + tovirt(r6,r6) +#else LOAD_REG_IMMEDIATE(r6,2f) +#endif lis r7,MSR_KERNEL@h ori r7,r7,MSR_KERNEL@l mtspr SPRN_SRR0,r6 @@ -1348,9 +1356,17 @@ _GLOBAL(book3e_secondary_thread_init) mflrr28 b 3b -_STATIC(init_core_book3e) +_GLOBAL(init_core_book3e) /* Establish the interrupt vector base */ +#ifdef CONFIG_RELOCATABLE +/* In relocatable case the value of the constant expression 'expr' is only + * offset. So instead, we should loads the address of label 'name'. + */ + tovirt(r2,r2) + LOAD_REG_ADDR(r3, interrupt_base_book3e) +#else LOAD_REG_IMMEDIATE(r3, interrupt_base_book3e) +#endif mtspr SPRN_IVPR,r3 sync blr diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 3d11d80..27cfbcd 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -414,12 +414,25 @@ _STATIC(__after_prom_start) /* process relocations for the final address of the kernel */ lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */ sldir25,r25,32 +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1/* flagged to stay where we are ? */ bne 1f add r25,r25,r26 1: mr r3,r25 bl .relocate +#if defined(CONFIG_PPC_BOOK3E) + /* In relocatable case we always have to load the address of label 'name' +* to set IVPR. So after .relocate we have to update IVPR with current +* address of label. +*/ + bl .init_core_book3e +#endif #endif /* @@ -447,12 +460,24 @@ _STATIC(__after_prom_start) * variable __run_at_load, if it is set the kernel is treated as relocatable * kernel, otherwise it will be moved to PHYSICAL_START */ +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1 bne 3f +#ifdef CONFIG_PPC_BOOK3E + LOAD_REG_ADDR(r5, __end_interrupts) + LOAD_REG_ADDR(r11, _stext) + sub r5,r5,r11 +#else /* just copy interrupts */ LOAD_REG_IMMEDIATE(r5, __end_interrupts - _stext) +#endif b 5f 3: #endif -- 1.7.9.5 -- To unsubscribe from this
[v4][PATCH 3/8] book3e/kexec/kdump: enable kexec for kernel
We need to active KEXEC for book3e and bypass or convert non-book3e stuff
in kexec coverage.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/kernel/machine_kexec_64.c | 148 ++--
arch/powerpc/kernel/misc_64.S |6 ++
3 files changed, 89 insertions(+), 67 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7205989..3c91ad0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -378,7 +378,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool kexec system call
- depends on (PPC_BOOK3S || FSL_BOOKE || (44x !SMP))
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x !SMP)) || PPC_BOOK3E
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 611acdf..ee153a8 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -30,72 +30,6 @@
#include asm/smp.h
#include asm/hw_breakpoint.h
-int default_machine_kexec_prepare(struct kimage *image)
-{
- int i;
- unsigned long begin, end; /* limits of segment */
- unsigned long low, high;/* limits of blocked memory range */
- struct device_node *node;
- const unsigned long *basep;
- const unsigned int *sizep;
-
- if (!ppc_md.hpte_clear_all)
- return -ENOENT;
-
- /*
-* Since we use the kernel fault handlers and paging code to
-* handle the virtual mode, we must make sure no destination
-* overlaps kernel static data or bss.
-*/
- for (i = 0; i image-nr_segments; i++)
- if (image-segment[i].mem __pa(_end))
- return -ETXTBSY;
-
- /*
-* For non-LPAR, we absolutely can not overwrite the mmu hash
-* table, since we are still using the bolted entries in it to
-* do the copy. Check that here.
-*
-* It is safe if the end is below the start of the blocked
-* region (end = low), or if the beginning is after the
-* end of the blocked region (begin = high). Use the
-* boolean identity !(a || b) === (!a !b).
-*/
- if (htab_address) {
- low = __pa(htab_address);
- high = low + htab_size_bytes;
-
- for (i = 0; i image-nr_segments; i++) {
- begin = image-segment[i].mem;
- end = begin + image-segment[i].memsz;
-
- if ((begin high) (end low))
- return -ETXTBSY;
- }
- }
-
- /* We also should not overwrite the tce tables */
- for_each_node_by_type(node, pci) {
- basep = of_get_property(node, linux,tce-base, NULL);
- sizep = of_get_property(node, linux,tce-size, NULL);
- if (basep == NULL || sizep == NULL)
- continue;
-
- low = *basep;
- high = low + (*sizep);
-
- for (i = 0; i image-nr_segments; i++) {
- begin = image-segment[i].mem;
- end = begin + image-segment[i].memsz;
-
- if ((begin high) (end low))
- return -ETXTBSY;
- }
- }
-
- return 0;
-}
-
#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
static void copy_segments(unsigned long ind)
@@ -367,6 +301,87 @@ void default_machine_kexec(struct kimage *image)
/* NOTREACHED */
}
+#ifdef CONFIG_PPC_BOOK3E
+int default_machine_kexec_prepare(struct kimage *image)
+{
+ int i;
+ /*
+* Since we use the kernel fault handlers and paging code to
+* handle the virtual mode, we must make sure no destination
+* overlaps kernel static data or bss.
+*/
+ for (i = 0; i image-nr_segments; i++)
+ if (image-segment[i].mem __pa(_end))
+ return -ETXTBSY;
+ return 0;
+}
+#else /* CONFIG_PPC_BOOK3E */
+int default_machine_kexec_prepare(struct kimage *image)
+{
+ int i;
+ unsigned long begin, end; /* limits of segment */
+ unsigned long low, high;/* limits of blocked memory range */
+ struct device_node *node;
+ const unsigned long *basep;
+ const unsigned int *sizep;
+
+ if (!ppc_md.hpte_clear_all)
+ return -ENOENT;
+
+ /*
+* Since we use the kernel fault handlers and paging code to
+* handle the virtual mode, we must make sure no destination
+* overlaps kernel static data or bss.
+*/
+ for (i = 0; i image-nr_segments; i++)
+ if (image-segment[i].mem
[v4][PATCH 1/8] powerpc/book3e: rename interrupt_end_book3e with __end_interrupts
We can rename 'interrupt_end_book3e' with '__end_interrupts' then book3s/book3e can share this unique label to make sure we can use this conveniently. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/kernel/exceptions-64e.S |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 2d06704..99cb68e 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -309,8 +309,8 @@ interrupt_base_book3e: /* fake trap */ EXCEPTION_STUB(0x300, hypercall) EXCEPTION_STUB(0x320, ehpriv) - .globl interrupt_end_book3e -interrupt_end_book3e: + .globl __end_interrupts +__end_interrupts: /* Critical Input Interrupt */ START_EXCEPTION(critical_input); @@ -493,7 +493,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) beq+1f LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) - LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e) + LOAD_REG_IMMEDIATE(r15,__end_interrupts) cmpld cr0,r10,r14 cmpld cr1,r10,r15 blt+cr0,1f @@ -559,7 +559,7 @@ kernel_dbg_exc: beq+1f LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) - LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e) + LOAD_REG_IMMEDIATE(r15,__end_interrupts) cmpld cr0,r10,r14 cmpld cr1,r10,r15 blt+cr0,1f -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core / ACPI: Avoid device removal locking problems
Hi Rafael,
On 08/26/2013 04:09 AM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
There are two mutexes, device_hotplug_lock and acpi_scan_lock, held
around the acpi_bus_trim() call in acpi_scan_hot_remove() which
generally removes devices (it removes ACPI device objects at least,
but it may also remove physical device objects through .detach()
callbacks of ACPI scan handlers). Thus, potentially, device sysfs
attributes are removed under these locks and to remove those
attributes it is necessary to hold the s_active references of their
directory entries for writing.
On the other hand, the execution of a .show() or .store() callback
from a sysfs attribute is carried out with that attribute's s_active
reference held for reading. Consequently, if any device sysfs
attribute that may be removed from within acpi_scan_hot_remove()
through acpi_bus_trim() has a .store() or .show() callback which
acquires either acpi_scan_lock or device_hotplug_lock, the execution
of that callback may deadlock with the removal of the attribute.
[Unfortunately, the online device attribute of CPUs and memory
blocks and the eject attribute of ACPI device objects are affected
by this issue.]
To avoid those deadlocks introduce a new protection mechanism that
can be used by the device sysfs attributes in question. Namely,
if a device sysfs attribute's .store() or .show() callback routine
is about to acquire device_hotplug_lock or acpi_scan_lock, it can
first execute read_lock_device_remove() and return an error code if
that function returns false. If true is returned, the lock in
question may be acquired and read_unlock_device_remove() must be
called. [This mechanism is implemented by means of an additional
rwsem in drivers/base/core.c.]
Make the affected sysfs attributes in the driver core and ACPI core
use read_lock_device_remove() and read_unlock_device_remove() as
described above.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Reported-by: Gu Zheng guz.f...@cn.fujitsu.com
I'm sorry to forget to mention that the original reporter is
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com. I continued
the investigation and found more issues.
We tested this patch on kernel 3.11-rc6, but it seems that the
issue is still there. Detail info as following.
Thanks,
Gu
==
[ INFO: possible circular locking dependency detected ]
3.11.0-rc6-lockdebug-refea+ #162 Tainted: GF
---
kworker/0:2/754 is trying to acquire lock:
(s_active#73){.+}, at: [8121062b] sysfs_addrm_finish+0x3b/0x70
but task is already holding lock:
(mem_sysfs_mutex){+.+.+.}, at: [813b949d]
remove_memory_block+0x1d/0xa0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
Commit 9a11899 (USB: OHCI: add missing PCI PM callbacks to ohci-pci.c) breaks several builds
Broken builds: mips:ath79_defconfig parisc:defconfig sparc32:defconfig sparc64:defconfig tile:defconfig Error log: drivers/usb/host/ohci-pci.c: In function 'ohci_pci_init': drivers/usb/host/ohci-pci.c:309:35: error: 'ohci_suspend' undeclared (first use in this function) drivers/usb/host/ohci-pci.c:309:35: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/host/ohci-pci.c:310:34: error: 'ohci_resume' undeclared (first use in this function) make[3]: *** [drivers/usb/host/ohci-pci.o] Error 1 Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: xilinx: fix memleak
decrease device_node refcount np1 in err case. Signed-off-by: Libo Chen libo.c...@huawei.com --- drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c index e90e1f4..64b4639 100644 --- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c @@ -175,6 +175,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np) printk(KERN_WARNING Setting MDIO clock divisor to default %d\n, DEFAULT_CLOCK_DIVISOR); clk_div = DEFAULT_CLOCK_DIVISOR; + of_node_put(np1); goto issue; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] mmc: dw_mmc: Honor requests to set the clock to 0 (turn off clock)
Jaehoon, On Sun, Aug 25, 2013 at 6:31 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi Doug, On 08/24/2013 05:40 AM, Doug Anderson wrote: Jaehoon, On Fri, Aug 23, 2013 at 6:21 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi Doug, If the clock-gating is enabled, then maybe it's continuously printed the kernel message for Bus_speed. Can you explain? I don't think dw_mmc has support for clock gating right now. ...or are there some patches that I'm not aware of? I could believe that if you've got some non-upstream clock gating patches that these would need to be modified to handle it... ...but unless those are slated to land upstream it seems like I can't take them into account, can I? If i enabled the CONFIG_MMC_CLK_GATE, the i have found the below message whenever some operation is run. I will test more with your patch. Ah, sorry! I wasn't aware of that config option. I was thinking of automatic clock gating based on something like the common clock framework. When there are no more users of a gate clock it will get turned off. To have that work dw_mmc would need to release its biu / ciu clocks at some point. If I had to guess, I'd speculate that perhaps we should just change the printout to a dev_debug(), though I do find that printout incredibly useful. If I had to guess I'd say that the mmc core is switching between a clock of 0 and a full speed clock constantly. If that's true then it means that dw_mmc used to treat that like a no-op. Now it actually gates the clock. If you comment out the printout, do things still work? Does your power consumption go down? Let me know if you find anything. Otherwise I can try to reproduce this week. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unused swap offset / bad page map.
On Fri, Aug 23, 2013 at 11:53 AM, Dave Jones da...@redhat.com wrote: It actually seems worse, seems I can trigger it even easier now, as if there's a leak. Can you please try the new fix for TLB flush? commit 2b047252d087be7f2ba Fix TLB gather virtual address range invalidation corner cases -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Commit 9a11899 (USB: OHCI: add missing PCI PM callbacks to ohci-pci.c) breaks several builds
On 08/25/2013 08:30 PM, Guenter Roeck wrote: Broken builds: mips:ath79_defconfig parisc:defconfig sparc32:defconfig sparc64:defconfig tile:defconfig Add: powerpc:ppc64e_defconfig powerpc:cell_defconfig powerps:maple_defconfig That makes it 8 out of 82 builds, or roughly 10% of all builds. My qemu test build for powerpc (which has its own config file) fails as well :(. Guenter Error log: drivers/usb/host/ohci-pci.c: In function 'ohci_pci_init': drivers/usb/host/ohci-pci.c:309:35: error: 'ohci_suspend' undeclared (first use in this function) drivers/usb/host/ohci-pci.c:309:35: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/host/ohci-pci.c:310:34: error: 'ohci_resume' undeclared (first use in this function) make[3]: *** [drivers/usb/host/ohci-pci.o] Error 1 Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vme: vme_ca91cx42.c: fix to pass correct device identity to free_irq()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
free_irq() expects the same device identity that was passed to
corresponding request_irq(), otherwise the IRQ is not freed.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/vme/bridges/vme_ca91cx42.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 64bfea3..f24e234 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -243,6 +243,8 @@ static int ca91cx42_irq_init(struct vme_bridge
*ca91cx42_bridge)
static void ca91cx42_irq_exit(struct ca91cx42_driver *bridge,
struct pci_dev *pdev)
{
+ struct vme_bridge *ca91cx42_bridge;
+
/* Disable interrupts from PCI to VME */
iowrite32(0, bridge-base + VINT_EN);
@@ -251,7 +253,9 @@ static void ca91cx42_irq_exit(struct ca91cx42_driver
*bridge,
/* Clear Any Pending PCI Interrupts */
iowrite32(0x00FF, bridge-base + LINT_STAT);
- free_irq(pdev-irq, pdev);
+ ca91cx42_bridge = container_of((void *)bridge, struct vme_bridge,
+ driver_priv);
+ free_irq(pdev-irq, ca91cx42_bridge);
}
static int ca91cx42_iack_received(struct ca91cx42_driver *bridge, int level)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] arcmsr: Support Areca new SATA Raid Adapter ARC1214/1224/1264/1284
From: Ching ching2...@areca.com.tw Support Areca new SATA Raid adapter ARC1214/1224/1264/1284. Modify maximum outstanding command number, notify command complete with auto request sense Signed-off-by: Ching ching2...@areca.com.tw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] raid6/test: replace echo -e with printf
On Thu, 22 Aug 2013 17:09:11 +0200 H. Peter Anvin h...@zytor.com wrote: Acked-by: H. Peter Anvin h...@zytor.com Applied with the Ack - thanks. NeilBrown Max Filippov jcmvb...@gmail.com wrote: -e is a non-standard echo option, echo output is implementation-dependent when it is used. Replace echo -e with printf as suggested by POSIX echo manual. Cc: NeilBrown ne...@suse.de Cc: Jim Kukunas james.t.kuku...@linux.intel.com Cc: H. Peter Anvin h...@zytor.com Cc: Yuanhan Liu yuanhan@linux.intel.com Signed-off-by: Max Filippov jcmvb...@gmail.com --- lib/raid6/test/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/raid6/test/Makefile b/lib/raid6/test/Makefile index 087332d..73b0151 100644 --- a/lib/raid6/test/Makefile +++ b/lib/raid6/test/Makefile @@ -28,7 +28,7 @@ ifeq ($(IS_X86),yes) gcc -c -x assembler - /dev/null \ rm ./-.o echo -DCONFIG_AS_AVX2=1) else -HAS_ALTIVEC := $(shell echo -e '\#include altivec.h\nvector int a;' |\ +HAS_ALTIVEC := $(shell printf '\#include altivec.h\nvector int a;\n' |\ gcc -c -x c - /dev/null \ rm ./-.o echo yes) ifeq ($(HAS_ALTIVEC),yes) signature.asc Description: PGP signature
[PATCH 2/3] arcmsr: Fix command throttling for ARC188x series
From: Ching ching2...@areca.com.tw Fix command throttling for ARC188x series adapter. Signed-off-by: Ching ching2...@areca.com.tw --- patch2 Description: Binary data
Re: Commit 9a11899 (USB: OHCI: add missing PCI PM callbacks to ohci-pci.c) breaks several builds
On Sun, Aug 25, 2013 at 09:02:15PM -0700, Guenter Roeck wrote: On 08/25/2013 08:30 PM, Guenter Roeck wrote: Broken builds: mips:ath79_defconfig parisc:defconfig sparc32:defconfig sparc64:defconfig tile:defconfig Add: powerpc:ppc64e_defconfig powerpc:cell_defconfig powerps:maple_defconfig That makes it 8 out of 82 builds, or roughly 10% of all builds. My qemu test build for powerpc (which has its own config file) fails as well :(. Ugh, I got no reports of this from linux-next or the 0-day build system, odd. Alan, can you send a follow-on patch to fix this? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arcmsr: Fix bug of updating adapter firmware through ioctl(ARCHTTP) interface
From: Ching ching2...@areca.com.tw Fix bug of updating adapter firmware through ioctl(ARCHTTP) interface. Signed-off-by: Ching ching2...@areca.com.tw --- patch3 Description: Binary data
Re: Unusually high system CPU usage with recent kernels
On Sun, Aug 25, 2013 at 09:50:21PM +0200, Tibor Billes wrote: From: Paul E. McKenney Sent: 08/24/13 11:03 PM On Sat, Aug 24, 2013 at 09:59:45PM +0200, Tibor Billes wrote: From: Paul E. McKenney Sent: 08/22/13 12:09 AM On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote: From: Paul E. McKenney Sent: 08/21/13 09:12 PM On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote: From: Paul E. McKenney Sent: 08/20/13 11:43 PM On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote: From: Paul E. McKenney Sent: 08/20/13 04:53 PM On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote: Hi, I was using the 3.9.7 stable release and tried to upgrade to the 3.10.x series. The 3.10.x series was showing unusually high (75%) system CPU usage in some situations, making things really slow. The latest stable I tried is 3.10.7. I also tried 3.11-rc5, they both show this behaviour. This behaviour doesn't show up when the system is idling, only when doing some CPU intensive work, like compiling with multiple threads. Compiling with only one thread seems not to trigger this behaviour. To be more precise I did a `perf record -a` while compiling a large C++ program with scons using 4 threads, the result is appended at the end of this email. New one on me! You are running a mainstream system (x86_64), so I am surprised no one else noticed. Could you please send along your .config file? Here it is Interesting. I don't see RCU stuff all that high on the list, but the items I do see lead me to suspect RCU_FAST_NO_HZ, which has some relevance to the otherwise inexplicable group of commits you located with your bisection. Could you please rerun with CONFIG_RCU_FAST_NO_HZ=n? If that helps, there are some things I could try. It did help. I didn't notice anything unusual when running with CONFIG_RCU_FAST_NO_HZ=n. Interesting. Thank you for trying this -- and we at least have a short-term workaround for this problem. I will put a patch together for further investigation. I don't specifically need this config option so I'm fine without it in the long term, but I guess it's not supposed to behave like that. OK, good, we have a long-term workload for your specific case, even better. ;-) But yes, there are situations where RCU_FAST_NO_HZ needs to work a bit better. I hope you will bear with me with a bit more testing... In the meantime, could you please tell me how you were measuring performance for your kernel builds? Wall-clock time required to complete one build? Number of builds completed per unit time? Something else? Actually, I wasn't all this sophisticated. I have a system monitor applet on my top panel (using MATE, Linux Mint), four little graphs, one of which shows CPU usage. Different colors indicate different kind of CPU usage. Blue shows user space usage, red shows system usage, and two more for nice and iowait. During a normal compile it's almost completely filled with blue user space CPU usage, only the top few pixels show some iowait and system usage. With CONFIG_RCU_FAST_NO_HZ set, about 3/4 of the graph was red system CPU usage, the rest was blue. So I just looked for a pile of red on my graphs when I tested different kernel builds. But also compile speed was horrible I couldn't wait for the build to finish. Even the UI got unresponsive. We have been having problems with CPU accounting, but this one looks quite real. Now I did some measuring. In the normal case a compile finished in 36 seconds, compiled 315 object files. Here are some output lines from dstat -tasm --vm during compile: system total-cpu-usage -dsk/total- -net/total- ---paging-- ---system-- swap--- --memory-usage- -virtual-memory time |usr sys idl wai hiq siq| read writ| recv send| in out | int csw | used free| used buff cach free|majpf minpf alloc free 21-08 21:48:05| 91 8 2 0 0 0| 0 5852k| 0 0 | 0 0 |1413 1772 | 0 7934M| 581M 58.0M 602M 6553M| 0 71k 46k 54k 21-08 21:48:06| 93 6 1 0 0 0| 0 2064k| 137B 131B| 0 0 |1356 1650 | 0 7934M| 649M 58.0M 604M 6483M| 0 72k 47k 28k 21-08 21:48:07| 86 11 4 0 0 0| 0 5872k| 0 0 | 0 0 |2000
Re: [PATCH 00/16] cpufreq: create use cpufreq_generic_get() routine
On 24 August 2013 20:20, Rafael J. Wysocki r...@sisk.pl wrote: OK, let me rephrase that more directly: Please, slow down. Allow your previous changes to be integrated before you throw more of them at people. Okay, I will try :) Btw, Are you going to take any of my patches for 3.12? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 2/3] mmc: dw_mmc: Honor requests to set the clock to 0 (turn off clock)
On Fri, August 23, 2013, Doug Anderson wrote:
Previously the dw_mmc driver would ignore any requests to disable the
card's clock. This doesn't seem like a good thing in general, but had
one extra bad side effect in the following situtation:
* mmc core would set clk to 400kHz at boot time while initting
* mmc core would set clk to 0 since no card, but it would be ignored.
* suspend to ram and resume; clocks in the dw_mmc IP block are now 0
but dw_mmc thinks that they're 400kHz (it ignored the set to 0).
* insert card
* mmc core would set clk to 400kHz which would be considered a no-op.
Note that if there is no card in the slot and we do a suspend/resume
cycle, we _do_ still end up with differences in a dw_mmc register
dump, but the differences are clock related and we've got the clock
disabled both before and after, so this should be OK.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v6:
- Replaces previous pathes that ensured saving/restoring clocks.
drivers/mmc/host/dw_mmc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ee5f167..f6c7545 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -635,7 +635,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
u32 div;
u32 clk_en_a;
- if (slot-clock != host-current_speed || force_clkinit) {
+ if (slot-clock == 0) {
+ mci_writel(host, CLKENA, 0);
+ mci_send_cmd(slot,
+ SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
Basically dw_mmc driver uses host's low power mode(auto clock gating)
So, how about keeping origin code rather than programming clock setting to '0'?
+ } else if (slot-clock != host-current_speed || force_clkinit) {
And then, if condition('slot-clock is not zero') is added in order to allow to
set clock,
print messages which Jaehoon pointed would be solved.
Thanks,
Seungwon Jeon
div = host-bus_hz / slot-clock;
if (host-bus_hz % slot-clock host-bus_hz slot-clock)
/*
@@ -675,9 +679,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
/* inform CIU */
mci_send_cmd(slot,
SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
-
- host-current_speed = slot-clock;
}
+ host-current_speed = slot-clock;
/* Set the current slot bus width */
mci_writel(host, CTYPE, (slot-ctype slot-id));
@@ -807,13 +810,11 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
mci_writel(slot-host, UHS_REG, regs);
- if (ios-clock) {
- /*
- * Use mirror of ios-clock to prevent race with mmc
- * core ios update when finding the minimum.
- */
- slot-clock = ios-clock;
- }
+ /*
+ * Use mirror of ios-clock to prevent race with mmc
+ * core ios update when finding the minimum.
+ */
+ slot-clock = ios-clock;
if (drv_data drv_data-set_ios)
drv_data-set_ios(slot-host, ios);
--
1.8.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] sched: Clean-up struct sd_lb_stat
On Sun, Aug 25, 2013 at 7:56 PM, Lei Wen adrian.w...@gmail.com wrote: On Tue, Aug 20, 2013 at 12:01 AM, Peter Zijlstra pet...@infradead.org wrote: From: Joonsoo Kim iamjoonsoo@lge.com There is no reason to maintain separate variables for this_group and busiest_group in sd_lb_stat, except saving some space. But this structure is always allocated in stack, so this saving isn't really benificial [peterz: reducing stack space is good; in this case readability increases enough that I think its still beneficial] This patch unify these variables, so IMO, readability may be improved. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com [peterz: lots of style edits, a few fixes and a rename] Signed-off-by: Peter Zijlstra pet...@infradead.org Link: http://lkml.kernel.org/r/1375778203-31343-4-git-send-email-iamjoonsoo@lge.com --- kernel/sched/fair.c | 225 +--- 1 file changed, 112 insertions(+), 113 deletions(-) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4277,36 +4277,6 @@ static unsigned long task_h_load(struct [snip]... - env-imbalance = DIV_ROUND_CLOSEST( - sds-max_load * sds-busiest-sgp-power, SCHED_POWER_SCALE); + env-imbalance = DIV_ROUND_CLOSEST(sds-busiest_stat.avg_load * + sds-busiest-sgp-power, SCHED_POWER_SCALE); I am wondering whether we could change this line as below is more appropriate, since it would avoid the division here: env-imbalance = (sds-busiest_stat.avg_load * sds-busiest-sgp-power) SCHED_POWER_SHIFT; I am not sure whether compiler would be smarter enough to covert into operation, if it see SCHED_POWER_SCALE is 1024 here. This would change the rounding. Fortunately, gcc is smart enough to handle this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones'
On 24 August 2013 04:45, Eduardo Valentin eduardo.valen...@ti.com wrote: diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index ad1fde2..ede6487 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -20,6 +20,9 @@ #include linux/platform_device.h #include linux/regulator/consumer.h #include linux/slab.h +#include linux/thermal.h +#include linux/cpu_cooling.h +#include linux/cpumask.h In alphabetical order please.. @@ -268,6 +272,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev) goto out_free_table; } + /* +* For now, just loading the cooling device; +* thermal DT code takes care of matching them. +*/ + if (of_find_property(np, cooling-zones, NULL)) + cdev = cpufreq_cooling_register(cpu_present_mask); Should we check if it passed or failed? And if failed Atleast flag an appropriate message? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Commit 9a11899 (USB: OHCI: add missing PCI PM callbacks to ohci-pci.c) breaks several builds
On 08/25/2013 09:26 PM, Greg Kroah-Hartman wrote: On Sun, Aug 25, 2013 at 09:02:15PM -0700, Guenter Roeck wrote: On 08/25/2013 08:30 PM, Guenter Roeck wrote: Broken builds: mips:ath79_defconfig parisc:defconfig sparc32:defconfig sparc64:defconfig tile:defconfig Add: powerpc:ppc64e_defconfig powerpc:cell_defconfig powerps:maple_defconfig That makes it 8 out of 82 builds, or roughly 10% of all builds. My qemu test build for powerpc (which has its own config file) fails as well :(. Ugh, I got no reports of this from linux-next or the 0-day build system, odd. Maybe the build system isn't as comprehensive as mine, or it just takes a bit longer. My system caught it because you updated linux-stable to 3.11-rc7, which triggers all builds. The functions are only declared if CONFIG_PM is defined, yet are called unconditionally. This means the patch breaks in all configurations where CONFIG_PM is undefined and CONFIG_USB_OHCI_HCD_PCI is defined. Add this to the agenda at the kernel summit: We need more automated test coverage. It is a bit scary that my little pc-based server farm catches problems like this faster than everything else out there. And it isn't even the kind of problem I am looking for, but rather a side effect of the builds I am running. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/7] cpufreq: Add boost frequency support in core
Some minor nitpicking, nothing much :)
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
+static int cpufreq_boost_set_sw(int state)
+{
+ struct cpufreq_frequency_table *freq_table;
+ struct cpufreq_policy *policy;
+ int ret = -EINVAL;
+
+ list_for_each_entry(policy, cpufreq_policy_list, policy_list) {
+ freq_table = cpufreq_frequency_get_table(policy-cpu);
+ if (freq_table) {
+ ret = cpufreq_frequency_table_cpuinfo(policy,
+ freq_table);
+ if (!ret) {
+ policy-user_policy.max = policy-max;
+ __cpufreq_governor(policy,
CPUFREQ_GOV_LIMITS);
+ }
In case ret wasn't 0 (i.e. we failed), we should print an error
message and break
our loop ?
+ }
+ }
+
+ return ret;
+}
+
+int cpufreq_boost_trigger_state(int state)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ if (cpufreq_driver-boost_enabled == state)
+ return 0;
+
+ write_lock_irqsave(cpufreq_driver_lock, flags);
+ cpufreq_driver-boost_enabled = state;
+ write_unlock_irqrestore(cpufreq_driver_lock, flags);
+
+ ret = cpufreq_driver-set_boost(state);
+ if (ret) {
+ write_lock_irqsave(cpufreq_driver_lock, flags);
+ cpufreq_driver-boost_enabled = !state;
+ write_unlock_irqrestore(cpufreq_driver_lock, flags);
+
+ pr_err(%s: Cannot %s BOOST\n, __func__,
+ state ? enabled : disabled);
s/enabled/enable and s/disabled/disable
+ }
+
+ return ret;
+}
+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/7] cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: The Intel's hardware based boost solution driver has been changed to cooperate with common cpufreq boost framework. The global sysfs boost attribute entry code (/sys/devices/system/cpu/cpufreq/boost) has been moved to a core cpufreq code. This attribute is now only visible, when cpufreq driver supports it. The _store_boost() function has been redesigned to be used as set_boost callback. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Myungjoo Ham myungjoo@samsung.com --- Changes for v7: - Remove superfluous acpi_cpufreq_driver.boost_supported = false at acpi_cpufreq_boost_init() Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuset: mm: Reduce large amounts of memory barrier related damage v3
On 08/23/2013 02:15 PM, Peter Zijlstra wrote:
So I guess the quick and ugly solution is something like the below.
This still crashes :)
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1762,19 +1762,21 @@ unsigned slab_node(void)
static unsigned offset_il_node(struct mempolicy *pol,
struct vm_area_struct *vma, unsigned long off)
{
- unsigned nnodes = nodes_weight(pol-v.nodes);
- unsigned target;
- int c;
- int nid = -1;
+ unsigned nnodes, target;
+ int c, nid;
+again:
+ nnodes = nodes_weight(pol-v.nodes);
if (!nnodes)
return numa_node_id();
+
target = (unsigned int)off % nnodes;
- c = 0;
- do {
+ for (c = 0, nid = -1; c = target; c++)
nid = next_node(nid, pol-v.nodes);
- c++;
- } while (c = target);
+
+ if (unlikely((unsigned)nid = MAX_NUMNODES))
+ goto again;
I'll go kick off a compile that replaces the conditional above with:
if (unlikely(!node_online(nid)))
goto again;
return nid;
}
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/7] thermal:boost: Automatic enable/disable of BOOST feature
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote:
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index b5defd4..ec19da9 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -408,10 +408,24 @@ int cpufreq_frequency_table_target(struct
cpufreq_policy *policy,
void cpufreq_frequency_table_update_policy_cpu(struct cpufreq_policy
*policy);
ssize_t cpufreq_show_cpus(const struct cpumask *mask, char *buf);
+#ifdef CONFIG_CPU_FREQ
int cpufreq_boost_trigger_state(int state);
int cpufreq_boost_supported(void);
int cpufreq_boost_enabled(void);
-
+#else
+static inline int cpufreq_boost_trigger_state(int state)
+{
+ return 0;
+}
+static inline int cpufreq_boost_supported(void)
+{
+ return 0;
+}
+static inline int cpufreq_boost_enabled(void)
+{
+ return 0;
+}
+#endif
I almost gave an Ack before I saw this :)
This should be moved to the first patch I believe..
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 4/7] cpufreq:boost:Kconfig: Provide support for software managed BOOST
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: For safety reasons new flag - CONFIG_CPU_FREQ_BOOST_SW has been added. Only after selecting EXYNOS Frequency Overclocking - Software Kconfig option the software managed boost is enabled. It also selects thermal subsystem to be compiled in. Thermal is necessary for disabling boost and cooling down the device when overheating detected. Boost _MUST_NOT_ work without thermal subsystem with properly defined overheating temperatures. This option doesn't affect x86's ACPI hardware managed boost support (i.e. Intel, AMD). In this situation boost management is embedded at hardware. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Myungjoo Ham myungjoo@samsung.com --- Changes for v7: - Remove superfluous default n definition - Generic CPU_FREQ_BOOST_SW depends on THERMAL Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/7] cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: The cpufreq_driver's boost_supported flag is true only when boost support is explicitly enabled. Boost related attributes are exported only under the same condition. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Myungjoo Ham myungjoo@samsung.com --- Changes for v7: - Replace CONFIG_CPU_FREQ_BOOST_SW with CONFIG_ARM_EXYNOS_CPU_FREQ_BOOST_SW - Move boost_supported initialization to struct cpufreq_driver exynos_driver Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
Hi Stephen,
Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
Freescale FTM PWM
On 08/23/2013 01:36 AM, Thierry Reding wrote:
On Thu, Aug 22, 2013 at 08:26:10AM +0200, Sascha Hauer wrote:
On Thu, Aug 22, 2013 at 02:55:42AM +, Xiubo Li-B47053 wrote:
Hi Tomasz,
Thanks for your comments.
Could you explain meaning of this property more precisely?
I'm interested especially how is this related to the PWM IP block
and boards.
Yes. There are 8 channels most. While the pinctrls of 4th and 5th
channels could be used by uart's Rx and Tx, then these 2 channels
won't be used for pwm output, so there will be 6 channels available
by the pwm. Thus, the pwm chip will register only 6 pwms(6 channels)
most(fsl,pwm-channel-orders = {0 1 2 3
6 7}).And also the fsl,pwm-channel-number will be 6.
If the chip has eight PWMs I would register all of them. If some of
them are not routed out by the pinmux then just nothing happens if
you use them. In a sane devicetree they won't be referenced anyway
when they are not routed out of the SoC.
In that case, shouldn't this be hooked up to the pinctrl subsystem as
well? As I understand the above, the logical thing would be for each
PWM channel's .request() operation to configure the pinmuxing
appropriately. And if it can't be configured as necessary then
.request() should return an error (or propagate the error from the
pinctrl subsystem).
I think the pin-muxing should be static, i.e. set up when the PWM device
as a whole probe()s, rather than being twiddled at request/free time.
Certainly the pinmux support in the device core is now set up to acquire
the default state right before probe(). I don't see a need to do anything
custom here.
As we have tolk about this before in [PATCH 1/4]:
Why do you need to manipulate the pinctrl to en/disable a channel?
This is because in Vybrid VF610 TOWER board, there are 4 leds, and each
led's one point(diode's positive pole) is connected to 3.3V, and the
other point is connected to pwm's one channel. When the 4 pinctrls are
configured as enable at the same time, the 4 pinctrls is low valtage, and
the 4 leds will be lighted up as default, then when you enable/disable
one led will effects others.
These pinctrls are belong to pwm, and I don't think led or other customer
could control them directly.
So, here I authorize the 4 pinctrls to each channel controls.
For the reason above, I have to control the pinctrls separately.
If all the pinctrls set as default state, the 8 pinctrls must be controlled
together.
And the 4 leds will all be lighted up as default and will influence each other.
Thanks very much.
--
Best Regards.
Xiubo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 7/7] cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: Special driver data flag (CPUFREQ_BOOST_FREQ) has been added to indicate frequency, which can be only enabled for BOOST mode. This frequency shall be used only for limited time, since it might cause target device to overheat. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Myungjoo Ham myungjoo@samsung.com --- Changes for v7: - None Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 6/7] Documentation:cpufreq:boost: Update BOOST documentation
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: Since the support for software and hardware controlled boosting has been added, the corresponding Documentation entry had been updated. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Myungjoo Ham myungjoo@samsung.com --- Changes for v7: - None Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
The Patch adds nodes for TPS659038 PMIC for DRA7 boards.
It is based on top of:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.
Documentation: Documentation/devicetree/bindings/mfd/palmas.txt
Documentation/devicetree/bindings/regulator/palmas-pmic.txt
Boot Tested on DRA7 d1 Board.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 118
1 file changed, 118 insertions(+)
Index: linux/arch/arm/boot/dts/dra7-evm.dts
===
--- linux.orig/arch/arm/boot/dts/dra7-evm.dts 2013-08-26 09:57:52.496173554
+0530
+++ linux/arch/arm/boot/dts/dra7-evm.dts2013-08-26 10:38:44.995414695
+0530
@@ -93,6 +93,119 @@
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ tps659038: tps659038@58 {
+ compatible = ti,tps659038;
+ reg = 0x58;
+
+ tps659038_pmic {
+ compatible = ti,tps659038-pmic;
+
+ regulators {
+ smps123_reg: smps123 {
+ /* VDD_MPU */
+ regulator-name = smps123;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
125;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ /* VDD_DSPEVE */
+ regulator-name = smps45;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
115;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ /* VDD_GPU - over VDD_SMPS6 */
+ regulator-name = smps6;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
1250;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ /* CORE_VDD */
+ regulator-name = smps7;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
103;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ /* VDD_IVAHD */
+ regulator-name = smps8;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
125;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ /* VDDS1V8 */
+ regulator-name = smps9;
+ regulator-min-microvolt =
180;
+ regulator-max-microvolt =
180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ /* LDO1_OUT -- SDIO */
+ regulator-name = ldo1;
+ regulator-min-microvolt =
180;
+ regulator-max-microvolt =
330;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ /* VDD_RTCIO */
+ /* LDO2 - VDDSHV5, LDO2 also
goes to CAN_PHY_3V3 */
+ regulator-name = ldo2;
+ regulator-min-microvolt =
330;
+
Re: [PATCH v6 01/10] tracing: Add support for SOFT_DISABLE to syscall events
(2013/08/23 8:27), Tom Zanussi wrote:
The original SOFT_DISABLE patches didn't add support for soft disable
of syscall events; this adds it and paves the way for future patches
allowing triggers to be added to syscall events, since triggers are
built on top of SOFT_DISABLE.
Add an array of ftrace_event_file pointers indexed by syscall number
to the trace array and remove the existing enabled bitmaps, which as a
result are now redundant. The ftrace_event_file structs in turn
contain the soft disable flags we need for per-syscall soft disable
accounting; later patches add additional 'trigger' flags and
per-syscall triggers and filters.
This looks good for me.
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
kernel/trace/trace.h | 4 ++--
kernel/trace/trace_syscalls.c | 36 ++--
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index fe39acd..b1227b9 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -192,8 +192,8 @@ struct trace_array {
#ifdef CONFIG_FTRACE_SYSCALLS
int sys_refcount_enter;
int sys_refcount_exit;
- DECLARE_BITMAP(enabled_enter_syscalls, NR_syscalls);
- DECLARE_BITMAP(enabled_exit_syscalls, NR_syscalls);
+ struct ftrace_event_file *enter_syscall_files[NR_syscalls];
+ struct ftrace_event_file *exit_syscall_files[NR_syscalls];
#endif
int stop_count;
int clock_id;
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 559329d..230cdb6 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -302,6 +302,7 @@ static int __init syscall_exit_define_fields(struct
ftrace_event_call *call)
static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id)
{
struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file;
struct syscall_trace_enter *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -314,7 +315,13 @@ static void ftrace_syscall_enter(void *data, struct
pt_regs *regs, long id)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr 0)
return;
- if (!test_bit(syscall_nr, tr-enabled_enter_syscalls))
+
+ /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+ ftrace_file = rcu_dereference_raw(tr-enter_syscall_files[syscall_nr]);
+ if (!ftrace_file)
+ return;
+
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, ftrace_file-flags))
return;
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -345,6 +352,7 @@ static void ftrace_syscall_enter(void *data, struct
pt_regs *regs, long id)
static void ftrace_syscall_exit(void *data, struct pt_regs *regs, long ret)
{
struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file;
struct syscall_trace_exit *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -356,7 +364,13 @@ static void ftrace_syscall_exit(void *data, struct
pt_regs *regs, long ret)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr 0)
return;
- if (!test_bit(syscall_nr, tr-enabled_exit_syscalls))
+
+ /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+ ftrace_file = rcu_dereference_raw(tr-exit_syscall_files[syscall_nr]);
+ if (!ftrace_file)
+ return;
+
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, ftrace_file-flags))
return;
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -397,7 +411,7 @@ static int reg_event_syscall_enter(struct
ftrace_event_file *file,
if (!tr-sys_refcount_enter)
ret = register_trace_sys_enter(ftrace_syscall_enter, tr);
if (!ret) {
- set_bit(num, tr-enabled_enter_syscalls);
+ rcu_assign_pointer(tr-enter_syscall_files[num], file);
tr-sys_refcount_enter++;
}
mutex_unlock(syscall_trace_lock);
@@ -415,9 +429,14 @@ static void unreg_event_syscall_enter(struct
ftrace_event_file *file,
return;
mutex_lock(syscall_trace_lock);
tr-sys_refcount_enter--;
- clear_bit(num, tr-enabled_enter_syscalls);
+ rcu_assign_pointer(tr-enter_syscall_files[num], NULL);
if (!tr-sys_refcount_enter)
unregister_trace_sys_enter(ftrace_syscall_enter, tr);
+ /*
+ * Callers expect the event to be completely disabled on
+ * return, so wait for current handlers to finish.
+ */
+ synchronize_sched();
mutex_unlock(syscall_trace_lock);
}
@@ -435,7 +454,7 @@ static int reg_event_syscall_exit(struct
ftrace_event_file *file,
Re: [PATCH tip/core/rcu 8/9] nohz_full: Add full-system-idle state machine
On 08/20/2013 10:47 AM, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds the state machine that takes the per-CPU idle data
as input and produces a full-system-idle indication as output. This
state machine is driven out of RCU's quiescent-state-forcing
mechanism, which invokes rcu_sysidle_check_cpu() to collect per-CPU
idle state and then rcu_sysidle_report() to drive the state machine.
The full-system-idle state is sampled using rcu_sys_is_idle(), which
also drives the state machine if RCU is idle (and does so by forcing
RCU to become non-idle). This function returns true if all but the
timekeeping CPU (tick_do_timer_cpu) are idle and have been idle long
enough to avoid memory contention on the full_sysidle_state state
variable. The rcu_sysidle_force_exit() may be called externally
to reset the state machine back into non-idle state.
For large systems the state machine is driven out of RCU's
force-quiescent-state logic, which provides good scalability at the price
of millisecond-scale latencies on the transition to full-system-idle
state. This is not so good for battery-powered systems, which are usually
small enough that they don't need to care about scalability, but which
do care deeply about energy efficiency. Small systems therefore drive
the state machine directly out of the idle-entry code. The number of
CPUs in a small system is defined by a new NO_HZ_FULL_SYSIDLE_SMALL
Kconfig parameter, which defaults to 8. Note that this is a build-time
definition.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Lai Jiangshan la...@cn.fujitsu.com
[ paulmck: Use true and false for boolean constants per Lai Jiangshan. ]
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
include/linux/rcupdate.h | 18 +++
kernel/rcutree.c | 16 ++-
kernel/rcutree.h | 5 +
kernel/rcutree_plugin.h | 284
++-
kernel/time/Kconfig | 27 +
5 files changed, 343 insertions(+), 7 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 30bea9c..f1f1bc3 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -1011,4 +1011,22 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return
false; }
#endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */
+/* Only for use by adaptive-ticks code. */
+#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
+extern bool rcu_sys_is_idle(void);
+extern void rcu_sysidle_force_exit(void);
+#else /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
+
+static inline bool rcu_sys_is_idle(void)
+{
+ return false;
+}
+
+static inline void rcu_sysidle_force_exit(void)
+{
+}
+
+#endif /* #else #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
+
+
#endif /* __LINUX_RCUPDATE_H */
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 7b5be56..eca70f44 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -734,6 +734,7 @@ static int dyntick_save_progress_counter(struct rcu_data
*rdp,
bool *isidle, unsigned long *maxj)
{
rdp-dynticks_snap = atomic_add_return(0, rdp-dynticks-dynticks);
+ rcu_sysidle_check_cpu(rdp, isidle, maxj);
return (rdp-dynticks_snap 0x1) == 0;
}
@@ -1373,11 +1374,17 @@ int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
rsp-n_force_qs++;
if (fqs_state == RCU_SAVE_DYNTICK) {
/* Collect dyntick-idle snapshots. */
+ if (is_sysidle_rcu_state(rsp)) {
+ isidle = 1;
+ maxj = jiffies - ULONG_MAX / 4;
+ }
force_qs_rnp(rsp, dyntick_save_progress_counter,
isidle, maxj);
+ rcu_sysidle_report_gp(rsp, isidle, maxj);
fqs_state = RCU_FORCE_QS;
} else {
/* Handle dyntick-idle and offline CPUs. */
+ isidle = 0;
force_qs_rnp(rsp, rcu_implicit_dynticks_qs, isidle, maxj);
}
/* Clear flag to prevent immediate re-entry. */
@@ -2103,9 +2110,12 @@ static void force_qs_rnp(struct rcu_state *rsp,
cpu = rnp-grplo;
bit = 1;
for (; cpu = rnp-grphi; cpu++, bit = 1) {
- if ((rnp-qsmask bit) != 0
- f(per_cpu_ptr(rsp-rda, cpu), isidle, maxj))
- mask |= bit;
+ if ((rnp-qsmask bit) != 0) {
+ if ((rnp-qsmaskinit bit) != 0)
+ *isidle = 0;
+ if (f(per_cpu_ptr(rsp-rda, cpu), isidle, maxj))
+ mask |= bit;
+ }
}
if (mask != 0) {
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 9dd8b17..6fd3659 100644
---
RE: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
Hi Thierry,
Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
Freescale FTM PWM
On Thu, Aug 22, 2013 at 08:26:10AM +0200, Sascha Hauer wrote:
On Thu, Aug 22, 2013 at 02:55:42AM +, Xiubo Li-B47053 wrote:
Hi Tomasz,
Thanks for your comments.
Could you explain meaning of this property more precisely? I'm
interested especially how is this related to the PWM IP block and
boards.
Yes.
There are 8 channels most. While the pinctrls of 4th and 5th
channels could be used by uart's Rx and Tx, then these 2 channels
won't be used for pwm output, so there will be 6 channels available
by the pwm.
Thus, the pwm chip will register only 6 pwms(6 channels)
most(fsl,pwm-channel-orders = {0 1 2 3 6 7}).And also the fsl,pwm-
channel-number will be 6.
If the chip has eight PWMs I would register all of them. If some of
them are not routed out by the pinmux then just nothing happens if you
use them. In a sane devicetree they won't be referenced anyway when
they are not routed out of the SoC.
In that case, shouldn't this be hooked up to the pinctrl subsystem as
well? As I understand the above, the logical thing would be for each PWM
channel's .request() operation to configure the pinmuxing appropriately.
And if it can't be configured as necessary then .request() should return
an error (or propagate the error from the pinctrl subsystem).
That's maybe better, if so, the pinctrl configuration must be split into two
steps:
1, get the channel pinctrl active and idle states by callig
pinctrl_lookup_state() in .request().
2, select the proper state in .enable()/.disable().
Thanks very much.
--
Best Regards.
Xiubo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
