[PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
The iSeries viodasd drivers does some very strange things with
scatterlists, one of these causing a BUG_ON to trigger when
scatterlist debugging is enabled due to initializing the
scatterlist with memset instead of sg_init_table().
This fixes it by using sg_init_table(). The rest of the stuff
it does to that poor list is still pretty awful but it will work.
I may look into fixing things in a nicer way some other time.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/block/viodasd.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- linux-work.orig/drivers/block/viodasd.c 2008-03-12 10:25:55.0
+1100
+++ linux-work/drivers/block/viodasd.c 2008-03-12 10:39:38.0 +1100
@@ -528,8 +528,7 @@ static int block_event_to_scatterlist(co
numsg = VIOMAXBLOCKDMA;
*total_len = 0;
- memset(sg, 0, sizeof(sg[0]) * VIOMAXBLOCKDMA);
-
+ sg_init_table(sg, VIOMAXBLOCKDMA);
for (i = 0; (i numsg) (rw_data-dma_info[i].len 0); ++i) {
sg_dma_address(sg[i]) = rw_data-dma_info[i].token;
sg_dma_len(sg[i]) = rw_data-dma_info[i].len;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
Hi Ben, On Wed, 12 Mar 2008 17:23:56 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The iSeries viodasd drivers does some very strange things with scatterlists, one of these causing a BUG_ON to trigger when scatterlist debugging is enabled due to initializing the scatterlist with memset instead of sg_init_table(). This fixes it by using sg_init_table(). The rest of the stuff it does to that poor list is still pretty awful but it will work. Presumably this is also needed in 2.6.24.xx -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpGGpSaQnhsx.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
On Wed, 2008-03-12 at 17:44 +1100, Stephen Rothwell wrote: Hi Ben, On Wed, 12 Mar 2008 17:23:56 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The iSeries viodasd drivers does some very strange things with scatterlists, one of these causing a BUG_ON to trigger when scatterlist debugging is enabled due to initializing the scatterlist with memset instead of sg_init_table(). This fixes it by using sg_init_table(). The rest of the stuff it does to that poor list is still pretty awful but it will work. Presumably this is also needed in 2.6.24.xx Possibly, though the problem only occurs when enabling scatterlist debug, which distros don't do. Is it worth putting in a stable release ? If yes, I'll submit it as soon as it hits upstream. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Ensure that pmu_sys_suspended exists in appropriate configs.
Hi Tony, On Wed, Mar 12, 2008 at 10:48:48AM +1100, Tony Breeds wrote: pmu_sys_suspended is declared extern when: defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32) but only defined when: defined(CONFIG_SUSPEND) defined(CONFIG_PPC32) which is wrong. Lets fix that. As I wrote, this isn't defined in my config: # CONFIG_SUSPEND is not set CONFIG_HIBERNATION=y Cheers, -- Guido ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
Hi Andrew, The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc returning from prom_init Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc000d5dc cpu 0x0: Vector: 300 (Data Access) at [c07636e0] pc: c000d5dc: .do_IRQ+0x74/0x1f4 lr: c000d5a8: .do_IRQ+0x40/0x1f4 sp: c0763960 msr: 80001032 dar: 0 dsisr: 4000 current = 0xc0688e60 paca= 0xc0689900 pid = 0, comm = swapper enter ? for help [c0763a00] c0004c24 hardware_interrupt_entry+0x24/0x28 --- Exception: 501 (Hardware Interrupt) at c06021b0 .free_bootmem_core+0x94/0xcc [link register ] c060373c .free_bootmem_with_active_regions+0x78/0xb8 [c0763cf0] c0602610 .init_bootmem_core+0x5c/0xfc (unreliable) [c0763d80] c05eb68c .do_init_bootmem+0x964/0xaf0 [c0763e50] c05e03b0 .setup_arch+0x1a4/0x218 [c0763ee0] c05d76bc .start_kernel+0xe8/0x424 [c0763f90] c0008590 .start_here_common+0x60/0xd0 -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc: Export empty_zero_page
On Wed, Mar 12, 2008 at 02:41:10PM +1100, Tony Breeds wrote: I suspect you meant arch/*powerpc* arch ppc, wont fix the problem ;P Um, right. I didn't know about this: Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64 platforms. Currently there are efforts underway to port the remaining arch/ppc platforms to the merged tree. New submissions to the arch/ppc tree have been frozen with the 2.6.22 kernel release and that tree will remain in bug-fix only mode until its scheduled removal. Platforms that are not ported by June 2008 will be removed due to the lack of an interested maintainer. Oops, sorry. So should I not bother with a patch to arch/ppc at all? I guess it's somewhat likely that whatever is left in arch/ppc is not likely to need to support ext4? Back with a real patch in just a bit. :-) - Ted ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] pseries: phyp dump: config file
Thanks for the review. I will try and make the recommended changes and repost it soon. Manish Paul Mackerras wrote: Manish Ahuja writes: +config PHYP_DUMP +bool Hypervisor-assisted dump (EXPERIMENTAL) +depends on PPC_PSERIES EXPERIMENTAL +default y I think this should default to n for now (i.e. leave out the default line entirely). We can make it default to y later. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
On 11/03/2008, Paul Mackerras [EMAIL PROTECTED] wrote: -- This line needs to be exactly 3 dashes, because otherwise the tools include the diffstat into the commit message. Putting 4 or more dashes was an annoying habit Linas had, and it means I have to fix it manually (usually after I have committed the patches, and then notice that the commit message has the extra stuff in it, so I have to go back and fix the separators, reset my tree and re-commit the patches.) Sorry, I had no idea! If I didn't have enough dashes, then quilt would sometimes wipe out the comment at the top, so paranoia made me add lots of dashes. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
On Wed, 12 Mar 2008 18:25:37 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc returning from prom_init Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc000d5dc cpu 0x0: Vector: 300 (Data Access) at [c07636e0] pc: c000d5dc: .do_IRQ+0x74/0x1f4 lr: c000d5a8: .do_IRQ+0x40/0x1f4 sp: c0763960 msr: 80001032 dar: 0 dsisr: 4000 current = 0xc0688e60 paca= 0xc0689900 pid = 0, comm = swapper enter ? for help [c0763a00] c0004c24 hardware_interrupt_entry+0x24/0x28 --- Exception: 501 (Hardware Interrupt) at c06021b0 .free_bootmem_core+0x94/0xcc [link register ] c060373c .free_bootmem_with_active_regions+0x78/0xb8 [c0763cf0] c0602610 .init_bootmem_core+0x5c/0xfc (unreliable) [c0763d80] c05eb68c .do_init_bootmem+0x964/0xaf0 [c0763e50] c05e03b0 .setup_arch+0x1a4/0x218 [c0763ee0] c05d76bc .start_kernel+0xe8/0x424 [c0763f90] c0008590 .start_here_common+0x60/0xd0 Beats me. Maybe we're still enabling interrupts too early. But the new semaphore code got fixed (didn't it?) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
On Wed, Mar 12, 2008 at 10:46:45AM -0700, Andrew Morton wrote: On Wed, 12 Mar 2008 18:25:37 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Beats me. Maybe we're still enabling interrupts too early. But the new semaphore code got fixed (didn't it?) On the 7th, according to my records. Easy to check -- look in kernel/semaphore.c and see whether down() is using spin_lock_irqsave (good) or spin_lock_irq (bad). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
Hi, On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? Gruß, Jens Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It still fails. So this is really an open bug for PPC. -- Luis Machado Software Engineer IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
On 10/03/2008, Michael Ellerman [EMAIL PROTECTED] wrote: On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote: + +/* Global, used to communicate data between early boot and late boot */ +static struct phyp_dump phyp_dump_global; +struct phyp_dump *phyp_dump_info = phyp_dump_global; I don't see the point of this. You have a static (ie. non-global) struct called phyp_dump_global, then you create a pointer to it and pass that around. I did this. This is a style used to minimize disruption due to future design changes. Basically, the idea is that, at some later time, for some unknown reason, we decide that this structure shouldn't be global, or maybe shouldn't be statically allocated, or maybe should be per-cpu, or who knows. By creating a pointer, and just passing that around, you isolate other code from this change. I learned this trick after spending too many months of my life hunting down globals and replacing them by dynamically allocated structs. Its a long and painful process, on many levels, often requiring major code restructuring. Code that touches globals directly is often poorly thought out, designed. But going in the opposite direction is easy: if your code always passes everything it needs as args to subroutines, then you are free clear ... if one of those args just happens to be a pointer to a global, there's no loss (not even a performance loss -- the arg passing overhead is about the same as a global TOC lookup!) So it may look weird if you're not used to seeing it; but the alternative is almost always worse. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
On Wed, 2008-03-12 at 18:25 +0530, Kamalesh Babulal wrote: Hi Andrew, The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc returning from prom_init Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc000d5dc cpu 0x0: Vector: 300 (Data Access) at [c07636e0] pc: c000d5dc: .do_IRQ+0x74/0x1f4 lr: c000d5a8: .do_IRQ+0x40/0x1f4 sp: c0763960 msr: 80001032 dar: 0 dsisr: 4000 current = 0xc0688e60 paca= 0xc0689900 pid = 0, comm = swapper enter ? for help [c0763a00] c0004c24 hardware_interrupt_entry+0x24/0x28 --- Exception: 501 (Hardware Interrupt) at c06021b0 .free_bootmem_core+0x94/0xcc [link register ] c060373c .free_bootmem_with_active_regions+0x78/0xb8 [c0763cf0] c0602610 .init_bootmem_core+0x5c/0xfc (unreliable) [c0763d80] c05eb68c .do_init_bootmem+0x964/0xaf0 [c0763e50] c05e03b0 .setup_arch+0x1a4/0x218 [c0763ee0] c05d76bc .start_kernel+0xe8/0x424 [c0763f90] c0008590 .start_here_common+0x60/0xd0 Is this only on one machine ? happens all the time ? I ran into similar issues on rc3-mm1. rc5-mm1 seems to be working fine for me on ppc64. Thanks, Badari ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
slow Kilauea TCP throughput?
I have a project where I would like to use the AMC405EX under Linux for high speed data acquisition. I have the Kilauea board in the lab but measured only 150Mbit/s TCP throughput (outbound) with iperf. I need twice of that and actually expecting 3x higher bandwidth from that architecture. what is it that I'm missing? can anybody confirm my results or tell me what am I doing wrong? any help is appreciated sincerely ingo /home # uname -a Linux kilauea 2.6.23-g1dfaad37 #1 Wed Nov 21 07:15:18 CET 2007 ppc unknown home # ./iperf -c 192.168.1.249 -t60 -i1 Client connecting to 192.168.1.249, TCP port 5001 TCP window size: 16.0 KByte (default) [ 5] local 192.168.1.50 port 59035 connected with 192.168.1.249 port 5001 [ 5] 0.0- 1.0 sec 16.6 MBytes139 Mbits/sec [ 5] 1.0- 2.0 sec 16.6 MBytes140 Mbits/sec ... [ 5] 58.0-59.0 sec 18.0 MBytes151 Mbits/sec [ 5] 59.0-60.0 sec 18.0 MBytes151 Mbits/sec [ 5] 0.0-60.0 sec 1.04 GBytes148 Mbits/sec /home # ifconfig eth0 Link encap:Ethernet HWaddr 00:06:4B:10:19:5B inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:798928 errors:0 dropped:0 overruns:0 frame:0 TX packets:1634765 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:53947650 (51.4 MiB) TX bytes:2341215308 (2.1 GiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) * The information contained in this e-mail is intended only for the person or entity to which it is addressed and may contain confidential and / or privileged material. If you are not the intended recipient of this e-mail, the use of this information or any disclosure, copying or distribution is prohibited and may be unlawful. If you received this in error, please contact the sender and delete the material from any computer. L-3 Communications Security Systems, manufacturer of the eXaminer 3DX 6000 Explosive Detection System - http://www.l-3com.com ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Linux =2.6.24 support for FEC on MPC5200 (not B!)
Here is a patch for the lite5200 to get the FEC working again for kernel
=2.6.24. It was created against Linux 2.6.24.
The FEC driver is also compatible with the MPC5200, not only with the
MPC5200B, so an according entry was added to the drivers matching list.
Furthermore the settings for the PHY were entered in the dts file for
the Lite5200. Note, that this is not exactly the same as in the
Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
at :00 for the 5200B. I could test the patch on a Lite5200 and a
Lite5200B, both booted a kernel via tftp and mounted the root via nfs
successfully.
I hope, you can include the patch into the official tree.
Kind regards, René Bürgel
--
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 12
Fax: 03 72 06/ 88 73 - 60
E-Mail: [EMAIL PROTECTED]
Internet: www.unicontrol.de
--- ../kernel/current/arch/powerpc/boot/dts/lite5200.dts2008-03-12
18:26:02.0 +0100
+++ linux-2.6.24-uc/arch/powerpc/boot/dts/lite5200.dts 2008-03-12
17:44:06.0 +0100
@@ -273,6 +273,22 @@
mac-address = [ 02 03 04 05 06 07 ]; // Bad!
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = mpc5200-fec-phy;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 1;
+ };
};
[EMAIL PROTECTED] {
--- ../kernel/linux-2.6.24-uc/drivers/net/fec_mpc52xx.c 2008-03-12
15:25:27.0 +0100
+++ linux-2.6.24-uc/drivers/net/fec_mpc52xx.c 2008-03-12 18:39:30.0
+0100
@@ -1059,6 +1059,10 @@
static struct of_device_id mpc52xx_fec_match[] = {
{
.type = network,
+ .compatible = mpc5200b-fec,
+ },
+ {
+ .type = network,
.compatible = mpc5200-fec,
},
{ }
--- ../kernel/linux-2.6.24-uc/drivers/net/fec_mpc52xx_phy.c 2008-03-12
15:12:11.0 +0100
+++ linux-2.6.24-uc/drivers/net/fec_mpc52xx_phy.c 2008-03-12
19:47:39.0 +0100
@@ -181,6 +181,10 @@
.type = mdio,
.compatible = mpc5200b-fec-phy,
},
+ {
+ .type = mdio,
+ .compatible = mpc5200-fec-phy,
+ },
{},
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
Due to chip constraint MPC837x USB DR module can only use
ULPI and serial PHY interfaces. The patch fixes the wrong
type in dts.
This patch fixes USB malfunctioning on the MPC837xE-RDB boards.
Similar patch has been already applied for the MDS boards:
commit 28b958859206b7010d03129611c2e444898e3ee4
Author: Li Yang [EMAIL PROTECTED]
Date: Thu Mar 6 18:42:26 2008 +0800
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_rdb.dts |3 +--
arch/powerpc/boot/dts/mpc8378_rdb.dts |3 +--
arch/powerpc/boot/dts/mpc8379_rdb.dts |3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 440aa4d..5bc09ad 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -143,7 +143,6 @@
mode = cpu;
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
[EMAIL PROTECTED] {
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
@@ -151,7 +150,7 @@
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
- phy_type = utmi;
+ phy_type = ulpi;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 9271153..711f9a3 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -143,7 +143,6 @@
mode = cpu;
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
[EMAIL PROTECTED] {
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
@@ -151,7 +150,7 @@
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
- phy_type = utmi;
+ phy_type = ulpi;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 0dda2fc..c11ceb7 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -143,7 +143,6 @@
mode = cpu;
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
[EMAIL PROTECTED] {
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
@@ -151,7 +150,7 @@
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
- phy_type = utmi;
+ phy_type = ulpi;
};
[EMAIL PROTECTED] {
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc: Export empty_zero_page
Once again, this time with feeling - Ted From c91cfaabc17f8a53807a2f31f067a732e34a1550 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o [EMAIL PROTECTED] Date: Wed, 12 Mar 2008 11:50:39 -0400 Subject: [PATCH] [PATCH] powerpc: Export empty_zero_page The empty_zero_page symbol is exported by most other architectures (s390, ia64, x86, um), and an upcoming ext4 patch needs it because ZERO_PAGE() references empty_zero_page, and we need it to zero out an unitialized extents in ext4 files. Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] --- arch/powerpc/kernel/ppc_ksyms.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index aa9ff35..885a723 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -58,6 +58,7 @@ extern void program_check_exception(struct pt_regs *regs); extern void single_step_exception(struct pt_regs *regs); extern int sys_sigreturn(struct pt_regs *regs); +EXPORT_SYMBOL(empty_zero_page); EXPORT_SYMBOL(clear_pages); EXPORT_SYMBOL(copy_page); EXPORT_SYMBOL(ISA_DMA_THRESHOLD); -- 1.5.4.1.144.gdfee-dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Early Debug message on MPC8568MDS
Hello, How can I enable the early debug message on 2.6.23 kernel for MPC8568MDS board? What is the first line shall be displayed on the serial port? The board uses the first port of UART, where does it defined? Thanks for your help, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
Beats me. Maybe we're still enabling interrupts too early. But the new semaphore code got fixed (didn't it?) Won't lockdep/irqtrace warn if that happens ? You don't yet have the lockdep patches for ppc64 (I'm still trying to find out why they break iSeries) but it should warn of such a spurrious IRQ enable on other archs too... At least, from a quick look at the code, it -seems- that it does have such a test. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Ensure that pmu_sys_suspended exists in appropriate configs.
On Wed, Mar 12, 2008 at 09:38:57AM +0100, Guido Günther wrote: Hi Tony, On Wed, Mar 12, 2008 at 10:48:48AM +1100, Tony Breeds wrote: pmu_sys_suspended is declared extern when: defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32) but only defined when: defined(CONFIG_SUSPEND) defined(CONFIG_PPC32) which is wrong. Lets fix that. As I wrote, this isn't defined in my config: # CONFIG_SUSPEND is not set CONFIG_HIBERNATION=y Hmm okay I thought I tested for you. I don't know if I missed it in one of your original posts, can you supply your .config and compiler error. I can't see anywhere outside of: $ git grep -E -l pmu_sys_suspended -- drivers/macintosh/via-pmu-led.c drivers/macintosh/via-pmu.c include/linux/pmu.h where pmu_sys_suspended is referenced and I'm having difficulty understanding how CONFIG_HIBERNATION is affecting that. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On 03/12/2008 10:43 PM, York Sun wrote:
+static int fsl_diu_open(struct fb_info *info, int user)
+{
+ struct mfb_info *mfbi = info-par;
+ int res = 0;
+
+ spin_lock(diu_lock);
+ mfbi-count++;
+ if (mfbi-count == 1) {
+ DPRINTK(open plane index %d\n, mfbi-index);
+ fsl_diu_check_var(info-var, info);
+ fsl_diu_set_par(info);
Please retest your code (at least) with sleep-inside spinlock debug option. If I
see correctly you call GFP_KERNEL allocation somewhere deeper in this function,
which might sleep.
+ res = fsl_diu_enable_panel(info);
+ if (res 0)
+ mfbi-count--;
+ }
+
+ spin_unlock(diu_lock);
+ return res;
+}
+static void __exit uninstall_fb(struct fb_info *info)
+{
+ struct mfb_info *mfbi = info-par;
+
+ DPRINTK(Entered: uninstall_fb\n);
You don't need this stuff everywhere (kprobes).
+ if (!mfbi-registered)
+ return;
+
+ unregister_framebuffer(info);
+ unmap_video_memory(info);
+ if (info-cmap)
+ fb_dealloc_cmap(info-cmap);
+
+ mfbi-registered = 0;
+}
[...]
+static int fsl_diu_probe(struct platform_device *pdev)
+{
+ struct mfb_info *mfbi;
+ unsigned long dummy_ad_addr;
+ int ret, i, error = 0;
+
+ DPRINTK(Entered: fsl_diu_probe\n);
+
+ /* Area descriptor memory pool aligns to 64-bit boundary */
+ allocate_buf(pool.ad, sizeof(struct diu_ad) * FSL_AOI_NUM, 8);
+
+ /* Get memory for Gamma Table - 32-byte aligned memory */
+ allocate_buf(pool.gamma, 768, 32);
+
+ /* For performance, cursor bitmap buffer aligns to 32-byte boundary */
+ allocate_buf(pool.cursor, MAX_CURS * MAX_CURS * 2, 32);
+
+ i = sizeof(fsl_diu_info) / sizeof(struct fb_info);
+ dummy_ad = (struct diu_ad *)((u32)pool.ad.vaddr + pool.ad.offset) + i;
+ dummy_ad-paddr = pool.ad.paddr + i * sizeof(struct diu_ad);
+ dummy_aoi_virt = fsl_diu_alloc(64, dummy_ad_addr);
+ dummy_ad-addr = cpu_to_le32(dummy_ad_addr);
+ dummy_ad-pix_fmt = 0x2317;
+ dummy_ad-src_size_g_alpha = cpu_to_le32((4 12) | 4);
+ dummy_ad-aoi_size = cpu_to_le32((4 16) | 2);
+ dummy_ad-offset_xyi = 0;
+ dummy_ad-offset_xyd = 0;
+ dummy_ad-next_ad = 0;
+ memset(dummy_aoi_virt, 0x00, 64);
+ write_reg((dr.diu_reg-desc[0]), dummy_ad-paddr);
+ write_reg((dr.diu_reg-desc[1]), dummy_ad-paddr);
+ write_reg((dr.diu_reg-desc[2]), dummy_ad-paddr);
+
+ for (i = 0; i sizeof(fsl_diu_info) / sizeof(struct fb_info); i++) {
+ fsl_diu_info[i].fix.smem_start = 0;
+ mfbi = fsl_diu_info[i].par;
+ mfbi-ad = (struct diu_ad *)((u32)pool.ad.vaddr
+ + pool.ad.offset) + i;
+ mfbi-ad-paddr = pool.ad.paddr + i * sizeof(struct diu_ad);
+ ret = install_fb(fsl_diu_info[i], pdev);
+ if (ret) {
+ printk(KERN_ERR Failed to register framebuffer %d\n,
+ i);
+ return ret;
some kind of free here
+ }
+ }
[...]
+int __init fsl_diu_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+ int error;
+ DPRINTK(Entered: fsl_diu_init\n);
+ np = of_find_compatible_node(NULL, NULL, fsl-diu);
+ if (!np) {
+ printk(KERN_ERR Err: can't find device node 'fsl-diu'\n);
+ return -ENODEV;
+ }
+
+ of_address_to_resource(np, 0, r);
+ of_node_put(np);
+
+ DPRINTK(%s, r.start: 0x%08x\n, __func__, r.start);
+
+ dr.diu_reg = ioremap(r.start, sizeof(struct diu));
The arch never fails with remapping?
+
+ write_reg((dr.diu_reg-diu_mode), 0); /* disable DIU anyway*/
+
+ spin_lock_init(dr.reg_lock);
+
+
+ /*
+* For kernel boot options (in 'video=xxxfb:options' format)
+*/
+#ifndef MODULE
+ {
+ char *option;
+
+ if (fb_get_options(fslfb, option))
+ return -ENODEV;
+ fsl_diu_setup(option);
+ }
+#endif
+ error = platform_driver_register(fsl_diu_driver);
+
+ if (!error) {
+ error = platform_device_register(fsl_diu_device);
+ if (error) {
+ printk(KERN_ERR Err:
+ can't register FB device driver!\n);
+ platform_driver_unregister(fsl_diu_driver);
iounmap
+ }
+ printk(KERN_INFO FSL_DIU_FB: registed FB device driver!\n);
+ }
else iounmap
+
+ return error;
+}
[...]
diff --git a/drivers/video/fsl-diu-fb.h b/drivers/video/fsl-diu-fb.h
new file mode 100644
index 000..294d0bf
--- /dev/null
+++ b/drivers/video/fsl-diu-fb.h
@@ -0,0 +1,388 @@
[...]
Re: [BUG] 2.6.25-rc5-mm1 kernel panic with Exception: 501 on powerpc
On Wed, 2008-03-12 at 11:51 -0600, Matthew Wilcox wrote: On Wed, Mar 12, 2008 at 10:46:45AM -0700, Andrew Morton wrote: On Wed, 12 Mar 2008 18:25:37 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Beats me. Maybe we're still enabling interrupts too early. But the new semaphore code got fixed (didn't it?) On the 7th, according to my records. Easy to check -- look in kernel/semaphore.c and see whether down() is using spin_lock_irqsave (good) or spin_lock_irq (bad). down() looks OK, but there's still a spin_lock_irq() in __down_common(), although I don't know if it makes sense for us to be in __down() at that stage. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] maple: use platform name in define_machine()
Prevailing practice for define_machine() in powerpc is to use the
platform name when the platform has only one define_machine()
statement, but maple uses maple_md. This caused me some
head-scratching when writing some new code that uses
machine_is(maple).
Use maple instead of maple_md. There should not be any behavioral
change -- fixup_maple_ide() calls machine_is(maple) but the body of
the function is ifdef'd out.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index 3ce2d73..3b32e07 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -319,7 +319,7 @@ static int __init maple_probe(void)
return 1;
}
-define_machine(maple_md) {
+define_machine(maple) {
.name = Maple,
.probe = maple_probe,
.setup_arch = maple_setup_arch,
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
maple: minor updates
Please consider the following mostly-trivial patches for 2.6.26. arch/powerpc/configs/maple_defconfig | 133 -- arch/powerpc/platforms/maple/pci.c | 47 arch/powerpc/platforms/maple/setup.c |2 +- 3 files changed, 129 insertions(+), 53 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] maple: kill fixup_maple_ide
This function has been a no-op for about 18 months; it's there in
the history should anyone need to resurrect it.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/pci.c | 47
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c
b/arch/powerpc/platforms/maple/pci.c
index 3ffa0ac..3018552 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -592,50 +592,3 @@ int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int
channel)
}
return irq;
}
-
-/* XXX: To remove once all firmwares are ok */
-static void fixup_maple_ide(struct pci_dev* dev)
-{
- if (!machine_is(maple))
- return;
-
-#if 0 /* Enable this to enable IDE port 0 */
- {
- u8 v;
-
- pci_read_config_byte(dev, 0x40, v);
- v |= 2;
- pci_write_config_byte(dev, 0x40, v);
- }
-#endif
-#if 0 /* fix bus master base */
- pci_write_config_dword(dev, 0x20, 0xcc01);
- printk(old ide resource: %lx - %lx \n,
- dev-resource[4].start, dev-resource[4].end);
- dev-resource[4].start = 0xcc00;
- dev-resource[4].end = 0xcc10;
-#endif
-#if 0 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
- {
- struct pci_dev *apicdev;
- u32 v;
-
- apicdev = pci_get_slot (dev-bus, PCI_DEVFN(5,0));
- if (apicdev == NULL)
- printk(IDE Fixup IRQ: Can't find IO-APIC !\n);
- else {
- pci_write_config_byte(apicdev, 0xf2, 0x10 + 2*14);
- pci_read_config_dword(apicdev, 0xf4, v);
- v = ~0x0022;
- pci_write_config_dword(apicdev, 0xf4, v);
- pci_write_config_byte(apicdev, 0xf2, 0x10 + 2*15);
- pci_read_config_dword(apicdev, 0xf4, v);
- v = ~0x0022;
- pci_write_config_dword(apicdev, 0xf4, v);
- pci_dev_put(apicdev);
- }
- }
-#endif
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8111_IDE,
-fixup_maple_ide);
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] maple: enable ipr driver in defconfig
Some machines supported by the maple platform have an Obsidian controller which can't be used without enabling CONFIG_IPR and the options on which it depends. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] --- arch/powerpc/configs/maple_defconfig | 133 -- 1 files changed, 128 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig index 8b810d0..25be62b 100644 --- a/arch/powerpc/configs/maple_defconfig +++ b/arch/powerpc/configs/maple_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc4 -# Thu Dec 6 16:48:26 2007 +# Wed Mar 12 16:21:48 2008 # CONFIG_PPC64=y @@ -333,7 +333,7 @@ CONFIG_DEFAULT_TCP_CONG=cubic CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set +CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set @@ -374,6 +374,7 @@ CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set +# CONFIG_BLK_DEV_IDESCSI is not set CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_PROC_FS=y @@ -427,10 +428,129 @@ CONFIG_IDE_ARCH_OBSOLETE_INIT=y # SCSI device support # # CONFIG_RAID_ATTRS is not set -# CONFIG_SCSI is not set -# CONFIG_SCSI_DMA is not set +CONFIG_SCSI=y +CONFIG_SCSI_DMA=y +# CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set -# CONFIG_ATA is not set +# CONFIG_SCSI_PROC_FS is not set + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +CONFIG_CHR_DEV_SG=y +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SCAN_ASYNC is not set +CONFIG_SCSI_WAIT_SCAN=m + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set +# CONFIG_SCSI_SRP_ATTRS is not set +CONFIG_SCSI_LOWLEVEL=y +# CONFIG_ISCSI_TCP is not set +# CONFIG_BLK_DEV_3W__RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_AIC94XX is not set +# CONFIG_SCSI_ARCMSR is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_HPTIOP is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_EATA is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_GDTH is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_STEX is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +CONFIG_SCSI_IPR=y +CONFIG_SCSI_IPR_TRACE=y +CONFIG_SCSI_IPR_DUMP=y +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_QLA_FC is not set +# CONFIG_SCSI_QLA_ISCSI is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_DEBUG is not set +# CONFIG_SCSI_SRP is not set +CONFIG_ATA=y +CONFIG_ATA_NONSTANDARD=y +# CONFIG_SATA_AHCI is not set +# CONFIG_SATA_SVW is not set +# CONFIG_ATA_PIIX is not set +# CONFIG_SATA_MV is not set +# CONFIG_SATA_NV is not set +# CONFIG_PDC_ADMA is not set +# CONFIG_SATA_QSTOR is not set +# CONFIG_SATA_PROMISE is not set +# CONFIG_SATA_SX4 is not set +# CONFIG_SATA_SIL is not set +# CONFIG_SATA_SIL24 is not set +# CONFIG_SATA_SIS is not set +# CONFIG_SATA_ULI is not set +# CONFIG_SATA_VIA is not set +# CONFIG_SATA_VITESSE is not set +# CONFIG_SATA_INIC162X is not set +# CONFIG_PATA_ALI is not set +# CONFIG_PATA_AMD is not set +# CONFIG_PATA_ARTOP is not set +# CONFIG_PATA_ATIIXP is not set +# CONFIG_PATA_CMD640_PCI is not set +# CONFIG_PATA_CMD64X is not set +# CONFIG_PATA_CS5520 is not set +# CONFIG_PATA_CS5530 is not set +# CONFIG_PATA_CYPRESS is not set +# CONFIG_PATA_EFAR is not set +# CONFIG_ATA_GENERIC is not set +# CONFIG_PATA_HPT366 is not set +# CONFIG_PATA_HPT37X is not set +# CONFIG_PATA_HPT3X2N is not set +# CONFIG_PATA_HPT3X3 is not set +# CONFIG_PATA_IT821X is not set +# CONFIG_PATA_IT8213 is not set +# CONFIG_PATA_JMICRON is not set +# CONFIG_PATA_TRIFLEX is not set +# CONFIG_PATA_MARVELL is not set +# CONFIG_PATA_MPIIX is not set +# CONFIG_PATA_OLDPIIX is not set +# CONFIG_PATA_NETCELL is not set +# CONFIG_PATA_NS87410 is not set +# CONFIG_PATA_NS87415 is not set +# CONFIG_PATA_OPTI is not set +# CONFIG_PATA_OPTIDMA is not set +# CONFIG_PATA_PDC_OLD is not set +# CONFIG_PATA_RADISYS is not set +# CONFIG_PATA_RZ1000 is not set +# CONFIG_PATA_SC1200 is not set +# CONFIG_PATA_SERVERWORKS is
Please pull powerpc.git merge branch
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug-fixes for various powerpc platforms.
Thanks,
Paul.
arch/powerpc/Makefile |2
arch/powerpc/boot/Makefile | 18 -
arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8379_mds.dts | 70 ++
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/wrapper |6
arch/powerpc/configs/adder875-uboot_defconfig | 798 ---
arch/powerpc/configs/adder875_defconfig | 61 +-
arch/powerpc/kernel/head_8xx.S | 30 +
arch/powerpc/kernel/misc_32.S | 15
arch/powerpc/kernel/pci-common.c|8
arch/powerpc/kernel/ppc_ksyms.c |3
arch/powerpc/mm/hash_utils_64.c |4
arch/powerpc/platforms/83xx/mpc837x_mds.c |8
arch/powerpc/platforms/Kconfig |1
arch/powerpc/platforms/Kconfig.cputype |7
arch/powerpc/platforms/cell/spufs/context.c |3
arch/powerpc/platforms/cell/spufs/run.c |3
arch/powerpc/platforms/cell/spufs/sched.c |4
arch/powerpc/platforms/cell/spufs/spufs.h |1
arch/powerpc/platforms/powermac/pic.c |2
arch/powerpc/sysdev/qe_lib/qe.c |7
arch/ppc/kernel/head_8xx.S | 30 +
drivers/block/viodasd.c |3
drivers/macintosh/via-pmu-backlight.c |5
drivers/macintosh/via-pmu.c |2
include/asm-powerpc/pgtable-ppc32.h |8
include/asm-ppc/pgtable.h |8
include/linux/pmu.h |9
30 files changed, 389 insertions(+), 883 deletions(-)
delete mode 100644 arch/powerpc/configs/adder875-uboot_defconfig
rename arch/powerpc/configs/{adder875-redboot_defconfig = adder875_defconfig}
(95%)
Andy Fleming (1):
[POWERPC] 83xx: Make 83xx perfmon support selectable
Benjamin Herrenschmidt (3):
[POWERPC] Fix bogus test for unassigned PCI resources
[POWERPC] Fix sleep on some powerbooks
[POWERPC] Fix viodasd driver with scatterlist debug
Grant Likely (1):
[POWERPC] Fix zImage-dtb.initrd build error
Guido Guenther (1):
[POWERPC] Fix build of modular drivers/macintosh/apm_emu.c
Ionut Nicu (1):
[POWERPC] QE: Make qe_get_firmware_info reentrant
Jeremy Kerr (2):
[POWERPC] spufs: don't (ab)use SCHED_IDLE
[POWERPC] spufs: fix rescheduling of non-runnable contexts
Jeremy McNicoll (1):
[POWERPC] 85xx: sbc8548 - Fix incorrect PCI-X and PCI interrupt map
Li Yang (2):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
[POWERPC] 83xx: Add local bus device nodes to MPC837xMDS device trees.
Michael Ellerman (1):
[POWERPC] Fix large hash table allocation on Cell blades
Paul Mackerras (1):
[POWERPC] Add __ucmpdi2 for 64-bit comparisons in 32-bit kernels
Scott Wood (1):
[POWERPC] 8xx: Fix wrapper platform for adder875, and combine defconfigs.
Theodore Ts'o (1):
[POWERPC] Export empty_zero_page
Timur Tabi (1):
[POWERPC] QE: Fix QE firmware uploading limit
Tony Breeds (3):
[POWERPC] Fix undefined pmu_sys_suspended compilation error
[POWERPC] Fix drivers/macintosh/mediabay.c when !CONFIG_ADB_PMU
[POWERPC] Fix arch/powerpc/platforms/powermac/pic.c when !CONFIG_ADB_PMU
Vitaly Bordug (1):
[POWERPC] 8xx: fix swap
Yuri Tikhonov (1):
[PPC] 8xx: swap bug-fix
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Hi York,
Just a few things from a first pass.
On Wed, 12 Mar 2008 16:43:42 -0500 York Sun [EMAIL PROTECTED] wrote:
+++ b/drivers/video/fsl-diu-fb.c
+#include asm/of_platform.h
Please include linux/of_platform.h instead.
+/* Align to 64-bit(8-byte), 32-byte, etc. */
+static int allocate_buf(struct diu_addr *buf, u32 size, u32 bytes_align)
+{
+ buf-vaddr = dma_alloc_coherent(0, ssize,
+ (dma_addr_t *) (buf-paddr),
This cast is unnecessary as buf-paddr is a dma_addr_t ...
+++ b/drivers/video/fsl-diu-fb.h
+static struct fb_videomode __devinitdata fsl_diu_default_mode = {
+static struct fb_videomode __devinitdata fsl_diu_mode_db[] = {
Why are these in the .h file? They should be in the .c file.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpK1onq6ve7k.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
AFAICT the DABRX register just has two global bits that enable paying attention to the DABR register. It only needs to be set once at boot time (as the cell code does). I don't see how missing that initialization could ever have explained the behavior we see where DABR matches are intermittent. If those DABRX bits weren't set then no DABR match would have happened. (Apparently they are set before boot on an Apple G5.) What we actually see is that DABR matches seem to be reliable when things are slow, and get intermittent when there are enough threads with DABR set. I searched the web trying to figure out what a DABRX register does so I could just go try it myself rather than waiting another n months for powerpc folks to forget about it again. (I did try it, and mtspr(SPRN_DABRX, DABRX_KERNEL | DABRX_USER); makes no difference to the test on my machine, even done in set_dabr every time we set SPRN_DABR.) I happened across: http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/79B6E24422AA101287256E93006C957E/$file/PowerPC_970FX_errata_DD3.X_V1.7.pdf which is IBM PowerPC 970FX RISC Microprocessor Errata List for DD3.X and contains Erratum #8: DABRX register might not always be updated correctly: Projected Impact The data address breakpoint function might not always work. Workaround None. Status A fix is not planned at this time for the PowerPC 970FX. The only machine I have at home for testing powerpc is an Apple G5, supplied to me by IBM. It says: cpu : PPC970FX, altivec supported revision: 3.0 (pvr 003c 0300) so I am guessing this document applies to the chips I have. Since I can't test on other chips myself, it is plausible from what I've seen that there is no mysterious kernel problem and only this hardware problem. The description of the hardware problem would not make me think that it would behave this way, but it is not very detailed or precise, or at least does not seem so to a reader not expert on powerpc. So, uh, go IBM! I'm in the minority in this conversation as someone not expert on powerpc, and as someone not employed by IBM. (I don't really mind finding public IBM documents about powerpc on the web and telling IBM powerpc folks about them. But, well.) I don't know what I can do next to tell whether this processor erratum is in fact what's happening in the test case. If it is, I don't know if there might be some arcane way to work around it despite None cited above. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
If Mike and Paul are okay, then I will leave this bit as is and fix all other issues and comments. Thanks, Manish Linas Vepstas wrote: On 10/03/2008, Michael Ellerman [EMAIL PROTECTED] wrote: On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote: + +/* Global, used to communicate data between early boot and late boot */ +static struct phyp_dump phyp_dump_global; +struct phyp_dump *phyp_dump_info = phyp_dump_global; I don't see the point of this. You have a static (ie. non-global) struct called phyp_dump_global, then you create a pointer to it and pass that around. I did this. This is a style used to minimize disruption due to future design changes. Basically, the idea is that, at some later time, for some unknown reason, we decide that this structure shouldn't be global, or maybe shouldn't be statically allocated, or maybe should be per-cpu, or who knows. By creating a pointer, and just passing that around, you isolate other code from this change. I learned this trick after spending too many months of my life hunting down globals and replacing them by dynamically allocated structs. Its a long and painful process, on many levels, often requiring major code restructuring. Code that touches globals directly is often poorly thought out, designed. But going in the opposite direction is easy: if your code always passes everything it needs as args to subroutines, then you are free clear ... if one of those args just happens to be a pointer to a global, there's no loss (not even a performance loss -- the arg passing overhead is about the same as a global TOC lookup!) So it may look weird if you're not used to seeing it; but the alternative is almost always worse. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/11] celleb: add support for PCI Express
Arnd Bergmann [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch adds support for PCI Express port on Celleb. I/O space
of this PCI Express port is not mapped in memory space. So we use
the io-workaround mechanism to make accesses indirect.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
This one looks good, but I wonder if we should make it possible to
also use it on QS20, which the current code doesn't allow.
It's a rather hypothetical question, because QS20 has been replaced
by QS21 as a product and it never supported PCIe cards with I/O space
mappings, but it would be the right thing to do.
Since you don't have the QS20 hardware to test that, and I currently
doubt anyone at IBM has the energy to do the work, it will probably
never get done. If you send another version of the patch, maybe you
can add comments to hint that this is actually possible, just hasn't
been implemented.
Sorry, I don't know about QS20 and its chipset. However, if anyone
changes the code to work also on QS20, I'll welcome the change and
test it on Celleb.
Though I don't know it helps you, I explain a little about Celleb.
The way to access SCC PCIe I/O port is the same as the way to access
its config space.
- Write an address to the address register.
- Write an 'I/O port write' or 'I/O port read' command with byte
enable bits to the command register.
- Write or Read the data register.
That's all, and you can find this in my code.
By the way, I found a minor bug in my patch. I'll send fixed one.
+ dummy_page_da = dma_map_single(bus-phb-parent, dummy_page_va,
+ PAGE_SIZE, DMA_FROM_DEVICE);
+ if (dummy_page_da == DMA_FROM_DEVICE) {
Comparing with DMA_FROM_DEVICE is wrong. We should compare with
DMA_ERROR_CODE. And using dma_mapping_error() is the right way.
Best regards,
Kou Ishizaki
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
