Probably better would be to check the board file for mpc834x_mds.c
I mean just cross that you probe all the buses which are on the device.
What is fsl,pq2pro-localbus? Do u have such node in dts as the
mpc8349_itx has.
> -Original Message-
> From: pku@gmail.com [mailto:pku@gmail.
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
wrote:
> That did it.
>
>
>
> I based my board specific file on mpc834x_itx.c which had
>
>
>
> static struct of_device_id __initdata mpc834x_itx_ids[] = {
>
> { .compatible = "fsl,pq2pro-localbus", },
>
> { .compa
> For MSI I doubt any. I think on some parts we might have two (or
> more) groups of MSIs.
>
> However I want to be able to handle timers and the slightly more
> generic message interrupts.
You can probably add a reg and a ranges, the reg remains the same
as today as to not inflict any coll
That did it.
I based my board specific file on mpc834x_itx.c which had
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = "fsl,pq2pro-localbus", },
{ .compatible = "simple-bus", },
{},
};
Don't know if this is broken?
From
Can you look into your board specific file
Like board/freescale/mpc8249_mds/mpc8349_mds.c
And check if the buses are getting probed.
For example
static struct of_device_id mpc834x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
On Thu, Jan 29, 2009 at 12:16 PM, Mike Ditto wrote:
> But I can't explain why the driver isn't attaching for you. Did you
> try it built-in instead of as a module?
>
Hi Mike et al,
I am trying it built-in at the moment (ie. not as a module).
I've stuck a whole bunch of printks() in. This is wh
> -Original Message-
> From: Dushara Jayasinghe [mailto:dusha...@optiscan.com]
> Sent: Thursday, February 19, 2009 2:33 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Li Yang-R58472
> Subject: RE: Newby trying to get Ethernet going on MPC83xx
> series device.
>
> Thanks for the swift response.
>
Thanks for the swift response.
> > I also found that both gfar_init (in gianfar.c) and
> > gfar_mdio_init (in gianfar_mii.c) are called but the probe
> > handlers of either of these devices are not executed.
> >
> > What am I missing?
> Don't find any obvious problem. I suggest you to debug
> -Original Message-
> From:
> linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs
> .org] On Behalf Of Kumar Gala
> Sent: Thursday, February 19, 2009 0:47 AM
> To: Ira Snyder
> Cc: Arnd Bergmann; Jan-Bernd Themann
> -Original Message-
> From:
> linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs
> .org] On Behalf Of Ira Snyder
> Sent: Wednesday, February 18, 2009 6:24 AM
> To: linux-ker...@vger.kernel.org
> Cc: linuxppc-dev@
> -Original Message-
> From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
> On Behalf Of Dushara Jayasinghe
> Sent: Thursday, February 19, 2009 12:27 PM
> To: 'linuxppc-dev@ozlabs.org'
> Subject: Newby trying to get Eth
Hi I'm having difficulty getting an Ethernet device up on a dev board with an
MPX8349 controller.
The contents of my .dts file are as follows (based on mpc8349emitx.dts):
soc8...@e000 {
...
m...@24520 {
#address-cells = <1>;
On Wed, 18 Feb 2009 13:48:52 -0800 (PST)
David Miller wrote:
> From: Henk Stegeman
> Date: Wed, 18 Feb 2009 11:41:14 +0100
>
> Please CC: netdev, now added, on all networking reports and patches.
>
> Thank you.
>
> > I discovered the hard way that because linux bridging uses
> > net_device_op
From: Henk Stegeman
Date: Wed, 18 Feb 2009 11:41:14 +0100
Please CC: netdev, now added, on all networking reports and patches.
Thank you.
> I discovered the hard way that because linux bridging uses
> net_device_ops, bridging only works with network drivers that publish
> their device operation
/sys/devices/system/cpu/cpu*/online don't exist anymore.
When the kernel is booted with maxcpus=1 /sys/devices/system/cpu/cpu1 is
also missing:
$ ls -la /sys/devices/system/cpu/
totale 0
drwxr-xr-x 3 root root0 9 feb 23:15 .
drwxr-xr-x 7 root root0 9 feb 23:15 ..
drwxr-xr-x 4 root root
Kumar,
>
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
With the following in gfar_start_xmit():
BUG_ON(skb->len > priv->dev->mtu);
I bug checked during the NFS root boot process with skb->len at 1514 and
priv->dev
Ingo and Benjamin,
As discussed, I made a branch called mainline/function-graph-tracer
based off of Linus's commit:
commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a
Author: Linus Torvalds
Date: Fri Feb 13 15:31:30 2009 -0800
Linux 2.6.29-rc5
and cherry picked the below change. I added
On 02/17/2009 03:14 PM, gt bradley wrote:
> I'm trying to set up my PS3 to netboot (with an nfsroot).
>
> I'm using instructions at
> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-nfs-root-howto.txt
>
> I've passed section 3 (using tftp) to verify network /dhcp etc. (i.
On Feb 18, 2009, at 11:22 AM, Scott Coulter wrote:
Kumar,
I'm told this will occur when:
Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as
though
t
Kumar,
> I'm told this will occur when:
> Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as though
the mtu is set to 1500. Under what conditions would the d
On Feb 18, 2009, at 10:16 AM, Scott Coulter wrote:
Hi all,
As a simple stress test for my board with an MPC8572E and an
MPC8568E on
it, I setup both processors to boot linux 2.6.27.6 with an NFS root
and
then perform repeated native compiles of a linux kernel over NFS.
After
running fo
On Wed, Feb 18, 2009 at 05:31:34PM +0530, Vijay Nikam wrote:
> > Don't specify this explicitly. Please base new development off of the
> > device tree that is in upstream Linux, not the very old tree in your BSP.
>
> May I know the reason why I should not specify it explicitly ? ? ?
Because dtc
On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
Documentation/virtio-over-PCI.txt | 61 ++
arch/powerpc/boot/dts/mpc834x_mds.dts |7 +
we'll have to review the .dts and expect a documentation update for
the node. But that's pretty minor at this point.
drivers/virtio/Kconfig
On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> On Wednesday 18 February 2009 08:54:25 Ira Snyder wrote:
> > This adds support to Linux for using virtio between two computers linked by
> > a PCI interface. This allows the use of virtio_net to create a familiar,
> > fast interface f
Hi all,
As a simple stress test for my board with an MPC8572E and an MPC8568E on
it, I setup both processors to boot linux 2.6.27.6 with an NFS root and
then perform repeated native compiles of a linux kernel over NFS. After
running for 4 days straight or so with between 250-300 build cycles per
I checked and read the
Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt and
booting-without-of.txt. It is different then what I read before from
booting-without-of.txt ... perhaps as it is old and came with BSP. Am
I right ? ? ?
> Don't specify this explicitly. Please base new development off
Hello,
I discovered the hard way that because linux bridging uses
net_device_ops, bridging only works with network drivers that publish
their device operations trough net_device_ops.
In my case running:
brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
net_device_ops) gave me a:
From: Anton Blanchard
Date: Wed, 18 Feb 2009 16:11:12 +1100
> @@ -145,9 +145,10 @@ extern void *alloc_large_system_hash(const char
> *tablename,
> #define HASH_EARLY 0x0001 /* Allocating during early boot? */
>
> /* Only NUMA needs hash distribution.
> - * IA64 and x86_64 have suf
28 matches
Mail list logo
