* Re: MPC5200 ethernet communication stops unexpected
From: David Kanceruk @ 2007-05-15 15:03 UTC (permalink / raw)
To: Hans Thielemans; +Cc: linuxppc-embedded
In-Reply-To: <1179234357.1668.10.camel@pc-hans>
Hello Hans,
Our problem was with the FEC sending data with one or two
incorrect bytes when we switched from the MPC5200 to the MPC5200B. The
byte positions were always the same. The socket buffer has the correct
data before and after the DMA engine runs but the FEC TxFIFO does not
always match.
One solution to our problem was to make the following call prior to
starting the DMA:
flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data
+ skb->len);
The other solution was to set the BSDIS bit in the XLB config register
during initialization as follows:
xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB;
out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_BSDIS);
Either solution works for us. The BSDIS bit is a new feature in the
MPC5200B. The MPC5200 did not have this bit.
According to the Freescale documentation, (Application note AN3045,
for instance) setting this bit is supposed to "disable" BestComm bus
snooping. However, I have reason to believe the documentation is in
error. Everything I have observed seems to indicate that in the
MPC5200 BestComm bus snooping was always enabled or enabled via some
other means. In the MPC5200B it appears to be "disabled" at reset (not
"enabled" as the documentation states). This is why flushing the cache
manually is one solution. Since setting the BSDIS bit also fixes the
problem, it suggests that this actually "enables" BestComm bus
snooping instead of disabling it. In my mind, it could all boil down
to a simple documentation error.
Perhaps you are also experiencing a caching problem.
Best regards,
David Kanceruk
On 5/15/07, Hans Thielemans <hans.thielemans@metris.com> wrote:
> Hi David,
>
> I have a similar problem. I use the PSC for communication to a DSP.
> With the MPC5200 this has always worked. Now we got boards with the
> MCP5200B in place.
>
> The bestcomm dma seems to miss bits, bytes in the last word (32bit) of a
> dma block. Mostly it is one byte which becomes 0. The blocks are 256
> bytes and written/read by 32 bits.
> The behavior is influenced by cpu activity, bus priorities. So far I
> found no settings which have never errors.
>
> Did you have any further progress?
>
> Regards
>
> Hans Thielemans
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to chance."
^ permalink raw reply
* RE: MPC5200 ethernet communication stops unexpected
From: Hans Thielemans @ 2007-05-15 15:16 UTC (permalink / raw)
To: David Kanceruk; +Cc: linuxppc-embedded
Hello David,
In this case, I am flushing cache. And overall, these are empty packets
sent which are never changed.
The cpu creates this once and then this is always reused. It is received
maybe 100000 times correct and
then suddenly I see an error in the last word.=20
I also tried playing with the BSDIS and PLDIS bits, and with the bus
priorities. This influences the error rate,
but it is never really gone.=20
As a hack I have now added an extra word after the packet, and have the
receiver ignore it. This seems to help,
but I don't like it.
Regards
Hans
-----Original Message-----
From: David Kanceruk [mailto:david.kanceruk@gmail.com]=20
Sent: dinsdag 15 mei 2007 17:04
To: Hans Thielemans
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC5200 ethernet communication stops unexpected
Hello Hans,
Our problem was with the FEC sending data with one or two incorrect
bytes when we switched from the MPC5200 to the MPC5200B. The byte
positions were always the same. The socket buffer has the correct data
before and after the DMA engine runs but the FEC TxFIFO does not always
match.
One solution to our problem was to make the following call prior to
starting the DMA:
flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data
+ skb->len);
The other solution was to set the BSDIS bit in the XLB config register
during initialization as follows:
xlb =3D (struct mpc52xx_xlb *)MPC5xxx_XLB;
out_be32(&xlb->config, in_be32(&xlb->config) |
MPC52xx_XLB_CFG_BSDIS);
Either solution works for us. The BSDIS bit is a new feature in the
MPC5200B. The MPC5200 did not have this bit.
According to the Freescale documentation, (Application note AN3045, for
instance) setting this bit is supposed to "disable" BestComm bus
snooping. However, I have reason to believe the documentation is in
error. Everything I have observed seems to indicate that in the MPC5200
BestComm bus snooping was always enabled or enabled via some other
means. In the MPC5200B it appears to be "disabled" at reset (not
"enabled" as the documentation states). This is why flushing the cache
manually is one solution. Since setting the BSDIS bit also fixes the
problem, it suggests that this actually "enables" BestComm bus snooping
instead of disabling it. In my mind, it could all boil down to a simple
documentation error.
Perhaps you are also experiencing a caching problem.
Best regards,
David Kanceruk
On 5/15/07, Hans Thielemans <hans.thielemans@metris.com> wrote:
> Hi David,
>
> I have a similar problem. I use the PSC for communication to a DSP.
> With the MPC5200 this has always worked. Now we got boards with the=20
> MCP5200B in place.
>
> The bestcomm dma seems to miss bits, bytes in the last word (32bit) of
> a dma block. Mostly it is one byte which becomes 0. The blocks are 256
> bytes and written/read by 32 bits.
> The behavior is influenced by cpu activity, bus priorities. So far I=20
> found no settings which have never errors.
>
> Did you have any further progress?
>
> Regards
>
> Hans Thielemans
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to
chance."
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: David Brownell @ 2007-05-15 15:28 UTC (permalink / raw)
To: Jean Delvare, Grant Likely; +Cc: linuxppc-dev, i2c, rtc-linux, James Chapman
In-Reply-To: <20070515152626.199f9d6b@hyperion.delvare>
On Tuesday 15 May 2007, Jean Delvare wrote:
> On Mon, 14 May 2007 13:11:23 -0600, Grant Likely wrote:
> > --- a/drivers/i2c/busses/i2c-mpc.c
> > +++ b/drivers/i2c/busses/i2c-mpc.c
> > @@ -327,9 +327,10 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > platform_set_drvdata(pdev, i2c);
> >
> > i2c->adap = mpc_ops;
> > + i2c->adap.nr = pdev->id;
By the way: mpc_ops is a static i2c_adapter, so given that
the reason for using pdev->id that way was that there might
be more than one such platform device ... shouldn't allocation
of the adapter be moved into allocation of the "i2c->" object?
Or at least, add a check to ensure that the static mpc_ops
structure isn't in use before progressing this probe().
- Dave
> > i2c_set_adapdata(&i2c->adap, i2c);
> > i2c->adap.dev.parent = &pdev->dev;
> > - if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
> > + if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> > printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
> > goto fail_add;
> > }
>
> --
> Jean Delvare
>
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: David Kanceruk @ 2007-05-15 15:40 UTC (permalink / raw)
To: Hans Thielemans; +Cc: linuxppc-embedded
In-Reply-To: <80AD928CDD8C8C469A1357A9C7B7657FF72DE0@kryp01.krypton.be>
Hello Hans,
There sure seems to be strange behavior in the BestComm unit. Our
problem was always with the first byte or the 63rd byte on a buffer of
102 bytes.
Did you use a value of (1<<16) for the BSDIS bit? We also do a
ioremap when setting a pointer to the xlb.
Dave
On 5/15/07, Hans Thielemans <Hans.Thielemans@metris.com> wrote:
> Hello David,
>
> In this case, I am flushing cache. And overall, these are empty packets
> sent which are never changed.
> The cpu creates this once and then this is always reused. It is received
> maybe 100000 times correct and
> then suddenly I see an error in the last word.
>
> I also tried playing with the BSDIS and PLDIS bits, and with the bus
> priorities. This influences the error rate,
> but it is never really gone.
>
> As a hack I have now added an extra word after the packet, and have the
> receiver ignore it. This seems to help,
> but I don't like it.
>
> Regards
>
> Hans
>
> -----Original Message-----
> From: David Kanceruk [mailto:david.kanceruk@gmail.com]
> Sent: dinsdag 15 mei 2007 17:04
> To: Hans Thielemans
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC5200 ethernet communication stops unexpected
>
> Hello Hans,
>
> Our problem was with the FEC sending data with one or two incorrect
> bytes when we switched from the MPC5200 to the MPC5200B. The byte
> positions were always the same. The socket buffer has the correct data
> before and after the DMA engine runs but the FEC TxFIFO does not always
> match.
>
> One solution to our problem was to make the following call prior to
> starting the DMA:
>
> flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data
> + skb->len);
>
> The other solution was to set the BSDIS bit in the XLB config register
> during initialization as follows:
>
> xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB;
> out_be32(&xlb->config, in_be32(&xlb->config) |
> MPC52xx_XLB_CFG_BSDIS);
>
> Either solution works for us. The BSDIS bit is a new feature in the
> MPC5200B. The MPC5200 did not have this bit.
>
> According to the Freescale documentation, (Application note AN3045, for
> instance) setting this bit is supposed to "disable" BestComm bus
> snooping. However, I have reason to believe the documentation is in
> error. Everything I have observed seems to indicate that in the MPC5200
> BestComm bus snooping was always enabled or enabled via some other
> means. In the MPC5200B it appears to be "disabled" at reset (not
> "enabled" as the documentation states). This is why flushing the cache
> manually is one solution. Since setting the BSDIS bit also fixes the
> problem, it suggests that this actually "enables" BestComm bus snooping
> instead of disabling it. In my mind, it could all boil down to a simple
> documentation error.
>
> Perhaps you are also experiencing a caching problem.
>
> Best regards,
>
> David Kanceruk
>
> On 5/15/07, Hans Thielemans <hans.thielemans@metris.com> wrote:
> > Hi David,
> >
> > I have a similar problem. I use the PSC for communication to a DSP.
> > With the MPC5200 this has always worked. Now we got boards with the
> > MCP5200B in place.
> >
> > The bestcomm dma seems to miss bits, bytes in the last word (32bit) of
>
> > a dma block. Mostly it is one byte which becomes 0. The blocks are 256
>
> > bytes and written/read by 32 bits.
> > The behavior is influenced by cpu activity, bus priorities. So far I
> > found no settings which have never errors.
> >
> > Did you have any further progress?
> >
> > Regards
> >
> > Hans Thielemans
> >
>
>
>
> --
> David Kanceruk
>
> "The generation of random numbers is far too important to be left to
> chance."
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to chance."
^ permalink raw reply
* RE: MPC5200B memory performance
From: Fillod Stephane @ 2007-05-15 15:14 UTC (permalink / raw)
To: Daniel Schnell, linuxppc-embedded
Daniel Schnell wrote:
>With the attached program (compile with -lrt) I am testing the memcpy()
>throughput. In theory the memory throughput should be the double of the
>memcpy() throughput if source and destination buffers are same size and
>inside the DDR-RAM.
Theory tells that write speed is a little bit different than read speed,
but that's when you want to be picky. RTFD(*).
(*) Datasheets
>So one could make the simple calculation:
>
>132 MHz * 32 Bit (address width) * 2 (DDR) ~ 1GBytes/sec brutto memory
throughput.
>
>For a memcpy this should be then ~500MB/second.
All you can say is, assuming 100% efficient
CPU/cache/bus/DDR-controller,=20
you can say that memcpy (hitting the DRAM) cannot be higher than that=20
value :-)
>Of course in real world scenarios we cannot reach the theoretical
limit,
>but be about 30 % near I guess.
IMO, real world scenarios *should* achieve at least 70%, with
appropriate
memcpy implementation. I've been disappointed lately by PQ3 which cannot
do better than ~50% efficiency. I'd love anyone, esp. from Freescale,
to prove me wrong or show my mistake. The FAE didn't give an answer,=20
but I saw that newer parts will have a "Queue manager" helping=20
the DDR controller. Any idea?
[...]
>The first 4 values are because of the data cache. So here we are
testing
What's your data cache size BTW? Do you have a L2 cache?
>cache performance. All other values will test the memory controller
>interface.
Well, you're testing also part of the cache and memory subsystem.
On the read side, you're paying an extra for cache misses. On the write
side,
there's read-on-write. I don't know the mpc5200 details, but most cache=20
subsystems think it's smart to fill-up (read) end of line you began
to write. But in the big memcpy case, the read is useless because=20
the cache didn't know you were about to overwrite the full line.=20
That's why the dcbz ppc instruction comes in handy to prevent the R-O-W.
In that regard, glibc is very suboptimal. For better performance,
I recommend you to read and understand the cacheable_memcpy assembly
function in Linux kernel (arch/ppc/lib/string.S). It's missing
some read prefetch (dcbt) though.
>All in all, I am not sure, why the memory access is so much slower than
I expected.
>Which factors did I miss in my calculation ? Can anybody run this
>program on its 5200B based board as a comparision ?
The values on PQ3 won't be of any help for you, esp. with disappointing
result (50% efficiency max). If you doubt about your memcpy
implementation,
you may implement the same bench with DMA (to get 50MiB of contiguous
RAM,
do it in kernel or under U-Boot).=20
Best Regards,
--=20
Stephane
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: Grant Likely @ 2007-05-15 15:51 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, James Chapman, linuxppc-dev, i2c, Jean Delvare
In-Reply-To: <200705150828.37529.david-b@pacbell.net>
On 5/15/07, David Brownell <david-b@pacbell.net> wrote:
> On Tuesday 15 May 2007, Jean Delvare wrote:
> > On Mon, 14 May 2007 13:11:23 -0600, Grant Likely wrote:
>
> > > --- a/drivers/i2c/busses/i2c-mpc.c
> > > +++ b/drivers/i2c/busses/i2c-mpc.c
> > > @@ -327,9 +327,10 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > > platform_set_drvdata(pdev, i2c);
> > >
> > > i2c->adap = mpc_ops;
> > > + i2c->adap.nr = pdev->id;
>
> By the way: mpc_ops is a static i2c_adapter, so given that
> the reason for using pdev->id that way was that there might
> be more than one such platform device ... shouldn't allocation
> of the adapter be moved into allocation of the "i2c->" object?
Take another look; this is a funny quirk of the driver. The
assignment is 'i2c->adap = mpc_ops'; not 'i2c->adap = &mpc_ops'. And
in struct mpc_i2c, the field is declared as 'struct i2c_adapter adap',
not 'struct i2c_adapter *adap'. The driver instance gets a copy of
the mpc_ops structure to initialize it, not a pointer to the staticly
defined structure. I got bitten by the same thing when I was looking
at the code.
Not to mention that mpc_ops is poorly named.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: David Brownell @ 2007-05-15 16:05 UTC (permalink / raw)
To: Grant Likely; +Cc: rtc-linux, James Chapman, linuxppc-dev, i2c, Jean Delvare
In-Reply-To: <528646bc0705150851pa578a56nc0dc171677748e5a@mail.gmail.com>
On Tuesday 15 May 2007, Grant Likely wrote:
>
> Take another look; this is a funny quirk of the driver. The
> assignment is 'i2c->adap = mpc_ops'; not 'i2c->adap = &mpc_ops'. And
> in struct mpc_i2c, the field is declared as 'struct i2c_adapter adap',
> not 'struct i2c_adapter *adap'. The driver instance gets a copy of
> the mpc_ops structure to initialize it, not a pointer to the staticly
> defined structure. I got bitten by the same thing when I was looking
> at the code.
I see -- you're right. That "template" idiom is a good one to get
rid of, FWIW ... not only is it confusing, but it also wastes space.
- Dave
^ permalink raw reply
* [PATCH 0/5] MPC8641 HPCN fixes
From: Wade Farnsworth @ 2007-05-15 16:17 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
These patches fix a few of the peripherals on the MPC8641 HPCN.
Any comments would be appreciated.
Thanks,
--Wade Farnsworth
^ permalink raw reply
* [PATCH 1/5] Add MTD support to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-15 16:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1179245829.8132.100.camel@rhino>
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -335,4 +335,17 @@
big-endian;
};
};
+
+ flash@ff800000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <ff800000 00800000>;
+ bank-width = <2>;
+ partitions = <00000000 00300000
+ 00300000 00100000
+ 00400000 00300000
+ 00700000 00100000>;
+ partition-names = "kernel", "firmware b", "fs", "firmware a";
+ };
};
^ permalink raw reply
* [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-15 16:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1179245829.8132.100.camel@rhino>
This adds device nodes for the ISA devices on the MPC8641 HPCN to the
dts. Additionally, it moves the node for the i8259 to the isa bus,
since the i8259 is actually on that bus.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 48 ++++++++++++++++++-----
1 file changed, 38 insertions(+), 10 deletions(-)
Index: linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -285,17 +285,45 @@
f800 0 0 3 &i8259 0 0
f800 0 0 4 &i8259 0 0
>;
- i8259: i8259@4d0 {
- clock-frequency = <0>;
- interrupt-controller;
- device_type = "interrupt-controller";
- #address-cells = <0>;
+
+ isa@f0 {
+ device_type = "isa";
#interrupt-cells = <2>;
- built-in;
- compatible = "chrp,iic";
- big-endian;
- interrupts = <49 2>;
- interrupt-parent = <&mpic>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0 00001000>;
+ interrupt-parent = <4d0>;
+
+ 8042@60 {
+ device_type = "8042";
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent = <4d0>;
+ };
+
+ rtc@70 {
+ device_type = "rtc";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ device_type = "gpio";
+ reg = <1 400 80>;
+ };
+
+ i8259: i8259@4d0 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ big-endian;
+ interrupts = <49 2>;
+ interrupt-parent = <&mpic>;
+ };
};
};
^ permalink raw reply
* Re: [PATCH 3/5] Support for the LPC47M192 SuperIO on the MPC8641 HPCN
From: Wade Farnsworth @ 2007-05-15 16:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1179245829.8132.100.camel@rhino>
This adds support for the LPC47M192 SuperIO on the MPC8641 HPCN.
Specifically this adds support for the I8042 Keyboard/Mouse and the GPIO
on the chip.
Also, the mouse needs to use IRQ 12, which is currently in use by some
PCI devices. Move those devices to IRQ 11.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 4 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 43 +++++++++++++++----
2 files changed, 38 insertions(+), 9 deletions(-)
Index: linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -264,7 +264,7 @@
/* IDSEL 0x1c */
e000 0 0 1 &i8259 9 2
e000 0 0 2 &i8259 a 2
- e000 0 0 3 &i8259 c 2
+ e000 0 0 3 &i8259 b 2
e000 0 0 4 &i8259 7 2
/* IDSEL 0x1d */
@@ -274,7 +274,7 @@
e800 0 0 4 &i8259 0 0
/* IDSEL 0x1e */
- f000 0 0 1 &i8259 c 2
+ f000 0 0 1 &i8259 b 2
f000 0 0 2 &i8259 0 0
f000 0 0 3 &i8259 0 0
f000 0 0 4 &i8259 0 0
Index: linux-2.6-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ linux-2.6-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -141,7 +141,7 @@ const unsigned char uli1575_irq_route_ta
0x1, /* 9: 0b0001 */
0x3, /* 10: 0b0011 */
0x9, /* 11: 0b1001 */
- 0xb, /* 12: 0b1011 */
+ 0, /* 12: Reserved */
0, /* 13: Reserved */
0xd, /* 14, 0b1101 */
0xf, /* 15, 0b1111 */
@@ -211,7 +211,7 @@ static void __devinit quirk_uli1575(stru
pirq_map_word |= (uli1575_irq_route_table[i] & 0xf)
<< ((irq2pin[i] - PIRQA) * 4);
- /* ULI1575 IRQ mapping conf register default value is 0xb9317542 */
+ /* ULI1575 IRQ mapping conf register default value is 0x09317542 */
DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",
pirq_map_word);
pci_write_config_dword(dev, 0x48, pirq_map_word);
@@ -266,9 +266,9 @@ static void __devinit quirk_uli1575(stru
pci_write_config_byte(dev, 0x44, 0x30 | uli1575_irq_route_table[14]);
pci_write_config_byte(dev, 0x75, uli1575_irq_route_table[15]);
- /* Set IRQ14 and IRQ15 to legacy IRQs */
+ /* Set IRQ1, IRQ12, IRQ14 and IRQ15 to legacy IRQs */
pci_read_config_word(dev, 0x46, &temp);
- temp |= 0xc000;
+ temp |= 0xd002;
pci_write_config_word(dev, 0x46, temp);
/* Set i8259 interrupt trigger
@@ -280,12 +280,12 @@ static void __devinit quirk_uli1575(stru
* IRQ 9: Level
* IRQ 10: Level
* IRQ 11: Level
- * IRQ 12: Level
+ * IRQ 12: Edge
* IRQ 14: Edge
* IRQ 15: Edge
*/
- outb(0xfa, 0x4d0);
- outb(0x1e, 0x4d1);
+ outb(0xf8, 0x4d0);
+ outb(0x0e, 0x4d1);
#undef ULI1575_SET_DEV_IRQ
@@ -293,6 +293,35 @@ static void __devinit quirk_uli1575(stru
pci_read_config_byte(dev, 0xb8, &c);
c &= 0x7f;
pci_write_config_byte(dev, 0xb8, c);
+
+ /* enable superio @ 0x4e and keyboard/mouse address decoding */
+ pci_write_config_byte(dev, 0x63, 0x90);
+
+ /* LPC47M192 Super I/O configuration */
+ outb(0x55, 0x4e); /* enter superio config mode */
+
+ /* Enable keyboard and mouse */
+ outb(0x07, 0x4e); /* device selector register */
+ outb(0x07, 0x4f); /* select keyboard registers (device 7) */
+ outb(0x30, 0x4e); /* keyboard activation register */
+ outb(0x01, 0x4f); /* activate keyboard */
+ outb(0x70, 0x4e); /* keyboard IRQ register */
+ outb(0x01, 0x4f); /* IRQ1 for keyboard */
+ outb(0x72, 0x4e); /* mouse IRQ register */
+ outb(0x0c, 0x4f); /* IRQ12 for mouse */
+
+ /* Enable superio runtime registers for gpio in pci i/o space */
+ outb(0x20, 0x4e); /* device id register */
+ outb(0x07, 0x4e); /* device selector register */
+ outb(0x0a, 0x4f); /* select runtime registers (device A) */
+ outb(0x60, 0x4e); /* select runtime register address high byte */
+ outb(0x04, 0x4f); /* runtime register address high byte */
+ outb(0x61, 0x4e); /* select runtime register address low byte */
+ outb(0x01, 0x4f); /* runtime register address low byte */
+ outb(0x30, 0x4e); /* runtime registers activation register */
+ outb(0x01, 0x4f); /* activate runtime registers */
+
+ outb(0xaa, 0x4e); /* exit superio config mode */
}
static void __devinit quirk_uli5288(struct pci_dev *dev)
^ permalink raw reply
* Re: [Fwd: [alsa-devel] embedded sound architecture question]
From: Joachim Förster @ 2007-05-15 16:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46495CB4.8050809@246tNt.com>
Hi Sylvain,
thank you very much for your mail,
On Tue, 2007-05-15 at 09:09 +0200, Sylvain Munaut wrote:
> I'm not an alsa expert but I'm working on a driver right now. And alsa
> provide you a hook so you can allocate your memory buffer your self.
> So as long as your control maps it's memory somewhere in the
> cpu address space you should be fine.
By "hook", do you mean the prepare()/hw_params() callbacks?
I noticed that there is an (undocumented?) mmap() callback, too, so I
think, I have to implement that one and call something like
io_remap_pfn_range() to "connect" the device's memory to the VMA
(virtual memory area) which is provided as an argument to the mmap()
callback, right?
In our case, we are not going to allocate any memory like a typical ALSA
driver does (with DMA) (in prepare()/hw_params() callback), because the
device's IO memory will "be there" - we just have to "announce"/map it
into kernel space, right? Or is this interpretation wrong?
Joachim
^ permalink raw reply
* [PATCH 4/5] Add RTC CMOS support for the MPC8641 HPCN
From: Wade Farnsworth @ 2007-05-15 16:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1179245829.8132.100.camel@rhino>
This enables the new RTC CMOS driver to be used on the MPC8641 HPCN.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
Index: powerpc-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
===================================================================
--- powerpc-8641.orig/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ powerpc-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -18,6 +18,7 @@
#include <linux/kdev_t.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
+#include <linux/mc146818rtc.h>
#include <asm/system.h>
#include <asm/time.h>
@@ -368,6 +369,32 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_A
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, quirk_uli5288);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
+
+#ifdef CONFIG_RTC_DRV_CMOS
+struct resource rtc_platform_resource = {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(1),
+};
+
+static int __init mpc8641_hpcn_add_rtc(void)
+{
+ struct platform_device *pd;
+
+ pd = platform_device_register_simple("rtc_cmos", -1,
+ &rtc_platform_resource, 1);
+ if (IS_ERR(pd))
+ return PTR_ERR(pd);
+
+ /* rtc-cmos only supports 24-hr mode */
+ CMOS_WRITE(CMOS_READ(RTC_CONTROL) | RTC_24H, RTC_CONTROL);
+
+ return 0;
+}
+arch_initcall(mpc8641_hpcn_add_rtc);
+
+#endif /* CONFIG_RTC_DRV_CMOS */
+
#endif /* CONFIG_PCI */
^ permalink raw reply
* Re: [PATCH] [POWERPC] remove build warnings in windfarm_core
From: Linas Vepstas @ 2007-05-15 16:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <e1629d824068540e703ba7d661753992@kernel.crashing.org>
On Tue, May 15, 2007 at 08:32:08AM +0200, Segher Boessenkool wrote:
> >> - device_create_file(&wf_platform_device.dev, &new_ct->attr);
> >> + ret = device_create_file(&wf_platform_device.dev, &new_ct->attr);
> >> + if (ret) {
> >> + list_del(&new_ct->link);
> >> + printk(KERN_WARNING "windfarm: device_creat_file failed"
> >> + "for %s\n", new_ct->name);
> >> + goto out_unlock;
> >
> > This shows up why I hate the must_check stuff. The sysfs files are
> > not essential for the operation of the windfarm subsystem.
>
> They are essential for the user expectations of the
> subsystem though; if registration fails, a warning
> should be printed.
>
> > If the
> > sysfs registration fails for any reason, we now have a completely
> > non-functional windfarm subsystem instead of a mostly-working one. :(
>
> Yeah, but that's not must_check's fault, it doesn't
> say *what* to do with the error code :-)
Ergo, the patch should be reworked to print the warning only,
but otherwise continue with the setup.
--linas
^ permalink raw reply
* [PATCH] powerpc: EDAC platform devices setup for Marvell/mv64x60
From: Dave Jiang @ 2007-05-15 16:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, dfarnsworth
Creating platform devices (memory controller, sram error registers, cpu error
registers, pci error registers) for EDAC driver on the Marvell/mv64x60 chip.
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
arch/powerpc/sysdev/mv64x60_dev.c | 183 +++++++++++++++++++++++++++++++++++++
1 files changed, 183 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index 4b0a9c8..ce37ab8 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -389,6 +390,154 @@ error:
return err;
}
+/*
+ * Platform device setup for EDAC memory controller
+ */
+static int __init mv64x60_mem_ctrl_init(struct device_node *np, int id)
+{
+ struct resource r[2];
+ struct platform_device *pdev;
+ int ret;
+
+ memset(r, 0, sizeof(r));
+
+ ret = of_address_to_resource(np, 0, &r[0]);
+ if (ret)
+ goto err;
+
+ of_irq_to_resource(np, 0, &r[1]);
+
+ pdev = platform_device_register_simple("mv64x60_mc_err", id, r, 2);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+
+err:
+ return ret;
+}
+
+/*
+ * Platform device setup for EDAC CPU errors
+ */
+static int __init mv64x60_cpu_error_init(struct device_node *np, int id)
+{
+ struct resource r[3];
+ struct platform_device *pdev;
+ int ret;
+
+ memset(r, 0, sizeof(r));
+
+ ret = of_address_to_resource(np, 0, &r[0]);
+ if (ret)
+ goto err;
+
+ ret = of_address_to_resource(np, 1, &r[1]);
+ if (ret)
+ goto err;
+
+ of_irq_to_resource(np, 0, &r[2]);
+
+ pdev = platform_device_register_simple("mv64x60_cpu_err", id, r, 3);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+
+err:
+ return ret;
+}
+
+/*
+ * Platform device setup for EDAC SRAM errors
+ */
+static int __init mv64x60_sram_ctrl_init(struct device_node *np, int id)
+{
+ struct resource r[2];
+ struct platform_device *pdev;
+ int ret;
+
+ memset(r, 0, sizeof(r));
+
+ ret = of_address_to_resource(np, 0, &r[0]);
+ if (ret)
+ goto err;
+
+ of_irq_to_resource(np, 0, &r[1]);
+
+ pdev = platform_device_register_simple("mv64x60_sram_err", id, r, 2);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+
+err:
+ return ret;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ struct resource res;
+ void __iomem *pci_serr;
+ int ret;
+
+ ret = of_address_to_resource(np, 1, &res);
+ if (ret)
+ return ret;
+
+ pci_serr = ioremap(res.start, res.end - res.start + 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+
+/*
+ * Platform device setup for EDAC PCI errors
+ */
+static int __init mv64x60_pci_error_init(struct device_node *np, int id)
+{
+ struct resource r[2];
+ struct platform_device *pdev;
+ int ret;
+
+ memset(r, 0, sizeof(r));
+
+ ret = mv64x60_pci_fixup(np);
+ if (ret)
+ goto err;
+
+ ret = of_address_to_resource(np, 0, &r[0]);
+ if (ret)
+ goto err;
+
+ of_irq_to_resource(np, 0, &r[1]);
+
+ pdev = platform_device_register_simple("mv64x60_pci_err", id, r, 2);
+ if (IS_ERR(pdev)) {
+ ret = PTR_ERR(pdev);
+ goto err;
+ }
+
+ return 0;
+
+err:
+ return ret;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -413,6 +562,40 @@ static int __init mv64x60_device_setup(void)
if ((err = mv64x60_i2c_device_setup(np, id)))
goto error;
+ for (id = 0;
+ (np = of_find_compatible_node(np,
+ NULL,
+ "marvell,mv64x60-mem-ctrl"));
+ id++)
+ if ((err = mv64x60_mem_ctrl_init(np, id)))
+ goto error;
+
+ for (id = 0;
+ (np = of_find_compatible_node(np,
+ NULL,
+ "marvell,mv64x60-cpu-error"));
+ id++)
+ if ((err = mv64x60_cpu_error_init(np, id)))
+ goto error;
+
+ for (id = 0;
+ (np = of_find_compatible_node(np,
+ NULL,
+ "marvell,mv64x60-sram-ctrl"));
+ id++)
+ if ((err = mv64x60_sram_ctrl_init(np, id)))
+ goto error;
+
+#ifdef CONFIG_PCI
+ for (id = 0;
+ (np = of_find_compatible_node(np,
+ NULL,
+ "marvell,mv64x60-pci-error"));
+ id++)
+ if ((err = mv64x60_pci_error_init(np, id)))
+ goto error;
+#endif
+
return 0;
error:
^ permalink raw reply related
* [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02 hardware
From: Wade Farnsworth @ 2007-05-15 16:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1179245829.8132.100.camel@rhino>
This fixes PCI support for newer revisions of the MPCN8641 silicon and
the HPCN hardware.
Currently, there is a workaround for a PCI erratum that forces the host
bridge's primary bus to be 0xff. This workaround is no longer necessary
on newer revisions.
Additionally, the host bridge on the newer rev's behaves like a
transparent bridge, but does not use the correct PCI class, so this adds
a fixup for the class. This is the only device on bus 0, all other
devices are on subsequent buses.
Furthermore, all of the devices on the southbridge show up on bus 2,
behind an additional PCI bridge. In order to use the correct IRQ's for
the devices, we need to create additional device nodes for the PCI
bridges, and reproduce the interrupt map on the correct bus.
Since the southbridge devices are now bus 2, we also need to fix the bus
range for PCIe 2 to begin at bus 3.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 121 ++++++++++++++++++-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 8 -
arch/powerpc/platforms/86xx/pci.c | 27 +++-
3 files changed, 149 insertions(+), 7 deletions(-)On Tue, 2007-05-15 at
09:17 -0700, Wade Farnsworth wrote:
Index: linux-2.6-8641/arch/powerpc/platforms/86xx/pci.c
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/platforms/86xx/pci.c
+++ linux-2.6-8641/arch/powerpc/platforms/86xx/pci.c
@@ -134,16 +134,24 @@ mpc86xx_setup_pcie(struct pci_controller
early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0x80);
- /* PCIE Bus, Fix the MPC8641D host bridge's location to bus 0xFF. */
+ /*
+ * For Rev 1.0, fix the bus to 0xff. Otherwise use the default.
+ */
early_read_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, &temps);
- temps = (temps & 0xff000000) | (0xff) | (0x0 << 8) | (0xfe << 16);
+ if ((mfspr(SPRN_SVR) & 0xf0) == 0x10)
+ temps = (temps & 0xff000000) | 0xff | (0xfe << 16);
+ else
+ temps = (temps & 0xff000000) | hose->first_busno |
+ ((hose->first_busno + 1) << 8) |
+ (hose->last_busno << 16);
early_write_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, temps);
}
int mpc86xx_exclude_device(u_char bus, u_char devfn)
{
- if (bus == 0 && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
+ if ((mfspr(SPRN_SVR) & 0xf0) == 0x10)
+ if (bus == 0 && PCI_SLOT(devfn) == 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
return PCIBIOS_SUCCESSFUL;
}
@@ -162,6 +170,11 @@ int __init add_bridge(struct device_node
/* Fetch host bridge registers address */
has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+ /* For Rev 1 silicon, only the first PCI host is supported. */
+ if (((mfspr(SPRN_SVR) & 0xf0) == 0x10) &&
+ ((rsrc.start & 0xfffff) == 0x9000))
+ return 0;
+
/* Get bus range if any */
bus_range = of_get_property(dev, "bus-range", &len);
if (bus_range == NULL || len < 2 * sizeof(int))
@@ -203,3 +216,9 @@ int __init add_bridge(struct device_node
return 0;
}
+
+static void __devinit early_mpc86xx_pcie(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8 | 0x1;
+}
+DECLARE_PCI_FIXUP_EARLY(0x1957, 0x7011, early_mpc86xx_pcie);
Index: linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -286,6 +286,125 @@
f800 0 0 4 &i8259 0 0
>;
+ pci@00 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0000 0 0 0 0>;
+ bus-range = <0 fe>;
+ ranges = <02000000 0 80000000 80000000 0
+ 20000000
+ 01000000 0 00000000 00000000 0
+ 00100000>;
+
+ pci@00 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0000 0 0 0 0>;
+ bus-range = <1 fe>;
+ ranges = <02000000 0 80000000 80000000
+ 0 20000000
+ 01000000 0 00000000 00000000
+ 0 00100000>;
+ interrupt-map-mask = <3f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x11 */
+ 28800 0 0 1 &i8259 3 2
+ 28800 0 0 2 &i8259 4 2
+ 28800 0 0 3 &i8259 5 2
+ 28800 0 0 4 &i8259 6 2
+
+ /* IDSEL 0x12 */
+ 29000 0 0 1 &i8259 4 2
+ 29000 0 0 2 &i8259 5 2
+ 29000 0 0 3 &i8259 6 2
+ 29000 0 0 4 &i8259 3 2
+
+ /* IDSEL 0x13 */
+ 29800 0 0 1 &i8259 0 0
+ 29800 0 0 2 &i8259 0 0
+ 29800 0 0 3 &i8259 0 0
+ 29800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x14 */
+ 2a000 0 0 1 &i8259 0 0
+ 2a000 0 0 2 &i8259 0 0
+ 2a000 0 0 3 &i8259 0 0
+ 2a000 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x15 */
+ 2a800 0 0 1 &i8259 0 0
+ 2a800 0 0 2 &i8259 0 0
+ 2a800 0 0 3 &i8259 0 0
+ 2a800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x16 */
+ 2b000 0 0 1 &i8259 0 0
+ 2b000 0 0 2 &i8259 0 0
+ 2b000 0 0 3 &i8259 0 0
+ 2b000 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x17 */
+ 2b800 0 0 1 &i8259 0 0
+ 2b800 0 0 2 &i8259 0 0
+ 2b800 0 0 3 &i8259 0 0
+ 2b800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x18 */
+ 2c000 0 0 1 &i8259 0 0
+ 2c000 0 0 2 &i8259 0 0
+ 2c000 0 0 3 &i8259 0 0
+ 2c000 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x19 */
+ 2c800 0 0 1 &i8259 0 0
+ 2c800 0 0 2 &i8259 0 0
+ 2c800 0 0 3 &i8259 0 0
+ 2c800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x1a */
+ 2d000 0 0 1 &i8259 6 2
+ 2d000 0 0 2 &i8259 3 2
+ 2d000 0 0 3 &i8259 4 2
+ 2d000 0 0 4 &i8259 5 2
+
+ /* IDSEL 0x1b */
+ 2d800 0 0 1 &i8259 5 2
+ 2d800 0 0 2 &i8259 0 0
+ 2d800 0 0 3 &i8259 0 0
+ 2d800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x1c */
+ 2e000 0 0 1 &i8259 9 2
+ 2e000 0 0 2 &i8259 a 2
+ 2e000 0 0 3 &i8259 b 2
+ 2e000 0 0 4 &i8259 7 2
+
+ /* IDSEL 0x1d */
+ 2e800 0 0 1 &i8259 9 2
+ 2e800 0 0 2 &i8259 a 2
+ 2e800 0 0 3 &i8259 b 2
+ 2e800 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x1e */
+ 2f000 0 0 1 &i8259 b 2
+ 2f000 0 0 2 &i8259 0 0
+ 2f000 0 0 3 &i8259 0 0
+ 2f000 0 0 4 &i8259 0 0
+
+ /* IDSEL 0x1f */
+ 2f800 0 0 1 &i8259 6 2
+ 2f800 0 0 2 &i8259 0 0
+ 2f800 0 0 3 &i8259 0 0
+ 2f800 0 0 4 &i8259 0 0
+ >;
+ };
+ };
+
+
isa@f0 {
device_type = "isa";
#interrupt-cells = <2>;
@@ -335,7 +454,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <9000 1000>;
- bus-range = <0 ff>;
+ bus-range = <3 ff>;
ranges = <02000000 0 a0000000 a0000000 0 20000000
01000000 0 00000000 e3000000 0 00100000>;
clock-frequency = <1fca055>;
Index: linux-2.6-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
===================================================================
--- linux-2.6-8641.orig/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ linux-2.6-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -419,8 +419,12 @@ mpc86xx_hpcn_setup_arch(void)
}
#ifdef CONFIG_PCI
- for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
- add_bridge(np);
+ for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;) {
+ struct device_node *parent = of_get_parent(np);
+ if (strcmp(parent->type, "pci"))
+ add_bridge(np);
+ of_node_put(parent);
+ }
ppc_md.pci_exclude_device = mpc86xx_exclude_device;
#endif
^ permalink raw reply
* [PATCH] Fix drivers/rtc/Kconfig for powerpc
From: Wade Farnsworth @ 2007-05-15 16:53 UTC (permalink / raw)
To: rtc-linux; +Cc: linuxppc-dev
The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This makes
drivers/rtc/Kconfig to use the correct config option.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-8641/drivers/rtc/Kconfig
===================================================================
--- linux-2.6-8641.orig/drivers/rtc/Kconfig
+++ linux-2.6-8641/drivers/rtc/Kconfig
@@ -246,7 +246,7 @@ comment "Platform RTC drivers"
config RTC_DRV_CMOS
tristate "PC-style 'CMOS'"
depends on RTC_CLASS && (X86 || ALPHA || ARM26 || ARM \
- || M32R || ATARI || POWERPC || MIPS)
+ || M32R || ATARI || PPC || MIPS)
help
Say "yes" here to get direct support for the real time clock
found in every PC or ACPI-based system, and some other boards.
^ permalink raw reply
* Re: Fix bug adding properties with flatdevtree.c's ft_set_prop()
From: Scott Wood @ 2007-05-15 17:49 UTC (permalink / raw)
To: Paul Mackerras, Mark A. Greer, linuxppc-dev
In-Reply-To: <20070514031357.GM6517@localhost.localdomain>
On Mon, May 14, 2007 at 01:13:57PM +1000, David Gibson wrote:
> ft_set_prop() from flatdevtree.c in the zImage wrapper will either
> replace an existing property in the flat device tree, or add a new
> property definiion if the given property isn't present.
>
> However, when adding properties, it adds the property definition
> immediately before the node's END_NODE tag, potentially after any
> subnode definitions for the node. This confuses the kernel flat tree
> parser in prom.c which assumes that all property definitions for a
> node come before all subnode definitions.
>
> This patch corrects ft_set_prop() so that it adds new properties
> before the first subnode, instead of before the END_NODE tag.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Andrei Konovalov @ 2007-05-15 18:07 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0705151430120.7758-100000@slslc02.psi.ch>
Miroslaw Dach wrote:
>>> [ 9.357642] Freeing unused kernel memory: 96k init
>> Any NFS timeouts after reaching this point? Any network activity at all?
>> (NFS timeout is quite long, so waiting few minutes would make sense)
>
> I have monitored the network activity on the NFS server with program
> ethereal. It seems to be that the root file system is mounted. There are
> packet sent from a to my xilinx board. The /var/log/messages contains also
> the entry that mount was done successfully. When init is executed the
> ethereal show only individual packets which are sent (in fixed interval of
> time - once per 20 seconds) from the NFS server to the client but client
> seem to be dead. Even ping does not reach my xilinx board when kernel
> executes the init.
Hmm...
IIRC TEMAC is configured in FIFO mode.
And I thought the problem could be due to small FIFOs. So that the default
NFS reply of 4kbytes could not fit into the receive FIFO, and the CPU is not
fast enough to read the reply out of the FIFO before it overflows.
But your observations don't seem to confirm this is the case.
Anyway, you could try adding
nfsroot=,rsize=1024,wsize=1024
to your cmdline just in case...
Thanks,
Andrei
> I think that the best prove that the rootfile system is properly mounted
> is the fact that my own test init function (which substitutes the real
> init) which simply prints the string to the console does that what is
> expected to do. The real init unfortunately does not print anything to the
> console.
>
> Best Regards
>
> Mirek
>
^ permalink raw reply
* Re: Fix bug adding properties with flatdevtree.c's ft_set_prop()
From: Mark A. Greer @ 2007-05-15 18:08 UTC (permalink / raw)
To: Paul Mackerras, Mark A. Greer, linuxppc-dev
In-Reply-To: <20070514031357.GM6517@localhost.localdomain>
On Mon, May 14, 2007 at 01:13:57PM +1000, David Gibson wrote:
> ft_set_prop() from flatdevtree.c in the zImage wrapper will either
> replace an existing property in the flat device tree, or add a new
> property definiion if the given property isn't present.
>
> However, when adding properties, it adds the property definition
> immediately before the node's END_NODE tag, potentially after any
> subnode definitions for the node. This confuses the kernel flat tree
> parser in prom.c which assumes that all property definitions for a
> node come before all subnode definitions.
Oops. :)
> This patch corrects ft_set_prop() so that it adds new properties
> before the first subnode, instead of before the END_NODE tag.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Mark A. Greer <mgreer@mvista.com>
^ permalink raw reply
* Re: Fix bug adding properties with flatdevtree.c's ft_set_prop()
From: Mark A. Greer @ 2007-05-15 18:11 UTC (permalink / raw)
To: Scott Wood, Paul Mackerras, Mark A. Greer, linuxppc-dev
In-Reply-To: <20070515002648.GA31585@localhost.localdomain>
On Tue, May 15, 2007 at 10:26:48AM +1000, David Gibson wrote:
> On Mon, May 14, 2007 at 11:28:16AM -0500, Scott Wood wrote:
> > On Mon, May 14, 2007 at 01:13:57PM +1000, David Gibson wrote:
> > > This patch corrects ft_set_prop() so that it adds new properties
> > > before the first subnode, instead of before the END_NODE tag.
> >
> > Is there any reason not to just insert at the beginning of the node?
>
> Only that we have to search through the node first to see if the
> property already exists, so we've already reached the end by the time
> we know we need to insert.
David, Jon,
Does dtc guarantee that there aren't any properties after a subnode?
Mark
^ permalink raw reply
* Help need for WindRiver EST SBC8260 Board
From: techie mj @ 2007-05-15 18:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Hi All,
For my project work(Packet filter) we are planning to buy a used WindRiver
EST SBC8260 board.
I am new to this. So i request everyone to suggest me what i should look for
while buying the board.My development environment will be LINUX may be
vxworks in future.
1) My dealer is providing only the Board. ( 4MB-SIMM flash,16MB-SDRAM DIMM,
8kb- 8 bit EEPROM, 2MB- 8 bit Flash, 4MB SDRAM (Local Bus), RS-232, 10/100
Base-TX Ethernet)
Is it enough -or whether i need any extra addon cards
2) Do i need to buy JTAG debugger or any
Is it possible to debug the code without JTAG/BDM
3) what are the cables i need
4) Can i directly download the bootcode from my PC to the Board through
ethernet/serial port
5) Can anyone provide me the user manual for the above board. any weblinks
are also good
6) any other points
Thanks
mjose
[-- Attachment #2: Type: text/html, Size: 1331 bytes --]
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: Mark A. Greer @ 2007-05-15 18:15 UTC (permalink / raw)
To: david; +Cc: linuxppc-dev
In-Reply-To: <20070514045404.GP6517@localhost.localdomain>
On Mon, May 14, 2007 at 02:54:04PM +1000, David Gibson wrote:
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-08 15:07:45.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:38:39.000000000 +1000
> @@ -33,8 +33,8 @@
> timebase-frequency = <0>; // Filled in by zImage
> i-cache-line-size = <32>;
> d-cache-line-size = <32>;
> - i-cache-size = <0>;
> - d-cache-size = <0>;
> + i-cache-size = <2000000>; /* 32 kB */
> + d-cache-size = <2000000>; /* 32 kB */
> dcr-controller;
> dcr-access-method = "native";
> };
Ahh HA! You did it too! :)
^ permalink raw reply
* Re: [PATCH] powerpc: add dts entries to 85xx for EDAC
From: Kumar Gala @ 2007-05-15 18:20 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070510170305.GA16203@blade.az.mvista.com>
On Thu, 10 May 2007, Dave Jiang wrote:
> Adding memory-controller and l2-cache-controller entries to be used by EDAC
> as of_devices.
>
> Signed-off-by: Dave Jiang <djiang@mvista.com>
>
> ---
>
> Fixed up additional changes per Kumar.
>
> arch/powerpc/boot/dts/mpc8540ads.dts | 16 ++++++++++++++++
> arch/powerpc/boot/dts/mpc8548cds.dts | 16 ++++++++++++++++
> arch/powerpc/boot/dts/mpc8560ads.dts | 18 +++++++++++++++++-
> 3 files changed, 49 insertions(+), 1 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: fix alignment problem in rh_alloc_align() with exact-sized blocks
From: Kumar Gala @ 2007-05-15 18:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1179160286213-git-send-email-timur@freescale.com>
On Mon, 14 May 2007, Timur Tabi wrote:
> When an rheap is created, the caller can specify the alignment to use. In
> rh_alloc_align(), if a free block is found that is the exact size needed
> (including extra space for alignment), that configured alignment value is not
> used to align the pointer. Instead, the default alignment is used. If the
> default alignment is smaller than the configured alignment, then the returned
> value will not be aligned correctly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/lib/rheap.c | 22 ++++++++--------------
> 1 files changed, 8 insertions(+), 14 deletions(-)
>
applied.
- k
^ 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