* Re: [v5][PATCH 3/6] book3e/kgdb: update thread's dbcr0
From: Scott Wood @ 2013-10-18 22:57 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1371724110-8250-4-git-send-email-tiejun.chen@windriver.com>
On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> gdb always need to generate a single step properly to invoke
> a kgdb state. But with lazy interrupt, book3e can't always
> trigger a debug exception with a single step since the current
> is blocked for handling those pending exception, then we miss
> that expected dbcr configuration at last to generate a debug
> exception.
What do you mean by "the current is blocked"? Could you explain more
clearly what lazy EE has to do with MSR_DE and DBCR0?
> So here we also update thread's dbcr0 to make sure the current
> can go back with that missed dbcr0 configuration.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/kgdb.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index c1eef24..55409ac 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -410,7 +410,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> struct pt_regs *linux_regs)
> {
> char *ptr = &remcom_in_buffer[1];
> - unsigned long addr;
> + unsigned long addr, dbcr0;
>
> switch (remcom_in_buffer[0]) {
> /*
> @@ -427,8 +427,15 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> /* set the trace bit if we're stepping */
> if (remcom_in_buffer[0] == 's') {
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> - mtspr(SPRN_DBCR0,
> - mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
> + dbcr0 = mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
> + mtspr(SPRN_DBCR0, dbcr0);
> +#ifdef CONFIG_PPC_BOOK3E_64
This could as well be "CONFIG_PPC64" -- CONFIG_PPC_ADV_DEBUG_REGS
implies booke or 40x. Lazy EE is a CONFIG_PPC64 thing, not specifically
CONFIG_PPC_BOOK3E_64.
> + /* With lazy interrut we have to update thread dbcr0 here
s/interrut/interrupts/
> + * to make sure we can set debug properly at last to invoke
> + * kgdb again to work well.
> + */
> + current->thread.dbcr0 = dbcr0;
> +#endif
> linux_regs->msr |= MSR_DE;
> #else
> linux_regs->msr |= MSR_SE;
Hmm, what happens here if we enable KGDB on booke without
CONFIG_PPC_ADV_DEBUG_REGS? Kconfig doesn't appear to prevent it.
-Scott
^ permalink raw reply
* Re: [v5][PATCH 2/6] powerpc/book3e: store critical/machine/debug exception thread info
From: Scott Wood @ 2013-10-18 22:43 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1371724110-8250-3-git-send-email-tiejun.chen@windriver.com>
On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> We need to store thread info to these exception thread info like something
> we already did for PPC32.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 4d8e57f..07cf657 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -67,6 +67,18 @@
> std r10,PACA_##level##_STACK(r13);
> #endif
>
> +/* Store something to exception thread info */
> +#define BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(type) \
> + ld r14,PACAKSAVE(r13); \
> + CURRENT_THREAD_INFO(r14, r14); \
> + CURRENT_THREAD_INFO(r15, r1); \
> + ld r10,TI_FLAGS(r14); \
> + std r10,TI_FLAGS(r15); \
> + ld r10,TI_PREEMPT(r14); \
> + std r10,TI_PREEMPT(r15); \
> + ld r10,TI_TASK(r14); \
> + std r10,TI_TASK(r15);
Where is "type" used?
BTW, no need for a BOOK3E prefix for things local to this file.
-Scott
^ permalink raw reply
* Re: [v5][PATCH 1/6] powerpc/book3e: load critical/machine/debug exception stack
From: Scott Wood @ 2013-10-18 22:37 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1371724110-8250-2-git-send-email-tiejun.chen@windriver.com>
On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> We always alloc critical/machine/debug check exceptions. This is
> different from the normal exception. So we should load these exception
> stack properly like we did for booke.
This is "booke". Do you mean like "like we did for 32-bit"?
And the code is already trying to load the special stack; it just
happens that it's loading from a different location than the C code
placed the stack addresses. The changelog should point out the specific
thing that is being fixed.
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 49 +++++++++++++++++++++++++++++++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 4b23119..4d8e57f 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -36,6 +36,37 @@
> */
> #define SPECIAL_EXC_FRAME_SIZE INT_FRAME_SIZE
>
> +/* only on book3e */
> +#define DBG_STACK_BASE dbgirq_ctx
> +#define MC_STACK_BASE mcheckirq_ctx
> +#define CRIT_STACK_BASE critirq_ctx
> +
> +#ifdef CONFIG_RELOCATABLE
> +#define LOAD_STACK_BASE(reg, level) \
> + tovirt(r2,r2); \
> + LOAD_REG_ADDR(reg, level##_STACK_BASE);
> +#else
> +#define LOAD_STACK_BASE(reg, level) \
> + LOAD_REG_IMMEDIATE(reg, level##_STACK_BASE);
> +#endif
> +
> +#ifdef CONFIG_SMP
> +#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
> + mfspr r14,SPRN_PIR; \
> + slwi r14,r14,3; \
> + LOAD_STACK_BASE(r10, level); \
> + add r10,r10,r14; \
> + ld r10,0(r10); \
> + addi r10,r10,THREAD_SIZE; \
> + std r10,PACA_##level##_STACK(r13);
> +#else
> +#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
> + LOAD_STACK_BASE(r10, level); \
> + ld r10,0(r10); \
> + addi r10,r10,THREAD_SIZE; \
> + std r10,PACA_##level##_STACK(r13);
> +#endif
It looks like you're loading the stack from *irq_ctx, storing it in
PACA_*_stack, and then (immediately after this in the caller) loading it
back from PACA_*_STACK. Why not just load it from *irq_ctx and get rid
of PACA_*_STACK altogether -- or change the C code to initialize the
addresses in the PACA instead, and get ird of *irq_ctx on 64-bit?
> /* Exception prolog code for all exceptions */
> #define EXCEPTION_PROLOG(n, intnum, type, addition) \
> mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \
> @@ -68,20 +99,32 @@
> #define SPRN_GDBELL_SRR1 SPRN_GSRR1
>
> #define CRIT_SET_KSTACK \
> + andi. r10,r11,MSR_PR; \
> + bne 1f; \
> + BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
> ld r1,PACA_CRIT_STACK(r13); \
> - subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
> + subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
The caller will already check MSR_PR and override this if coming from
userspace; why do you need to check again here?
-Scott
^ permalink raw reply
* [PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta @ 2013-10-18 19:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmusta
In-Reply-To: <1382125125.2206.22.camel@tmusta-sc.rchland.ibm.com>
This patch addresses unaligned single precision floating point loads
and stores in the single-step code. The old implementation
improperly treated an 8 byte structure as an array of two 4 byte
words, which is a classic little endian bug.
Signed-off-by: Tom Musta <tmusta@gmail.com>
---
arch/powerpc/lib/sstep.c | 52 +++++++++++++++++++++++++++++++++++----------
1 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 570f2af..f6f17aa 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int (*func)(int, unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea & 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) &val[0];
+ ptr = (unsigned long) &data.ul;
if (sizeof(unsigned long) == 8 || nb == 4) {
- err = read_mem_unaligned(&val[0], ea, nb, regs);
- ptr += sizeof(unsigned long) - nb;
+ err = read_mem_unaligned(&data.ul[0], ea, nb, regs);
+ if (nb == 4)
+ ptr = (unsigned long)&(data.single.word);
} else {
/* reading a double on 32-bit */
- err = read_mem_unaligned(&val[0], ea, 4, regs);
+ err = read_mem_unaligned(&data.ul[0], ea, 4, regs);
if (!err)
- err = read_mem_unaligned(&val[1], ea + 4, 4, regs);
+ err = read_mem_unaligned(&data.ul[1], ea + 4, 4, regs);
}
if (err)
return err;
@@ -382,28 +396,42 @@ static int __kprobes do_fp_store(int rn, int (*func)(int, unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea & 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) &val[0];
+ ptr = (unsigned long) &data.ul[0];
if (sizeof(unsigned long) == 8 || nb == 4) {
- ptr += sizeof(unsigned long) - nb;
+ if (nb == 4)
+ ptr = (unsigned long)&(data.single.word);
err = (*func)(rn, ptr);
if (err)
return err;
- err = write_mem_unaligned(val[0], ea, nb, regs);
+ err = write_mem_unaligned(data.ul[0], ea, nb, regs);
} else {
/* writing a double on 32-bit */
err = (*func)(rn, ptr);
if (err)
return err;
- err = write_mem_unaligned(val[0], ea, 4, regs);
+ err = write_mem_unaligned(data.ul[0], ea, 4, regs);
if (!err)
- err = write_mem_unaligned(val[1], ea + 4, 4, regs);
+ err = write_mem_unaligned(data.ul[1], ea + 4, 4, regs);
}
return err;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] powerpc: Fix Unaligned Loads and Stores
From: Tom Musta @ 2013-10-18 19:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmusta
In-Reply-To: <1382125125.2206.22.camel@tmusta-sc.rchland.ibm.com>
This patch modifies the unaligned access routines of the sstep.c
module so that it properly reverses the bytes of storage operands
in the little endian kernel kernel. This is implemented by
breaking an unaligned little endian access into a combination of
single byte accesses plus an overal byte reversal operation.
Signed-off-by: Tom Musta <tmusta@gmail.com>
---
arch/powerpc/lib/sstep.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 5e0d0e9..570f2af 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -212,11 +212,19 @@ static int __kprobes read_mem_unaligned(unsigned long *dest, unsigned long ea,
{
int err;
unsigned long x, b, c;
+#ifdef __LITTLE_ENDIAN__
+ int len = nb; /* save a copy of the length for byte reversal */
+#endif
/* unaligned, do this in pieces */
x = 0;
for (; nb > 0; nb -= c) {
+#ifdef __LITTLE_ENDIAN__
+ c = 1;
+#endif
+#ifdef __BIG_ENDIAN__
c = max_align(ea);
+#endif
if (c > nb)
c = max_align(nb);
err = read_mem_aligned(&b, ea, c);
@@ -225,7 +233,24 @@ static int __kprobes read_mem_unaligned(unsigned long *dest, unsigned long ea,
x = (x << (8 * c)) + b;
ea += c;
}
+#ifdef __LITTLE_ENDIAN__
+ switch (len) {
+ case 2:
+ *dest = byterev_2(x);
+ break;
+ case 4:
+ *dest = byterev_4(x);
+ break;
+#ifdef __powerpc64__
+ case 8:
+ *dest = byterev_8(x);
+ break;
+#endif
+ }
+#endif
+#ifdef __BIG_ENDIAN__
*dest = x;
+#endif
return 0;
}
@@ -273,9 +298,29 @@ static int __kprobes write_mem_unaligned(unsigned long val, unsigned long ea,
int err;
unsigned long c;
+#ifdef __LITTLE_ENDIAN__
+ switch (nb) {
+ case 2:
+ val = byterev_2(val);
+ break;
+ case 4:
+ val = byterev_4(val);
+ break;
+#ifdef __powerpc64__
+ case 8:
+ val = byterev_8(val);
+ break;
+#endif
+ }
+#endif
/* unaligned or little-endian, do this in pieces */
for (; nb > 0; nb -= c) {
+#ifdef __LITTLE_ENDIAN__
+ c = 1;
+#endif
+#ifdef __BIG_ENDIAN__
c = max_align(ea);
+#endif
if (c > nb)
c = max_align(nb);
err = write_mem_aligned(val >> (nb - c) * 8, ea, c);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] powerpc: Enable emulate_step In Little Endian Mode
From: Tom Musta @ 2013-10-18 19:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmusta
In-Reply-To: <1382125125.2206.22.camel@tmusta-sc.rchland.ibm.com>
This patch modifies the endian chicken switch in the single step
emulation code (emulate_step()). The old (big endian) code bailed
early if a load or store instruction was to be emulated in little
endian mode.
The new code modifies the check and only bails in a cross-endian
situation (LE mode in a kernel compiled for BE and vice verse).
Signed-off-by: Tom Musta <tmusta@gmail.com>
---
arch/powerpc/lib/sstep.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index b1faa15..5e0d0e9 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1222,12 +1222,18 @@ int __kprobes emulate_step(struct pt_regs *regs,
unsigned int instr)
}
/*
- * Following cases are for loads and stores, so bail out
- * if we're in little-endian mode.
+ * Following cases are for loads and stores and this
+ * implementation does not support cross-endian. So
+ * bail out if this is the case.
*/
+#ifdef __BIG_ENDIAN__
if (regs->msr & MSR_LE)
return 0;
-
+#endif
+#ifdef __LITTLE_ENDIAN__
+ if (!regs->msr & MSR_LE)
+ return 0;
+#endif
/*
* Save register RA in case it's an update form load or store
* and the access faults.
--
1.7.1
^ permalink raw reply related
* [PATCH 0/3] powerpc: Fix Little Endian Bugs in Single Step Code
From: Tom Musta @ 2013-10-18 19:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmusta
This patch series addresses bugs in the PowerPC single-step emulation
code (arch/powerpc/lib/sstep.c) pertaining to Little Endian.
The existing code has a chicken switch for little endian. The first
patch softens the restriction so that only cross-endian modes are not
supported.
There is a general problem with unaligned little endian loads and stores.
This is addressed by the second patch.
Finally, there is a problem with unaligned single precision floating point
loads and stores which is addressed by the third patch.
Tom Musta (3):
powerpc: Enable emulate_step In Little Endian Mode
powerpc: Fix Unaligned Fixed Point Loads and Stores
powerpc: Fix Unaligned LE Floating Point Loads and Stores
arch/powerpc/lib/sstep.c | 109 +++++++++++++++++++++++++++++++++++++++------
1 files changed, 94 insertions(+), 15 deletions(-)
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Bhushan Bharat-R65777 @ 2013-10-18 19:24 UTC (permalink / raw)
To: Wood Scott-B07421, Wang Dongsheng-B40534; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1382124094.7979.885.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTksIDIwMTMgMTI6NTIgQU0NCj4gVG86IFdh
bmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBXb29kIFNj
b3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6
IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZvciBwdzIwIHN0YXRlIGFu
ZCBhbHRpdmVjDQo+IGlkbGUNCj4gDQo+IE9uIFRodSwgMjAxMy0xMC0xNyBhdCAyMjowMiAtMDUw
MCwgV2FuZyBEb25nc2hlbmctQjQwNTM0IHdyb3RlOg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4gPiBT
ZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywgMjAxMyAyOjQ2IFBNDQo+ID4gPiBUbzogV2FuZyBE
b25nc2hlbmctQjQwNTM0OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gQ2M6IGxpbnV4cHBjLWRl
dkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY1IDQvNF0gcG93
ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3RhdGUNCj4gPiA+IGFuZCBhbHRpdmVjIGlk
bGUNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+ID4g
PiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDExOjIyIEFNDQo+ID4gPiA+ID4g
PiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+
ID4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiA+ID4gPiBTdWJqZWN0
OiBSRTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjANCj4g
PiA+ID4gPiA+IHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g
Pg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiA+ID4gPiA+ID4gRnJvbTogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4gPiA+ID4gPiA+
IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDExOjIwIEFNDQo+ID4gPiA+ID4gPiA+
IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQ7IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4g
PiA+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiBTdWJq
ZWN0OiBSRTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAN
Cj4gPiA+ID4gPiA+ID4gc3RhdGUgYW5kIGFsdGl2ZWMgaWRsZQ0KPiA+ID4gPiA+ID4gPg0KPiA+
ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogV2FuZyBEb25nc2hlbmctQjQwNTM0
DQo+ID4gPiA+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgODoxNiBB
TQ0KPiA+ID4gPiA+ID4gPiA+IFRvOiBCaHVzaGFuIEJoYXJhdC1SNjU3Nzc7IFdvb2QgU2NvdHQt
QjA3NDIxDQo+ID4gPiA+ID4gPiA+ID4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
DQo+ID4gPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4
eDogYWRkIHN5c2ZzIGZvcg0KPiA+ID4gPiA+ID4gPiA+IHB3MjAgc3RhdGUgYW5kIGFsdGl2ZWMg
aWRsZQ0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0K
PiA+ID4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+
ID4gPiA+IEZyb206IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+ID4gPiA+ID4gPiA+ID4gU2Vu
dDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgMTowMSBBTQ0KPiA+ID4gPiA+ID4gPiA+ID4g
VG86IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNDsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiA+
ID4gPiA+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiA+
ID4gU3ViamVjdDogUkU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZv
cg0KPiA+ID4gPiA+ID4gPiA+ID4gcHcyMCBzdGF0ZSBhbmQgYWx0aXZlYyBpZGxlDQo+ID4gPiA+
ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+
ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4g
PiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTZW50
OiBUdWVzZGF5LCBPY3RvYmVyIDE1LCAyMDEzIDI6NTEgUE0NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
VG86IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBCaHVzaGFuIEJo
YXJhdC1SNjU3Nzc7DQo+ID4gPiA+ID4gPiA+ID4gPiA+IGxpbnV4cHBjLWRldkBsaXN0cy5vemxh
YnMub3JnOyBXYW5nDQo+ID4gPiA+ID4gPiA+ID4gPiBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiA+
ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5
c2ZzIGZvcg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBwdzIwIHN0YXRlIGFuZA0KPiA+ID4gPiA+ID4g
PiA+ID4gYWx0aXZlYyBpZGxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
PiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2NhbGUuY29tPg0K
PiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBBZGQgYSBzeXMgaW50ZXJm
YWNlIHRvIGVuYWJsZS9kaWFibGUgcHcyMCBzdGF0ZSBvcg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBh
bHRpdmVjIGlkbGUsIGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gY29udHJvbCB0aGUNCj4gPiA+ID4g
PiA+ID4gPiA+ID4gd2FpdCBlbnRyeSB0aW1lLg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gPiA+ID4gPiBFbmFibGUvRGlzYWJsZSBpbnRlcmZhY2U6DQo+ID4gPiA+ID4gPiA+ID4g
PiA+IDAsIGRpc2FibGUuIDEsIGVuYWJsZS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gL3N5cy9kZXZp
Y2VzL3N5c3RlbS9jcHUvY3B1WC9wdzIwX3N0YXRlDQo+ID4gPiA+ID4gPiA+ID4gPiA+IC9zeXMv
ZGV2aWNlcy9zeXN0ZW0vY3B1L2NwdVgvYWx0aXZlY19pZGxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+
DQo+ID4gPiA+ID4gPiA+ID4gPiA+IFNldCB3YWl0IHRpbWUgaW50ZXJmYWNlOihOYW5vc2Vjb25k
KQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiAvc3lzL2RldmljZXMvc3lzdGVtL2NwdS9jcHVYL3B3MjBf
d2FpdF90aW1lDQo+ID4gPiA+ID4gPiA+ID4gPiA+IC9zeXMvZGV2aWNlcy9zeXN0ZW0vY3B1L2Nw
dVgvYWx0aXZlY19pZGxlX3dhaXRfdGltZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBFeGFtcGxlOiBC
YXNlIG9uIFRCZnJlcSBpcyA0MU1IWi4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gMX40OChucyk6IFRC
WzYzXQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA0OX45Nyhucyk6IFRCWzYyXQ0KPiA+ID4gPiA+ID4g
PiA+ID4gPiA5OH4xOTUobnMpOiBUQls2MV0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gMTk2fjM5MChu
cyk6IFRCWzYwXQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiAzOTF+NzgwKG5zKTogVEJbNTldDQo+ID4g
PiA+ID4gPiA+ID4gPiA+IDc4MX4xNTYwKG5zKTogVEJbNThdDQo+ID4gPiA+ID4gPiA+ID4gPiA+
IC4uLg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTaWduZWQtb2Zm
LWJ5OiBXYW5nIERvbmdzaGVuZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA8ZG9uZ3NoZW5nLndhbmdA
ZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gLS0tDQo+ID4gPiA+ID4gPiA+ID4g
PiA+ICp2NToNCj4gPiA+ID4gPiA+ID4gPiA+ID4gQ2hhbmdlIGdldF9pZGxlX3RpY2tzX2JpdCBm
dW5jdGlvbiBpbXBsZW1lbnRhdGlvbi4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gPiA+ID4gKnY0Og0KPiA+ID4gPiA+ID4gPiA+ID4gPiBNb3ZlIGNvZGUgZnJvbSA4NXh4L2Nv
bW1vbi5jIHRvIGtlcm5lbC9zeXNmcy5jLg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+ID4gPiBSZW1vdmUgaGFzX3B3MjBfYWx0aXZlY19pZGxlIGZ1bmN0aW9uLg0KPiA+ID4g
PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBDaGFuZ2Ugd2FpdCAiZW50cnlfYml0
IiB0byB3YWl0IHRpbWUuDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+
IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gYi9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMNCj4gPiA+ID4gPiA+ID4gPiA+IGlu
ZGV4DQo+ID4gPiA+ID4gPiA+ID4gPiA+IDI3YTkwYjkuLjEwZDExMjggMTAwNjQ0DQo+ID4gPiA+
ID4gPiA+ID4gPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9rZXJuZWwvc3lzZnMuYw0KPiA+ID4gPiA+
ID4gPiA+ID4gPiArKysgYi9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMNCj4gPiA+ID4gPiA+
ID4gPiA+ID4gQEAgLTg1LDYgKzg1LDI4NCBAQCBfX3NldHVwKCJzbXQtc25vb3plLWRlbGF5PSIs
DQo+ID4gPiA+ID4gPiA+ID4gPiBzZXR1cF9zbXRfc25vb3plX2RlbGF5KTsNCj4gPiA+ID4gPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gICNlbmRpZiAvKiBDT05GSUdfUFBDNjQgKi8N
Cj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gKyNpZmRlZiBDT05GSUdf
RlNMX1NPQw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArI2RlZmluZSBNQVhfQklUCQkJCTYzDQo+ID4g
PiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gK3N0YXRpYyB1NjQgcHcyMF93
dDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gK3N0YXRpYyB1NjQgYWx0aXZlY19pZGxlX3d0Ow0KPiA+
ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgdW5zaWduZWQg
aW50IGdldF9pZGxlX3RpY2tzX2JpdCh1NjQgbnMpIHsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwl1
NjQgY3ljbGU7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwlp
ZiAobnMgPj0gMTAwMDApDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJCWN5Y2xlID0gZGl2X3U2NChu
cyArIDUwMCwgMTAwMCkgKg0KPiA+ID4gdGJfdGlja3NfcGVyX3VzZWM7DQo+ID4gPiA+ID4gPiA+
ID4gPiA+ICsJZWxzZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCQljeWNsZSA9IGRpdl91NjQobnMg
KiB0Yl90aWNrc19wZXJfdXNlYywgMTAwMCk7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gKwlpZiAoIWN5Y2xlKQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCQlyZXR1
cm4gMDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCXJldHVy
biBpbG9nMihjeWNsZSk7IH0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+
ID4gPiArc3RhdGljIHZvaWQgZG9fc2hvd19wd3JtZ3RjcjAodm9pZCAqdmFsKSB7DQo+ID4gPiA+
ID4gPiA+ID4gPiA+ICsJdTMyICp2YWx1ZSA9IHZhbDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0K
PiA+ID4gPiA+ID4gPiA+ID4gPiArCSp2YWx1ZSA9IG1mc3ByKFNQUk5fUFdSTUdUQ1IwKTsgfQ0K
PiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgc3NpemVf
dCBzaG93X3B3MjBfc3RhdGUoc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ID4gPiA+ID4gPiA+ID4g
PiArCQkJCXN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyDQo+ID4gPiAqYnVmKSB7
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdTMyIHZhbHVlOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiAr
CXVuc2lnbmVkIGludCBjcHUgPSBkZXYtPmlkOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4g
PiA+ID4gPiA+ID4gPiA+ICsJc21wX2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwgZG9fc2hvd19w
d3JtZ3RjcjAsDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsmdmFsdWUsIDEpOw0KPiA+ID4gPiA+ID4g
PiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdmFsdWUgJj0gUFdSTUdUQ1IwX1BXMjBf
V0FJVDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCXJldHVy
biBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCB2YWx1ZSA/IDEgOiAwKTsgfQ0KPiA+ID4gPiA+ID4gPiA+
ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgdm9pZCBkb19zdG9yZV9wdzIwX3N0
YXRlKHZvaWQgKnZhbCkgew0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCXUzMiAqdmFsdWUgPSB2YWw7
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdTMyIHB3MjBfc3RhdGU7DQo+ID4gPiA+ID4gPiA+ID4g
PiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwlwdzIwX3N0YXRlID0gbWZzcHIoU1BSTl9QV1JN
R1RDUjApOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJaWYg
KCp2YWx1ZSkNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJcHcyMF9zdGF0ZSB8PSBQV1JNR1RDUjBf
UFcyMF9XQUlUOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCWVsc2UNCj4gPiA+ID4gPiA+ID4gPiA+
ID4gKwkJcHcyMF9zdGF0ZSAmPSB+UFdSTUdUQ1IwX1BXMjBfV0FJVDsNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCW10c3ByKFNQUk5fUFdSTUdUQ1IwLCBwdzIw
X3N0YXRlKTsgfQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICtz
dGF0aWMgc3NpemVfdCBzdG9yZV9wdzIwX3N0YXRlKHN0cnVjdCBkZXZpY2UgKmRldiwNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gKwkJCQlzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gKwkJCQljb25zdCBjaGFyICpidWYsIHNpemVfdCBjb3VudCkgew0KPiA+
ID4gPiA+ID4gPiA+ID4gPiArCXUzMiB2YWx1ZTsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwl1bnNp
Z25lZCBpbnQgY3B1ID0gZGV2LT5pZDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+
ID4gPiA+ID4gPiArCWlmIChrc3RydG91MzIoYnVmLCAwLCAmdmFsdWUpKQ0KPiA+ID4gPiA+ID4g
PiA+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4g
PiA+ID4gPiA+ID4gPiArCWlmICh2YWx1ZSA+IDEpDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJCXJl
dHVybiAtRUlOVkFMOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+
ICsJc21wX2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwgZG9fc3RvcmVfcHcyMF9zdGF0ZSwNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gKyZ2YWx1ZSwgMSk7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gKwlyZXR1cm4gY291bnQ7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICt9
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gK3N0YXRpYyBzc2l6
ZV90IHNob3dfcHcyMF93YWl0X3RpbWUoc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ID4gPiA+ID4g
PiA+ID4gPiArCQkJCXN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyDQo+ID4gPiAq
YnVmKSB7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdTMyIHZhbHVlOw0KPiA+ID4gPiA+ID4gPiA+
ID4gPiArCXU2NCB0Yl9jeWNsZTsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwlzNjQgdGltZTsNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCXVuc2lnbmVkIGludCBj
cHUgPSBkZXYtPmlkOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+
ICsJaWYgKCFwdzIwX3d0KSB7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJCXNtcF9jYWxsX2Z1bmN0
aW9uX3NpbmdsZShjcHUsIGRvX3Nob3dfcHdybWd0Y3IwLA0KPiA+ID4gPiA+ID4gPiA+ID4gPiAr
JnZhbHVlLA0KPiA+ID4gPiA+ID4gPiAxKTsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJdmFsdWUg
PSAodmFsdWUgJiBQV1JNR1RDUjBfUFcyMF9FTlQpID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsJ
CQkJCVBXUk1HVENSMF9QVzIwX0VOVF9TSElGVDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+
ID4gPiA+ID4gPiA+ID4gPiArCQl0Yl9jeWNsZSA9ICgxIDw8IChNQVhfQklUIC0gdmFsdWUpKSAq
IDI7DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gSXMgdmFsdWUgPSAwIGFu
ZCB2YWx1ZSA9IDEgbGVnYWw/IFRoZXNlIHdpbGwgbWFrZQ0KPiA+ID4gPiA+ID4gPiA+ID4gdGJf
Y3ljbGUgPSAwLA0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJdGlt
ZSA9IGRpdl91NjQodGJfY3ljbGUgKiAxMDAwLCB0Yl90aWNrc19wZXJfdXNlYykNCj4gPiA+IC0g
MTsNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBBbmQgdGltZSA9IC0xOw0K
PiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBQbGVhc2UgbG9vayBhdCB0aGUgZW5k
IG9mIHRoZSBmdW5jdGlvbiwgOikNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ICJy
ZXR1cm4gc3ByaW50ZihidWYsICIlbGx1XG4iLCB0aW1lID4gMCA/IHRpbWUgOiAwKTsiDQo+ID4g
PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkga25vdyB5b3UgcmV0dXJuIDAgaWYgdmFsdWUgPSAw
LzEsIG15IHF1ZXN0aW9uIHdhcyB0aGF0LCBpcw0KPiA+ID4gPiA+ID4gPiB0aGlzIGNvcnJlY3Qg
YXMgcGVyIHNwZWNpZmljYXRpb24/DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEFoaCwg
YWxzbyBmb3IgInZhbHVlIiB1cHRvIDcgeW91IHdpbGwgcmV0dXJuIDAsIG5vPw0KPiA+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gSWYgdmFsdWUgPSAwLCBNQVhfQklUIC0gdmFsdWUgPSA2MyB0Yl9j
eWNsZSA9DQo+ID4gPiA+ID4gPiAweGZmZmZmZmZmX2ZmZmZmZmZmLCB0Yl9jeWNsZSAqIDEwMDAg
d2lsbCBvdmVyZmxvdywgYnV0IHRoaXMgc2l0dWF0aW9uDQo+IGlzIG5vdCBwb3NzaWJsZS4NCj4g
PiA+ID4gPiA+IEJlY2F1c2UgaWYgdGhlICJ2YWx1ZSA9IDAiIG1lYW5zIHRoaXMgZmVhdHVyZSB3
aWxsIGJlICJkaXNhYmxlIi4NCj4gPiA+ID4gPiA+IE5vdyBUaGUgZGVmYXVsdCB3YWl0IGJpdCBp
cyA1MChNQVhfQklUIC0gdmFsdWUsIHZhbHVlID0gMTMpLA0KPiA+ID4gPiA+ID4gdGhlIFBXMjAv
QWx0aXZlYyBJZGxlIHdhaXQgZW50cnkgdGltZSBpcyBhYm91dCAxbXMsIHRoaXMgdGltZQ0KPiA+
ID4gPiA+ID4gaXMgdmVyeSBsb25nIGZvciB3YWl0IGlkbGUgdGltZSwgYW5kIGl0J3MgY2Fubm90
IGJlDQo+ID4gPiA+ID4gPiBpbmNyZWFzZWQobWVhbnMgKE1BWF9CSVQNCj4gPiA+ID4gPiA+IC0g
dmFsdWUpDQo+ID4gPiA+ID4gY2Fubm90IGdyZWF0ZXIgdGhhbiA1MCkuDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiBXaGF0IHlvdSBzYWlkIGlzIG5vdCBvYnZpb3VzIGZyb20gY29kZSBhbmQgc28gYXQg
bGVhc3Qgd3JpdGUgYQ0KPiA+ID4gPiA+IGNvbW1lbnQgdGhhdCB2YWx1ZSB3aWxsIGJlIGFsd2F5
cyA+PSAxMyBvciB2YWx1ZSB3aWxsIG5ldmVyIGJlDQo+ID4gPiA+ID4gbGVzcyB0aGFuIDwgOCBh
bmQgYmVsb3cgY2FsY3VsYXRpb24gd2lsbCBub3Qgb3ZlcmZsb3cuIG1heSBiZQ0KPiA+ID4gPiA+
IGVycm9yIG91dCBpZiB2YWx1ZSBpcyBsZXNzIHRoYW4gOC4NCj4gPiA+ID4gPg0KPiA+ID4gPiBU
aGUgInZhbHVlIiBsZXNzIHRoYW4gMTAsIHRoaXMgd2lsbCBvdmVyZmxvdy4NCj4gPiA+ID4gVGhl
cmUgaXMgbm90IGVycm9yLCBUaGUgY29kZSBJIGtuZXcgaXQgY291bGQgbm90IGJlIGxlc3MgdGhh
biAxMCwNCj4gPiA+ID4gdGhhdCdzIHdoeSBJIHVzZSB0aGUgZm9sbG93aW5nIGNvZGUuIDopDQo+
ID4gPg0KPiA+ID4gSSBhbSBzb3JyeSB0byBwZXJzaXN0IGJ1dCB0aGlzIGlzIG5vdCBhYm91dCB3
aGF0IHlvdSBrbm93LCB0aGlzIGlzDQo+ID4gPiBhYm91dCBob3cgY29kZSBpcyByZWFkIGFuZCBj
b2RlIGRvZXMgbm90IHNheSB3aGF0IHlvdSBrbm93LCBzbyBhZGQgYQ0KPiA+ID4gY29tbWVudCBh
dCBsZWFzdCBhbmQgZXJyb3Igb3V0L3dhcm4gd2hlbiAidmFsdWUiIGlzIGxlc3MgdGhhbiBhIGNl
cnRhaW4NCj4gbnVtYmVyLg0KPiA+ID4NCj4gPiBTb3JyeSBmb3IgdGhlIGxhdGUgdG8gcmVzcG9u
c2UgdGhlIG1haWwuIElmIGl0IGNhdXNlZCBjb25mdXNpb24sIHdlIGNhbiBhZGQgYQ0KPiBjb21t
ZW50Lg0KPiA+DQo+ID4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgY29tbWVudD8NCj4gPiAvKg0K
PiA+ICAqIElmIHRoZSAidmFsdWUiIGxlc3MgdGhhbiAxMCwgdGhpcyB3aWxsIG92ZXJmbG93Lg0K
PiA+ICAqIEZyb20gYmVuY2htYXJrIHRlc3QsIHRoZSBkZWZhdWx0IHdhaXQgYml0IHdpbGwgbm90
IGJlIHNldCBsZXNzIHRoYW4gMTBiaXQuDQo+ID4gICogQmVjYXVzZSAxMCBiaXQgY29ycmVzcG9u
ZHMgdG8gdGhlIHdhaXQgZW50cnkgdGltZSBpcw0KPiA+IDQzOTM3NTU3MzQwMTk5OTYwOShucyks
DQo+ID4gICogZm9yIHdhaXQtZW50cnktaWRsZSB0aW1lIHRoaXMgdmFsdWUgbG9va3MgdG9vIGxv
bmcsIGFuZCB3ZSBjYW5ub3QNCj4gPiB1c2UgdGhvc2UNCj4gPiAgKiAibG9uZyIgdGltZSBhcyBh
IGRlZmF1bHQgd2FpdC1lbnRyeSB0aW1lLiBTbyBvdmVyZmxvdyBjb3VsZCBub3QNCj4gPiBoYXZl
IGhhcHBlbmVkDQo+ID4gICogYW5kIHdlIHVzZSB0aGlzIGNhbGN1bGF0aW9uIG1ldGhvZCB0byBn
ZXQgd2FpdC1lbnRyeS1pZGxlIHRpbWUuDQo+ID4gICovDQo+IA0KPiBJZiB0aGVyZSdzIHRvIGJl
IGEgbGltaXQgb24gdGhlIHRpbWVzIHdlIGFjY2VwdCwgbWFrZSBpdCBleHBsaWNpdC4NCj4gQ2hl
Y2sgZm9yIGl0IGJlZm9yZSBkb2luZyBhbnkgY29udmVyc2lvbnMsIGFuZCByZXR1cm4gYW4gZXJy
b3IgaWYgdXNlcnNwYWNlDQo+IHRyaWVzIHRvIHNldCBpdC4NCg0KSSBhZ3JlZS4gQW5kIGFjY29y
ZGluZ2x5IGNvbW1lbnQgd2lsbCBjaGFuZ2UgYW5kIGxvY2F0aW9uIG9mIGNvbW1lbnQgaW4gY29k
ZSB3aWxsIGFsc28gY2hhbmdlIDopDQoNCi1CaGFyYXQNCg0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-10-18 19:23 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B3391@039-SN2MPN1-021.039d.mgd.msft.net>
On Thu, 2013-10-17 at 21:36 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, October 18, 2013 12:52 AM
> > To: Wang Dongsheng-B40534
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> > On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Bhushan Bharat-R65777
> > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang Dongsheng-B40534
> > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bhushan Bharat-R65777
> > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wang Dongsheng-B40534
> > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > To: Wood Scott-B07421
> > > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
> > > > > > Dongsheng-B40534
> > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > > > and
> > > > > > altivec idle
> > > > > > >
> > > > > > > +static ssize_t show_pw20_wait_time(struct device *dev,
> > > > > > > + struct device_attribute *attr, char *buf) {
> > > > > > > + u32 value;
> > > > > > > + u64 tb_cycle;
> > > > > > > + s64 time;
> > > > > > > +
> > > > > > > + unsigned int cpu = dev->id;
> > > > > > > +
> > > > > > > + if (!pw20_wt) {
> > > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > > > 1);
> > > > > > > + value = (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > > +
> > > > > > > + tb_cycle = (1 << (MAX_BIT - value)) * 2;
> > > > > >
> > > > > > Is value = 0 and value = 1 legal? These will make tb_cycle = 0,
> > > > > >
> > > > > > > + time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > > > > >
> > > > > > And time = -1;
> > > > > >
> > > > > Please look at the end of the function, :)
> > > > >
> > > > > "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
> > > >
> > > > I know you return 0 if value = 0/1, my question was that, is this
> > > > correct as per specification?
> > > >
> > > > Ahh, also for "value" upto 7 you will return 0, no?
> > > >
> > > If value = 0, MAX_BIT - value = 63
> > > tb_cycle = 0xffffffff_ffffffff,
> >
> > Actually, tb_cycle will be undefined because you shifted a 32-bit value
> > (1) by more than 31 bits. s/1/1ULL/
> >
> Actually, we have been discussing this situation that could not have happened.
> See !pw20_wt branch, this branch is read default wait bit.
> The default wait bit is 50, the time is about 1ms.
> The default wait bit cannot less than 50, means the wait entry time cannot greater than 1ms.
> We have already begun benchmark test, and we got a preliminary results.
> 55, 56, 57bit looks good, but we need more benchmark to get the default bit.
What does the default have to do with it? The user could have set a
different value, and then read it back.
Plus, how much time corresponds to bit 50 depends on the actual timebase
frequency which could vary.
-Scott
^ permalink raw reply
* Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-10-18 19:21 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B33C3@039-SN2MPN1-021.039d.mgd.msft.net>
On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Bhushan Bharat-R65777
> > Sent: Thursday, October 17, 2013 2:46 PM
> > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> >
> >
> > > > > -----Original Message-----
> > > > > From: Wang Dongsheng-B40534
> > > > > Sent: Thursday, October 17, 2013 11:22 AM
> > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bhushan Bharat-R65777
> > > > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wang Dongsheng-B40534
> > > > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Bhushan Bharat-R65777
> > > > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and altivec idle
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > > > To: Wood Scott-B07421
> > > > > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > > > > > > > > Wang
> > > > > > > > Dongsheng-B40534
> > > > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > > state and
> > > > > > > > altivec idle
> > > > > > > > >
> > > > > > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > > > > >
> > > > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > > > idle, and
> > > > > > > > control the
> > > > > > > > > wait entry time.
> > > > > > > > >
> > > > > > > > > Enable/Disable interface:
> > > > > > > > > 0, disable. 1, enable.
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > > > >
> > > > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > > > 1~48(ns): TB[63]
> > > > > > > > > 49~97(ns): TB[62]
> > > > > > > > > 98~195(ns): TB[61]
> > > > > > > > > 196~390(ns): TB[60]
> > > > > > > > > 391~780(ns): TB[59]
> > > > > > > > > 781~1560(ns): TB[58]
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > Signed-off-by: Wang Dongsheng
> > > > > > > > > <dongsheng.wang@freescale.com>
> > > > > > > > > ---
> > > > > > > > > *v5:
> > > > > > > > > Change get_idle_ticks_bit function implementation.
> > > > > > > > >
> > > > > > > > > *v4:
> > > > > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > > > > >
> > > > > > > > > Remove has_pw20_altivec_idle function.
> > > > > > > > >
> > > > > > > > > Change wait "entry_bit" to wait time.
> > > > > > > > >
> > > > > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > b/arch/powerpc/kernel/sysfs.c
> > > > > > > > index
> > > > > > > > > 27a90b9..10d1128 100644
> > > > > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > > > > @@ -85,6 +85,284 @@ __setup("smt-snooze-delay=",
> > > > > > > > setup_smt_snooze_delay);
> > > > > > > > >
> > > > > > > > > #endif /* CONFIG_PPC64 */
> > > > > > > > >
> > > > > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > > > > +#define MAX_BIT 63
> > > > > > > > > +
> > > > > > > > > +static u64 pw20_wt;
> > > > > > > > > +static u64 altivec_idle_wt;
> > > > > > > > > +
> > > > > > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > > > > > + u64 cycle;
> > > > > > > > > +
> > > > > > > > > + if (ns >= 10000)
> > > > > > > > > + cycle = div_u64(ns + 500, 1000) *
> > tb_ticks_per_usec;
> > > > > > > > > + else
> > > > > > > > > + cycle = div_u64(ns * tb_ticks_per_usec, 1000);
> > > > > > > > > +
> > > > > > > > > + if (!cycle)
> > > > > > > > > + return 0;
> > > > > > > > > +
> > > > > > > > > + return ilog2(cycle);
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static void do_show_pwrmgtcr0(void *val) {
> > > > > > > > > + u32 *value = val;
> > > > > > > > > +
> > > > > > > > > + *value = mfspr(SPRN_PWRMGTCR0); }
> > > > > > > > > +
> > > > > > > > > +static ssize_t show_pw20_state(struct device *dev,
> > > > > > > > > + struct device_attribute *attr, char
> > *buf) {
> > > > > > > > > + u32 value;
> > > > > > > > > + unsigned int cpu = dev->id;
> > > > > > > > > +
> > > > > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > > > > > > > > +1);
> > > > > > > > > +
> > > > > > > > > + value &= PWRMGTCR0_PW20_WAIT;
> > > > > > > > > +
> > > > > > > > > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > > > > > > > > +
> > > > > > > > > +static void do_store_pw20_state(void *val) {
> > > > > > > > > + u32 *value = val;
> > > > > > > > > + u32 pw20_state;
> > > > > > > > > +
> > > > > > > > > + pw20_state = mfspr(SPRN_PWRMGTCR0);
> > > > > > > > > +
> > > > > > > > > + if (*value)
> > > > > > > > > + pw20_state |= PWRMGTCR0_PW20_WAIT;
> > > > > > > > > + else
> > > > > > > > > + pw20_state &= ~PWRMGTCR0_PW20_WAIT;
> > > > > > > > > +
> > > > > > > > > + mtspr(SPRN_PWRMGTCR0, pw20_state); }
> > > > > > > > > +
> > > > > > > > > +static ssize_t store_pw20_state(struct device *dev,
> > > > > > > > > + struct device_attribute *attr,
> > > > > > > > > + const char *buf, size_t count) {
> > > > > > > > > + u32 value;
> > > > > > > > > + unsigned int cpu = dev->id;
> > > > > > > > > +
> > > > > > > > > + if (kstrtou32(buf, 0, &value))
> > > > > > > > > + return -EINVAL;
> > > > > > > > > +
> > > > > > > > > + if (value > 1)
> > > > > > > > > + return -EINVAL;
> > > > > > > > > +
> > > > > > > > > + smp_call_function_single(cpu, do_store_pw20_state,
> > > > > > > > > +&value, 1);
> > > > > > > > > +
> > > > > > > > > + return count;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static ssize_t show_pw20_wait_time(struct device *dev,
> > > > > > > > > + struct device_attribute *attr, char
> > *buf) {
> > > > > > > > > + u32 value;
> > > > > > > > > + u64 tb_cycle;
> > > > > > > > > + s64 time;
> > > > > > > > > +
> > > > > > > > > + unsigned int cpu = dev->id;
> > > > > > > > > +
> > > > > > > > > + if (!pw20_wt) {
> > > > > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0,
> > > > > > > > > +&value,
> > > > > > 1);
> > > > > > > > > + value = (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > > > > +
> > > > > > > > > + tb_cycle = (1 << (MAX_BIT - value)) * 2;
> > > > > > > >
> > > > > > > > Is value = 0 and value = 1 legal? These will make tb_cycle =
> > > > > > > > 0,
> > > > > > > >
> > > > > > > > > + time = div_u64(tb_cycle * 1000, tb_ticks_per_usec)
> > - 1;
> > > > > > > >
> > > > > > > > And time = -1;
> > > > > > > >
> > > > > > > Please look at the end of the function, :)
> > > > > > >
> > > > > > > "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
> > > > > >
> > > > > > I know you return 0 if value = 0/1, my question was that, is
> > > > > > this correct as per specification?
> > > > > >
> > > > > > Ahh, also for "value" upto 7 you will return 0, no?
> > > > > >
> > > > > If value = 0, MAX_BIT - value = 63 tb_cycle = 0xffffffff_ffffffff,
> > > > > tb_cycle * 1000 will overflow, but this situation is not possible.
> > > > > Because if the "value = 0" means this feature will be "disable".
> > > > > Now The default wait bit is 50(MAX_BIT - value, value = 13), the
> > > > > PW20/Altivec Idle wait entry time is about 1ms, this time is very
> > > > > long for wait idle time, and it's cannot be increased(means
> > > > > (MAX_BIT
> > > > > - value)
> > > > cannot greater than 50).
> > > >
> > > > What you said is not obvious from code and so at least write a
> > > > comment that value will be always >= 13 or value will never be less
> > > > than < 8 and below calculation will not overflow. may be error out
> > > > if value is less than 8.
> > > >
> > > The "value" less than 10, this will overflow.
> > > There is not error, The code I knew it could not be less than 10,
> > > that's why I use the following code. :)
> >
> > I am sorry to persist but this is not about what you know, this is about
> > how code is read and code does not say what you know, so add a comment at
> > least and error out/warn when "value" is less than a certain number.
> >
> Sorry for the late to response the mail. If it caused confusion, we can add a comment.
>
> How about the following comment?
> /*
> * If the "value" less than 10, this will overflow.
> * From benchmark test, the default wait bit will not be set less than 10bit.
> * Because 10 bit corresponds to the wait entry time is 439375573401999609(ns),
> * for wait-entry-idle time this value looks too long, and we cannot use those
> * "long" time as a default wait-entry time. So overflow could not have happened
> * and we use this calculation method to get wait-entry-idle time.
> */
If there's to be a limit on the times we accept, make it explicit.
Check for it before doing any conversions, and return an error if
userspace tries to set it.
-Scott
^ permalink raw reply
* Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-10-18 19:02 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Wang Dongsheng-B40534,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C6F64@039-SN2MPN1-013.039d.mgd.msft.net>
On Fri, 2013-10-18 at 12:49 -0500, Bhushan Bharat-R65777 wrote:
>
> > -----Original Message-----
> > From: Wang Dongsheng-B40534
> > Sent: Friday, October 18, 2013 8:07 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec
> > idle
> >
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, October 18, 2013 12:52 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > > altivec idle
> > >
> > > On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > > To: Wood Scott-B07421
> > > > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > > > > > > > Wang
> > > > > > > Dongsheng-B40534
> > > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and
> > > > > > > altivec idle
> > > > > > > >
> > > > > > > > +static ssize_t show_pw20_wait_time(struct device *dev,
> > > > > > > > + struct device_attribute *attr, char *buf) {
> > > > > > > > + u32 value;
> > > > > > > > + u64 tb_cycle;
> > > > > > > > + s64 time;
> > > > > > > > +
> > > > > > > > + unsigned int cpu = dev->id;
> > > > > > > > +
> > > > > > > > + if (!pw20_wt) {
> > > > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > > > > 1);
> > > > > > > > + value = (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > > > +
> > > > > > > > + tb_cycle = (1 << (MAX_BIT - value)) * 2;
> > > > > > >
> > > > > > > Is value = 0 and value = 1 legal? These will make tb_cycle =
> > > > > > > 0,
> > > > > > >
> > > > > > > > + time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > > > > > >
> > > > > > > And time = -1;
> > > > > > >
> > > > > > Please look at the end of the function, :)
> > > > > >
> > > > > > "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
> > > > >
> > > > > I know you return 0 if value = 0/1, my question was that, is this
> > > > > correct as per specification?
> > > > >
> > > > > Ahh, also for "value" upto 7 you will return 0, no?
> > > > >
> > > > If value = 0, MAX_BIT - value = 63
> > > > tb_cycle = 0xffffffff_ffffffff,
> > >
> > > Actually, tb_cycle will be undefined because you shifted a 32-bit
> > > value
> > > (1) by more than 31 bits. s/1/1ULL/
> > >
>
> What Scott is saying is the left shift of "1" for more than 31 will be undefined.
> Scott this will be sign-extended, right?
It's undefined in C. I don't know what GCC on PPC specifically will do.
-Scott
^ permalink raw reply
* Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
From: Wolfgang Denk @ 2013-10-18 18:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1382114321.7979.840.camel@snotra.buserror.net>
Dear Scott,
In message <1382114321.7979.840.camel@snotra.buserror.net> you wrote:
>
> There's already been a patch posted for this:
> http://patchwork.ozlabs.org/patch/256747/
>
> I plan to apply it for my next pull request.
Ah, cool. Thanks!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"It is better to have tried and failed than to have failed to try,
but the result's the same." - Mike Dennison
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Bhushan Bharat-R65777 @ 2013-10-18 17:49 UTC (permalink / raw)
To: Wang Dongsheng-B40534, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B3391@039-SN2MPN1-021.039d.mgd.msft.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FuZyBEb25nc2hlbmct
QjQwNTM0DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOCwgMjAxMyA4OjA3IEFNDQo+IFRvOiBX
b29kIFNjb3R0LUIwNzQyMQ0KPiBDYzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BBVENIIHY1IDQvNF0gcG93ZXJw
Yy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3RhdGUgYW5kIGFsdGl2ZWMNCj4gaWRsZQ0KPiAN
Cj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogV29vZCBT
Y290dC1CMDc0MjENCj4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTgsIDIwMTMgMTI6NTIgQU0N
Cj4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2
NTc3NzsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiA+IGRldkBsaXN0cy5vemxhYnMu
b3JnDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5
c2ZzIGZvciBwdzIwIHN0YXRlIGFuZA0KPiA+IGFsdGl2ZWMgaWRsZQ0KPiA+DQo+ID4gT24gVGh1
LCAyMDEzLTEwLTE3IGF0IDAwOjUxIC0wNTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6
DQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9t
OiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIg
MTcsIDIwMTMgMTE6MjAgQU0NCj4gPiA+ID4gVG86IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNDsgV29v
ZCBTY290dC1CMDc0MjENCj4gPiA+ID4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
DQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjUgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBz
eXNmcyBmb3IgcHcyMCBzdGF0ZQ0KPiA+ID4gPiBhbmQgYWx0aXZlYyBpZGxlDQo+ID4gPiA+DQo+
ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
PiA+ID4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+ID4gPiBTZW50OiBUaHVy
c2RheSwgT2N0b2JlciAxNywgMjAxMyA4OjE2IEFNDQo+ID4gPiA+ID4gVG86IEJodXNoYW4gQmhh
cmF0LVI2NTc3NzsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiBDYzogbGludXhwcGMtZGV2
QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY1IDQvNF0g
cG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjANCj4gPiA+ID4gPiBzdGF0ZSBhbmQgYWx0
aXZlYyBpZGxlDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogQmh1c2hhbiBCaGFy
YXQtUjY1Nzc3DQo+ID4gPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywgMjAxMyAx
OjAxIEFNDQo+ID4gPiA+ID4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNjb3R0
LUIwNzQyMQ0KPiA+ID4gPiA+ID4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+
ID4gPiA+ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQg
c3lzZnMgZm9yIHB3MjANCj4gPiA+ID4gPiA+IHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gRnJvbTogV2FuZyBEb25nc2hlbmctQjQw
NTM0DQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTUsIDIwMTMgMjo1MSBQ
TQ0KPiA+ID4gPiA+ID4gPiBUbzogV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiA+ID4gQ2M6
IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+
ID4gPiA+ID4gPiA+IFdhbmcNCj4gPiA+ID4gPiA+IERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+ID4g
PiA+ID4gU3ViamVjdDogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9y
IHB3MjANCj4gPiA+ID4gPiA+ID4gc3RhdGUgYW5kDQo+ID4gPiA+ID4gPiBhbHRpdmVjIGlkbGUN
Cj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gK3N0YXRpYyBzc2l6ZV90IHNob3dfcHcyMF93
YWl0X3RpbWUoc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ID4gPiA+ID4gPiArCQkJCXN0cnVjdCBk
ZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpIHsNCj4gPiA+ID4gPiA+ID4gKwl1MzIg
dmFsdWU7DQo+ID4gPiA+ID4gPiA+ICsJdTY0IHRiX2N5Y2xlOw0KPiA+ID4gPiA+ID4gPiArCXM2
NCB0aW1lOw0KPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ICsJdW5zaWduZWQgaW50IGNw
dSA9IGRldi0+aWQ7DQo+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gKwlpZiAoIXB3MjBf
d3QpIHsNCj4gPiA+ID4gPiA+ID4gKwkJc21wX2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwgZG9f
c2hvd19wd3JtZ3RjcjAsICZ2YWx1ZSwNCj4gPiA+ID4gMSk7DQo+ID4gPiA+ID4gPiA+ICsJCXZh
bHVlID0gKHZhbHVlICYgUFdSTUdUQ1IwX1BXMjBfRU5UKSA+Pg0KPiA+ID4gPiA+ID4gPiArCQkJ
CQlQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQ7DQo+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+
ID4gKwkJdGJfY3ljbGUgPSAoMSA8PCAoTUFYX0JJVCAtIHZhbHVlKSkgKiAyOw0KPiA+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+IElzIHZhbHVlID0gMCBhbmQgdmFsdWUgPSAxIGxlZ2FsPyBUaGVzZSB3
aWxsIG1ha2UgdGJfY3ljbGUgPQ0KPiA+ID4gPiA+ID4gMCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+
ID4gPiA+ICsJCXRpbWUgPSBkaXZfdTY0KHRiX2N5Y2xlICogMTAwMCwgdGJfdGlja3NfcGVyX3Vz
ZWMpIC0gMTsNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBbmQgdGltZSA9IC0xOw0KPiA+ID4g
PiA+ID4NCj4gPiA+ID4gPiBQbGVhc2UgbG9vayBhdCB0aGUgZW5kIG9mIHRoZSBmdW5jdGlvbiwg
OikNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICJyZXR1cm4gc3ByaW50ZihidWYsICIlbGx1XG4iLCB0
aW1lID4gMCA/IHRpbWUgOiAwKTsiDQo+ID4gPiA+DQo+ID4gPiA+IEkga25vdyB5b3UgcmV0dXJu
IDAgaWYgdmFsdWUgPSAwLzEsIG15IHF1ZXN0aW9uIHdhcyB0aGF0LCBpcyB0aGlzDQo+ID4gPiA+
IGNvcnJlY3QgYXMgcGVyIHNwZWNpZmljYXRpb24/DQo+ID4gPiA+DQo+ID4gPiA+IEFoaCwgYWxz
byBmb3IgInZhbHVlIiB1cHRvIDcgeW91IHdpbGwgcmV0dXJuIDAsIG5vPw0KPiA+ID4gPg0KPiA+
ID4gSWYgdmFsdWUgPSAwLCBNQVhfQklUIC0gdmFsdWUgPSA2Mw0KPiA+ID4gdGJfY3ljbGUgPSAw
eGZmZmZmZmZmX2ZmZmZmZmZmLA0KPiA+DQo+ID4gQWN0dWFsbHksIHRiX2N5Y2xlIHdpbGwgYmUg
dW5kZWZpbmVkIGJlY2F1c2UgeW91IHNoaWZ0ZWQgYSAzMi1iaXQNCj4gPiB2YWx1ZQ0KPiA+ICgx
KSBieSBtb3JlIHRoYW4gMzEgYml0cy4gIHMvMS8xVUxMLw0KPiA+DQoNCldoYXQgU2NvdHQgaXMg
c2F5aW5nIGlzIHRoZSBsZWZ0IHNoaWZ0IG9mICIxIiBmb3IgbW9yZSB0aGFuIDMxIHdpbGwgYmUg
dW5kZWZpbmVkLg0KU2NvdHQgdGhpcyB3aWxsIGJlIHNpZ24tZXh0ZW5kZWQsIHJpZ2h0Pw0KDQot
QmhhcmF0DQoNCj4gQWN0dWFsbHksIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgc2l0dWF0
aW9uIHRoYXQgY291bGQgbm90IGhhdmUgaGFwcGVuZWQuDQo+IFNlZSAhcHcyMF93dCBicmFuY2gs
IHRoaXMgYnJhbmNoIGlzIHJlYWQgZGVmYXVsdCB3YWl0IGJpdC4NCj4gVGhlIGRlZmF1bHQgd2Fp
dCBiaXQgaXMgNTAsIHRoZSB0aW1lIGlzIGFib3V0IDFtcy4NCj4gVGhlIGRlZmF1bHQgd2FpdCBi
aXQgY2Fubm90IGxlc3MgdGhhbiA1MCwgbWVhbnMgdGhlIHdhaXQgZW50cnkgdGltZSBjYW5ub3QN
Cj4gZ3JlYXRlciB0aGFuIDFtcy4NCj4gV2UgaGF2ZSBhbHJlYWR5IGJlZ3VuIGJlbmNobWFyayB0
ZXN0LCBhbmQgd2UgZ290IGEgcHJlbGltaW5hcnkgcmVzdWx0cy4NCj4gNTUsIDU2LCA1N2JpdCBs
b29rcyBnb29kLCBidXQgd2UgbmVlZCBtb3JlIGJlbmNobWFyayB0byBnZXQgdGhlIGRlZmF1bHQg
Yml0Lg0KPiANCj4gCWlmICghcHcyMF93dCkgew0KPiAJCXNtcF9jYWxsX2Z1bmN0aW9uX3Npbmds
ZShjcHUsIGRvX3Nob3dfcHdybWd0Y3IwLCAmdmFsdWUsIDEpOw0KPiAJCXZhbHVlID0gKHZhbHVl
ICYgUFdSTUdUQ1IwX1BXMjBfRU5UKSA+Pg0KPiAJCQkJCVBXUk1HVENSMF9QVzIwX0VOVF9TSElG
VDsNCj4gDQo+IAkJdGJfY3ljbGUgPSAoMSA8PCAoTUFYX0JJVCAtIHZhbHVlKSkgKiAyOw0KPiAJ
CXRpbWUgPSBkaXZfdTY0KHRiX2N5Y2xlICogMTAwMCwgdGJfdGlja3NfcGVyX3VzZWMpIC0gMTsN
Cj4gCX0gZWxzZSB7DQo+IAkJdGltZSA9IHB3MjBfd3Q7DQo+IAl9DQo+IA0KPiBJZiBpdCBjYXVz
ZWQgY29uZnVzaW9uLCB3ZSBjYW4gYWRkIGEgY29tbWVudC4gQXMgSSBkaXNjdXNzIHdpdGggQmhh
cmF0Lg0KPiANCj4gPiA+IHRiX2N5Y2xlICogMTAwMCB3aWxsIG92ZXJmbG93LCBidXQgdGhpcyBz
aXR1YXRpb24gaXMgbm90IHBvc3NpYmxlLg0KPiA+ID4gQmVjYXVzZSBpZiB0aGUgInZhbHVlID0g
MCIgbWVhbnMgdGhpcyBmZWF0dXJlIHdpbGwgYmUgImRpc2FibGUiLg0KPiA+ID4gTm93IFRoZSBk
ZWZhdWx0IHdhaXQgYml0IGlzIDUwKE1BWF9CSVQgLSB2YWx1ZSwgdmFsdWUgPSAxMyksIHRoZQ0K
PiA+ID4gUFcyMC9BbHRpdmVjIElkbGUgd2FpdCBlbnRyeSB0aW1lIGlzIGFib3V0IDFtcywgdGhp
cyB0aW1lIGlzIHZlcnkNCj4gPiA+IGxvbmcgZm9yIHdhaXQgaWRsZSB0aW1lLCBhbmQgaXQncyBj
YW5ub3QgYmUgaW5jcmVhc2VkKG1lYW5zIChNQVhfQklUDQo+ID4gPiAtDQo+ID4gPiB2YWx1ZSkg
Y2Fubm90IGdyZWF0ZXIgdGhhbiA1MCkuDQo+ID4NCj4gPiBXaHkgY2FuIGl0IG5vdCBiZSBpbmNy
ZWFzZWQ/DQo+ID4NCj4gc2VlIGFib3ZlLCA6KQ0KDQoNCj4gDQo+IC1kb25nc2hlbmcNCj4gPiAt
U2NvdHQNCj4gPg0KDQo=
^ permalink raw reply
* Re: [PATCHv1 6/8] ASoC: fsl: add SGT15000 based audio machine driver.
From: Mark Brown @ 2013-10-18 17:33 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1382000477-17304-7-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
On Thu, Oct 17, 2013 at 05:01:15PM +0800, Xiubo Li wrote:
> + ret = snd_soc_register_card(&fsl_sgt1500_card);
> + if (ret) {
> + dev_err(&pdev->dev, "register soc sound card failed :%d\n",
> + ret);
> + return ret;
> + }
Use the newly added devm_snd_soc_register_card() (in -next).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv1 8/8] Documentation: Add device tree bindings for Freescale VF610 sound.
From: Mark Brown @ 2013-10-18 17:31 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1382000477-17304-9-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
On Thu, Oct 17, 2013 at 05:01:17PM +0800, Xiubo Li wrote:
> + -- Power supplies:
> + * Mic Bias
> +
> + -- SGTL5000 pins:
> + * MIC_IN
> + * LINE_IN
> + * HP_OUT
> + * LINE_OUT
Things that are part of the CODEC should be part of the CODEC binding
and this binding should reference that - this way the information
doesn't have to be replicated by all boards using the CODEC and if new
devices are supported by the CODEC driver then only that needs updating
hopefully.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv1 5/8] ASoC: sgtl5000: Revise the bugs about the sgt15000 codec.
From: Mark Brown @ 2013-10-18 17:28 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1382000477-17304-6-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Thu, Oct 17, 2013 at 05:01:14PM +0800, Xiubo Li wrote:
> @@ -883,14 +883,19 @@ static int ldo_regulator_register(struct snd_soc_codec *codec,
> struct regulator_init_data *init_data,
> int voltage)
> {
> +#ifdef CONFIG_SND_SOC_FSL_SGTL5000
> + return 0;
> +#else
> dev_err(codec->dev, "this setup needs regulator support in the kernel\n");
> return -EINVAL;
> +#endif
> }
If these systems don't actually need the internal regulator then should
they not be trying to enable it? Alternatively if it's OK to ignore
this then why is this conditional in the board?
If this is something that it's safe to ignore then it should either be
ignored all the time or should be controlled by platform data not by a
compile time #define.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] powerpc: Enable Little Endian Alignment Handler for Float Pair Instructions
From: Tom Musta @ 2013-10-18 17:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1382115864.2206.12.camel@tmusta-sc.rchland.ibm.com>
This patch enables alignment handling for the load/store floating point
pair instructions (lfdp, lfdpx, stfdp, stfdpx). The handler routine
is properly coded and only needs to be enabled.
Signed-off-by: Tom Musta <tmusta@gmail.com>
---
arch/powerpc/kernel/align.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index a3169a9..de91f3a 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -378,7 +378,6 @@ static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
* Only POWER6 has these instructions, and it does true little-endian,
* so we don't need the address swizzling.
*/
-#ifdef __BIG_ENDIAN__
static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
unsigned int flags)
{
@@ -406,7 +405,6 @@ static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
return -EFAULT;
return 1; /* exception handled and fixed up */
}
-#endif
#ifdef CONFIG_SPE
@@ -918,12 +916,8 @@ int fix_alignment(struct pt_regs *regs)
/* Special case for 16-byte FP loads and stores */
if (nb == 16) {
-#ifdef __BIG_ENDIAN__
PPC_WARN_ALIGNMENT(fp_pair, regs);
return emulate_fp_pair(addr, reg, flags);
-#else
- return -EFAULT;
-#endif
}
PPC_WARN_ALIGNMENT(unaligned, regs);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] powerpc: Fix Handler of Unaligned Load/Store Strings
From: Tom Musta @ 2013-10-18 17:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1382115864.2206.12.camel@tmusta-sc.rchland.ibm.com>
The alignment handler is incorrect for unaligned string instructions
in little endian mode. These instructions access data as arrays of
bytes and thus are endian neutral. However, the routine also handles
the load/store multiple instructions, which are NOT endian neutral.
This patch toggles the byte swapping flag for the string instructions
in little endian builds. This effectively disables the byte swapping
logic.
Signed-off-by: Tom Musta <tmusta@gmail.com>
---
arch/powerpc/kernel/align.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 6e3f977..a3169a9 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -254,15 +254,20 @@ static int emulate_dcbz(struct pt_regs *regs, unsigned char __user *addr)
* bottom 4 bytes of each register, and the loads clear the
* top 4 bytes of the affected register.
*/
+#ifdef __BIG_ENDIAN__
#ifdef CONFIG_PPC64
#define REG_BYTE(rp, i) *((u8 *)((rp) + ((i) >> 2)) + ((i) & 3) + 4)
#else
#define REG_BYTE(rp, i) *((u8 *)(rp) + (i))
#endif
+#endif
+
+#ifdef __LITTLE_ENDIAN__
+#define REG_BYTE(rp, i) (*(((u8 *)((rp) + ((i)>>2)) + ((i)&3))))
+#endif
#define SWIZ_PTR(p) ((unsigned char __user *)((p) ^ swiz))
-#ifdef __BIG_ENDIAN__
static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
unsigned int reg, unsigned int nb,
unsigned int flags, unsigned int instr,
@@ -304,6 +309,15 @@ static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
nb0 = nb + reg * 4 - 128;
nb = 128 - reg * 4;
}
+#ifdef __LITTLE_ENDIAN__
+ /*
+ * String instructions are endian neutral but the code
+ * below is not. Force byte swapping on so that the
+ * effects of swizzling are undone in the load/store
+ * loops below.
+ */
+ flags ^= SW;
+#endif
} else {
/* lwm, stmw */
nb = (32 - reg) * 4;
@@ -364,6 +378,7 @@ static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
* Only POWER6 has these instructions, and it does true little-endian,
* so we don't need the address swizzling.
*/
+#ifdef __BIG_ENDIAN__
static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
unsigned int flags)
{
@@ -882,13 +897,9 @@ int fix_alignment(struct pt_regs *regs)
* function
*/
if (flags & M) {
-#ifdef __BIG_ENDIAN__
PPC_WARN_ALIGNMENT(multiple, regs);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
-#else
- return -EFAULT;
-#endif
}
/* Verify the address of the operand */
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] powerpc: Alignment Handler Fixes for Little Endian
From: Tom Musta @ 2013-10-18 17:04 UTC (permalink / raw)
To: linuxppc-dev
This patch series fixes two bugs in the PowerPC Little Endian alignment
handler.
Tom Musta (2):
powerpc: Fix Handler of Unaligned Load/Store Strings
powerpc: Enable Little Endian Alignment Handler for Float Pair
Instructions
arch/powerpc/kernel/align.c | 25 +++++++++++++++----------
1 files changed, 15 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
From: Scott Wood @ 2013-10-18 16:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <1382081880-6666-1-git-send-email-wd@denx.de>
On Fri, 2013-10-18 at 09:38 +0200, Wolfgang Denk wrote:
> Default Debian PowerPC doesn't work on e500 because the code contains
> "lwsync" instructions, which are unsupported on this core. As a
> result, applications using this will crash with an "unhandled signal 4"
> "Illegal instruction" error.
>
> As a work around we add code to emulate this insn. This is expensive
> performance-wise, but allows to run standard user land code.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Scott Wood <scottwood@freescale.com>
> ---
> I am aware that the clean solution to the problem is to build user
> space with compiler options that match the target architecture.
> However, sometimes this is just too much effort.
>
> Also, of course the performance of such an emulation sucks. But the
> the occurrence of such instructions is so rare that no significant
> slowdown can be oserved.
>
> I'm not sure if this should / could go into mainline. I'm posting it
> primarily so it can be found should anybody else need this.
> - wd
>
> arch/powerpc/kernel/traps.c | 7 +++++++
> 1 file changed, 7 insertions(+)
There's already been a patch posted for this:
http://patchwork.ozlabs.org/patch/256747/
I plan to apply it for my next pull request.
-Scott
^ permalink raw reply
* Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Scott Wood @ 2013-10-18 16:31 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Mark Rutland, Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Li Yang-Leo-R58472, devicetree@vger.kernel.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B150C5CAB@039-SN2MPN1-013.039d.mgd.msft.net>
On Thu, 2013-10-17 at 21:06 -0500, Tang Yuantian-B29983 wrote:
> > On Wed, 2013-10-16 at 21:08 -0500, Tang Yuantian-B29983 wrote:
> > > > > > That shows the dividers as being somewhere in between the PLL
> > > > > > and the
> > > > MUX.
> > > > > > The MUX is where the divider is selected. There's nothing in
> > > > > > the PLL's programming interface that relates to the dividers.
> > > > > > As such it's simpler to model it as being part of the MUX.
> > > > > >
> > > > > > -Scott
> > > > > >
> > > > > I don't know whether it is simpler, but "modeling divider as being
> > > > > part
> > > > of the MUX"
> > > > > is your guess, right?
> > > > > If the "divider" is included in MUX, the MUX would not be called
> > "MUX".
> > > >
> > > > It's still selecting from multiple PLLs.
> > > >
> > > > > I don't know whether "divider" module exists or not. If it exists,
> > > > > it should be part of PLL or between PLL and MUX. wherever it was,
> > > > > the
> > > > device tree binding is appropriate.
> > > >
> > > > The device tree binding is unnecessarily complicated.
> > > >
> > > > > The P3041RM shows exactly each PLL has 2 outputs which definitely
> > > > > have
> > > > no "divider" at all.
> > > >
> > > > That diagram is a bit weird -- one of the outputs is used as is, and
> > > > the other is split into 1/2 and 1/4. It doesn't really matter
> > > > though; the end result is the same. We're describing the
> > > > programming interface, not artwork choices in the manual.
> > > >
> > > > -Scott
> > > >
> > > If the device tree needs to be modified, could you give me your
> > suggestions?
> >
> > My suggestion is to have only one output per PLL node. The MUX node
> > would have one input per PLL. Dividers would be handled internally to
> > the MUX driver.
> >
> > -Scott
> >
> I don't think your suggestion is constructive.
Hmm?
> Your suggestion is on the premise of that the "divider" is part of MUX,
> And I think it should be part of PLL.
> MUX can't CREATE clock which PLL can. So my thought is more reasonable.
> If the device tree documents like what you said, it would have few help for driver.
> The reason is obvious that the driver is still going to deal with the "divider"
> detail which varies from platform to platform.
> I will document as it was unless you prove your suggestion.
I can't follow this. My point is that my suggestion better matches the
programming model, and is simpler.
-Scott
^ permalink raw reply
* [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
From: Wolfgang Denk @ 2013-10-18 7:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Wolfgang Denk
Default Debian PowerPC doesn't work on e500 because the code contains
"lwsync" instructions, which are unsupported on this core. As a
result, applications using this will crash with an "unhandled signal 4"
"Illegal instruction" error.
As a work around we add code to emulate this insn. This is expensive
performance-wise, but allows to run standard user land code.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>
---
I am aware that the clean solution to the problem is to build user
space with compiler options that match the target architecture.
However, sometimes this is just too much effort.
Also, of course the performance of such an emulation sucks. But the
the occurrence of such instructions is so rare that no significant
slowdown can be oserved.
I'm not sure if this should / could go into mainline. I'm posting it
primarily so it can be found should anybody else need this.
- wd
arch/powerpc/kernel/traps.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f783c93..f330374 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs *regs)
return 0;
}
+ /* Emulating the lwsync insn as a sync insn */
+ if (instword == PPC_INST_LWSYNC) {
+ PPC_WARN_EMULATED(lwsync, regs);
+ asm volatile("sync" : : : "memory");
+ return 0;
+ }
+
/* Emulate the mcrxr insn. */
if ((instword & PPC_INST_MCRXR_MASK) == PPC_INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 5/7] jump_label: relax branch hinting restrictions
From: Radim Krčmář @ 2013-10-18 7:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-mips, x86, linux-doc, Heiko Carstens, sparclinux,
Paul Mackerras, H. Peter Anvin, Masami Hiramatsu, linux-s390,
Russell King, Raghavendra K T, Ingo Molnar, Andrew Jones,
Konrad Rzeszutek Wilk, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Jiri Kosina, linux-kernel, Ralf Baechle,
Rob Landley, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
In-Reply-To: <20131017133543.7e4e8d45@gandalf.local.home>
2013-10-17 13:35-0400, Steven Rostedt:
> On Thu, 17 Oct 2013 12:10:28 +0200
> Radim Krčmář <rkrcmar@redhat.com> wrote:
>
> > We implemented the optimized branch selection in higher levels of api.
> > That made static_keys very unintuitive, so this patch introduces another
> > element to jump_table, carrying one bit that tells the underlying code
> > which branch to optimize.
> >
> > It is now possible to select optimized branch for every jump_entry.
> >
> > Current side effect is 1/3 increase increase in space, we could:
> > * use bitmasks and selectors on 2+ aligned code/struct.
> > - aligning jump target is easy, but because it is not done by default
> > and few bytes in .text are much worse that few kilos in .data,
> > I chose not to
> > - data is probably aligned by default on all current architectures,
> > but programmer can force misalignment of static_key
> > * optimize each architecture independently
> > - I can't test everything and this patch shouldn't break anything, so
> > others can contribute in the future
> > * choose something worse, like packing or splitting
> > * ignore
> >
> > proof: example & x86_64 disassembly: (F = ffffffff)
> >
> > struct static_key flexible_feature;
> > noinline void jump_label_experiment(void) {
> > if ( static_key_false(&flexible_feature))
> > asm ("push 0xa1");
> > else asm ("push 0xa0");
> > if (!static_key_false(&flexible_feature))
> > asm ("push 0xb0");
> > else asm ("push 0xb1");
> > if ( static_key_true(&flexible_feature))
> > asm ("push 0xc1");
> > else asm ("push 0xc0");
> > if (!static_key_true(&flexible_feature))
> > asm ("push 0xd0");
> > else asm ("push 0xd1");
> > }
> >
> > Disassembly of section .text: (push marked by "->")
> >
> > F81002000 <jump_label_experiment>:
> > F81002000: e8 7b 29 75 00 callq F81754980 <__fentry__>
> > F81002005: 55 push %rbp
> > F81002006: 48 89 e5 mov %rsp,%rbp
> > F81002009: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F8100200e: -> ff 34 25 a0 00 00 00 pushq 0xa0
> > F81002015: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F8100201a: -> ff 34 25 b0 00 00 00 pushq 0xb0
> > F81002021: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F81002026: -> ff 34 25 c1 00 00 00 pushq 0xc1
> > F8100202d: 0f 1f 00 nopl (%rax)
> > F81002030: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F81002035: -> ff 34 25 d1 00 00 00 pushq 0xd1
> > F8100203c: 5d pop %rbp
> > F8100203d: 0f 1f 00 nopl (%rax)
> > F81002040: c3 retq
>
> This looks exactly like what we want. I take it this is with your
> patch. What was the result before the patch?
Yes, this is after the patch.
The branches would (should) be the same without patch, but
static_key_true() was defined as !static_key_false(), so this piece of
code was invalid before, because half of them would be patched to use
the wrong branch.
> -- Steve
>
> > F81002041: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> > F81002048: -> ff 34 25 d0 00 00 00 pushq 0xd0
> > F8100204f: 5d pop %rbp
> > F81002050: c3 retq
> > F81002051: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> > F81002058: -> ff 34 25 c0 00 00 00 pushq 0xc0
> > F8100205f: 90 nop
> > F81002060: eb cb jmp F8100202d <[...]+0x2d>
> > F81002062: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> > F81002068: -> ff 34 25 b1 00 00 00 pushq 0xb1
> > F8100206f: 90 nop
> > F81002070: eb af jmp F81002021 <[...]+0x21>
> > F81002072: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> > F81002078: -> ff 34 25 a1 00 00 00 pushq 0xa1
> > F8100207f: 90 nop
> > F81002080: eb 93 jmp F81002015 <[...]+0x15>
> > F81002082: 66 66 66 66 66 2e 0f [...]
> > F81002089: 1f 84 00 00 00 00 00
> >
> > Contents of section .data: (relevant part of embedded __jump_table)
^ permalink raw reply
* Re: [PATCH -V2 06/14] kvm: powerpc: booke: Convert BOOKE to use kvmppc_ops callbacks
From: Aneesh Kumar K.V @ 2013-10-18 4:44 UTC (permalink / raw)
To: Alexander Graf
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <01BC643C-0AA9-47E8-A7E9-7A84AB280298@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 07.10.2013, at 18:47, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Make required changes to get BOOKE configs to build with
>> the introduction of kvmppc_ops callback
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> This can not be a separate commit, as you're breaking bisectability for booke this way.
>
The only reason I split that into two was to make review easy. But yes
when merging to your tree we should fold.
> I've squashed this in with the previous commit.
>
Ok.
-aneesh
^ permalink raw reply
* RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Xiubo Li-B47053 @ 2013-10-18 3:42 UTC (permalink / raw)
To: Mark Brown, Lars-Peter Clausen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
Timur Tabi, linux-kernel@vger.kernel.org, Guo Shawn-R65073,
LW@KARO-electronics.de, linux@arm.linux.org.uk,
Chen Guangyu-B42378, oskar@scara.com, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org,
rob.herring@calxeda.com, linux-arm-kernel@lists.infradead.org,
Estevam Fabio-R49496, lgirdwood@gmail.com, rob@landley.net,
Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131017141003.GO2443@sirena.org.uk>
> > > I understand that, but I'm trying to figure out why of_iomap() is
> > > okay for hundreds of other drivers, but not this one. I've used it
> > > dozens of times myself, without ever worrying about overlapping
> regions.
>=20
> > The driver would work fine with just of_iomap(). But the resource
> > range check comes basically for free and it does help to catch errors,
> > so I'd recommend on using it rather than not using it.
>=20
> There's also the fact that it's a devm_ function which means less error
> handling code that we can break which is nice. There's probably a case
> for an improved OF helper here...
Using this instead of of_iomap() is because "devm_" and resource range chec=
k
as Lars and Mark said, and there are more than one SAI device here which wi=
ll
be added later, maybe the resource range check is needed.
Thanks.
--
BRS
Xiubo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox