* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Vladimir Murzin @ 2013-09-11 16:15 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Matt Evans, paulus, netdev, linuxppc-dev, davem
In-Reply-To: <5226DB64.3020207@redhat.com>
On Wed, Sep 04, 2013 at 09:04:04AM +0200, Daniel Borkmann wrote:
> On 09/03/2013 10:52 PM, Daniel Borkmann wrote:
> > On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
> [...]
> >>> Do you have a test case/suite by any chance ?
> >>>
> >>> Ben.
> >>>
> >>
> >> Hi Ben!
> >>
> >> Thanks for your feedback.
> >>
> >> This patch is only compile tested. I have no real hardware, but I'll
> >> probably bring up qemu ppc64 till end of the week...
> >> Meanwhile, I've made simple how-to for testing. You can use it if you wish.
> >> It is mainly based on the [1] and rechecked on x86-64.
Finally I've managed to bring up qemu ppc64 and done simple testing. As a
result I could see difference in opcodes for divide instruction - I've just
sent the patch for that.
WRT mod instruction result is:
For BPF program
(000) ldh [12]
(001) jeq #0x800 jt 2 jf 10
(002) ldh [16]
(003) sub #20
(004) mod #5
(005) jeq #0x0 jt 10 jf 6
(006) ldb [20]
(007) and #0x20
(008) jeq #0x20 jt 9 jf 10
(009) ret #65535
(010) ret #0
The following code is generated (with patch divw to divwu applied)
244 bytes emitted from JIT compiler (pass:3, flen:11)
d0000000015c0018 + <x>:
0: mflr r0
4: std r0,16(r1)
8: std r14,-144(r1)
c: std r15,-136(r1)
10: stdu r1,-288(r1)
14: lwz r7,108(r3)
18: lwz r15,104(r3)
1c: subf r15,r7,r15
20: ld r14,216(r3)
24: lis r7,-16384
28: rldicr r7,r7,32,31
2c: oris r7,r7,9
30: ori r7,r7,43428
34: mtlr r7
38: li r6,12
3c: blrl
40: blt- 0x00000000000000dc
44: nop
48: cmplwi r4,2048
4c: bne- 0x00000000000000d8
50: nop
54: lis r7,-16384
58: rldicr r7,r7,32,31
5c: oris r7,r7,9
60: ori r7,r7,43428
64: mtlr r7
68: li r6,16
6c: blrl
70: blt- 0x00000000000000dc
74: nop
78: addi r4,r4,-20
7c: li r8,5
80: divwu r7,r4,r8
84: mullw r7,r8,r7
88: subf r4,r7,r4
8c: cmplwi r4,0
90: beq- 0x00000000000000d8
94: nop
98: lis r7,-16384
9c: rldicr r7,r7,32,31
a0: oris r7,r7,9
a4: ori r7,r7,43456
a8: mtlr r7
ac: li r6,20
b0: blrl
b4: blt- 0x00000000000000dc
b8: nop
bc: andi. r4,r4,32
c0: cmplwi r4,32
c4: bne- 0x00000000000000d8
c8: nop
cc: li r3,-1
d0: addis r3,r3,1
d4: b 0x00000000000000dc
d8: li r3,0
dc: addi r1,r1,288
e0: ld r0,16(r1)
e4: mtlr r0
e8: ld r14,-144(r1)
ec: ld r15,-136(r1)
f0: blr
Raw codes are
flen=11 proglen=244 pass=3 image=d0000000015c0018
JIT code: 00000000: 7c 08 02 a6 f8 01 00 10 f9 c1 ff 70 f9 e1 ff 78
JIT code: 00000010: f8 21 fe e1 80 e3 00 6c 81 e3 00 68 7d e7 78 50
JIT code: 00000020: e9 c3 00 d8 3c e0 c0 00 78 e7 07 c6 64 e7 00 09
JIT code: 00000030: 60 e7 a9 a4 7c e8 03 a6 38 c0 00 0c 4e 80 00 21
JIT code: 00000040: 41 80 00 9c 60 00 00 00 28 04 08 00 40 82 00 8c
JIT code: 00000050: 60 00 00 00 3c e0 c0 00 78 e7 07 c6 64 e7 00 09
JIT code: 00000060: 60 e7 a9 a4 7c e8 03 a6 38 c0 00 10 4e 80 00 21
JIT code: 00000070: 41 80 00 6c 60 00 00 00 38 84 ff ec 39 00 00 05
JIT code: 00000080: 7c e4 43 96 7c e8 39 d6 7c 87 20 50 28 04 00 00
JIT code: 00000090: 41 82 00 48 60 00 00 00 3c e0 c0 00 78 e7 07 c6
JIT code: 000000a0: 64 e7 00 09 60 e7 a9 c0 7c e8 03 a6 38 c0 00 14
JIT code: 000000b0: 4e 80 00 21 41 80 00 28 60 00 00 00 70 84 00 20
JIT code: 000000c0: 28 04 00 20 40 82 00 14 60 00 00 00 38 60 ff ff
JIT code: 000000d0: 3c 63 00 01 48 00 00 08 38 60 00 00 38 21 01 20
JIT code: 000000e0: e8 01 00 10 7c 08 03 a6 e9 c1 ff 70 e9 e1 ff 78
JIT code: 000000f0: 4e 80 00 20
Ben,
How do you feel about it?
> >
> > Please also cc netdev on BPF related changes.
> >
> > Actually, your test plan can be further simplified ...
> >
> > For retrieving and disassembling the JIT image, we have bpf_jit_disasm [1].
> >
> > 1) echo 2 > /proc/sys/net/core/bpf_jit_enable
> > 2) ... attach filter ...
> > 3) bpf_jit_disasm -o
> >
> > For generating a simple stupid test filter, you can use bpfc [2] (also
> > see its man page). E.g. ...
> >
> > # cat blub
> > ldi #10
> > mod #8
> > ret a
> > # bpfc blub
> > { 0x0, 0, 0, 0x0000000a },
> > { 0x94, 0, 0, 0x00000008 },
> > { 0x16, 0, 0, 0x00000000 },
>
> Plus something like ...
>
> ldxi #0
> mod x
> ret a
>
Thanks Daniel!
Unfortunately, I couldn't trigger JIT compiler with the pair bpfc/netsniff-ng
(even for x86-64). I guess I missed something. I'd be very grateful if you
point at my mistakes.
> For longer-term testing, also trinity has BPF support. ;)
>
Wow! Could do give some hint how to run this for BPF only?
> > And load this array e.g. either into a small C program that attaches this
> > as BPF filter, or simply do bpfc blub > blub2 and run netsniff-ng -f blub2\
> > -s -i eth0, that should also do it.
> >
> > Then, when attached, the kernel should truncate incoming frames for pf_packet
> > into max length of 2, just as an example.
> >
> > [1] kernel tree, tools/net/bpf_jit_disasm.c
> > [2] git clone git://github.com/borkmann/netsniff-ng.git
Thanks
Vladimir
^ permalink raw reply
* Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Scott Wood @ 2013-09-11 16:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stephen Chivers, paulus, linuxppc-dev, cproctor
In-Reply-To: <1378862123.3783.5.camel@pasglop>
On Wed, 2013-09-11 at 11:15 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-09-10 at 18:47 -0500, Scott Wood wrote:
>
> > No blank line before }
> >
> > > +CONFIG_CMDLINE_BOOL=y
> > > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
> >
> > I take it there's no way to pass a command line in from whatever loader
> > this board uses... but you could put it in the dts instead.
>
> No, please don't put that in the device-tree. Somebody might want
> different settings, this is typically what .config is for.
I figured that in the defconfig it presents a barrier to getting rid of
the board-specific defconfig, while the dts is still going to be
per-board. In this case the device tree is not baked into firmware so
it's just as easy to change things in /chosen as in .config (actually
slightly easier since you only need to rewrap the kernel rather than
rebuild).
-Scott
^ permalink raw reply
* [PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless
From: Christophe Leroy @ 2013-09-11 15:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
The commit e0908085fc2391c85b85fb814ae1df377c8e0dcb is not needed anymore.
The issue was because dcbst wrongly sets the store bit when causing a DTLB
error, but this is now fixed by commit 0a2ab51ffb8dfdf51402dcfb446629648c96bc78
which handles the buggy dcbx instructions on data page faults on the 8xx.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur linux-3.11.org/arch/powerpc/mm/pgtable.c linux-3.11/arch/powerpc/mm/pgtable.c
--- linux-3.11.org/arch/powerpc/mm/pgtable.c 2013-09-02 22:46:10.000000000 +0200
+++ linux-3.11/arch/powerpc/mm/pgtable.c 2013-09-09 11:25:57.000000000 +0200
@@ -32,8 +32,6 @@
#include <asm/tlbflush.h>
#include <asm/tlb.h>
-#include "mmu_decl.h"
-
static inline int is_exec_fault(void)
{
return current->thread.regs && TRAP(current->thread.regs) == 0x400;
@@ -72,7 +70,7 @@
* support falls into the same category.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
@@ -81,17 +79,6 @@
if (!pg)
return pte;
if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -111,7 +98,7 @@
* as we don't have two bits to spare for _PAGE_EXEC and _PAGE_HWEXEC so
* instead we "filter out" the exec permission for non clean pages.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
struct page *pg;
@@ -193,7 +180,7 @@
* this context might not have been activated yet when this
* is called.
*/
- pte = set_pte_filter(pte, addr);
+ pte = set_pte_filter(pte);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
Only in linux-3.11/arch/powerpc/mm/: pgtable.c.orig
^ permalink raw reply
* [PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless
From: Christophe Leroy @ 2013-09-11 16:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
The commit e0908085fc2391c85b85fb814ae1df377c8e0dcb is not needed anymore.
The issue was because dcbst wrongly sets the store bit when causing a DTLB
error, but this is now fixed by commit 0a2ab51ffb8dfdf51402dcfb446629648c96bc78
which handles the buggy dcbx instructions on data page faults on the 8xx.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur linux-3.11.org/arch/powerpc/mm/pgtable.c linux-3.11/arch/powerpc/mm/pgtable.c
--- linux-3.11.org/arch/powerpc/mm/pgtable.c 2013-09-02 22:46:10.000000000 +0200
+++ linux-3.11/arch/powerpc/mm/pgtable.c 2013-09-09 11:25:57.000000000 +0200
@@ -32,8 +32,6 @@
#include <asm/tlbflush.h>
#include <asm/tlb.h>
-#include "mmu_decl.h"
-
static inline int is_exec_fault(void)
{
return current->thread.regs && TRAP(current->thread.regs) == 0x400;
@@ -72,7 +70,7 @@
* support falls into the same category.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
@@ -81,17 +79,6 @@
if (!pg)
return pte;
if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -111,7 +98,7 @@
* as we don't have two bits to spare for _PAGE_EXEC and _PAGE_HWEXEC so
* instead we "filter out" the exec permission for non clean pages.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
struct page *pg;
@@ -193,7 +180,7 @@
* this context might not have been activated yet when this
* is called.
*/
- pte = set_pte_filter(pte, addr);
+ pte = set_pte_filter(pte);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
Only in linux-3.11/arch/powerpc/mm/: pgtable.c.orig
^ permalink raw reply
* [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: Christophe Leroy @ 2013-09-11 16:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three
8Mbytes pages. But the setting of the MD_CTR was missing so as the index is
decremented every DTLB update, the pinning of the third 8Mbytes page was
overwriting the DTLB entry for IMMR.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S
--- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.000000000 +0200
+++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.000000000 +0200
@@ -862,6 +862,9 @@
addis r11, r11, 0x0080 /* Add 8M */
mtspr SPRN_MD_RPN, r11
+ addi r10, r10, 0x0100
+ mtspr SPRN_MD_CTR, r10
+
addis r8, r8, 0x0080 /* Add 8M */
mtspr SPRN_MD_EPN, r8
mtspr SPRN_MD_TWC, r9
^ permalink raw reply
* Re: [PATCH V3 1/6] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)
From: Geoff Levand @ 2013-09-11 16:49 UTC (permalink / raw)
To: Preeti U Murthy
Cc: paul.gortmaker, paulus, shangw, rjw, fweisbec, paulmck, arnd,
linux-pm, rostedt, john.stultz, tglx, chenhui.zhao, deepthi,
r58472, linux-kernel, srivatsa.bhat, schwidefsky, linuxppc-dev
In-Reply-To: <20130911025100.27726.95866.stgit@preeti.in.ibm.com>
On Wed, 2013-09-11 at 08:21 +0530, Preeti U Murthy wrote:
> arch/powerpc/platforms/ps3/smp.c | 2 +-
The PS3 part is trivial and looks OK.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH V3 2/6] powerpc: Implement broadcast timer interrupt as an IPI message
From: Geoff Levand @ 2013-09-11 16:50 UTC (permalink / raw)
To: Preeti U Murthy
Cc: paul.gortmaker, paulus, shangw, rjw, fweisbec, paulmck, arnd,
linux-pm, rostedt, john.stultz, tglx, chenhui.zhao, deepthi,
r58472, linux-kernel, srivatsa.bhat, schwidefsky, linuxppc-dev
In-Reply-To: <20130911025122.27726.84259.stgit@preeti.in.ibm.com>
On Wed, 2013-09-11 at 08:21 +0530, Preeti U Murthy wrote:
> arch/powerpc/platforms/ps3/smp.c | 2 +-
The PS3 part is trivial and looks OK.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: PPC: set default date on PPC without RTC
From: Wladislav Wiebe @ 2013-09-11 17:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <52303A6A.2050702@gmail.com>
Hi,
no matter anymore - got it:
--- a/linux/arch/powerpc/kernel/time.c
+++ b/linux/arch/powerpc/kernel/time.c
@@ -832,7 +832,7 @@ static void __read_persistent_clock(struct timespec *ts)
}
}
if (!ppc_md.get_rtc_time) {
- ts->tv_sec = 0;
+ ts->tv_sec = mktime(2011, 1, 1, 0, 0, 0);
return;
}
ppc_md.get_rtc_time(&tm);
On 11/09/13 11:39, Wladislav Wiebe wrote:
> Hello guys,
>
> would like to ask if there is a proper possibility on PPC to
> set default date (basically the year). The board has no RTC chip,
> and I would need instead of 1970 another year.
>
> For some reason does e.g:
> --- a/linux/arch/powerpc/kernel/time.c
> +++ b/linux/arch/powerpc/kernel/time.c
> @@ -1099,7 +1099,7 @@ void __init time_init(void)
>
>
> #define FEBRUARY 2
> -#define STARTOFTIME 1970
> +#define STARTOFTIME 2013
> #define SECDAY 86400L
> #define SECYR (SECDAY * 365)
> #define leapyear(year) ((year) % 4 == 0 && \
>
>
> not work to me. Is there also another place which should be changed?
> (I know it can be changed from userspace also, but I would need it before userspace)
>
>
> Thanks and BR,
> Wladislav Wiebe
>
^ permalink raw reply
* RE: [PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers
From: Luck, Tony @ 2013-09-11 18:34 UTC (permalink / raw)
To: Aruna Balakrishnaiah, linuxppc-dev@ozlabs.org,
seiji.aguchi@hds.com, linux-kernel@vger.kernel.org,
keescook@chromium.org
Cc: jkenisto@linux.vnet.ibm.com, mahesh@linux.vnet.ibm.com,
ccross@android.com, cbouatmailru@gmail.com
In-Reply-To: <20130911120639.27730.8671.stgit@aruna-ThinkPad-T420>
LQliaWdfb29wc19idWZfc3ogPSAocHNpbmZvLT5idWZzaXplICogMTAwKSAvIDQ1Ow0KKwliaWdf
b29wc19idWZfc3ogPSAocHNpbmZvLT5idWZzaXplICogMTAwKSAvIGNtcHI7DQoNClRlc3RlZCBv
biBhbiBFUlNUIGJhY2tlZCBzeXN0ZW0uICBTZWVtcyB0byBiZSB3b3JraW5nICh3ZSBzYXZlIGEg
bGl0dGxlIGxlc3MgaW5mb3JtYXRpb24NCnBlciBFUlNUIHJlY29yZCB0aGFuIGJlZm9yZSB0aGlz
IGNoYW5nZSAodW5jb21wcmVzc2VkIHNpemUgZ29lcyBkb3duIGZyb20gfjE3NTAwIHRvDQp+MTY0
MDAgYnl0ZXMpIC0gYnV0IHRoaXMgcGF0Y2ggc3dpdGNoZWQgdGhlIGRlbm9taW5hdG9yIGZyb20g
NDUgdG8gNDggKGZvciBFUlNUKSAtIHNvIHRoYXQNCnNlZW1zIHBsYXVzaWJsZS4NCg0KU2Vpamk6
IGxldCBtZSBrbm93IGhvdyB0aGUgZWZpdmFycyB0ZXN0cyBnby4NCg0KLVRvbnkNCg==
^ permalink raw reply
* RE: [PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers
From: Seiji Aguchi @ 2013-09-11 18:57 UTC (permalink / raw)
To: Luck, Tony, Aruna Balakrishnaiah, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
Cc: jkenisto@linux.vnet.ibm.com, mahesh@linux.vnet.ibm.com,
ccross@android.com, cbouatmailru@gmail.com
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F31CF4C85@ORSMSX106.amr.corp.intel.com>
PisJLyogYnVmZmVyIHJhbmdlIGZvciBlZml2YXJzICovDQo+KwljYXNlIDEwMDAgLi4uIDIwMDA6
DQo+KwkJY21wciA9IDU2Ow0KPisJCWJyZWFrOw0KDQo+IFNlaWppOiBsZXQgbWUga25vdyBob3cg
dGhlIGVmaXZhcnMgdGVzdHMgZ28uDQoNCmVmaXZhcnMgd29ya3MgZmluZS4NClVuY29tcHJlc3Nl
ZCBzaXplIGFib3V0IDE4MDAgYnl0ZXMuIEl0IG1hdGNoZXMgdGhlIHZhbHVlIG9mIGNtcHIsIDU2
LiANCg0KUGxlYXNlIGZlZWwgZnJlZSB0byBhZGQgbXkgIlRlc3RlZC1ieSIgdG8gYWxsIHRocmVl
IHBhdGNoZXMuDQoNClRlc3RlZC1ieTogU2VpamkgQWd1Y2hpIDxzZWlqaS5hZ3VjaGlAaGRzLmNv
bT4NCg0K
^ permalink raw reply
* Re: [RFC PATCH v2 15/25] smp, ppc: kill SMP single function call interrupt
From: Srivatsa S. Bhat @ 2013-09-11 20:03 UTC (permalink / raw)
To: Jiang Liu
Cc: linux-arch, Deepthi Dharwar, Paul E. McKenney, Jiri Kosina,
Peter Zijlstra, linuxppc-dev, Wang YanQing, Steven Rostedt,
linux-kernel, Paul Mackerras, Preeti U Murthy, Andrew Morton,
Shaohua Li, Ingo Molnar, Jiang Liu
In-Reply-To: <1378915649-16395-16-git-send-email-liuj97@gmail.com>
On 09/11/2013 09:37 PM, Jiang Liu wrote:
> From: Jiang Liu <jiang.liu@huawei.com>
>
> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" has unified the way to handle
> single and multiple cross-CPU function calls. Now only one interrupt
> is needed for architecture specific code to support generic SMP function
> call interfaces, so kill the redundant single function call interrupt.
>
> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> Cc: Jiang Liu <liuj97@gmail.com>
> ---
It turns out that freeing up the IPI slot in powerpc is very useful, since
we actually wanted a slot for some other use-case (and there are only 4 slots
available on powerpc).
Here are the patches which achieve that:
http://marc.info/?l=linuxppc-embedded&m=137886807502898&w=2
http://marc.info/?l=linuxppc-embedded&m=137886811502909&w=2
So, can you kindly consider dropping the powerpc patch from your series,
if that is OK with you? Thanks!
BTW, after doing the powerpc cleanup, even I had thought about killing one
of the smp-function variants in various architectures, but never got around
to do it. But now that you have posted the series which does that, I'll try
to review them.
Thank you!
Regards,
Srivatsa S. Bhat
> arch/powerpc/include/asm/smp.h | 3 +--
> arch/powerpc/kernel/smp.c | 12 +-----------
> 2 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index 48cfc85..53faa03 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -119,8 +119,7 @@ extern int cpu_to_core_id(int cpu);
> * in /proc/interrupts will be wrong!!! --Troy */
> #define PPC_MSG_CALL_FUNCTION 0
> #define PPC_MSG_RESCHEDULE 1
> -#define PPC_MSG_CALL_FUNC_SINGLE 2
> -#define PPC_MSG_DEBUGGER_BREAK 3
> +#define PPC_MSG_DEBUGGER_BREAK 2
>
> /* for irq controllers that have dedicated ipis per message (4) */
> extern int smp_request_message_ipi(int virq, int message);
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 38b0ba6..0c53b10 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -123,12 +123,6 @@ static irqreturn_t reschedule_action(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static irqreturn_t call_function_single_action(int irq, void *data)
> -{
> - generic_smp_call_function_single_interrupt();
> - return IRQ_HANDLED;
> -}
> -
> static irqreturn_t debug_ipi_action(int irq, void *data)
> {
> if (crash_ipi_function_ptr) {
> @@ -146,14 +140,12 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
> static irq_handler_t smp_ipi_action[] = {
> [PPC_MSG_CALL_FUNCTION] = call_function_action,
> [PPC_MSG_RESCHEDULE] = reschedule_action,
> - [PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
> [PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
> };
>
> const char *smp_ipi_name[] = {
> [PPC_MSG_CALL_FUNCTION] = "ipi call function",
> [PPC_MSG_RESCHEDULE] = "ipi reschedule",
> - [PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
> [PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
> };
>
> @@ -225,8 +217,6 @@ irqreturn_t smp_ipi_demux(void)
> generic_smp_call_function_interrupt();
> if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
> scheduler_ipi();
> - if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
> - generic_smp_call_function_single_interrupt();
> if (all & (1 << (24 - 8 * PPC_MSG_DEBUGGER_BREAK)))
> debug_ipi_action(0, NULL);
> #else
> @@ -257,7 +247,7 @@ EXPORT_SYMBOL_GPL(smp_send_reschedule);
>
> void arch_send_call_function_single_ipi(int cpu)
> {
> - do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
> + do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
> }
>
> void arch_send_call_function_ipi_mask(const struct cpumask *mask)
>
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-09-11 22:36 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <201309111644.r8BGiuDZ016325@localhost.localdomain>
On Wed, 2013-09-11 at 18:44 +0200, Christophe Leroy wrote:
> Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three
> 8Mbytes pages. But the setting of the MD_CTR was missing so as the index is
> decremented every DTLB update, the pinning of the third 8Mbytes page was
> overwriting the DTLB entry for IMMR.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S
> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.000000000 +0200
> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.000000000 +0200
> @@ -862,6 +862,9 @@
> addis r11, r11, 0x0080 /* Add 8M */
> mtspr SPRN_MD_RPN, r11
>
> + addi r10, r10, 0x0100
> + mtspr SPRN_MD_CTR, r10
> +
> addis r8, r8, 0x0080 /* Add 8M */
> mtspr SPRN_MD_EPN, r8
> mtspr SPRN_MD_TWC, r9
I wonder why we don't start from entry 31 so we can actually make use of
that autodecrement. What will happen when we load the first normal TLB
entry later on? I don't see any setting of SPRN_MD_CTR after this code,
so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB
case?
Ben, would patches like this be considered bugfixes as far as merging
goes, or would they be for next given that it's something that's never
really worked right and hasn't been touched in years?
-Scott
^ permalink raw reply
* Re: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
From: Scott Wood @ 2013-09-11 22:42 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev
In-Reply-To: <1378879004-2446-2-git-send-email-dongsheng.wang@freescale.com>
On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Each core's AltiVec unit may be placed into a power savings mode
> by turning off power to the unit. Core hardware will automatically
> power down the AltiVec unit after no AltiVec instructions have
> executed in N cycles. The AltiVec power-control is triggered by hardware.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> *v3:
> Assembly code instead of C code.
>
> *v2:
> Remove:
> delete setup_idle_hw_governor function.
> delete "Fix erratum" for rev1.
>
> Move:
> move setup_* into __setup/restore_cpu_e6500.
>
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index bfb18c7..3c03c109 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup)
> isync
> blr
>
> +/*
> + * FIXME - We don't know the AltiVec application scenarios.
> + */
> +#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */
> +_GLOBAL(setup_altivec_idle)
> + mfspr r3, SPRN_PWRMGTCR0
> +
> + /* Enable Altivec Idle */
> + oris r3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h
> + li r4, AV_WAIT_IDLE_BIT
> +
> + /* Set Automatic AltiVec Idle Count */
> + rlwimi r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT
> +
> + mtspr SPRN_PWRMGTCR0, r3
> +
> + blr
The FIXME comment is not clear. If you mean that we haven't yet done
testing to determine a reasonable default value for AV_WAIT_IDLE_BIT,
then just say that. Likewise with the FIXME comment in the pw20 patch
-- the uncertainty is due to a lack of investigation, not "because we
don't know the current state of the cpu load".
While some workloads may want a different value than whatever default we
set, that's what the sysfs interface is for. The only thing missing
here is benchmarking to determine a good overall default.
-Scott
^ permalink raw reply
* Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-09-11 23:04 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev
In-Reply-To: <1378879004-2446-4-git-send-email-dongsheng.wang@freescale.com>
On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> 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 entry bit interface:
> bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
I'm no fan of the way powerpc does bit numbering, but don't flip it
around here -- you'll just cause confusion.
Better yet, this interface should take real time units rather than a
timebase bit.
Also, you disable the power saving mode if the maximum interval is
selected, but the documentation doesn't say that -- and the
documentation should be in the code (or other easily findable place),
not just in the commit message.
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 7389d49..7395d79 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
> isync
> blr
>
> +_GLOBAL(has_pw20_altivec_idle)
> + /* 0 false, 1 true */
> + li r3, 0
> +
> + /* PW20 & AltiVec idle feature only exists for E6500 */
> + mfspr r0, SPRN_PVR
> + rlwinm r4, r0, 16, 16, 31
> + lis r12, 0
> + ori r12, r12, PVR_VER_E6500@l
> + cmpw r4, r12
> + bne 2f
> + li r3, 1
> +2:
> + blr
Why is this in asm? And shouldn't this go in the cputable somehow?
> +static void query_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, query_pwrmgtcr0, &value, 1);
> +
> + value &= PWRMGTCR0_PW20_WAIT;
> +
> + return sprintf(buf, "%u\n", value ? 1 : 0);
> +}
> +
> +static void control_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)
The difference between query/show and control/store is a bit awkward...
I'd s/query/do_show/ and s/control/do_store/ (or local_ or other
appropriate prefix).
> +static ssize_t show_altivec_idle_wait_entry_bit(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u32 value;
> + unsigned int cpu = dev->id;
> +
> + smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> +
> + value = MAX_BIT - ((value & PWRMGTCR0_AV_IDLE_CNT) >>
> + PWRMGTCR0_AV_IDLE_CNT_SHIFT);
> +
> + return sprintf(buf, "wait entry bit is %u\n", value);
> +}
Reading a sysfs value should just return the value, not a human-readable
string.
> +static DEVICE_ATTR(pw20_state, 0644, show_pw20_state, store_pw20_state);
> +static DEVICE_ATTR(pw20_wait_entry_bit, 0644, show_pw20_wait_entry_bit,
> + store_pw20_wait_entry_bit);
> +
> +static DEVICE_ATTR(altivec_idle, 0644, show_altivec_idle, store_altivec_idle);
> +static DEVICE_ATTR(altivec_idle_wait_entry_bit, 0644,
> + show_altivec_idle_wait_entry_bit,
> + store_altivec_idle_wait_entry_bit);
I'd make these 0600, given their ability to spam other CPUs with IPIs
even on read.
> +static int __init create_pw20_altivec_sysfs(void)
> +{
> + int i;
> + struct device *cpu_dev;
> +
> + if (!has_pw20_altivec_idle())
> + return -ENODEV;
> +
> + for_each_possible_cpu(i) {
> + cpu_dev = get_cpu_device(i);
> + device_create_file(cpu_dev, &dev_attr_pw20_state);
> + device_create_file(cpu_dev, &dev_attr_pw20_wait_entry_bit);
> +
> + device_create_file(cpu_dev, &dev_attr_altivec_idle);
> + device_create_file(cpu_dev,
> + &dev_attr_altivec_idle_wait_entry_bit);
> + }
> +
> + return 0;
> +}
> +device_initcall(create_pw20_altivec_sysfs);
I think I said this earlier, but it'd be nice to have a "late cpu setup"
cputable callback -- but failing that, this should be called from
register_cpu_online() which is where other CPU sysfs attributes are
created.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
From: Scott Wood @ 2013-09-11 23:24 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Varun Sethi, Poonam Aggrwal, linuxppc-dev, Priyanka Jain
In-Reply-To: <1378882686-19454-1-git-send-email-prabhakar@freescale.com>
On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote:
> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
> processor cores with high-performance data path acceleration architecture
> and network peripheral interfaces required for networking & telecommunications.
>
> T1042 personality is a reduced personality of T1040 without Integrated 8-port
> Gigabit Ethernet switch.
>
> The T1040/T1042 SoC includes the following function and features:
>
> - Four e5500 cores, each with a private 256 KB L2 cache
> - 256 KB shared L3 CoreNet platform cache (CPC)
> - Interconnect CoreNet platform
> - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
> support
> - Data Path Acceleration Architecture (DPAA) incorporating acceleration
> for the following functions:
> - Packet parsing, classification, and distribution
> - Queue management for scheduling, packet sequencing, and congestion
> management
> - Cryptography Acceleration (SEC 5.0)
> - RegEx Pattern Matching Acceleration (PME 2.2)
> - IEEE Std 1588 support
> - Hardware buffer management for buffer allocation and deallocation
> - Ethernet interfaces
> - Integrated 8-port Gigabit Ethernet switch (T1040 only)
> - Four 1 Gbps Ethernet controllers
> - Two RGMII interfaces or one RGMII and one MII interfaces
> - High speed peripheral interfaces
> - Four PCI Express 2.0 controllers running at up to 5 GHz
> - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
> - Upto two QSGMII interface
> - Upto six SGMII interface supporting 1000 Mbps
> - One SGMII interface supporting upto 2500 Mbps
> - Additional peripheral interfaces
> - Two USB 2.0 controllers with integrated PHY
> - SD/eSDHC/eMMC
> - eSPI controller
> - Four I2C controllers
> - Four UARTs
> - Four GPIO controllers
> - Integrated flash controller (IFC)
> - Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate
> - TDM interface
> - Multicore programmable interrupt controller (PIC)
> - Two 8-channel DMA engines
> - Single source clocking implementation
> - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Everything in there has already been pulled by Linus, so there's no
reason to use that tree as a base right now.
> +/include/ "t1042si-post.dtsi"
[snip]
> + serdes: serdes@ea000 {
> + compatible = "fsl,t1040-serdes";
> + reg = <0xea000 0x4000>;
> + };
> +
> + sdhc@114000 {
> + compatible = "fsl,t1040-esdhc", "fsl,esdhc";
> + sdhci,auto-cmd12;
> + };
Why does sdhci,auto-cmd12 need to be specified here? It's already in
t1042si-post.dtsi which you've included. Likewise with reg on the
serdes node.
I also question the need to define separate t1040 compatible values for
all of these, if the only difference is whether the onboard switch is
enabled or not.
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,t1042-clockgen", "fsl,qoriq-clockgen-2.0",
> + "fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-names = "sysclk";
> + #clock-cells = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pll0: pll0@800 {
> + #clock-cells = <1>;
> + reg = <0x800>;
> + compatible = "fsl,core-pll-clock";
> + clocks = <&clockgen>;
> + clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> + };
> + pll1: pll1@820 {
> + #clock-cells = <1>;
> + reg = <0x820>;
> + compatible = "fsl,core-pll-clock";
> + clocks = <&clockgen>;
> + clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> + };
> + mux0: mux0@0 {
> + #clock-cells = <0>;
> + reg = <0x0>;
> + compatible = "fsl,core-mux-clock";
Please update the clock stuff based on
http://patchwork.ozlabs.org/patch/274134/
> +/include/ "qoriq-dma-0.dtsi"
> + dma@100300 {
> + fsl,iommu-parent = <&pamu0>;
> + fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
> + };
> +
> +/include/ "qoriq-dma-1.dtsi"
> + dma@101300 {
> + fsl,iommu-parent = <&pamu0>;
> + fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
> + };
These are elo3:
http://patchwork.ozlabs.org/patch/271238/
> + display@180000 {
> + compatible = "fsl,diu", "fsl,t1042-diu";
> + reg = <0x180000 1000>;
> + interrupts = <74 2 0 0>;
> + };
More specific compatibles come first.
-Scott
^ permalink raw reply
* [PATCH] powerpc/b4qds: enable coreint
From: Scott Wood @ 2013-09-11 23:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Shaveta Leekha, Kevin Hao
Commit 9837b43c5f3514e5d28f65f1513f4dc6759d2810 ("powerpc/85xx: enable
coreint for all the 64bit boards") removed the ifdef that avoided
coreint on 64-bit, but it missed b4_qds.c.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Kevin Hao <haokexin@gmail.com>
Cc: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/platforms/85xx/b4_qds.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/b4_qds.c b/arch/powerpc/platforms/85xx/b4_qds.c
index 0c6702f..0f18663 100644
--- a/arch/powerpc/platforms/85xx/b4_qds.c
+++ b/arch/powerpc/platforms/85xx/b4_qds.c
@@ -79,12 +79,7 @@ define_machine(b4_qds) {
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#endif
-/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
-#ifdef CONFIG_PPC64
- .get_irq = mpic_get_irq,
-#else
.get_irq = mpic_get_coreint_irq,
-#endif
.restart = fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Scott Wood @ 2013-09-11 23:41 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Priyanka Jain, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <1378882706-19488-1-git-send-email-prabhakar@freescale.com>
On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote:
> Add support for T104x board in board file t104x_qds.c, It is common fo=
r
> both T1040 and T1042 as they share same QDS board.
>=20
> T1040QDS board Overview
> -----------------------
> - SERDES Connections, 8 lanes supporting:
> =E2=80=94 PCI Express: supporting Gen 1 and Gen 2;
> =E2=80=94 SGMII
> =E2=80=94 QSGMII
> =E2=80=94 SATA 2.0
> =E2=80=94 Aurora debug with dedicated connectors (T1040 only)
> - DDR Controller
> - Supports rates of up to 1600 MHz data-rate
> - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank=
types.
> -IFC/Local Bus
> - NAND flash: 8-bit, async, up to 2GB.
> - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
> - GASIC: Simple (minimal) target within Qixis FPGA
> - PromJET rapid memory download support
> - Ethernet
> - Two on-board RGMII 10/100/1G ethernet ports.
> - PHY #0 remains powered up during deep-sleep (T1040 only)
> - QIXIS System Logic FPGA
> - Clocks
> - System and DDR clock (SYSCLK, =E2=80=9CDDRCLK=E2=80=9D)
> - SERDES clocks
> - Power Supplies
> - Video
> - DIU supports video at up to 1280x1024x32bpp
> - USB
> - Supports two USB 2.0 ports with integrated PHYs
> =E2=80=94 Two type A ports with 5V@1.5A per port.
> =E2=80=94 Second port can be converted to OTG mini-AB
> - SDHC
> - SDHC port connects directly to an adapter card slot, featuring:
> - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
> =E2=80=94 Supporting eMMC memory devices
> - SPI
> - On-board support of 3 different devices and sizes
> - Other IO
> - Two Serial ports
> - ProfiBus port
> - Four I2C ports
>=20
> Add T104xQDS support in Kconfig and Makefile. Also create device tree.
>=20
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linu=
x.git
>=20
> TODO: Add noded for ethernet and board stuff
"board stuff"?
Isn't "board stuff" the whole point of this patch? :-)
> arch/powerpc/boot/dts/t1040qds.dts | 201 +++++++++++++++++++++++=
++++++++
> arch/powerpc/boot/dts/t1042qds.dts | 201 +++++++++++++++++++++++=
++++++++
> arch/powerpc/platforms/85xx/Kconfig | 20 +++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/t104x_qds.c | 102 ++++++++++++++++
> 5 files changed, 525 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
> create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
> create mode 100644 arch/powerpc/platforms/85xx/t104x_qds.c
>=20
> diff --git a/arch/powerpc/boot/dts/t1040qds.dts b/arch/powerpc/boot/dts=
/t1040qds.dts
> new file mode 100644
> index 0000000..cea5632
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/t1040qds.dts
> @@ -0,0 +1,201 @@
> +/*
> + * T1040QDS Device Tree Source
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + * * Redistributions of source code must retain the above copyrigh=
t
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyr=
ight
> + * notice, this list of conditions and the following disclaimer in th=
e
> + * documentation and/or other materials provided with the distributio=
n.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote produc=
ts
> + * derived from this software without specific prior written permissi=
on.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free Softwar=
e
> + * Foundation, either version 2 of that License or (at your option) an=
y
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND AN=
Y
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE I=
MPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR=
ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CA=
USED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE U=
SE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "fsl/t104xsi-pre.dtsi"
> +
> +/ {
> + model =3D "fsl,T1040QDS";
> + compatible =3D "fsl,T1040QDS";
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + interrupt-parent =3D <&mpic>;
> +
> + aliases {
> + /* TODO */
> + };
TODO? Did you mean this patch as an RFC?
Also, whitespace.
> + i2c@118000 {
> + pca9547@77 {
> + compatible =3D "philips,pca9547";
> + reg =3D <0x77>;
> + };
> + rtc@68 {
> + compatible =3D "dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D <0x1 0x1 0 0>;
> + };
> + };
> +
> + };
Whitespace
> +
> + pci0: pcie@ffe240000 {
> + reg =3D <0xf 0xfe240000 0 0x10000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x10000000
> + 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x10000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + pci1: pcie@ffe250000 {
> + reg =3D <0xf 0xfe250000 0 0x10000>;
> + ranges =3D <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x10000000
> + 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x10000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + pci2: pcie@ffe260000 {
> + reg =3D <0xf 0xfe260000 0 0x1000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x10000000
> + 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x10000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + pci3: pcie@ffe270000 {
> + reg =3D <0xf 0xfe270000 0 0x10000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x60000000 0 0x10000000
> + 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x10000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +};
Maybe some of this stuff could be put in a common dtsi between t1040 and
t1042?
Ideally for t1042 you'd just take the entire t1040 tree as an include,
and add the switch
> diff --git a/arch/powerpc/platforms/85xx/t104x_qds.c b/arch/powerpc/pla=
tforms/85xx/t104x_qds.c
> new file mode 100644
> index 0000000..d28da14
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/t104x_qds.c
> @@ -0,0 +1,102 @@
> +/*
> + * T104x QDS Setup
> + * Should apply for QDS platform of T1040 and it's personalities.
> + * viz T1040/T1042
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or modif=
y it
> + * under the terms of the GNU General Public License as published by=
the
> + * Free Software Foundation; either version 2 of the License, or (at=
your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/phy.h>
> +
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <linux/of_platform.h>
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include <asm/ehv_pic.h>
> +
> +#include "corenet_ds.h"
You don't need all of these includes.
> +define_machine(t104x_qds) {
> + .name =3D "T104x QDS",
> + .probe =3D t104x_qds_probe,
Should we have two machine descriptions, so that the proper chip name
shows up (e.g. in /proc/cpuinfo)?
> +/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
> +#ifdef CONFIG_PPC64
> + .get_irq =3D mpic_get_irq,
> +#else
> + .get_irq =3D mpic_get_coreint_irq,
> +#endif
This isn't true any more. When submitting code that was copied from
elsewhere, please check whether there were any updates in the code that
you copied from (unless you copied from b4qds, which the update missed
-- I just sent a patch to fix that).
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: Benjamin Herrenschmidt @ 2013-09-12 0:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Christophe Leroy, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1378939017.12204.409.camel@snotra.buserror.net>
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
> I wonder why we don't start from entry 31 so we can actually make use of
> that autodecrement. What will happen when we load the first normal TLB
> entry later on? I don't see any setting of SPRN_MD_CTR after this code,
> so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB
> case?
>
> Ben, would patches like this be considered bugfixes as far as merging
> goes, or would they be for next given that it's something that's never
> really worked right and hasn't been touched in years?
Since they don't affect anything outside of 8xx, I'm happy to take them
until around -rc2 or 3. But it's your call really.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: net: filter: fix DIVWU instruction opcode
From: Michael Neuling @ 2013-09-12 0:32 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: linuxppc-dev, matt, paulus
In-Reply-To: <1378915410-2262-1-git-send-email-murzin.v@gmail.com>
Vladimir Murzin <murzin.v@gmail.com> wrote:
> Currently DIVWU stands for *signed* divw opcode:
>
> 7d 2a 4b 96 divwu r9,r10,r9
> 7d 2a 4b d6 divw r9,r10,r9
>
> Use the *unsigned* divw opcode for DIVWU.
This looks like it's in only used in the BPF JIT code.
Matt, any chance you an ACK/NACK this?
Mikey
>
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index d7fe9f5..c91842c 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -218,7 +218,7 @@
> #define PPC_INST_MULLW 0x7c0001d6
> #define PPC_INST_MULHWU 0x7c000016
> #define PPC_INST_MULLI 0x1c000000
> -#define PPC_INST_DIVWU 0x7c0003d6
> +#define PPC_INST_DIVWU 0x7c000396
> #define PPC_INST_RLWINM 0x54000000
> #define PPC_INST_RLDICR 0x78000004
> #define PPC_INST_SLW 0x7c000030
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH] powerpc: net: filter: fix DIVWU instruction opcode
From: Matt Evans @ 2013-09-12 0:58 UTC (permalink / raw)
To: Michael Neuling
Cc: Vladimir Murzin, linuxppc-dev@lists.ozlabs.org, paulus@samba.org
In-Reply-To: <7012.1378945979@ale.ozlabs.ibm.com>
On 12 Sep 2013, at 10:02, Michael Neuling <mikey@neuling.org> wrote:
> Vladimir Murzin <murzin.v@gmail.com> wrote:
>=20
>> Currently DIVWU stands for *signed* divw opcode:
>>=20
>> 7d 2a 4b 96 divwu r9,r10,r9
>> 7d 2a 4b d6 divw r9,r10,r9
>>=20
>> Use the *unsigned* divw opcode for DIVWU.
>=20
> This looks like it's in only used in the BPF JIT code. =20
>=20
> Matt, any chance you an ACK/NACK this?
Sure, that looks sensible, thanks Vladimir.=20
Acked-by: Matt Evans <matt@ozlabs.org>
>=20
> Mikey
>=20
>>=20
>> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
>> ---
>> arch/powerpc/include/asm/ppc-opcode.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>=20
>> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include=
/asm/ppc-opcode.h
>> index d7fe9f5..c91842c 100644
>> --- a/arch/powerpc/include/asm/ppc-opcode.h
>> +++ b/arch/powerpc/include/asm/ppc-opcode.h
>> @@ -218,7 +218,7 @@
>> #define PPC_INST_MULLW 0x7c0001d6
>> #define PPC_INST_MULHWU 0x7c000016
>> #define PPC_INST_MULLI 0x1c000000
>> -#define PPC_INST_DIVWU 0x7c0003d6
>> +#define PPC_INST_DIVWU 0x7c000396
>> #define PPC_INST_RLWINM 0x54000000
>> #define PPC_INST_RLDICR 0x78000004
>> #define PPC_INST_SLW 0x7c000030
>> --=20
>> 1.7.10.4
>>=20
^ permalink raw reply
* Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
From: Scott Wood @ 2013-09-12 1:10 UTC (permalink / raw)
To: Yuantian.Tang; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1378882632-9053-1-git-send-email-Yuantian.Tang@freescale.com>
On Wed, 2013-09-11 at 14:57 +0800, Yuantian.Tang@freescale.com wrote:
> From: Tang Yuantian <yuantian.tang@freescale.com>
>
> The following SoCs will be affected: p2041, p3041, p4080,
> p5020, p5040, b4420, b4860, t4240
>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> v4:
> - add binding document
> - update compatible string
> - update the reg property
> v3:
> - fix typo
> v2:
> - add t4240, b4420, b4860 support
> - remove pll/4 clock from p2041, p3041 and p5020 board
>
> .../devicetree/bindings/clock/corenet-clock.txt | 80 +++++++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 34 ++++++-
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 34 ++++++-
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 59 ++++++++++-
> arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 59 ++++++++++-
> arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 111 ++++++++++++++++++++-
> arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 41 +++++++-
> arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 59 ++++++++++-
> arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 84 +++++++++++++++-
> arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++
> 17 files changed, 593 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt
> new file mode 100644
> index 0000000..51eab75
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
> @@ -0,0 +1,80 @@
> +Device Tree Clock bindings for Freescale PowerPC corenet platform
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be one or more of the following:
Shall include...
> + - "fsl,<chip>-clockgen": for chip specific clock block
> + - "fsl,qoriq-clockgen-[1,2].0": for chassis 1.0 and 2.0 clock
> + block respectively.
> + - "fsl,qoriq-chassis[1,2]-core-pll" - for a core PLL clock
> + - "fsl,qoriq-chassis[1,2]-core-mux" - for a core multiplexer clock.
> + Divided from the core PLL clock
Hmm, there's a bit of a mismatch here between "chassis2" and the "2.0"
on the clockgen node... perhaps it should be "fsl,qoriq-core-pll-2.0",
etc.
> + - "fixed-clock" - from common clock binding; should be output clock
> + of oscillator
> +- reg : shall be the control register offset from clock block base address.
This description of "reg" is overly specific (assumes how the parent
node's ranges are set up), incomplete (there's a size as well as the
offset), and does not apply to the clockgen node itself (you probably
shouldn't lump them together like this).
> +- clocks : shall be the input parent clock phandle for the clock.
Not required on the clockgen node
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property
From: Scott Wood @ 2013-09-12 1:15 UTC (permalink / raw)
To: Hu Mingkai-B21284; +Cc: Wood Scott-B07421, linuxppc-dev@ozlabs.org
In-Reply-To: <CF6CBFBA8EBBB949B6E321556F6E15090A135F45@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-09-10 at 21:07 -0500, Hu Mingkai-B21284 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 11, 2013 7:33 AM
> > To: Hu Mingkai-B21284
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions
> > property
> >
> > What happens to exsting users whose flash is laid out the existing way,
> > when they upgrade to these device trees?
> >
>
> The SPI flash layout should be mapping the new device tree.
>
> If the existing device tree is used to deploy the SPI flash, the following issues
> must be run into as the commit message described:
>
> 1. Kernel images would be overlapped with U-Boot image.
> 2. Kernel images would be overlapped with FMAN ucode.
> 3. Saving environment variables will crash the kernel image.
Has the SPI U-Boot image always been larger than 512K for all these
platforms? Why, given that we're under 512K for other boot modes?
> > We really should not be putting partition layout info in the device tree
> > to begin with...
> >
> OK, I will remove the layout diagram in the commit message.
That's not what I meant. I meant that the dts should be describing
hardware, and this is the sort of trouble we run into when we deviate
from that. A better way would be to use the mtdparts command line
option. Even better would be some sort of on-flash partition table.
-Scott
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Matt Evans @ 2013-09-12 1:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: paulus, Vladimir Murzin, linuxppc-dev, davem, dborkman
In-Reply-To: <1378154750.3978.43.camel@pasglop>
Hi Ben, Vladimir,
*dusts off very thick PPC cobwebs* Sorry for the delay as I'm =
travelling, didn't get to this until now.
On 02/09/2013, at 9:45 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
>> Ping
>>=20
>> On Wed, Aug 28, 2013 at 02:49:52AM +0400, Vladimir Murzin wrote:
>>> commit b6069a9570 (filter: add MOD operation) added generic
>>> support for modulus operation in BPF.
>>>=20
> Sorry, nobody got a chance to review that yet. Unfortunately Matt
> doesn't work for us anymore and none of us has experience with the
> BPF code, so somebody (possibly me) will need to spend a bit of time
> figuring it out before verifying that is correct.
>=20
> Do you have a test case/suite by any chance ?
>=20
> Ben.
>=20
>>> This patch brings JIT support for PPC64
>>>=20
>>> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
>>> ---
>>> arch/powerpc/net/bpf_jit_comp.c | 22 ++++++++++++++++++++++
>>> 1 file changed, 22 insertions(+)
>>>=20
>>> diff --git a/arch/powerpc/net/bpf_jit_comp.c =
b/arch/powerpc/net/bpf_jit_comp.c
>>> index bf56e33..96f24dc 100644
>>> --- a/arch/powerpc/net/bpf_jit_comp.c
>>> +++ b/arch/powerpc/net/bpf_jit_comp.c
>>> @@ -193,6 +193,28 @@ static int bpf_jit_build_body(struct sk_filter =
*fp, u32 *image,
>>> PPC_MUL(r_A, r_A, r_scratch1);
>>> }
>>> break;
>>> + case BPF_S_ALU_MOD_X: /* A %=3D X; */
>>> + ctx->seen |=3D SEEN_XREG;
>>> + PPC_CMPWI(r_X, 0);
>>> + if (ctx->pc_ret0 !=3D -1) {
>>> + PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
>>> + } else {
>>> + PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
>>> + PPC_LI(r_ret, 0);
>>> + PPC_JMP(exit_addr);
>>> + }
>>> + PPC_DIVWU(r_scratch1, r_A, r_X);
>>> + PPC_MUL(r_scratch1, r_X, r_scratch1);
>>> + PPC_SUB(r_A, r_A, r_scratch1);
>>> + break;
Without having compiled & tested this, it looks fine to me (especially =
with the corrected DIVWU opcode in the other patch, oops...).
>>> + case BPF_S_ALU_MOD_K: /* A %=3D K; */
>>> +#define r_scratch2 (r_scratch1 + 1)
>>> + PPC_LI32(r_scratch2, K);
>>> + PPC_DIVWU(r_scratch1, r_A, r_scratch2);
>>> + PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
>>> + PPC_SUB(r_A, r_A, r_scratch1);
>>> +#undef r_scratch2
>>> + break;
If you need another scratch register, it should really be defined in =
bpf_jit.h instead.
Once you define r_scratch2 in there,
Acked-by: Matt Evans <matt@ozlabs.org>
Thanks!
Matt
>>> case BPF_S_ALU_DIV_X: /* A /=3D X; */
>>> ctx->seen |=3D SEEN_XREG;
>>> PPC_CMPWI(r_X, 0);
>>> --=20
>>> 1.8.1.5
>>>=20
>=20
^ permalink raw reply
* RE: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
From: Tang Yuantian-B29983 @ 2013-09-12 1:31 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Li Yang-Leo-R58472
In-Reply-To: <1378948229.12204.486.camel@snotra.buserror.net>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IDIwMTPlubQ55pyIMTLml6Ug5pif5pyf5ZubIDk6MTANCj4gVG86IFRhbmcgWXVh
bnRpYW4tQjI5OTgzDQo+IENjOiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3JnOyBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IExpIFlh
bmctTGVvLVI1ODQ3Mg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0XSBwb3dlcnBjL21wYzg1eHg6
IFVwZGF0ZSB0aGUgY2xvY2sgZGV2aWNlIHRyZWUNCj4gbm9kZXMNCj4gDQo+IE9uIFdlZCwgMjAx
My0wOS0xMSBhdCAxNDo1NyArMDgwMCwgWXVhbnRpYW4uVGFuZ0BmcmVlc2NhbGUuY29tIHdyb3Rl
Og0KPiA+IEZyb206IFRhbmcgWXVhbnRpYW4gPHl1YW50aWFuLnRhbmdAZnJlZXNjYWxlLmNvbT4N
Cj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcgU29DcyB3aWxsIGJlIGFmZmVjdGVkOiBwMjA0MSwgcDMw
NDEsIHA0MDgwLCBwNTAyMCwNCj4gPiBwNTA0MCwgYjQ0MjAsIGI0ODYwLCB0NDI0MA0KPiA+DQo+
ID4gU2lnbmVkLW9mZi1ieTogVGFuZyBZdWFudGlhbiA8WXVhbnRpYW4uVGFuZ0BmcmVlc2NhbGUu
Y29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IExpIFlhbmcgPGxlb2xpQGZyZWVzY2FsZS5jb20+DQo+
ID4gLS0tDQo+ID4gdjQ6DQo+ID4gCS0gYWRkIGJpbmRpbmcgZG9jdW1lbnQNCj4gPiAJLSB1cGRh
dGUgY29tcGF0aWJsZSBzdHJpbmcNCj4gPiAJLSB1cGRhdGUgdGhlIHJlZyBwcm9wZXJ0eQ0KPiA+
IHYzOg0KPiA+IAktIGZpeCB0eXBvDQo+ID4gdjI6DQo+ID4gCS0gYWRkIHQ0MjQwLCBiNDQyMCwg
YjQ4NjAgc3VwcG9ydA0KPiA+IAktIHJlbW92ZSBwbGwvNCBjbG9jayBmcm9tIHAyMDQxLCBwMzA0
MSBhbmQgcDUwMjAgYm9hcmQNCj4gPg0KPiA+ICAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9jbG9j
ay9jb3JlbmV0LWNsb2NrLnR4dCAgICB8ICA4MA0KPiArKysrKysrKysrKysrKysNCj4gPiAgYXJj
aC9wb3dlcnBjL2Jvb3QvZHRzL2ZzbC9iNDQyMHNpLXBvc3QuZHRzaSAgICAgICAgfCAgMzQgKysr
KysrLQ0KPiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL2I0NDIwc2ktcHJlLmR0c2kgICAg
ICAgICB8ICAgMiArDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvYjQ4NjBzaS1wb3N0
LmR0c2kgICAgICAgIHwgIDM0ICsrKysrKy0NCj4gPiAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2Zz
bC9iNDg2MHNpLXByZS5kdHNpICAgICAgICAgfCAgIDQgKw0KPiA+ICBhcmNoL3Bvd2VycGMvYm9v
dC9kdHMvZnNsL3AyMDQxc2ktcG9zdC5kdHNpICAgICAgICB8ICA1OSArKysrKysrKysrLQ0KPiA+
ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL3AyMDQxc2ktcHJlLmR0c2kgICAgICAgICB8ICAg
NCArDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvcDMwNDFzaS1wb3N0LmR0c2kgICAg
ICAgIHwgIDU5ICsrKysrKysrKystDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvcDMw
NDFzaS1wcmUuZHRzaSAgICAgICAgIHwgICA0ICsNCj4gPiAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRz
L2ZzbC9wNDA4MHNpLXBvc3QuZHRzaSAgICAgICAgfCAxMTENCj4gKysrKysrKysrKysrKysrKysr
KystDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvcDQwODBzaS1wcmUuZHRzaSAgICAg
ICAgIHwgICA4ICsrDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvcDUwMjBzaS1wb3N0
LmR0c2kgICAgICAgIHwgIDQxICsrKysrKystDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9m
c2wvcDUwMjBzaS1wcmUuZHRzaSAgICAgICAgIHwgICAyICsNCj4gPiAgYXJjaC9wb3dlcnBjL2Jv
b3QvZHRzL2ZzbC9wNTA0MHNpLXBvc3QuZHRzaSAgICAgICAgfCAgNTkgKysrKysrKysrKy0NCj4g
PiAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2ZzbC9wNTA0MHNpLXByZS5kdHNpICAgICAgICAgfCAg
IDQgKw0KPiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL3Q0MjQwc2ktcG9zdC5kdHNpICAg
ICAgICB8ICA4NA0KPiArKysrKysrKysrKysrKystDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0
cy9mc2wvdDQyNDBzaS1wcmUuZHRzaSAgICAgICAgIHwgIDEyICsrKw0KPiA+ICAxNyBmaWxlcyBj
aGFuZ2VkLCA1OTMgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkgIGNyZWF0ZSBtb2RlDQo+
ID4gMTAwNjQ0IERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9jbG9jay9jb3JlbmV0
LWNsb2NrLnR4dA0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJl
ZS9iaW5kaW5ncy9jbG9jay9jb3JlbmV0LWNsb2NrLnR4dA0KPiA+IGIvRG9jdW1lbnRhdGlvbi9k
ZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2sudHh0DQo+ID4gbmV3IGZpbGUg
bW9kZSAxMDA2NDQNCj4gPiBpbmRleCAwMDAwMDAwLi41MWVhYjc1DQo+ID4gLS0tIC9kZXYvbnVs
bA0KPiA+ICsrKyBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9jbG9jay9jb3Jl
bmV0LWNsb2NrLnR4dA0KPiA+IEBAIC0wLDAgKzEsODAgQEANCj4gPiArRGV2aWNlIFRyZWUgQ2xv
Y2sgYmluZGluZ3MgZm9yIEZyZWVzY2FsZSBQb3dlclBDIGNvcmVuZXQgcGxhdGZvcm0NCj4gPiAr
DQo+ID4gK1RoaXMgYmluZGluZyB1c2VzIHRoZSBjb21tb24gY2xvY2sgYmluZGluZ1sxXS4NCj4g
PiArDQo+ID4gK1sxXSBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvY2xvY2svY2xv
Y2stYmluZGluZ3MudHh0DQo+ID4gKw0KPiA+ICtSZXF1aXJlZCBwcm9wZXJ0aWVzOg0KPiA+ICst
IGNvbXBhdGlibGUgOiBzaGFsbCBiZSBvbmUgb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nOg0KPiAN
Cj4gU2hhbGwgaW5jbHVkZS4uLg0KPiANCj4gPiArCS0gImZzbCw8Y2hpcD4tY2xvY2tnZW4iOiBm
b3IgY2hpcCBzcGVjaWZpYyBjbG9jayBibG9jaw0KPiA+ICsJLSAiZnNsLHFvcmlxLWNsb2NrZ2Vu
LVsxLDJdLjAiOiBmb3IgY2hhc3NpcyAxLjAgYW5kIDIuMCBjbG9jaw0KPiA+ICsJCWJsb2NrIHJl
c3BlY3RpdmVseS4NCj4gPiArCS0gImZzbCxxb3JpcS1jaGFzc2lzWzEsMl0tY29yZS1wbGwiIC0g
Zm9yIGEgY29yZSBQTEwgY2xvY2sNCj4gPiArCS0gImZzbCxxb3JpcS1jaGFzc2lzWzEsMl0tY29y
ZS1tdXgiIC0gZm9yIGEgY29yZSBtdWx0aXBsZXhlciBjbG9jay4NCj4gPiArCQlEaXZpZGVkIGZy
b20gdGhlIGNvcmUgUExMIGNsb2NrDQo+IA0KPiBIbW0sIHRoZXJlJ3MgYSBiaXQgb2YgYSBtaXNt
YXRjaCBoZXJlIGJldHdlZW4gImNoYXNzaXMyIiBhbmQgdGhlICIyLjAiDQo+IG9uIHRoZSBjbG9j
a2dlbiBub2RlLi4uIHBlcmhhcHMgaXQgc2hvdWxkIGJlICJmc2wscW9yaXEtY29yZS1wbGwtMi4w
IiwNCj4gZXRjLg0KPiANCj4gPiArCS0gImZpeGVkLWNsb2NrIiAtIGZyb20gY29tbW9uIGNsb2Nr
IGJpbmRpbmc7IHNob3VsZCBiZSBvdXRwdXQgY2xvY2sNCj4gPiArCQlvZiBvc2NpbGxhdG9yDQo+
ID4gKy0gcmVnIDogc2hhbGwgYmUgdGhlIGNvbnRyb2wgcmVnaXN0ZXIgb2Zmc2V0IGZyb20gY2xv
Y2sgYmxvY2sgYmFzZQ0KPiBhZGRyZXNzLg0KPiANCj4gVGhpcyBkZXNjcmlwdGlvbiBvZiAicmVn
IiBpcyBvdmVybHkgc3BlY2lmaWMgKGFzc3VtZXMgaG93IHRoZSBwYXJlbnQNCj4gbm9kZSdzIHJh
bmdlcyBhcmUgc2V0IHVwKSwgaW5jb21wbGV0ZSAodGhlcmUncyBhIHNpemUgYXMgd2VsbCBhcyB0
aGUNCj4gb2Zmc2V0KSwgYW5kIGRvZXMgbm90IGFwcGx5IHRvIHRoZSBjbG9ja2dlbiBub2RlIGl0
c2VsZiAoeW91IHByb2JhYmx5DQo+IHNob3VsZG4ndCBsdW1wIHRoZW0gdG9nZXRoZXIgbGlrZSB0
aGlzKS4NCj4gDQpEbyB5b3UgbWVhbiBJIHNob3VsZCBleHBsYWluIHRoZSBSRUcgb2YgY2xvY2tn
ZW4gYW5kIGl0cyBjaGlsZCBub2RlIHJlc3BlY3RpdmVseT8NCg0KPiA+ICstIGNsb2NrcyA6IHNo
YWxsIGJlIHRoZSBpbnB1dCBwYXJlbnQgY2xvY2sgcGhhbmRsZSBmb3IgdGhlIGNsb2NrLg0KPiAN
Cj4gTm90IHJlcXVpcmVkIG9uIHRoZSBjbG9ja2dlbiBub2RlDQo+IA0KUmVxdWlyZWQgYnkgY2hp
bGQgbm9kZSBvZiBjbG9ja2dlbi4NCg0KUmVnYXJkcywNCll1YW50aWFuDQo+IC1TY290dA0KPiAN
Cg0K
^ permalink raw reply
* RE: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
From: Wang Dongsheng-B40534 @ 2013-09-12 2:27 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378939377.12204.412.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMiwgMjAxMyA2OjQzIEFNDQo+IFRvOiBX
YW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMi80
XSBwb3dlcnBjLzg1eHg6IGFkZCBoYXJkd2FyZSBhdXRvbWF0aWNhbGx5DQo+IGVudGVyIGFsdGl2
ZWMgaWRsZSBzdGF0ZQ0KPiANCj4gT24gV2VkLCAyMDEzLTA5LTExIGF0IDEzOjU2ICswODAwLCBE
b25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5n
LndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPg0KPiA+IEVhY2ggY29yZSdzIEFsdGlWZWMgdW5pdCBt
YXkgYmUgcGxhY2VkIGludG8gYSBwb3dlciBzYXZpbmdzIG1vZGUNCj4gPiBieSB0dXJuaW5nIG9m
ZiBwb3dlciB0byB0aGUgdW5pdC4gQ29yZSBoYXJkd2FyZSB3aWxsIGF1dG9tYXRpY2FsbHkNCj4g
PiBwb3dlciBkb3duIHRoZSBBbHRpVmVjIHVuaXQgYWZ0ZXIgbm8gQWx0aVZlYyBpbnN0cnVjdGlv
bnMgaGF2ZQ0KPiA+IGV4ZWN1dGVkIGluIE4gY3ljbGVzLiBUaGUgQWx0aVZlYyBwb3dlci1jb250
cm9sIGlzIHRyaWdnZXJlZCBieQ0KPiBoYXJkd2FyZS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6
IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0K
PiA+ICp2MzoNCj4gPiBBc3NlbWJseSBjb2RlIGluc3RlYWQgb2YgQyBjb2RlLg0KPiA+DQo+ID4g
KnYyOg0KPiA+IFJlbW92ZToNCj4gPiBkZWxldGUgc2V0dXBfaWRsZV9od19nb3Zlcm5vciBmdW5j
dGlvbi4NCj4gPiBkZWxldGUgIkZpeCBlcnJhdHVtIiBmb3IgcmV2MS4NCj4gPg0KPiA+IE1vdmU6
DQo+ID4gbW92ZSBzZXR1cF8qIGludG8gX19zZXR1cC9yZXN0b3JlX2NwdV9lNjUwMC4NCj4gPg0K
PiA+ICBhcmNoL3Bvd2VycGMva2VybmVsL2NwdV9zZXR1cF9mc2xfYm9va2UuUyB8IDIwICsrKysr
KysrKysrKysrKysrKysrDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspDQo+
ID4NCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2tlcm5lbC9jcHVfc2V0dXBfZnNsX2Jv
b2tlLlMNCj4gYi9hcmNoL3Bvd2VycGMva2VybmVsL2NwdV9zZXR1cF9mc2xfYm9va2UuUw0KPiA+
IGluZGV4IGJmYjE4YzcuLjNjMDNjMTA5IDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9r
ZXJuZWwvY3B1X3NldHVwX2ZzbF9ib29rZS5TDQo+ID4gKysrIGIvYXJjaC9wb3dlcnBjL2tlcm5l
bC9jcHVfc2V0dXBfZnNsX2Jvb2tlLlMNCj4gPiBAQCAtNTMsMTEgKzUzLDMwIEBAIF9HTE9CQUwo
X19lNTAwX2RjYWNoZV9zZXR1cCkNCj4gPiAgCWlzeW5jDQo+ID4gIAlibHINCj4gPg0KPiA+ICsv
Kg0KPiA+ICsgKiBGSVhNRSAtIFdlIGRvbid0IGtub3cgdGhlIEFsdGlWZWMgYXBwbGljYXRpb24g
c2NlbmFyaW9zLg0KPiA+ICsgKi8NCj4gPiArI2RlZmluZSBBVl9XQUlUX0lETEVfQklUCQk1MCAv
KiAxbXMsIFRCIGZyZXF1ZW5jeSBpcyA0MS42Nk1IWg0KPiAqLw0KPiA+ICtfR0xPQkFMKHNldHVw
X2FsdGl2ZWNfaWRsZSkNCj4gPiArCW1mc3ByCXIzLCBTUFJOX1BXUk1HVENSMA0KPiA+ICsNCj4g
PiArCS8qIEVuYWJsZSBBbHRpdmVjIElkbGUgKi8NCj4gPiArCW9yaXMJcjMsIHIzLCBQV1JNR1RD
UjBfQVZfSURMRV9QRF9FTkBoDQo+ID4gKwlsaQlyNCwgQVZfV0FJVF9JRExFX0JJVA0KPiA+ICsN
Cj4gPiArCS8qIFNldCBBdXRvbWF0aWMgQWx0aVZlYyBJZGxlIENvdW50ICovDQo+ID4gKwlybHdp
bWkJcjMsIHI0LCBQV1JNR1RDUjBfQVZfSURMRV9DTlRfU0hJRlQsDQo+IFBXUk1HVENSMF9BVl9J
RExFX0NOVA0KPiA+ICsNCj4gPiArCW10c3ByCVNQUk5fUFdSTUdUQ1IwLCByMw0KPiA+ICsNCj4g
PiArCWJscg0KPiANCj4gVGhlIEZJWE1FIGNvbW1lbnQgaXMgbm90IGNsZWFyLiAgSWYgeW91IG1l
YW4gdGhhdCB3ZSBoYXZlbid0IHlldCBkb25lDQo+IHRlc3RpbmcgdG8gZGV0ZXJtaW5lIGEgcmVh
c29uYWJsZSBkZWZhdWx0IHZhbHVlIGZvciBBVl9XQUlUX0lETEVfQklULA0KPiB0aGVuIGp1c3Qg
c2F5IHRoYXQuICBMaWtld2lzZSB3aXRoIHRoZSBGSVhNRSBjb21tZW50IGluIHRoZSBwdzIwIHBh
dGNoDQo+IC0tIHRoZSB1bmNlcnRhaW50eSBpcyBkdWUgdG8gYSBsYWNrIG9mIGludmVzdGlnYXRp
b24sIG5vdCAiYmVjYXVzZSB3ZQ0KPiBkb24ndCBrbm93IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRo
ZSBjcHUgbG9hZCIuDQo+IA0KPiBXaGlsZSBzb21lIHdvcmtsb2FkcyBtYXkgd2FudCBhIGRpZmZl
cmVudCB2YWx1ZSB0aGFuIHdoYXRldmVyIGRlZmF1bHQgd2UNCj4gc2V0LCB0aGF0J3Mgd2hhdCB0
aGUgc3lzZnMgaW50ZXJmYWNlIGlzIGZvci4gIFRoZSBvbmx5IHRoaW5nIG1pc3NpbmcNCj4gaGVy
ZSBpcyBiZW5jaG1hcmtpbmcgdG8gZGV0ZXJtaW5lIGEgZ29vZCBvdmVyYWxsIGRlZmF1bHQuDQo+
IA0KVGhhbmtzLg0KDQo=
^ 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