configuring macrowindow for x86 platform and creating a display window????
Hi all ... i need to know how to configure the microwindow for X86 on linux and create a window ? please revert back if any of you have an experience on this I need to know how to start with ... Misbah -- View this message in context: http://www.nabble.com/configuring-macrowindow-for-x86-platform-and-creating-a-display-window-tp14708301p14708301.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/4 v2] PS3: Add logical performance monitor driver support
On Tue, 8 Jan 2008, Geoff Levand wrote: --- /dev/null +++ b/drivers/ps3/ps3-lpm.c + /* + * As per the PPE book IV, to avoid bookmark lost there must loss? + * not be a traced branch within 10 cycles of setting the + * SPRN_BKMK register. The actual text is unclear if 'within' + * includes cycles before the call. + */ With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Am Dienstag, den 08.01.2008, 22:05 +0300 schrieb Anton Vorontsov:
Otherwise oops will happen if ethernet device has not been opened:
Unable to handle kernel paging request for data at address 0x014c
Faulting instruction address: 0xc016f7f0
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx
NIP: c016f7f0 LR: c01722a0 CTR:
REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b)
MSR: 00029000 EE,ME CR: 20004428 XER: 2000
DEAR: 014c, ESR:
TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000
GPR00: c01aceb8 c79ddd20 c789f5e0 c79ddd3c c79ddd64
GPR08: c7845b60 c79dde3c c01ace80 20004422 200249fc 02a0 100da728
GPR16: 100c 20022078 0009 200220e0 bfc85558
GPR24: c79ddd3c c02e0e70 c022fc64 c7845800 bfc85498
NIP [c016f7f0] phy_ethtool_gset+0x0/0x4c
LR [c01722a0] fs_get_settings+0x18/0x28
Call Trace:
[c79ddd20] [c79dde38] 0xc79dde38 (unreliable)
[c79ddd30] [c01aceb8] dev_ethtool+0x294/0x11ec
[c79dde30] [c01aaa44] dev_ioctl+0x454/0x6a8
[c79ddeb0] [c019b9d4] sock_ioctl+0x84/0x230
[c79dded0] [c007ded8] do_ioctl+0x34/0x8c
[c79ddee0] [c007dfbc] vfs_ioctl+0x8c/0x41c
[c79ddf10] [c007e38c] sys_ioctl+0x40/0x74
[c79ddf40] [c000d4c0] ret_from_syscall+0x0/0x3c
Instruction dump:
8163 800b0030 2f80 419e0010 7c0803a6 4e800021 7c691b78 80010014
7d234b78 38210010 7c0803a6 4e800020 8003014c 7c6b1b78 3860 90040004
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: Vitaly Bordug [EMAIL PROTECTED]
---
Just resending it, it feels like it got lost during holidays.
drivers/net/fs_enet/fs_enet-main.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..23fddc3 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -897,14 +897,21 @@ static void fs_get_regs(struct net_device *dev, struct
ethtool_regs *regs,
static int fs_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+
+ if (!fep-phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(fep-phydev, cmd);
}
static int fs_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
- phy_ethtool_sset(fep-phydev, cmd);
- return 0;
+
+ if (!fep-phydev)
+ return -ENODEV;
+
+ return phy_ethtool_sset(fep-phydev, cmd);
}
static int fs_nway_reset(struct net_device *dev)
I got also oops problem with the driver.
What could be false?
After the following patch it functions.
Thanks for any advance.
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..d5081b1 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -99,6 +99,8 @@ static int fs_enet_rx_napi(struct napi_struct *napi,
int budget)
if (!netif_running(dev))
return 0;
+ if (fep-cur_rx == NULL)
+ return 0;
/*
* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] enable built-in networking for Sequoia defconfig
Josh, Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch. BTW, is it normal to edit the defconfig file by hand? I cannot get CONFIG_IBM_NEW_EMAC enabled through Kconfig. Am I missing something: a) Patch to enable IBM_NEW_EMAC via Kconfig is welcome b) Matthias only knows only half the truth. Matthias On Tuesday 08 January 2008 17:09, Josh Boyer wrote: On Fri, 04 Jan 2008 17:26:54 -0600 Hollis Blanchard [EMAIL PROTECTED] wrote: Enable EMAC driver for Sequoia (and while we're in there, disable Macintosh drivers for Sequoia and Bamboo). Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] applied, thanks. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] [POWERPC] Xilinx: Uartlite: Make console output actually work.
Stephen == Stephen Neuendorffer [EMAIL PROTECTED] writes:
From: Grant Likely [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
Fixed to apply against 2.6.24-rc5, and remove DEBUG information.
Please CC me and the linux-serial list on uartlite patches.
The subject seems to be wrong, as console output works ok here
(non-OF). Perhaps change to uartlite: fix OF console setup ?
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
drivers/serial/uartlite.c | 121
+
1 files changed, 79 insertions(+), 42 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 3f59324..71e4c0a 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -9,6 +9,8 @@
* kind, whether express or implied.
*/
+#undef DEBUG
+
Don't do that! What are you trying to do?
#include linux/platform_device.h
#include linux/module.h
#include linux/console.h
@@ -321,6 +323,49 @@ static struct uart_ops ulite_ops = {
.verify_port= ulite_verify_port
};
+/**
+ * ulite_get_port: Get the uart_port for a given port number and base addr
+ */
+static struct uart_port *ulite_get_port(int id)
+{
+struct uart_port *port;
+
+/* if id = -1; then scan for a free id and use that */
+if (id 0) {
+for (id = 0; id ULITE_NR_UARTS; id++)
+if (ulite_ports[id].mapbase == 0)
+break;
+}
+
+if ((id 0) || (id = ULITE_NR_UARTS)) {
+printk(KERN_WARNING uartlite: invalid id: %i\n, id);
pr_warn
+return NULL;
+}
+
+/* The ID is valid, so get the address of the uart_port structure */
+port = ulite_ports[id];
+
+/* Is the structure is already initialized? */
+if (port-mapbase)
+return port;
+
+/* At this point, we've got an empty uart_port struct, initialize it */
+spin_lock_init(port-lock);
+port-membase = NULL;
+port-fifosize = 16;
+port-regshift = 2;
+port-iotype = UPIO_MEM;
+port-iobase = 1; /* mark port in use */
+port-ops = ulite_ops;
+port-irq = NO_IRQ;
+port-flags = UPF_BOOT_AUTOCONF;
+port-dev = NULL;
+port-type = PORT_UNKNOWN;
+port-line = id;
Please put the above in a conditional istead of 2 returns, E.G.
if (!port-mapbase) {
spin_lock_init ..
+
+return port;
+}
+
/* -
* Console driver operations
*/
@@ -376,7 +421,7 @@ static void ulite_console_write(struct console *co,
const char *s,
}
#if defined(CONFIG_OF)
-static inline void __init ulite_console_of_find_device(int id)
+static inline u32 __init ulite_console_of_find_device(int id)
resource_size_t?
{
struct device_node *np;
struct resource res;
@@ -392,13 +437,14 @@ static inline void __init
ulite_console_of_find_device(int id)
if (rc)
continue;
-ulite_ports[id].mapbase = res.start;
of_node_put(np);
-return;
+return res.start+3;
Are all OF users big endian?
}
+
+return 0;
}
#else /* CONFIG_OF */
-static inline void __init ulite_console_of_find_device(int id) { /* do
nothing */ }
+static inline u32 __init ulite_console_of_find_device(int id) { return 0; }
#endif /* CONFIG_OF */
static int __init ulite_console_setup(struct console *co, char *options)
@@ -408,25 +454,33 @@ static int __init ulite_console_setup(struct console
*co, char *options)
int bits = 8;
int parity = 'n';
int flow = 'n';
+u32 base;
-if (co-index 0 || co-index = ULITE_NR_UARTS)
-return -EINVAL;
+/* Find a matching uart port in the device tree */
+base = ulite_console_of_find_device(co-index);
-port = ulite_ports[co-index];
+/* Get the port structure */
+port = ulite_get_port(co-index);
+if (!port)
+return -ENODEV;
-/* Check if it is an OF device */
-if (!port-mapbase)
-ulite_console_of_find_device(co-index);
+/* was it initialized for this device? */
+if (base) {
I preferred the old way, where it was clearer that this stuff is only
done in the OF case, E.G.:
/* Check if it is an OF device */
if (!port-mapbase)
port-mapbase = ulite_console_of_find_device(co-index);
+if ((port-mapbase) (port-mapbase != base)) {
+pr_debug(KERN_DEBUG ulite: addr mismatch; %x != %x\n,
+ port-mapbase, base);
+return -ENODEV; /* port used by another device; bail */
You have this both here and in ulite_assign - Couldn't this be moved
to ulite_get_port?
+}
+port-mapbase = base;
+}
-
Re: [patch 1/4] POWERPC: Add Cell SPRN bookmark register
On Wednesday 09 January 2008, Geoff Levand wrote: Add a definition for the Cell SPRN bookmark register to asm-powerpc/regs.h Signed-off-by: Geoff Levand [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-virtex.git
On Tue, 8 Jan 2008 23:07:51 -0700 Grant Likely [EMAIL PROTECTED] wrote: Josh, here are some Xilinx Virtex changes for 2.6.25: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25 Hm.. Seems Peter has some comments on the first one. Shall I wait for that to get hashed out? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-virtex.git
Josh == Josh Boyer [EMAIL PROTECTED] writes: Josh On Tue, 8 Jan 2008 23:07:51 -0700 Josh Grant Likely [EMAIL PROTECTED] wrote: Josh, here are some Xilinx Virtex changes for 2.6.25: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25 Josh Hm.. Seems Peter has some comments on the first one. Shall I wait for Josh that to get hashed out? Yes please. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Hello Sergej,
Wed Jan 9 21:46:06 EST 2008 Sergej Stepanov [EMAIL PROTECTED] wrote:
I got also oops problem with the driver.
What could be false?
After the following patch it functions.
Thanks for any advance.
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..d5081b1 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -99,6 +99,8 @@ static int fs_enet_rx_napi(struct napi_struct *napi,
int budget)
seems your mailer wraps long lines
if (!netif_running(dev))
return 0;
+ if (fep-cur_rx == NULL)
+ return 0;
/*
* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
Hmm... I had also a oops in fs_enet_rx_napi () because of an
uninitialized fep-cur_rx. The following Patch solves this, also
adds support for using Ethernet over SCC on a CPM2.
From 62cd02d481eb772f4417e9ba17fb010d1954c330 Mon Sep 17 00:00:00 2001
From: Heiko Schocher [EMAIL PROTECTED]
Date: Mon, 7 Jan 2008 09:42:09 +0100
Subject: [PATCH] [POWERPC] Fix Ethernet over SCC on a CPM2
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c | 11 +--
drivers/net/fs_enet/mac-scc.c | 18 ++
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..b4a1480 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -982,6 +982,7 @@ static struct net_device *fs_init_instance(struct device
*dev,
fep = netdev_priv(ndev);
fep-dev = dev;
+ fep-ndev = ndev;
dev_set_drvdata(dev, ndev);
fep-fpi = fpi;
if (fpi-init_ioports)
@@ -1085,7 +1086,6 @@ static struct net_device *fs_init_instance(struct device
*dev,
}
registered = 1;
-
return ndev;
err:
@@ -1312,6 +1312,9 @@ static int __devinit fs_enet_probe(struct of_device
*ofdev,
ndev-dev_addr[0], ndev-dev_addr[1], ndev-dev_addr[2],
ndev-dev_addr[3], ndev-dev_addr[4], ndev-dev_addr[5]);
+ /* to initialize the fep-cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(ndev);
return 0;
out_free_bd:
@@ -1342,9 +1345,13 @@ static int fs_enet_remove(struct of_device *ofdev)
}
static struct of_device_id fs_enet_match[] = {
-#ifdef CONFIG_FS_ENET_HAS_SCC
+#if defined(CONFIG_FS_ENET_HAS_SCC)
{
+#if defined(CONFIG_CPM1)
.compatible = fsl,cpm1-scc-enet,
+#else
+ .compatible = fsl,cpm2-scc-enet,
+#endif
.data = (void *)fs_scc_ops,
},
#endif
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 48f2f30..3b5ca76 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,6 +50,7 @@
#include fs_enet.h
/*/
+#define SCC_EB ((u_char)0x10) /* Set big endian byte order */
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
@@ -65,6 +66,8 @@
#define __fs_out16(addr, x)out_be16(addr, x)
#define __fs_in32(addr)in_be32(addr)
#define __fs_in16(addr)in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -96,10 +99,18 @@ static inline int scc_cr_cmd(struct fs_enet_private *fep,
u32 op)
const struct fs_platform_info *fpi = fep-fpi;
int i;
+#if defined(CONFIG_CPM1)
W16(cpmp, cp_cpcr, fpi-cp_command | CPM_CR_FLG | (op 8));
for (i = 0; i MAX_CR_CMD_LOOPS; i++)
if ((R16(cpmp, cp_cpcr) CPM_CR_FLG) == 0)
return 0;
+#else
+ W32(cpmp, cp_cpcr, fpi-cp_command | CPM_CR_FLG | op);
+ for (i = 0; i MAX_CR_CMD_LOOPS; i++)
+ if ((R32(cpmp, cp_cpcr) CPM_CR_FLG) == 0)
+ return 0;
+
+#endif
printk(KERN_ERR %s(): Not able to issue CPM command\n,
__FUNCTION__);
@@ -306,8 +317,15 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifdef CONFIG_CPM2
+ /* from oldstyle driver in arch/ppc */
+ /* seems necessary */
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | 0x20);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | 0x20);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
--
1.5.2.2
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [PATCH] enable built-in networking for Sequoia defconfig
On Wednesday 09 January 2008 13:07, Josh Boyer wrote: On Wed, 9 Jan 2008 12:16:25 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: Josh, Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch. I applied it there, just haven't pushed it out yet. Will do that today. BTW, is it normal to edit the defconfig file by hand? The defconfig? Not sure. What I normally do is a make foo_defconfig, edit the .config, make oldconfig, and copy the resulting .config back to foo_defconfig. Yes, this is what I also do. But how did Hollis get these lines into .config or sequoia_defconfig: +CONFIG_IBM_NEW_EMAC=y +CONFIG_IBM_NEW_EMAC_RXB=128 +CONFIG_IBM_NEW_EMAC_TXB=64 +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 I did not find any Kconfigs where these might come from. Any hint? Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On 1/9/08, Sven Luther [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote: Woo! Thanks Olaf. I was just about to sit down and write something like this myself. Looks good to me. I'll pick this up (but I'm going to move it to the fixup_device_tree_efika() function) Indeed, thanks, this makes the efika kernel again work out of the box. Would it be possible to merge this upstream asap ? I'll see if paulus will pick it up for 2.6.24 g. -- 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: add phy-handle property for fec_mpc52xx
On 1/9/08, Olaf Hering [EMAIL PROTECTED] wrote: The new network driver fec_mpc52xx will not work on efika because the firmware does not provide all required properties. http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to create more properties. But only the phy stuff is required to get a working network. Question: What will happen with this code if the mdio and phy nodes have already been created by the forth script? There is not checking to see if the phy node already exists. Cheers, g. -- 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] enable built-in networking for Sequoia defconfig
On Wednesday 09 January 2008, Matthias Fuchs wrote: The defconfig? Not sure. What I normally do is a make foo_defconfig, edit the .config, make oldconfig, and copy the resulting .config back to foo_defconfig. Yes, this is what I also do. But how did Hollis get these lines into .config or sequoia_defconfig: +CONFIG_IBM_NEW_EMAC=y +CONFIG_IBM_NEW_EMAC_RXB=128 +CONFIG_IBM_NEW_EMAC_TXB=64 +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 I did not find any Kconfigs where these might come from. Take a look at drivers/net/ibm_newemac/Kconfig. Viele Grüße, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk() does not work on UART1
On Wed, 2008-01-09 at 00:06 -0500, mike zheng wrote: Hi All, I have one mpc8568 board using UART1 as the serial port. The OS is Linux Kernel2.4. If I use the polling mode driver of gen550_progress(), it works fine. However the printk() does not work after the console_init(). Anyone know what shall I change in the kernel to use UART1 as serial console? I assume the default is UART0, but I don't know where the value is set. I changed the CONFIG_CMDLINE to ttyS1, it does NOT work. Make sure you've configured PC0/1/2/3 for UART1 SOUT/RTS/CTS/SIN in u-boot. Haiying ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
add phy-handle property for fec_mpc52xx
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
---
arch/powerpc/kernel/prom_init.c | 28
1 file changed, 28 insertions(+)
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
else if (strncmp(version, FirmWorks,3., 12) == 0) {
of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
call_prom(interpret, 1, 1, dev /memory 0 to allow-reclaim);
+#ifdef CONFIG_PPC_MPC52xx
+ } else if (strcmp(version, EFIKA5K2) == 0) {
+ call_prom(interpret, 1, 1,
+.\ Adding EFIKA5K2 Ethernet PHY\ cr
+s\ /builtin\ find-device
+new-device
+1 encode-int s\ #address-cells\ property
+0 encode-int s\ #size-cells\ property
+s\ mdio\ 2dup device-name device-type
+s\ mpc5200b-fec-phy\ encode-string s\
compatible\ property
+0xf0003000 0x400 reg
+0x2 encode-int
+0x5 encode-int encode+
+0x3 encode-int encode+
+s\ interrupts\ property
+new-device
+s\ ethernet-phy\ 2dup device-name
device-type
+0x10 encode-int s\ reg\ property
+my-self
+ihandlephandle
+finish-device
+finish-device
+s\ /builtin/ethernet\ find-device
+encode-int
+s\ phy-handle\ property
+device-end
+ );
+#endif
} else
return;
_prom-memory = call_prom(open, 1, 1, ADDR(/memory));
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote: Woo! Thanks Olaf. I was just about to sit down and write something like this myself. Looks good to me. I'll pick this up (but I'm going to move it to the fixup_device_tree_efika() function) Indeed, thanks, this makes the efika kernel again work out of the box. Would it be possible to merge this upstream asap ? Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
Woo! Thanks Olaf. I was just about to sit down and write something
like this myself. Looks good to me. I'll pick this up (but I'm going
to move it to the fixup_device_tree_efika() function)
Cheers,
g.
On 1/9/08, Olaf Hering [EMAIL PROTECTED] wrote:
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
---
arch/powerpc/kernel/prom_init.c | 28
1 file changed, 28 insertions(+)
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
else if (strncmp(version, FirmWorks,3., 12) == 0) {
of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
call_prom(interpret, 1, 1, dev /memory 0 to
allow-reclaim);
+#ifdef CONFIG_PPC_MPC52xx
+ } else if (strcmp(version, EFIKA5K2) == 0) {
+ call_prom(interpret, 1, 1,
+.\ Adding EFIKA5K2 Ethernet PHY\ cr
+s\ /builtin\ find-device
+new-device
+1 encode-int s\ #address-cells\ property
+0 encode-int s\ #size-cells\ property
+s\ mdio\ 2dup device-name device-type
+s\ mpc5200b-fec-phy\ encode-string s\
compatible\ property
+0xf0003000 0x400 reg
+0x2 encode-int
+0x5 encode-int encode+
+0x3 encode-int encode+
+s\ interrupts\ property
+new-device
+s\ ethernet-phy\ 2dup device-name
device-type
+0x10 encode-int s\ reg\ property
+my-self
+ihandlephandle
+finish-device
+finish-device
+s\ /builtin/ethernet\ find-device
+encode-int
+s\ phy-handle\ property
+device-end
+ );
+#endif
} else
return;
_prom-memory = call_prom(open, 1, 1, ADDR(/memory));
___
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: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 03:21:35PM +, Matt Sealey wrote: NO. YES :) Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] enable built-in networking for Sequoia defconfig
On Wed, 9 Jan 2008 15:42:38 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: On Wednesday 09 January 2008 13:07, Josh Boyer wrote: On Wed, 9 Jan 2008 12:16:25 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: Josh, Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch. I applied it there, just haven't pushed it out yet. Will do that today. BTW, is it normal to edit the defconfig file by hand? The defconfig? Not sure. What I normally do is a make foo_defconfig, edit the .config, make oldconfig, and copy the resulting .config back to foo_defconfig. Yes, this is what I also do. But how did Hollis get these lines into .config or sequoia_defconfig: +CONFIG_IBM_NEW_EMAC=y +CONFIG_IBM_NEW_EMAC_RXB=128 +CONFIG_IBM_NEW_EMAC_TXB=64 +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 I did not find any Kconfigs where these might come from. They're in drivers/net/ibm_newemac/Kconfig. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On 1/9/08, Matt Sealey [EMAIL PROTECTED] wrote: NO. please elaborate -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Sven Luther wrote: On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote: Woo! Thanks Olaf. I was just about to sit down and write something like this myself. Looks good to me. I'll pick this up (but I'm going to move it to the fixup_device_tree_efika() function) Indeed, thanks, this makes the efika kernel again work out of the box. Would it be possible to merge this upstream asap ? Friendly, Sven Luther ___ 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: Please pull linux-2.6-virtex.git
On 1/9/08, Peter Korsgaard [EMAIL PROTECTED] wrote: Josh == Josh Boyer [EMAIL PROTECTED] writes: Josh On Tue, 8 Jan 2008 23:07:51 -0700 Josh Grant Likely [EMAIL PROTECTED] wrote: Josh, here are some Xilinx Virtex changes for 2.6.25: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25 Josh Hm.. Seems Peter has some comments on the first one. Shall I wait for Josh that to get hashed out? Yes please. Gah; teach me to pick up patches right before bed. I shouldn't have picked up the ulite console changes patch just yet. I've dropped it from the series until I have a chance to rework it. Sorry. Here's the new pull request The following changes since commit 4f43143f9fbbb679c38d2ff99e44d3aaa00d0fe1: Paul Mackerras (1): Merge branch 'for-2.6.25' of git://git.kernel.org/.../olof/pasemi are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25 Stephen Neuendorffer (5): [POWERPC] Xilinx: update compatible list for interrupt controller [POWERPC] Xilinx: Add correct compatible list for device tree bus bindings. [POWERPC] Xilinx: Update booting-without-of. [POWERPC] Xilinx: updated device tree compatibility to match uboot bsp generator. [POWERPC] Xilinx uartlite: Section type fixups Documentation/powerpc/booting-without-of.txt | 56 +++--- arch/powerpc/boot/serial.c |3 +- arch/powerpc/platforms/40x/virtex.c | 12 +- arch/powerpc/sysdev/xilinx_intc.c|8 +++- drivers/serial/uartlite.c|6 +- 5 files changed, 56 insertions(+), 29 deletions(-) -- Bye, Peter Korsgaard -- 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: add phy-handle property for fec_mpc52xx
NO. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Sven Luther wrote: On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote: Woo! Thanks Olaf. I was just about to sit down and write something like this myself. Looks good to me. I'll pick this up (but I'm going to move it to the fixup_device_tree_efika() function) Indeed, thanks, this makes the efika kernel again work out of the box. Would it be possible to merge this upstream asap ? Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
I'd also say that the sound driver isn't ready for production use and it misuses the BestComm task for generic bidirectional buffer copies by forcing it to 32-bit transfers (this obviously involves some software upsampling at some point as nearly all common sound data is 16-bit, also twice the bandwidth to achieve). The Freescale docs for this task (and the one provided by the firmware, no doubt, is identical in operation) clearly state that the transfer size is configurable, so saying it only accepts 32-bit sample data is simply inefficient and lazy. Someone needs to sit down and look at these, after a year of simple stagnation since Sylvain lost the time to maintain them. I don't think it is at all a good idea to think oh it has been in the wild for a year and nobody maintains it so we will mainline it now. That's a ridiculous development philosophy. And, since nobody seems to give a shit, it will stay as bad as it is right now (a quick hack) whether in the wild or mainlined.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Sven Luther wrote: On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote: On 1/9/08, Sven Luther [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote: Woo! Thanks Olaf. I was just about to sit down and write something like this myself. Looks good to me. I'll pick this up (but I'm going to move it to the fixup_device_tree_efika() function) Indeed, thanks, this makes the efika kernel again work out of the box. Would it be possible to merge this upstream asap ? I'll see if paulus will pick it up for 2.6.24 Cool, this would mean the only thing missing the patchset i have been carrying is the sound driver. Do you see something else that has been added since then ? Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk() does not work on UART1
I found the problem. The CONFIG_CMDLINE was overwritten. Right now, it is working. Thanks for all the help, Mike On 1/9/08, Haiying Wang [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 00:06 -0500, mike zheng wrote: Hi All, I have one mpc8568 board using UART1 as the serial port. The OS is Linux Kernel2.4. If I use the polling mode driver of gen550_progress(), it works fine. However the printk() does not work after the console_init(). Anyone know what shall I change in the kernel to use UART1 as serial console? I assume the default is UART0, but I don't know where the value is set. I changed the CONFIG_CMDLINE to ttyS1, it does NOT work. Make sure you've configured PC0/1/2/3 for UART1 SOUT/RTS/CTS/SIN in u-boot. Haiying ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 03:26:04PM +, Matt Sealey wrote: Clarification: I really have to disagree with this patch, and Sven. The whole point of removing the stuff from the Linux kernel (as the efika.forth script and the associated patch performs) is that it means the Linux kernel is no longer a moving target for our firmware development. What firmware development ? If users require these kernels they can run efika.forth - the major stumbling block being this is quite ugly to do right now. This is our problem - bplan, Genesi, myself whoever you want to target - it should not be made into a Linux problem by creating this moving target that needs constant patching to maintain driver coherency. Then get the firmware fixed, and everyone would be happy. I don't see that happening in the near future, just as there has been no pegasos firmware release in ages, and my work on it has been scratched, and ignored for the efika firmware which has lot of regression compared to the latest pegasos beta releases. A new efika firmware upgrade has been promised in, what was it, marsch last year or so, where is it ? Let's just fix this in the kernel, until we get a fixed efika firmware, then we can drop it easily enough. But until this happens, we need to be able to boot the kernel without any extra work on the users part. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Fix remainder calculating bug in single floating pointdivision
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Tuesday, January 08, 2008 2:20 PM To: Dan Malek Cc: Liu Yu; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] Fix remainder calculating bug in single floating pointdivision On Jan 6, 2008, at 2:44 PM, Dan Malek wrote: On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote: It's nice to see somebody digging in that scary math emu stuff. If you could also get rid of the warnings, it would be perfect :-) Yes, it is :-) I didn't think it would have a life beyond MPC8xx. that this code was lifted from somewhere else (glibc ? gcc soft-float ?), It seems like a lifetime ago I copied the framework from Sparc, and the internals from gcc soft-float. I didn't change any of the internal emulation functions (hence, some of the warnings), just the calling interface. While it's convenient, I still don't think kernel float emulation should be a solution. The tools should generate soft-float for the applications and libraries. If we think this is really true, we could move to using include/math- emu/* instead of the files in powerpc/math-emu. Why it's better to move to using include/math-emu. I found they have similar framework, is powerpc/math-emu evolved from include/math-emu? The problem I had was when I tried to recreate the history of the code in powerpc/math-emu and how it doesn't really match the glibc code base. There are some differences and I wasn't sure if they were do to trying to match PPC HW at a bit level or not. I was hoping that the work Liu Yu would get as a bit of a testsuite to see if there was any harm in moving over to include/math-emu. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On 1/9/08, Matt Sealey [EMAIL PROTECTED] wrote: Please let's keep the nature of our firmware and the Linux codebase independant, and move the burden of support to Genesi, and not the Linux PowerPC team. After all, what is next, after phy-handle do you want to add i2c, irda, missing xlb/cdm entries in the patch so that other things work? Does everyone have to custom compile their own kernel? What happens if we do another firmware release and the Linux kernel overwrites important values without checking as it does now? It simply causes problems. FWIW, I've got a patch in my tree that removes a bunch of the efika fixups. I've learned a lot over the past year and I'm taking a more pragmatic approach. So, fixups that are not absolutely required to get a working Efika are going away. However, I'm still inclined to pick up Olaf's patch with the appropriate protections around it so it is only done if the nodes are missing. Cheers, g. -- 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: add phy-handle property for fec_mpc52xx
On Wed, 2008-01-09 at 15:26 +, Matt Sealey wrote: If anyone wants to help/assist/suggest any updates to efika.forth, create binary tools which assist the installation of the script for users and for placement on Linux distro CDs etc. I would be very grateful, but it seems we have hit the Wall of Apathy where users complain for a feature but are not willing to work for it. We're already shipping efika.forth in Fedora rawhide, and in my updated spins of Fedora 8. It's a pain in the arse, but it kind of works. It would be much better if the kernel would 'just work'. The ideal way of achieving that is for the firmware to be fixed -- but that's been promised for a long time now, and we just don't believe you any more. So working round it in the kernel seems to be the next best option. (I am invoking the Open Source Fallacy of that if the source is available you can patch it, I say that patching Linux is not the solution, but patching the firmware is. But nobody is willing to work on patching the firmware and keeping Linux entirely independant of our so-deemed crappy firmware) /me looks at http://git.infradead.org/?p=openfirmware.git /me looks at the Efika... -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 03:26:04PM +, Matt Sealey wrote: Clarification: I really have to disagree with this patch, and Sven. The whole point of removing the stuff from the Linux kernel (as the efika.forth script and the associated patch performs) is that it means the Linux kernel is no longer a moving target for our firmware development. But that's what this _accomplishes_. If linux needs something from the firmware environment that it doesn't provide, it adds it itself. That means that the firmwarelinux interface is no longer a moving target. If anyone wants to help/assist/suggest any updates to efika.forth, create binary tools which assist the installation of the script for users and for placement on Linux distro CDs etc. I would be very grateful, but it seems we have hit the Wall of Apathy where users complain for a feature but are not willing to work for it. Amazing. Olaf just did that work for you, and he did it without providing yet another tool for distros to pick up and maintain. And still you complain. Is it really that strange that people aren't helping you out?! -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
Clarification: I really have to disagree with this patch, and Sven.
The whole point of removing the stuff from the Linux kernel (as the
efika.forth script and the associated patch performs) is that it means
the Linux kernel is no longer a moving target for our firmware
development.
If users require these kernels they can run efika.forth - the major
stumbling block being this is quite ugly to do right now. This is our
problem - bplan, Genesi, myself whoever you want to target - it should
not be made into a Linux problem by creating this moving target that
needs constant patching to maintain driver coherency.
There is a clever way to load in a forth script to nvramrc on the
Efika through exploitation of an exposed internal firmware structure
(not security critical, just very useful). Unfortunately right now I
am not willing to shoulder the entire burden of writing, testing and
further development of a suite of tools to bridge the gap between the
current firmware which misses certain features, and a new firmware
which may not be released in a timely fashion.
If anyone wants to help/assist/suggest any updates to efika.forth,
create binary tools which assist the installation of the script for
users and for placement on Linux distro CDs etc. I would be very
grateful, but it seems we have hit the Wall of Apathy where users
complain for a feature but are not willing to work for it.
(I am invoking the Open Source Fallacy of that if the source is
available you can patch it, I say that patching Linux is not the
solution, but patching the firmware is. But nobody is willing to
work on patching the firmware and keeping Linux entirely independant
of our so-deemed crappy firmware)
Please let's keep the nature of our firmware and the Linux codebase
independant, and move the burden of support to Genesi, and not the
Linux PowerPC team. After all, what is next, after phy-handle do
you want to add i2c, irda, missing xlb/cdm entries in the patch so
that other things work? Does everyone have to custom compile their
own kernel? What happens if we do another firmware release and
the Linux kernel overwrites important values without checking as
it does now? It simply causes problems.
Therefore I heartily do not acknowledge this patch. Olaf, if you
would like to assist in the development of an easy installer for
the device tree supplement for users, please feel free... save
these guys from having to maintain support for a broken device
tree by providing a correct one :D
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Olaf Hering wrote:
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
---
arch/powerpc/kernel/prom_init.c | 28
1 file changed, 28 insertions(+)
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
else if (strncmp(version, FirmWorks,3., 12) == 0) {
of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
call_prom(interpret, 1, 1, dev /memory 0 to allow-reclaim);
+#ifdef CONFIG_PPC_MPC52xx
+ } else if (strcmp(version, EFIKA5K2) == 0) {
+ call_prom(interpret, 1, 1,
+ .\ Adding EFIKA5K2 Ethernet PHY\ cr
+ s\ /builtin\ find-device
+ new-device
+ 1 encode-int s\ #address-cells\ property
+ 0 encode-int s\ #size-cells\ property
+ s\ mdio\ 2dup device-name device-type
+ s\ mpc5200b-fec-phy\ encode-string s\
compatible\ property
+ 0xf0003000 0x400 reg
+ 0x2 encode-int
+ 0x5 encode-int encode+
+ 0x3 encode-int encode+
+ s\ interrupts\ property
+ new-device
+ s\ ethernet-phy\ 2dup device-name
device-type
+ 0x10 encode-int s\ reg\ property
+ my-self
+ ihandlephandle
+ finish-device
+ finish-device
+ s\ /builtin/ethernet\ find-device
+ encode-int
+ s\ phy-handle\ property
+ device-end
+ );
+#endif
} else
return;
_prom-memory =
Re: [PATCH] enable built-in networking for Sequoia defconfig
Thanks, Sorry, I must have been blind. Matthias On Wednesday 09 January 2008 16:21, Josh Boyer wrote: On Wed, 9 Jan 2008 15:42:38 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: On Wednesday 09 January 2008 13:07, Josh Boyer wrote: On Wed, 9 Jan 2008 12:16:25 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: Josh, Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch. I applied it there, just haven't pushed it out yet. Will do that today. BTW, is it normal to edit the defconfig file by hand? The defconfig? Not sure. What I normally do is a make foo_defconfig, edit the .config, make oldconfig, and copy the resulting .config back to foo_defconfig. Yes, this is what I also do. But how did Hollis get these lines into .config or sequoia_defconfig: +CONFIG_IBM_NEW_EMAC=y +CONFIG_IBM_NEW_EMAC_RXB=128 +CONFIG_IBM_NEW_EMAC_TXB=64 +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 I did not find any Kconfigs where these might come from. They're in drivers/net/ibm_newemac/Kconfig. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI interrupt assignment on sequoia board
On Wed, 9 Jan 2008 16:53:22 +0100 Matthias Fuchs [EMAIL PROTECTED] wrote: Hi, I noticed that Josh's 'for-2.5.25' does not assign PCI interrupts correctly: bash-3.00# lspci -v 00:00.0 Class 0680: 1014:027f Subsystem: 10e8:cafe Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at unassigned (32-bit, prefetchable) Capabilities: [58] Power Management version 2 00:0a.0 Class 0b20: 1014:027f (this is a PPC440EPx PCI target board in a sequoia PCI slot) Subsystem: 12fe:0441 Flags: bus master, medium devsel, latency 128, IRQ 16 Memory at 00018000 (32-bit, prefetchable) [size=64M] Memory at 00018400 (32-bit, prefetchable) [size=16M] Capabilities: [58] Power Management version 2 00:0c.0 Class 0200: 168c:0013 (rev 01) Subsystem: 14b7:0a60 Flags: bus master, medium devsel, latency 128, IRQ 16 Memory at 00018500 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 bash-3.00# uname -a Linux sequoia 2.6.24-rc6-g78994e24 #5 Wed Jan 9 16:22:31 CET 2008 ppc ppc ppc GNU/Linux All interrupts are '16'. But I expected 67 as correctly stated in the device tree. This test has been made with the uboot wrapper code. Any idea? Does lspci display the virtual IRQ number that is assigned when the device tree is parsed and interrupts are mapped? I think so. If you look at the other devices in /proc/interrupts you'll see they have the virtual IRQ numbers as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI interrupt assignment on sequoia board
Hi Matthias, On Wednesday 09 January 2008, Matthias Fuchs wrote: I noticed that Josh's 'for-2.5.25' does not assign PCI interrupts correctly: bash-3.00# lspci -v 00:00.0 Class 0680: 1014:027f Subsystem: 10e8:cafe Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at unassigned (32-bit, prefetchable) Capabilities: [58] Power Management version 2 00:0a.0 Class 0b20: 1014:027f (this is a PPC440EPx PCI target board in a sequoia PCI slot) Subsystem: 12fe:0441 Flags: bus master, medium devsel, latency 128, IRQ 16 Memory at 00018000 (32-bit, prefetchable) [size=64M] Memory at 00018400 (32-bit, prefetchable) [size=16M] Capabilities: [58] Power Management version 2 00:0c.0 Class 0200: 168c:0013 (rev 01) Subsystem: 14b7:0a60 Flags: bus master, medium devsel, latency 128, IRQ 16 Memory at 00018500 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 bash-3.00# uname -a Linux sequoia 2.6.24-rc6-g78994e24 #5 Wed Jan 9 16:22:31 CET 2008 ppc ppc ppc GNU/Linux All interrupts are '16'. But I expected 67 as correctly stated in the device tree. This test has been made with the uboot wrapper code. Those are virtual interrupt numbers. Yeah, that's confusing, I know. The implementation should be correct. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix remainder calculating bug in single floating pointdivision
On Jan 9, 2008, at 9:38 AM, Liu Yu wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Tuesday, January 08, 2008 2:20 PM To: Dan Malek Cc: Liu Yu; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] Fix remainder calculating bug in single floating pointdivision On Jan 6, 2008, at 2:44 PM, Dan Malek wrote: On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote: It's nice to see somebody digging in that scary math emu stuff. If you could also get rid of the warnings, it would be perfect :-) Yes, it is :-) I didn't think it would have a life beyond MPC8xx. that this code was lifted from somewhere else (glibc ? gcc soft-float ?), It seems like a lifetime ago I copied the framework from Sparc, and the internals from gcc soft-float. I didn't change any of the internal emulation functions (hence, some of the warnings), just the calling interface. While it's convenient, I still don't think kernel float emulation should be a solution. The tools should generate soft-float for the applications and libraries. If we think this is really true, we could move to using include/math- emu/* instead of the files in powerpc/math-emu. Why it's better to move to using include/math-emu. I found they have similar framework, is powerpc/math-emu evolved from include/math-emu? * We dont really need more than one way in the kernel source tree to do math-emu * include/math-emu is used by more archs so gets more review * include/math-emu is closer to glibc soft-fp code so fixes to one apply cleanly to the other - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
Sven Luther wrote: Let's just fix this in the kernel, until we get a fixed efika firmware, then we can drop it easily enough. But until this happens, we need to be able to boot the kernel without any extra work on the users part. That is exactly why I don't like the idea. Yes, it makes it easier for users and easier for distro managers to say it supports the Efika but it makes the Forth fixing, and any further firmware development (ignore the lack of releases, it means nothing) much harder. It should not be a function of Linux to fix firmware problems. This was the FIRM line by Ben, Segher and the rest of the LinuxPPC guys when we released the Efika - fix the firmware, not Linux, don't hack drivers, don't rely on fixups. I disagreed at the time due to the urgency to release the board, but now, we have the luxury of not having to rush it through to get a product on sale. I would much rather the Linux kernel did not implement fixups for firmware which we can fix. The phy-handle part that Olaf specifies in his patch can be added by a user to nvramrc, BY HAND, in around 10 lines of Forth code. Those 6 lines are in the efika.forth script, and in fact Olaf is simply running interpret over an encoded version of this! (I say 10 lines because the efika.forth script is needlessly verbose for the purpose of being readable by humans). It is not scary or difficult to do this if you need ethernet to work, and not beyond the scope of the installation documentation or an Efika wiki page. The Forth stuff will work fine for *all* operating systems. If you don't like not having your Linux distro or a default kernel working on our default firmware, PLEASE FEEL FREE TO BLAME US. PROFUSELY. Alternatively I'd love to work with people to create a comprehensive pre-update binary fix (not a boot loader but an installer) for the Forth script so that users can run it before they boot any distro disk, and then the kernel on the CD, the kernel in the distro repositories, will not have the burden of tracking firmware releases, and the Linux team will not have the burden of maintaining tiny fixes for things which may always be fixed. After all, there is no profit or benefit in fixing something 5 times just in case the user only has 4 of them installed. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 04:30:13PM +, Matt Sealey wrote: Sven Luther wrote: Let's just fix this in the kernel, until we get a fixed efika firmware, then we can drop it easily enough. But until this happens, we need to be able to boot the kernel without any extra work on the users part. That is exactly why I don't like the idea. Yes, it makes it easier for users and easier for distro managers to say it supports the Efika but it makes the Forth fixing, and any further firmware development (ignore the lack of releases, it means nothing) much harder. efika firmware development is dead. Until we see a release we should assume that the efika is a firmware with breakage, and no upstream support at all. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] add phy-handle property for fec_mpc52xx
From: Olaf Hering [EMAIL PROTECTED]
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
(Olaf's s-o-b line needs to go here)
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
and to make it check if the nodes exist before blindly creating them.
Cheers,
g.
arch/powerpc/kernel/prom_init.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1add6ef..5d89a21 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
prom_printf(fixup_device_tree_efika: ,
skipped entry %x - setprop error\n, i);
}
+
+ /* Make sure ethernet mdio bus node exists */
+ node = call_prom(finddevice, 1, 1, ADDR(/builtin/mdio));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf(Adding Ethernet MDIO node\n);
+ call_prom(interpret, 1, 1,
+s\ /builtin\ find-device
+new-device
+1 encode-int s\ #address-cells\ property
+0 encode-int s\ #size-cells\ property
+s\ mdio\ 2dup device-name device-type
+s\ mpc5200b-fec-phy\ encode-string
+s\ compatible\ property
+0xf0003000 0x400 reg
+0x2 encode-int
+0x5 encode-int encode+
+0x3 encode-int encode+
+s\ interrupts\ property
+finish-device);
+ };
+
+ /* Make sure ethernet phy device node exist */
+ node = call_prom(finddevice, 1, 1,
ADDR(/builtin/mdio/ethernet-phy));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf(Adding Ethernet PHY node\n);
+ call_prom(interpret, 1, 1,
+s\ /builtin/mdio\ find-device
+new-device
+s\ ethernet-phy\ device-name
+0x10 encode-int s\ reg\ property
+my-self
+ihandlephandle
+finish-device
+s\ /builtin/ethernet\ find-device
+encode-int
+s\ phy-handle\ property
+device-end);
+ }
+
}
#else
#define fixup_device_tree_efika()
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On 1/9/08, Matt Sealey [EMAIL PROTECTED] wrote: However, I'm still inclined to pick up Olaf's patch with the appropriate protections around it so it is only done if the nodes are missing. Eh.. yeah. Maybe. Seems like a cop-out to me. I would rather you removed the patch and called us a bunch of idiots for coding bad firmware, than have the fixups be dependant on what could turn into a very well coded but essentially screen-long list of fixups for myriad firmware versions where the properties may or may not be present or correct for various firmware versions and devices. I've come to the conclusion that Postel knew what he was talking about; Be conservative in what you do; be liberal in what you accept from others. :-) I 100% agree that this stuff is better done in firmware. However, until that stuff is in place; it is 100% reasonable and desirable to work around it in prom_init. That being said, I will modify prom_init to not blindly apply fixups if they have already been done in firmware. Grant, are you any good at coding firmware-level stuff without utilizing any preexisting code under the GPL? I'd like to collaborate on an installer tool which can put efika.forth (and therefore all these fixes) in. I'm good at firmware stuff, but time comes at a premium. This level of work would require a contract arrangement between our two companies. Cheers, g. -- 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: [RFC] add phy-handle property for fec_mpc52xx
Okay I have a better suggestion.
Apply all the prom_init fixes you like. But, instead of swizzling on the
individual nodes, do it blanket for the firmware version.
For instance, wrap the entire efika fixups stuff with a check for the
openprom property built-on - this is the date the firmware was built.
efika.forth will change this!
Just make sure it's less than.. let's say, a certain version of efika.forth,
and I will roll a version which has a higher version and some extra features
like CAN/I2C exposure.
If you run efika.forth it will not touch the device tree. If you don't, it
will add the small amount of patches. Add a huge comment that this hunk of
code should be scheduled for deletion at some later date. Put a Kconfig
around it so it can be taken out, even, at distro option.
Does that sound better? Right now I'm a little too busy to write and
compile test code for it so I will not venture to submit a patch..
do we want to work on a comprehensive, required efika.forth release
that fixes these things together, or is it just my job for now?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Grant Likely wrote:
From: Olaf Hering [EMAIL PROTECTED]
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
(Olaf's s-o-b line needs to go here)
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
and to make it check if the nodes exist before blindly creating them.
Cheers,
g.
arch/powerpc/kernel/prom_init.c | 39
+++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1add6ef..5d89a21 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
prom_printf(fixup_device_tree_efika: ,
skipped entry %x - setprop error\n, i);
}
+
+ /* Make sure ethernet mdio bus node exists */
+ node = call_prom(finddevice, 1, 1, ADDR(/builtin/mdio));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf(Adding Ethernet MDIO node\n);
+ call_prom(interpret, 1, 1,
+ s\ /builtin\ find-device
+ new-device
+ 1 encode-int s\ #address-cells\ property
+ 0 encode-int s\ #size-cells\ property
+ s\ mdio\ 2dup device-name device-type
+ s\ mpc5200b-fec-phy\ encode-string
+ s\ compatible\ property
+ 0xf0003000 0x400 reg
+ 0x2 encode-int
+ 0x5 encode-int encode+
+ 0x3 encode-int encode+
+ s\ interrupts\ property
+ finish-device);
+ };
+
+ /* Make sure ethernet phy device node exist */
+ node = call_prom(finddevice, 1, 1,
ADDR(/builtin/mdio/ethernet-phy));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf(Adding Ethernet PHY node\n);
+ call_prom(interpret, 1, 1,
+ s\ /builtin/mdio\ find-device
+ new-device
+ s\ ethernet-phy\ device-name
+ 0x10 encode-int s\ reg\ property
+ my-self
+ ihandlephandle
+ finish-device
+ s\ /builtin/ethernet\ find-device
+ encode-int
+ s\ phy-handle\ property
+ device-end);
+ }
+
}
#else
#define fixup_device_tree_efika()
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 04:36:19PM +, Matt Sealey wrote: Sven Luther wrote: On Wed, Jan 09, 2008 at 04:30:13PM +, Matt Sealey wrote: Sven Luther wrote: Let's just fix this in the kernel, until we get a fixed efika firmware, then we can drop it easily enough. But until this happens, we need to be able to boot the kernel without any extra work on the users part. That is exactly why I don't like the idea. Yes, it makes it easier for users and easier for distro managers to say it supports the Efika but it makes the Forth fixing, and any further firmware development (ignore the lack of releases, it means nothing) much harder. efika firmware development is dead. Until we see a release we should assume that the efika is a firmware with breakage, and no upstream The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is* the upstream support for now. What his patch does is say, the upstream support exists, but we don't like it, so we will supplement the patch.. Matt, your work on efika.forth is laudable, and it is nice that you took the time to support it. *BUT* it is not acceptable for a distribution, or for someone who will have to do user support, to have to launch a second binary before launching the kernel. Especially when netbooting for example. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
Sven Luther wrote: On Wed, Jan 09, 2008 at 04:36:19PM +, Matt Sealey wrote: The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is* the upstream support for now. What his patch does is say, the upstream support exists, but we don't like it, so we will supplement the patch.. Matt, your work on efika.forth is laudable, and it is nice that you took the time to support it. *BUT* it is not acceptable for a distribution, or for someone who will have to do user support, to have to launch a second binary before launching the kernel. Especially when netbooting for example. Then I think you are all missing the fact that I said there *IS A REALLY CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not be a runnable script, but executed on boot, because it'll be flashed into nvramrc. However I don't have the time to go into making this app, creating the tools to munge efika.forth into a correct more uploadable format, and creating the install tool. I barely have enough time to track this list and make sure any drivers requiring firmware tree changes are taken care of (I definitely lost the plot with the USB one, I haven't even checked it even though I was asked to 2 weeks ago..) Unfortunately one guy who already has a significant amount of work to do all day, who is not the responsible person for firmware issues, and is not being assisted by anyone in the community either generated and maintained by Genesi or existing around Linux, poses some serious problems with timeliness of updates. If anyone wants to stop patching Linux and instead make efika.forth easier to use, feel free, REALLY. Sven, are you volunteering for this REALLY tiny task? It will probably take all of a day for a couple of guys to work up the tools to do it based on very simple instructions and data provided.. the work is probably worth the price of a pizza, so no contracts are going to be worked out for it. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [patch 4/4 v2] PS3: Add logical performance monitor driver support
Hello,
I found a bug in our patch.
+/**
+ * ps3_lpm_open - Open the logical performance monitor device.
+ * @tb_type: Specifies the type of trace buffer lv1 sould use for this lpm
+ * instance, specified by one of enum ps3_lpm_tb_type.
+ * @tb_cache: Optional user supplied buffer to use as the trace buffer cache.
+ * If NULL, the driver will allocate and manage an internal buffer.
+ * Unused when when @tb_type is PS3_LPM_TB_TYPE_NONE.
+ * @tb_cache_size: The size in bytes of the user supplied @tb_cache buffer.
+ * Unused when @tb_cache is NULL or @tb_type is PS3_LPM_TB_TYPE_NONE.
+ */
+
+int ps3_lpm_open(enum ps3_lpm_tb_type tb_type, void *tb_cache,
+ u64 tb_cache_size)
+{
+ int result;
+ u64 tb_size;
+
+ BUG_ON(!lpm_priv);
+ BUG_ON(tb_type != PS3_LPM_TB_TYPE_NONE
+ tb_type != PS3_LPM_TB_TYPE_INTERNAL);
+
+ if (tb_type == PS3_LPM_TB_TYPE_NONE tb_cache)
+ dev_dbg(sbd_core(), %s:%u: bad in vals\n, __func__, __LINE__);
+
+ if (!atomic_add_unless(lpm_priv-open, 1, 1)) {
+ dev_dbg(sbd_core(), %s:%u: busy\n, __func__, __LINE__);
+ return -EBUSY;
+ }
+
+ if (tb_type == PS3_LPM_TB_TYPE_NONE) {
+ lpm_priv-tb_cache_internal = NULL;
+ lpm_priv-tb_cache_size = 0;
+ lpm_priv-tb_cache = NULL;
+ } else if (tb_cache) {
+ if (tb_cache != (void *)_ALIGN_UP((unsigned long)tb_cache, 128)
+ || tb_cache_size != _ALIGN_UP(tb_cache_size, 128)) {
+ dev_err(sbd_core(), %s:%u: unaligned tb_cache\n,
+ __func__, __LINE__);
+ result = -EINVAL;
+ goto fail_align;
+ }
+ lpm_priv-tb_cache_internal = NULL;
+ lpm_priv-tb_cache_size = tb_cache_size;
+ lpm_priv-tb_cache = tb_cache;
+ } else {
+ /* tb_cache needs 128 byte alignment. */
+ lpm_priv-tb_cache_size = PS3_LPM_DEFAULT_TB_CACHE_SIZE;
+ lpm_priv-tb_cache_internal = kzalloc(tb_cache_size + 127,
The first parameter of kzalloc() is wrong.
lpm_priv-tb_cache_internal = kzalloc(lpm_priv-tb_cache_size +
127,
^^
+ GFP_KERNEL);
+ if (!lpm_priv-tb_cache_internal) {
+ dev_err(sbd_core(), %s:%u: alloc internal tb_cache
+ failed\n, __func__, __LINE__);
+ result = -ENOMEM;
+ goto fail_malloc;
+ }
+ lpm_priv-tb_cache = (void *)_ALIGN_UP(
+ (unsigned long)lpm_priv-tb_cache_internal, 128);
+ }
+
+ result = lv1_construct_lpm(0, tb_type, 0, 0,
+ ps3_mm_phys_to_lpar(__pa(lpm_priv-tb_cache)),
+ lpm_priv-tb_cache_size, lpm_priv-lpm_id,
+ lpm_priv-outlet_id, tb_size);
+
+ if (result) {
+ dev_err(sbd_core(), %s:%u: lv1_construct_lpm failed: %s\n,
+ __func__, __LINE__, ps3_result(result));
+ result = -EINVAL;
+ goto fail_construct;
+ }
+
+ lpm_priv-shadow.pm_control = PS3_LPM_SHADOW_REG_INIT;
+ lpm_priv-shadow.pm_start_stop = PS3_LPM_SHADOW_REG_INIT;
+ lpm_priv-shadow.pm_interval = PS3_LPM_SHADOW_REG_INIT;
+ lpm_priv-shadow.group_control = PS3_LPM_SHADOW_REG_INIT;
+ lpm_priv-shadow.debug_bus_control = PS3_LPM_SHADOW_REG_INIT;
+
+ dev_dbg(sbd_core(), %s:%u: lpm_id 0x%lx, outlet_id 0x%lx,
+ tb_size 0x%lx\n, __func__, __LINE__, lpm_priv-lpm_id,
+ lpm_priv-outlet_id, tb_size);
+
+ return 0;
+
+fail_construct:
+ kfree(lpm_priv-tb_cache_internal);
+ lpm_priv-tb_cache_internal = NULL;
+fail_malloc:
+fail_align:
+ atomic_dec(lpm_priv-open);
+ return result;
+}
+EXPORT_SYMBOL_GPL(ps3_lpm_open);
Thanks.
Takashi Yamamoto.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Linux for ml310
always CC the mailing list when replying. On 1/9/08, Joachim Meyer [EMAIL PROTECTED] wrote: arch/ppc/boot/common/ns16550.c:21: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared here (not in a function) arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].baud_base') arch/ppc/boot/common/ns16550.c:21: error: `XPAR_INTC_0_UARTNS550_0_VEC_ID' undeclared here (not in a function) arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].irq') arch/ppc/boot/common/ns16550.c:21: error: `XPAR_UARTNS550_0_BASEADDR' undeclared here (not in a function) arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].iomem_base') arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0]' You're xparameters_ml300.h file does not define `XPAR_UARTNS550_0_CLOCK_FREQ_HZ', `XPAR_INTC_0_UARTNS550_0_VEC_ID' and `XPAR_UARTNS550_0_BASEADDR'. You'll need to look in your xparams file, find out what the real #defines are for the uart and add fixups to xparameter.h so ns16550 can find them. You're almost there! :-) g. -- 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: Generic MMC-over-SPI binding?
Hi, Arnd Bergmann wrote: The important part where this connects to the mmc-spi driver is that you need to set spi_board_info-modalias to mmc-spi, if the device node can be identified as an mmc card. Doing that now, using the code you provided as a base. The SPI child device gets registered, but it appears something is still missing as no messages I could attribute to mmc-spi appear. My suspicion would be that it doesn't like the monolithic kernel for some reason (the mmc-spi driver registers itself as a driver called mmc_spi, not sure if the modalias handling will catch that; still investigating there). Then you call that function after registering the master, from mpc52xx_psc_spi_of_probe. I've changed mpc52xx_psc_spi_do_probe to have an additional argument for the OF device node of the SPI master; ARCH=ppc can call this with NULL as long as it still exists. Simon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 04:56:17PM +, Matt Sealey wrote: Okay I have a better suggestion. Apply all the prom_init fixes you like. But, instead of swizzling on the individual nodes, do it blanket for the firmware version. For instance, wrap the entire efika fixups stuff with a check for the openprom property built-on - this is the date the firmware was built. efika.forth will change this! This is crazy, and not future proof. The way Grant did it, checking for the existence of the node before creating is enough for any reasonable upgrade to the firmware. If future firmware will break with this, then they will break other stuff anyway, and a new patch is needed. Just make sure it's less than.. let's say, a certain version of efika.forth, and I will roll a version which has a higher version and some extra features like CAN/I2C exposure. If you run efika.forth it will not touch the device tree. If you don't, it will add the small amount of patches. Add a huge comment that this hunk of code should be scheduled for deletion at some later date. Put a Kconfig around it so it can be taken out, even, at distro option. Have you not read Grant's code ? It create the nodes only if they are not existent already. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 05:17:52PM +, Matt Sealey wrote: Sven Luther wrote: On Wed, Jan 09, 2008 at 04:36:19PM +, Matt Sealey wrote: The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is* the upstream support for now. What his patch does is say, the upstream support exists, but we don't like it, so we will supplement the patch.. Matt, your work on efika.forth is laudable, and it is nice that you took the time to support it. *BUT* it is not acceptable for a distribution, or for someone who will have to do user support, to have to launch a second binary before launching the kernel. Especially when netbooting for example. Then I think you are all missing the fact that I said there *IS A REALLY CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not be a runnable script, but executed on boot, because it'll be flashed into nvramrc. However I don't have the time to go into making this app, creating the tools to munge efika.forth into a correct more uploadable format, and creating the install tool. I barely have enough time to track this list and make sure any drivers requiring firmware tree changes are taken care of (I definitely lost the plot with the USB one, I haven't even checked it even though I was asked to 2 weeks ago..) Unfortunately one guy who already has a significant amount of work to do all day, who is not the responsible person for firmware issues, and is not being assisted by anyone in the community either generated and maintained by Genesi or existing around Linux, poses some serious problems with timeliness of updates. If anyone wants to stop patching Linux and instead make efika.forth easier to use, feel free, REALLY. Sven, are you volunteering for this REALLY tiny task? It will probably take all of a day for a couple of guys to work up the tools to do it based on very simple instructions and data provided.. the work is probably worth the price of a pizza, so no contracts are going to be worked out for it. Just fix it conditionally in linux, like it is being proposed, and everyone is happy :) Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Stefan Roese wrote: On Tuesday 08 January 2008, Sean MacLennan wrote: How about just 44x? Cheers, Sean diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..682deae 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if 44x No. Not all 44x have OHCI built in. Currently 440EP, 440EPx and 405EZ have it. But since your patch only touches 440EP, you should just enable OHCI for exactly this platform. Best regards, Stefan Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..2660f30 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if 440EP # MIPS: default y if SOC_AU1X00 # more: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Base Warp Platform support
So no comments? I got it perfect the first time :D Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
There were several issues if a memreserve range existed and happened
to be in highmem:
* The bootmem allocator is only aware of lowmem so calling
reserve_bootmem with a highmem address would cause a BUG_ON
* All highmem pages were provided to the buddy allocator
Added a lmb_is_reserved() api that we now use to determine if a highem
page should continue to be PageReserved or provided to the buddy
allocator.
Also, we incorrectly reported the amount of pages reserved since all
highmem pages are initally marked reserved and we clear the
PageReserved flag as we free up the highmem pages.
---
As normal, posted here for review, will be pushed via my for-2.6.25 branch
arch/powerpc/mm/lmb.c | 13 +
arch/powerpc/mm/mem.c | 14 ++
include/asm-powerpc/lmb.h |1 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 8f4d2dc..4ce23bc 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -342,3 +342,16 @@ void __init lmb_enforce_memory_limit(unsigned long
memory_limit)
}
}
}
+
+int __init lmb_is_reserved(unsigned long addr)
+{
+ int i;
+
+ for (i = 0; i lmb.reserved.cnt; i++) {
+ unsigned long upper = lmb.reserved.region[i].base +
+ lmb.reserved.region[i].size - 1;
+ if ((addr = lmb.reserved.region[i].base) (addr = upper))
+ return 1;
+ }
+ return 0;
+}
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5402fb6..a004032 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -218,9 +218,13 @@ void __init do_init_bootmem(void)
#endif
/* reserve the sections we're already using */
- for (i = 0; i lmb.reserved.cnt; i++)
- reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(lmb.reserved, i));
+ for (i = 0; i lmb.reserved.cnt; i++) {
+ unsigned long addr = lmb.reserved.region[i].base +
+lmb_size_bytes(lmb.reserved, i) - 1;
+ if (addr total_lowmem)
+ reserve_bootmem(lmb.reserved.region[i].base,
+ lmb_size_bytes(lmb.reserved, i));
+ }
/* XXX need to clip this if using highmem? */
sparse_memory_present_with_active_regions(0);
@@ -334,11 +338,13 @@ void __init mem_init(void)
highmem_mapnr = total_lowmem PAGE_SHIFT;
for (pfn = highmem_mapnr; pfn max_mapnr; ++pfn) {
struct page *page = pfn_to_page(pfn);
-
+ if (lmb_is_reserved(pfn PAGE_SHIFT))
+ continue;
ClearPageReserved(page);
init_page_count(page);
__free_page(page);
totalhigh_pages++;
+ reservedpages--;
}
totalram_pages += totalhigh_pages;
printk(KERN_DEBUG High memory: %luk\n,
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index b5f9f4c..5d1dc48 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -51,6 +51,7 @@ extern unsigned long __init __lmb_alloc_base(unsigned long
size,
extern unsigned long __init lmb_phys_mem_size(void);
extern unsigned long __init lmb_end_of_DRAM(void);
extern void __init lmb_enforce_memory_limit(unsigned long memory_limit);
+extern int __init lmb_is_reserved(unsigned long addr);
extern void lmb_dump_all(void);
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
Sven Luther wrote: This is crazy, and not future proof. The way Grant did it, checking for the existence of the node before creating is enough for any reasonable upgrade to the firmware. If future firmware will break with this, then they will break other stuff anyway, and a new patch is needed. In other words, Grant's method is crazy and not future-proof, too. I don't see the difference, Sven, and this demonstrates entirely Just make sure it's less than.. let's say, a certain version of efika.forth, and I will roll a version which has a higher version and some extra features like CAN/I2C exposure. If you run efika.forth it will not touch the device tree. If you don't, it will add the small amount of patches. Add a huge comment that this hunk of code should be scheduled for deletion at some later date. Put a Kconfig around it so it can be taken out, even, at distro option. Have you not read Grant's code ? It create the nodes only if they are not existent already. What if they ARE existant under other names, you will have two ethernet-phy in the system, maybe with the same name, and this is stupid. What if it adds the wrong properties if we work out something is wrong somewhere? Linux prom_init must not be a moving target for firmware development - it is the hardest thing to replace (it is not like loading and unloading a module) and it may in fact be polluting valid device trees REGARDLESS of any checks you might make. You cannot make Linux try and PREDICT how the device tree looks based on arbitrary name strings, because Linux device tree usage does not comply with the IEEE 1275-1994 definition of device tree properties. Grant's patch should look for a compatible property with ethernet-phy in it, check for phy-handle in the ethernet node, make sure that a node very similar to mdio does not already exist, etc, it is going into a screen of code to do it comprehensively and future proof. Just don't do it at all. The burden is on Genesi. So, it's difficult right now, and hard for users, so what? That's OUR problem, I dare say today it is MY problem. I do not want this to become a LINUX problem in the future when a new board comes out that is Efika-compatible, requiring patch removal, reshuffling, compliance testing etc. You do realise any new firmware with this kernel needs to work, regardless of the patch being present, in order to be validated? We can't ship an Efika board with a firmware which actively breaks because of a Linux kernel patch for older boards and some ancient bad decision, and saying to use a new Efika you must use a brand new Linux kernel is the kind of insanity in embedded development which made us choose SmartFirmware over U-Boot and FDT in the first place.. I am not happy that we are being dragged into this model of playing first to mainline with arbitrary snippets of code which do NOT improve things in the long term. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Kconfig scsi_wait_scan
Michael, I find I need to add a string to the SCSI_WAIT_SCAN tristate in order to be able to turn the module off. See the patch below. On our embedded appliance the only use for SCSI is for the usb_storage driver. Cheers, Sean MacLennan Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..960dc78 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -248,7 +248,7 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate SCSI wait scan default m depends on SCSI depends on MODULES ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ad7414 driver
Mark,
This patch adds a driver for the ad7414 chip. It was written by Stefan
Roese based on the ad7418 driver. All I did was get it compiling under
the newer kernels.
Cheers,
Sean MacLennan
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a0445be..f14972a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -57,6 +57,16 @@ config SENSORS_ABITUGURU3
This driver can also be built as a module. If so, the module
will be called abituguru3.
+config SENSORS_AD7414
+ tristate Analog Devices AD7414
+ depends on I2C EXPERIMENTAL
+ help
+ If you say yes here you get support for the Analog Devices
+ AD7414 temperature monitoring chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called ad7414.
+
config SENSORS_AD7418
tristate Analog Devices AD7416, AD7417 and AD7418
depends on I2C EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 55595f6..fa6066e 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SENSORS_W83791D) += w83791d.o
obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
+obj-$(CONFIG_SENSORS_AD7414) += ad7414.o
obj-$(CONFIG_SENSORS_AD7418) += ad7418.o
obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o
obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o
@@ -72,4 +73,3 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
endif
-
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ drivers/hwmon/ad7414.c 2008-01-09 12:09:51.0 -0500
@@ -0,0 +1,322 @@
+/*
+ * An hwmon driver for the Analog Devices AD7414
+ *
+ * Copyright 2006 Stefan Roese [EMAIL PROTECTED], DENX Software Engineering
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * Based on ad7418.c
+ * Copyright 2006 Tower Technologies, Alessandro Zummo [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 Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/i2c.h
+#include linux/hwmon.h
+#include linux/err.h
+#include linux/mutex.h
+#include linux/delay.h
+
+
+#define DRV_VERSION 0.2
+
+/* straight from the datasheet */
+#define AD7414_TEMP_MIN (-55000)
+#define AD7414_TEMP_MAX 125000
+
+/* Addresses to scan */
+static unsigned short normal_i2c[] = { 0x48, 0x4a, I2C_CLIENT_END };
+
+/* Insmod parameters */
+I2C_CLIENT_INSMOD;
+
+/* AD7414 registers */
+#define AD7414_REG_TEMP0x00
+#define AD7414_REG_CONF0x01
+#define AD7414_REG_T_HIGH 0x02
+#define AD7414_REG_T_LOW 0x03
+
+struct ad7414_data {
+ struct i2c_client client;
+ struct device *dev;
+ struct mutexlock;
+ charvalid; /* !=0 if following fields are
valid */
+ unsigned long last_updated; /* In jiffies */
+ u16 temp_input; /* Register values */
+ u8 temp_max;
+ u8 temp_min;
+ u8 temp_alert;
+ u8 temp_max_flag;
+ u8 temp_min_flag;
+};
+
+
+struct ad7414_dev {
+ struct list_head list;
+ struct device *dev;
+};
+
+static LIST_HEAD(ad7414_dev_list);
+
+
+static int ad7414_attach_adapter(struct i2c_adapter *adapter);
+static int ad7414_detect(struct i2c_adapter *adapter, int address, int kind);
+static int ad7414_detach_client(struct i2c_client *client);
+
+static struct i2c_driver ad7414_driver = {
+ .driver = {
+ .name = ad7414,
+ },
+ .attach_adapter = ad7414_attach_adapter,
+ .detach_client = ad7414_detach_client,
+};
+
+/*
+ * TEMP: 0.001C/bit (-55C to +125C)
+ * REG: (0.5C/bit, two's complement) 7
+ */
+static inline int AD7414_TEMP_FROM_REG(u16 reg)
+{
+ /* use integer division instead of equivalent right shift to
+* guarantee arithmetic shift and preserve the sign
+*/
+ return ((s16)reg / 128) * 500;
+}
+
+/* All registers are word-sized, except for the configuration registers.
+ * AD7414 uses a high-byte first convention, which is exactly opposite to
+ * the usual practice.
+ */
+static int ad7414_read(struct i2c_client *client, u8 reg)
+{
+ if (reg == AD7414_REG_TEMP)
+ return swab16(i2c_smbus_read_word_data(client, reg));
+ else
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ad7414_write(struct i2c_client *client, u8 reg, u16 value)
Re: [PATCH] MTD for Taco
Stefan Roese wrote:
On Saturday 05 January 2008, Sean MacLennan wrote:
This patch adds the maps for the taco. It also gets the ndfc.c NAND
driver in a compilable state. The map is guaranteed to change since the
exact NOR/NAND flash configuration is in flux right now when we found
the 256M NAND flash won't boot properly.
Currently it configures the NOR in a reasonable fashion and leaves the
NAND as one honkin' parition.
snip
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..f5e93cf 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,6 @@
#include linux/platform_device.h
#include asm/io.h
-#ifdef CONFIG_40x
-#include asm/ibm405.h
-#else
-#include asm/ibm44x.h
-#endif
You do break arch/ppc support with this patch. We have to still support
arch/ppc a few month, so please don't break this support for now.
Here is an updated patch that does not break the ppc arch support.
Unfortunately, it still has the taco specific patch. I can't find
anything different between the taco and the sequoia and since this patch
fixes the problem, the hardware guys refuse to look into it. I can't
blame them as we are overloaded as it is.
But I will send out the patch anyway in case anybody needs the ndfc
driver working under the powerpc arch.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..ca9f35a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -153,7 +153,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 1c0e89f..fe19177 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,13 @@
#include linux/platform_device.h
#include asm/io.h
+#ifndef CONFIG_PPC_MERGE
#ifdef CONFIG_40x
#include asm/ibm405.h
#else
#include asm/ibm44x.h
#endif
+#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +112,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_WARP
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the Warp!
+ */
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ *p++ = __raw_readb(ndfc-ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ __raw_writeb(*p++, ndfc-ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ if (*p++ != __raw_readb(ndfc-ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
/*
* Speedups for buffer read/write/verify
*
@@ -145,6 +181,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const
uint8_t *buf, int len)
return -EFAULT;
return 0;
}
+#endif
/*
* Initialize chip structure
@@ -236,6 +273,8 @@ static int ndfc_nand_probe(struct platform_device *pdev)
#ifndef CONFIG_PHYS_64BIT
ndfc-ndfcbase = ioremap((phys_addr_t)phys, res-end - res-start + 1);
+#elif defined(CONFIG_PPC_MERGE)
+ ndfc-ndfcbase = ioremap(phys, res-end - res-start + 1);
#else
ndfc-ndfcbase = ioremap64(phys, res-end - res-start + 1);
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3 v2] Add initial iomega StorCenter board port.
On Tue, Jan 08, 2008 at 04:07:17PM -0600, Jon Loeliger wrote:
+static void storcenter_power_off(void)
+{
+ /* No way to shut power off with software */
+ local_irq_disable();
+ for (;;) ;
+ /* NOTREACHED */
+}
So leave it out, and let the generic halt function be used.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
Josh Boyer wrote: On Wed, 09 Jan 2008 13:05:35 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Stefan Roese wrote: On Saturday 05 January 2008, Sean MacLennan wrote: This patch adds the maps for the taco. It also gets the ndfc.c NAND driver in a compilable state. The map is guaranteed to change since the exact NOR/NAND flash configuration is in flux right now when we found the 256M NAND flash won't boot properly. Currently it configures the NOR in a reasonable fashion and leaves the NAND as one honkin' parition. snip diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 1c0e89f..f5e93cf 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -24,11 +24,6 @@ #include linux/platform_device.h #include asm/io.h -#ifdef CONFIG_40x -#include asm/ibm405.h -#else -#include asm/ibm44x.h -#endif You do break arch/ppc support with this patch. We have to still support arch/ppc a few month, so please don't break this support for now. Here is an updated patch that does not break the ppc arch support. Unfortunately, it still has the taco specific patch. I can't find anything different between the taco and the sequoia and since this patch fixes the problem, the hardware guys refuse to look into it. I can't blame them as we are overloaded as it is. But I will send out the patch anyway in case anybody needs the ndfc driver working under the powerpc arch. This doesn't really get the addresses, etc from the device tree though, correct? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev No. You have to setup everything the old way. This *just* gets it working so if you have the PPC layout, it will work. Unless testing goes *really* well, I doubt I will have time in the short term to port it to the of_platform. I'm afraid I will have to live with it works, don't touch it for now :( Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
/* reserve the sections we're already using */
- for (i = 0; i lmb.reserved.cnt; i++)
- reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(lmb.reserved, i));
+ for (i = 0; i lmb.reserved.cnt; i++) {
+ unsigned long addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(lmb.reserved, i) - 1;
+ if (addr total_lowmem)
+ reserve_bootmem(lmb.reserved.region[i].base,
+ lmb_size_bytes(lmb.reserved, i));
+ }
It looks like if the reserved area straddles the highmem boundary, it'll
only reserve the highmem portion.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/2] Base Warp Platform support
Ooops. Guess I am not perfect after all ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.0 -0500
@@ -0,0 +1,239 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/init.h
+#include linux/of_platform.h
+#include linux/kthread.h
+
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+
+#include 44x.h
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = ibm,plb4, },
+ { .compatible = ibm,opb, },
+ { .compatible = ibm,ebc, },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if(!of_flat_dt_is_compatible(root, pika,warp))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = Warp,
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds = ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds = ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ void *fpga;
+ int irq;
+ struct resource res;
+ struct task_struct *dtm_thread;
+
+ if((np = of_find_compatible_node(NULL, NULL, pika,fpga)) == NULL) {
+ printk(KERN_ERR __FILE__ : Unable to find fpga\n);
+ return -ENOENT;
+ }
+
+ if((irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ : irq_of_parse_and_map failed\n);
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+* fpga space, which is over 8k.
+*/
+ if(of_address_to_resource(np, 0, res) ||
+ (fpga = ioremap(res.start, 0x24)) == NULL) {
+ printk(KERN_ERR __FILE__ : Unable to map FPGA\n);
+ return -ENOENT;
+ }
+
+ /* Turn off the line LEDs */
+ out_be32(fpga + 8, 0);
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, pika-dtm);
+
+ if(IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ printk(KERN_ERR __FILE__ : Unable to start PIKA DTM thread\n);
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(warp_fpga_init);
+
+#define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
+
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mtd/ndfc.h
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+
[PATCH v4 0/3] OF-platform PATA driver
Hi all, Here is the resend (aka v4) version of the OF-platform PATA driver and related patches. Changes since v3: - Acked-by: Paul Mundt [EMAIL PROTECTED] - In the powerpc specific patch: update defconfig and use machine_device_initcall -- this is new call found in the galak/powerpc.git. Changes since v2: - PPC added to PATA_PLATFORM depends on Kconfig entry; I didn't remove EMBEDDED depends on -- this wasn't discussed much and these patches should not depend on the decision. - cosmetic fixes; - s/ioport_shift/reg_shift/g patch dropped. Changes since v1: - __pata_platform_probe now accepts pio_mask argument; - pata-platform compatible property renamed to ata-generic; - pata_of_platform understands pio-mode property. It's used to pass pio_mask to the __pata_platform_probe. That is, in ata-generic context pio-mode means pio mode the bus already configured for; - New optional patch that renames pata_platform_info's ioport_shift to reg_shift. Changes since RFC: - nuked drivers/ata/pata_platform.h; - powerpc bits: proper localbus node added. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c | 144
include/linux/pata_platform.h |9 +++
2 files changed, 95 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..224bb6c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
-struct pata_platform_info *info)
+unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info info-ioport_shift)
- shift = info-ioport_shift;
-
ioaddr-data_addr = ioaddr-cmd_addr + (ATA_REG_DATA shift);
ioaddr-error_addr = ioaddr-cmd_addr + (ATA_REG_ERR shift);
ioaddr-feature_addr= ioaddr-cmd_addr + (ATA_REG_FEATURE shift);
@@ -114,8 +109,13 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
+ * @__pio_mask: PIO mask
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +135,18 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
-* Simple resource validation ..
-*/
- if ((pdev-num_resources != 3) (pdev-num_resources != 2)) {
- dev_err(pdev-dev, invalid number of resources\n);
- return -EINVAL;
- }
-
- /*
-* Get the I/O base first
-*/
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
-* Then the CTL base
-*/
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,20 +157,21 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq 0)
- irq = 0;/* no irq */
+ if (irq_res irq_res-start 0) {
+ irq = irq_res-start;
+ irq_flags = irq_res-flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(pdev-dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host-ports[0];
ap-ops = pata_platform_port_ops;
- ap-pio_mask = pio_mask;
+ ap-pio_mask = __pio_mask;
ap-flags |= ATA_FLAG_SLAVE_POSS;
/*
@@ -209,25 +186,24 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap-ioaddr.cmd_addr = devm_ioremap(pdev-dev, io_res-start,
+ ap-ioaddr.cmd_addr = devm_ioremap(dev, io_res-start,
io_res-end - io_res-start + 1);
-
[PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Also add || PPC to the PATA_PLATFORM's depends on Kconfig entry,
needed for PA Semi Electra.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Reviewed-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/ata/Kconfig| 12 -
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 104
3 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..64b4964 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -607,13 +607,23 @@ config PATA_WINBOND_VLB
config PATA_PLATFORM
tristate Generic platform device PATA support
- depends on EMBEDDED || ARCH_RPC
+ depends on EMBEDDED || ARCH_RPC || PPC
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate OpenFirmware platform device PATA support
+ depends on PATA_PLATFORM PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate Acorn ICS PATA support
depends on ARM ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI)+= pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 000..b7bc4e4
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,104 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/pata_platform.h
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev-node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int reg_shift = 0;
+ int pio_mode = 0;
+ int pio_mask;
+ const u32 *prop;
+
+ ret = of_address_to_resource(dn, 0, io_res);
+ if (ret) {
+ dev_err(ofdev-dev, can't get IO address from
+ device tree\n);
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, ctl_res);
+ if (ret) {
+ dev_err(ofdev-dev, can't get CTL address from
+ device tree\n);
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = of_get_property(dn, reg-shift, NULL);
+ if (prop)
+ reg_shift = *prop;
+
+ prop = of_get_property(dn, pio-mode, NULL);
+ if (prop) {
+ pio_mode = *prop;
+ if (pio_mode 6) {
+ dev_err(ofdev-dev, invalid pio-mode\n);
+ return -EINVAL;
+ }
+ } else {
+ dev_info(ofdev-dev, pio-mode unspecified, assuming PIO0\n);
+ }
+
+ pio_mask = 1 pio_mode;
+ pio_mask |= (1 pio_mode) - 1;
+
+ return __pata_platform_probe(ofdev-dev, io_res, ctl_res, irq_res,
+reg_shift, pio_mask);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(ofdev-dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = ata-generic, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pata_of_platform_match);
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = pata_of_platform,
+ .match_table= pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove =
Re: [PATCH] MTD for Taco
On Wed, 09 Jan 2008 13:05:35 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Stefan Roese wrote: On Saturday 05 January 2008, Sean MacLennan wrote: This patch adds the maps for the taco. It also gets the ndfc.c NAND driver in a compilable state. The map is guaranteed to change since the exact NOR/NAND flash configuration is in flux right now when we found the 256M NAND flash won't boot properly. Currently it configures the NOR in a reasonable fashion and leaves the NAND as one honkin' parition. snip diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 1c0e89f..f5e93cf 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -24,11 +24,6 @@ #include linux/platform_device.h #include asm/io.h -#ifdef CONFIG_40x -#include asm/ibm405.h -#else -#include asm/ibm44x.h -#endif You do break arch/ppc support with this patch. We have to still support arch/ppc a few month, so please don't break this support for now. Here is an updated patch that does not break the ppc arch support. Unfortunately, it still has the taco specific patch. I can't find anything different between the taco and the sequoia and since this patch fixes the problem, the hardware guys refuse to look into it. I can't blame them as we are overloaded as it is. But I will send out the patch anyway in case anybody needs the ndfc driver working under the powerpc arch. This doesn't really get the addresses, etc from the device tree though, correct? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
Hi Linas, Linas Vepstas wrote: On 08/01/2008, Nathan Lynch [EMAIL PROTECTED] wrote: Manish Ahuja wrote: + +The goal of hypervisor-assisted dump is to enable the dump of +a crashed system, and to do so from a fully-reset system, and +to minimize the total elapsed time until the system is back +in production use. Is it actually faster than kdump? This is a basic presumption; I used the word actually. I already know that it is intended to be faster. :) it should blow it away, as, after all, it requires one less reboot! There's more than rebooting going on during system dump processing. Depending on the system type, booting may not be where most time is spent. As a side effect, the system is in production *while* the dump is being taken; A dubious feature IMO. Seems that the design potentially trades reliability of first failure data capture for availability. E.g. system crashes, reboots, resumes processing while copying dump, crashes again before dump procedure is complete. How is that handled, if at all? with kdump, you can't go into production until after the dump is finished, and the system has been rebooted a second time. On systems with terabytes of RAM, the time difference can be hours. The difference in time it takes to resume the normal workload may be significant, yes. But the time it takes to get a usable dump image would seem to be the basically the same. Since you bring up large systems... a system with terabytes of RAM is practically guaranteed to be a NUMA configuration with dozens of cpus. When processing a dump on such a system, I wonder how well we fare: can we successfully boot with (say) 128 cpus and 256MB of usable memory? Do we have to hot-online nodes as system memory is freed up (and does that even work)? We need to be able to restore the system to its optimal topology when the dump is finished; if the best we can do is a degraded configuration, the workload will suffer and the system admin is likely to just reboot the machine again so the kernel will have the right NUMA topology. +Implementation details: +-- +In order for this scheme to work, memory needs to be reserved +quite early in the boot cycle. However, access to the device +tree this early in the boot cycle is difficult, and device-tree +access is needed to determine if there is a crash data waiting. I don't think this bit about early device tree access is correct. By the time your code is reserving memory (from early_init_devtree(), I think), RTAS has been instantiated and you are able to test for the existence of /rtas/ibm,dump-kernel. If I remember right, it was still too early to look up this token directly, so we wrote some code to crawl the flat device tree to find it. But not only was that a lot of work, but I somehow decided that doing this to the flat tree was wrong, as otherwise someone would surely have written the access code. If this can be made to work, that would be great, but we couldn't make it work at the time. +To work around this problem, all but 256MB of RAM is reserved +during early boot. A short while later in boot, a check is made +to determine if there is dump data waiting. If there isn't, +then the reserved memory is released to general kernel use. So I think these gymnastics are unneeded -- unless I'm misunderstanding something, you should be able to determine very early whether to reserve that memory. Only if you can get at rtas, but you can't get at rtas at that point. Sorry, but I think you are mistaken (see Michael's earlier reply). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also updates defconfig and adds some code to probe localbus.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 17 -
arch/powerpc/configs/mpc834x_itx_defconfig |3 ++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 12
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index e354f26..06d5b9c 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -253,6 +253,21 @@
device_type = pci;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,mpc8349e-localbus,
+fsl,pq2pro-localbus;
+ reg = e0005000 d8;
+ ranges = 3 0 f000 210;
-
+ [EMAIL PROTECTED],0 {
+ compatible = fsl,mpc8349emitx-pata, ata-generic;
+ reg = 3 0 10 3 20c 4;
+ reg-shift = 1;
+ pio-mode = 6;
+ interrupts = 17 8;
+ interrupt-parent = ipic;
+ };
+ };
};
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig
b/arch/powerpc/configs/mpc834x_itx_defconfig
index 6feb86e..2fbe4e5 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -570,7 +570,8 @@ CONFIG_SATA_SIL=y
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
-# CONFIG_PATA_PLATFORM is not set
+CONFIG_PATA_PLATFORM=y
+CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..50e8f63 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include linux/delay.h
#include linux/seq_file.h
#include linux/root_dev.h
+#include linux/of_platform.h
#include asm/system.h
#include asm/atomic.h
@@ -37,6 +38,17 @@
#include mpc83xx.h
+static struct of_device_id __initdata mpc834x_itx_ids[] = {
+ { .compatible = fsl,pq2pro-localbus, },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ return of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+}
+machine_device_initcall(mpc834x_itx, mpc834x_itx_declare_of_platform_devices);
+
/*
*
* Setup the architecture
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
On Wed, 09 Jan 2008 13:50:41 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: No. You have to setup everything the old way. This *just* gets it working so if you have the PPC layout, it will work. Unless testing goes *really* well, I doubt I will have time in the short term to port it to the of_platform. I'm afraid I will have to live with it works, don't touch it for now :( That's fine for you, nobody expects you to have to do all the porting for everything :). I don't want it actually ported to of_platform anyway. What I really want, and what Stefan has started some time ago, is to make it get the values from the device tree but still create the regular platform devices. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Base Warp Platform support
On Wed, 09 Jan 2008 12:30:39 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: So no comments? I got it perfect the first time :D Not quite.. :) The way you have the patches laid out right now will break compiling and git bisecting. Could you take these and roll them up into distinct patches that can all apply without breaking a compile individually? I recommend doing it this way: Patch 1) platform files in arch/powerpc/platforms/44x/ Patch 2) DTS Patch 3) boot files in arch/powerpc/boot Patch 4) defconfig or something along those lines. That way we can apply them in that order, nothing breaks for the compile, and they aren't scattered about. If you start a new email thread with those I think most of it looked fairly good otherwise. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
On Wed, 09 Jan 2008 12:26:14 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Signed-off-by: Sean MacLennan [EMAIL PROTECTED] This one needs to go to the linux-usb list and David Brownell. Although I'm not sure what the benefit here really is. You can still set this in the defconfig without adding this patch... I don't see a need to do a default. josh --- diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..2660f30 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if 440EP # MIPS: default y if SOC_AU1X00 # more: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Josh Boyer wrote: On Wed, 09 Jan 2008 12:26:14 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Signed-off-by: Sean MacLennan [EMAIL PROTECTED] This one needs to go to the linux-usb list and David Brownell. Although I'm not sure what the benefit here really is. You can still set this in the defconfig without adding this patch... I don't see a need to do a default. Without the default, I was unable to select this option. I may have solved it the wrong way. It seems if there is no string after the tristate or boolean, you are not allowed to set the variable, it can only default. So with no default, I cannot enable this option and therefore cannot enable the ohci driver. Again, I think the default PCI case catches most boards and all PCI-less, or possibly PCI-less, boards need a default. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Jan 9, 2008, at 12:53 PM, Scott Wood wrote:
On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
/* reserve the sections we're already using */
-for (i = 0; i lmb.reserved.cnt; i++)
-reserve_bootmem(lmb.reserved.region[i].base,
-lmb_size_bytes(lmb.reserved, i));
+for (i = 0; i lmb.reserved.cnt; i++) {
+unsigned long addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(lmb.reserved, i) - 1;
+if (addr total_lowmem)
+reserve_bootmem(lmb.reserved.region[i].base,
+lmb_size_bytes(lmb.reserved, i));
+}
It looks like if the reserved area straddles the highmem boundary,
it'll
only reserve the highmem portion.
Yeah, I thought about that. I'm wondering if we should warn about
this.. its seems like a bad thing to do.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
I used the word actually. I already know that it is intended to be faster. :) it should blow it away, as, after all, it requires one less reboot! There's more than rebooting going on during system dump processing. Depending on the system type, booting may not be where most time is spent. As a side effect, the system is in production *while* the dump is being taken; A dubious feature IMO. Seems that the design potentially trades reliability of first failure data capture for availability. E.g. system crashes, reboots, resumes processing while copying dump, crashes again before dump procedure is complete. How is that handled, if at all? This is a simple version. The intent was not to have a complex dump taking mechanism in version 1. Subsequent versions will see planned improvement on the way the pages are tracked and freed. Also it is very easily possible now, to register for another dump as soon as the scratch area is copied to a user designated region. But for now this simple implementation exists. It is also possible to extend this further to only preserve pages that are kernel pages and free the non required pages like user/data pages etc. This would reduce the space preserved and would prevent any issues that are caused by reserving everything in memory except for the first 256 MB. Improvements and future versions are planned to make this efficient. But for now the intent is to get this off the ground and handle simple cases. with kdump, you can't go into production until after the dump is finished, and the system has been rebooted a second time. On systems with terabytes of RAM, the time difference can be hours. The difference in time it takes to resume the normal workload may be significant, yes. But the time it takes to get a usable dump image would seem to be the basically the same. Since you bring up large systems... a system with terabytes of RAM is practically guaranteed to be a NUMA configuration with dozens of cpus. When processing a dump on such a system, I wonder how well we fare: can we successfully boot with (say) 128 cpus and 256MB of usable memory? Do we have to hot-online nodes as system memory is freed up (and does that even work)? We need to be able to restore the system to its optimal topology when the dump is finished; if the best we can do is a degraded configuration, the workload will suffer and the system admin is likely to just reboot the machine again so the kernel will have the right NUMA topology. +Implementation details: +-- +In order for this scheme to work, memory needs to be reserved +quite early in the boot cycle. However, access to the device +tree this early in the boot cycle is difficult, and device-tree +access is needed to determine if there is a crash data waiting. I don't think this bit about early device tree access is correct. By the time your code is reserving memory (from early_init_devtree(), I think), RTAS has been instantiated and you are able to test for the existence of /rtas/ibm,dump-kernel. If I remember right, it was still too early to look up this token directly, so we wrote some code to crawl the flat device tree to find it. But not only was that a lot of work, but I somehow decided that doing this to the flat tree was wrong, as otherwise someone would surely have written the access code. If this can be made to work, that would be great, but we couldn't make it work at the time. +To work around this problem, all but 256MB of RAM is reserved +during early boot. A short while later in boot, a check is made +to determine if there is dump data waiting. If there isn't, +then the reserved memory is released to general kernel use. So I think these gymnastics are unneeded -- unless I'm misunderstanding something, you should be able to determine very early whether to reserve that memory. Only if you can get at rtas, but you can't get at rtas at that point. Sorry, but I think you are mistaken (see Michael's earlier reply). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Help with device tree binding for SMC serial
Hi
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0100;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Trying 10/HALF
Hi, After booting, my MPC8641 based board keeps printing Trying 10/HALF for ever. I am unable to use the Ethernet, even though there are interrupts occuring. Based on /proc/interrupts, both tx and rx interrupt count is increasing, and zero count for enet_error interrupt. I think this is coming from drivers/net/phy/phy.c during autonegotiation. However, I am not sure how to take care of this. Appreciate some pointers. Thanks Siva ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
On Wed, 09 Jan 2008 14:26:56 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Josh Boyer wrote: On Wed, 09 Jan 2008 12:26:14 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Signed-off-by: Sean MacLennan [EMAIL PROTECTED] This one needs to go to the linux-usb list and David Brownell. Although I'm not sure what the benefit here really is. You can still set this in the defconfig without adding this patch... I don't see a need to do a default. Without the default, I was unable to select this option. I may have solved it the wrong way. It seems if there is no string after the tristate or boolean, you are not allowed to set the variable, it can only default. So with no default, I cannot enable this option and therefore cannot enable the ohci driver. Again, I think the default PCI case catches most boards and all PCI-less, or possibly PCI-less, boards need a default. Ah, possibly. Did you try doing a 'select USB_ARCH_HAS_OHCI' in the config 440EP section of arch/powerpc/platforms/44x/Kconfig? I'm just trying to save you some trouble. There's nothing actually wrong with your patch now, other than it has to be sent to the right maintainer. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
Kumar Gala wrote: On Jan 9, 2008, at 12:53 PM, Scott Wood wrote: It looks like if the reserved area straddles the highmem boundary, it'll only reserve the highmem portion. Yeah, I thought about that. I'm wondering if we should warn about this.. its seems like a bad thing to do. How is the firmware supposed to know where Linux sets its lowmem limit? I think this is something that needs to be handled. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Josh Boyer wrote: Ah, possibly. Did you try doing a 'select USB_ARCH_HAS_OHCI' in the config 440EP section of arch/powerpc/platforms/44x/Kconfig? I'm just trying to save you some trouble. There's nothing actually wrong with your patch now, other than it has to be sent to the right maintainer. josh That works. Thanks! Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] Warp Base Platform
I have split up the patches slightly differently based on Josh's comments.
The first patch is basically the platform/44x files.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool PIKA Warp
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the PIKA for Computer
+ Telephony Developers link for more information.
+
#config LUAN
# bool Luan
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..c1733c0 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.0 -0500
@@ -0,0 +1,239 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/init.h
+#include linux/of_platform.h
+#include linux/kthread.h
+
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+
+#include 44x.h
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = ibm,plb4, },
+ { .compatible = ibm,opb, },
+ { .compatible = ibm,ebc, },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if(!of_flat_dt_is_compatible(root, pika,warp))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = Warp,
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds = ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds = ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
[PATCH 2/5] Warp Base Platform - dts
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.0 -0500
@@ -0,0 +1,232 @@
+/*
+ * Device Tree Source for PIKA Warp
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = pika,warp;
+ compatible = pika,warp;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,440EP;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by zImage */
+ timebase-frequency = 0; /* Filled in by zImage */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440ep;
+ dcr-reg = 00e 002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440ep;
+ dcr-reg = 00c 002;
+ };
+
+ plb {
+ compatible = ibm,plb-440ep, ibm,plb-440gp, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-440ep, ibm,sdram-405gp;
+ dcr-reg = 010 2;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440ep, ibm,dma-440gp;
+ dcr-reg = 100 027;
+ };
+
+ FPGA0: fpga {
+ compatible = pika,fpga;
+ reg = 0 8000 2200;
+ interrupts = 18 8;
+ interrupt-parent = UIC0;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440ep, ibm,mcmal-440gp,
ibm,mcmal;
+ dcr-reg = 180 62;
+ num-tx-chans = 4;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0 1 2 3 4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0 UIC0 a 4
+ /*RXEOB*/ 1 UIC0 b 4
+ /*SERR*/ 2 UIC1 0 4
+ /*TXDE*/ 3 UIC1 1 4
+ /*RXDE*/ 4 UIC1 2 4;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-440ep, ibm,opb-440gp,
ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 8000
+ 8000 0 8000 8000;
+ interrupt-parent = UIC1;
+ interrupts = 7 4;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = ibm,ebc-440ep, ibm,ebc-440gp,
ibm,ebc;
+ dcr-reg = 012 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ clock-frequency = 0; /* Filled in by zImage */
+
[PATCH 4/5] Warp Base Platform - defconfig
Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- --- /dev/null 2005-11-20 22:22:37.0 -0500 +++ arch/powerpc/configs/warp_defconfig 2008-01-08 12:30:27.0 -0500 @@ -0,0 +1,1057 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc6 +# Tue Jan 8 12:23:23 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_4xx=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION=-pika +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_HOTPLUG is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory + +# +# Platform support +# +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_BAMBOO is not set +# CONFIG_EBONY is not set +# CONFIG_SEQUOIA is not set +# CONFIG_TAISHAN is not set +# CONFIG_KATMAI is not set +# CONFIG_RAINIER is not set +CONFIG_WARP=y +CONFIG_440EP=y +CONFIG_IBM440EP_ERR42=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_300 is not set +CONFIG_HZ_1000=y +CONFIG_HZ=1000 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +# CONFIG_MATH_EMULATION is not set +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is
[PATCH 5/5] Warp Base Platform - cputable
I think I sent this, but I will include it here for completeness.
It adds the 440EP Rev C to the cputable.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index f1928af..ece0c71 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1226,6 +1226,18 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = ppc440,
},
+ { /* Matches both physical and logical PVR for 440EP (logical pvr = pvr
| 0x8) */
+ .pvr_mask = 0xfff7,
+ .pvr_value = 0x48d4,
+ .cpu_name = 440EP Rev. C,
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440ep,
+ .machine_check = machine_check_4xx,
+ .platform = ppc440,
+ },
{ /* Use logical PVR for 440EP (logical pvr = pvr | 0x8) */
.pvr_mask = 0xffff,
.pvr_value = 0x48db,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/5] Warp Base Platform
Basically the powerpc/boot directory files.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/44x.h b/arch/powerpc/boot/44x.h
index 0256344..9db0213 100644
--- a/arch/powerpc/boot/44x.h
+++ b/arch/powerpc/boot/44x.h
@@ -12,5 +12,6 @@
void ebony_init(void *mac0, void *mac1);
void bamboo_init(void *mac0, void *mac1);
+void warp_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..df0ef6f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -56,13 +56,13 @@ src-wlib := string.S crt0.S stdio.c main.c \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c
+ fsl-soc.c mpc8xx.c pq2.c warp.c
src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-warp.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_WARP) += cuImage.warp
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.0 -0500
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 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 version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include 44x.h
+#include cuboot.h
+
+#define TARGET_44x
+#include ppcboot.h
+
+static bd_t bd;
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+
+ warp_init(bd.bi_enetaddr, bd.bi_enet1addr);
+}
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/warp.c2008-01-08 12:09:54.0 -0500
@@ -0,0 +1,33 @@
+/*
+ * Copyright (c) 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 Free Software Foundation; version 2 of the License
+ */
+#include ops.h
+#include 4xx.h
+#include 44x.h
+
+static u8 *warp_mac0, *warp_mac1;
+
+static void warp_fixups(void)
+{
+ unsigned long sysclk = 6600;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(warp_mac0, warp_mac1);
+}
+
+void warp_init(void *mac0, void *mac1)
+{
+ platform_ops.fixups = warp_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ warp_mac0 = mac0;
+ warp_mac1 = mac1;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
Kumar Gala wrote:
I'm thinking I'll add something like:
if (addr total_lowmem)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(lmb.reserved, i));
+ else if (lmb.reserved.region[i].base total_lowmem) {
less than, surely?
+ unsigned long adjusted_size;
+// adjusted_size = xxx;
need to figure out the math here.
Wouldn't it just be total_lowmem - lmb.reserved.region[i].base?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/4 v2] PS3: Add logical performance monitor repository routines
On Wed, 9 Jan 2008 11:01:38 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED]
wrote:
On Wed, 9 Jan 2008, Stephen Rothwell wrote:
On Tue, 08 Jan 2008 22:35:36 -0800 Geoff Levand [EMAIL PROTECTED] wrote:
+int ps3_repository_read_num_pu(unsigned int *num_pu)
+{
+ int result;
+ u64 v1;
+
+ v1 = 0;
+ result = read_node(PS3_LPAR_ID_CURRENT,
+make_first_field(bi, 0),
+make_field(pun, 0),
+0, 0,
+v1, NULL);
+ *num_pu = v1;
Why not just pass num_pu instead of v1 to read_node()?
We need a temporary because num_pu and v1 differ in size.
The alternative is to make num_pu u64.
Ooops, sorry. I read the second one first and didn't look hard enough
when I came back to this one.
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id)
+{
+ int result;
+ u64 v1;
+
+ v1 = 0;
+ result = read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field(bi, 0),
+ make_field(pu, pu_index),
+ 0, 0,
+ v1, NULL);
+ *pu_id = v1;
Similarly with pu_id?
Yep, here we don't need the temporary.
Which, of course means that the result temporary isn't needed either.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpJg5SLN9zwh.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Generic MMC-over-SPI binding?
On Wednesday 09 January 2008, Simon Richter wrote: The important part where this connects to the mmc-spi driver is that you need to set spi_board_info-modalias to mmc-spi, if the device node can be identified as an mmc card. Doing that now, using the code you provided as a base. The SPI child device gets registered, but it appears something is still missing as no messages I could attribute to mmc-spi appear. My suspicion would be that it doesn't like the monolithic kernel for some reason (the mmc-spi driver registers itself as a driver called mmc_spi, not sure if the modalias handling will catch that; still investigating there). Right, the modalias needs to be the same as the driver name, not the module name, so you should change it to mmc_spi as well. For loading the module it would not make a difference because - and _ are treated the same by the module loader, but the device only gets associated with the driver when it matches exactly. Then you call that function after registering the master, from mpc52xx_psc_spi_of_probe. I've changed mpc52xx_psc_spi_do_probe to have an additional argument for the OF device node of the SPI master; ARCH=ppc can call this with NULL as long as it still exists. Ok. keeping the code itself in the mpc52xx_psc_spi driver is fine as long as it's relatively small. Other of_platform_drivers for SPI will just have to it the same way. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood
Sent: Wednesday, January 09, 2008 1:46 PM
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried
to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 87fc 2;
The current binding has the actual parameter ram block as the
second reg
property, not the two-byte pointer. If your firmware doesn't
initialize
the pointer, you'll have to do it in platform code.
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0100;
};
cpm-command should be 1d00 for SMC1.
Otherwise, it looks OK.
Ok we're now using
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 0 40;// base_address length
parameter_ram_address length
interrupts = 4 8; // Interrupt from table 4.3
of mpc8280rm, interrupt is level or edge
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 1d00; // Page and Sub-block code
of the CPCR
};
Right now we're trying to just get a kernel to give us some serial
output, so we can continue the porting job.
We're unsig a cuImage (using the pq2fads code right now).
Now our problem is that the serial port is spitting out 0x0a's as fast
as it can.
Seems to be repeadtin the linefeed at the end of Uncompressing Kernel
Image ... OK
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote:
Ok we're now using
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 0 40;// base_address length
parameter_ram_address length
interrupts = 4 8; // Interrupt from table 4.3
of mpc8280rm, interrupt is level or edge
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 1d00; // Page and Sub-block code
of the CPCR
};
Looks good.
Right now we're trying to just get a kernel to give us some serial
output, so we can continue the porting job.
We're unsig a cuImage (using the pq2fads code right now).
Now our problem is that the serial port is spitting out 0x0a's as fast
as it can.
Don't forget to exclude the SMC parameter RAM from the muram data area
in /soc/cpm/muram/data/reg. If you have an older device tree binding
that has no /soc/cpm/muram node, but instead has two resources in
/soc/cpm/reg, you need to move to head-of-tree to get this to work.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood Don't forget to exclude the SMC parameter RAM from the muram data area in /soc/cpm/muram/data/reg. If you have an older device tree binding that has no /soc/cpm/muram node, but instead has two resources in /soc/cpm/reg, you need to move to head-of-tree to get this to work. Did that, now we get e checkstop resert. Time to hook up the BDI-2000 Is there a way to have the bootwrapper use the u-boot serial for a while (like a early srial port) for debugging? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote: From: Scott Wood Don't forget to exclude the SMC parameter RAM from the muram data area in /soc/cpm/muram/data/reg. If you have an older device tree binding that has no /soc/cpm/muram node, but instead has two resources in /soc/cpm/reg, you need to move to head-of-tree to get this to work. Did that, now we get e checkstop resert. Time to hook up the BDI-2000 Is there a way to have the bootwrapper use the u-boot serial for a while (like a early srial port) for debugging? If you mean calling into u-boot for a console, no, there's no code for that. What do your cpm and muram nodes look like? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood [mailto:[EMAIL PROTECTED]
Rune Torgersen wrote:
From: Scott Wood
Don't forget to exclude the SMC parameter RAM from the muram
data area
in /soc/cpm/muram/data/reg. If you have an older device
tree binding
that has no /soc/cpm/muram node, but instead has two resources in
/soc/cpm/reg, you need to move to head-of-tree to get this to work.
Did that, now we get e checkstop resert. Time to hook up the
BDI-2000
Is there a way to have the bootwrapper use the u-boot
serial for a while
(like a early srial port) for debugging?
If you mean calling into u-boot for a console, no, there's no
code for that.
What do your cpm and muram nodes look like?
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
#interrupt-cells = 2;
compatible = fsl,mpc8280-cpm, fsl,cpm2;
reg = 119c0 30;
ranges;
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
ranges = 0 0 1;
[EMAIL PROTECTED] {
compatible = fsl,cpm-muram-data;
reg = 100 1f00 9800 800;
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8280-brg,
fsl,cpm2-brg,
fsl,cpm-brg;
reg = 119f0 10 115f0 10;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 0 40;// base_address
length parameter_ram_address length
interrupts = 4 8; // Interrupt from
table 4.3 of mpc8280rm, interrupt is level or edge
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 1d00; // Page and
Sub-block code of the CPCR
};
};
and chosen node (not sure if needed)
chosen {
linux,stdout-path = /soc/cpm/[EMAIL PROTECTED];
bootargs = console=ttyS0,115200;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
It's in production with 256MB of RAM? Err. Sure as the dump progresses more RAM will be freed, but that's hardly production. I think Nathan's right, any sysadmin who wants predictability will probably double reboot anyway. Thats a changeable parameter. Its something we chose for now. It by no means is set in stone. Its not a design parameter. If you like to allocate 1GB we can. But that is something we did for now. we expect this to be a variable value dependent upon the size of the system. So if you have 128 GB system and you can spare 10 gb, you should be able to have 10 GB to boot with. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] Add support for Freescale QUICCEngine UART
This patchset creates a new serial device driver for the Freescale QE. Part 1 of this patch set contains all the PowerPC-specific changes. Part 2 contains all the actual driver and changes for Kconfig and Makefile. The PowerPC portions of this patchset have already been reviewed and approved. I'd like someone from linux-serial to review the actual driver itself. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
Add file ucc_uart.c, a serial device driver for the Freescale QUICCEngine.
Update the Kconfig and Makefile accordingly.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
drivers/serial/Kconfig| 10 +
drivers/serial/Makefile |1 +
drivers/serial/ucc_uart.c | 1507 +
3 files changed, 1518 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/ucc_uart.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index d7e1996..d962b74 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1284,4 +1284,14 @@ config SERIAL_OF_PLATFORM
Currently, only 8250 compatible ports are supported, but
others can easily be added.
+config SERIAL_QE
+ tristate Freescale QUICC Engine serial port support
+ depends on QUICC_ENGINE
+ select SERIAL_CORE
+ select FW_LOADER
+ default n
+ help
+ This driver supports the QE serial ports on Freescale embedded
+ PowerPC that contain a QUICC Engine.
+
endmenu
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index af6377d..7eb4553 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
+obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
new file mode 100644
index 000..6fe4cfc
--- /dev/null
+++ b/drivers/serial/ucc_uart.c
@@ -0,0 +1,1507 @@
+/*
+ * Freescale QUICC Engine UART device driver
+ *
+ * Author: Timur Tabi [EMAIL PROTECTED]
+ *
+ * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ *
+ * This driver adds support for UART devices via Freescale's QUICC Engine
+ * found on some Freescale SOCs.
+ *
+ * If Soft-UART support is needed but not already present, then this driver
+ * will request and upload the Soft-UART microcode upon probe. The
+ * filename of the microcode should be fsl_qe_ucode_uart_X_YZ.bin, where X
+ * is the name of the SOC (e.g. 8323), and YZ is the revision of the SOC,
+ * (e.g. 11 for 1.1).
+ */
+
+#include linux/module.h
+#include linux/serial.h
+#include linux/serial_core.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include linux/fs_uart_pd.h
+#include asm/ucc_slow.h
+
+#include linux/firmware.h
+#include asm/reg.h
+
+/*
+ * The GUMR flag for Soft UART. This would normally be defined in qe.h,
+ * but Soft-UART is a hack and we want to keep everything related to it in
+ * this file.
+ */
+#define UCC_SLOW_GUMR_H_SUART 0x4000 /* Soft-UART */
+
+/*
+ * soft_uart is 1 if we need to use Soft-UART mode
+ */
+static int soft_uart;
+/*
+ * firmware_loaded is 1 if the firmware has been loaded, 0 otherwise.
+ */
+static int firmware_loaded;
+
+/* Enable this macro to configure all serial ports in internal loopback
+ mode */
+/* #define LOOPBACK */
+
+/* The major and minor device numbers are defined in
+ * http://www.lanana.org/docs/device-list/devices-2.6+.txt. For the QE
+ * UART, we have major number 204 and minor numbers 46 - 49, which are the
+ * same as for the CPM2. This decision was made because no Freescale part
+ * has both a CPM and a QE.
+ */
+#define SERIAL_QE_MAJOR 204
+#define SERIAL_QE_MINOR 46
+
+/* Since we only have minor numbers 46 - 49, there is a hard limit of 4 ports
*/
+#define UCC_MAX_UART4
+
+/* The number of buffer descriptors for receiving characters. */
+#define RX_NUM_FIFO 4
+
+/* The number of buffer descriptors for transmitting characters. */
+#define TX_NUM_FIFO 4
+
+/* The maximum size of the character buffer for a single RX BD. */
+#define RX_BUF_SIZE 32
+
+/* The maximum size of the character buffer for a single TX BD. */
+#define TX_BUF_SIZE 32
+
+#define UCC_WAIT_CLOSING 100
+
+struct ucc_uart_pram {
+ struct ucc_slow_pram common;
+ u8 res1[8]; /* reserved */
+ __be16 maxidl; /* Maximum idle chars */
+ __be16 idlc;/* temp idle counter */
+ __be16 brkcr; /* Break count register */
+ __be16 parec; /* receive parity error counter */
+ __be16 frmec; /* receive framing error counter */
+ __be16 nosec; /* receive noise counter */
+ __be16 brkec; /* receive break condition counter */
+ __be16 brkln; /* last received break length */
+ __be16 uaddr[2];/* UART address character 1 2 */
+ __be16 rtemp; /* Temp storage */
+ __be16 toseq; /* Transmit out of sequence char */
+ __be16 cchars[8]; /* control characters 1-8 */
+
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, 2008-01-09 at 12:44 -0600, Nathan Lynch wrote: Hi Linas, Linas Vepstas wrote: On 08/01/2008, Nathan Lynch [EMAIL PROTECTED] wrote: Manish Ahuja wrote: + +The goal of hypervisor-assisted dump is to enable the dump of +a crashed system, and to do so from a fully-reset system, and +to minimize the total elapsed time until the system is back +in production use. Is it actually faster than kdump? This is a basic presumption; As a side effect, the system is in production *while* the dump is being taken; It's in production with 256MB of RAM? Err. Sure as the dump progresses more RAM will be freed, but that's hardly production. I think Nathan's right, any sysadmin who wants predictability will probably double reboot anyway. with kdump, you can't go into production until after the dump is finished, and the system has been rebooted a second time. On systems with terabytes of RAM, the time difference can be hours. Since you bring up large systems... a system with terabytes of RAM is practically guaranteed to be a NUMA configuration with dozens of cpus. When processing a dump on such a system, I wonder how well we fare: can we successfully boot with (say) 128 cpus and 256MB of usable memory? Do we have to hot-online nodes as system memory is freed up (and does that even work)? We need to be able to restore the system to its optimal topology when the dump is finished; if the best we can do is a degraded configuration, the workload will suffer and the system admin is likely to just reboot the machine again so the kernel will have the right NUMA topology. Yeah that's a good question. Even if the hot-onlining works, there's still kernel data structures allocated at boot which want to be node-local. So the end result will be != a production boot. +Implementation details: +-- +In order for this scheme to work, memory needs to be reserved +quite early in the boot cycle. However, access to the device +tree this early in the boot cycle is difficult, and device-tree +access is needed to determine if there is a crash data waiting. I don't think this bit about early device tree access is correct. By the time your code is reserving memory (from early_init_devtree(), I think), RTAS has been instantiated and you are able to test for the existence of /rtas/ibm,dump-kernel. If I remember right, it was still too early to look up this token directly, so we wrote some code to crawl the flat device tree to find it. But not only was that a lot of work, but I somehow decided that doing this to the flat tree was wrong, as otherwise someone would surely have written the access code. If this can be made to work, that would be great, but we couldn't make it work at the time. +To work around this problem, all but 256MB of RAM is reserved +during early boot. A short while later in boot, a check is made +to determine if there is dump data waiting. If there isn't, +then the reserved memory is released to general kernel use. So I think these gymnastics are unneeded -- unless I'm misunderstanding something, you should be able to determine very early whether to reserve that memory. Only if you can get at rtas, but you can't get at rtas at that point. AFAICT you don't need to get at RTAS, you just need to look at the device tree to see if the property is present, and that is trivial. You probably just need to add a check in early_init_dt_scan_rtas() which sets a flag for the PHYP dump stuff, or add your own scan routine if you need. 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
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
Hi Anton,
Juts one small trivial comment (could be fixed later).
On Wed, 9 Jan 2008 22:10:41 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+static struct of_device_id pata_of_platform_match[] = {
This could be declared const.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpiwdpCxZY1X.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Thu, Jan 10, 2008 at 10:40:48AM +1100, Stephen Rothwell wrote:
Hi Anton,
Juts one small trivial comment (could be fixed later).
On Wed, 9 Jan 2008 22:10:41 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+static struct of_device_id pata_of_platform_match[] = {
This could be declared const.
Good point, but let's not hold up merge based on this. Need something
for janitors to do too, and it's good enough to merge as-is. :)
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] add default device trees for MPC837x MDS board
On Tue, Jan 08, 2008 at 08:58:17AM -0700, Grant Likely wrote:
Hi Leo,
comments below. I've made my comments on the first file, but they
apply to the other two also.
Cheers,
g.
[snip]
+ ranges = 0 e000 0010;
+ reg = e000 0200;
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = mpc83xx_wdt;
fsl,mpc8377_wdt, fsl,mpc83xx_wdt as per generic names recommended
practice.
Uh.. that's reasonable advice, but it has nothing to do with the
generic names recommended practice.
--
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
Re: [PATCH] Fix remainder calculating bug in single floating point division
On Wed, Jan 09, 2008 at 09:24:07AM +0800, Liu Yu wrote: can you provide the test case that shows the error. It seems that math-emu only be used for MPC8xx on current kernel. It can be used for IBM/AMCC 4xx too. -- 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
Re: [PATCH 1/3] add default device trees for MPC837x MDS board
On 1/9/08, David Gibson [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 08:58:17AM -0700, Grant Likely wrote: + compatible = mpc83xx_wdt; fsl,mpc8377_wdt, fsl,mpc83xx_wdt as per generic names recommended practice. Uh.. that's reasonable advice, but it has nothing to do with the generic names recommended practice. Actually, that *is* advice given in the generic names recommended practice document: http://www.openfirmware.org/1275/practice/gnames/gnamv14a.html#HDR11 Section 6.2, last sentence. :-) Cheers, g. -- 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
[patch 2/4 v3] PS3: Add logical performance monitor repository routines
From: Takashi Yamamoto [EMAIL PROTECTED]
Add repository routines for the PS3 logical performance monitor.
Signed-off-by: Takashi Yamamoto [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
v2: o Correct Yamamoto-san's mail addr.
v3: o Change num_pu and pu_id to type u64.
o Add comments to describe some symbol names.
arch/powerpc/platforms/ps3/platform.h | 12 +++--
arch/powerpc/platforms/ps3/repository.c | 75 +++-
2 files changed, 83 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -186,10 +186,10 @@ int ps3_repository_read_stor_dev_region(
unsigned int dev_index, unsigned int region_index,
unsigned int *region_id, u64 *region_start, u64 *region_size);
-/* repository pu and memory info */
+/* repository logical pu and memory info */
-int ps3_repository_read_num_pu(unsigned int *num_pu);
-int ps3_repository_read_ppe_id(unsigned int *pu_index, unsigned int *ppe_id);
+int ps3_repository_read_num_pu(u64 *num_pu);
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id);
int ps3_repository_read_rm_base(unsigned int ppe_id, u64 *rm_base);
int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size);
int ps3_repository_read_region_total(u64 *region_total);
@@ -200,9 +200,15 @@ int ps3_repository_read_mm_info(u64 *rm_
int ps3_repository_read_num_be(unsigned int *num_be);
int ps3_repository_read_be_node_id(unsigned int be_index, u64 *node_id);
+int ps3_repository_read_be_id(u64 node_id, u64 *be_id);
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq);
int ps3_repository_read_be_tb_freq(unsigned int be_index, u64 *tb_freq);
+/* repository performance monitor info */
+
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights);
+
/* repository 'Other OS' area */
int ps3_repository_read_boot_dat_addr(u64 *lpar_addr);
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -684,6 +684,35 @@ int ps3_repository_read_stor_dev_region(
return result;
}
+/**
+ * ps3_repository_read_num_pu - Number of logical PU processors for this lpar.
+ */
+
+int ps3_repository_read_num_pu(u64 *num_pu)
+{
+ *num_pu = 0;
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field(bi, 0),
+ make_field(pun, 0),
+ 0, 0,
+ num_pu, NULL);
+}
+
+/**
+ * ps3_repository_read_pu_id - Read the logical PU id.
+ * @pu_index: Zero based index.
+ * @pu_id: The logical PU id.
+ */
+
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id)
+{
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field(bi, 0),
+ make_field(pu, pu_index),
+ 0, 0,
+ pu_id, NULL);
+}
+
int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size)
{
return read_node(PS3_LPAR_ID_CURRENT,
@@ -856,6 +885,10 @@ int ps3_repository_read_boot_dat_info(u6
: ps3_repository_read_boot_dat_size(size);
}
+/**
+ * ps3_repository_read_num_be - Number of physical BE processors in the system.
+ */
+
int ps3_repository_read_num_be(unsigned int *num_be)
{
int result;
@@ -871,6 +904,12 @@ int ps3_repository_read_num_be(unsigned
return result;
}
+/**
+ * ps3_repository_read_be_node_id - Read the physical BE processor node id.
+ * @be_index: Zero based index.
+ * @node_id: The BE processor node id.
+ */
+
int ps3_repository_read_be_node_id(unsigned int be_index, u64 *node_id)
{
return read_node(PS3_LPAR_ID_PME,
@@ -881,6 +920,22 @@ int ps3_repository_read_be_node_id(unsig
node_id, 0);
}
+/**
+ * ps3_repository_read_be_id - Read the physical BE processor id.
+ * @node_id: The BE processor node id.
+ * @be_id: The BE processor id.
+ */
+
+int ps3_repository_read_be_id(u64 node_id, u64 *be_id)
+{
+ return read_node(PS3_LPAR_ID_PME,
+ make_first_field(be, 0),
+ node_id,
+ 0,
+ 0,
+ be_id, NULL);
+}
+
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq)
{
return read_node(PS3_LPAR_ID_PME,
@@ -897,11 +952,29 @@ int ps3_repository_read_be_tb_freq(unsig
u64 node_id;
*tb_freq = 0;
- result = ps3_repository_read_be_node_id(0, node_id);
+ result = ps3_repository_read_be_node_id(be_index, node_id);
return result ? result
: ps3_repository_read_tb_freq(node_id, tb_freq);
}
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights)
+{
+ int result;
+ u64 node_id;
+
+ *lpar = 0;
+ *rights = 0;
+ result = ps3_repository_read_be_node_id(be_index, node_id);
+ return result ? result
+ : read_node(PS3_LPAR_ID_PME,
+
[patch 3/4 v3] PS3: Add logical performance monitor device support
Add PS3 logical performance monitor device support to the
PS3 system-bus and platform device registration routines.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
v2: o Add enum ps3_lpm_tb_type.
o Remove redundant enclosing structure and return proper
error codes from ps3_register_lpm_devices().
v3: o Add lpm.node_id to struct ps3_system_bus_device.
o Cleanup repository discovery logic.
arch/powerpc/platforms/ps3/device-init.c | 85 +++
arch/powerpc/platforms/ps3/system-bus.c |5 +
include/asm-powerpc/ps3.h|8 ++
3 files changed, 98 insertions(+)
create mode 100644 arch/powerpc/platforms/ps3/lpm.c
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -30,6 +30,89 @@
#include platform.h
+static int __init ps3_register_lpm_devices(void)
+{
+ int result;
+ u64 tmp1;
+ u64 tmp2;
+ struct ps3_system_bus_device *dev;
+
+ pr_debug( - %s:%d\n, __func__, __LINE__);
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ dev-match_id = PS3_MATCH_ID_LPM;
+ dev-dev_type = PS3_DEVICE_TYPE_LPM;
+
+ /* The current lpm driver only supports a single BE processor. */
+
+ result = ps3_repository_read_be_node_id(0, dev-lpm.node_id);
+
+ if (result) {
+ pr_debug(%s:%d: ps3_repository_read_be_node_id failed \n,
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ result = ps3_repository_read_lpm_privileges(dev-lpm.node_id, tmp1,
+ dev-lpm.rights);
+
+ if (result) {
+ pr_debug(%s:%d: ps3_repository_read_lpm_privleges failed \n,
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ lv1_get_logical_partition_id(tmp2);
+
+ if (tmp1 != tmp2) {
+ pr_debug(%s:%d: wrong lpar\n,
+ __func__, __LINE__);
+ result = -ENODEV;
+ goto fail_rights;
+ }
+
+ if (!(dev-lpm.rights PS3_LPM_RIGHTS_USE_LPM)) {
+ pr_debug(%s:%d: don't have rights to use lpm\n,
+ __func__, __LINE__);
+ result = -EPERM;
+ goto fail_rights;
+ }
+
+ pr_debug(%s:%d: pu_id %lu, rights %lu(%lxh)\n,
+ __func__, __LINE__, dev-lpm.pu_id, dev-lpm.rights,
+ dev-lpm.rights);
+
+ result = ps3_repository_read_pu_id(0, dev-lpm.pu_id);
+
+ if (result) {
+ pr_debug(%s:%d: ps3_repository_read_pu_id failed \n,
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ result = ps3_system_bus_device_register(dev);
+
+ if (result) {
+ pr_debug(%s:%d ps3_system_bus_device_register failed\n,
+ __func__, __LINE__);
+ goto fail_register;
+ }
+
+ pr_debug( - %s:%d\n, __func__, __LINE__);
+ return 0;
+
+
+fail_register:
+fail_rights:
+fail_read_repo:
+ kfree(dev);
+ pr_debug( - %s:%d: failed\n, __func__, __LINE__);
+ return result;
+}
+
/**
* ps3_setup_gelic_device - Setup and register a gelic device instance.
*
@@ -787,6 +870,8 @@ static int __init ps3_register_devices(v
ps3_register_sound_devices();
+ ps3_register_lpm_devices();
+
pr_debug( - %s:%d\n, __func__, __LINE__);
return 0;
}
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -715,6 +715,7 @@ int ps3_system_bus_device_register(struc
static unsigned int dev_ioc0_count;
static unsigned int dev_sb_count;
static unsigned int dev_vuart_count;
+ static unsigned int dev_lpm_count;
if (!dev-core.parent)
dev-core.parent = ps3_system_bus;
@@ -737,6 +738,10 @@ int ps3_system_bus_device_register(struc
snprintf(dev-core.bus_id, sizeof(dev-core.bus_id),
vuart_%02x, ++dev_vuart_count);
break;
+ case PS3_DEVICE_TYPE_LPM:
+ snprintf(dev-core.bus_id, sizeof(dev-core.bus_id),
+ lpm_%02x, ++dev_lpm_count);
+ break;
default:
BUG();
};
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -317,6 +317,7 @@ enum ps3_match_id {
PS3_MATCH_ID_STOR_FLASH = 8,
PS3_MATCH_ID_SOUND = 9,
PS3_MATCH_ID_GRAPHICS = 10,
+ PS3_MATCH_ID_LPM= 11,
};
#define PS3_MODULE_ALIAS_EHCI ps3:1
@@ -329,11 +330,13 @@ enum ps3_match_id {
#define PS3_MODULE_ALIAS_STOR_FLASH ps3:8
#define PS3_MODULE_ALIAS_SOUND ps3:9
#define PS3_MODULE_ALIAS_GRAPHICS ps3:10
+#define PS3_MODULE_ALIAS_LPMps3:11
enum ps3_system_bus_device_type {
PS3_DEVICE_TYPE_IOC0 = 1,
[patch 4/4 v3] PS3: Add logical performance monitor driver support
From: Takashi Yamamoto [EMAIL PROTECTED] Add PS3 logical performance monitor (lpm) device driver. The PS3's LV1 hypervisor provides a Logical Performance Monitor that abstracts the Cell processor's performance monitor features for use by guest operating systems. Signed-off-by: Takashi Yamamoto [EMAIL PROTECTED] Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- v2: o Correct Yamamoto-san's mail addr. o Text cleanups. o Added more comments explaining lpm operation. o Split SRPN_BKMK into separate patch. o Use get_hard_smp_processor_id() in ps3_get_hw_thread_id(). o Split ps3_copy_trace_buffer() into ps3_lpm_copy_tb() and ps3_lpm_copy_tb_to_user(). o Replace mutex with atomic_t in ps3_lpm_open()/ps3_lpm_close(). o General cleanup of ps3_lpm_open()/ps3_lpm_close(). v3: o Add BE node_id to struct lpm_priv. o Change some dev_err() to dev_dbg(). o Fix kzalloc() bug. o Text fix 'lost' - 'loss'. o Use lpm_priv-node_id with lv1_construct_lpm(). arch/powerpc/platforms/ps3/Kconfig | 13 drivers/ps3/Makefile |1 drivers/ps3/ps3-lpm.c | 1248 + include/asm-powerpc/ps3.h | 62 + 4 files changed, 1324 insertions(+) create mode 100644 arch/powerpc/platforms/ps3/ps3-lpm.c --- a/arch/powerpc/platforms/ps3/Kconfig +++ b/arch/powerpc/platforms/ps3/Kconfig @@ -138,4 +138,17 @@ config PS3_FLASH be disabled on the kernel command line using ps3flash=off, to not allocate this fixed buffer. +config PS3_LPM + tristate PS3 Logical Performance Monitor support + depends on PPC_PS3 + help + Include support for the PS3 Logical Performance Monitor. + + This support is required to use the logical performance monitor + of the PS3's LV1 hypervisor. + + If you intend to use the advanced performance monitoring and + profiling support of the Cell processor with programs like + oprofile and perfmon2, then say Y or M, otherwise say N. + endmenu --- a/drivers/ps3/Makefile +++ b/drivers/ps3/Makefile @@ -4,3 +4,4 @@ ps3av_mod-objs += ps3av.o ps3av_cmd.o obj-$(CONFIG_PPC_PS3) += sys-manager-core.o obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o +obj-$(CONFIG_PS3_LPM) += ps3-lpm.o --- /dev/null +++ b/drivers/ps3/ps3-lpm.c @@ -0,0 +1,1248 @@ +/* + * PS3 Logical Performance Monitor. + * + * Copyright (C) 2007 Sony Computer Entertainment Inc. + * Copyright 2007 Sony Corp. + * + * 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; version 2 of the License. + * + * 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 + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/uaccess.h +#include asm/ps3.h +#include asm/lv1call.h +#include asm/cell-pmu.h + + +/* BOOKMARK tag macros */ +#define PS3_PM_BOOKMARK_START0x8000ULL +#define PS3_PM_BOOKMARK_STOP 0x4000ULL +#define PS3_PM_BOOKMARK_TAG_KERNEL 0x1000ULL +#define PS3_PM_BOOKMARK_TAG_USER 0x3000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_HI 0xF000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_LO 0x0F00ULL + +/* CBE PM CONTROL register macros */ +#define PS3_PM_CONTROL_PPU_TH0_BOOKMARK 0x1000 +#define PS3_PM_CONTROL_PPU_TH1_BOOKMARK 0x0800 +#define PS3_PM_CONTROL_PPU_COUNT_MODE_MASK 0x000C +#define PS3_PM_CONTROL_PPU_COUNT_MODE_PROBLEM0x0008 +#define PS3_WRITE_PM_MASK0xULL + +/* CBE PM START STOP register macros */ +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_START 0x0200 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_START 0x0100 +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_STOP 0x0002 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_STOP 0x0001 +#define PS3_PM_START_STOP_START_MASK 0xFF00 +#define PS3_PM_START_STOP_STOP_MASK 0x00FF + +/* CBE PM COUNTER register macres */ +#define PS3_PM_COUNTER_MASK_HI 0xULL +#define PS3_PM_COUNTER_MASK_LO 0xULL + +/* BASE SIGNAL GROUP NUMBER macros */ +#define PM_ISLAND2_BASE_SIGNAL_GROUP_NUMBER 0 +#define PM_ISLAND2_SIGNAL_GROUP_NUMBER1 6 +#define
Re: [PATCH 2/3] sbc834x: Add device tree source for Wind River SBC834x board.
On Wed, Jan 09, 2008 at 12:49:31AM -0500, Paul Gortmaker wrote:
This adds the device tree source for the Wind River SBC834x board.
It is based on the MPC834x_MDS DTS, with the biggest difference being
the lack of BCSR and the PCI2 that the MDS gets via the PIB. That,
and this file is also dts-v1 format.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/sbc8349.dts | 247
+
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8349.dts
b/arch/powerpc/boot/dts/sbc8349.dts
[snip]
+ [EMAIL PROTECTED] {
+ device_type = watchdog;
+ compatible = mpc83xx_wdt;
Grah! Hasn't someone fixed this so that the driver doesn't need the
crap device_type?
[snip]
+ [EMAIL PROTECTED] {
+ device_type = spi;
+ compatible = fsl_spi;
And again here.
[snip]
+ [EMAIL PROTECTED] {
+ device_type = usb;
+ compatible = fsl-usb2-mph;
And here.
[snip
+ /* May need to remove if on a part without crypto engine */
+ [EMAIL PROTECTED] {
+ device_type = crypto;
+ model = SEC2;
+ compatible = talitos;
I'm almost certain this one was fixed, hasn't it been merged yet?
[snip]
+ ipic: [EMAIL PROTECTED] {
By generic names best practice this should be
[EMAIL PROTECTED], although that's probably not your error.
--
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
