* [PATCH v2 1/3] powerpc: move the cpu_has_feature to a separate file
From: Kevin Hao @ 2013-09-02 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1378100726-32545-1-git-send-email-haokexin@gmail.com>
We plan to use jump label for cpu_has_feature. In order to implement
this we need to include the linux/jump_label.h in asm/cputable.h.
But it seems that asm/cputable.h is so basic header file for ppc that
it is almost included by all the other header files. The including of
the linux/jump_label.h will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
v2: Update the commit log to replace the jump_label_base.h with jump_label.h.
arch/powerpc/include/asm/cacheflush.h | 1 +
arch/powerpc/include/asm/cpufeatures.h | 14 ++++++++++++++
arch/powerpc/include/asm/cputable.h | 8 --------
arch/powerpc/include/asm/cputime.h | 1 +
arch/powerpc/include/asm/dbell.h | 1 +
arch/powerpc/include/asm/dcr-native.h | 1 +
arch/powerpc/include/asm/mman.h | 1 +
arch/powerpc/include/asm/time.h | 1 +
arch/powerpc/kernel/align.c | 1 +
arch/powerpc/kernel/irq.c | 1 +
arch/powerpc/kernel/process.c | 1 +
arch/powerpc/kernel/setup-common.c | 1 +
arch/powerpc/kernel/setup_32.c | 1 +
arch/powerpc/kernel/smp.c | 1 +
arch/powerpc/oprofile/op_model_rs64.c | 1 +
arch/powerpc/platforms/cell/pervasive.c | 1 +
arch/powerpc/xmon/ppc-dis.c | 1 +
17 files changed, 29 insertions(+), 8 deletions(-)
create mode 100644 arch/powerpc/include/asm/cpufeatures.h
diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
index 5b93122..8d2d4c3 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -11,6 +11,7 @@
#include <linux/mm.h>
#include <asm/cputable.h>
+#include <asm/cpufeatures.h>
/*
* No cache flushing is required when address mappings are changed,
diff --git a/arch/powerpc/include/asm/cpufeatures.h b/arch/powerpc/include/asm/cpufeatures.h
new file mode 100644
index 0000000..37650db
--- /dev/null
+++ b/arch/powerpc/include/asm/cpufeatures.h
@@ -0,0 +1,14 @@
+#ifndef __ASM_POWERPC_CPUFEATURES_H
+#define __ASM_POWERPC_CPUFEATURES_H
+
+#include <asm/cputable.h>
+
+static inline int cpu_has_feature(unsigned long feature)
+{
+ return (CPU_FTRS_ALWAYS & feature) ||
+ (CPU_FTRS_POSSIBLE
+ & cur_cpu_spec->cpu_features
+ & feature);
+}
+
+#endif /* __ASM_POWERPC_CPUFEATURE_H */
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 0d4939b..ca177b2 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -546,14 +546,6 @@ enum {
};
#endif /* __powerpc64__ */
-static inline int cpu_has_feature(unsigned long feature)
-{
- return (CPU_FTRS_ALWAYS & feature) ||
- (CPU_FTRS_POSSIBLE
- & cur_cpu_spec->cpu_features
- & feature);
-}
-
#define HBP_NUM 1
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/cputime.h b/arch/powerpc/include/asm/cputime.h
index 607559a..15481e2 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -28,6 +28,7 @@ static inline void setup_cputime_one_jiffy(void) { }
#include <asm/div64.h>
#include <asm/time.h>
#include <asm/param.h>
+#include <asm/cpufeatures.h>
typedef u64 __nocast cputime_t;
typedef u64 __nocast cputime64_t;
diff --git a/arch/powerpc/include/asm/dbell.h b/arch/powerpc/include/asm/dbell.h
index 5fa6b20..2d9eae3 100644
--- a/arch/powerpc/include/asm/dbell.h
+++ b/arch/powerpc/include/asm/dbell.h
@@ -16,6 +16,7 @@
#include <linux/threads.h>
#include <asm/ppc-opcode.h>
+#include <asm/cpufeatures.h>
#define PPC_DBELL_MSG_BRDCAST (0x04000000)
#define PPC_DBELL_TYPE(x) (((x) & 0xf) << (63-36))
diff --git a/arch/powerpc/include/asm/dcr-native.h b/arch/powerpc/include/asm/dcr-native.h
index 7d2e623..3372650 100644
--- a/arch/powerpc/include/asm/dcr-native.h
+++ b/arch/powerpc/include/asm/dcr-native.h
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <asm/cputable.h>
+#include <asm/cpufeatures.h>
typedef struct {
unsigned int base;
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 8565c25..74922ad 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -13,6 +13,7 @@
#include <asm/cputable.h>
#include <linux/mm.h>
+#include <asm/cpufeatures.h>
/*
* This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index c1f2676..20e6ee9 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -18,6 +18,7 @@
#include <linux/percpu.h>
#include <asm/processor.h>
+#include <asm/cpufeatures.h>
/* time.c */
extern unsigned long tb_ticks_per_jiffy;
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index a27ccd5..4f49cb1 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -25,6 +25,7 @@
#include <asm/cputable.h>
#include <asm/emulated_ops.h>
#include <asm/switch_to.h>
+#include <asm/cpufeatures.h>
struct aligninfo {
unsigned char len;
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index c69440c..164a9ad 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -75,6 +75,7 @@
#endif
#define CREATE_TRACE_POINTS
#include <asm/trace.h>
+#include <asm/cpufeatures.h>
DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
EXPORT_PER_CPU_SYMBOL(irq_stat);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6f428da..cc65650 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -57,6 +57,7 @@
#endif
#include <linux/kprobes.h>
#include <linux/kdebug.h>
+#include <asm/cpufeatures.h>
/* Transactional Memory debug */
#ifdef TM_DEBUG_SW
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 3d261c0..6e3e595 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -61,6 +61,7 @@
#include <asm/cputhreads.h>
#include <mm/mmu_decl.h>
#include <asm/fadump.h>
+#include <asm/cpufeatures.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index a4bbcae..304a85b 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -39,6 +39,7 @@
#include <asm/udbg.h>
#include <asm/mmu_context.h>
#include <asm/epapr_hcalls.h>
+#include <asm/cpufeatures.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 442d8e2..e793c0d 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -50,6 +50,7 @@
#endif
#include <asm/vdso.h>
#include <asm/debug.h>
+#include <asm/cpufeatures.h>
#ifdef DEBUG
#include <asm/udbg.h>
diff --git a/arch/powerpc/oprofile/op_model_rs64.c b/arch/powerpc/oprofile/op_model_rs64.c
index 9b801b8..924b66c8 100644
--- a/arch/powerpc/oprofile/op_model_rs64.c
+++ b/arch/powerpc/oprofile/op_model_rs64.c
@@ -14,6 +14,7 @@
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/oprofile_impl.h>
+#include <asm/cpufeatures.h>
#define dbg(args...)
diff --git a/arch/powerpc/platforms/cell/pervasive.c b/arch/powerpc/platforms/cell/pervasive.c
index d17e98b..036215b 100644
--- a/arch/powerpc/platforms/cell/pervasive.c
+++ b/arch/powerpc/platforms/cell/pervasive.c
@@ -35,6 +35,7 @@
#include <asm/pgtable.h>
#include <asm/reg.h>
#include <asm/cell-regs.h>
+#include <asm/cpufeatures.h>
#include "pervasive.h"
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 89098f32..a642155 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -24,6 +24,7 @@ Software Foundation, 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, US
#include "ansidecl.h"
#include "ppc.h"
#include "dis-asm.h"
+#include <asm/cpufeatures.h>
/* Print a PowerPC or POWER instruction. */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 2/3] powerpc: use the jump label for cpu_has_feature
From: Kevin Hao @ 2013-09-02 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1378100726-32545-1-git-send-email-haokexin@gmail.com>
The cpu features are fixed once the probe of cpu features are done.
And the function cpu_has_feature() does be used in some hot path.
The checking of the cpu features for each time of invoking of
cpu_has_feature() seems suboptimal. This tries to reduce this
overhead of this check by using jump label. But we can only use
the jump label for this check only after the execution of
jump_label_init(), so we introduce another jump label to
still do the feature check by default before all the cpu
feature jump labels are initialized.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
v2: Include the jump_label.h instead of jump_label_base.h.
arch/powerpc/include/asm/cpufeatures.h | 27 +++++++++++++++++++++++++++
arch/powerpc/kernel/cputable.c | 23 +++++++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/arch/powerpc/include/asm/cpufeatures.h b/arch/powerpc/include/asm/cpufeatures.h
index 37650db..2631287 100644
--- a/arch/powerpc/include/asm/cpufeatures.h
+++ b/arch/powerpc/include/asm/cpufeatures.h
@@ -2,7 +2,33 @@
#define __ASM_POWERPC_CPUFEATURES_H
#include <asm/cputable.h>
+#ifdef CONFIG_JUMP_LABEL
+#include <linux/jump_label.h>
+#ifdef __powerpc64__
+#define MAX_CPU_FEATURES 64
+#else
+#define MAX_CPU_FEATURES 32
+#endif
+extern struct static_key cpu_feat_keys[MAX_CPU_FEATURES];
+extern struct static_key cpu_feat_keys_enabled;
+
+static inline int cpu_has_feature(unsigned long feature)
+{
+ if (CPU_FTRS_ALWAYS & feature)
+ return 1;
+
+ if (!(CPU_FTRS_POSSIBLE | feature))
+ return 0;
+
+ if (static_key_false(&cpu_feat_keys_enabled)) {
+ int i = __builtin_ctzl(feature);
+
+ return static_key_false(&cpu_feat_keys[i]);
+ } else
+ return !!(cur_cpu_spec->cpu_features & feature);
+}
+#else
static inline int cpu_has_feature(unsigned long feature)
{
return (CPU_FTRS_ALWAYS & feature) ||
@@ -10,5 +36,6 @@ static inline int cpu_has_feature(unsigned long feature)
& cur_cpu_spec->cpu_features
& feature);
}
+#endif
#endif /* __ASM_POWERPC_CPUFEATURE_H */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 597d954..50bd216 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -21,6 +21,7 @@
#include <asm/prom.h> /* for PTRRELOC on ARCH=ppc */
#include <asm/mmu.h>
#include <asm/setup.h>
+#include <asm/cpufeatures.h>
struct cpu_spec* cur_cpu_spec = NULL;
EXPORT_SYMBOL(cur_cpu_spec);
@@ -2258,3 +2259,25 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
return NULL;
}
+
+#ifdef CONFIG_JUMP_LABEL
+struct static_key cpu_feat_keys[MAX_CPU_FEATURES];
+struct static_key cpu_feat_keys_enabled;
+
+static __init int cpu_feat_keys_init(void)
+{
+ int i;
+
+ for (i = 0; i < MAX_CPU_FEATURES; i++) {
+ unsigned long f = 1 << i;
+
+ if (cur_cpu_spec->cpu_features & f)
+ static_key_slow_inc(&cpu_feat_keys[i]);
+ }
+
+ static_key_slow_inc(&cpu_feat_keys_enabled);
+
+ return 0;
+}
+early_initcall(cpu_feat_keys_init);
+#endif
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 3/3] powerpc: use jump label for mmu_has_feature
From: Kevin Hao @ 2013-09-02 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1378100726-32545-1-git-send-email-haokexin@gmail.com>
The mmu features are fixed once the probe of mmu features are done.
And the function mmu_has_feature() does be used in some hot path.
The checking of the mmu features for each time of invoking of
mmu_has_feature() seems suboptimal. This tries to reduce this
overhead of this check by using jump label. But we can only use
the jump label for this check only after the execution of
jump_label_init(), so we introduce another jump label to
still do the feature check by default before all the mmu
feature jump labels are initialized.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
v2: Include the jump_label.h instead of jump_label_base.h.
arch/powerpc/include/asm/mmu.h | 19 +++++++++++++++++++
arch/powerpc/kernel/cputable.c | 20 ++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 691fd8a..b7f049e 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -121,10 +121,29 @@
DECLARE_PER_CPU(int, next_tlbcam_idx);
#endif
+#ifdef CONFIG_JUMP_LABEL
+#include <linux/jump_label.h>
+
+#define MAX_MMU_FEATURES 32
+
+extern struct static_key mmu_feat_keys[MAX_MMU_FEATURES];
+extern struct static_key mmu_feat_keys_enabled;
+
+static inline int mmu_has_feature(unsigned long feature)
+{
+ if (static_key_false(&mmu_feat_keys_enabled)) {
+ int i = __builtin_ctzl(feature);
+
+ return static_key_false(&mmu_feat_keys[i]);
+ } else
+ return !!(cur_cpu_spec->mmu_features & feature);
+}
+#else
static inline int mmu_has_feature(unsigned long feature)
{
return (cur_cpu_spec->mmu_features & feature);
}
+#endif
static inline void mmu_clear_feature(unsigned long feature)
{
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 50bd216..785370b 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2280,4 +2280,24 @@ static __init int cpu_feat_keys_init(void)
return 0;
}
early_initcall(cpu_feat_keys_init);
+
+struct static_key mmu_feat_keys[MAX_MMU_FEATURES];
+struct static_key mmu_feat_keys_enabled;
+
+static __init int mmu_feat_keys_init(void)
+{
+ int i;
+
+ for (i = 0; i < MAX_MMU_FEATURES; i++) {
+ unsigned long f = 1 << i;
+
+ if (cur_cpu_spec->mmu_features & f)
+ static_key_slow_inc(&mmu_feat_keys[i]);
+ }
+
+ static_key_slow_inc(&mmu_feat_keys_enabled);
+
+ return 0;
+}
+early_initcall(mmu_feat_keys_init);
#endif
--
1.8.3.1
^ permalink raw reply related
* [PATCH] fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization
From: Shengzhou Liu @ 2013-09-02 5:25 UTC (permalink / raw)
To: linuxppc-dev, linux-usb; +Cc: Shengzhou Liu
In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
based on master branch of upstream, from sdk1.4
drivers/usb/host/ehci-fsl.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index bd831ec..3156e12 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -270,8 +270,9 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
if (pdata->have_sysif_regs && pdata->controller_ver &&
(phy_mode == FSL_USB2_PHY_ULPI)) {
/* check PHY_CLK_VALID to get phy clk valid */
- if (!spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
- PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0)) {
+ if (!(spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
+ PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0) ||
+ in_be32(non_ehci + FSL_SOC_USB_PRICTRL))) {
printk(KERN_WARNING "fsl-ehci: USB PHY clock invalid\n");
return -EINVAL;
}
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH V2 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Liu Shengzhou-B36685 @ 2013-09-02 9:55 UTC (permalink / raw)
To: Xie Xiaobo-R63061, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org, Wood Scott-B07421
Cc: Johnston Michael-R49610, Xie Xiaobo-R63061
In-Reply-To: <1377856896-29244-2-git-send-email-X.Xie@freescale.com>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+shengzhou.liu=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Xie =
Xiaobo
> Sent: Friday, August 30, 2013 6:02 PM
> To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood Scott-=
B07421
> Cc: Johnston Michael-R49610; Xie Xiaobo-R63061
> Subject: [PATCH V2 2/2] powerpc/85xx: Add TWR-P1025 board support
>=20
> +
> + mdio@24000 {
> + phy0: ethernet-phy@2 {
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <1 1>;
> + reg =3D <0x2>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <2 1>;
> + reg =3D <0x1>;
> + };
#interrupt-cells is 4.
^ permalink raw reply
* [PATCH V3 1/2] powerpc/85xx: Add QE common init functions
From: Xie Xiaobo @ 2013-09-02 10:11 UTC (permalink / raw)
To: linuxppc-dev, galak, scottwood; +Cc: Xie Xiaobo
Define two QE init functions in common file, and avoid
the same codes being duplicated in board files.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
V3 -> V2: Nochange
arch/powerpc/platforms/85xx/common.c | 47 +++++++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx.h | 8 ++++++
2 files changed, 55 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index d0861a0..fb3f5e6 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -7,6 +7,8 @@
*/
#include <linux/of_platform.h>
+#include <asm/qe.h>
+#include <asm/qe_ic.h>
#include <sysdev/cpm2_pic.h>
#include "mpc85xx.h"
@@ -80,3 +82,48 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
}
#endif
+
+#ifdef CONFIG_QUICC_ENGINE
+void __init mpc85xx_qe_pic_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
+ if (np) {
+ qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
+ qe_ic_cascade_high_mpic);
+ of_node_put(np);
+ } else
+ pr_err("%s: Could not find qe-ic node\n", __func__);
+}
+
+void __init mpc85xx_qe_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe");
+ if (!np) {
+ np = of_find_node_by_name(NULL, "qe");
+ if (!np) {
+ pr_err("%s: Could not find Quicc Engine node\n",
+ __func__);
+ return;
+ }
+ }
+
+ qe_reset();
+ of_node_put(np);
+
+ np = of_find_node_by_name(NULL, "par_io");
+ if (np) {
+ struct device_node *ucc;
+
+ par_io_init(np);
+ of_node_put(np);
+
+ for_each_node_by_name(ucc, "ucc")
+ par_io_of_config(ucc);
+
+ }
+}
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
index 2aa7c5d..1d39095 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -8,4 +8,12 @@ extern void mpc85xx_cpm2_pic_init(void);
static inline void __init mpc85xx_cpm2_pic_init(void) {}
#endif /* CONFIG_CPM2 */
+#ifdef CONFIG_QUICC_ENGINE
+extern void mpc85xx_qe_pic_init(void);
+extern void mpc85xx_qe_init(void);
+#else
+static inline void __init mpc85xx_qe_pic_init(void) {}
+static inline void __init mpc85xx_qe_init(void) {}
+#endif
+
#endif
--
1.8.0
^ permalink raw reply related
* [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Xie Xiaobo @ 2013-09-02 10:11 UTC (permalink / raw)
To: linuxppc-dev, galak, scottwood; +Cc: Michael Johnston, Xie Xiaobo
In-Reply-To: <1378116699-18826-1-git-send-email-X.Xie@freescale.com>
TWR-P1025 Overview
-----------------
512Mbyte DDR3 (on board DDR)
64MB Nor Flash
eTSEC1: Connected to RGMII PHY AR8035
eTSEC3: Connected to RGMII PHY AR8035
Two USB2.0 Type A
One microSD Card slot
One mini-PCIe slot
One mini-USB TypeB dual UART
Signed-off-by: Michael Johnston <michael.johnston@freescale.com>
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
Patch V3: fix pcie range issue in dts
Patch V2: QE related init codes were factored out to a common file
arch/powerpc/boot/dts/p1025twr.dtsi | 244 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1025twr_32b.dts | 135 ++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 6 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/twr_p102x.c | 142 +++++++++++++++++++
5 files changed, 528 insertions(+)
create mode 100644 arch/powerpc/boot/dts/p1025twr.dtsi
create mode 100644 arch/powerpc/boot/dts/p1025twr_32b.dts
create mode 100644 arch/powerpc/platforms/85xx/twr_p102x.c
diff --git a/arch/powerpc/boot/dts/p1025twr.dtsi b/arch/powerpc/boot/dts/p1025twr.dtsi
new file mode 100644
index 0000000..07df721
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1025twr.dtsi
@@ -0,0 +1,244 @@
+/*
+ * P1025 TWR Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * 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 copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * 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 CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/{
+ aliases {
+ ethernet3 = &enet3;
+ ethernet4 = &enet4;
+ };
+};
+
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x4000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg = <0x0 0x00040000>;
+ label = "NOR Vitesse-7385 Firmware";
+ read-only;
+ };
+
+ partition@40000 {
+ /* 256KB for DTB Image */
+ reg = <0x00040000 0x00040000>;
+ label = "NOR DTB Image";
+ };
+
+ partition@80000 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg = <0x00080000 0x00380000>;
+ label = "NOR Linux Kernel Image";
+ };
+
+ partition@400000 {
+ /* 58.75MB for JFFS2 based Root file System */
+ reg = <0x00400000 0x03ac0000>;
+ label = "NOR Root File System";
+ };
+
+ partition@ec0000 {
+ /* This location must not be altered */
+ /* 256KB for QE ucode firmware*/
+ reg = <0x03ec0000 0x00040000>;
+ label = "NOR QE microcode firmware";
+ read-only;
+ };
+
+ partition@f00000 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment Variables */
+ reg = <0x03f00000 0x00100000>;
+ label = "NOR U-Boot Image";
+ read-only;
+ };
+ };
+
+ /* CS2 for Display */
+ ssd1289@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ssd1289";
+ reg = <0x2 0x0000 0x0002
+ 0x2 0x0002 0x0002>;
+ };
+
+};
+
+&soc {
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <1 1>;
+ reg = <0x2>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <2 1>;
+ reg = <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ mdio@25000 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ mdio@26000 {
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+
+ };
+
+ enet1: ethernet@b1000 {
+ status = "disabled";
+ };
+
+ enet2: ethernet@b2000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ par_io@e0100 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xe0100 0x60>;
+ ranges = <0x0 0xe0100 0x60>;
+ device_type = "par_io";
+ num-ports = <3>;
+ pio1: ucc_pin@01 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x13 0x1 0x0 0x1 0x0 /* QE_MUX_MDC */
+ 0x1 0x14 0x3 0x0 0x1 0x0 /* QE_MUX_MDIO */
+ 0x0 0x17 0x2 0x0 0x2 0x0 /* CLK12 */
+ 0x0 0x18 0x2 0x0 0x1 0x0 /* CLK9 */
+ 0x0 0x7 0x1 0x0 0x2 0x0 /* ENET1_TXD0_SER1_TXD0 */
+ 0x0 0x9 0x1 0x0 0x2 0x0 /* ENET1_TXD1_SER1_TXD1 */
+ 0x0 0xb 0x1 0x0 0x2 0x0 /* ENET1_TXD2_SER1_TXD2 */
+ 0x0 0xc 0x1 0x0 0x2 0x0 /* ENET1_TXD3_SER1_TXD3 */
+ 0x0 0x6 0x2 0x0 0x2 0x0 /* ENET1_RXD0_SER1_RXD0 */
+ 0x0 0xa 0x2 0x0 0x2 0x0 /* ENET1_RXD1_SER1_RXD1 */
+ 0x0 0xe 0x2 0x0 0x2 0x0 /* ENET1_RXD2_SER1_RXD2 */
+ 0x0 0xf 0x2 0x0 0x2 0x0 /* ENET1_RXD3_SER1_RXD3 */
+ 0x0 0x5 0x1 0x0 0x2 0x0 /* ENET1_TX_EN_SER1_RTS_B */
+ 0x0 0xd 0x1 0x0 0x2 0x0 /* ENET1_TX_ER */
+ 0x0 0x4 0x2 0x0 0x2 0x0 /* ENET1_RX_DV_SER1_CTS_B */
+ 0x0 0x8 0x2 0x0 0x2 0x0 /* ENET1_RX_ER_SER1_CD_B */
+ 0x0 0x11 0x2 0x0 0x2 0x0 /* ENET1_CRS */
+ 0x0 0x10 0x2 0x0 0x2 0x0>; /* ENET1_COL */
+ };
+
+ pio2: ucc_pin@02 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x13 0x1 0x0 0x1 0x0 /* QE_MUX_MDC */
+ 0x1 0x14 0x3 0x0 0x1 0x0 /* QE_MUX_MDIO */
+ 0x1 0xb 0x2 0x0 0x1 0x0 /* CLK13 */
+ 0x1 0x7 0x1 0x0 0x2 0x0 /* ENET5_TXD0_SER5_TXD0 */
+ 0x1 0xa 0x1 0x0 0x2 0x0 /* ENET5_TXD1_SER5_TXD1 */
+ 0x1 0x6 0x2 0x0 0x2 0x0 /* ENET5_RXD0_SER5_RXD0 */
+ 0x1 0x9 0x2 0x0 0x2 0x0 /* ENET5_RXD1_SER5_RXD1 */
+ 0x1 0x5 0x1 0x0 0x2 0x0 /* ENET5_TX_EN_SER5_RTS_B */
+ 0x1 0x4 0x2 0x0 0x2 0x0 /* ENET5_RX_DV_SER5_CTS_B */
+ 0x1 0x8 0x2 0x0 0x2 0x0>; /* ENET5_RX_ER_SER5_CD_B */
+ };
+
+ pio3: ucc_pin@03 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x0 0x16 0x2 0x0 0x2 0x0 /* SER7_CD_B*/
+ 0x0 0x12 0x2 0x0 0x2 0x0 /* SER7_CTS_B*/
+ 0x0 0x13 0x1 0x0 0x2 0x0 /* SER7_RTS_B*/
+ 0x0 0x14 0x2 0x0 0x2 0x0 /* SER7_RXD0*/
+ 0x0 0x15 0x1 0x0 0x2 0x0>; /* SER7_TXD0*/
+ };
+
+ pio4: ucc_pin@04 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x0 0x2 0x0 0x2 0x0 /* SER3_CD_B*/
+ 0x0 0x1c 0x2 0x0 0x2 0x0 /* SER3_CTS_B*/
+ 0x0 0x1d 0x1 0x0 0x2 0x0 /* SER3_RTS_B*/
+ 0x0 0x1e 0x2 0x0 0x2 0x0 /* SER3_RXD0*/
+ 0x0 0x1f 0x1 0x0 0x2 0x0>; /* SER3_TXD0*/
+ };
+ };
+};
+
+&qe {
+ serial2: ucc@2600 {
+ device_type = "serial";
+ compatible = "ucc_uart";
+ port-number = <0>;
+ rx-clock-name = "brg6";
+ tx-clock-name = "brg6";
+ pio-handle = <&pio3>;
+ };
+
+ serial3: ucc@2200 {
+ device_type = "serial";
+ compatible = "ucc_uart";
+ port-number = <1>;
+ rx-clock-name = "brg2";
+ tx-clock-name = "brg2";
+ pio-handle = <&pio4>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1025twr_32b.dts b/arch/powerpc/boot/dts/p1025twr_32b.dts
new file mode 100644
index 0000000..ccb173f
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1025twr_32b.dts
@@ -0,0 +1,135 @@
+/*
+ * P1025 TWR Device Tree Source (32-bit address map)
+ *
+ * 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 copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * 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 CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model = "fsl,P1025";
+ compatible = "fsl,TWR-P1025";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg = <0 0xffe05000 0 0x1000>;
+
+ /* NOR Flash and SSD1289 */
+ ranges = <0x0 0x0 0x0 0xec000000 0x04000000
+ 0x2 0x0 0x0 0xe0000000 0x00020000>;
+ };
+
+ soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg = <0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@ffe80000 {
+ ranges = <0x0 0x0 0xffe80000 0x40000>;
+ reg = <0 0xffe80000 0 0x480>;
+ brg-frequency = <0>;
+ bus-frequency = <0>;
+ status = "disabled"; /* no firmware loaded */
+
+ enet3: ucc@2000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "clk12";
+ tx-clock-name = "clk9";
+ pio-handle = <&pio1>;
+ phy-handle = <&qe_phy0>;
+ phy-connection-type = "mii";
+ };
+
+ mdio@2120 {
+ qe_phy0: ethernet-phy@18 {
+ interrupt-parent = <&mpic>;
+ interrupts = <4 1 0 0>;
+ reg = <0x18>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy1: ethernet-phy@19 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1 0 0>;
+ reg = <0x19>;
+ device_type = "ethernet-phy";
+ };
+ tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet4: ucc@2400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "none";
+ tx-clock-name = "clk13";
+ pio-handle = <&pio2>;
+ phy-handle = <&qe_phy1>;
+ phy-connection-type = "rmii";
+ };
+ };
+};
+
+/include/ "p1025twr.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 8f02b05..fe36689 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -117,6 +117,12 @@ config P1023_RDS
help
This option enables support for the P1023 RDS board
+config TWR_P102x
+ bool "Freescale TWR-P102x"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the TWR-P1025 board.
+
config SOCRATES
bool "Socrates"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 2eab37e..b8d9f66 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_P1010_RDB) += p1010rdb.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1022_RDK) += p1022_rdk.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
+obj-$(CONFIG_TWR_P102x) += twr_p102x.o
obj-$(CONFIG_P2041_RDB) += p2041_rdb.o corenet_ds.o
obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
new file mode 100644
index 0000000..8ba3b25
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright 2010-2011, 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Michael Johnston <michael.johnston@freescale.com>
+ *
+ * Description:
+ * TWR-P102x Board Setup
+ *
+ * This program is free software; you can redistribute it and/or modify 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/init.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+
+#include <asm/pci-bridge.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+#include <asm/qe.h>
+#include <asm/qe_ic.h>
+#include <asm/fsl_guts.h>
+
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+static void __init twr_p1025_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+
+#ifdef CONFIG_QUICC_ENGINE
+ mpc85xx_qe_pic_init();
+#endif
+}
+
+/* ************************************************************************
+ *
+ * Setup the architecture
+ *
+ */
+static void __init twr_p1025_setup_arch(void)
+{
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("twr_p1025_setup_arch()", 0);
+
+ mpc85xx_smp_init();
+
+ fsl_pci_assign_primary();
+
+#ifdef CONFIG_QUICC_ENGINE
+ mpc85xx_qe_init();
+
+#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
+ if (machine_is(twr_p1025)) {
+ struct ccsr_guts __iomem *guts;
+
+ np = of_find_node_by_name(NULL, "global-utilities");
+ if (np) {
+ guts = of_iomap(np, 0);
+ if (!guts)
+ pr_err("twr_p1025: could not map"
+ "global utilities register\n");
+ else {
+ /* P1025 has pins muxed for QE and other functions. To
+ * enable QE UEC mode, we need to set bit QE0 for UCC1
+ * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
+ * and QE12 for QE MII management signals in PMUXCR
+ * register.
+ */
+
+ printk(KERN_INFO "P1025 pinmux configured for QE\n");
+
+ /* Set QE mux bits in PMUXCR */
+ setbits32(&guts->pmuxcr, MPC85xx_PMUXCR_QE(0) |
+ MPC85xx_PMUXCR_QE(3) |
+ MPC85xx_PMUXCR_QE(9) |
+ MPC85xx_PMUXCR_QE(12));
+ iounmap(guts);
+
+#if defined(CONFIG_SERIAL_QE)
+ /* On P1025TWR board, the UCC7 acted as UART port.
+ * However, The UCC7's CTS pin is low level in default,
+ * it will impact the transmission in full duplex
+ * communication. So disable the Flow control pin PA18.
+ * The UCC7 UART just can use RXD and TXD pins.
+ */
+ par_io_config_pin(0, 18, 0, 0, 0, 0);
+#endif
+ /* Drive PB29 to CPLD low - CPLD will then change
+ * muxing from LBC to QE */
+ par_io_config_pin(1, 29, 1, 0, 0, 0);
+ par_io_data_set(1, 29, 0);
+ }
+ of_node_put(np);
+ }
+ }
+#endif
+#endif /* CONFIG_QUICC_ENGINE */
+
+ printk(KERN_INFO "TWR-P1025 board from Freescale Semiconductor\n");
+}
+
+machine_arch_initcall(twr_p1025, mpc85xx_common_publish_devices);
+
+static int __init twr_p1025_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,TWR-P1025");
+}
+
+define_machine(twr_p1025) {
+ .name = "TWR-P1025",
+ .probe = twr_p1025_probe,
+ .setup_arch = twr_p1025_setup_arch,
+ .init_IRQ = twr_p1025_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v2 00/10] Series of fixes for NX driver
From: Herbert Xu @ 2013-09-02 10:35 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: linuxppc-dev, linux-kernel, linux-crypto
In-Reply-To: <1377787000-4966-1-git-send-email-mhcerri@linux.vnet.ibm.com>
On Thu, Aug 29, 2013 at 11:36:30AM -0300, Marcelo Cerri wrote:
> This series of patches contains fixes in several algorithms implemented
> by the NX driver. The patches can be separated in three different
> categories:
>
> - Changes to split the data in several hyper calls to respect the
> limits of data that the co-processador can handle. This affects
> all AES modes.
> - Fixes in how the driver handle zero length messages. This affects
> XCBC and GCM.
> - Fixes for SHA-2 when chunks bigger than the block size are provided.
>
> v2:
> - Fixed conflict.
All applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] Powerpc/dts: Correct sdhci quirk for bsc9131
From: Haijun Zhang @ 2013-09-02 10:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Haijun Zhang, X.Xie
We use property "sdhci,auto-cmd12" instead of "fsl,sdhci-auto-cmd12"
to distinguish if the sdhc host has quirk SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12.
Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com>
---
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
index 5180d9d..0c0efa9 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
@@ -130,7 +130,7 @@ usb@22000 {
/include/ "pq3-esdhc-0.dtsi"
sdhc@2e000 {
- fsl,sdhci-auto-cmd12;
+ sdhci,auto-cmd12;
interrupts = <41 0x2 0 0>;
};
--
1.8.0
^ permalink raw reply related
* [PATCH] [RFC PATCH v1 1/1] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel
From: Yu Chen @ 2013-09-02 22:19 UTC (permalink / raw)
To: galak, wangshilong1991, chenhui.zhao, lu.zhongjun, liu.xiang6
Cc: linuxppc-dev, Chen Yu
From: Chen Yu <chen.yu10@zte.com.cn>
In current 85xx smp kexec implementation,master cpu reset slave cpus by mpic_reset_core,
before jump to second kernel.In order to wake slave cpus up in second kernel,we debug
this patch on p2041rdb.
The main principle of this patch,is to get slave cpus polling for flag to change,
thus waiting for master cpu to set it with non-zero cpu number(see misc_32.S).
This flag is placed in kexec control page,so it would not be overlapped when copying kimage.
The master cpu put flag's physical address in r28 as a parameter passed to second kernel,
so the latter knows how to wake slave cpus up in smp_85xx_kick_cpu.
The pseudo-code may be like:
void slave_cpu_spin(void)
{
int cpu = smp_processor_id();
while (*kexec_poll != cpu)
;
/*slave wakeup and jump*/
jump(*(kexec_poll+1));
}
void master_cpu_wakeup(unsigned long *kexec_poll, int cpu)
{
*(kexec_poll+1) = __early_start;
mb();
*kexec_poll = cpu;
}
However,after applied this patch,we got some kernel exception during booting second kernel,
I'm not sure if it's caused by improper treament of cache,or tlb,or other.So I put this
patch here hoping someone can check and review it.
Signed-off-by: Chen Yu <chen.yu10@zte.com.cn>
---
arch/powerpc/include/asm/kexec.h | 7 ++
arch/powerpc/kernel/head_fsl_booke.S | 6 ++
arch/powerpc/kernel/misc_32.S | 63 +++++++++++++
arch/powerpc/platforms/85xx/smp.c | 162 +++++++++++++++++++++++++++++++---
4 files changed, 224 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 16d7e33..a70f480 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -87,6 +87,13 @@ extern int overlaps_crashkernel(unsigned long start, unsigned long size);
extern void reserve_crashkernel(void);
extern void machine_kexec_mask_interrupts(void);
+#ifdef CONFIG_FSL_BOOKE
+#define KEXEC_MAGIC 0xdeadbeef
+#define KEXEC_RESERVE_LIMIT 0x10
+extern const unsigned int relocate_smp_cpu_size;
+extern const unsigned char relocate_smp_cpu_wait[];
+extern const unsigned int relocate_smp_cpu_offset;
+#endif
#else /* !CONFIG_KEXEC */
static inline void crash_kexec_secondary(struct pt_regs *regs) { }
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index d10a7ca..497f1dc 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -178,6 +178,12 @@ _ENTRY(__early_start)
* This is where the main kernel code starts.
*/
+#if defined(CONFIG_KEXEC) && defined(CONFIG_SMP)
+ /* r28 contain position where slave cpus spin*/
+ lis r1,kexec_poll_phy@h
+ ori r1,r1,kexec_poll_phy@l
+ stw r28,0(r1)
+#endif
/* ptr to current */
lis r2,init_task@h
ori r2,r2,init_task@l
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index e469f30..5562306 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -707,6 +707,16 @@ relocate_new_kernel:
mr r30, r4
mr r31, r5
+#ifdef CONFIG_SMP
+ bl 1f
+1: mflr r8
+ addi r8,r8,kexec_flag-1b
+ lis r7,PAGE_OFFSET@h
+ ori r7,r7,PAGE_OFFSET@l
+ /*r28 contain slave cpu spin physical address */
+ subf r28, r7, r8
+#endif
+
#define ENTRY_MAPPING_KEXEC_SETUP
#include "fsl_booke_entry_mapping.S"
#undef ENTRY_MAPPING_KEXEC_SETUP
@@ -1172,4 +1182,57 @@ relocate_new_kernel_end:
.globl relocate_new_kernel_size
relocate_new_kernel_size:
.long relocate_new_kernel_end - relocate_new_kernel
+#ifdef CONFIG_FSL_BOOKE
+ /**
+ * Slave cpus wait for kexec_flag to change
+ */
+ .globl relocate_smp_cpu_offset
+relocate_smp_cpu_offset:
+ .long relocate_smp_cpu_wait-relocate_new_kernel
+
+ .globl relocate_smp_cpu_wait
+relocate_smp_cpu_wait:
+
+ bl 1f
+1: mflr r5
+ addi r5,r5,kexec_flag-1b
+ /*see if anyone calls me?*/
+ mfspr r24,SPRN_PIR
+99: lwz r4,4(r5)
+ cmpw r4,r24
+ msync
+ bne 99b
+
+ msync
+ /*r4 contains jump address*/
+ lwz r4,8(r5)
+ msync
+ lis r5,MSR_KERNEL@h
+ ori r5,r5,MSR_KERNEL@l
+ msync
+ isync
+ mtspr SPRN_SRR1, r5
+ mtspr SPRN_SRR0, r4
+ msync
+ isync
+ rfi
+ isync
+1: b 1b
+
+ /**
+ * kexec_flag indicates a kexec magic
+ * kexec_flag+4 bytes supposed to be set with cpu number
+ * kexec_flag+8 countain addr for slave cpu to jump into
+ */
+ .globl kexec_flag
+kexec_flag:
+ .long KEXEC_MAGIC
+ .long 0
+ .long 0
+relocate_smp_cpu_wait_end:
+ .globl relocate_smp_cpu_size
+relocate_smp_cpu_size:
+ .long relocate_smp_cpu_wait_end-relocate_smp_cpu_wait
+#endif
+
#endif
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 6a17599..4dc8366 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -141,6 +141,73 @@ static inline u32 read_spin_table_addr_l(void *spin_table)
return in_be32(&((struct epapr_spin_table *)spin_table)->addr_l);
}
+#ifdef CONFIG_KEXEC
+
+unsigned long kexec_poll_phy __init_task_data;
+
+void reserve_kexec_bootmem(unsigned long poll_phy, int size)
+{
+ ;/*fixme*/
+}
+
+/*
+ * Reserved bootmem for slave cpus kexec spin area.
+ */
+void mpc85xx_smp_reserve_kexec(void)
+{
+ unsigned long kexec_poll_virt;
+ unsigned long *kexec_magic_virt;
+
+ if (!kexec_poll_phy ||
+ kexec_poll_phy >= __max_low_memory)
+ return;
+
+ kexec_poll_virt = (unsigned long)phys_to_virt(kexec_poll_phy);
+ kexec_magic_virt = (unsigned long *)kexec_poll_virt;
+
+ if (*kexec_magic_virt == KEXEC_MAGIC)
+ reserve_kexec_bootmem(kexec_poll_phy, KEXEC_RESERVE_LIMIT);
+}
+
+/*
+ * Kick slave cpus from kexec spin area.
+ */
+int mpc85xx_smp_kick_kexec_cpus(int nr)
+{
+ unsigned long kexec_poll_virt;
+ unsigned long *kexec_flag_virt;
+ unsigned long *kexec_magic_virt;
+ unsigned long *kexec_jump_virt;
+
+ /*verify accessible*/
+ if (!kexec_poll_phy ||
+ kexec_poll_phy >= __max_low_memory)
+ return -EBUSY;
+
+ kexec_poll_virt = (unsigned long)phys_to_virt(kexec_poll_phy);
+
+ kexec_magic_virt = (unsigned long *)kexec_poll_virt;
+ kexec_flag_virt = (unsigned long *)kexec_poll_virt + 1;
+ kexec_jump_virt = (unsigned long *)kexec_poll_virt + 2;
+
+ /*verify a valid kexec kick*/
+ if (*kexec_magic_virt == KEXEC_MAGIC) {
+ flush_dcache_range((ulong)kexec_poll_virt,
+ (ulong)kexec_poll_virt + L1_CACHE_BYTES-1);
+ *kexec_jump_virt = (unsigned long)__early_start;
+ mb();
+ /*kick cpu[nr] up*/
+ *kexec_flag_virt = nr;
+ mb();
+ flush_dcache_range((ulong)kexec_poll_virt,
+ (ulong)kexec_poll_virt + L1_CACHE_BYTES-1);
+
+ return 0;
+ }
+ return -EBUSY;
+}
+#endif
+
static int __cpuinit smp_85xx_kick_cpu(int nr)
{
unsigned long flags;
@@ -181,6 +248,10 @@ static int __cpuinit smp_85xx_kick_cpu(int nr)
local_irq_save(flags);
#ifdef CONFIG_PPC32
+#ifdef CONFIG_KEXEC
+ if (!mpc85xx_smp_kick_kexec_cpus(nr))
+ goto kexec_kick_done;
+#endif
#ifdef CONFIG_HOTPLUG_CPU
/* Corresponding to generic_set_cpu_dead() */
generic_set_cpu_up(nr);
@@ -226,6 +297,9 @@ static int __cpuinit smp_85xx_kick_cpu(int nr)
out_be32(&spin_table->addr_l, __pa(__early_start));
flush_spin_table(spin_table);
+#ifdef CONFIG_KEXEC
+kexec_kick_done:
+#endif
/* Wait a bit for the CPU to ack. */
if (!spin_event_timeout(__secondary_hold_acknowledge == hw_cpu,
10000, 100)) {
@@ -267,6 +341,10 @@ struct smp_ops_t smp_85xx_ops = {
#ifdef CONFIG_KEXEC
atomic_t kexec_down_cpus = ATOMIC_INIT(0);
+atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
+atomic_t kexec_slave_finish = ATOMIC_INIT(0);
+unsigned long wait_code_buffer;
+static struct kimage *save_image;
void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
{
@@ -274,8 +352,29 @@ void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
if (secondary) {
atomic_inc(&kexec_down_cpus);
- /* loop forever */
- while (1);
+ mb();
+
+ if (crash_shutdown) {
+ /* loop forever */
+ while (1)
+ ;
+ } else {
+ while (!atomic_read(&kexec_ready_to_reboot))
+ cpu_relax();
+ /*flush destination*/
+ if (save_image)
+ mpc85xx_smp_flush_dcache_kexec(save_image, 1);
+
+ flush_icache_range(wait_code_buffer,
+ wait_code_buffer + relocate_smp_cpu_size);
+ flush_dcache_range(wait_code_buffer,
+ wait_code_buffer + relocate_smp_cpu_size);
+
+ atomic_inc(&kexec_slave_finish);
+
+ ((void (*)(void)) wait_code_buffer)();
+ /* NOTREACHED */
+ }
}
}
@@ -285,13 +384,23 @@ static void mpc85xx_smp_kexec_down(void *arg)
ppc_md.kexec_cpu_down(0,1);
}
-static void map_and_flush(unsigned long paddr)
+static void map_and_flush(unsigned long paddr, int atomic)
{
struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
- unsigned long kaddr = (unsigned long)kmap(page);
+ unsigned long kaddr;
+
+ if (atomic)
+ kaddr = (unsigned long)kmap_atomic(page);
+ else
+ kaddr = (unsigned long)kmap(page);
flush_dcache_range(kaddr, kaddr + PAGE_SIZE);
- kunmap(page);
+ flush_icache_range(kaddr, kaddr + PAGE_SIZE);
+
+ if (atomic)
+ kunmap_atomic((void *)kaddr);
+ else
+ kunmap(page);
}
/**
@@ -312,18 +421,18 @@ static void mpc85xx_smp_flush_dcache_kexec(struct kimage *image)
ptr = (entry & IND_INDIRECTION) ?
phys_to_virt(entry & PAGE_MASK) : ptr + 1) {
if (!(entry & IND_DESTINATION)) {
- map_and_flush(entry);
+ map_and_flush(entry, atomic);
}
}
/* flush out last IND_DONE page */
- map_and_flush(entry);
+ map_and_flush(entry, atomic);
} else {
/* crash type kexec images are copied to the crash region */
for (i = 0; i < image->nr_segments; i++) {
struct kexec_segment *seg = &image->segment[i];
for (paddr = seg->mem; paddr < seg->mem + seg->memsz;
paddr += PAGE_SIZE) {
- map_and_flush(paddr);
+ map_and_flush(paddr, atomic);
}
}
}
@@ -340,8 +449,11 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
mpc85xx_smp_flush_dcache_kexec(image);
- if (image->type == KEXEC_TYPE_DEFAULT)
+ if (image->type == KEXEC_TYPE_DEFAULT) {
+ save_image = image;
+ mb();
smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
+ }
while ( (atomic_read(&kexec_down_cpus) != (num_cpus - 1)) &&
( timeout > 0 ) )
@@ -352,12 +464,34 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
if ( !timeout )
printk(KERN_ERR "Unable to bring down secondary cpu(s)");
- for_each_online_cpu(i)
- {
- if ( i == smp_processor_id() ) continue;
- mpic_reset_core(i);
- }
+ if (image->type == KEXEC_TYPE_DEFAULT) {
+ wait_code_buffer =
+ (unsigned long)page_address(image->control_code_page)+
+ relocate_smp_cpu_offset;
+
+ /* copy slave cpu spin code to the control code page */
+ memcpy((void *)wait_code_buffer, relocate_smp_cpu_wait,
+ relocate_smp_cpu_size);
+ atomic_set(&kexec_ready_to_reboot, 1);
+ mb();
+ timeout = INT_MAX;
+
+ while ((atomic_read(&kexec_slave_finish) != (num_cpus-1)) &&
+ (timeout > 0))
+ timeout--;
+
+ if (!timeout)
+ pr_err("Unable to wait for secondary cpu(s) to flush caches\n");
+
+ } else {
+ for_each_online_cpu(i)
+ {
+ if (i == smp_processor_id())
+ continue;
+ mpic_reset_core(i);
+ }
+ }
default_machine_kexec(image);
}
#endif /* CONFIG_KEXEC */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Vladimir Murzin @ 2013-09-02 17:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dborkman, paulus, davem
In-Reply-To: <1377643792-10327-1-git-send-email-murzin.v@gmail.com>
Ping
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.
>
> This patch brings JIT support for PPC64
>
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> 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 %= X; */
> + ctx->seen |= SEEN_XREG;
> + PPC_CMPWI(r_X, 0);
> + if (ctx->pc_ret0 != -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;
> + case BPF_S_ALU_MOD_K: /* A %= 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;
> case BPF_S_ALU_DIV_X: /* A /= X; */
> ctx->seen |= SEEN_XREG;
> PPC_CMPWI(r_X, 0);
> --
> 1.8.1.5
>
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Benjamin Herrenschmidt @ 2013-09-02 20:45 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: paulus, dborkman, linuxppc-dev, davem, Matt Evans
In-Reply-To: <20130902174842.GA1866@hp530>
On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
> Ping
>
> 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.
> >
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.
Do you have a test case/suite by any chance ?
Ben.
> > This patch brings JIT support for PPC64
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> > ---
> > arch/powerpc/net/bpf_jit_comp.c | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > 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 %= X; */
> > + ctx->seen |= SEEN_XREG;
> > + PPC_CMPWI(r_X, 0);
> > + if (ctx->pc_ret0 != -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;
> > + case BPF_S_ALU_MOD_K: /* A %= 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;
> > case BPF_S_ALU_DIV_X: /* A /= X; */
> > ctx->seen |= SEEN_XREG;
> > PPC_CMPWI(r_X, 0);
> > --
> > 1.8.1.5
> >
^ permalink raw reply
* Re: [PATCH] iommu: WARN_ON when removing a device with no iommu_group associated
From: Wei Yang @ 2013-09-03 3:15 UTC (permalink / raw)
To: Alex Williamson
Cc: Wei Yang, benh, aik, linux-kernel, iommu, paulus, linuxppc-dev
In-Reply-To: <1377228807.25163.33.camel@ul30vt.home>
Any more comments? Or this one is not proper?
On Thu, Aug 22, 2013 at 09:33:27PM -0600, Alex Williamson wrote:
>[+cc iommu]
>
>On Fri, 2013-08-23 at 09:55 +0800, Wei Yang wrote:
>> When removing a device from the system, iommu_group driver will try to
>> disconnect it from its group. While in some cases, one device may not
>> associated with any iommu_group. For example, not enough DMA address space.
>>
>> In the generic bus notification, it will check dev->iommu_group before calling
>> iommu_group_remove_device(). While in some cases, developers may call
>> iommu_group_remove_device() in a different code path and without check. For
>> those devices with dev->iommu_group set to NULL, kernel will crash.
>>
>> This patch gives a warning and return when trying to remove a device from an
>> iommu_group with dev->iommu_group set to NULL. This helps to indicate some bad
>> behavior and also guard the kernel.
>>
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>
>Acked-by: Alex Williamson <alex.williamson@redhat.com>
>
>> ---
>> drivers/iommu/iommu.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index fbe9ca7..43396f0 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -379,6 +379,9 @@ void iommu_group_remove_device(struct device *dev)
>> struct iommu_group *group = dev->iommu_group;
>> struct iommu_device *tmp_device, *device = NULL;
>>
>> + if (WARN_ON(!group))
>> + return;
>> +
>> /* Pre-notify listeners that a device is being removed. */
>> blocking_notifier_call_chain(&group->notifier,
>> IOMMU_GROUP_NOTIFY_DEL_DEVICE, dev);
>
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
From: Yijing Wang @ 2013-09-03 7:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Gavin Shan, Bjorn Helgaas,
James E.J. Bottomley, David S. Miller
Cc: linux-pci, linux-kernel, Paul Mackerras, Hanjun Guo, Yijing Wang,
linuxppc-dev
In-Reply-To: <1378193715-25328-1-git-send-email-wangyijing@huawei.com>
Use pci_is_pcie() to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/powerpc/kernel/eeh.c | 3 +--
arch/powerpc/sysdev/fsl_pci.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 39954fe..b0bd41a 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev, char * buf, size_t len)
}
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
- cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
- if (cap) {
+ if (pci_is_pcie(dev)) {
n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
printk(KERN_WARNING
"EEH: PCI-E capabilities and status follow:\n");
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5402a1d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
u8 hdr_type;
/* if we aren't a PCIe don't bother */
- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+ if (!pci_is_pcie(dev))
return;
/* if we aren't in host mode don't bother */
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao @ 2013-09-03 7:51 UTC (permalink / raw)
To: linuxppc-dev, B07421; +Cc: b38951
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
---
arch/powerpc/boot/dts/b4qds.dtsi | 4 ++++
arch/powerpc/boot/dts/t4240qds.dts | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..2aa3399 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,6 +120,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@50 {
compatible = "at24,24c64";
reg = <0x50>;
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..084db57 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,6 +118,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@51 {
compatible = "at24,24c256";
reg = <0x51>;
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang @ 2013-09-03 9:01 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
djbw@fb.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130902155636.GA18206@e106331-lin.cambridge.arm.com>
On 09/02/2013 11:58 PM, Mark Rutland wrote:
> Hi,
>
> On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
>> the device tree nodes for them.
>>
>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>> ---
>> .../devicetree/bindings/powerpc/fsl/dma.txt | 67 ++++++++++++++++
>> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
>> arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 ++++++++++++++++++++
>> arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 ++++++++++++++++++++
>> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
>> 5 files changed, 235 insertions(+), 4 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>> index ddf17af..332ac77 100644
>> --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>> @@ -126,6 +126,73 @@ Example:
>> };
>> };
>>
>> +** Freescale Elo3 DMA Controller
>> + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
> I was under the impression EloPlus was the previous revision. Should
> that say Elo3, or is Elo3 considered to be an EloPlus implementation?
In this patch 1/3 I revise the doc to make it clear we have Elo and
EloPlus, and I'm adding another new Elo3. Yes the only difference
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels),
so we can call "Elo3 is an 8-channel EloPlus"
>> + series chips, such as t1040, t4240, b4860.
>> +
>> +Required properties:
>> +
>> +- compatible : must include "fsl,elo3-dma"
>> +- reg : <registers specifier for DMA general status reg>
> The example has two reg entries. What both are should be specified. From
> what you described last time, it sounds like each is a status register
> for four channels.
>
> Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
> the second covers the channels at 0x300,0x380,0x400,0x480? If the
> registers have specific names in a datasheet, it would be worth
> mentioning them.
Yes, each is a status register for four channels, you got it -- this
means my statement works.
Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies can
cover tens even hundreds of registers, just a summary is OK I think.
> If the specification of the DMA controller allows for more channels, it
> may be worth describing that case now.
This DMA controller doesn't allows for more channels. (Even if it does,
it should be another new controller)
>> +- ranges : describes the mapping between the address space of the
>> + DMA channels and the address space of the DMA controller
> This looks odd as a required property, and I'm slightly confused. Is
> this used to map the reg values of the DMA channels, or is it used when
> mapping the DMA address space (for which dma-ranges exists in ePAPR and
> other bindings).
It is used to map the reg values of DMA channels.
>> +
>> +- DMA channel nodes:
>> + - compatible : must include "fsl,eloplus-dma-channel"
>> + - reg : <registers specifier for channel>
> What does this represent? What are valid values?
>
> In the example below it looks like these are offsets of control
> registers within the dma controller.
Yes, they are offsets of control registers within dma controller, but
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers,
they are in one continuous physical address space, we divide all these
registers into two controller/channel parts, according to contents in
these registers, common status registers for all channels are called dma
controller registers, otherwise channel specific registers are called
dma channel registers.
> If the reg property may have any value, how do they get mapped to bits
> in the status register(s)?
In fact, each channel has its own status register(and also other
registers), the dma controller status register is just aggregation of
all channel status register. (that seems duplicated somehow, maybe this
is due to hardware compatibility with legacy one, and the device tree
just describes the physical hardware without lie)
> May some channels be unusable for some reason, or will all eight
> channels be wired on any given Elo3 DMA?
Sorry, not get your point clearly, maybe you are clear now because of my
previous explanations.
> Cheers,
> Mark.
>
>> + - interrupts : <interrupt specifier for DMA channel IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> +
>> +Example:
>> +dma@100300 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,elo3-dma";
>> + reg = <0x100300 0x4>,
>> + <0x100600 0x4>;
>> + ranges = <0x0 0x100100 0x500>;
>> + dma-channel@0 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x0 0x80>;
>> + interrupts = <28 2 0 0>;
>> + };
>> + dma-channel@80 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x80 0x80>;
>> + interrupts = <29 2 0 0>;
>> + };
>> + dma-channel@100 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x100 0x80>;
>> + interrupts = <30 2 0 0>;
>> + };
>> + dma-channel@180 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x180 0x80>;
>> + interrupts = <31 2 0 0>;
>> + };
>> + dma-channel@300 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x300 0x80>;
>> + interrupts = <76 2 0 0>;
>> + };
>> + dma-channel@380 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x380 0x80>;
>> + interrupts = <77 2 0 0>;
>> + };
>> + dma-channel@400 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x400 0x80>;
>> + interrupts = <78 2 0 0>;
>> + };
>> + dma-channel@480 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x480 0x80>;
>> + interrupts = <79 2 0 0>;
>> + };
>> +};
>> +
>> Note on DMA channel compatible properties: The compatible property must say
>> "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
>> driver (fsldma). Any DMA channel used by fsldma cannot be used by another
>> diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
>> index 7399154..ea53ea1 100644
>> --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
>> +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
>> @@ -223,13 +223,13 @@
>> reg = <0xe2000 0x1000>;
>> };
>>
>> -/include/ "qoriq-dma-0.dtsi"
>> +/include/ "elo3-dma-0.dtsi"
>> dma@100300 {
>> fsl,iommu-parent = <&pamu0>;
>> fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
>> };
>>
>> -/include/ "qoriq-dma-1.dtsi"
>> +/include/ "elo3-dma-1.dtsi"
>> dma@101300 {
>> fsl,iommu-parent = <&pamu0>;
>> fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
>> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>> new file mode 100644
>> index 0000000..3c210e0
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>> @@ -0,0 +1,82 @@
>> +/*
>> + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x100000 ]
>> + *
>> + * 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 copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * * Neither the name of Freescale Semiconductor nor the
>> + * names of its contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>> + * 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 CAUSED AND
>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +dma0: dma@100300 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,elo3-dma";
>> + reg = <0x100300 0x4>,
>> + <0x100600 0x4>;
>> + ranges = <0x0 0x100100 0x500>;
>> + dma-channel@0 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x0 0x80>;
>> + interrupts = <28 2 0 0>;
>> + };
>> + dma-channel@80 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x80 0x80>;
>> + interrupts = <29 2 0 0>;
>> + };
>> + dma-channel@100 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x100 0x80>;
>> + interrupts = <30 2 0 0>;
>> + };
>> + dma-channel@180 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x180 0x80>;
>> + interrupts = <31 2 0 0>;
>> + };
>> + dma-channel@300 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x300 0x80>;
>> + interrupts = <76 2 0 0>;
>> + };
>> + dma-channel@380 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x380 0x80>;
>> + interrupts = <77 2 0 0>;
>> + };
>> + dma-channel@400 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x400 0x80>;
>> + interrupts = <78 2 0 0>;
>> + };
>> + dma-channel@480 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x480 0x80>;
>> + interrupts = <79 2 0 0>;
>> + };
>> +};
>> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>> new file mode 100644
>> index 0000000..cccf3bb
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>> @@ -0,0 +1,82 @@
>> +/*
>> + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x101000 ]
>> + *
>> + * 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 copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * * Neither the name of Freescale Semiconductor nor the
>> + * names of its contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>> + * 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 CAUSED AND
>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +dma1: dma@101300 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,elo3-dma";
>> + reg = <0x101300 0x4>,
>> + <0x101600 0x4>;
>> + ranges = <0x0 0x101100 0x500>;
>> + dma-channel@0 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x0 0x80>;
>> + interrupts = <32 2 0 0>;
>> + };
>> + dma-channel@80 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x80 0x80>;
>> + interrupts = <33 2 0 0>;
>> + };
>> + dma-channel@100 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x100 0x80>;
>> + interrupts = <34 2 0 0>;
>> + };
>> + dma-channel@180 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x180 0x80>;
>> + interrupts = <35 2 0 0>;
>> + };
>> + dma-channel@300 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x300 0x80>;
>> + interrupts = <80 2 0 0>;
>> + };
>> + dma-channel@380 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x380 0x80>;
>> + interrupts = <81 2 0 0>;
>> + };
>> + dma-channel@400 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x400 0x80>;
>> + interrupts = <82 2 0 0>;
>> + };
>> + dma-channel@480 {
>> + compatible = "fsl,eloplus-dma-channel";
>> + reg = <0x480 0x80>;
>> + interrupts = <83 2 0 0>;
>> + };
>> +};
>> diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>> index bd611a9..ec95c60 100644
>> --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>> @@ -387,8 +387,8 @@
>> reg = <0xea000 0x4000>;
>> };
>>
>> -/include/ "qoriq-dma-0.dtsi"
>> -/include/ "qoriq-dma-1.dtsi"
>> +/include/ "elo3-dma-0.dtsi"
>> +/include/ "elo3-dma-1.dtsi"
>>
>> /include/ "qoriq-espi-0.dtsi"
>> spi@110000 {
>> --
>> 1.7.9.5
>>
>>
>>
>>
^ permalink raw reply
* [PATCH] powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
From: Shengzhou Liu @ 2013-09-03 8:28 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Shengzhou Liu
Enable CONFIG_AT803X_PHY to support AR8030/8033/8035 PHY.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 60027c2..ccb9d12 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -103,6 +103,7 @@ CONFIG_FSL_PQ_MDIO=y
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_VITESSE_PHY=y
+CONFIG_AT803X_PHY=y
CONFIG_FIXED_PHY=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 5a58882..2ddbba5 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -136,6 +136,7 @@ CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
+CONFIG_AT803X_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_MOUSEDEV is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 152fa05..b08ba94 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -136,6 +136,7 @@ CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
+CONFIG_AT803X_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_MOUSEDEV is not set
--
1.7.0.4
^ permalink raw reply related
* [PATCH] powerpc: xmon: Fix printing of set of CPUs in xmon
From: Paul Mackerras @ 2013-09-03 10:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: anton
Commit 24ec2125f3 ("powerpc/xmon: Use cpumask iterator to avoid warning")
replaced a loop from 0 to NR_CPUS-1 with a for_each_possible_cpu() loop,
which means that if the last possible cpu is in xmon, we print the
wrong value for the end of the range. For example, if 4 cpus are
possible, NR_CPUS is 128, and all cpus are in xmon, we print "0-7f"
rather than "0-3". The code also assumes that the set of possible
cpus is contiguous, which may not necessarily be true.
This fixes the code to check explicitly for contiguity, and to print
the ending value correctly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/xmon/xmon.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 1fcdc2e..a7f176c 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -972,27 +972,27 @@ static void bootcmds(void)
static int cpu_cmd(void)
{
#ifdef CONFIG_SMP
- unsigned long cpu;
+ unsigned long cpu, first_cpu, last_cpu;
int timeout;
- int count;
if (!scanhex(&cpu)) {
/* print cpus waiting or in xmon */
printf("cpus stopped:");
- count = 0;
+ last_cpu = first_cpu = NR_CPUS;
for_each_possible_cpu(cpu) {
if (cpumask_test_cpu(cpu, &cpus_in_xmon)) {
- if (count == 0)
- printf(" %x", cpu);
- ++count;
- } else {
- if (count > 1)
- printf("-%x", cpu - 1);
- count = 0;
+ if (cpu == last_cpu + 1) {
+ last_cpu = cpu;
+ } else {
+ if (last_cpu != first_cpu)
+ printf("-%lx", last_cpu);
+ last_cpu = first_cpu = cpu;
+ printf(" %lx", cpu);
+ }
}
}
- if (count > 1)
- printf("-%x", NR_CPUS - 1);
+ if (last_cpu != first_cpu)
+ printf("-%lx", last_cpu);
printf("\n");
return 0;
}
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Gleb Natapov @ 2013-09-03 10:53 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, linux-mm,
Paul Mackerras, Paolo Bonzini, linuxppc-dev, David Gibson
In-Reply-To: <52240295.7050608@ozlabs.ru>
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
> >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
> >> them to user space which saves time on switching to user space and back.
> >>
> >> Both real and virtual modes are supported. The kernel tries to
> >> handle a TCE request in the real mode, if fails it passes the request
> >> to the virtual mode to complete the operation. If it a virtual mode
> >> handler fails, the request is passed to user space.
> >>
> >> The first user of this is VFIO on POWER. Trampolines to the VFIO external
> >> user API functions are required for this patch.
> >>
> >> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
> >> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
> >> of map/unmap requests. The device supports a single attribute which is
> >> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
> >> establishes the connection between KVM and VFIO.
> >>
> >> Tests show that this patch increases transmission speed from 220MB/s
> >> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
> >>
> >> Signed-off-by: Paul Mackerras <paulus@samba.org>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>
> >> ---
> >>
> >> Changes:
> >> v9:
> >> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
> >> KVM device
> >> * release_spapr_tce_table() is not shared between different TCE types
> >> * reduced the patch size by moving VFIO external API
> >> trampolines to separate patche
> >> * moved documentation from Documentation/virtual/kvm/api.txt to
> >> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>
> >> v8:
> >> * fixed warnings from check_patch.pl
> >>
> >> 2013/07/11:
> >> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
> >> for KVM_BOOK3S_64
> >> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
> >> for this here but the next patch for hugepages support will use it more.
> >>
> >> 2013/07/06:
> >> * added realmode arch_spin_lock to protect TCE table from races
> >> in real and virtual modes
> >> * POWERPC IOMMU API is changed to support real mode
> >> * iommu_take_ownership and iommu_release_ownership are protected by
> >> iommu_table's locks
> >> * VFIO external user API use rewritten
> >> * multiple small fixes
> >>
> >> 2013/06/27:
> >> * tce_list page is referenced now in order to protect it from accident
> >> invalidation during H_PUT_TCE_INDIRECT execution
> >> * added use of the external user VFIO API
> >>
> >> 2013/06/05:
> >> * changed capability number
> >> * changed ioctl number
> >> * update the doc article number
> >>
> >> 2013/05/20:
> >> * removed get_user() from real mode handlers
> >> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
> >> translated TCEs, tries realmode_get_page() on those and if it fails, it
> >> passes control over the virtual mode handler which tries to finish
> >> the request handling
> >> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
> >> on a page
> >> * The only reason to pass the request to user mode now is when the user mode
> >> did not register TCE table in the kernel, in all other cases the virtual mode
> >> handler is expected to do the job
> >> ---
> >> .../virtual/kvm/devices/spapr_tce_iommu.txt | 37 +++
> >> arch/powerpc/include/asm/kvm_host.h | 4 +
> >> arch/powerpc/kvm/book3s_64_vio.c | 310 ++++++++++++++++++++-
> >> arch/powerpc/kvm/book3s_64_vio_hv.c | 122 ++++++++
> >> arch/powerpc/kvm/powerpc.c | 1 +
> >> include/linux/kvm_host.h | 1 +
> >> virt/kvm/kvm_main.c | 5 +
> >> 7 files changed, 477 insertions(+), 3 deletions(-)
> >> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>
> >> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >> new file mode 100644
> >> index 0000000..4bc8fc3
> >> --- /dev/null
> >> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >> @@ -0,0 +1,37 @@
> >> +SPAPR TCE IOMMU device
> >> +
> >> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
> >> +Architectures: powerpc
> >> +
> >> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
> >> +
> >> +Groups:
> >> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
> >> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
> >> +
> >> +This is completely made up device which provides API to link
> >> +logical bus number (LIOBN) and IOMMU group. The user space has
> >> +to create a new SPAPR TCE IOMMU device per a logical bus.
> >> +
> > Why not have one device that can handle multimple links?
>
>
> I can do that. If I make it so, it won't even look as a device at all, just
> some weird interface to KVM but ok. What bothers me is it is just a
May be I do not understand usage pattern here. Why do you feel that device
that can handle multiple links is worse than device per link? How many logical
buses is there usually? How often they created/destroyed? I am not insisting
on the change, just trying to understand why you do not like it.
> question what I will have to do next. Because I can easily predict a
> suggestion to move kvmppc_spapr_tce_table's (a links list) from
> kvm->arch.spapr_tce_tables to that device but I cannot do that for obvious
> compatibility reasons caused by the fact that the list is already used for
> emulated devices (for the starter - they need mmap()).
>
> Or supporting all IOMMU links (and leaving emulated stuff as is) in on
> "device" is the last thing I have to do and then you'll ack the patch?
>
I am concerned more about API here. Internal implementation details I
leave to powerpc experts :)
>
>
> >> +LIOBN is a PCI bus identifier from PPC64-server (sPAPR) DMA hypercalls
> >> +(H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE).
> >> +IOMMU group is a minimal isolated device set which can be passed to
> >> +the user space via VFIO.
> >> +
> >> +Right after creation the device is in uninitlized state and requires
> >> +a KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE attribute to be set.
> >> +The attribute contains liobn, IOMMU fd and flags:
> >> +
> >> +struct kvm_create_spapr_tce_iommu_linkage {
> >> + __u64 liobn;
> >> + __u32 fd;
> >> + __u32 flags;
> >> +};
> >> +
> >> +The user space creates the SPAPR TCE IOMMU device, obtains
> >> +an IOMMU fd via VFIO ABI and sets the attribute to the SPAPR TCE IOMMU
> >> +device. At the moment of setting the attribute, the SPAPR TCE IOMMU
> >> +device links LIOBN to IOMMU group and makes necessary steps
> >> +to make sure that VFIO group will not disappear before KVM destroys.
> >> +
> >> +The kernel advertises this feature via KVM_CAP_SPAPR_TCE_IOMMU capability.
> > [skip]
>
> Yes, I read the other comment. So roughly speaking I'll replace the
> KVM_CAP_SPAPR_TCE_IOMMU check with the KVM_CAP_DEVICE_CTRL capability check
> + try to KVM_CREATE_DEVICE with the KVM_CREATE_DEVICE_TEST flag set, and we
> are fine.
Yes, but KVM_CREATE_DEVICE_TEST does not create device, only checks if
device type is supported.
--
Gleb.
^ permalink raw reply
* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Alexey Kardashevskiy @ 2013-09-03 16:01 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, linux-mm,
Paul Mackerras, Paolo Bonzini, linuxppc-dev, David Gibson
In-Reply-To: <20130903105315.GY22899@redhat.com>
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
> On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
>> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
>>>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>>>> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
>>>> them to user space which saves time on switching to user space and back.
>>>>
>>>> Both real and virtual modes are supported. The kernel tries to
>>>> handle a TCE request in the real mode, if fails it passes the request
>>>> to the virtual mode to complete the operation. If it a virtual mode
>>>> handler fails, the request is passed to user space.
>>>>
>>>> The first user of this is VFIO on POWER. Trampolines to the VFIO external
>>>> user API functions are required for this patch.
>>>>
>>>> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
>>>> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
>>>> of map/unmap requests. The device supports a single attribute which is
>>>> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
>>>> establishes the connection between KVM and VFIO.
>>>>
>>>> Tests show that this patch increases transmission speed from 220MB/s
>>>> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>>>>
>>>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>
>>>> ---
>>>>
>>>> Changes:
>>>> v9:
>>>> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
>>>> KVM device
>>>> * release_spapr_tce_table() is not shared between different TCE types
>>>> * reduced the patch size by moving VFIO external API
>>>> trampolines to separate patche
>>>> * moved documentation from Documentation/virtual/kvm/api.txt to
>>>> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>
>>>> v8:
>>>> * fixed warnings from check_patch.pl
>>>>
>>>> 2013/07/11:
>>>> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
>>>> for KVM_BOOK3S_64
>>>> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
>>>> for this here but the next patch for hugepages support will use it more.
>>>>
>>>> 2013/07/06:
>>>> * added realmode arch_spin_lock to protect TCE table from races
>>>> in real and virtual modes
>>>> * POWERPC IOMMU API is changed to support real mode
>>>> * iommu_take_ownership and iommu_release_ownership are protected by
>>>> iommu_table's locks
>>>> * VFIO external user API use rewritten
>>>> * multiple small fixes
>>>>
>>>> 2013/06/27:
>>>> * tce_list page is referenced now in order to protect it from accident
>>>> invalidation during H_PUT_TCE_INDIRECT execution
>>>> * added use of the external user VFIO API
>>>>
>>>> 2013/06/05:
>>>> * changed capability number
>>>> * changed ioctl number
>>>> * update the doc article number
>>>>
>>>> 2013/05/20:
>>>> * removed get_user() from real mode handlers
>>>> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
>>>> translated TCEs, tries realmode_get_page() on those and if it fails, it
>>>> passes control over the virtual mode handler which tries to finish
>>>> the request handling
>>>> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
>>>> on a page
>>>> * The only reason to pass the request to user mode now is when the user mode
>>>> did not register TCE table in the kernel, in all other cases the virtual mode
>>>> handler is expected to do the job
>>>> ---
>>>> .../virtual/kvm/devices/spapr_tce_iommu.txt | 37 +++
>>>> arch/powerpc/include/asm/kvm_host.h | 4 +
>>>> arch/powerpc/kvm/book3s_64_vio.c | 310 ++++++++++++++++++++-
>>>> arch/powerpc/kvm/book3s_64_vio_hv.c | 122 ++++++++
>>>> arch/powerpc/kvm/powerpc.c | 1 +
>>>> include/linux/kvm_host.h | 1 +
>>>> virt/kvm/kvm_main.c | 5 +
>>>> 7 files changed, 477 insertions(+), 3 deletions(-)
>>>> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>
>>>> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>> new file mode 100644
>>>> index 0000000..4bc8fc3
>>>> --- /dev/null
>>>> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>> @@ -0,0 +1,37 @@
>>>> +SPAPR TCE IOMMU device
>>>> +
>>>> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
>>>> +Architectures: powerpc
>>>> +
>>>> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
>>>> +
>>>> +Groups:
>>>> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
>>>> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
>>>> +
>>>> +This is completely made up device which provides API to link
>>>> +logical bus number (LIOBN) and IOMMU group. The user space has
>>>> +to create a new SPAPR TCE IOMMU device per a logical bus.
>>>> +
>>> Why not have one device that can handle multimple links?
>>
>>
>> I can do that. If I make it so, it won't even look as a device at all, just
>> some weird interface to KVM but ok. What bothers me is it is just a
> May be I do not understand usage pattern here. Why do you feel that device
> that can handle multiple links is worse than device per link? How many logical
> buses is there usually? How often they created/destroyed? I am not insisting
> on the change, just trying to understand why you do not like it.
Is it usually one PCI host bus adapter per IOMMU group which is usually
one PCI card or 2-3 cards if it is a legacy PCI-X, and they are created
when QEMU-KVM starts. Not many. And they live till KVM ends.
My point is why would I want to put all links to one device? It all is just
a matter of taste and nothing more. Or I am missing something but I do not
see what. If it is all about making thing to be kosher/halal/orthodox, then
I have more stuff to do, like reworking the emulated TCEs. But if is it for
(I do not know, just guessing) performance or something like that - then
I'll fix it, I just need to know what I am fixing.
>> question what I will have to do next. Because I can easily predict a
>> suggestion to move kvmppc_spapr_tce_table's (a links list) from
>> kvm->arch.spapr_tce_tables to that device but I cannot do that for obvious
>> compatibility reasons caused by the fact that the list is already used for
>> emulated devices (for the starter - they need mmap()).
>>
>> Or supporting all IOMMU links (and leaving emulated stuff as is) in on
>> "device" is the last thing I have to do and then you'll ack the patch?
>>
> I am concerned more about API here. Internal implementation details I
> leave to powerpc experts :)
The Expert (Ben) wants capabilities number and API to get fixed in KVM tree :)
>
>>
>>
>>>> +LIOBN is a PCI bus identifier from PPC64-server (sPAPR) DMA hypercalls
>>>> +(H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE).
>>>> +IOMMU group is a minimal isolated device set which can be passed to
>>>> +the user space via VFIO.
>>>> +
>>>> +Right after creation the device is in uninitlized state and requires
>>>> +a KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE attribute to be set.
>>>> +The attribute contains liobn, IOMMU fd and flags:
>>>> +
>>>> +struct kvm_create_spapr_tce_iommu_linkage {
>>>> + __u64 liobn;
>>>> + __u32 fd;
>>>> + __u32 flags;
>>>> +};
>>>> +
>>>> +The user space creates the SPAPR TCE IOMMU device, obtains
>>>> +an IOMMU fd via VFIO ABI and sets the attribute to the SPAPR TCE IOMMU
>>>> +device. At the moment of setting the attribute, the SPAPR TCE IOMMU
>>>> +device links LIOBN to IOMMU group and makes necessary steps
>>>> +to make sure that VFIO group will not disappear before KVM destroys.
>>>> +
>>>> +The kernel advertises this feature via KVM_CAP_SPAPR_TCE_IOMMU capability.
>>> [skip]
>>
>> Yes, I read the other comment. So roughly speaking I'll replace the
>> KVM_CAP_SPAPR_TCE_IOMMU check with the KVM_CAP_DEVICE_CTRL capability check
>> + try to KVM_CREATE_DEVICE with the KVM_CREATE_DEVICE_TEST flag set, and we
>> are fine.
> Yes, but KVM_CREATE_DEVICE_TEST does not create device, only checks if
> device type is supported.
Sure.
--
Alexey
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Vladimir Murzin @ 2013-09-03 19:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, dborkman, linuxppc-dev, davem, Matt Evans
In-Reply-To: <1378154750.3978.43.camel@pasglop>
On Tue, Sep 03, 2013 at 06:45:50AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
> > Ping
> >
> > 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.
> > >
> 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.
>
> 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.
1. get the tcpdump utility (git clone git://bpf.tcpdump.org/tcpdump)
2. get the libcap library (git clone git://bpf.tcpdump.org/libpcap)
2.1. apply patch for libcap [2] (against libcap-1.3 branch)
2.2. build libcap (./configure && make && ln -s libcap.so.1.3.0 libcap.so)
3. build tcpdump (LDFLAGS="-L/path/to/libcap" ./configure && make)
4. run
# ./tcpdump -d "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
(000) ldh [14]
(001) jeq #0x800 jt 2 jf 10
(002) ldh [18]
(003) sub #20
(004) mod #5
(005) jeq #0x0 jt 10 jf 6
(006) ldb [22]
(007) and #0x20
(008) jeq #0x20 jt 9 jf 10
(009) ret #65535
(010) ret #0
to get pseudo code (we are interested the most into line #4)
5. enable bpf jit compiler
# echo 2 > /proc/sys/net/core/bpf_jit_enable
6. run
./tcpdump -nv "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
7. check dmesg for lines starting with (output for x86-64 is provided as an example)
[ 3768.329253] flen=11 proglen=99 pass=3 image=ffffffffa003c000
[ 3768.329254] JIT code: ffffffffa003c000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 60
[ 3768.329255] JIT code: ffffffffa003c010: 44 2b 4f 64 4c 8b 87 c0 00 00 00 0f b7 47 76 86
[ 3768.329256] JIT code: ffffffffa003c020: c4 3d 00 08 00 00 75 37 be 02 00 00 00 e8 9f 3e
[ 3768.329257] JIT code: ffffffffa003c030: 02 e1 83 e8 14 31 d2 b9 05 00 00 00 f7 f1 89 d0
[ 3768.329258] JIT code: ffffffffa003c040: 85 c0 74 1b be 06 00 00 00 e8 9f 3e 02 e1 25 20
[ 3768.329259] JIT code: ffffffffa003c050: 00 00 00 83 f8 20 75 07 b8 ff ff 00 00 eb 02 31
[ 3768.329259] JIT code: ffffffffa003c060: c0 c9 c3
8. make sure generated opcodes (JIT code) implement pseudo code form step 4.
Reference
[1] http://comments.gmane.org/gmane.linux.network/242456
[2] http://permalink.gmane.org/gmane.network.tcpdump.devel/5973
P.S.
I hope net people will corect me if I'm wrong there
Cheers
Vladimir Murzin
> > > This patch brings JIT support for PPC64
> > >
> > > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> > > ---
> > > arch/powerpc/net/bpf_jit_comp.c | 22 ++++++++++++++++++++++
> > > 1 file changed, 22 insertions(+)
> > >
> > > 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 %= X; */
> > > + ctx->seen |= SEEN_XREG;
> > > + PPC_CMPWI(r_X, 0);
> > > + if (ctx->pc_ret0 != -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;
> > > + case BPF_S_ALU_MOD_K: /* A %= 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;
> > > case BPF_S_ALU_DIV_X: /* A /= X; */
> > > ctx->seen |= SEEN_XREG;
> > > PPC_CMPWI(r_X, 0);
> > > --
> > > 1.8.1.5
> > >
>
>
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-09-03 20:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben !
Please pull mpc5xxx patches for v3.12.
There are cleanups for some mpc5121 specific drivers and DTS files
in preparation to switch mpc5121 clock support to a clock driver
based on common clock framework. Additionally Sebastian fixed the
mpc52xx PIC driver so that it builds when using older gcc versions.
All these patches have already been in linux-next for a while.
Thanks,
Anatolij
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
for you to fetch changes up to f2110cb961200e5c382e9d0878ded015109b5dd6:
dts: mpc512x: prepare for preprocessor support (2013-08-24 00:18:55 +0200)
----------------------------------------------------------------
Gerhard Sittig (6):
serial: mpc512x: cleanup clock API use
USB: fsl-mph-dr-of: cleanup clock API use
mtd: mpc5121_nfc: cleanup clock API use
fsl-viu: cleanup clock API use
powerpc: mpc512x: array decl for MCLK registers in CCM
dts: mpc512x: prepare for preprocessor support
Sebastian Siewior (1):
powerpc: 52xx: provide a default in mpc52xx_irqhost_map()
arch/powerpc/boot/dts/ac14xx.dts | 2 +-
arch/powerpc/boot/dts/include/dt-bindings | 1 +
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
arch/powerpc/include/asm/mpc5121.h | 18 +-----
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 3 +-
drivers/media/platform/fsl-viu.c | 23 ++++---
drivers/mtd/nand/mpc5121_nfc.c | 21 ++++---
drivers/tty/serial/mpc52xx_uart.c | 98 ++++++++++++++++++++++++-----
drivers/usb/host/fsl-mph-dr-of.c | 16 ++---
10 files changed, 123 insertions(+), 63 deletions(-)
create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Daniel Borkmann @ 2013-09-03 20:52 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: Matt Evans, paulus, netdev, linuxppc-dev, davem
In-Reply-To: <20130903195819.GA1971@hp530>
On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
> On Tue, Sep 03, 2013 at 06:45:50AM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
>>> Ping
>>>
>>> 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.
>>>>
>> 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.
>>
>> 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.
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 },
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
> 1. get the tcpdump utility (git clone git://bpf.tcpdump.org/tcpdump)
> 2. get the libcap library (git clone git://bpf.tcpdump.org/libpcap)
> 2.1. apply patch for libcap [2] (against libcap-1.3 branch)
> 2.2. build libcap (./configure && make && ln -s libcap.so.1.3.0 libcap.so)
> 3. build tcpdump (LDFLAGS="-L/path/to/libcap" ./configure && make)
> 4. run
>
> # ./tcpdump -d "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
> (000) ldh [14]
> (001) jeq #0x800 jt 2 jf 10
> (002) ldh [18]
> (003) sub #20
> (004) mod #5
> (005) jeq #0x0 jt 10 jf 6
> (006) ldb [22]
> (007) and #0x20
> (008) jeq #0x20 jt 9 jf 10
> (009) ret #65535
> (010) ret #0
>
> to get pseudo code (we are interested the most into line #4)
>
> 5. enable bpf jit compiler
>
> # echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> 6. run
>
> ./tcpdump -nv "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
>
> 7. check dmesg for lines starting with (output for x86-64 is provided as an example)
>
> [ 3768.329253] flen=11 proglen=99 pass=3 image=ffffffffa003c000
> [ 3768.329254] JIT code: ffffffffa003c000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 60
> [ 3768.329255] JIT code: ffffffffa003c010: 44 2b 4f 64 4c 8b 87 c0 00 00 00 0f b7 47 76 86
> [ 3768.329256] JIT code: ffffffffa003c020: c4 3d 00 08 00 00 75 37 be 02 00 00 00 e8 9f 3e
> [ 3768.329257] JIT code: ffffffffa003c030: 02 e1 83 e8 14 31 d2 b9 05 00 00 00 f7 f1 89 d0
> [ 3768.329258] JIT code: ffffffffa003c040: 85 c0 74 1b be 06 00 00 00 e8 9f 3e 02 e1 25 20
> [ 3768.329259] JIT code: ffffffffa003c050: 00 00 00 83 f8 20 75 07 b8 ff ff 00 00 eb 02 31
> [ 3768.329259] JIT code: ffffffffa003c060: c0 c9 c3
>
> 8. make sure generated opcodes (JIT code) implement pseudo code form step 4.
>
> Reference
> [1] http://comments.gmane.org/gmane.linux.network/242456
> [2] http://permalink.gmane.org/gmane.network.tcpdump.devel/5973
>
> P.S.
> I hope net people will corect me if I'm wrong there
>
> Cheers
> Vladimir Murzin
>
>>>> This patch brings JIT support for PPC64
>>>>
>>>> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
^ permalink raw reply
* Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Yang,Wei @ 2013-09-04 1:27 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev, b38951
In-Reply-To: <1378194704-29909-1-git-send-email-hongtao.jia@freescale.com>
On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
Hi Hongtao,
If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
since some eeprom devices is connected to PCA9574 I2C bus
multiplexer, so these devices should be connected to pca9547 node. Just
like the following, what do you think of it?
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ eeprom@51 {
+ compatible =
"at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@52 {
+ compatible =
"at24,24c256";
+ reg = <0x52>;
+ };
+ eeprom@53 {
+ compatible =
"at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@54 {
+ compatible =
"at24,24c256";
+ reg = <0x54>;
+ };
+ eeprom@55 {
+ compatible =
"at24,24c256";
+ reg = <0x55>;
+ };
+ eeprom@56 {
+ compatible =
"at24,24c256";
+ reg = <0x56>;
+ };
+ rtc@68 {
+ compatible =
"dallas,ds3232";
+ reg = <0x68>;
+ interrupts =
<0x1 0x1 0 0>;
+ };
+ };
Wei
>
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> ---
> arch/powerpc/boot/dts/b4qds.dtsi | 4 ++++
> arch/powerpc/boot/dts/t4240qds.dts | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
> index e6d2f8f..2aa3399 100644
> --- a/arch/powerpc/boot/dts/b4qds.dtsi
> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> @@ -120,6 +120,10 @@
> };
>
> i2c@118000 {
> + pca9547@77 {
> + compatible = "philips,pca9547";
> + reg = <0x77>;
> + };
> eeprom@50 {
> compatible = "at24,24c64";
> reg = <0x50>;
> diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
> index 0555976..084db57 100644
> --- a/arch/powerpc/boot/dts/t4240qds.dts
> +++ b/arch/powerpc/boot/dts/t4240qds.dts
> @@ -118,6 +118,10 @@
> };
>
> i2c@118000 {
> + pca9547@77 {
> + compatible = "philips,pca9547";
> + reg = <0x77>;
> + };
> eeprom@51 {
> compatible = "at24,24c256";
> reg = <0x51>;
^ permalink raw reply
* RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
From: Seiji Aguchi @ 2013-09-04 1:44 UTC (permalink / raw)
To: Aruna Balakrishnaiah, Luck, Tony
Cc: jkenisto@linux.vnet.ibm.com, keescook@chromium.org,
mahesh@linux.vnet.ibm.com, ccross@android.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
cbouatmailru@gmail.com
In-Reply-To: <521C36F4.8030607@linux.vnet.ibm.com>
Aruna,
Sorry for the late response.
> Seiji,
>=20
> Could you let us know the efivars buffer size with which the pstore is
> registered when
> the failure occurred.
I looked into the issue today.
I added some debug message just before pstore_compress().
As you can see below, the buffer size is a fixed value(1024).
Therefore, the size doesn't seem to be related to the failure directly.
Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out=
is zero.
So, I thought big_oops_buf_sz is too big in my environment.
And then, I tuned big_oops_buf_sz to (psinfo->bufsize * 100) / 53.
At the same time, while looking into this issue, I had two concerns about c=
urrent cording.
1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_=
inflateInit()?
If you use zlib_deflateInit2() for specifying window_bit at compressi=
ng time,=20
zlib_inflateInit2() seems to be appropriate for decompressing.
(Please see a comment about inflateInit2() in include/linux/zlib.h and=
source code of crypto/deflate.c)
2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the be=
ginning of=20
compressing/decompressing time.
So, in pstore case, stream.workspace must be initialized to 0 with mem=
set() in pstore_compress()/decompress().
I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2()=
and initializing stream.workspace , in my environment.
As a result, compressions/decmpressions of all entries succeeded with efiva=
rs driver.
<snip>
Panic#2 Part1
<4>[ 75.665020] [<ffffffff811af59c>] SyS_write+0x4c/0xa0
<4>[ 75.665020] [<ffffffff8168be82>] system_call_fastpath+0x16/0x1b
<4>[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 =
00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae =
f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e=20
<1>[ 75.665020] RIP [<ffffffff813d3946>] sysrq_handle_crash+0x16/0x20
<4>[ 75.665020] RSP <ffff88007852de80>
<4>[ 75.665020] CR2: 0000000000000000
<4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]---
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2155 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2246 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore: compression failed for Part 2 returned -5
<3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2239 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2231 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2185 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore: compression failed for Part 5 returned -5
<3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2234 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2208 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2218 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2222 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore: compression failed for Part 9 returned -5
<3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9
<3>[ 75.665020] pstore_dump hsize=3D14 len=3D2256 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D14 len=3D2219 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D14 len=3D2226 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<0>[ 75.665020] Kernel panic - not syncing: Fatal exception
<3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text co=
nsole
<snip>
Seiji
^ 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