RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Wednesday, September 11, 2013 11:13 PM > To: Zhao Qiang-B45475 > Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 > Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in > device tree > > > On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: > > > Since P1010RDB-PA and P1010RDB-PB boards use different external PHY > > interrupt signals. > > And actually the PHY interrupt is not used effectively with > > corresponding interrupt handler. > > So we can remove the interrupts node without side-effect to comply > > with both P1010RDB-PA and P1010RDB-PB. > > > > Signed-off-by: Shengzhou Liu > > Signed-off-by: Zhao Qiang > > --- > > arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- > > 1 file changed, 3 deletions(-) > > > > NAK. The device tree should represent the HW not what drivers decide to do > with > it. > > If different board revs have different interrupt signals than create dts's to > handle the 2 board revs. > > - k > You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing current p1010rdb.dtsi just because of the unused phy interrupt? and phy interrupt is not present in those dts of P3/P4/P5 platforms. Actually currently many hardware are not present in dts, such as a lot of i2c devices, temperature monitor, etc. -Shengzhou ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
When backends (ex: efivars) have smaller registered buffers, the big_oops_buf
is quite too big for them as number of repeated occurences in the text captured
will be less. Patch takes care of adjusting the buffer size based on the
registered buffer size. cmpr values has been arrived after doing experiments
with
plain text for buffers of size 1k - 4k (Smaller the buffer size repeated
occurence
will be less) and with sample crash log for buffers ranging from 4k - 10k.
Reported-by: Seiji Aguchi
Signed-off-by: Aruna Balakrishnaiah
---
Changes from v1:
Retain the cmpr = 45 for buffers ranging of size 4k - 10k. 45 seems to
work.
I added an additional headroom of 3%. Revert it back to 45.
fs/pstore/platform.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 4ffb7ab..57b4219 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -195,8 +195,29 @@ error:
static void allocate_buf_for_compression(void)
{
size_t size;
+ size_t cmpr;
+
+ switch (psinfo->bufsize) {
+ /* buffer range for efivars */
+ case 1000 ... 2000:
+ cmpr = 56;
+ break;
+ case 2001 ... 3000:
+ cmpr = 54;
+ break;
+ case 3001 ... 3999:
+ cmpr = 52;
+ break;
+ /* buffer range for nvram, erst */
+ case 4000 ... 1:
+ cmpr = 45;
+ break;
+ default:
+ cmpr = 60;
+ break;
+ }
- big_oops_buf_sz = (psinfo->bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo->bufsize * 100) / cmpr;
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
size = max(zlib_deflate_workspacesize(WINDOW_BITS, MEM_LEVEL),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit : On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote: I wonder why we don't start from entry 31 so we can actually make use of that autodecrement. What will happen when we load the first normal TLB entry later on? I don't see any setting of SPRN_MD_CTR after this code, so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB case? Ben, would patches like this be considered bugfixes as far as merging goes, or would they be for next given that it's something that's never really worked right and hasn't been touched in years? Since they don't affect anything outside of 8xx, I'm happy to take them until around -rc2 or 3. But it's your call really. Scott, you're right, I didn't see that other consequence. I'll come with a more complete patch this afternoon. Thanks ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 12, 2013 7:04 AM
> To: Wang Dongsheng-B40534
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
>
> On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng
> >
> > Add a sys interface to enable/diable pw20 state or altivec idle, and
> > control the wait entry time.
> >
> > Enable/Disable interface:
> > 0, disable. 1, enable.
> > /sys/devices/system/cpu/cpuX/pw20_state
> > /sys/devices/system/cpu/cpuX/altivec_idle
> >
> > Set wait entry bit interface:
> > bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> > /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> > /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
>
> I'm no fan of the way powerpc does bit numbering, but don't flip it
> around here -- you'll just cause confusion.
>
OK. 0 bit is maxtime, 63 bit is mintime.
> Better yet, this interface should take real time units rather than a
> timebase bit.
>
I think the real time is not suitable, because timebase bit does not correspond
with
real time.
> Also, you disable the power saving mode if the maximum interval is
> selected,
It's not disable the pw20 state or altivec idle, just max-delay entry time.
>but the documentation doesn't say that -- and the documentation
> should be in the code (or other easily findable place), not just in the
> commit message.
>
Also add a comment in the 85xx/common.c ?
> > Signed-off-by: Wang Dongsheng
> > ---
> > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > index 7389d49..7395d79 100644
> > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > @@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
> > isync
> > blr
> >
> > +_GLOBAL(has_pw20_altivec_idle)
> > + /* 0 false, 1 true */
> > + li r3, 0
> > +
> > + /* PW20 & AltiVec idle feature only exists for E6500 */
> > + mfspr r0, SPRN_PVR
> > + rlwinm r4, r0, 16, 16, 31
> > + lis r12, 0
> > + ori r12, r12, PVR_VER_E6500@l
> > + cmpwr4, r12
> > + bne 2f
> > + li r3, 1
> > +2:
> > + blr
>
> Why is this in asm? And shouldn't this go in the cputable somehow?
>
Not a special reason for this, just asm...
I see that, we can use cpu_spec->pvr_value in c code.
> > +static void query_pwrmgtcr0(void *val) {
> > + u32 *value = val;
> > +
> > + *value = mfspr(SPRN_PWRMGTCR0);
> > +}
> > +
> > +static ssize_t show_pw20_state(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + u32 value;
> > + unsigned int cpu = dev->id;
> > +
> > + smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> > +
> > + value &= PWRMGTCR0_PW20_WAIT;
> > +
> > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > +
> > +static void control_pw20_state(void *val) {
> > + u32 *value = val;
> > + u32 pw20_state;
> > +
> > + pw20_state = mfspr(SPRN_PWRMGTCR0);
> > +
> > + if (*value)
> > + pw20_state |= PWRMGTCR0_PW20_WAIT;
> > + else
> > + pw20_state &= ~PWRMGTCR0_PW20_WAIT;
> > +
> > + mtspr(SPRN_PWRMGTCR0, pw20_state);
> > +}
> > +
> > +static ssize_t store_pw20_state(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
>
> The difference between query/show and control/store is a bit awkward...
> I'd s/query/do_show/ and s/control/do_store/ (or local_ or other
> appropriate prefix).
>
do_show/do_store looks better than others.
> > +static ssize_t show_altivec_idle_wait_entry_bit(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + u32 value;
> > + unsigned int cpu = dev->id;
> > +
> > + smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> > +
> > + value = MAX_BIT - ((value & PWRMGTCR0_AV_IDLE_CNT) >>
> > + PWRMGTCR0_AV_IDLE_CNT_SHIFT);
> > +
> > + return sprintf(buf, "wait entry bit is %u\n", value); }
>
> Reading a sysfs value should just return the value, not a human-readable
> string.
>
Thanks.
> > +static DEVICE_ATTR(pw20_state, 0644, show_pw20_state,
> > +store_pw20_state); static DEVICE_ATTR(pw20_wait_entry_bit, 0644,
> show_pw20_wait_entry_bit,
> > + store_pw20_wait_entry_bit);
> > +
> > +static DEVICE_ATTR(altivec_idle, 0644, show_altivec_idle,
> > +store_altivec_idle); static DEVICE_ATTR(altivec_idle_wait_entry_bit,
> 0644,
> > + show_altivec_idle_wait_entry_bit,
> > + store_altivec_idle_wait_entry_bit);
>
> I'd make these 0600, given their ability to spam other CPUs with IPIs
> even on read.
>
Thanks.
> > +static int __init create_pw20_altivec_sysfs(void) {
> > + int i;
> > + struct dev
Re: [PATCH] ppc: bpf_jit: support MOD operation
On Thu, Sep 12, 2013 at 02:18:37AM +0100, Matt Evans wrote:
> Hi Ben, Vladimir,
>
>
> *dusts off very thick PPC cobwebs* Sorry for the delay as I'm travelling,
> didn't get to this until now.
>
> On 02/09/2013, at 9:45 PM, Benjamin Herrenschmidt wrote:
>
> > On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
> >> Ping
> >>
> >> 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
> >>> ---
> >>> 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;
>
> Without having compiled & tested this, it looks fine to me (especially with
> the corrected DIVWU opcode in the other patch, oops...).
>
> >>> + case BPF_S_ALU_MOD_K: /* A %= K; */
> >>> +#define r_scratch2 (r_scratch1 + 1)
> >>> + PPC_LI32(r_scratch2, K);
> >>> + PPC_DIVWU(r_scratch1, r_A, r_scratch2);
> >>> + PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
> >>> + PPC_SUB(r_A, r_A, r_scratch1);
> >>> +#undef r_scratch2
> >>> + break;
>
> If you need another scratch register, it should really be defined in
> bpf_jit.h instead.
>
> Once you define r_scratch2 in there,
>
> Acked-by: Matt Evans
>
>
> Thanks!
>
>
> Matt
>
Thanks!
Vladimir
>
>
>
> >>> case BPF_S_ALU_DIV_X: /* A /= X; */
> >>> ctx->seen |= SEEN_XREG;
> >>> PPC_CMPWI(r_X, 0);
> >>> --
> >>> 1.8.1.5
> >>>
> >
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: net: filter: fix DIVWU instruction opcode
On Thu, Sep 12, 2013 at 10:28:03AM +0930, Matt Evans wrote: > On 12 Sep 2013, at 10:02, Michael Neuling wrote: > > > Vladimir Murzin wrote: > > > >> Currently DIVWU stands for *signed* divw opcode: > >> > >> 7d 2a 4b 96divwu r9,r10,r9 > >> 7d 2a 4b d6divwr9,r10,r9 > >> > >> Use the *unsigned* divw opcode for DIVWU. > > > > This looks like it's in only used in the BPF JIT code. > > > > Matt, any chance you an ACK/NACK this? > > Sure, that looks sensible, thanks Vladimir. > > Acked-by: Matt Evans > Thanks! Vladimir > > > > Mikey > > > >> > >> Signed-off-by: Vladimir Murzin > >> --- > >> arch/powerpc/include/asm/ppc-opcode.h |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/powerpc/include/asm/ppc-opcode.h > >> b/arch/powerpc/include/asm/ppc-opcode.h > >> index d7fe9f5..c91842c 100644 > >> --- a/arch/powerpc/include/asm/ppc-opcode.h > >> +++ b/arch/powerpc/include/asm/ppc-opcode.h > >> @@ -218,7 +218,7 @@ > >> #define PPC_INST_MULLW0x7c0001d6 > >> #define PPC_INST_MULHWU0x7c16 > >> #define PPC_INST_MULLI0x1c00 > >> -#define PPC_INST_DIVWU0x7c0003d6 > >> +#define PPC_INST_DIVWU0x7c000396 > >> #define PPC_INST_RLWINM0x5400 > >> #define PPC_INST_RLDICR0x7804 > >> #define PPC_INST_SLW0x7c30 > >> -- > >> 1.7.10.4 > >> ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, September 12, 2013 6:43 AM > To: Wang Dongsheng-B40534 > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH v3 2/4] powerpc/85xx: add hardware automatically > enter altivec idle state > > On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: > > From: Wang Dongsheng > > > > Each core's AltiVec unit may be placed into a power savings mode > > by turning off power to the unit. Core hardware will automatically > > power down the AltiVec unit after no AltiVec instructions have > > executed in N cycles. The AltiVec power-control is triggered by > hardware. > > > > Signed-off-by: Wang Dongsheng > > --- > > *v3: > > Assembly code instead of C code. > > > > *v2: > > Remove: > > delete setup_idle_hw_governor function. > > delete "Fix erratum" for rev1. > > > > Move: > > move setup_* into __setup/restore_cpu_e6500. > > > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 > > 1 file changed, 20 insertions(+) > > > > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S > b/arch/powerpc/kernel/cpu_setup_fsl_booke.S > > index bfb18c7..3c03c109 100644 > > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S > > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S > > @@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup) > > isync > > blr > > > > +/* > > + * FIXME - We don't know the AltiVec application scenarios. > > + */ > > +#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ > */ > > +_GLOBAL(setup_altivec_idle) > > + mfspr r3, SPRN_PWRMGTCR0 > > + > > + /* Enable Altivec Idle */ > > + orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h > > + li r4, AV_WAIT_IDLE_BIT > > + > > + /* Set Automatic AltiVec Idle Count */ > > + rlwimi r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT, > PWRMGTCR0_AV_IDLE_CNT > > + > > + mtspr SPRN_PWRMGTCR0, r3 > > + > > + blr > > The FIXME comment is not clear. If you mean that we haven't yet done > testing to determine a reasonable default value for AV_WAIT_IDLE_BIT, > then just say that. Likewise with the FIXME comment in the pw20 patch > -- the uncertainty is due to a lack of investigation, not "because we > don't know the current state of the cpu load". > > While some workloads may want a different value than whatever default we > set, that's what the sysfs interface is for. The only thing missing > here is benchmarking to determine a good overall default. > Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
> -Original Message- > From: Wood Scott-B07421 > Sent: 2013年9月12日 星期四 9:10 > To: Tang Yuantian-B29983 > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Li Yang-Leo-R58472 > Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree > nodes > > On Wed, 2013-09-11 at 14:57 +0800, yuantian.t...@freescale.com wrote: > > From: Tang Yuantian > > > > The following SoCs will be affected: p2041, p3041, p4080, p5020, > > p5040, b4420, b4860, t4240 > > > > Signed-off-by: Tang Yuantian > > Signed-off-by: Li Yang > > --- > > v4: > > - add binding document > > - update compatible string > > - update the reg property > > v3: > > - fix typo > > v2: > > - add t4240, b4420, b4860 support > > - remove pll/4 clock from p2041, p3041 and p5020 board > > > > .../devicetree/bindings/clock/corenet-clock.txt| 80 > +++ > > arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 34 ++- > > arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 + > > arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 34 ++- > > arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 + > > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 59 ++- > > arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 + > > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 59 ++- > > arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 + > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 111 > - > > arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++ > > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 41 +++- > > arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 + > > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 59 ++- > > arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 + > > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 84 > +++- > > arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++ > > 17 files changed, 593 insertions(+), 8 deletions(-) create mode > > 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt > > > > diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt > > b/Documentation/devicetree/bindings/clock/corenet-clock.txt > > new file mode 100644 > > index 000..51eab75 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt > > @@ -0,0 +1,80 @@ > > +Device Tree Clock bindings for Freescale PowerPC corenet platform > > + > > +This binding uses the common clock binding[1]. > > + > > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > > + > > +Required properties: > > +- compatible : shall be one or more of the following: > > Shall include... > > > + - "fsl,-clockgen": for chip specific clock block > > + - "fsl,qoriq-clockgen-[1,2].0": for chassis 1.0 and 2.0 clock > > + block respectively. > > + - "fsl,qoriq-chassis[1,2]-core-pll" - for a core PLL clock > > + - "fsl,qoriq-chassis[1,2]-core-mux" - for a core multiplexer clock. > > + Divided from the core PLL clock > > Hmm, there's a bit of a mismatch here between "chassis2" and the "2.0" > on the clockgen node... perhaps it should be "fsl,qoriq-core-pll-2.0", > etc. > > > + - "fixed-clock" - from common clock binding; should be output clock > > + of oscillator > > +- reg : shall be the control register offset from clock block base > address. > > This description of "reg" is overly specific (assumes how the parent > node's ranges are set up), incomplete (there's a size as well as the > offset), and does not apply to the clockgen node itself (you probably > shouldn't lump them together like this). > Do you mean I should explain the REG of clockgen and its child node respectively? > > +- clocks : shall be the input parent clock phandle for the clock. > > Not required on the clockgen node > Required by child node of clockgen. Regards, Yuantian > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc: bpf_jit: support MOD operation
Hi Ben, Vladimir,
*dusts off very thick PPC cobwebs* Sorry for the delay as I'm travelling,
didn't get to this until now.
On 02/09/2013, at 9:45 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
>> Ping
>>
>> 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
>>> ---
>>> 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;
Without having compiled & tested this, it looks fine to me (especially with the
corrected DIVWU opcode in the other patch, oops...).
>>> + case BPF_S_ALU_MOD_K: /* A %= K; */
>>> +#define r_scratch2 (r_scratch1 + 1)
>>> + PPC_LI32(r_scratch2, K);
>>> + PPC_DIVWU(r_scratch1, r_A, r_scratch2);
>>> + PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
>>> + PPC_SUB(r_A, r_A, r_scratch1);
>>> +#undef r_scratch2
>>> + break;
If you need another scratch register, it should really be defined in bpf_jit.h
instead.
Once you define r_scratch2 in there,
Acked-by: Matt Evans
Thanks!
Matt
>>> case BPF_S_ALU_DIV_X: /* A /= X; */
>>> ctx->seen |= SEEN_XREG;
>>> PPC_CMPWI(r_X, 0);
>>> --
>>> 1.8.1.5
>>>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property
On Tue, 2013-09-10 at 21:07 -0500, Hu Mingkai-B21284 wrote: > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 11, 2013 7:33 AM > > To: Hu Mingkai-B21284 > > Cc: linuxppc-...@ozlabs.org > > Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions > > property > > > > What happens to exsting users whose flash is laid out the existing way, > > when they upgrade to these device trees? > > > > The SPI flash layout should be mapping the new device tree. > > If the existing device tree is used to deploy the SPI flash, the following > issues > must be run into as the commit message described: > > 1. Kernel images would be overlapped with U-Boot image. > 2. Kernel images would be overlapped with FMAN ucode. > 3. Saving environment variables will crash the kernel image. Has the SPI U-Boot image always been larger than 512K for all these platforms? Why, given that we're under 512K for other boot modes? > > We really should not be putting partition layout info in the device tree > > to begin with... > > > OK, I will remove the layout diagram in the commit message. That's not what I meant. I meant that the dts should be describing hardware, and this is the sort of trouble we run into when we deviate from that. A better way would be to use the mtdparts command line option. Even better would be some sort of on-flash partition table. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
On Wed, 2013-09-11 at 14:57 +0800, yuantian.t...@freescale.com wrote: > From: Tang Yuantian > > The following SoCs will be affected: p2041, p3041, p4080, > p5020, p5040, b4420, b4860, t4240 > > Signed-off-by: Tang Yuantian > Signed-off-by: Li Yang > --- > v4: > - add binding document > - update compatible string > - update the reg property > v3: > - fix typo > v2: > - add t4240, b4420, b4860 support > - remove pll/4 clock from p2041, p3041 and p5020 board > > .../devicetree/bindings/clock/corenet-clock.txt| 80 +++ > arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 34 ++- > arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 + > arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 34 ++- > arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 + > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 59 ++- > arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 + > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 59 ++- > arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 + > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 111 > - > arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++ > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 41 +++- > arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 + > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 59 ++- > arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 + > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 84 +++- > arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++ > 17 files changed, 593 insertions(+), 8 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt > > diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt > b/Documentation/devicetree/bindings/clock/corenet-clock.txt > new file mode 100644 > index 000..51eab75 > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt > @@ -0,0 +1,80 @@ > +Device Tree Clock bindings for Freescale PowerPC corenet platform > + > +This binding uses the common clock binding[1]. > + > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > + > +Required properties: > +- compatible : shall be one or more of the following: Shall include... > + - "fsl,-clockgen": for chip specific clock block > + - "fsl,qoriq-clockgen-[1,2].0": for chassis 1.0 and 2.0 clock > + block respectively. > + - "fsl,qoriq-chassis[1,2]-core-pll" - for a core PLL clock > + - "fsl,qoriq-chassis[1,2]-core-mux" - for a core multiplexer clock. > + Divided from the core PLL clock Hmm, there's a bit of a mismatch here between "chassis2" and the "2.0" on the clockgen node... perhaps it should be "fsl,qoriq-core-pll-2.0", etc. > + - "fixed-clock" - from common clock binding; should be output clock > + of oscillator > +- reg : shall be the control register offset from clock block base address. This description of "reg" is overly specific (assumes how the parent node's ranges are set up), incomplete (there's a size as well as the offset), and does not apply to the clockgen node itself (you probably shouldn't lump them together like this). > +- clocks : shall be the input parent clock phandle for the clock. Not required on the clockgen node -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: net: filter: fix DIVWU instruction opcode
On 12 Sep 2013, at 10:02, Michael Neuling wrote: > Vladimir Murzin wrote: > >> Currently DIVWU stands for *signed* divw opcode: >> >> 7d 2a 4b 96divwu r9,r10,r9 >> 7d 2a 4b d6divwr9,r10,r9 >> >> Use the *unsigned* divw opcode for DIVWU. > > This looks like it's in only used in the BPF JIT code. > > Matt, any chance you an ACK/NACK this? Sure, that looks sensible, thanks Vladimir. Acked-by: Matt Evans > > Mikey > >> >> Signed-off-by: Vladimir Murzin >> --- >> arch/powerpc/include/asm/ppc-opcode.h |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/include/asm/ppc-opcode.h >> b/arch/powerpc/include/asm/ppc-opcode.h >> index d7fe9f5..c91842c 100644 >> --- a/arch/powerpc/include/asm/ppc-opcode.h >> +++ b/arch/powerpc/include/asm/ppc-opcode.h >> @@ -218,7 +218,7 @@ >> #define PPC_INST_MULLW0x7c0001d6 >> #define PPC_INST_MULHWU0x7c16 >> #define PPC_INST_MULLI0x1c00 >> -#define PPC_INST_DIVWU0x7c0003d6 >> +#define PPC_INST_DIVWU0x7c000396 >> #define PPC_INST_RLWINM0x5400 >> #define PPC_INST_RLDICR0x7804 >> #define PPC_INST_SLW0x7c30 >> -- >> 1.7.10.4 >> ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: net: filter: fix DIVWU instruction opcode
Vladimir Murzin wrote: > Currently DIVWU stands for *signed* divw opcode: > > 7d 2a 4b 96 divwu r9,r10,r9 > 7d 2a 4b d6 divwr9,r10,r9 > > Use the *unsigned* divw opcode for DIVWU. This looks like it's in only used in the BPF JIT code. Matt, any chance you an ACK/NACK this? Mikey > > Signed-off-by: Vladimir Murzin > --- > arch/powerpc/include/asm/ppc-opcode.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/ppc-opcode.h > b/arch/powerpc/include/asm/ppc-opcode.h > index d7fe9f5..c91842c 100644 > --- a/arch/powerpc/include/asm/ppc-opcode.h > +++ b/arch/powerpc/include/asm/ppc-opcode.h > @@ -218,7 +218,7 @@ > #define PPC_INST_MULLW 0x7c0001d6 > #define PPC_INST_MULHWU 0x7c16 > #define PPC_INST_MULLI 0x1c00 > -#define PPC_INST_DIVWU 0x7c0003d6 > +#define PPC_INST_DIVWU 0x7c000396 > #define PPC_INST_RLWINM 0x5400 > #define PPC_INST_RLDICR 0x7804 > #define PPC_INST_SLW 0x7c30 > -- > 1.7.10.4 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote: > I wonder why we don't start from entry 31 so we can actually make use of > that autodecrement. What will happen when we load the first normal TLB > entry later on? I don't see any setting of SPRN_MD_CTR after this code, > so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB > case? > > Ben, would patches like this be considered bugfixes as far as merging > goes, or would they be for next given that it's something that's never > really worked right and hasn't been touched in years? Since they don't affect anything outside of 8xx, I'm happy to take them until around -rc2 or 3. But it's your call really. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board support
On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote:
> Add support for T104x board in board file t104x_qds.c, It is common for
> both T1040 and T1042 as they share same QDS board.
>
> T1040QDS board Overview
> ---
> - SERDES Connections, 8 lanes supporting:
> — PCI Express: supporting Gen 1 and Gen 2;
> — SGMII
> — QSGMII
> — SATA 2.0
> — Aurora debug with dedicated connectors (T1040 only)
> - DDR Controller
> - Supports rates of up to 1600 MHz data-rate
> - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank types.
> -IFC/Local Bus
> - NAND flash: 8-bit, async, up to 2GB.
> - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
> - GASIC: Simple (minimal) target within Qixis FPGA
> - PromJET rapid memory download support
> - Ethernet
> - Two on-board RGMII 10/100/1G ethernet ports.
> - PHY #0 remains powered up during deep-sleep (T1040 only)
> - QIXIS System Logic FPGA
> - Clocks
> - System and DDR clock (SYSCLK, “DDRCLK”)
> - SERDES clocks
> - Power Supplies
> - Video
> - DIU supports video at up to 1280x1024x32bpp
> - USB
> - Supports two USB 2.0 ports with integrated PHYs
> — Two type A ports with 5V@1.5A per port.
> — Second port can be converted to OTG mini-AB
> - SDHC
> - SDHC port connects directly to an adapter card slot, featuring:
> - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
> — Supporting eMMC memory devices
> - SPI
> - On-board support of 3 different devices and sizes
> - Other IO
> - Two Serial ports
> - ProfiBus port
> - Four I2C ports
>
> Add T104xQDS support in Kconfig and Makefile. Also create device tree.
>
> Signed-off-by: Priyanka Jain
> Signed-off-by: Poonam Aggrwal
> Signed-off-by: Prabhakar Kushwaha
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>
> TODO: Add noded for ethernet and board stuff
"board stuff"?
Isn't "board stuff" the whole point of this patch? :-)
> arch/powerpc/boot/dts/t1040qds.dts | 201
> +++
> arch/powerpc/boot/dts/t1042qds.dts | 201
> +++
> arch/powerpc/platforms/85xx/Kconfig | 20 +++
> arch/powerpc/platforms/85xx/Makefile|1 +
> arch/powerpc/platforms/85xx/t104x_qds.c | 102
> 5 files changed, 525 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
> create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
> create mode 100644 arch/powerpc/platforms/85xx/t104x_qds.c
>
> diff --git a/arch/powerpc/boot/dts/t1040qds.dts
> b/arch/powerpc/boot/dts/t1040qds.dts
> new file mode 100644
> index 000..cea5632
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/t1040qds.dts
> @@ -0,0 +1,201 @@
> +/*
> + * T1040QDS Device Tree Source
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + * * Redistributions of source code must retain the above 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/t104xsi-pre.dtsi"
> +
> +/ {
> + model = "fsl,T1040QDS";
> + compatible = "fsl,T1040QDS";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-parent = <&mpic>;
> +
> +
[PATCH] powerpc/b4qds: enable coreint
Commit 9837b43c5f3514e5d28f65f1513f4dc6759d2810 ("powerpc/85xx: enable
coreint for all the 64bit boards") removed the ifdef that avoided
coreint on 64-bit, but it missed b4_qds.c.
Signed-off-by: Scott Wood
Cc: Kevin Hao
Cc: Shaveta Leekha
---
arch/powerpc/platforms/85xx/b4_qds.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/b4_qds.c
b/arch/powerpc/platforms/85xx/b4_qds.c
index 0c6702f..0f18663 100644
--- a/arch/powerpc/platforms/85xx/b4_qds.c
+++ b/arch/powerpc/platforms/85xx/b4_qds.c
@@ -79,12 +79,7 @@ define_machine(b4_qds) {
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#endif
-/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
-#ifdef CONFIG_PPC64
- .get_irq= mpic_get_irq,
-#else
.get_irq= mpic_get_coreint_irq,
-#endif
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote:
> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
> processor cores with high-performance data path acceleration architecture
> and network peripheral interfaces required for networking &
> telecommunications.
>
> T1042 personality is a reduced personality of T1040 without Integrated 8-port
> Gigabit Ethernet switch.
>
> The T1040/T1042 SoC includes the following function and features:
>
> - Four e5500 cores, each with a private 256 KB L2 cache
> - 256 KB shared L3 CoreNet platform cache (CPC)
> - Interconnect CoreNet platform
> - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
>support
> - Data Path Acceleration Architecture (DPAA) incorporating acceleration
> for the following functions:
> - Packet parsing, classification, and distribution
> - Queue management for scheduling, packet sequencing, and congestion
> management
> - Cryptography Acceleration (SEC 5.0)
> - RegEx Pattern Matching Acceleration (PME 2.2)
> - IEEE Std 1588 support
> - Hardware buffer management for buffer allocation and deallocation
> - Ethernet interfaces
> - Integrated 8-port Gigabit Ethernet switch (T1040 only)
> - Four 1 Gbps Ethernet controllers
> - Two RGMII interfaces or one RGMII and one MII interfaces
> - High speed peripheral interfaces
>- Four PCI Express 2.0 controllers running at up to 5 GHz
>- Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
>- Upto two QSGMII interface
>- Upto six SGMII interface supporting 1000 Mbps
>- One SGMII interface supporting upto 2500 Mbps
> - Additional peripheral interfaces
>- Two USB 2.0 controllers with integrated PHY
>- SD/eSDHC/eMMC
>- eSPI controller
>- Four I2C controllers
>- Four UARTs
>- Four GPIO controllers
>- Integrated flash controller (IFC)
>- Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate
>- TDM interface
> - Multicore programmable interrupt controller (PIC)
> - Two 8-channel DMA engines
> - Single source clocking implementation
> - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
>
> Signed-off-by: Poonam Aggrwal
> Signed-off-by: Priyanka Jain
> Signed-off-by: Varun Sethi
> Signed-off-by: Prabhakar Kushwaha
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Everything in there has already been pulled by Linus, so there's no
reason to use that tree as a base right now.
> +/include/ "t1042si-post.dtsi"
[snip]
> + serdes: serdes@ea000 {
> + compatible = "fsl,t1040-serdes";
> + reg= <0xea000 0x4000>;
> + };
> +
> + sdhc@114000 {
> + compatible = "fsl,t1040-esdhc", "fsl,esdhc";
> + sdhci,auto-cmd12;
> + };
Why does sdhci,auto-cmd12 need to be specified here? It's already in
t1042si-post.dtsi which you've included. Likewise with reg on the
serdes node.
I also question the need to define separate t1040 compatible values for
all of these, if the only difference is whether the onboard switch is
enabled or not.
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,t1042-clockgen", "fsl,qoriq-clockgen-2.0",
> +"fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-names = "sysclk";
> + #clock-cells = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pll0: pll0@800 {
> + #clock-cells = <1>;
> + reg = <0x800>;
> + compatible = "fsl,core-pll-clock";
> + clocks = <&clockgen>;
> + clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> + };
> + pll1: pll1@820 {
> + #clock-cells = <1>;
> + reg = <0x820>;
> + compatible = "fsl,core-pll-clock";
> + clocks = <&clockgen>;
> + clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> + };
> + mux0: mux0@0 {
> + #clock-cells = <0>;
> + reg = <0x0>;
> + compatible = "fsl,core-mux-clock";
Please update the clock stuff based on
http://patchwork.ozlabs.org/patch/274134/
> +/include/ "qoriq-dma-0.dtsi"
> + dma@100300 {
> + fsl,iommu-parent = <&pamu0>;
> + fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
> + };
> +
> +/include/ "qoriq-dma-1.dtsi"
> + dma@101300 {
> + fsl,iommu-parent = <&pamu0>;
> + fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
> + };
These are elo3:
http://patchwork.ozlabs.org/patch/271238/
> + display@18 {
> +compatible = "fsl,diu", "fsl,t1042-diu";
> +reg = <0x18 1000>;
> +
Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
>
> Add a sys interface to enable/diable pw20 state or altivec idle, and
> control the wait entry time.
>
> Enable/Disable interface:
> 0, disable. 1, enable.
> /sys/devices/system/cpu/cpuX/pw20_state
> /sys/devices/system/cpu/cpuX/altivec_idle
>
> Set wait entry bit interface:
> bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
I'm no fan of the way powerpc does bit numbering, but don't flip it
around here -- you'll just cause confusion.
Better yet, this interface should take real time units rather than a
timebase bit.
Also, you disable the power saving mode if the maximum interval is
selected, but the documentation doesn't say that -- and the
documentation should be in the code (or other easily findable place),
not just in the commit message.
> Signed-off-by: Wang Dongsheng
> ---
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 7389d49..7395d79 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
> isync
> blr
>
> +_GLOBAL(has_pw20_altivec_idle)
> + /* 0 false, 1 true */
> + li r3, 0
> +
> + /* PW20 & AltiVec idle feature only exists for E6500 */
> + mfspr r0, SPRN_PVR
> + rlwinm r4, r0, 16, 16, 31
> + lis r12, 0
> + ori r12, r12, PVR_VER_E6500@l
> + cmpwr4, r12
> + bne 2f
> + li r3, 1
> +2:
> + blr
Why is this in asm? And shouldn't this go in the cputable somehow?
> +static void query_pwrmgtcr0(void *val)
> +{
> + u32 *value = val;
> +
> + *value = mfspr(SPRN_PWRMGTCR0);
> +}
> +
> +static ssize_t show_pw20_state(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u32 value;
> + unsigned int cpu = dev->id;
> +
> + smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> +
> + value &= PWRMGTCR0_PW20_WAIT;
> +
> + return sprintf(buf, "%u\n", value ? 1 : 0);
> +}
> +
> +static void control_pw20_state(void *val)
> +{
> + u32 *value = val;
> + u32 pw20_state;
> +
> + pw20_state = mfspr(SPRN_PWRMGTCR0);
> +
> + if (*value)
> + pw20_state |= PWRMGTCR0_PW20_WAIT;
> + else
> + pw20_state &= ~PWRMGTCR0_PW20_WAIT;
> +
> + mtspr(SPRN_PWRMGTCR0, pw20_state);
> +}
> +
> +static ssize_t store_pw20_state(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
The difference between query/show and control/store is a bit awkward...
I'd s/query/do_show/ and s/control/do_store/ (or local_ or other
appropriate prefix).
> +static ssize_t show_altivec_idle_wait_entry_bit(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u32 value;
> + unsigned int cpu = dev->id;
> +
> + smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> +
> + value = MAX_BIT - ((value & PWRMGTCR0_AV_IDLE_CNT) >>
> + PWRMGTCR0_AV_IDLE_CNT_SHIFT);
> +
> + return sprintf(buf, "wait entry bit is %u\n", value);
> +}
Reading a sysfs value should just return the value, not a human-readable
string.
> +static DEVICE_ATTR(pw20_state, 0644, show_pw20_state, store_pw20_state);
> +static DEVICE_ATTR(pw20_wait_entry_bit, 0644, show_pw20_wait_entry_bit,
> + store_pw20_wait_entry_bit);
> +
> +static DEVICE_ATTR(altivec_idle, 0644, show_altivec_idle,
> store_altivec_idle);
> +static DEVICE_ATTR(altivec_idle_wait_entry_bit, 0644,
> + show_altivec_idle_wait_entry_bit,
> + store_altivec_idle_wait_entry_bit);
I'd make these 0600, given their ability to spam other CPUs with IPIs
even on read.
> +static int __init create_pw20_altivec_sysfs(void)
> +{
> + int i;
> + struct device *cpu_dev;
> +
> + if (!has_pw20_altivec_idle())
> + return -ENODEV;
> +
> + for_each_possible_cpu(i) {
> + cpu_dev = get_cpu_device(i);
> + device_create_file(cpu_dev, &dev_attr_pw20_state);
> + device_create_file(cpu_dev, &dev_attr_pw20_wait_entry_bit);
> +
> + device_create_file(cpu_dev, &dev_attr_altivec_idle);
> + device_create_file(cpu_dev,
> + &dev_attr_altivec_idle_wait_entry_bit);
> + }
> +
> + return 0;
> +}
> +device_initcall(create_pw20_altivec_sysfs);
I think I said this earlier, but it'd be nice to have a "late cpu setup"
cputable callback -- but failing that, this should be called from
register_cpu_online() which is where other CPU sysfs attributes are
created.
-Scott
Re: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: > From: Wang Dongsheng > > Each core's AltiVec unit may be placed into a power savings mode > by turning off power to the unit. Core hardware will automatically > power down the AltiVec unit after no AltiVec instructions have > executed in N cycles. The AltiVec power-control is triggered by hardware. > > Signed-off-by: Wang Dongsheng > --- > *v3: > Assembly code instead of C code. > > *v2: > Remove: > delete setup_idle_hw_governor function. > delete "Fix erratum" for rev1. > > Move: > move setup_* into __setup/restore_cpu_e6500. > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 > 1 file changed, 20 insertions(+) > > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S > b/arch/powerpc/kernel/cpu_setup_fsl_booke.S > index bfb18c7..3c03c109 100644 > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S > @@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup) > isync > blr > > +/* > + * FIXME - We don't know the AltiVec application scenarios. > + */ > +#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */ > +_GLOBAL(setup_altivec_idle) > + mfspr r3, SPRN_PWRMGTCR0 > + > + /* Enable Altivec Idle */ > + orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h > + li r4, AV_WAIT_IDLE_BIT > + > + /* Set Automatic AltiVec Idle Count */ > + rlwimi r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT > + > + mtspr SPRN_PWRMGTCR0, r3 > + > + blr The FIXME comment is not clear. If you mean that we haven't yet done testing to determine a reasonable default value for AV_WAIT_IDLE_BIT, then just say that. Likewise with the FIXME comment in the pw20 patch -- the uncertainty is due to a lack of investigation, not "because we don't know the current state of the cpu load". While some workloads may want a different value than whatever default we set, that's what the sysfs interface is for. The only thing missing here is benchmarking to determine a good overall default. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
On Wed, 2013-09-11 at 18:44 +0200, Christophe Leroy wrote: > Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three > 8Mbytes pages. But the setting of the MD_CTR was missing so as the index is > decremented every DTLB update, the pinning of the third 8Mbytes page was > overwriting the DTLB entry for IMMR. > > Signed-off-by: Christophe Leroy > > diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S > linux-3.11/arch/powerpc/kernel/head_8xx.S > --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 > 22:46:10.0 +0200 > +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.0 > +0200 > @@ -862,6 +862,9 @@ > addis r11, r11, 0x0080/* Add 8M */ > mtspr SPRN_MD_RPN, r11 > > + addir10, r10, 0x0100 > + mtspr SPRN_MD_CTR, r10 > + > addis r8, r8, 0x0080 /* Add 8M */ > mtspr SPRN_MD_EPN, r8 > mtspr SPRN_MD_TWC, r9 I wonder why we don't start from entry 31 so we can actually make use of that autodecrement. What will happen when we load the first normal TLB entry later on? I don't see any setting of SPRN_MD_CTR after this code, so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB case? Ben, would patches like this be considered bugfixes as far as merging goes, or would they be for next given that it's something that's never really worked right and hasn't been touched in years? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 15/25] smp, ppc: kill SMP single function call interrupt
On 09/11/2013 09:37 PM, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" has unified the way to handle
> single and multiple cross-CPU function calls. Now only one interrupt
> is needed for architecture specific code to support generic SMP function
> call interfaces, so kill the redundant single function call interrupt.
>
> Signed-off-by: Jiang Liu
> Cc: Jiang Liu
> ---
It turns out that freeing up the IPI slot in powerpc is very useful, since
we actually wanted a slot for some other use-case (and there are only 4 slots
available on powerpc).
Here are the patches which achieve that:
http://marc.info/?l=linuxppc-embedded&m=137886807502898&w=2
http://marc.info/?l=linuxppc-embedded&m=137886811502909&w=2
So, can you kindly consider dropping the powerpc patch from your series,
if that is OK with you? Thanks!
BTW, after doing the powerpc cleanup, even I had thought about killing one
of the smp-function variants in various architectures, but never got around
to do it. But now that you have posted the series which does that, I'll try
to review them.
Thank you!
Regards,
Srivatsa S. Bhat
> arch/powerpc/include/asm/smp.h | 3 +--
> arch/powerpc/kernel/smp.c | 12 +---
> 2 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index 48cfc85..53faa03 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -119,8 +119,7 @@ extern int cpu_to_core_id(int cpu);
> * in /proc/interrupts will be wrong!!! --Troy */
> #define PPC_MSG_CALL_FUNCTION 0
> #define PPC_MSG_RESCHEDULE 1
> -#define PPC_MSG_CALL_FUNC_SINGLE 2
> -#define PPC_MSG_DEBUGGER_BREAK 3
> +#define PPC_MSG_DEBUGGER_BREAK 2
>
> /* for irq controllers that have dedicated ipis per message (4) */
> extern int smp_request_message_ipi(int virq, int message);
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 38b0ba6..0c53b10 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -123,12 +123,6 @@ static irqreturn_t reschedule_action(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static irqreturn_t call_function_single_action(int irq, void *data)
> -{
> - generic_smp_call_function_single_interrupt();
> - return IRQ_HANDLED;
> -}
> -
> static irqreturn_t debug_ipi_action(int irq, void *data)
> {
> if (crash_ipi_function_ptr) {
> @@ -146,14 +140,12 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
> static irq_handler_t smp_ipi_action[] = {
> [PPC_MSG_CALL_FUNCTION] = call_function_action,
> [PPC_MSG_RESCHEDULE] = reschedule_action,
> - [PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
> [PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
> };
>
> const char *smp_ipi_name[] = {
> [PPC_MSG_CALL_FUNCTION] = "ipi call function",
> [PPC_MSG_RESCHEDULE] = "ipi reschedule",
> - [PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
> [PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
> };
>
> @@ -225,8 +217,6 @@ irqreturn_t smp_ipi_demux(void)
> generic_smp_call_function_interrupt();
> if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
> scheduler_ipi();
> - if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
> - generic_smp_call_function_single_interrupt();
> if (all & (1 << (24 - 8 * PPC_MSG_DEBUGGER_BREAK)))
> debug_ipi_action(0, NULL);
> #else
> @@ -257,7 +247,7 @@ EXPORT_SYMBOL_GPL(smp_send_reschedule);
>
> void arch_send_call_function_single_ipi(int cpu)
> {
> - do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
> + do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
> }
>
> void arch_send_call_function_ipi_mask(const struct cpumask *mask)
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers
>+ /* buffer range for efivars */ >+ case 1000 ... 2000: >+ cmpr = 56; >+ break; > Seiji: let me know how the efivars tests go. efivars works fine. Uncompressed size about 1800 bytes. It matches the value of cmpr, 56. Please feel free to add my "Tested-by" to all three patches. Tested-by: Seiji Aguchi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers
- big_oops_buf_sz = (psinfo->bufsize * 100) / 45; + big_oops_buf_sz = (psinfo->bufsize * 100) / cmpr; Tested on an ERST backed system. Seems to be working (we save a little less information per ERST record than before this change (uncompressed size goes down from ~17500 to ~16400 bytes) - but this patch switched the denominator from 45 to 48 (for ERST) - so that seems plausible. Seiji: let me know how the efivars tests go. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC: set default date on PPC without RTC
Hi,
no matter anymore - got it:
--- a/linux/arch/powerpc/kernel/time.c
+++ b/linux/arch/powerpc/kernel/time.c
@@ -832,7 +832,7 @@ static void __read_persistent_clock(struct timespec *ts)
}
}
if (!ppc_md.get_rtc_time) {
- ts->tv_sec = 0;
+ ts->tv_sec = mktime(2011, 1, 1, 0, 0, 0);
return;
}
ppc_md.get_rtc_time(&tm);
On 11/09/13 11:39, Wladislav Wiebe wrote:
> Hello guys,
>
> would like to ask if there is a proper possibility on PPC to
> set default date (basically the year). The board has no RTC chip,
> and I would need instead of 1970 another year.
>
> For some reason does e.g:
> --- a/linux/arch/powerpc/kernel/time.c
> +++ b/linux/arch/powerpc/kernel/time.c
> @@ -1099,7 +1099,7 @@ void __init time_init(void)
>
>
> #define FEBRUARY 2
> -#defineSTARTOFTIME 1970
> +#defineSTARTOFTIME 2013
> #define SECDAY 86400L
> #define SECYR (SECDAY * 365)
> #defineleapyear(year) ((year) % 4 == 0 && \
>
>
> not work to me. Is there also another place which should be changed?
> (I know it can be changed from userspace also, but I would need it before
> userspace)
>
>
> Thanks and BR,
> Wladislav Wiebe
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 1/6] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)
On Wed, 2013-09-11 at 08:21 +0530, Preeti U Murthy wrote: > arch/powerpc/platforms/ps3/smp.c|2 +- The PS3 part is trivial and looks OK. Acked-by: Geoff Levand ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 2/6] powerpc: Implement broadcast timer interrupt as an IPI message
On Wed, 2013-09-11 at 08:21 +0530, Preeti U Murthy wrote: > arch/powerpc/platforms/ps3/smp.c|2 +- The PS3 part is trivial and looks OK. Acked-by: Geoff Levand ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless
The commit e0908085fc2391c85b85fb814ae1df377c8e0dcb is not needed anymore.
The issue was because dcbst wrongly sets the store bit when causing a DTLB
error, but this is now fixed by commit 0a2ab51ffb8dfdf51402dcfb446629648c96bc78
which handles the buggy dcbx instructions on data page faults on the 8xx.
Signed-off-by: Christophe Leroy
diff -ur linux-3.11.org/arch/powerpc/mm/pgtable.c
linux-3.11/arch/powerpc/mm/pgtable.c
--- linux-3.11.org/arch/powerpc/mm/pgtable.c2013-09-02 22:46:10.0
+0200
+++ linux-3.11/arch/powerpc/mm/pgtable.c2013-09-09 11:25:57.0
+0200
@@ -32,8 +32,6 @@
#include
#include
-#include "mmu_decl.h"
-
static inline int is_exec_fault(void)
{
return current->thread.regs && TRAP(current->thread.regs) == 0x400;
@@ -72,7 +70,7 @@
* support falls into the same category.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE)
||
@@ -81,17 +79,6 @@
if (!pg)
return pte;
if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
-* "dcbst" from flush_dcache_icache) fault as write
-* operation if there is an unpopulated TLB entry
-* for the address in question. To workaround that,
-* we invalidate the TLB here, thus avoiding dcbst
-* misbehaviour.
-*/
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -111,7 +98,7 @@
* as we don't have two bits to spare for _PAGE_EXEC and _PAGE_HWEXEC so
* instead we "filter out" the exec permission for non clean pages.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
struct page *pg;
@@ -193,7 +180,7 @@
* this context might not have been activated yet when this
* is called.
*/
- pte = set_pte_filter(pte, addr);
+ pte = set_pte_filter(pte);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
Only in linux-3.11/arch/powerpc/mm/: pgtable.c.orig
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three 8Mbytes pages. But the setting of the MD_CTR was missing so as the index is decremented every DTLB update, the pinning of the third 8Mbytes page was overwriting the DTLB entry for IMMR. Signed-off-by: Christophe Leroy diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.0 +0200 @@ -862,6 +862,9 @@ addis r11, r11, 0x0080/* Add 8M */ mtspr SPRN_MD_RPN, r11 + addir10, r10, 0x0100 + mtspr SPRN_MD_CTR, r10 + addis r8, r8, 0x0080 /* Add 8M */ mtspr SPRN_MD_EPN, r8 mtspr SPRN_MD_TWC, r9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc 8xx: Reverting commit e0908085fc2391c85b85fb814ae1df377c8e0dcb which has become useless
The commit e0908085fc2391c85b85fb814ae1df377c8e0dcb is not needed anymore.
The issue was because dcbst wrongly sets the store bit when causing a DTLB
error, but this is now fixed by commit 0a2ab51ffb8dfdf51402dcfb446629648c96bc78
which handles the buggy dcbx instructions on data page faults on the 8xx.
Signed-off-by: Christophe Leroy
diff -ur linux-3.11.org/arch/powerpc/mm/pgtable.c
linux-3.11/arch/powerpc/mm/pgtable.c
--- linux-3.11.org/arch/powerpc/mm/pgtable.c2013-09-02 22:46:10.0
+0200
+++ linux-3.11/arch/powerpc/mm/pgtable.c2013-09-09 11:25:57.0
+0200
@@ -32,8 +32,6 @@
#include
#include
-#include "mmu_decl.h"
-
static inline int is_exec_fault(void)
{
return current->thread.regs && TRAP(current->thread.regs) == 0x400;
@@ -72,7 +70,7 @@
* support falls into the same category.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE)
||
@@ -81,17 +79,6 @@
if (!pg)
return pte;
if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
-* "dcbst" from flush_dcache_icache) fault as write
-* operation if there is an unpopulated TLB entry
-* for the address in question. To workaround that,
-* we invalidate the TLB here, thus avoiding dcbst
-* misbehaviour.
-*/
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -111,7 +98,7 @@
* as we don't have two bits to spare for _PAGE_EXEC and _PAGE_HWEXEC so
* instead we "filter out" the exec permission for non clean pages.
*/
-static pte_t set_pte_filter(pte_t pte, unsigned long addr)
+static pte_t set_pte_filter(pte_t pte)
{
struct page *pg;
@@ -193,7 +180,7 @@
* this context might not have been activated yet when this
* is called.
*/
- pte = set_pte_filter(pte, addr);
+ pte = set_pte_filter(pte);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
Only in linux-3.11/arch/powerpc/mm/: pgtable.c.orig
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc: bpf_jit: support MOD operation
On Wed, Sep 04, 2013 at 09:04:04AM +0200, Daniel Borkmann wrote:
> On 09/03/2013 10:52 PM, Daniel Borkmann wrote:
> > On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
> [...]
> >>> Do you have a test case/suite by any chance ?
> >>>
> >>> Ben.
> >>>
> >>
> >> Hi Ben!
> >>
> >> Thanks for your feedback.
> >>
> >> This patch is only compile tested. I have no real hardware, but I'll
> >> probably bring up qemu ppc64 till end of the week...
> >> Meanwhile, I've made simple how-to for testing. You can use it if you wish.
> >> It is mainly based on the [1] and rechecked on x86-64.
Finally I've managed to bring up qemu ppc64 and done simple testing. As a
result I could see difference in opcodes for divide instruction - I've just
sent the patch for that.
WRT mod instruction result is:
For BPF program
(000) ldh [12]
(001) jeq #0x800 jt 2jf 10
(002) ldh [16]
(003) sub #20
(004) mod #5
(005) jeq #0x0 jt 10 jf 6
(006) ldb [20]
(007) and #0x20
(008) jeq #0x20jt 9jf 10
(009) ret #65535
(010) ret #0
The following code is generated (with patch divw to divwu applied)
244 bytes emitted from JIT compiler (pass:3, flen:11)
d15c0018 + :
0: mflrr0
4: std r0,16(r1)
8: std r14,-144(r1)
c: std r15,-136(r1)
10: stdur1,-288(r1)
14: lwz r7,108(r3)
18: lwz r15,104(r3)
1c: subfr15,r7,r15
20: ld r14,216(r3)
24: lis r7,-16384
28: rldicr r7,r7,32,31
2c: orisr7,r7,9
30: ori r7,r7,43428
34: mtlrr7
38: li r6,12
3c: blrl
40: blt-0x00dc
44: nop
48: cmplwi r4,2048
4c: bne-0x00d8
50: nop
54: lis r7,-16384
58: rldicr r7,r7,32,31
5c: orisr7,r7,9
60: ori r7,r7,43428
64: mtlrr7
68: li r6,16
6c: blrl
70: blt-0x00dc
74: nop
78: addir4,r4,-20
7c: li r8,5
80: divwu r7,r4,r8
84: mullw r7,r8,r7
88: subfr4,r7,r4
8c: cmplwi r4,0
90: beq-0x00d8
94: nop
98: lis r7,-16384
9c: rldicr r7,r7,32,31
a0: orisr7,r7,9
a4: ori r7,r7,43456
a8: mtlrr7
ac: li r6,20
b0: blrl
b4: blt-0x00dc
b8: nop
bc: andi. r4,r4,32
c0: cmplwi r4,32
c4: bne-0x00d8
c8: nop
cc: li r3,-1
d0: addis r3,r3,1
d4: b 0x00dc
d8: li r3,0
dc: addir1,r1,288
e0: ld r0,16(r1)
e4: mtlrr0
e8: ld r14,-144(r1)
ec: ld r15,-136(r1)
f0: blr
Raw codes are
flen=11 proglen=244 pass=3 image=d15c0018
JIT code: : 7c 08 02 a6 f8 01 00 10 f9 c1 ff 70 f9 e1 ff 78
JIT code: 0010: f8 21 fe e1 80 e3 00 6c 81 e3 00 68 7d e7 78 50
JIT code: 0020: e9 c3 00 d8 3c e0 c0 00 78 e7 07 c6 64 e7 00 09
JIT code: 0030: 60 e7 a9 a4 7c e8 03 a6 38 c0 00 0c 4e 80 00 21
JIT code: 0040: 41 80 00 9c 60 00 00 00 28 04 08 00 40 82 00 8c
JIT code: 0050: 60 00 00 00 3c e0 c0 00 78 e7 07 c6 64 e7 00 09
JIT code: 0060: 60 e7 a9 a4 7c e8 03 a6 38 c0 00 10 4e 80 00 21
JIT code: 0070: 41 80 00 6c 60 00 00 00 38 84 ff ec 39 00 00 05
JIT code: 0080: 7c e4 43 96 7c e8 39 d6 7c 87 20 50 28 04 00 00
JIT code: 0090: 41 82 00 48 60 00 00 00 3c e0 c0 00 78 e7 07 c6
JIT code: 00a0: 64 e7 00 09 60 e7 a9 c0 7c e8 03 a6 38 c0 00 14
JIT code: 00b0: 4e 80 00 21 41 80 00 28 60 00 00 00 70 84 00 20
JIT code: 00c0: 28 04 00 20 40 82 00 14 60 00 00 00 38 60 ff ff
JIT code: 00d0: 3c 63 00 01 48 00 00 08 38 60 00 00 38 21 01 20
JIT code: 00e0: e8 01 00 10 7c 08 03 a6 e9 c1 ff 70 e9 e1 ff 78
JIT code: 00f0: 4e 80 00 20
Ben,
How do you feel about it?
> >
> > Please also cc netdev on BPF related changes.
> >
> > Actually, your test plan can be further simplified ...
> >
> > For retrieving and disassembling the JIT image, we have bpf_jit_disasm [1].
> >
> > 1) echo 2 > /proc/sys/net/core/bpf_jit_enable
> > 2) ... attach filter ...
> > 3) bpf_jit_disasm -o
> >
> > For generating a simple stupid test filter, you can use bpfc [2] (also
> > see its man page). E.g. ...
> >
> ># cat blub
> >ldi #10
> >mod #8
> >ret a
> ># bpfc blub
> >{ 0x0, 0, 0, 0x000a },
> >{ 0x94, 0, 0, 0x0008 },
> >{ 0x16, 0, 0, 0x },
>
> Plus something like ...
>
> ldxi #0
> mod x
> ret a
>
Thanks Daniel!
Unfortunately, I couldn't trigger JIT compiler with the pair bpfc/netsniff-ng
(even for x86-64). I guess I missed something. I'd be very grateful if you
point at my mistakes.
> For longer-term testing, also trinity has BPF support. ;)
>
Wow! Could do give some hint how to run this for BPF only?
> > And load this array e.g. either into a small C program that attaches this
> > as BPF filter, or simply do bpfc blub > blub2 and run netsniff-ng -f
Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
On Wed, 2013-09-11 at 11:15 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2013-09-10 at 18:47 -0500, Scott Wood wrote: > > > No blank line before } > > > > > +CONFIG_CMDLINE_BOOL=y > > > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs" > > > > I take it there's no way to pass a command line in from whatever loader > > this board uses... but you could put it in the dts instead. > > No, please don't put that in the device-tree. Somebody might want > different settings, this is typically what .config is for. I figured that in the defconfig it presents a barrier to getting rid of the board-specific defconfig, while the dts is still going to be per-board. In this case the device tree is not baked into firmware so it's just as easy to change things in /chosen as in .config (actually slightly easier since you only need to rewrap the kernel rather than rebuild). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH v2 15/25] smp, ppc: kill SMP single function call interrupt
From: Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.
Signed-off-by: Jiang Liu
Cc: Jiang Liu
---
arch/powerpc/include/asm/smp.h | 3 +--
arch/powerpc/kernel/smp.c | 12 +---
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 48cfc85..53faa03 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -119,8 +119,7 @@ extern int cpu_to_core_id(int cpu);
* in /proc/interrupts will be wrong!!! --Troy */
#define PPC_MSG_CALL_FUNCTION 0
#define PPC_MSG_RESCHEDULE 1
-#define PPC_MSG_CALL_FUNC_SINGLE 2
-#define PPC_MSG_DEBUGGER_BREAK 3
+#define PPC_MSG_DEBUGGER_BREAK 2
/* for irq controllers that have dedicated ipis per message (4) */
extern int smp_request_message_ipi(int virq, int message);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..0c53b10 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -123,12 +123,6 @@ static irqreturn_t reschedule_action(int irq, void *data)
return IRQ_HANDLED;
}
-static irqreturn_t call_function_single_action(int irq, void *data)
-{
- generic_smp_call_function_single_interrupt();
- return IRQ_HANDLED;
-}
-
static irqreturn_t debug_ipi_action(int irq, void *data)
{
if (crash_ipi_function_ptr) {
@@ -146,14 +140,12 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
static irq_handler_t smp_ipi_action[] = {
[PPC_MSG_CALL_FUNCTION] = call_function_action,
[PPC_MSG_RESCHEDULE] = reschedule_action,
- [PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
[PPC_MSG_CALL_FUNCTION] = "ipi call function",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
- [PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
};
@@ -225,8 +217,6 @@ irqreturn_t smp_ipi_demux(void)
generic_smp_call_function_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
- if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
- generic_smp_call_function_single_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_DEBUGGER_BREAK)))
debug_ipi_action(0, NULL);
#else
@@ -257,7 +247,7 @@ EXPORT_SYMBOL_GPL(smp_send_reschedule);
void arch_send_call_function_single_ipi(int cpu)
{
- do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
+ do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
}
void arch_send_call_function_ipi_mask(const struct cpumask *mask)
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: export cpu_to_chip_id
On Wed, Sep 11, 2013 at 12:07:45PM +0530, Vasant Hegde wrote: > On 09/10/2013 10:08 PM, Vladimir Murzin wrote: > > While cross-building for PPC64 I've got > > > Vladimir, > > Below commit ID fixes this issue. Great! For whatever reason I thought _GPL is default policy for exported symbols... but, never mind ;) Sorry for the noise Vladimir > > commit 256588fda10f2a712631f8a4e72641a66adebdb8 > Author: Guenter Roeck > Date: Mon Sep 9 18:37:56 2013 -0700 > > powerpc: Export cpu_to_chip_id() to fix build error > > -Vasant > > > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! > > > > mtip32xx refer to topology_physical_package_id, which stands for > > cpu_to_chip-id. > > > > Make cpu_to_chip-id (and topology_physical_package_id) available for > > external users. > > > > Signed-off-by: Vladimir Murzin > > --- > > arch/powerpc/kernel/smp.c |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c > > index 442d8e2..1d9c1c2 100644 > > --- a/arch/powerpc/kernel/smp.c > > +++ b/arch/powerpc/kernel/smp.c > > @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu) > > of_node_put(np); > > return of_get_ibm_chip_id(np); > > } > > +EXPORT_SYMBOL_GPL(cpu_to_chip_id); > > > > /* Helper routines for cpu to core mapping */ > > int cpu_core_index_of_thread(int cpu) > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: net: filter: fix DIVWU instruction opcode
Currently DIVWU stands for *signed* divw opcode: 7d 2a 4b 96 divwu r9,r10,r9 7d 2a 4b d6 divwr9,r10,r9 Use the *unsigned* divw opcode for DIVWU. Signed-off-by: Vladimir Murzin --- arch/powerpc/include/asm/ppc-opcode.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index d7fe9f5..c91842c 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -218,7 +218,7 @@ #define PPC_INST_MULLW 0x7c0001d6 #define PPC_INST_MULHWU0x7c16 #define PPC_INST_MULLI 0x1c00 -#define PPC_INST_DIVWU 0x7c0003d6 +#define PPC_INST_DIVWU 0x7c000396 #define PPC_INST_RLWINM0x5400 #define PPC_INST_RLDICR0x7804 #define PPC_INST_SLW 0x7c30 -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: > Since P1010RDB-PA and P1010RDB-PB boards use different external PHY > interrupt signals. > And actually the PHY interrupt is not used effectively with > corresponding interrupt handler. > So we can remove the interrupts node without side-effect to comply > with both P1010RDB-PA and P1010RDB-PB. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Zhao Qiang > --- > arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- > 1 file changed, 3 deletions(-) > NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] pstore: Remove the messages related to compression failure
Remove the messages indicating compression failure as it will
add to the space during panic path.
Reported-by: Seiji Aguchi
Signed-off-by: Aruna Balakrishnaiah
---
fs/pstore/platform.c |4
1 file changed, 4 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 18924c7..4ad8c93 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -316,10 +316,6 @@ static void pstore_dump(struct kmsg_dumper *dumper,
compressed = true;
total_len = zipped_len;
} else {
- pr_err("pstore: compression failed for Part %d"
- " returned %d\n", part, zipped_len);
- pr_err("pstore: Capture uncompressed"
- " oops/panic report of Part %d\n",
part);
compressed = false;
total_len = copy_kmsg_to_buffer(hsize, len);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] pstore: Use zlib_inflateInit2 instead of zlib_inflateInit
Since zlib_deflateInit2() is used for specifying window bit during compression, zlib_inflateInit2() is appropriate for decompression. Reported-by: Seiji Aguchi Signed-off-by: Aruna Balakrishnaiah --- fs/pstore/platform.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c index 4efaa75..18924c7 100644 --- a/fs/pstore/platform.c +++ b/fs/pstore/platform.c @@ -168,7 +168,7 @@ static int pstore_decompress(void *in, void *out, size_t inlen, size_t outlen) int err, ret; ret = -EIO; - err = zlib_inflateInit(&stream); + err = zlib_inflateInit2(&stream, WINDOW_BITS); if (err != Z_OK) goto error; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers
When backends (ex: efivars) have smaller registered buffers, the big_oops_buf
is quite too big for them as number of repeated occurences in the text captured
will be less. Patch takes care of adjusting the buffer size based on the
registered buffer size. cmpr values has been arrived after doing experiments
with
plain text for buffers of size 1k - 4k (Smaller the buffer size repeated
occurence
will be less) and with sample crash log for buffers ranging from 4k - 10k.
Reported-by: Seiji Aguchi
Signed-off-by: Aruna Balakrishnaiah
---
fs/pstore/platform.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 4ffb7ab..4efaa75 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -195,8 +195,29 @@ error:
static void allocate_buf_for_compression(void)
{
size_t size;
+ size_t cmpr;
+
+ switch (psinfo->bufsize) {
+ /* buffer range for efivars */
+ case 1000 ... 2000:
+ cmpr = 56;
+ break;
+ case 2001 ... 3000:
+ cmpr = 54;
+ break;
+ case 3001 ... 3999:
+ cmpr = 52;
+ break;
+ /* buffer range for nvram, erst */
+ case 4000 ... 1:
+ cmpr = 48;
+ break;
+ default:
+ cmpr = 60;
+ break;
+ }
- big_oops_buf_sz = (psinfo->bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo->bufsize * 100) / cmpr;
big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
if (big_oops_buf) {
size = max(zlib_deflate_workspacesize(WINDOW_BITS, MEM_LEVEL),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PPC: set default date on PPC without RTC
Hello guys, would like to ask if there is a proper possibility on PPC to set default date (basically the year). The board has no RTC chip, and I would need instead of 1970 another year. For some reason does e.g: --- a/linux/arch/powerpc/kernel/time.c +++ b/linux/arch/powerpc/kernel/time.c @@ -1099,7 +1099,7 @@ void __init time_init(void) #define FEBRUARY 2 -#defineSTARTOFTIME 1970 +#defineSTARTOFTIME 2013 #define SECDAY 86400L #define SECYR (SECDAY * 365) #defineleapyear(year) ((year) % 4 == 0 && \ not work to me. Is there also another place which should be changed? (I know it can be changed from userspace also, but I would need it before userspace) Thanks and BR, Wladislav Wiebe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Export cpu_to_chip_id() to fix build error
On 09/11/2013 03:33 AM, Benjamin Herrenschmidt wrote: On Mon, 2013-09-09 at 18:37 -0700, Guenter Roeck wrote: powerpc allmodconfig build fails with: ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! The problem was introduced with commit 15863ff3b (powerpc: Make chip-id information available to userspace). Thanks, I'll send that to Linus asap. Verified on today's Linus tree. This issue is fixed. Thanks a lot. -Vasant Ben. Export the missing symbol. Cc: Vasant Hegde Cc: Shivaprasad G Bhat Signed-off-by: Guenter Roeck --- arch/powerpc/kernel/smp.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 442d8e2..8e59abc 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu) of_node_put(np); return of_get_ibm_chip_id(np); } +EXPORT_SYMBOL(cpu_to_chip_id); /* Helper routines for cpu to core mapping */ int cpu_core_index_of_thread(int cpu) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
From: Tang Yuantian
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian
Signed-off-by: Li Yang
---
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt| 80 +++
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 34 ++-
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 34 ++-
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 59 ++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 59 ++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 111 -
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 41 +++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 59 ++-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 84 +++-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++
17 files changed, 593 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 000..51eab75
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,80 @@
+Device Tree Clock bindings for Freescale PowerPC corenet platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one or more of the following:
+ - "fsl,-clockgen": for chip specific clock block
+ - "fsl,qoriq-clockgen-[1,2].0": for chassis 1.0 and 2.0 clock
+ block respectively.
+ - "fsl,qoriq-chassis[1,2]-core-pll" - for a core PLL clock
+ - "fsl,qoriq-chassis[1,2]-core-mux" - for a core multiplexer clock.
+ Divided from the core PLL clock
+ - "fixed-clock" - from common clock binding; should be output clock
+ of oscillator
+- reg : shall be the control register offset from clock block base address.
+- clocks : shall be the input parent clock phandle for the clock.
+- #clock-cells : from common clock binding; shall be set to 0 or 1.
+- clock-names : from common clock binding
+- clock-output-names : from common clock binding
+
+Example for clock provider:
+
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0",
+ "fixed-clock";
+ reg = <0xe1000 0x1000>;
+ clock-frequency = <0>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 0x4>;
+ compatible = "fsl,qoriq-chassis1-core-pll";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 0x4>;
+ compatible = "fsl,qoriq-chassis1-core-pll";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 0x4>;
+ compatible = "fsl,qoriq-chassis1-core-mux";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux0";
+ };
+
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20 0x4>;
+ compatible = "fsl,qoriq-chassis1-core-mux";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
+ clock-output-names = "cmux1";
+ };
+ };
+ }
+
+Example for clock consumer:
+
+/ {
+ cpu0: PowerPC,e5500@0 {
+ ...
+
[PATCH 2/2] powerpc/configs: Enable T1040QDS by default in corenet
T1040 supports both 32 & 64 bit kernel. so enable T1040QDS by default in the config files. Signed-off-by: Prabhakar Kushwaha --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/configs/corenet64_smp_defconfig |1 + 2 files changed, 2 insertions(+) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 60027c2..6e71494 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -28,6 +28,7 @@ CONFIG_P3041_DS=y CONFIG_P4080_DS=y CONFIG_P5020_DS=y CONFIG_P5040_DS=y +CONFIG_T104x_QDS=y CONFIG_HIGHMEM=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6c8b020..6bfb82b 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -24,6 +24,7 @@ CONFIG_MAC_PARTITION=y CONFIG_B4_QDS=y CONFIG_P5020_DS=y CONFIG_P5040_DS=y +CONFIG_T104x_QDS=y CONFIG_T4240_QDS=y # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set CONFIG_BINFMT_MISC=m -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
