* Re: [PATCH 1/3] sbc834x: Add support for Wind River SBC834x boards
From: Stephen Rothwell @ 2008-01-09 7:01 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1199857773848-git-send-email-paul.gortmaker@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
Hi Paul,
On Wed, 9 Jan 2008 00:49:30 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> +static void __init sbc834x_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_node_by_type(NULL, "ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
> +
> + /* Initialize the default interrupt mapping priorities,
> + * in case the boot rom changed something on us.
> + */
> + ipic_set_default_priority();
> +}
This needs an of_node_put(np) somewhere.
> +static struct of_device_id sbc834x_ids[] = {
__initdata
> +static int __init sbc834x_declare_of_platform_devices(void)
> +{
> + if (!machine_is(sbc834x))
> + return 0;
> +
> + of_platform_bus_probe(NULL, sbc834x_ids, NULL);
> + return 0;
> +}
> +device_initcall(sbc834x_declare_of_platform_devices);
machine_device_initcall(sbc834x, ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 2/4 v2] PS3: Add logical performance monitor repository routines
From: Stephen Rothwell @ 2008-01-09 7:15 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus, Takashi Yamamoto
In-Reply-To: <47846B38.7010409@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Tue, 08 Jan 2008 22:35:36 -0800 Geoff Levand <geoffrey.levand@am.sony.com> 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()?
> +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"?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH 1/3] add default device trees for MPC837x MDS board
From: Li Yang @ 2008-01-09 8:38 UTC (permalink / raw)
To: Grant Likely, Wood Scott; +Cc: linuxppc-dev, paulus
In-Reply-To: <fa686aa40801080953y14ecdc60i8c2418ba8d6e809a@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Wednesday, January 09, 2008 1:54 AM
> To: Wood Scott
> Cc: Li Yang; linuxppc-dev@ozlabs.org; paulus@samba.org
> Subject: Re: [PATCH 1/3] add default device trees for MPC837x=20
> MDS board
>=20
> On 1/8/08, Scott Wood <scottwood@freescale.com> wrote:
> > On Tue, Jan 08, 2008 at 08:58:17AM -0700, Grant Likely wrote:
> > > On 1/7/08, Li Yang <leoli@freescale.com> wrote:
> > > > + phy_type =3D "utmi_wide";
> > >
> > > fsl,phy_type please.
> >
> > Again, code will break. Can we stop ambushing people=20
> submitting board=20
> > support with complaints against existing, non-board-specific=20
> > code/device trees? Fix that first, then complain if new=20
> code reintroduces the crud.
>=20
> I disagree (about bringing up these comments). New board=20
> port is the time to bring these issue up. It keeps the issue=20
> in the forefront so it actually gets fixed.
Hi,
I agree that it's good to bring these issues up for a better standarized =
device tree definition. It will be even better if the guidelines are =
documented rather than nuncupated on the mail list. However, I think =
that adding new board support is independent of fixing preexistent =
issues. I do prefer to fix these issues together with other occurrences =
by separated patches rather than respin the new board support over and =
over again.
- Leo
^ permalink raw reply
* Re: [patch 2/4 v2] PS3: Add logical performance monitor repository routines
From: Geert Uytterhoeven @ 2008-01-09 10:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus, Takashi Yamamoto
In-Reply-To: <20080109181501.334e98c8.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1546 bytes --]
On Wed, 9 Jan 2008, Stephen Rothwell wrote:
> On Tue, 08 Jan 2008 22:35:36 -0800 Geoff Levand <geoffrey.levand@am.sony.com> 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.
> > +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.
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
* Toolchain for Freescale e200
From: Per-Erik Johansson @ 2008-01-09 9:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <67A10FA1-8F9D-4A87-BB67-C04EC9FA5BEF@kernel.crashing.org>
Hi
I need a new toolchain since my old one hasn't got support for the (as)
-me200 and book-e stuff I need to compile a kernel for the e200 core.
What flags do I specify to get what I need?
--target=powerpc-e200-linux-gnu --with-cpu=?? --enable-threads=posix
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld
And should I use a particular version of gcc, binutils..?
I'm not that familiar with building cross-toolchains, have tried with
tools like crosstool and buildroot but cant seem to get it to build what I
need.
>From what I understand the e200 and e500 are code compatible so maybe I
could a toolchain for e500 instead, --with-cpu=8540?
Any help is much appreciated!
Best regards
Per-Erik
^ permalink raw reply
* configuring macrowindow for x86 platform and creating a display window????
From: Misbah khan @ 2008-01-09 10:22 UTC (permalink / raw)
To: linuxppc-dev
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.
^ permalink raw reply
* 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
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