* Re: [PATCH 3/6] PowerPC 440EPx: 440EPx/440EP dcr defines
From: Josh Boyer @ 2007-08-02 20:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070801020936.GC31391@localhost.localdomain>
On Wed, 1 Aug 2007 12:09:36 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Jul 30, 2007 at 07:12:45PM +0400, Valentine Barshak wrote:
> > This patch adds DCR defines needed for 440EP/440EPx clock
> > initialization. These defines have been introduced in the Bamboo
> > support by Josh Boyer and are needed for Sequoia as well.
>
> These should really go in the same patch that uses them. I dislike
> this business of splitting patches up when the parts are functionally
> dependent on each other.
Yeah. We have a small race here anyway, since two different patch sets
need this but are currently not depending as such. E.g. Bamboo or
Sequoia should be first, and the other should be patches after that
series.
josh
^ permalink raw reply
* Re: [PATCH 4/6] PowerPC 440EPx: Sequoia bootwrapper
From: Josh Boyer @ 2007-08-02 20:29 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070730151445.GA5075@ru.mvista.com>
On Mon, 30 Jul 2007 19:14:45 +0400
> +#define SPRN_CCR1 0x378
> +void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
> +{
> + u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
> + u32 reg;
> + u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
> +
> + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLD0);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x000F0000) >> 16;
> + fwdva = tmp ? tmp : 16;
> + tmp = (reg & 0x00000700) >> 8;
> + fwdvb = tmp ? tmp : 8;
> + tmp = (reg & 0x1F000000) >> 24;
> + fbdv = tmp ? tmp : 32;
> + lfbdv = (reg & 0x0000007F);
> +
> + mtdcr(DCRN_CPR0_ADDR, CPR0_OPBD0);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x03000000) >> 24;
> + opbdv0 = tmp ? tmp : 4;
> +
> + mtdcr(DCRN_CPR0_ADDR, CPR0_PERD0);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x07000000) >> 24;
> + perdv0 = tmp ? tmp : 8;
> +
> + mtdcr(DCRN_CPR0_ADDR, CPR0_PRIMBD0);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x07000000) >> 24;
> + prbdv0 = tmp ? tmp : 8;
> +
> + mtdcr(DCRN_CPR0_ADDR, CPR0_SCPID);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x03000000) >> 24;
> + spcid0 = tmp ? tmp : 4;
> +
> + /* Calculate M */
> + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLC0);
> + reg = mfdcr(DCRN_CPR0_DATA);
> + tmp = (reg & 0x03000000) >> 24;
> + if (tmp == 0) { /* PLL output */
> + tmp = (reg & 0x20000000) >> 29;
> + if (!tmp) /* PLLOUTA */
> + m = fbdv * lfbdv * fwdva;
> + else
> + m = fbdv * lfbdv * fwdvb;
> + }
> + else if (tmp == 1) /* CPU output */
> + m = fbdv * fwdva;
> + else
> + m = perdv0 * opbdv0 * fwdvb;
> +
> + vco = (m * sysclk) + (m >> 1);
> + cpu = vco / fwdva;
> + plb = vco / fwdvb / prbdv0;
> + opb = plb / opbdv0;
> + ebc = plb / perdv0;
> +
> + /* FIXME */
> + uart0 = ser_clk;
> +
> + /* Figure out timebase. Either CPU or default TmrClk */
> + asm volatile (
> + "mfspr %0,%1\n"
> + :
> + "=&r"(reg) : "i"(SPRN_CCR1));
> + if (reg & 0x0080)
> + tb = 25000000; /* TmrClk is 25MHz */
> + else
> + tb = cpu;
> +
> + dt_fixup_cpu_clocks(cpu, tb, 0);
> + dt_fixup_clock("/plb", plb);
> + dt_fixup_clock("/plb/opb", opb);
> + dt_fixup_clock("/plb/opb/ebc", ebc);
> + dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
> + dt_fixup_clock("/plb/opb/serial@ef600400", uart0);
> + dt_fixup_clock("/plb/opb/serial@ef600500", uart0);
> + dt_fixup_clock("/plb/opb/serial@ef600600", uart0);
> +}
We don't need to duplicate this function in two different wrappers.
I'll move it into 4xx.c in my next round of patches, so that bamboo and
sequoia can just call a common function.
> +/*
> + * 440EPx DDR1/2 memory controller code
> + * TODO: move to generic 44x code
> + */
> +
> +/* DDR0_02 */
> +#define DDR_START 0x1
> +#define DDR_START_SHIFT 0
> +#define DDR_MAX_CS_REG 0x3
> +#define DDR_MAX_CS_REG_SHIFT 24
> +#define DDR_MAX_COL_REG 0xf
> +#define DDR_MAX_COL_REG_SHIFT 16
> +#define DDR_MAX_ROW_REG 0xf
> +#define DDR_MAX_ROW_REG_SHIFT 8
> +/* DDR0_08 */
> +#define DDR_DDR2_MODE 0x1
> +#define DDR_DDR2_MODE_SHIFT 0
> +/* DDR0_10 */
> +#define DDR_CS_MAP 0x3
> +#define DDR_CS_MAP_SHIFT 8
> +/* DDR0_14 */
> +#define DDR_REDUC 0x1
> +#define DDR_REDUC_SHIFT 16
> +/* DDR0_42 */
> +#define DDR_APIN 0x7
> +#define DDR_APIN_SHIFT 24
> +/* DDR0_43 */
> +#define DDR_COL_SZ 0x7
> +#define DDR_COL_SZ_SHIFT 8
> +#define DDR_BANK8 0x1
> +#define DDR_BANK8_SHIFT 0
> +
> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> +
> +static void ibm440epx_fixup_memsize(void)
And we should move this at the same time. Isn't denali used by another
CPU as well?
josh
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Josh Boyer @ 2007-08-02 20:32 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070801050542.GJ31391@localhost.localdomain>
On Wed, 1 Aug 2007 15:05:42 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> > >> + { /* 440EPX - without Security/Kasumi */
> > >> + .pvr_mask = 0xf0000fff,
> > >> + .pvr_value = 0x200008D4,
> > >> + .cpu_name = "440EPX - no Security/Kasumi",
> > >> + .cpu_features = CPU_FTRS_44X,
> > >> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
> > >> 440EPX has an FPU */
> > >> + .icache_bsize = 32,
> > >> + .dcache_bsize = 32,
> > >> + },
> > >
> > > Since the with/without Security/Kasumi versions have no differences in
> > > their cputable entry other than the PVR, couldn't you just remove the
> > > relevant PVR bit from the mask and use a single entry?
> >
> > And get rid of the stupid "has an FPU" comment at the same time
> > please :-)
>
> Actually that comment may be worthwhile if expanded a little. I think
> the point is that 440EPx *unlike most other 4xx chips* has an FPU. So
> the point of the comment is not explaining the feature bit, which is
> obvious, but as a "no, really, it does".
Right. 440EP(x) are the only currently available 44x chips that
contain an FPU, so I also think the comment can stay.
josh
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Josh Boyer @ 2007-08-02 20:34 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070730151628.GA5100@ru.mvista.com>
On Mon, 30 Jul 2007 19:16:28 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> diff -ruN linux.orig/arch/powerpc/kernel/cputable.c linux/arch/powerpc/kernel/cputable.c
> --- linux.orig/arch/powerpc/kernel/cputable.c 2007-07-27 20:37:10.000000000 +0400
> +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27 20:44:26.000000000 +0400
> @@ -1132,6 +1132,42 @@
> .dcache_bsize = 32,
> .platform = "ppc440",
> },
> + { /* 440EPX - with Security/Kasumi */
> + .pvr_mask = 0xf0000fff,
> + .pvr_value = 0x200008D0,
> + .cpu_name = "440EPX - with Security/Kasumi",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + },
> + { /* 440EPX - without Security/Kasumi */
> + .pvr_mask = 0xf0000fff,
> + .pvr_value = 0x200008D4,
> + .cpu_name = "440EPX - no Security/Kasumi",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + },
> + { /* 440GRX - with Security/Kasumi */
> + .pvr_mask = 0xf0000fff,
> + .pvr_value = 0x200008D8,
> + .cpu_name = "440GRX - with Security/Kasumi",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + },
> + { /* 440GRX - without Security/Kasumi */
> + .pvr_mask = 0xf0000fff,
> + .pvr_value = 0x200008DC,
> + .cpu_name = "440GRX - no Security/Kasumi",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + },
Should the 440GRX PVR additions be done in a separate patch? Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?
> diff -ruN linux.orig/arch/powerpc/platforms/44x/sequoia.c linux/arch/powerpc/platforms/44x/sequoia.c
> --- linux.orig/arch/powerpc/platforms/44x/sequoia.c 1970-01-01 03:00:00.000000000 +0300
> +++ linux/arch/powerpc/platforms/44x/sequoia.c 2007-07-27 20:44:26.000000000 +0400
> @@ -0,0 +1,66 @@
> +/*
> + * Sequoia board specific routines
> + *
> + * Wade Farnsworth <wfarnsworth@mvista.com>
> + * Copyright 2004-2007 MontaVista Software Inc.
> + *
> + * Rewritten and ported to the merged powerpc tree:
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + * Copyright 2007 IBM Corporation
I didn't really do this. Might want to give yourself credit instead :).
josh
^ permalink raw reply
* Re: [PATCH 6/6] PowerPC 440EPx: Sequoia new EMAC support
From: Josh Boyer @ 2007-08-02 20:35 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070730152339.GA5126@ru.mvista.com>
On Mon, 30 Jul 2007 19:23:39 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The patch adds PHY support for the Sequoia board to the new EMAC driver and
> enables NEW_EMAC for 440EPx Kconfig.
> The phy code has been written by Stefan Roese.
> This has been tested with the following version of the EMAC dirver:
>
> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/platforms/44x/Kconfig | 5 +---
> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 3 deletions(-)
>
> --- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.000000000 +0400
> +++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.000000000 +0400
> @@ -47,9 +47,8 @@
> config 440EPX
> bool
> select PPC_FPU
> -# Disabled until the new EMAC Driver is merged.
> -# select IBM_NEW_EMAC_EMAC4
> -# select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_ZMII
Probably don't want this bit yet. The EMAC driver isn't really merged
yet.
josh
^ permalink raw reply
* [PATCH] Fix FSL BookE machine check reporting
From: Becky Bruce @ 2007-08-02 20:37 UTC (permalink / raw)
To: linuxppc-dev
Reserved MCSR bits on FSL BookE parts may have spurious values
when mcheck occurs. Mask these off when printing the MCSR to
avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
for e500 - this bit doesn't actually have any meaning.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/kernel/traps.c | 4 +---
include/asm-powerpc/reg_booke.h | 12 +++++++++++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2bb1cb9..d8502e3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -299,7 +299,7 @@ static inline int check_io_access(struct pt_regs *regs)
#ifndef CONFIG_FSL_BOOKE
#define get_mc_reason(regs) ((regs)->dsisr)
#else
-#define get_mc_reason(regs) (mfspr(SPRN_MCSR))
+#define get_mc_reason(regs) (mfspr(SPRN_MCSR) & MCSR_MASK)
#endif
#define REASON_FP ESR_FP
#define REASON_ILLEGAL (ESR_PIL | ESR_PUO)
@@ -414,8 +414,6 @@ void machine_check_exception(struct pt_regs *regs)
printk("Data Cache Push Parity Error\n");
if (reason & MCSR_DCPERR)
printk("Data Cache Parity Error\n");
- if (reason & MCSR_GL_CI)
- printk("Guarded Load or Cache-Inhibited stwcx.\n");
if (reason & MCSR_BUS_IAERR)
printk("Bus - Instruction Address Error\n");
if (reason & MCSR_BUS_RAERR)
diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h
index 064405c..8fdc2b4 100644
--- a/include/asm-powerpc/reg_booke.h
+++ b/include/asm-powerpc/reg_booke.h
@@ -223,7 +223,6 @@
#define MCSR_ICPERR 0x40000000UL /* I-Cache Parity Error */
#define MCSR_DCP_PERR 0x20000000UL /* D-Cache Push Parity Error */
#define MCSR_DCPERR 0x10000000UL /* D-Cache Parity Error */
-#define MCSR_GL_CI 0x00010000UL /* Guarded Load or Cache-Inhibited stwcx. */
#define MCSR_BUS_IAERR 0x00000080UL /* Instruction Address Error */
#define MCSR_BUS_RAERR 0x00000040UL /* Read Address Error */
#define MCSR_BUS_WAERR 0x00000020UL /* Write Address Error */
@@ -232,6 +231,12 @@
#define MCSR_BUS_WBERR 0x00000004UL /* Write Data Bus Error */
#define MCSR_BUS_IPERR 0x00000002UL /* Instruction parity Error */
#define MCSR_BUS_RPERR 0x00000001UL /* Read parity Error */
+
+/* e500 parts may set unused bits in MCSR; mask these off */
+#define MCSR_MASK (MCSR_MCP | MCSR_ICPERR | MCSR_DCP_PERR | \
+ MCSR_DCPERR | MCSR_BUS_IAERR | MCSR_BUS_RAERR | \
+ MCSR_BUS_WAERR | MCSR_BUS_IBERR | MCSR_BUS_RBERR | \
+ MCSR_BUS_WBERR | MCSR_BUS_IPERR | MCSR_BUS_RPERR)
#endif
#ifdef CONFIG_E200
#define MCSR_MCP 0x80000000UL /* Machine Check Input Pin */
@@ -243,6 +248,11 @@
#define MCSR_BUS_DRERR 0x00000008UL /* Read Bus Error on data load */
#define MCSR_BUS_WRERR 0x00000004UL /* Write Bus Error on buffered
store or cache line push */
+
+/* e200 parts may set unused bits in MCSR; mask these off */
+#define MCSR_MASK (MCSR_MCP | MCSR_CP_PERR | MCSR_CPERR | \
+ MCSR_EXCP_ERR | MCSR_BUS_IRERR | MCSR_BUS_DRERR | \
+ MCSR_BUS_WRERR)
#endif
/* Bit definitions for the DBSR. */
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH] Use 1TB segments
From: Will Schmidt @ 2007-08-02 20:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18095.59959.698141.565343@cargo.ozlabs.ibm.com>
Hi Paul,
just a few questions.
On Wed, 2007-08-01 at 12:04 +1000, Paul Mackerras wrote:
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6). We don't currently use 1TB segments
> for user addresses < 1T, since that would effectively prevent 32-bit
> processes from using huge pages unless we also had a way to revert to
> using 256MB segments.
I think I have a question about "user address < 1T".. once I think on
it a bit more it'll either click, or I'll have a question
articulated. :-)
> -static inline void __tlbiel(unsigned long va, unsigned int psize)
> +static inline void __tlbiel(unsigned long va, int psize, int ssize)
> -static inline void tlbie(unsigned long va, int psize, int local)
> +static inline void tlbie(unsigned long va, int psize, int ssize, int local)
> static long native_hpte_insert(unsigned long hpte_group, unsigned long va,
> unsigned long pa, unsigned long rflags,
> - unsigned long vflags, int psize)
> + unsigned long vflags, int psize, int ssize)
> static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
> - unsigned long va, int psize, int local)
> + unsigned long va, int psize, int ssize,
> + int local)
Is there technical reason why the 'local' variable remains at the end of
the parm list for these? In other cases 'ssize' simply gets added to
the end of the parm list.
> +static int __init htab_dt_scan_seg_sizes(unsigned long node,
> + const char *uname, int depth,
> + void *data)
> +{
> + char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> + u32 *prop;
> + unsigned long size = 0;
> +
> + /* We are scanning "cpu" nodes only */
> + if (type == NULL || strcmp(type, "cpu") != 0)
> + return 0;
> +
> + prop = (u32 *)of_get_flat_dt_prop(node, "ibm,processor-segment-sizes",
> + &size);
> + if (prop != NULL && size >= 8) {
> + if (prop[0] == 0x1c && prop[1] == 0x28) {
This is 0x1c indicating 2^28 for 256M; and 0x28 indicating 2^40 for 1TB
segments.
Will there ever be a segment size between the two? Or will the
representation every vary from this? i.e. wondering if prop[0] will
always be for 256M and prop[1] for 1TB.
> +#define slb_vsid_shift(ssize) \
> + ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
> @@ -100,12 +106,13 @@ void slb_flush_and_rebolt(void)
> vflags = SLB_VSID_KERNEL | vmalloc_llp;
>
> ksp_esid_data = mk_esid_data(get_paca()->kstack, 2);
> - if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
> + mask = (mmu_kernel_ssize == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T;
Is this one worthy of a #define like the slb_vsid_shift() above?
> +#define VSID_MULTIPLIER_256M ASM_CONST(200730139) /* 28-bit prime */
> +#define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
Anything special in how this 24-bit prime value was selected? (same
question could be for the 28-bit prime, though I see that value was
updated at least once a few years back)
-Will
^ permalink raw reply
* Re: FEC driver not working after upgrade
From: Wolfgang Denk @ 2007-08-02 20:51 UTC (permalink / raw)
To: Mit Matelske; +Cc: linuxppc-dev
In-Reply-To: <11952546.post@talk.nabble.com>
In message <11952546.post@talk.nabble.com> you wrote:
>
> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and cannot
...
> I am running a 5200B. Thanks for any help.
Do you really have the latest snapshot, i. e. top of tree from the git
repository?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are very few personal problems that cannot be solved through a
suitable application of high explosives.
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Hollis Blanchard @ 2007-08-02 20:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <41060.0659474314$1184697204@news.gmane.org>
On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
> For those interested, here's my current 4xx patch series. There are a few
> cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
> another round of Bamboo patches. These are all based off of Paul's current
> tree.
Bamboo is booting for me with your patches. Let's get them in soon...
> Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
> that Ben and David have poked at. If it doesn't get merged soon, I'll take
> a look at getting it working again.
Please!
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Roland Dreier @ 2007-08-02 21:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, linuxppc-dev, raisch, paulus, general,
Hoang-Nam Nguyen
In-Reply-To: <200708021608.16436.arnd@arndb.de>
> remap_4k_pfn is defined in terms of remap_pfn_range if the base page
> size if 4k, so you don't need this #ifdef afaics.
Good point. I'll wait for an updated patch.
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Josh Boyer @ 2007-08-02 21:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <f8tgfm$e2g$1@sea.gmane.org>
On Thu, 2 Aug 2007 20:57:26 +0000 (UTC)
Hollis Blanchard <hollisb@us.ibm.com> wrote:
> On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
>
> > For those interested, here's my current 4xx patch series. There are a few
> > cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
> > another round of Bamboo patches. These are all based off of Paul's current
> > tree.
>
> Bamboo is booting for me with your patches. Let's get them in soon...
I plan on submitting a series to Paul tomorrow-ish for 2.6.24. Too
late for 2.6.23.
> > Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
> > that Ben and David have poked at. If it doesn't get merged soon, I'll take
> > a look at getting it working again.
>
> Please!
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Either way, I'm hoping we can get something into 2.6.24.
josh
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
From: David Brownell @ 2007-08-02 21:47 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070802142641.GA6309@localhost.localdomain>
On Thursday 02 August 2007, Anton Vorontsov wrote:
> Probably someday mpc83xx_spi->sysclk should be renamed to
> mpc83xx_spi->spiclk to be less confusing.
Why not "today", with this patch? That would fix some of
the root cause of this bug...
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Benjamin Herrenschmidt @ 2007-08-02 22:37 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186087283.22717.80.camel@farscape.rchland.ibm.com>
> Is there technical reason why the 'local' variable remains at the end of
> the parm list for these? In other cases 'ssize' simply gets added to
> the end of the parm list.
Looks nicer to have psize and ssize together :-)
Ben.
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Benjamin Herrenschmidt @ 2007-08-02 22:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070802163951.11c398ee@weaponx.rchland.ibm.com>
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
>
> Someone brought up the fact that the EMAC rewrite is mostly just
> changing probing code and the guts are still similar to the current
> EMAC driver. I haven't really looked into it yet, but if that's true,
> I'd be curious as to why it was done that way.
Ask :-) What specifically do you want to know ?
Ben.
^ permalink raw reply
* Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver
From: Linas Vepstas @ 2007-08-02 22:53 UTC (permalink / raw)
To: Matthew Wilcox
Cc: James.Bottomley, linux-scsi, willy, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-pci
In-Reply-To: <20070705185406.GA3527@parisc-linux.org>
On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote:
> On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote:
> > Well you've sent it a couple of times, and I've sent it in five more times
> > over the past year. Once we were told "awaiting maintainer ack".
> >
> > This situation is fairly stupid. How about we make you the maintainer?
>
> Last time I looked at it, I still wasn't comfortable with it. I'm going
> to look at it again.
Please do. Its burning the proverbial hole in my pocket; I'd really
like to get this off my list of things I worry about.
> I'm fairly sure Linas doesn't want to be the sym2 maintainer. It's
> still an ugly pile of junk that needs cleaning up.
Heh. I have no difficulty living with ugly code: its actually a
great excuse to fix things instead of doing "real work" :-)
Rather, the menagerie of hardware I have access to is constantly
changing; I don't have a symbios card just right now, and it might
take a few days to even find someone who did. Which is an incredibly
unpleasent, unrewarding activity.
--linas
^ permalink raw reply
* Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
From: David Brownell @ 2007-08-02 23:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Domen Puncer, Russell King, linux-mips
In-Reply-To: <20070801125753.GB27199@lst.de>
On Wednesday 01 August 2007, Christoph Hellwig wrote:
> On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > > It doesn't make any assumption on struct clk, it's just a
> > > wrapper around functions from clk.h.
> > > Point of this patch was to abstract exported functions, since
> > > arch/powerpc/ can support multiple platfroms in one binary.
> >
> > So... the thread just ended without any consensus, ACK or whatever.
> >
> > Choices I see:
> > - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have
> > every implemenation fill some global struct.
> > - leave this patch as it is, abstraction only for arch/powerpc/.
That seems the best solution for now, I agree.
> > - or I can just forget about this, and leave it for the next sucker
> > who will want nicer clock handling in some driver
>
> It seems like arm really wants this optimized to the last cycle
> and no abstraction inbetween so we're probably stuck with the status
> quo. I'm pretty sure this will get too messy sooner and later and
> people will clean the mess up, but due to the political issues I
> don't think it's fair to put that burden on you just for submitting
> the powerpc implementation.
>
> So, please leave the patch as-is.
>
^ permalink raw reply
* Re: FEC driver not working after upgrade
From: Mit Matelske @ 2007-08-02 23:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802205107.C069F352659@atlas.denx.de>
wd wrote:
>
> In message <11952546.post@talk.nabble.com> you wrote:
>>
>> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and
>> cannot
> ...
>> I am running a 5200B. Thanks for any help.
>
> Do you really have the latest snapshot, i. e. top of tree from the git
> repository?
>
Yes sir. I have the 2007-7-10 snapshot.
Someone posted what I assume to be a similar problem back in March:
http://www.nabble.com/Problems-with-PHY-on-STK5200-tf3326321.html#a9247789
but there was no solution. Thanks for any and all help.
Mit Matelske
--
View this message in context: http://www.nabble.com/FEC-driver-not-working-after-upgrade-tf4202285.html#a11975001
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Will Schmidt @ 2007-08-02 23:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186094245.5495.637.camel@localhost.localdomain>
On Fri, 2007-08-03 at 08:37 +1000, Benjamin Herrenschmidt wrote:
> > Is there technical reason why the 'local' variable remains at the end of
> > the parm list for these? In other cases 'ssize' simply gets added to
> > the end of the parm list.
>
> Looks nicer to have psize and ssize together :-)
Aah! And here I thought there was some obscure register usage
optimization going on.. :-)
-Will
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Josh Boyer @ 2007-08-03 0:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <1186094296.5495.638.camel@localhost.localdomain>
On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> >
> > Someone brought up the fact that the EMAC rewrite is mostly just
> > changing probing code and the guts are still similar to the current
> > EMAC driver. I haven't really looked into it yet, but if that's true,
> > I'd be curious as to why it was done that way.
>
> Ask :-) What specifically do you want to know ?
:)
Are the guts mostly the same, and if so why wasn't the existing driver just
modified to do the device tree probing, perhaps in addition to the arch/ppc
method?
I can answer the "are they similar" myself with inspection, but I just haven't
found the time yet. So just some history about the patch would be good in
general I think.
josh
^ permalink raw reply
* suspend/resume (Xilinx V4)
From: John Williams @ 2007-08-02 23:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Any comments on the status/feasibility of suspend/resume for LinuxPPC on
Xilinx devices?
The only suspend-related traffic I see here in the last 12 months is for
the lite5200b board.
Any guesstimates of level of difficulty for such a task on Xilinx
PPC405? The core lite5200b patchset didn't look too hairy (just a
modest bit of ASM :), but there would also be Xilinx device driver hooks
to consider.
Also, are there kernel revision dependencies here? Project is currently
on an MVL 2.6.10 tree - but have seen mention of 2.6.17 (?) being
earliest with PPC suspend/resume capability.
All info appreciated. Thanks,
John
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Benjamin Herrenschmidt @ 2007-08-03 0:29 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070803002652.GX3925@crusty.rchland.ibm.com>
On Thu, 2007-08-02 at 19:26 -0500, Josh Boyer wrote:
> On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> > >
> > > Someone brought up the fact that the EMAC rewrite is mostly just
> > > changing probing code and the guts are still similar to the current
> > > EMAC driver. I haven't really looked into it yet, but if that's true,
> > > I'd be curious as to why it was done that way.
> >
> > Ask :-) What specifically do you want to know ?
>
> :)
>
> Are the guts mostly the same, and if so why wasn't the existing driver just
> modified to do the device tree probing, perhaps in addition to the arch/ppc
> method?
>
> I can answer the "are they similar" myself with inspection, but I just haven't
> found the time yet. So just some history about the patch would be good in
> general I think.
Guts are the same with subtle differences :-)
The main reason not to modify the existing one was because I wanted to
be conservative and not take any chance at breaking arch/ppc. Also, we
did that in earlier versions internally (have both OCP and device-tree
probing) and it's a terrible mess. Since arch/ppc is doomed, I wanted to
avoid designing something that can do both for no real benefit.
There are other subtle differences, such as the locking of the MDIO
accesses, and locking bits and pieces in general (EMAC wasn't tested in
SMP environments, and while it was tested with preempt, there are a few
subtle differences and issues that went unnoticed).
I also haven't brought back the workarounds for the loss of the Rx clock
with some PHYs at this stage. I need to get my hand on HW that has this
issue to be able to decide what to do I believe. The thing is, global
whacking of clock control registers like the old driver does is a bit
scary, totally per-chip-type, and requires locking vs. other parts of
the system that may want to access the same registers etc...
However, some of the chip folks told me it might be possible instead to
just use loopback mode when there is no link. So I want to investigate
that possibility first, but for that, I need HW that has the symptoms
and so far, I think I don't.
Finally, we still need to add in proper DMA unmapping. The current
driver never unmaps which is a problem on Axon when using the iommu.
Cheers,
Ben.
^ permalink raw reply
* Re: suspend/resume (Xilinx V4)
From: Grant Likely @ 2007-08-03 0:53 UTC (permalink / raw)
To: John Williams; +Cc: linuxppc-embedded
In-Reply-To: <46B26E97.3040706@itee.uq.edu.au>
On 8/2/07, John Williams <jwilliams@itee.uq.edu.au> wrote:
> Hi,
>
> Any comments on the status/feasibility of suspend/resume for LinuxPPC on
> Xilinx devices?
Pretty much non-existant as far as status goes. Feasibility depends
entirely on what power management features the Xilinx silicon
supports. I haven't looked into whether or not the 405 core can be
put into sleep states.
>
> The only suspend-related traffic I see here in the last 12 months is for
> the lite5200b board.
>
> Any guesstimates of level of difficulty for such a task on Xilinx
> PPC405? The core lite5200b patchset didn't look too hairy (just a
> modest bit of ASM :), but there would also be Xilinx device driver hooks
> to consider.
I suspect the driver code will be where most of the effort lies.
> Also, are there kernel revision dependencies here? Project is currently
> on an MVL 2.6.10 tree - but have seen mention of 2.6.17 (?) being
> earliest with PPC suspend/resume capability.
Suspend support for ppc has existed for a long time, but there aren't
many embedded ppc boards which support it (5200 being a notable
example).
Personally, I'm keeping up to date with mainline (2.6.22+) on my Virtex tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: Benjamin Herrenschmidt @ 2007-08-03 1:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070802034848.GA837@localhost.localdomain>
On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > PPC44x cascade UIC irq handler fix.
> >
> > According to PPC44x UM, if an interrupt is configured as level-sensitive,
> > and a clear is attempted on the UIC_SR, the UIC_SR field is not
> > cleared if the incoming interrupt signal is at the asserted polarity.
> > This causes us to enter a cascade handler twice, since we first ack
> > parent UIC interrupt and ack child UIC one after that.
> > The patch checks child UIC msr value and returns IRQ_HANDLED
> > if there're no pending interrupts. Otherwise we get a kernel panic
> > with a "Fatal exception in interrupt" (illegal vector).
> > The patch also fixes status flags.
> >
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> Hrm... This doesn't seem like the right fix to me. Instead, I think
> the cascaded IRQ handler should ack the interrupt on the child first.
> I'm a little surprised it doesn't at the moment.
Well, we certainly do also need to make the code more solid vs.
spurrious interrupts.
The main thing is, if the cascade is a level interrupt, it should
probably use a smarter cascade handler that masks it, handle the child
interrupts, then unmasks it.
Ben.
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-03 0:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070802151833.5e250f2b@weaponx.rchland.ibm.com>
On Thu, Aug 02, 2007 at 03:18:33PM -0500, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:47:51 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > Duh, forgot to attach the actual patch. Here it is:
>
> So, no signed-off-by. Intentional, as it's for comments only?
Pretty much.
> Also, could you break this out into a separate thread when you do
> submit it please? Will make a few people's lives easier since this has
> nothing to do with 440EPx really :)
Sure.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] fixes for the SLB shadow buffer
From: Michael Neuling @ 2007-08-03 1:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: will_schmidt, linuxppc-dev
In-Reply-To: <30559.1186046895@neuling.org>
We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Integrated more comments from people.
arch/powerpc/kernel/entry_64.S | 3 +++
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/slb.c | 28 ++++++++++++++++++----------
include/asm-powerpc/mmu-hash64.h | 1 +
4 files changed, 23 insertions(+), 11 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -389,8 +389,11 @@ BEGIN_FTR_SECTION
ld r9,PACA_SLBSHADOWPTR(r13)
li r12,0
std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
+ eieio
std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
+ eieio
std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
+ eieio
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_utils_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
@@ -759,7 +759,7 @@ int hash_page(unsigned long ea, unsigned
mmu_psize_defs[mmu_vmalloc_psize].sllp) {
get_paca()->vmalloc_sllp =
mmu_psize_defs[mmu_vmalloc_psize].sllp;
- slb_flush_and_rebolt();
+ slb_vmalloc_update();
}
#endif /* CONFIG_PPC_64K_PAGES */
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -53,7 +53,8 @@ static inline unsigned long mk_vsid_data
return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
}
-static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
+static inline void slb_shadow_update(unsigned long ea,
+ unsigned long flags,
unsigned long entry)
{
/*
@@ -61,11 +62,11 @@ static inline void slb_shadow_update(uns
* updating it.
*/
get_slb_shadow()->save_area[entry].esid = 0;
- barrier();
- get_slb_shadow()->save_area[entry].vsid = vsid;
- barrier();
- get_slb_shadow()->save_area[entry].esid = esid;
-
+ smp_wmb();
+ get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
+ smp_wmb();
+ get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
+ smp_wmb();
}
static inline void create_shadowed_slbe(unsigned long ea, unsigned long flags,
@@ -76,8 +77,7 @@ static inline void create_shadowed_slbe(
* we don't get a stale entry here if we get preempted by PHYP
* between these two statements.
*/
- slb_shadow_update(mk_esid_data(ea, entry), mk_vsid_data(ea, flags),
- entry);
+ slb_shadow_update(ea, flags, entry);
asm volatile("slbmte %0,%1" :
: "r" (mk_vsid_data(ea, flags)),
@@ -104,8 +104,7 @@ void slb_flush_and_rebolt(void)
ksp_esid_data &= ~SLB_ESID_V;
/* Only third entry (stack) may change here so only resave that */
- slb_shadow_update(ksp_esid_data,
- mk_vsid_data(ksp_esid_data, lflags), 2);
+ slb_shadow_update(get_paca()->kstack, lflags, 2);
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
@@ -123,6 +122,15 @@ void slb_flush_and_rebolt(void)
: "memory");
}
+void slb_vmalloc_update(void)
+{
+ unsigned long vflags;
+
+ vflags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_vmalloc_psize].sllp;
+ slb_shadow_update(VMALLOC_START, vflags, 1);
+ slb_flush_and_rebolt();
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -262,6 +262,7 @@ extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
extern void stab_initialize(unsigned long stab);
+extern void slb_vmalloc_update(void);
#endif /* __ASSEMBLY__ */
/*
^ 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