Re: [RFC 2/2] powerpc: copy_4K_page tweaked for Cell - add CPU feature
On Thu, 14 Aug 2008 10:10:48 pm Michael Ellerman wrote: On Thu, 2008-08-14 at 21:48 +1000, Mark Nelson wrote: Hi Michael, On Thu, 14 Aug 2008 08:51:35 pm Michael Ellerman wrote: On Thu, 2008-08-14 at 16:18 +1000, Mark Nelson wrote: Add a new CPU feature, CPU_FTR_CP_USE_DCBTZ, to be added to the CPUs that benefit from having dcbt and dcbz instructions used in copy_4K_page(). So far Cell, PPC970 and Power4 benefit. This way all the other 64bit powerpc chips will have the whole prefetching loop nop'ed out. Index: upstream/arch/powerpc/lib/copypage_64.S === --- upstream.orig/arch/powerpc/lib/copypage_64.S +++ upstream/arch/powerpc/lib/copypage_64.S @@ -18,6 +18,7 @@ PPC64_CACHES: _GLOBAL(copy_4K_page) li r5,4096 /* 4K page size */ +BEGIN_FTR_SECTION ld r10,[EMAIL PROTECTED](r2) lwz r11,DCACHEL1LOGLINESIZE(r10)/* log2 of cache line size */ lwz r12,DCACHEL1LINESIZE(r10) /* Get cache line size */ @@ -30,7 +31,7 @@ setup: dcbzr9,r3 add r9,r9,r12 bdnzsetup - +END_FTR_SECTION_IFSET(CPU_FTR_CP_USE_DCBTZ) addir3,r3,-8 srdir8,r5,7 /* page is copied in 128 byte strides */ addir8,r8,-1/* one stride copied outside loop */ Instead of nop'ing it out, we could use an alternative feature section to either run it or jump over it. It would look something like: _GLOBAL(copy_4K_page) BEGIN_FTR_SECTION li r5,4096 /* 4K page size */ ld r10,[EMAIL PROTECTED](r2) lwz r11,DCACHEL1LOGLINESIZE(r10)/* log2 of cache line size */ lwz r12,DCACHEL1LINESIZE(r10) /* Get cache line size */ li r9,0 srd r8,r5,r11 mtctr r8 setup: dcbtr9,r4 dcbzr9,r3 add r9,r9,r12 bdnzsetup FTR_SECTION_ELSE b 1f ALT_FTR_SECTION_END_IFSET(CPU_FTR_CP_USE_DCBTZ) 1: addir3,r3,-8 So in the no-dcbtz case you'd get a branch instead of 11 nops. Of course you'd need to benchmark it to see if skipping the nops is better than executing them ;P Thanks for looking through this. That does look a lot better. In the first version there wasn't quite as much to nop out (the cache line size was hardcoded to 128 bytes) so I wasn't so worried but I'll definitely try this with an alternative section like you describe. The jump probably will turn out to be better because I'd imagine that the same chips that don't need the dcbt and dcbz because they've got beefy enough hardware prefetchers also won't be disturbed by the jump (but benchmarks tomorrow will confirm; or prove me wrong :) ) Yeah, that would make sense. But you never know :) It turns out that on Power6 using the alternative section doesn't have any noticeable effect on performance. On Power5 though it actually made the compile test a tiny bit slower: with alternative feature section: real5m7.549s user17m24.256s sys 1m0.621s real5m7.829s user17m24.879s sys 1m0.465s original implementation: real5m6.468s user17m22.891s sys 0m59.765s real5m6.965s user17m23.160s sys 0m59.844s So I guess I'll leave it the way it is... Thanks! Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: oops in proc_sys_compare
On Fri, 15 Aug 2008, Al Viro wrote: On Thu, Aug 14, 2008 at 07:31:06PM +0100, Hugh Dickins wrote: I got this oops below, after several hours of swap-heavy kernel builds in tmpfs, on 2.6.27-rc1-mm1 a couple of weeks ago. Tried to reproduce it without success, then got a very similar trace (not saved) from 2.6.27-rc3 itself doing the same test yesterday: again oopsing in proc_sys_compare on address -16, looks like it's trying for PROC_I(dentry-d_inode)-sysctl but d_inode is NULL. I looked to see what's been going on in fs/proc recently, and your [PATCH] sanitize proc_sysctl 9043476f726802f4b00c96d0c4f418dde48d1304 does sound like it might be implicated. I've only seen this on PowerPC G5, similar tests on x86_32 and _64 haven't shown it: maybe a memory barrier needed somewhere? Bloody interesting. We never create negative hashed dentries in there and AFAICS we should never get d_delete() called on those... Missing barrier would mean serious trouble in dcache.c and not just for /proc/sys... Are you sure about oops decoding? At least disassembly of proc_sys_compare() in the kernel image in question would be nice to see... Here it is: I'd changed config meanwhile, so this is from a rebuild, but symbol addresses fit exactly with the trace (and the 2.6.27-rc1-mm1 fs/proc/proc_sysctl.c is identical to that in 2.6.27-rc3 or current git). I did try objdump -Sd at first, but that just looked more confusing. c0121e7c .proc_sys_compare: proc_sys_compare(): /home/hugh/26271E1/fs/proc/proc_sysctl.c:383 c0121e7c: 7c 08 02 a6 mflrr0 c0121e80: fb e1 ff f0 std r31,-16(r1) c0121e84: 7c a9 2b 78 mr r9,r5 c0121e88: 7c 9f 23 78 mr r31,r4 c0121e8c: f8 01 00 10 std r0,16(r1) c0121e90: f8 21 ff 81 stdur1,-128(r1) /home/hugh/26271E1/fs/proc/proc_sysctl.c:385 c0121e94: 60 00 00 00 nop c0121e98: 80 a4 00 04 lwz r5,4(r4) c0121e9c: 80 09 00 04 lwz r0,4(r9) c0121ea0: 7f 80 28 00 cmpwcr7,r0,r5 c0121ea4: 40 9e 00 3c bne-cr7,c0121ee0 .proc_sys_compare+0x64 /home/hugh/26271E1/fs/proc/proc_sysctl.c:387 c0121ea8: e8 89 00 08 ld r4,8(r9) c0121eac: e8 7f 00 08 ld r3,8(r31) c0121eb0: 4b f0 aa 45 bl c002c8f4 .memcmp c0121eb4: 60 00 00 00 nop c0121eb8: 2f a3 00 00 cmpdi cr7,r3,0 c0121ebc: 40 9e 00 24 bne-cr7,c0121ee0 .proc_sys_compare+0x64 PROC_I(): /home/hugh/26271E1/fs/proc/proc_sysctl.c:384 c0121ec0: e9 3f ff e0 ld r9,-32(r31) c0121ec4: e8 69 ff f0 ld r3,-16(r9) c0121ec8: 4b f2 f8 4d bl c0051714 .sysctl_is_seen c0121ecc: 60 00 00 00 nop proc_sys_compare(): /home/hugh/26271E1/fs/proc/proc_sysctl.c:389 c0121ed0: 7c 63 00 34 cntlzw r3,r3 c0121ed4: 54 63 d9 7e rlwinm r3,r3,27,5,31 c0121ed8: 78 63 00 20 clrldi r3,r3,32 c0121edc: 48 00 00 08 b c0121ee4 .proc_sys_compare+0x68 c0121ee0: 38 60 00 01 li r3,1 /home/hugh/26271E1/fs/proc/proc_sysctl.c:390 c0121ee4: 38 21 00 80 addir1,r1,128 c0121ee8: e8 01 00 10 ld r0,16(r1) c0121eec: eb e1 ff f0 ld r31,-16(r1) c0121ef0: 7c 08 03 a6 mtlrr0 c0121ef4: 4e 80 00 20 blr ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix lockdep IRQ tracing bug
A small bogon sneaked into the ppc64 lockdep support. A test is branching slightly off causing a clobbered register value to overwrite the irq state under some circumstances. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- This explains some of the reported weird lockdep errors, maybe even all of them, we'll see. We should probably backport that to 2.6.26-stable too, any candidate ? arch/powerpc/include/asm/irqflags.h |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/irqflags.h 2008-08-15 16:48:43.0 +1000 +++ linux-work/arch/powerpc/include/asm/irqflags.h 2008-08-15 16:51:02.0 +1000 @@ -20,7 +20,7 @@ #define TRACE_ENABLE_INTS bl .trace_hardirqs_on #define TRACE_DISABLE_INTS bl .trace_hardirqs_off #define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \ - cmpdi en, 0; \ + cmpdi en,0; \ bne 95f;\ stb en,PACASOFTIRQEN(r13); \ bl .trace_hardirqs_off;\ @@ -29,7 +29,8 @@ li en,1; #define TRACE_AND_RESTORE_IRQ(en) \ TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \ -96:stb en,PACASOFTIRQEN(r13) + stb en,PACASOFTIRQEN(r13); \ +96: #else #define TRACE_ENABLE_INTS #define TRACE_DISABLE_INTS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] port ndfc driver to of platform
On Friday 15 August 2008, Sean MacLennan wrote:
Port the ndfc driver to an OF platform driver.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Looks great, but I just noticed one more detail:
+static const struct of_device_id ndfc_match[] = {
+ { .compatible = amcc,ndfc, },
+ {}
};
You should add
MODULE_DEVICE_TABLE(of, ndfc_match);
to enable module auto-loading.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] port ndfc driver to of platform
On Friday 15 August 2008, Sean MacLennan wrote: Changes to the warp platform with the ndfc as an of platform device. The main changes are: * move the NAND information to the DTS * remove warp-nand.c * remove rev A fixups from cuboot-warp.c Signed-off-by: Sean MacLennan [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
Hello Wolfgang (and all), On Wed, Aug 13, 2008 at 04:12:17PM +0200, Wolfgang Grandegger wrote: ...but I prepared a patch to do the reset in the process context. Would be nice if you could give the patch below a try. Will do later. Thanks! Still, I think it might be useful to discuss if a complete reset is not overkill anyhow. The documentation says that only the FIFO and the Bestcom needs to be reset. Or, if we take the big hammer solution, it would be good to audit if this won't cause any side-effects (do all related states get updated...). Remember that there lately have been patches removing some improper usage of netif_* calls; furthermore, I also found some questionable areas in this code (mails will be sent later). So, this driver needs some careful attention IMHO. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
On Wed, Aug 06, 2008 at 03:16:40PM +0800, Li Yang wrote:
Some of Freescale SoC chips have a QE or CPM co-processor which
supports full speed USB. The driver adds device mode support
of both QE and CPM USB controller to Linux USB gadget. The
driver is tested with MPC8360 and MPC8272, and should work with
other models having QE/CPM given minor tweaks.
Signed-off-by: Xie Xiaobo [EMAIL PROTECTED]
Signed-off-by: Li Yang [EMAIL PROTECTED]
Hi,
Just want to report that the driver works here on MPC8360E-MDS,
with few issues though.
+/*-
+ Gadget driver register and unregister.
+ --*/
+int usb_gadget_register_driver(struct usb_gadget_driver *driver)
+{
+ int retval;
+ unsigned long flags = 0;
+
+ /* standard operations */
+ if (!udc_controller)
+ return -ENODEV;
+
+ if (!driver || (driver-speed != USB_SPEED_FULL
+ driver-speed != USB_SPEED_HIGH)
+ || !driver-bind || !driver-unbind ||
+ !driver-disconnect || !driver-setup)
Usually unbind is assigned via __exit_p() macro, thus the driver
will not able to work with g_ether when it is built in.
Plus I got this with various debugging enabled:
g_ether gadget: high speed config #1: CDC Ethernet (ECM)
BUG: spinlock recursion on CPU#0, swapper/0
lock: cf846c50, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
Call Trace:
[c0361cb0] [c0008a90] show_stack+0x4c/0x16c (unreliable)
[c0361cf0] [c0175b84] spin_bug+0x7c/0xc4
[c0361d10] [c0175ea8] _raw_spin_lock+0xb4/0xb8
[c0361d20] [c027e5dc] _spin_lock_irqsave+0x30/0x48
[c0361d40] [c01c8450] qe_ep_init+0x80/0x3a4
[c0361d60] [c01c8828] qe_ep_enable+0xb4/0xe4
[c0361d80] [c01cb210] ecm_set_alt+0x88/0x12c
[c0361d90] [c01cbb10] set_config+0xc8/0x1bc
[c0361db0] [c01cbf90] composite_setup+0x20c/0x3a8
[c0361de0] [c01c7f88] setup_received_handle+0x1e4/0x26c
[c0361e00] [c01c807c] ep0_setup_handle+0x6c/0x74
[c0361e10] [c01c81f0] qe_ep0_rx+0x16c/0x17c
[c0361e30] [c01c9140] rx_irq+0x88/0xc0
[c0361e40] [c01c98c8] qe_udc_irq+0x10c/0x134
[c0361e60] [c006083c] handle_IRQ_event+0x5c/0xb0
[c0361e80] [c0062964] handle_level_irq+0xa8/0x144
[c0361ea0] [c0029a9c] qe_ic_cascade_low_ipic+0x58/0x90
[c0361eb0] [c0006820] do_IRQ+0xa4/0xc8
[c0361ec0] [c0013e88] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xa0/0x104
LR = cpu_idle+0xa0/0x104
[c0361f80] [c0009d88] cpu_idle+0x50/0x104 (unreliable)
[c0361fa0] [c027f07c] 0xc027f07c
[c0361fc0] [c030d91c] start_kernel+0x1ac/0x230
[c0361ff0] [3438] 0x3438
BUG: spinlock lockup on CPU#0, swapper/0, cf846c50
Call Trace:
[c0361ca0] [c0008a90] show_stack+0x4c/0x16c (unreliable)
[c0361ce0] [c0175df0] __spin_lock_debug+0xf4/0xf8
[c0361d10] [c0175e80] _raw_spin_lock+0x8c/0xb8
[c0361d20] [c027e5dc] _spin_lock_irqsave+0x30/0x48
[c0361d40] [c01c8450] qe_ep_init+0x80/0x3a4
[c0361d60] [c01c8828] qe_ep_enable+0xb4/0xe4
[c0361d80] [c01cb210] ecm_set_alt+0x88/0x12c
[c0361d90] [c01cbb10] set_config+0xc8/0x1bc
[c0361db0] [c01cbf90] composite_setup+0x20c/0x3a8
[c0361de0] [c01c7f88] setup_received_handle+0x1e4/0x26c
[c0361e00] [c01c807c] ep0_setup_handle+0x6c/0x74
[c0361e10] [c01c81f0] qe_ep0_rx+0x16c/0x17c
[c0361e30] [c01c9140] rx_irq+0x88/0xc0
[c0361e40] [c01c98c8] qe_udc_irq+0x10c/0x134
[c0361e60] [c006083c] handle_IRQ_event+0x5c/0xb0
[c0361e80] [c0062964] handle_level_irq+0xa8/0x144
[c0361ea0] [c0029a9c] qe_ic_cascade_low_ipic+0x58/0x90
[c0361eb0] [c0006820] do_IRQ+0xa4/0xc8
[c0361ec0] [c0013e88] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xa0/0x104
LR = cpu_idle+0xa0/0x104
[c0361f80] [c0009d88] cpu_idle+0x50/0x104 (unreliable)
[c0361fa0] [c027f07c] 0xc027f07c
[c0361fc0] [c030d91c] start_kernel+0x1ac/0x230
[c0361ff0] [3438] 0x3438
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] DTC: Remove support for the legacy DTS source file format.
On Thu, Aug 14, 2008 at 7:29 PM, David Gibson [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 06:02:43PM -0500, Jon Loeliger wrote: Now that all in-kernel-tree DTS files are properly /dts-v1/, remove direct support for the older, un-numbered DTS source file format. Um.. why? I just don't see a compelling reason to remove this backwards compatibility. It costs us very little to keep it around indefinitely. I agree, why are we removing backwards compatibility? The dts-v1 format isn't that old, so I'm sure there are plenty of device trees out there, especially on our BSPs, that haven't been updated yet. How about just printing a warning and saying that the device tree should be updated with the conversion tool? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] DTC: Remove support for the legacy DTS source file format.
On Thu, Aug 14, 2008 at 7:29 PM, David Gibson [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 06:02:43PM -0500, Jon Loeliger wrote: Now that all in-kernel-tree DTS files are properly /dts-v1/, remove direct support for the older, un-numbered DTS source file format. Um.. why? I just don't see a compelling reason to remove this backwards compatibility. It costs us very little to keep it around indefinitely. Because we are going to get rid of the cruft, simplify things, and move forward. Really. This was the plan from the onset. I agree, why are we removing backwards compatibility? The dts-v1 format isn't that old, so I'm sure there are plenty of device trees out there, especially on our BSPs, that haven't been updated yet. They can run the conversion tool and be fine. How about just printing a warning and saying that the device tree should be updated with the conversion tool? How about all the in-tree DTS files are already V1? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc52xx localplus bus and dm9000
On Thu, Aug 14, 2008 at 3:52 AM, Sinisa Denic [EMAIL PROTECTED] wrote:
Hi,I have mpc52xx based board very similar to lite5200b.
There is Davicom DM9000 connected to Local Plus Bus CS0.
Does anybody have idea how should DTS part look like in order to add this
resource in system.
I've written something like this:
lpb {
device_type = network;
device_type doesn't make any sense here. Drop this line.
compatible = fsl,lpb;
ranges = 0 0 ff00 100;
You need to add #address-cells = 2 and #size-cells = 1 properties
to this node. Otherwise the address translation doesn't work. The
local plus bus uses 2 cells to describe address. First cell is the
chip select and second cell is the address offset on the chip select.
The ranges property translates between the global address space to the
local chip select address space. In this case, 0 0 means 0 offset
from chip select 0, and ff00 is the address it is mapped to on the
parent bus.
[EMAIL PROTECTED],0 {
compatible = dm9000;
reg = 0 0 10;
#size-cells = 1;
#address-cells = 1;
You should not need #address-cells or #size-cells on the child node
because it is not a bus.
};
};
but it's not working.
Is it enough to have right dts record for default dm9000 driver working
or I have to change something more?
Thank you in andvance.
Sinisa Denic
System and software engineer
tel: +381(0)112016142
ABS Control Systems
bul.Zorana Djindjica 8a
Belgrade,Serbia
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] port ndfc driver to of platform
Added in the MODULE_DEVICE_TABLE.
Cheers,
Sean
Port of the ndfc driver to an of platform driver.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 41f361c..ab0d77e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -165,7 +165,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate NDFC NanD Flash Controller
- depends on 4xx !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 955959e..abdb42f 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -5,9 +5,13 @@
* Platform independend driver for NDFC (NanD Flash Controller)
* integrated into EP440 cores
*
+ * Ported to an OF platform driver by Sean MacLennan
+ *
* Author: Thomas Gleixner
*
* Copyright 2006 IBM
+ * Copyright 2008 PIKA Technologies
+ *Sean MacLennan [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or
modify it
* under the terms of the GNU General Public License as published
by the
@@ -21,27 +25,17 @@
#include linux/mtd/partitions.h
#include linux/mtd/ndfc.h
#include linux/mtd/mtd.h
-#include linux/platform_device.h
-
+#include linux/of_platform.h
#include asm/io.h
-#ifdef CONFIG_40x
-#include asm/ibm405.h
-#else
-#include asm/ibm44x.h
-#endif
-
-struct ndfc_nand_mtd {
- struct mtd_info mtd;
- struct nand_chipchip;
- struct platform_nand_chip *pl_chip;
-};
-static struct ndfc_nand_mtd ndfc_mtd[NDFC_MAX_BANKS];
struct ndfc_controller {
- void __iomem*ndfcbase;
- struct nand_hw_control ndfc_control;
- atomic_tchilds_active;
+ struct of_device *ofdev;
+ void __iomem *ndfcbase;
+ struct mtd_info mtd;
+ struct nand_chip chip;
+ int chip_select;
+ struct nand_hw_control ndfc_control;
};
static struct ndfc_controller ndfc_ctrl;
@@ -50,17 +44,14 @@ static void ndfc_select_chip(struct mtd_info *mtd, int chip)
{
uint32_t ccr;
struct ndfc_controller *ndfc = ndfc_ctrl;
- struct nand_chip *nandchip = mtd-priv;
- struct ndfc_nand_mtd *nandmtd = nandchip-priv;
- struct platform_nand_chip *pchip = nandmtd-pl_chip;
- ccr = __raw_readl(ndfc-ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc-ndfcbase + NDFC_CCR);
if (chip = 0) {
ccr = ~NDFC_CCR_BS_MASK;
- ccr |= NDFC_CCR_BS(chip + pchip-chip_offset);
+ ccr |= NDFC_CCR_BS(chip + ndfc-chip_select);
} else
ccr |= NDFC_CCR_RESET_CE;
- __raw_writel(ccr, ndfc-ndfcbase + NDFC_CCR);
+ out_be32(ndfc-ndfcbase + NDFC_CCR, ccr);
}
static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -80,7 +71,7 @@ static int ndfc_ready(struct mtd_info *mtd)
{
struct ndfc_controller *ndfc = ndfc_ctrl;
- return __raw_readl(ndfc-ndfcbase + NDFC_STAT) NDFC_STAT_IS_READY;
+ return in_be32(ndfc-ndfcbase + NDFC_STAT) NDFC_STAT_IS_READY;
}
static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
@@ -88,9 +79,9 @@ static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
uint32_t ccr;
struct ndfc_controller *ndfc = ndfc_ctrl;
- ccr = __raw_readl(ndfc-ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc-ndfcbase + NDFC_CCR);
ccr |= NDFC_CCR_RESET_ECC;
- __raw_writel(ccr, ndfc-ndfcbase + NDFC_CCR);
+ out_be32(ndfc-ndfcbase + NDFC_CCR, ccr);
wmb();
}
@@ -102,9 +93,10 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
uint8_t *p = (uint8_t *)ecc;
wmb();
- ecc = __raw_readl(ndfc-ndfcbase + NDFC_ECC);
- ecc_code[0] = p[1];
- ecc_code[1] = p[2];
+ ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
+ /* The NDFC uses Smart Media (SMC) bytes order */
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
@@ -123,7 +115,7 @@ static void ndfc_read_buf(struct mtd_info *mtd, uint8_t
*buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len 0; len -= 4)
- *p++ = __raw_readl(ndfc-ndfcbase + NDFC_DATA);
+ *p++ = in_be32(ndfc-ndfcbase + NDFC_DATA);
}
static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@ -132,7 +124,7 @@ static void ndfc_write_buf(struct mtd_info *mtd, const
uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len 0; len -= 4)
- __raw_writel(*p++, ndfc-ndfcbase + NDFC_DATA);
+ out_be32(ndfc-ndfcbase + NDFC_DATA, *p++);
}
static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@
[PATCH 0/3] powerpc: cmo fix page loaning and add info to lparcfg
We need to correct a problem found where the kernel is using 64k pages but the firmware pages size is 4k. In this case we were not properly marking pages as 'loaned' to firmware. To fix this I exposed some data pulled from rtas during early setup. I also made these values available via /proc/ppc64/lparcfg in the second patch. The first patch makes the data available and the other two patches (unrelated to each other) depend on the first. Regards, Robert Jennings ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Fix CMM page loaning on 64k page kernel with 4k hardware pages
From: Brian King [EMAIL PROTECTED]
If the firmware page size used for collaborative memory overcommit
is 4k, but the kernel is using 64k pages, the page loaning is currently
broken as it only marks the first 4k page of each 64k page as loaned.
This fixes this to iterate through each 4k page and mark them all as
loaned/active.
Signed-off-by: Brian King [EMAIL PROTECTED]
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/plpar_wrappers.h | 27 ++--
1 file changed, 25 insertions(+), 2 deletions(-)
Index: b/arch/powerpc/platforms/pseries/plpar_wrappers.h
===
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -2,6 +2,7 @@
#define _PSERIES_PLPAR_WRAPPERS_H
#include asm/hvcall.h
+#include asm/page.h
static inline long poll_pending(void)
{
@@ -44,12 +45,34 @@ static inline long register_slb_shadow(u
static inline long plpar_page_set_loaned(unsigned long vpa)
{
- return plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_LOANED, vpa, 0);
+ unsigned long cmo_page_sz = cmo_get_page_size();
+ long rc = 0;
+ int i;
+
+ for (i = 0; !rc i PAGE_SIZE; i += cmo_page_sz)
+ rc = plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_LOANED, vpa +
i, 0);
+
+ for (i -= cmo_page_sz; rc i != 0; i -= cmo_page_sz)
+ plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_ACTIVE,
+ vpa + i - cmo_page_sz, 0);
+
+ return rc;
}
static inline long plpar_page_set_active(unsigned long vpa)
{
- return plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_ACTIVE, vpa, 0);
+ unsigned long cmo_page_sz = cmo_get_page_size();
+ long rc = 0;
+ int i;
+
+ for (i = 0; !rc i PAGE_SIZE; i += cmo_page_sz)
+ rc = plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_ACTIVE, vpa +
i, 0);
+
+ for (i -= cmo_page_sz; rc i != 0; i -= cmo_page_sz)
+ plpar_hcall_norets(H_PAGE_INIT, H_PAGE_SET_LOANED,
+ vpa + i - cmo_page_sz, 0);
+
+ return rc;
}
extern void vpa_init(int cpu);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: add CMO enabled flag and paging space data to lparcfg
Add a field in lparcfg output to indicate whether the kernel is running on a dedicated or shared memory lpar. Added fields to show the paging space pool IDs and the CMO page size. Submitted-by: Robert Jennings [EMAIL PROTECTED] --- arch/powerpc/kernel/lparcfg.c |5 + 1 file changed, 5 insertions(+) Index: b/arch/powerpc/kernel/lparcfg.c === --- a/arch/powerpc/kernel/lparcfg.c +++ b/arch/powerpc/kernel/lparcfg.c @@ -416,6 +416,8 @@ static void pseries_cmo_data(struct seq_ unsigned long cmo_faults = 0; unsigned long cmo_fault_time = 0; + seq_printf(m, cmo_enabled=%d\n, firmware_has_feature(FW_FEATURE_CMO)); + if (!firmware_has_feature(FW_FEATURE_CMO)) return; @@ -427,6 +429,9 @@ static void pseries_cmo_data(struct seq_ seq_printf(m, cmo_faults=%lu\n, cmo_faults); seq_printf(m, cmo_fault_time_usec=%lu\n, cmo_fault_time / tb_ticks_per_usec); + seq_printf(m, cmo_primary_psp=%d\n, cmo_get_primary_psp()); + seq_printf(m, cmo_secondary_psp=%d\n, cmo_get_secondary_psp()); + seq_printf(m, cmo_page_size=%lu\n, cmo_get_page_size()); } static int pseries_lparcfg_data(struct seq_file *m, void *v) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
12.5 MHz woo hoo!
[EMAIL PROTECTED] root]# cat /proc/cpuinfo
processor : 0
cpu : 750GX
temperature : 1-76 C (uncalibrated)
clock : 200.00MHz
revision: 2.3 (pvr 0008 0203)
bogomips: 24.96
timebase: 1250 -- 12.5 MHz exactly!!!
platform: PowerMac
model : Power Macintosh
machine : Power Macintosh
motherboard : AAPL,8500 MacRISC
detected as : 16 (PowerMac 8500/8600)
pmac flags :
pmac-generation : OldWorld
Hey, anybody know if that temperature, thermal thingy works well enough
to bother fooling with the code to produce a more valid value?
also:
[EMAIL PROTECTED] root]# alias tis
alias tis='cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state'
[EMAIL PROTECTED] root]# tis
25 178419
30 0
35 0
40 0
45 0
50 0
55 0
60 0
65 0
70 0
75 0
80 0
85 0
90 0
95 0
100 0
[EMAIL PROTECTED] root]# uname -vr
2.6.26-pll #4 Thu Aug 14 04:02:58 PDT 2008
Finally, can someone tell me if the attached file shows up ok if it were
a patch I wanted to submit? I can't seem to figure out how to 'import
inline' using this ancient mailer.
kevin
/*
* cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
* ($Revision: 1.0 $)
*
* Copyright (C) 2008 kevin Diggs
*
* ~~
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
*
* ~~
*/
#define DEBUG
#include linux/init.h
#include linux/module.h
#include linux/autoconf.h
#include linux/kernel.h
#include linux/errno.h
#include linux/cpu.h
#include linux/of.h
#include linux/notifier.h
#include linux/delay.h
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
#include linux/sysdev.h
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
#include linux/hrtimer.h
#endif
#include asm/uaccess.h
#include asm/bitops.h
#include asm/time.h
#include asm/mmu.h
#include asm/processor.h
#include asm/io.h
#include asm/pgtable.h
#include asm/cputable.h
#include asm/system.h
#include asm/pll_if.h
#include asm/pll.h
#include asm/smp.h
MODULE_LICENSE(GPL);
static unsigned int boot_ratio;
static unsigned int pllifvBusClock;
static unsigned int override_bus_clock = 0;
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
static enum hrtimer_restart pllTimerF(struct hrtimer *hrt);
static struct hrtimer pll_timer;
static unsigned long hrtimers_got_no_freakin_callback_data;
#ifdef DEBUG
cycles_t pll_time_stamp;
#endif
#else
static void pllTimerF(unsigned long newPLL);
static struct timer_list pll_timer;
cycles_t pll_time_stamp;
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
extern unsigned long loops_per_jiffy;
unsigned long boot_loops;
static struct sys_device *sysdev_cpu;
static ssize_t show_ppc750gxpll(struct sys_device *dev, char *buf)
{
return sprintf(buf, %x\n, get_PLL());
}
int modifyPLL(unsigned int pll, int scaleLPJ);
//static ssize_t __attribute_used__ store_ppc750gxpll(struct sys_device *dev,
// const char *buf, size_t count)
static ssize_t __used store_ppc750gxpll(struct sys_device *dev,
const char *buf, size_t count)
{
unsigned int pll;
char *ptr;
pr_debug(__FILE__%s()-%d: buf=%s\n, __func__, __LINE__, buf);
pll = simple_strtoul(buf, ptr, 16);
pr_debug(__FILE__%s()-%d: %x (%d)\n, __func__, __LINE__, pll, pll);
/* modifyPLL(pll,!0); */
modifyPLL(pll, 0);
return ptr-buf;
}
static SYSDEV_ATTR(ppc750gxpll, 0600, show_ppc750gxpll, store_ppc750gxpll);
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ
struct plliftCallData {
void *data;
int scalar;
};
static struct plliftCallData pllifvSwitchCallData;
static struct plliftCallData pllifvLockCallData;
static RAW_NOTIFIER_HEAD(pllifvPllSwitchChain);
static RAW_NOTIFIER_HEAD(pllifvPllLockChain);
#endif
/*
* This initializes the code for the PLL control:
* boot_ratio is used to scale the loops_per_jiffy value from its boot value
* boot_loops is the boot value of loops_per_jiffy and is used to compute new
* values
*/
static int __init init_PLL(void)
{
unsigned int temp;
#ifdef CONFIG_PPC_OF
const u32 *clk;
struct device_node *tree_root;
#endif
if
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
On Jun 18, 2008, at 3:38 AM, Heiko Schocher wrote: Hello, changes since the last patch: update the Portpin initialization. [powerpc] Added support for the MPC8247 based board MGCOGE from Keymile. Signed-off-by: Heiko Schocher [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mgcoge.dts | 174 +++ arch/powerpc/configs/mgcoge_defconfig | 900 + arch/powerpc/platforms/82xx/Kconfig |8 + arch/powerpc/platforms/82xx/Makefile |1 + arch/powerpc/platforms/82xx/mgcoge.c | 129 + 5 files changed, 1212 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/mgcoge.dts create mode 100644 arch/powerpc/configs/mgcoge_defconfig create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c This fails to compile for with 2.6.27-rc3: drivers/net/fs_enet/mac-scc.c: In function 'restart': drivers/net/fs_enet/mac-scc.c:256: error: implicit declaration of function '__fs_out8' drivers/net/fs_enet/mac-scc.c:265: error: 'SCC_EB' undeclared (first use in this function) drivers/net/fs_enet/mac-scc.c:265: error: (Each undeclared identifier is reported only once drivers/net/fs_enet/mac-scc.c:265: error: for each function it appears in.) make[3]: *** [drivers/net/fs_enet/mac-scc.o] Error 1 make[2]: *** [drivers/net/fs_enet] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug in lmb_enforce_memory_limit()
From: Michael Ellerman [EMAIL PROTECTED]
Date: Thu, 14 Aug 2008 21:26:53 +1000
Perhaps after the first loop we should set memory_limit to equal
lmb_end_of_DRAM(), then the second loop should work as it is.
Sounds great. Mind if I push the following to Linus?
lmb: Fix reserved region handling in lmb_enforce_memory_limit().
The idea of the implementation of this fix is from Michael Ellerman.
This function has two loops, but they each interpret the memory_limit
value differently. The first loop interprets it as a size limit
whereas the second loop interprets it as an address limit.
Before the second loop runs, reset memory_limit to lmb_end_of_DRAM()
so that it all works out.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/lib/lmb.c b/lib/lmb.c
index 5d7b928..97e5470 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -462,6 +462,8 @@ void __init lmb_enforce_memory_limit(u64 memory_limit)
if (lmb.memory.region[0].size lmb.rmo_size)
lmb.rmo_size = lmb.memory.region[0].size;
+ memory_limit = lmb_end_of_DRAM();
+
/* And truncate any reserves above the limit also. */
for (i = 0; i lmb.reserved.cnt; i++) {
p = lmb.reserved.region[i];
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug in lmb_enforce_memory_limit()
On Fri, 2008-08-15 at 15:25 -0700, David Miller wrote: From: Michael Ellerman [EMAIL PROTECTED] Date: Thu, 14 Aug 2008 21:26:53 +1000 Perhaps after the first loop we should set memory_limit to equal lmb_end_of_DRAM(), then the second loop should work as it is. Sounds great. Mind if I push the following to Linus? Looks good to me. I'll test it on Monday. I don't know if I have a system with memory holes to test on, but I take it you do? I notice some of our 32-bit code is using lmb_enforce_memory_limit() to enforce an address limit, which is technically broken, but is probably fine because it doesn't need to worry about holes. lmb: Fix reserved region handling in lmb_enforce_memory_limit(). The idea of the implementation of this fix is from Michael Ellerman. This function has two loops, but they each interpret the memory_limit value differently. The first loop interprets it as a size limit whereas the second loop interprets it as an address limit. Before the second loop runs, reset memory_limit to lmb_end_of_DRAM() so that it all works out. Signed-off-by: David S. Miller [EMAIL PROTECTED] Acked-by: Michael Ellerman [EMAIL PROTECTED] cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove dead module_find_bug code.
Doing some various make randconfig and came across an error when CONFIG_BUG
was not set. Looking further in this, I found that module_find_bug, defined
in powerpc arch code, is not called anywhere.
There is a static module_find_bug in lib/bug.c but that is a separate issue.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
arch/powerpc/kernel/module.c | 15 ---
1 file changed, 15 deletions(-)
Index: linux-tip.git/arch/powerpc/kernel/module.c
===
--- linux-tip.git.orig/arch/powerpc/kernel/module.c 2008-08-15
20:18:52.0 -0700
+++ linux-tip.git/arch/powerpc/kernel/module.c 2008-08-15 20:18:58.0
-0700
@@ -99,18 +99,3 @@ void module_arch_cleanup(struct module *
{
module_bug_cleanup(mod);
}
-
-struct bug_entry *module_find_bug(unsigned long bugaddr)
-{
- struct mod_arch_specific *mod;
- unsigned int i;
- struct bug_entry *bug;
-
- list_for_each_entry(mod, module_bug_list, bug_list) {
- bug = mod-bug_table;
- for (i = 0; i mod-num_bugs; ++i, ++bug)
- if (bugaddr == bug-bug_addr)
- return bug;
- }
- return NULL;
-}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] DTC: Remove support for the legacy DTS source file format.
On Fri, Aug 15, 2008 at 10:44:33AM -0500, Jon Loeliger wrote: On Thu, Aug 14, 2008 at 7:29 PM, David Gibson [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 06:02:43PM -0500, Jon Loeliger wrote: Now that all in-kernel-tree DTS files are properly /dts-v1/, remove direct support for the older, un-numbered DTS source file format. Um.. why? I just don't see a compelling reason to remove this backwards compatibility. It costs us very little to keep it around indefinitely. Because we are going to get rid of the cruft, simplify things, and move forward. Really. This was the plan from the onset. Uh.. removing compatibility for the old format was never part of *my* plan for the change. Discourage any further use of the v0 format, yes, remove support for, no. I just don't see a benefit to this. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
