Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Fri, 2009-04-17 at 11:26 +0300, Artem Bityutskiy wrote: > > I'm going to try to help you. I've just created a git tree where > I'll push patches I consider OK and I approve. Here it is: > git://git.infradead.org/users/dedekind/l2-mtd-2.6.git > > My hope is that you would look at that tree from time to time > and pull it. At least you may be sure I looked at the patches and > did some validation. This should save your time and help MTD > users. This was _really_ useful. Thank you very much. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote: > Create an of-aware driver using the now exported generic functions from > plat-ram.c. Also add the documentation for the binding. Partitions are > not yet supported. Tested on a phyCORE-MPC5200B-IO. Do we have an ack for the device-tree bindings? It _would_ be possible to hook up RAM through the existing of_physmap driver, I think -- although it would be slightly less efficient that way. Maybe cleaner from the device-tree POV though. And if we want to put a special case in the _code_ to make it more efficient, we can do that. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mailing list moving
On Fri, 2009-06-05 at 19:08 +1000, Stephen Rothwell wrote: > Hi Michael, > > On Fri, 05 Jun 2009 17:38:40 +1000 Michael Ellerman > wrote: > > > > On Fri, 2009-06-05 at 17:26 +1000, Stephen Rothwell wrote: > > > Hi all, > > > > > > On Sun, 31 May 2009 15:09:50 +1000 Stephen Rothwell > > > wrote: > > > > > > The archives on lists.ozlabs.org (and ozlabs.org) have unfortunately not > > > retained their URLs (the basename of the article URLs changed). > > > > Would a rewrite rule fix it? It'd be nice for them to keep working. > > No, because the actual article numbers changed when I rebuilt the archive > on the new server. > > Sorry. > > I do, however, have the old archives, so maybe we can do something ... We could use the old archive to work out the mapping between old and new and write a billion rewrite rules, but it'd probably crash the rewrite code - and if not slow the server to a crawl. So into the too hard basket I think :) cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
On Sat, Jun 06, 2009 at 09:14:08AM +0100, David Woodhouse wrote:
> On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. Also add the documentation for the binding. Partitions are
> > not yet supported. Tested on a phyCORE-MPC5200B-IO.
>
> Do we have an ack for the device-tree bindings?
>
> It _would_ be possible to hook up RAM through the existing of_physmap
> driver, I think -- although it would be slightly less efficient that
> way.
>
> Maybe cleaner from the device-tree POV though. And if we want to put a
> special case in the _code_ to make it more efficient, we can do that.
During development, I also checked physmap_of.c and found this binding:
{
.type = "rom",
.compatible = "direct-mapped"
},
which made some sense to me and I thought about .type = "ram". However, I then
found this in the code:
/* Helper function to handle probing of the obsolete "direct-mapped"
* compatible binding, which has an extra "probe-type" property
* describing the type of flash probe necessary. */
static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
struct map_info *map)
{
[...]
dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
"flash binding\n");
My conclusion was then that a mtd-ram binding wouldn't belong here, but I have
maybe misinterpreted things...
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Missing some interrupts
Hi All, i have a freescale board, that contains MPC8555 processor & DSP-core there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of the MPC8555 processor. i test one interrupt from the DSP-core to the MPC8555 processor where i configure this interrupt line to be edge-triggered (falling edge) & i receive it successfully but when i generate this interrupt 10 successive times using for loop i just receive 2 interrupts? why can't i receive the 8 other interrupts? i print the value of every irq number inside do_IRQ & i found that i receive the DSP-interrupt just only twice. do u have any suggestions to solve this problem? i want to make sure that i can receive 10 interrupts -- View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
On Sat, Jun 6, 2009 at 9:17 AM, wael showair wrote: > > Hi All, > i have a freescale board, that contains MPC8555 processor & DSP-core > there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of > the MPC8555 processor. > > i test one interrupt from the DSP-core to the MPC8555 processor where i > configure this interrupt line to be edge-triggered (falling edge) & i > receive it successfully > but > when i generate this interrupt 10 successive times using for loop > i just receive 2 interrupts? > > why can't i receive the 8 other interrupts? > i print the value of every irq number inside do_IRQ & i found that i receive > the DSP-interrupt just only twice. > > do u have any suggestions to solve this problem? > i want to make sure that i can receive 10 interrupts Don't do a printk() with interrupts disabled. A printk() takes 1.5ms on a mpc5200. > -- > View this message in context: > http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html > Sent from the linuxppc-dev mailing list archive at Nabble.com. > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Saturday 06 June 2009, Greg KH wrote: > Frank and Ian, any thoughts about the vmap call in the > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what > is the prealloc_buf buffer used for? It is a circular buffer used to hold data streaming either to or from a board (for example when producing an analog output waveform). Reads and writes to the device files read/write to the circular buffer, plus a few drivers do dma directly to/from it. I personally don't have a problem with requiring drivers to have their own dma buffers and making them copy data between their private dma buffers and the main circular buffer. I guess the original design wanted to support zero-copy dma. signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SD card over (xilinx_)SPI, timeout error while CID
> "Joachim" == Joachim Foerster writes: Hi, Joachim> Any hints? Does anybody use SD card support with Joachim> mmc_spi+xilinx_spi ? I don't, but have you compared the spi signals on a scope in the 2 setups? Is timing significantly different? -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
On Fri, Jun 5, 2009 at 6:05 AM, Wolfram Sang wrote: > diff --git a/Documentation/powerpc/dts-bindings/mtd-ram.txt > b/Documentation/powerpc/dts-bindings/mtd-ram.txt > new file mode 100644 > index 000..a2e9932 > --- /dev/null > +++ b/Documentation/powerpc/dts-bindings/mtd-ram.txt > @@ -0,0 +1,18 @@ > +RAM emulating an MTD > + > +An external RAM like SRAM or FRAM can also be treated as an MTD. > + > + - compatible : should contain the specific model of the RAM chip > + used, if known, followed by "mtd-ram". > + - reg : Address range of the RAM chip > + - bank-width : Width (in bytes) of the RAM bank. Question: why is bank-width even relevant for a RAM device? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
Am 06.06.09 18:05 schrieb(en) Grant Likely: > + - bank-width : Width (in bytes) of the RAM bank. Question: why is bank-width even relevant for a RAM device? At least if the RAM is attached to the 5200's Local Plus Bus in 16-bit mode, no byte write accesses are allowed (byte /reads/ work, though). I have a tweak (which I will post next week) to address this case, which depends upon this setting. No idea if the same happens on other chips and/or on 5200 in 32-bit (muxed) mode, but I guess similar effects will pop up there, too. Cheers, Albrecht. pgpcv5MnhXQZ1.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
The PCIe MSI interrupts are missing from the device tree source, and
thus were not enabled. This patch adds them.
v2 of the patch fixes inconsistent white space, reported by David Gibson.
Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
Signed-off-by: Leon Woestenberg
Tested-by: Leon Woestenberg
Index: git/arch/powerpc/boot/dts/mpc8315erdb.dts
===
--- git.orig/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-05-23
20:49:40.0 +0200
+++ git/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-06-06 10:35:14.0
+0200
@@ -322,6 +322,21 @@
reg = <0x700 0x100>;
device_type = "ipic";
};
+
+ ipic-...@7c0 {
+ compatible = "fsl,ipic-msi";
+ reg = <0x7c0 0x40>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8>;
+ interrupt-parent = < &ipic >;
+ };
};
pci0: p...@e0008500 {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull -next branch from git.secretlab.ca
Hi Ben, Here are some new commits to support the Xilinx ML507 board for 2.6.31 The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d: Stephen Rothwell (1): powerpc/pci: Fix annotation of pcibios_claim_one_bus are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next Grant Likely (1): powerpc/virtex: refactor intc driver and add support for i8259 cascading Roderick Colenbrander (3): powerpc/virtex: Add support for Xilinx PCI host bridge powerpc/virtex: Add Xilinx ML510 reference design support powerpc/virtex: Add ml510 reference design device tree arch/powerpc/boot/dts/virtex440-ml510.dts | 465 + arch/powerpc/include/asm/xilinx_pci.h | 21 ++ arch/powerpc/platforms/40x/virtex.c |2 + arch/powerpc/platforms/44x/Kconfig| 13 +- arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/virtex.c |2 + arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++ arch/powerpc/platforms/Kconfig|4 + arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/xilinx_intc.c | 81 -- arch/powerpc/sysdev/xilinx_pci.c | 132 11 files changed, 732 insertions(+), 19 deletions(-) create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts create mode 100644 arch/powerpc/include/asm/xilinx_pci.h create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c create mode 100644 arch/powerpc/sysdev/xilinx_pci.c -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Remove machine_is(chrp) from 64-bit kernel
The CHRP platform type only exists in a 32-bit build. Don't bother
checking machine_is(chrp) if we're in 64-bit mode.
Signed-off-by: David Woodhouse
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 45936c9..c22f7e8 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
+#ifdef CONFIG_PPC32
if (machine_is(chrp))
return -1;
-
+#endif
np = of_find_node_by_name(NULL, "valkyrie");
if (np)
of_platform_device_create(np, "valkyrie", NULL);
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/install: Bail with error code on error in install script
From: Grant Likely
If anything goes wrong when copying images into the install path, then
the install script should exit with an error code so that 'make' knows
about it and tells the user.
Signed-off-by: Grant Likely
---
arch/powerpc/boot/install.sh |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index 51b2387..98312d1 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -18,6 +18,9 @@
# $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc.
#
+# Bail with error code if anything goes wrong
+set -e
+
# User may have a custom install script
if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec
~/bin/${CROSS_COMPILE}installkernel "$@"; fi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/install: Bail with error code on error in install script
Oops, forgot one. Here is a new request including the xilinxfb refactoring:
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascading
John Linn (1):
fbdev: Add PLB support and cleanup DCR in xilinxfb driver.
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c |2 +
arch/powerpc/platforms/44x/Kconfig| 13 +-
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/virtex.c |2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig|4 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 --
arch/powerpc/sysdev/xilinx_pci.c | 132
drivers/video/xilinxfb.c | 290 ++-
12 files changed, 883 insertions(+), 158 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
On Sat, Jun 6, 2009 at 10:39 AM, Grant Likely wrote:
> From: Grant Likely
>
> If anything goes wrong when copying images into the install path, then
> the install script should exit with an error code so that 'make' knows
> about it and tells the user.
>
> Signed-off-by: Grant Likely
> ---
>
> arch/powerpc/boot/install.sh | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
> index 51b2387..98312d1 100644
> --- a/arch/powerpc/boot/install.sh
> +++ b/arch/powerpc/boot/install.sh
> @@ -18,6 +18,9 @@
> # $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc.
> #
>
> +# Bail with error code if anything goes wrong
> +set -e
> +
> # User may have a custom install script
>
> if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec
> ~/bin/${CROSS_COMPILE}installkernel "$@"; fi
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
On Sat, Jun 6, 2009 at 7:34 AM, Jon Smirl wrote: > On Sat, Jun 6, 2009 at 9:17 AM, wael showair wrote: >> >> Hi All, >> i have a freescale board, that contains MPC8555 processor & DSP-core >> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of >> the MPC8555 processor. >> >> i test one interrupt from the DSP-core to the MPC8555 processor where i >> configure this interrupt line to be edge-triggered (falling edge) & i >> receive it successfully >> but >> when i generate this interrupt 10 successive times using for loop >> i just receive 2 interrupts? >> >> why can't i receive the 8 other interrupts? >> i print the value of every irq number inside do_IRQ & i found that i receive >> the DSP-interrupt just only twice. >> >> do u have any suggestions to solve this problem? >> i want to make sure that i can receive 10 interrupts > > Don't do a printk() with interrupts disabled. A printk() takes 1.5ms > on a mpc5200. Look at /proc/interrupts instead to see how many IRQs are received. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
Benjamin Herrenschmidt wrote: No, Mel's patch is for a different problem and has been fixed upstream already. This is more concerning... I'm not sure what's up but would you be able to send a disassembly of the hpte_need_flush() function in your kernel binary for me to see what access precisely caused the fault ? Was able to recreate this with git3 kernel. Here is the disassembly shm-fork 10 10 (64):PASS shm-fork 10 20 (32):cpu 0x1: Vector: 300 (Data Access) at [c000faa13490] pc: c0038240: .hpte_need_flush+0x1bc/0x2d8 lr: c00380f0: .hpte_need_flush+0x6c/0x2d8 sp: c000faa13710 msr: 80009032 dar: c0005e5e0480 dsisr: 4000 current = 0xc000f9bde3e0 paca= 0xc0b72600 pid = 12152, comm = shm-fork enter ? for help [c000faa13710] c0038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable) [c000faa137d0] c0039fa4 .huge_ptep_get_and_clear+0x40/0x5c [c000faa13850] c012d044 .__unmap_hugepage_range+0x178/0x2b8 [c000faa13940] c012d1d8 .unmap_hugepage_range+0x54/0x88 [c000faa139e0] c0116f78 .unmap_vmas+0x178/0x8f4 [c000faa13b30] c011c690 .unmap_region+0xfc/0x1e4 [c000faa13c00] c011de20 .do_munmap+0x2f4/0x38c [c000faa13cc0] c02f6a08 .SyS_shmdt+0xc0/0x188 [c000faa13d70] c000c430 .sys_ipc+0x274/0x2fc [c000faa13e30] c0008534 syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 0421d2dc SP (fffee026010) is in userspace 1:mon> di $.hpte_need_flush c0038084 fac1ffb0 std r22,-80(r1) c0038088 7c0802a6 mflrr0 c003808c f8010010 std r0,16(r1) c0038090 2fa7 cmpdi cr7,r7,0 c0038094 fb21ffc8 std r25,-56(r1) c0038098 6cc01000 xoris r0,r6,4096 c003809c fb41ffd0 std r26,-48(r1) c00380a0 7cd93378 mr r25,r6 c00380a4 fb61ffd8 std r27,-40(r1) c00380a8 7cb62b78 mr r22,r5 c00380ac fb81ffe0 std r28,-32(r1) . . 1:mon> c0038204 38090001 addir0,r9,1 c0038208 78004602 rldicl r0,r0,40,24 c003820c 7c004a14 add r0,r0,r9 c0038210 78090220 clrldi r9,r0,40 c0038214 2fbd cmpdi cr7,r29,0 c0038218 409e0010 bne cr7,c0038228# .hpte_need_flush+0x1a4/0x2d8 c003821c 7929e0e4 rldicr r9,r9,28,35 c0038220 7be00120 clrldi r0,r31,36 c0038224 480c b c0038230# .hpte_need_flush+0x1ac/0x2d8 c0038228 792945c6 rldicr r9,r9,40,23 c003822c 7be00600 clrldi r0,r31,24 c0038230 7d3f0378 or r31,r9,r0 c0038234 7c1cb82e lwzxr0,r28,r23 c0038238 3d360001 addis r9,r22,1 c003823c 2f80 cmpwi cr7,r0,0 c0038240 eb898000 ld r28,-32768(r9) <<== +0x1bc should be this 1:mon> r R00 = R16 = 23aa4db0 R01 = c000faa13710 R17 = R02 = c0a9d788 R18 = 9010 R03 = 0004 R19 = R04 = 03fff000 R20 = R05 = c0005e5d8480 R21 = 0400 R06 = 364008000393 R22 = c0005e5d8480 R07 = 0001 R23 = 0075 R08 = 0004 R24 = R09 = c0005e5e8480 R25 = 364008000393 R10 = 0003fff0 R26 = c000673f0680 R11 = 0280 R27 = 0004 R12 = 44022422 R28 = c0890430 R13 = c0b72600 R29 = 0001 R14 = R30 = c0fe0430 R15 = R31 = 8812ebfff000 pc = c0038240 .hpte_need_flush+0x1bc/0x2d8 lr = c00380f0 .hpte_need_flush+0x6c/0x2d8 msr = 80009032 cr = 44022422 ctr = c025cc28 xer = 0001 trap = 300 dar = c0005e5e0480 dsisr = 4000 1:mon> Have attached the complete disassembly. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - shm-fork 10 10 (64):PASS shm-fork 10 20 (32):cpu 0x1: Vector: 300 (Data Access) at [c000faa13490] pc: c0038240: .hpte_need_flush+0x1bc/0x2d8 lr: c00380f0: .hpte_need_flush+0x6c/0x2d8 sp: c000faa13710 msr: 80009032 dar: c0005e5e0480 dsisr: 4000 current = 0xc000f9bde3e0 paca= 0xc0b72600 pid = 12152, comm = shm-fork enter ? for help [c000faa13710] c0038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable) [c000faa137d0] c0039fa4 .huge_ptep_get_and_clear+0x40/0x5c [c000faa13850] c012d044 .__unmap_hugepage_range+0x178/0x2b8 [c000faa13940] c012d
Re: [PATCH] Remove machine_is(chrp) from 64-bit kernel
On Sat, 2009-06-06 at 17:38 +0100, David Woodhouse wrote:
> The CHRP platform type only exists in a 32-bit build. Don't bother
> checking machine_is(chrp) if we're in 64-bit mode.
>
> Signed-off-by: David Woodhouse
Isn't the test bogus anyway ? It should be if (!machine_is(powermac))
but is useless since the function is called via:
machine_device_initcall(powermac, pmac_declare_of_platform_devices);
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/powermac/setup.c
> b/arch/powerpc/platforms/powermac/setup.c
> index 45936c9..c22f7e8 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
> {
> struct device_node *np;
>
> +#ifdef CONFIG_PPC32
> if (machine_is(chrp))
> return -1;
> -
> +#endif
> np = of_find_node_by_name(NULL, "valkyrie");
> if (np)
> of_platform_device_create(np, "valkyrie", NULL);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Enable additional BAT registers in setup_745x_specifics()
Currently the kernel expects the additional four IBAT and DBAT registers to be available, but doesn't enable these registers on 745x CPUs, which have them disabled after reset. Thus set the HIGH_BAT_EN bit in HID0 register, if the corresponding MMU feature is defined. Signed-off-by: Gerhard Pircher --- arch/powerpc/kernel/cpu_setup_6xx.S |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S index 54f767e..1e9949e 100644 --- a/arch/powerpc/kernel/cpu_setup_6xx.S +++ b/arch/powerpc/kernel/cpu_setup_6xx.S @@ -239,6 +239,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR) ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE ori r11,r11,HID0_LRSTK | HID0_BTIC orisr11,r11,hid0_...@h +BEGIN_MMU_FTR_SECTION + orisr11,r11,hid0_high_...@h +END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS) BEGIN_FTR_SECTION xorir11,r11,HID0_BTIC END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC) -- 1.5.6.5 -- GMX FreeDSL mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.! http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: how can i send real-time signal?
Am Fri, 5 Jun 2009 10:41:56 -0700 (PDT) schrieb wael showair : > My aim is : Each time the DSP-core interrupts the MPC8555 processor, a > process in the user space will be informed by the arrival of this each > interrupt. You should have a look at drivers/uio... > So i decided to use sw signals, in the ISR of the DSP-core interrupt > i send a SW signal to the user space process? Is this the best > solution? are there any better suggestion to achieve my aim? signals are expensive. Look at the UIO-Framework for a cheaper solution. preallocated RT-Signals on the other Hand are fragile. Blocking reads are cheaper and in case of preempt-RT, but not resticted to it, much easier to handle. Bene ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
Dear David Jander, In message <200903161652.09747.david.jan...@protonic.nl> you wrote: > Complete workaround for DTLB errata in e300c2/c3/c4 processors. > > Due to the bug, the hardware-implemented LRU algorythm always goes to way > 1 of the TLB. This fix implements the proposed software workaround in > form of a LRW table for chosing the TLB-way. > > Signed-off-by: Kumar Gala > Signed-off-by: David Jander What is the actual status of this patch? Patchwork (http://patchwork.ozlabs.org/patch/24502/) says it's "superseded" - but by what? I can't see such code in mainline - what happened to it? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One essential to success is that you desire be an all-obsessing one, your thoughts and aims be co-ordinated, and your energy be concentra- ted and applied without letup. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Dear John,
In message <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038...@mail.gmail.com> you
wrote:
>
> I think the fec's parent clock is the ipb clock not the ppc core clock.
> Could that be the problem?
I don't think so.
When debugging, I printed the actual clock frequencies, and they
looked as expected. And "arch/powerpc/platforms/512x/clock.c" has
this:
385 static struct clk fec_clk = {
386 .name = "fec_clk",
387 .flags = CLK_HAS_CTRL,
388 .reg = 0,
389 .bit = 13,
390 .calc = unity_clk_calc,
391 .parent = &ips_clk,
392 };
which looks OK to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The human mind ordinarily operates at only ten percent of its
capacity. The rest is overhead for the operating system.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
On Sun, 2009-06-07 at 00:07 +0200, Wolfgang Denk wrote: > Dear David Jander, > > In message <200903161652.09747.david.jan...@protonic.nl> you wrote: > > Complete workaround for DTLB errata in e300c2/c3/c4 processors. > > > > Due to the bug, the hardware-implemented LRU algorythm always goes to way > > 1 of the TLB. This fix implements the proposed software workaround in > > form of a LRW table for chosing the TLB-way. > > > > Signed-off-by: Kumar Gala > > Signed-off-by: David Jander > > What is the actual status of this patch? > > Patchwork (http://patchwork.ozlabs.org/patch/24502/) says it's > "superseded" - but by what? > > I can't see such code in mainline - what happened to it? I can see the code in mainline ... but only in the -data- TLB miss handler, not the instruction one... Kumar ? Shouldn't we have the workaround in both ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
On Sat, 2009-06-06 at 06:17 -0700, wael showair wrote: > Hi All, > i have a freescale board, that contains MPC8555 processor & DSP-core > there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of > the MPC8555 processor. > > i test one interrupt from the DSP-core to the MPC8555 processor where i > configure this interrupt line to be edge-triggered (falling edge) & i > receive it successfully > but > when i generate this interrupt 10 successive times using for loop > i just receive 2 interrupts? > > why can't i receive the 8 other interrupts? > i print the value of every irq number inside do_IRQ & i found that i receive > the DSP-interrupt just only twice. That sounds normal... It all depends what you are doing in the interrupt handler. If you are doing something for too long, you will "miss" some interrupts, but that isn't necessarily a problem. You cannot really rely on getting the exact same number of edge interrupts that were emitted. At least not unless you have a hard RT system and can guarantee that you'll always dequeue them fast enough. Basically, what happens is that in a PIC like the MPIC, if one edge interrupt is latched, and another one arrives before that first one has been acked, then the second one is "subsumed", ie, there's only one input latch. That should however not be a problem if your driver is written properly. The idea is that when you get the interrupt, you need to check your device for -all- the work to do, not only one "item". For example, if the device fills a ring buffer, you need to check for more than one entry in there. The only guarantee you have is that the interrupt will have been acked before your handler is called. So if another interrupt happens while your handler is running, you -will- be called again. So you don't need to worry too much about racing with new incoming messages inside the interrupt handler itself. But you need to be prepared to pick up more than one item of work... whatever that is. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Dear John, in message <4b73d43f0906061527p7ca1b301ybcfc576870a16...@mail.gmail.com> you wrote: > > I noticed the latest BSP from Freescale has this patch: > > From: Chen Hongjun > Date: Thu, 16 Apr 2009 20:22:52 +0800 > Subject: [PATCH] Fixed FEC bug for bluestone board. > > Signed-off-by: Chen Hongjun > --- > drivers/net/fs_enet/mii-fec.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c > index 13a7d66..53d01a8 100644 > --- a/drivers/net/fs_enet/mii-fec.c > +++ b/drivers/net/fs_enet/mii-fec.c > @@ -208,7 +208,7 @@ static int __devinit fs_enet_mdio_probe(struct of_device > *ofdev, > if (!fec->fecp) > goto out_fec; > > - fec->mii_speed = ((ppc_proc_freq + 499) / 500) << 1; > + fec->mii_speed = ppc_proc_freq + 499) / 250) / 2) & 0x3F) > << 1; Heh. So we now have 3 versions: mainline: fec->mii_speed = ((ppc_proc_freq + 499) / 500) << 1; Freescale: fec->mii_speed = ppc_proc_freq + 499) / 250) / 2) & 0x3F) << 1; we: fec->mii_speed = (((ppc_proc_freq / 100) / 30) + 1) << 1; So what does this give: ppc_proc_freq mii_speed mainlinefreescale we -- 50 MHz 0x14 -> 2.5 MHz 0x14 -> 2.5 MHz 0x04 -> 12.50 MHz 100 MHz 0x28 -> 2.5 MHz 0x28 -> 2.5 MHz 0x08 -> 12.50 MHz 150 MHz 0x3C -> 2.5 MHz 0x3C -> 2.5 MHz 0x0C -> 12.50 MHz 200 MHz 0x50 -> 2.5 MHz 0x50 -> 2.5 MHz 0x0E -> 14.29 MHz 250 MHz 0x64 -> 2.5 MHz 0x64 -> 2.5 MHz 0x12 -> 13.89 MHz 300 MHz 0x78 -> 2.5 MHz 0x78 -> 2.5 MHz 0x16 -> 13.36 MHz 316.8 MHz 0x80 -> 2.475 MHz 0x00 -> MDC off 0x16 -> 14.40 MHz 350 MHz 0x8C -> 2.5 MHz 0x0C -> 29.17 MHz 0x18 -> 14.58 MHz 400 MHz 0xA0 -> 2.5 MHz 0x20 -> 12.50 MHz 0x1C -> 14.29 MHz 450 MHz 0xB3 -> 2.5 MHz 0x34 -> 8.654 MHz 0x20 -> 14.06 MHz 500 MHz 0xC8 -> 2.5 MHz 0x48 -> 6.944 MHz 0x22 -> 14.71 MHz So - the mainline version and what we have don't take into account that MII_SPEED uses only bit 25...30, i.e. it must fit into the range from (1 << 1) ... (3F << 1). The Freescale code tries to address this, but just clipping the data is incorrect as we can see above. The funny thing is that the RefMan says: "...MDC frequency of 1/(mii_speed*2) of the system clock frequency" "To be compliant with the IEEE MII specification, the MII_SPEED field must be programmed with a value that provides an MDC frequency of less than or equal to 2.5 MHz." The big question seems to be what the RefMan means when talking about the "system clock frequency". Obiously it is NOT the CPU clock as code variants above assume. The examples in "Table 17-24. Programming Examples for MII_SPEED Register" list "system clock frequencies" of 25, 33, 40 and 50 MHz - which also indiocates that some other frequency might be referenced here. But which one is it? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right', and 'build car'." - John Sladek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
Benjamin Herrenschmidt wrote: > > On Sat, 2009-06-06 at 06:17 -0700, wael showair wrote: >> Hi All, >> i have a freescale board, that contains MPC8555 processor & DSP-core >> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC >> of >> the MPC8555 processor. >> >> i test one interrupt from the DSP-core to the MPC8555 processor where i >> configure this interrupt line to be edge-triggered (falling edge) & i >> receive it successfully >> but >> when i generate this interrupt 10 successive times using for loop >> i just receive 2 interrupts? >> >> why can't i receive the 8 other interrupts? >> i print the value of every irq number inside do_IRQ & i found that i >> receive >> the DSP-interrupt just only twice. > > That sounds normal... It all depends what you are doing in the interrupt > handler. If you are doing something for too long, you will "miss" some > interrupts, but that isn't necessarily a problem. > > You cannot really rely on getting the exact same number of edge > interrupts that were emitted. At least not unless you have a hard RT > system and can guarantee that you'll always dequeue them fast enough. > > Basically, what happens is that in a PIC like the MPIC, if one edge > interrupt is latched, and another one arrives before that first one has > been acked, then the second one is "subsumed", ie, there's only one > input latch. > > That should however not be a problem if your driver is written properly. > The idea is that when you get the interrupt, you need to check your > device for -all- the work to do, not only one "item". For example, if > the device fills a ring buffer, you need to check for more than one > entry in there. > > The only guarantee you have is that the interrupt will have been acked > before your handler is called. So if another interrupt happens while > your handler is running, you -will- be called again. > > So How can i achieve this? how can i ack the interrupt b 4 calling the > handler? > > So you don't need > to worry too much about racing with new incoming messages inside the > interrupt handler itself. But you need to be prepared to pick up more > than one item of work... whatever that is. > > Cheers, > Ben. > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > > -- View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23906763.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing some interrupts
> > You cannot really rely on getting the exact same number of edge > > interrupts that were emitted. At least not unless you have a hard RT > > system and can guarantee that you'll always dequeue them fast enough. > > Yes, my system is a hard RT & i want to receive all the interrupts that > have been generated exactly No. Linux is not hard RT. You cannot rely on this in a reliable way, if for any reason the kernel masks interrupt for too long, which can happen, you'll see that sort of coalescing happening. If you -really- can't do anything else, then use critical interrupts but there is little if no support at all for them in linux. It's your model that is wrong, you should be able to "poll" the device for how much work (or interrupts) have been sent and react accordingly regardless of how many actual IRQ triggers came in via the OpenPIC. > so who is responsible for acking the interrupt? At the PIC level, they are acked by the core just before calling into your handler. > is there any API in the kernel should i call to do this ack? or > it is something Dependant on the device that generates the interrupt? The PIC-level ack is done for you. I don't know what your DSP does. > Actaully, the device in my case which is a DSP-core is toggles the > outpin pin of its GPIO that is connected to the input pin of the > OpenPIC, so how can > i ack this device? do u have any suggestions? The Ack isn't your problem. Your model is wrong if you design assuming you will receive all edge interrupts. Being careful about latencies etc... (and making sure you toggle for long enough, btw, didn't think about that one, check your MPIC specs) may improve how many of them you actually receive, -but- you cannot guarantee that you'll get them all, so even if you somewhat manager into most of your tests to get 100%, you'll still have an unreliable system. You must design your communication between the DSP and Linux such that the interrupt is purely a wakeup call indicating there's work to do, and some -other- mean for Linux to actually know how much work is to be done, the actual number of interrupts is not a proper way to do so. > So how can i achieve this step? how can i ack the interrupt b 4 i call > the handler? where can i do this in the kernel? The kernel does it for you as I said. It's your communication model that is flawed. Never -ever- rely on edge interrupts in ways that require them not to be coalesced. Cheers, Ben. > >So you don't need to worry too much about racing with new incoming > messages inside the > > interrupt handler itself. But you need to be prepared to pick up more > > than one item of work... whatever that is. > > > > Cheers, > > Ben. > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > > > Quoted from: > http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html -- View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23906859.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: how can i send real-time signal?
Am Fri, 5 Jun 2009 10:41:56 -0700 (PDT) schrieb wael showair : > My aim is : Each time the DSP-core interrupts the MPC8555 processor, a > process in the user space will be informed by the arrival of this each > interrupt. You should have a look at drivers/uio... > So i decided to use sw signals, in the ISR of the DSP-core interrupt > i send a SW signal to the user space process? Is this the best > solution? are there any better suggestion to achieve my aim? signals are expensive. Look at the UIO-Framework for a cheaper solution. preallocated RT-Signals on the other Hand are fragile. Blocking reads are cheaper and in case of preempt-RT, but not resticted to it, much easier to handle. Bene -- View this message in context: http://www.nabble.com/how-can-i-send-real-time-signal--tp23892580p23906892.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
I noticed the latest BSP from Freescale has this patch:
From: Chen Hongjun
Date: Thu, 16 Apr 2009 20:22:52 +0800
Subject: [PATCH] Fixed FEC bug for bluestone board.
Signed-off-by: Chen Hongjun
---
drivers/net/fs_enet/mii-fec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 13a7d66..53d01a8 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -208,7 +208,7 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec->fecp)
goto out_fec;
- fec->mii_speed = ((ppc_proc_freq + 499) / 500) << 1;
+ fec->mii_speed = ppc_proc_freq + 499) / 250) / 2) &
0x3F) << 1;
setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
--
1.5.4
On Sat, Jun 6, 2009 at 4:16 PM, Wolfgang Denk wrote:
> Dear John,
>
> In message <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038...@mail.gmail.com>
> you wrote:
> >
> > I think the fec's parent clock is the ipb clock not the ppc core clock.
> > Could that be the problem?
>
> I don't think so.
>
> When debugging, I printed the actual clock frequencies, and they
> looked as expected. And "arch/powerpc/platforms/512x/clock.c" has
> this:
>
> 385 static struct clk fec_clk = {
> 386 .name = "fec_clk",
> 387 .flags = CLK_HAS_CTRL,
> 388 .reg = 0,
> 389 .bit = 13,
> 390 .calc = unity_clk_calc,
> 391 .parent = &ips_clk,
> 392 };
>
> which looks OK to me.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> The human mind ordinarily operates at only ten percent of its
> capacity. The rest is overhead for the operating system.
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
> > > > The big question seems to be what the RefMan means when talking about > the "system clock frequency". Obiously it is NOT the CPU clock as > code variants above assume. The examples in "Table 17-24. Programming > Examples for MII_SPEED Register" list "system clock frequencies" of > 25, 33, 40 and 50 MHz - which also indiocates that some other > frequency might be referenced here. > > But which one is it? My best guess is still that it is ips clock. I think I stated in a previous email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked at he MII clock on a scope to see how the calculated values compare to actual? > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "Today's robots are very primitive, capable of understanding only a > few simple instructions such as 'go left', 'go right', and 'build > car'." - John Sladek > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
