* Re: [patch 4/4 v2] PS3: Add logical performance monitor driver support
From: Geert Uytterhoeven @ 2008-01-09 10:41 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus, Takashi Yamamoto
In-Reply-To: <47846B48.5000003@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1003 bytes --]
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: Geert.Uytterhoeven@sonycom.com
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
^ permalink raw reply
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Sergej Stepanov @ 2008-01-09 10:46 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080108190555.GA23302@localhost.localdomain>
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 0x0000014c
> Faulting instruction address: 0xc016f7f0
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC85xx
> NIP: c016f7f0 LR: c01722a0 CTR: 00000000
> REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b)
> MSR: 00029000 <EE,ME> CR: 20004428 XER: 20000000
> DEAR: 0000014c, ESR: 00000000
> TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000
> GPR00: c01aceb8 c79ddd20 c789f5e0 00000000 c79ddd3c 00000000 c79ddd64 00000000
> GPR08: 00000000 c7845b60 c79dde3c c01ace80 20004422 200249fc 000002a0 100da728
> GPR16: 100c0000 00000000 00000000 00000000 20022078 00000009 200220e0 bfc85558
> GPR24: c79ddd3c 00000000 00000000 c02e0e70 c022fc64 ffffffff 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:
> 81630000 800b0030 2f800000 419e0010 7c0803a6 4e800021 7c691b78 80010014
> 7d234b78 38210010 7c0803a6 4e800020 <8003014c> 7c6b1b78 38600000 90040004
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
> 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.
^ permalink raw reply related
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Matthias Fuchs @ 2008-01-09 11:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080108100937.0cfca4cf@zod.rchland.ibm.com>
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 <hollisb@us.ibm.com> wrote:
>
> > Enable EMAC driver for Sequoia (and while we're in there, disable
> > Macintosh drivers for Sequoia and Bamboo).
> >
> > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
>
> applied, thanks.
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH 1/7] [POWERPC] Xilinx: Uartlite: Make console output actually work.
From: Peter Korsgaard @ 2008-01-09 11:20 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20080108193520.402F7F68051@mail132-sin.bigfish.com>
>>>>> "Stephen" == Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> writes:
> From: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> 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 <stephen.neuendorffer@xilinx.com>
> ---
> 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;
> + }
> - /* Do we have a device now? */
> - if (!port->mapbase) {
> - pr_debug("console on ttyUL%i not present\n", co->index);
> + if (!port->mapbase)
> return -ENODEV;
> - }
> - /* not initialized yet? */
> + /* registers mapped yet? */
> if (!port->membase) {
> - if (ulite_request_port(port))
> + port->membase = ioremap(port->mapbase, ULITE_REGION);
> + if (!port->membase)
> return -ENODEV;
Why not use request_port?
> }
> @@ -488,39 +542,22 @@ static int __devinit ulite_assign(struct device *dev, int id, u32 base, int irq)
> struct uart_port *port;
> int rc;
> - /* 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) {
> - dev_err(dev, "%s%i too large\n", ULITE_NAME, id);
> - return -EINVAL;
> + port = ulite_get_port(id);
> + if (!port) {
> + dev_err(dev, "Cannot get uart_port structure\n");
ulite_get_port can only fail in the invalid id case, where a suitable
error message has already been printed. This doesn't really add
anything.
> + return -ENODEV;
Why change the error code?
> }
> - if ((ulite_ports[id].mapbase) && (ulite_ports[id].mapbase != base)) {
> - dev_err(dev, "cannot assign to %s%i; it is already in use\n",
> - ULITE_NAME, id);
> - return -EBUSY;
> + /* was it initialized for this device? */
> + if ((port->mapbase) && (port->mapbase != base)) {
> + pr_debug(KERN_DEBUG "ulite: addr mismatch; %x != %x\n",
> + port->mapbase, base);
> + return -ENODEV;
Why change the error message? I found the old better. Also use
dev_err istead of pr_debug.
You again changed the error code.
> }
> - port = &ulite_ports[id];
> -
> - spin_lock_init(&port->lock);
> - port->fifosize = 16;
> - port->regshift = 2;
> - port->iotype = UPIO_MEM;
> - port->iobase = 1; /* mark port in use */
port-> mapbase = base;
> - port->membase = NULL;
> - port->ops = &ulite_ops;
port-> irq = irq;
> - port->flags = UPF_BOOT_AUTOCONF;
port-> dev = dev;
> - port->type = PORT_UNKNOWN;
> - port->line = id;
> -
> dev_set_drvdata(dev, port);
> /* Register the port */
> --
> 1.5.3.4-dirty
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Uartlite: Section type fixups
From: Peter Korsgaard @ 2008-01-09 11:24 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20080108193519.5282318F8069@mail8-blu.bigfish.com>
>>>>> "Stephen" == Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> writes:
Stephen> All the __devexit functions are now appropriately tagged. This fixes
Stephen> some ppc link warnings.
You forgot to add __devexit_p(ulite_remove) in ulite_platform_driver,
otherwise:
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Stephen> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Stephen> ---
Stephen> drivers/serial/uartlite.c | 4 ++--
Stephen> 1 files changed, 2 insertions(+), 2 deletions(-)
Stephen> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
Stephen> index 02c2d89..ecd5540 100644
Stephen> --- a/drivers/serial/uartlite.c
Stephen> +++ b/drivers/serial/uartlite.c
Stephen> @@ -594,7 +594,7 @@ static int __devinit ulite_assign(struct device *dev, int id, u32 base, int irq)
Stephen> *
Stephen> * @dev: pointer to device structure
Stephen> */
Stephen> -static int __devinit ulite_release(struct device *dev)
Stephen> +static int __devexit ulite_release(struct device *dev)
Stephen> {
Stephen> struct uart_port *port = dev_get_drvdata(dev);
Stephen> int rc = 0;
Stephen> @@ -627,7 +627,7 @@ static int __devinit ulite_probe(struct platform_device *pdev)
Stephen> return ulite_assign(&pdev->dev, pdev->id, res->start, res2->start);
Stephen> }
Stephen> -static int ulite_remove(struct platform_device *pdev)
Stephen> +static int __devexit ulite_remove(struct platform_device *pdev)
Stephen> {
Stephen> return ulite_release(&pdev->dev);
Stephen> }
Stephen> --
Stephen> 1.5.3.4-dirty
Stephen> _______________________________________________
Stephen> Linuxppc-dev mailing list
Stephen> Linuxppc-dev@ozlabs.org
Stephen> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch 1/4] POWERPC: Add Cell SPRN bookmark register
From: Arnd Bergmann @ 2008-01-09 11:55 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <47846B30.5040406@am.sony.com>
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 <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Josh Boyer @ 2008-01-09 12:07 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200801091216.25581.matthias.fuchs@esd-electronics.com>
On Wed, 9 Jan 2008 12:16:25 +0100
Matthias Fuchs <matthias.fuchs@esd-electronics.com> 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.
josh
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Josh Boyer @ 2008-01-09 12:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801082207h24c9b262i55b9756c3c435d7c@mail.gmail.com>
On Tue, 8 Jan 2008 23:07:51 -0700
"Grant Likely" <grant.likely@secretlab.ca> 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
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Peter Korsgaard @ 2008-01-09 12:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080109063512.1226b979@zod.rchland.ibm.com>
>>>>> "Josh" == Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
Josh> On Tue, 8 Jan 2008 23:07:51 -0700
Josh> "Grant Likely" <grant.likely@secretlab.ca> 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
^ permalink raw reply
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Heiko Schocher @ 2008-01-09 12:58 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <1199875566.3408.11.camel@p60365-ste>
Hello Sergej,
Wed Jan 9 21:46:06 EST 2008 Sergej Stepanov Sergej.Stepanov@ids.de 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 <hs@denx.de>
Date: Mon, 7 Jan 2008 09:42:09 +0100
Subject: [PATCH] [POWERPC] Fix Ethernet over SCC on a CPM2
Signed-off-by: Heiko Schocher <hs@denx.de>
---
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
^ permalink raw reply related
* RE: [patch 4/4 v2] PS3: Add logical performance monitor driver support
From: TakashiYamamoto @ 2008-01-09 13:20 UTC (permalink / raw)
To: 'Geoff Levand', paulus; +Cc: linuxppc-dev
In-Reply-To: <47846B48.5000003@am.sony.com>
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.
^ permalink raw reply
* Re: printk() does not work on UART1
From: Haiying Wang @ 2008-01-09 14:14 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev
In-Reply-To: <5c9cd53b0801082106p7b57e11ejc809c182a26599d5@mail.gmail.com>
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
^ permalink raw reply
* add phy-handle property for fec_mpc52xx
From: Olaf Hering @ 2008-01-09 14:06 UTC (permalink / raw)
To: linuxppc-dev
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"
+ " ihandle>phandle"
+ " 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"));
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 14:44 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080109140608.GA15673@aepfle.de>
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 <olaf@aepfle.de> 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"
> + " ihandle>phandle"
> + " 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.
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Matthias Fuchs @ 2008-01-09 14:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080109060723.06885abd@zod.rchland.ibm.com>
On Wednesday 09 January 2008 13:07, Josh Boyer wrote:
> On Wed, 9 Jan 2008 12:16:25 +0100
> Matthias Fuchs <matthias.fuchs@esd-electronics.com> 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
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 14:50 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109144910.GA4222@powerlinux.fr>
On 1/9/08, Sven Luther <sven@powerlinux.fr> 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.
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 14:58 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <fa686aa40801090650l38bea6a0l7a1ea2d81667f42e@mail.gmail.com>
On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote:
> On 1/9/08, Sven Luther <sven@powerlinux.fr> 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
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Grant Likely @ 2008-01-09 15:03 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87ir23tbgz.fsf@macbook.be.48ers.dk>
On 1/9/08, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Josh" == Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
>
> Josh> On Tue, 8 Jan 2008 23:07:51 -0700
> Josh> "Grant Likely" <grant.likely@secretlab.ca> 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.
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 15:10 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080109140608.GA15673@aepfle.de>
On 1/9/08, Olaf Hering <olaf@aepfle.de> 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.
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Stefan Roese @ 2008-01-09 15:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Hollis Blanchard
In-Reply-To: <200801091542.38914.matthias.fuchs@esd-electronics.com>
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=3Dy
> +CONFIG_IBM_NEW_EMAC_RXB=3D128
> +CONFIG_IBM_NEW_EMAC_TXB=3D64
> +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=3D32
> +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=3D256
> +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=3D0
>
> I did not find any Kconfigs where these might come from.
Take a look at drivers/net/ibm_newemac/Kconfig.
Viele Gr=FC=DFe,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 14:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <fa686aa40801090644q5d1aa117ka7e8f5aed34237bd@mail.gmail.com>
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
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 15:21 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109144910.GA4222@powerlinux.fr>
NO.
--
Matt Sealey <matt@genesi-usa.com>
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
^ permalink raw reply
* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-09 15:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi
First I want to thank you for you fast and useful answer last time.
I decided to use the kernel 2.6 for my ml310 now.
I downloaded this Kernel:
http://git.secretlab.ca/git/gitweb.cgi=3Fp=3Dlinux-2.6-virtex.git;a=3Dsnapshot;h=
=3Dd7ed933b578d9c4dec0e23a5a6f78c464b31c47c;sf=3Dtbz2
Is this a complete Kernel=3F I don't really understand this whole git-tree s=
tuff.
then i copied the arch/ppc/configs/ml300=5Fdefconfig to .config.
I used an edk9.1 with linux=5F2=5F6 as OS for the ppc405=5F0, 0x10000000 for me=
mory size, 100000000 for uart16550 bus clock freq and set the target direc=
tory. Under connected=5Fperiphs where: RS232=5FUart, SPI=5FEEPROM, PCI32=5FBRIDGE,=
SysACE=5FCompactFlash and opb=5Fintc=5F0.
At Software I pressed the "Generate Libaries and BSPs" Button and copied t=
he generated xparameters.h to linux-2.6-virtex/arch/ppc/platforms/4xx/xpar=
ameters.
I tried to compile with=20
make ARCH=3Dppc CROSS=5FCOMPILE=3Dpowerpc-405-linux-gnu- zImage
but it soon aborted with:
---------------------------
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC arch/ppc/syslib/xilinx=5Fpic.o
In file included from arch/ppc/syslib/xilinx=5Fpic.c:16:
arch/ppc/platforms/4xx/xparameters/xparameters.h:14:26: linux/config.h: No=
such file or directory
make[1]: *** [arch/ppc/syslib/xilinx=5Fpic.o] Error 1
make: *** [arch/ppc/syslib] Error 2
------------------------------
Can you help me=3F
Is there any tutorial (beside http://wiki.secretlab.ca/index.php/Linux=5Fon=5F=
Xilinx=5FVirtex) which provides detailed information=3F
Which Kernel should I use (And where to get it)=3F
Are ther eany patches necessary=3F
As crosscompiler I used crosstool with:
eval `cat powerpc-405.dat gcc-4.1.0-glibc-2.3.6.dat` sh all.sh --notest
I hope I don't bother you too much
Greetings & Thanks
Joachim
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 15:20 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784E67F.6000000@genesi-usa.com>
On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> NO.
please elaborate
>
> --
> Matt Sealey <matt@genesi-usa.com>
> 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.
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 15:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering, sven
In-Reply-To: <4784E67F.6000000@genesi-usa.com>
On Wed, Jan 09, 2008 at 03:21:35PM +0000, Matt Sealey wrote:
> NO.
YES :)
Friendly,
Sven Luther
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox