[PATCH] macintosh: make Open Firmware device id constant
From: Márton Németh nm...@freemail.hu
The match_table field of the struct of_device_id is constant in
linux/of_platform.h
so it is worth to make the initialization data also constant.
The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
struct I1 {
...
const struct I2 *x;
...
};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
struct I1 y = {
.x = E,
};
@c@
identifier r.I2;
identifier s.E;
@@
const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+ const
struct I2 E[] = ...;
// /smpl
Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Julia Lawall ju...@diku.dk
Cc: co...@diku.dk
---
diff -u -p a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
--- a/drivers/macintosh/therm_windtunnel.c 2010-01-07 19:08:40.0 +0100
+++ b/drivers/macintosh/therm_windtunnel.c 2010-01-08 04:47:10.0 +0100
@@ -457,7 +457,7 @@ therm_of_remove( struct of_device *dev )
return 0;
}
-static struct of_device_id therm_of_match[] = {{
+static const struct of_device_id therm_of_match[] = {{
.name = fan,
.compatible = adm1030
}, {}
diff -u -p a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
--- a/drivers/macintosh/smu.c 2009-12-03 04:51:21.0 +0100
+++ b/drivers/macintosh/smu.c 2010-01-08 04:47:28.0 +0100
@@ -660,7 +660,7 @@ static int smu_platform_probe(struct of_
return 0;
}
-static struct of_device_id smu_platform_match[] =
+static const struct of_device_id smu_platform_match[] =
{
{
.type = smu,
diff -u -p a/drivers/macintosh/therm_pm72.c b/drivers/macintosh/therm_pm72.c
--- a/drivers/macintosh/therm_pm72.c 2009-12-03 04:51:21.0 +0100
+++ b/drivers/macintosh/therm_pm72.c 2010-01-08 04:50:17.0 +0100
@@ -2211,7 +2211,7 @@ static int fcu_of_remove(struct of_devic
return 0;
}
-static struct of_device_id fcu_match[] =
+static const struct of_device_id fcu_match[] =
{
{
.type = fcu,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] pmac-zilog: add platform driver, version 2
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
This patch should be applied after [PATCH 3/13] pmac-zilog: cleanup.
Signed-off-by: Finn Thain fth...@telegraphics.com.au
---
Version 2 of this patch adopts Geert's suggestions: make better use of
dev_{dbg,err,info} macros, change platform_driver_register() to
platform_driver_probe(), and use __init and __exit attributes.
arch/m68k/configs/mac_defconfig |5 +
arch/m68k/configs/multi_defconfig |5 +
drivers/serial/Kconfig| 12 +-
drivers/serial/pmac_zilog.c | 158 +-
drivers/serial/pmac_zilog.h | 14 +++
5 files changed, 168 insertions(+), 26 deletions(-)
Index: linux-2.6.31/drivers/serial/Kconfig
===
--- linux-2.6.31.orig/drivers/serial/Kconfig2010-01-10 13:13:55.0
+1100
+++ linux-2.6.31/drivers/serial/Kconfig 2010-01-10 13:14:18.0 +1100
@@ -1079,12 +1079,12 @@ config SERIAL_68360
default y
config SERIAL_PMACZILOG
- tristate PowerMac z85c30 ESCC support
- depends on PPC_OF PPC_PMAC
+ tristate Mac or PowerMac z85c30 ESCC support
+ depends on (M68K MAC) || (PPC_OF PPC_PMAC)
select SERIAL_CORE
help
This driver supports the Zilog z85C30 serial ports found on
- PowerMac machines.
+ (Power)Mac machines.
Say Y or M if you want to be able to these serial ports.
config SERIAL_PMACZILOG_TTYS
@@ -1109,16 +1109,16 @@ config SERIAL_PMACZILOG_TTYS
unable to use the 8250 module for PCMCIA or other 16C550-style
UARTs.
- Say N unless you need the z85c30 ports on your powermac
+ Say N unless you need the z85c30 ports on your (Power)Mac
to appear as /dev/ttySn.
config SERIAL_PMACZILOG_CONSOLE
- bool Console on PowerMac z85c30 serial port
+ bool Console on Mac or PowerMac z85c30 serial port
depends on SERIAL_PMACZILOG=y
select SERIAL_CORE_CONSOLE
help
If you would like to be able to use the z85c30 serial port
- on your PowerMac as the console, you can do so by answering
+ on your (Power)Mac as the console, you can do so by answering
Y to this option.
config SERIAL_LH7A40X
Index: linux-2.6.31/arch/m68k/configs/mac_defconfig
===
--- linux-2.6.31.orig/arch/m68k/configs/mac_defconfig 2010-01-10
13:13:55.0 +1100
+++ linux-2.6.31/arch/m68k/configs/mac_defconfig2010-01-10
13:13:57.0 +1100
@@ -701,6 +701,11 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/arch/m68k/configs/multi_defconfig
===
--- linux-2.6.31.orig/arch/m68k/configs/multi_defconfig 2010-01-10
13:13:55.0 +1100
+++ linux-2.6.31/arch/m68k/configs/multi_defconfig 2010-01-10
13:13:57.0 +1100
@@ -822,6 +822,11 @@ CONFIG_A2232=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/drivers/serial/pmac_zilog.c
===
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2010-01-10
13:13:55.0 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.c2010-01-10 13:13:57.0
+1100
@@ -63,11 +63,18 @@
#include asm/sections.h
#include asm/io.h
#include asm/irq.h
+
+#ifdef CONFIG_PPC_PMAC
#include asm/prom.h
#include asm/machdep.h
#include asm/pmac_feature.h
#include asm/dbdma.h
#include asm/macio.h
+#else
+#include linux/platform_device.h
+#include asm/macints.h
+#define machine_is_compatible(x) (0)
+#endif
#if defined (CONFIG_SERIAL_PMACZILOG_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
@@ -83,11 +90,9 @@
static char version[] __initdata = pmac_zilog: 0.6 (Benjamin Herrenschmidt
b...@kernel.crashing.org);
MODULE_AUTHOR(Benjamin Herrenschmidt b...@kernel.crashing.org);
-MODULE_DESCRIPTION(Driver for the PowerMac serial ports.);
+MODULE_DESCRIPTION(Driver for the Mac and PowerMac serial ports.);
MODULE_LICENSE(GPL);
-#define PWRDBG(fmt, arg...)printk(KERN_DEBUG fmt , ## arg)
-
#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
#define PMACZILOG_MAJORTTY_MAJOR
#define PMACZILOG_MINOR64
@@ -341,7 +346,7 @@ static struct tty_struct *pmz_receive_ch
Re: PCI-PCI bridge scanning broken on 460EX
Hi, Ben Felix Radensky wrote: Hi, Ben Adding Feng Kan from AMCC to CC. Benjamin Herrenschmidt wrote: On Mon, 2009-12-28 at 12:51 +0200, Felix Radensky wrote: Hi, I'm running linux-2.6.33-rc2 on Canyonlands board. When PLX 6254 transparent PCI-PCI bridge is plugged into PCI slot the kernel simply resets the board without printing anything to console. Without PLX bridge kernel boots fine. Sorry for the late reply... No need to apologize, I appreciate you help very much. I've tracked down the problem to the following code in pci_scan_bridge() in drivers/pci/probe.c: if (pcibios_assign_all_busses() || broken) /* Temporarily disable forwarding of the configuration cycles on all bridges in this bus segment to avoid possible conflicts in the second pass between two bridges programmed with overlapping bus ranges. */ pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses ~0xff); If test for broken is removed, kernel boots fine, detects the bridge, but does not detect the device behind the bridge. The same device plugged directly into PCI slot is detected correctly. So we would have a similar mismatch between the initial setup and the kernel... However, I don't quite see yet why the kernel trying to fix it up breaks things, that will need a bit more debugging here... Can you give it a quick try with adding something like : ppc_pci_add_flags(PPC_PCI_REASSIGN_ALL_BUS); Near the end of ppc4xx_pci.c ? It looks like another case of reset not actually resetting bridges (are we not properly doing a fundamental reset ? Stefan what's your take there ?) The above will cause busses to be re-assigned which is risky because it will allow the kernel to assign numbers beyond the limits of what ppc4xx_pci.c supports (see my comments in the thread you quotes). The good thing is that we now have a working fixmap infrastructure, so we could/should just move ppc4xx_pci.c to use that, and just always re-assign busses. To remind you, tests for broken were added by commit a1c19894b786f10c76ac40e93c6b5d70c9b946d2, and were intended to solve device detection problem behind PCI-E switches, as discussed in this thread: http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-October/063939.html PCI: Probing PCI hardware pci_bus :00: scanning bus pci :00:06.0: found [3388:0020] class 000604 header type 01 pci :00:06.0: supports D1 D2 pci :00:06.0: PME# supported from D0 D1 D2 D3hot pci :00:06.0: PME# disabled pci_bus :00: fixups for bus pci :00:06.0: scanning behind bridge, config 00, pass 0 pci :00:06.0: bus configuration invalid, reconfiguring Ok so we hit a P2P bridge whose primary, secondary and subordinate bus numbers are all 0, which is clearly unconfigured. I think this is the root complex bridge pci :00:06.0: scanning behind bridge, config 00, pass 1 Now this is when the bus should be reconfigured (pass 1). Sadly the code doesn't print much debug. Also from that point, it should renumber things and work... pci_bus :01: scanning bus Which it does to some extent. It assigned bus number 1 to it afaik so we now start looking below the RC bridge: pci :01:06.0: found [3388:0020] class 000604 header type 01 Hrm... class PCI bridge, vendor 3388 device 0020, is that your PLX ? It's not the right vendor ID but maybe that's configurable by our OEM or something... The bridge and its evaluation board were manufactured by HiNT, later purchased by PLX. 3388:0020 is HiNT HB6 Universal PCI-PCI bridge in transparent mode. pci :01:06.0: supports D1 D2 pci :01:06.0: PME# supported from D0 D1 D2 D3hot pci :01:06.0: PME# disabled pci_bus :01: fixups for bus pci :00:06.0: PCI bridge to [bus 01-ff] pci :00:06.0: bridge window [io 0x-0x0fff] pci :00:06.0: bridge window [mem 0x-0x000f] pci :00:06.0: bridge window [mem 0x-0x000f 64bit pref] pci :01:06.0: scanning behind bridge, config ff0100, pass 0 Allright, that's where it gets interesting. It tries to scan behind the bridge. It gets something it doesn't like. IE, it gets a secondary bus number of 1 (what the heck ? I wonder what your firmware does) which Linux is not happy about and decides to renumber it. U-boot has problems with this bridge as well, so I had to completely disable PCI support in u-boot to get linux running. pci :01:06.0: bus configuration invalid, reconfiguring Now, that's where Linux should have written 00 to the register, which is what you commented out. pci :01:06.0: scanning behind bridge, config ff0100, pass 1 pci_bus :01: bus scan returning with max=01 pci_bus :00: bus scan returning with max=01 Because of that commenting out, it doesn't see
Allocator MAX_ORDER exceeds SECTION_SIZE
I get the following compilation failure, if 64k pages is selected on 2.6.32.3 on a PowerMAC config: include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Any idea? -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] pmac-zilog: add platform driver, version 3
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
Signed-off-by: Finn Thain fth...@telegraphics.com.au
---
This patch should be applied after [PATCH 3/13] pmac-zilog: cleanup.
It obsoletes [PATCH 4/13] pmac-zilog, mac68k: replace mac68k SCC code
with platform device listed in the linux-ppc patchwork.
Version 2 of this patch adopts Geert's suggestions: make better use of
dev_{dbg,err,info} macros, change platform_driver_register() to
platform_driver_probe(), and use __init and __exit attributes.
Version 3 does not #include macints.h.
arch/m68k/configs/mac_defconfig |5 +
arch/m68k/configs/multi_defconfig |5 +
drivers/serial/Kconfig| 12 +-
drivers/serial/pmac_zilog.c | 157 +-
drivers/serial/pmac_zilog.h | 14 +++
5 files changed, 167 insertions(+), 26 deletions(-)
Index: linux-2.6.31/drivers/serial/Kconfig
===
--- linux-2.6.31.orig/drivers/serial/Kconfig2010-01-10 23:38:58.0
+1100
+++ linux-2.6.31/drivers/serial/Kconfig 2010-01-10 23:39:02.0 +1100
@@ -1079,12 +1079,12 @@ config SERIAL_68360
default y
config SERIAL_PMACZILOG
- tristate PowerMac z85c30 ESCC support
- depends on PPC_OF PPC_PMAC
+ tristate Mac or PowerMac z85c30 ESCC support
+ depends on (M68K MAC) || (PPC_OF PPC_PMAC)
select SERIAL_CORE
help
This driver supports the Zilog z85C30 serial ports found on
- PowerMac machines.
+ (Power)Mac machines.
Say Y or M if you want to be able to these serial ports.
config SERIAL_PMACZILOG_TTYS
@@ -1109,16 +1109,16 @@ config SERIAL_PMACZILOG_TTYS
unable to use the 8250 module for PCMCIA or other 16C550-style
UARTs.
- Say N unless you need the z85c30 ports on your powermac
+ Say N unless you need the z85c30 ports on your (Power)Mac
to appear as /dev/ttySn.
config SERIAL_PMACZILOG_CONSOLE
- bool Console on PowerMac z85c30 serial port
+ bool Console on Mac or PowerMac z85c30 serial port
depends on SERIAL_PMACZILOG=y
select SERIAL_CORE_CONSOLE
help
If you would like to be able to use the z85c30 serial port
- on your PowerMac as the console, you can do so by answering
+ on your (Power)Mac as the console, you can do so by answering
Y to this option.
config SERIAL_LH7A40X
Index: linux-2.6.31/arch/m68k/configs/mac_defconfig
===
--- linux-2.6.31.orig/arch/m68k/configs/mac_defconfig 2010-01-10
23:39:02.0 +1100
+++ linux-2.6.31/arch/m68k/configs/mac_defconfig2010-01-10
23:39:02.0 +1100
@@ -701,6 +701,11 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/arch/m68k/configs/multi_defconfig
===
--- linux-2.6.31.orig/arch/m68k/configs/multi_defconfig 2010-01-10
23:39:02.0 +1100
+++ linux-2.6.31/arch/m68k/configs/multi_defconfig 2010-01-10
23:39:02.0 +1100
@@ -822,6 +822,11 @@ CONFIG_A2232=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/drivers/serial/pmac_zilog.c
===
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2010-01-10
23:39:02.0 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.c2010-01-11 03:11:55.0
+1100
@@ -63,11 +63,17 @@
#include asm/sections.h
#include asm/io.h
#include asm/irq.h
+
+#ifdef CONFIG_PPC_PMAC
#include asm/prom.h
#include asm/machdep.h
#include asm/pmac_feature.h
#include asm/dbdma.h
#include asm/macio.h
+#else
+#include linux/platform_device.h
+#define machine_is_compatible(x) (0)
+#endif
#if defined (CONFIG_SERIAL_PMACZILOG_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
@@ -83,11 +89,9 @@
static char version[] __initdata = pmac_zilog: 0.6 (Benjamin Herrenschmidt
b...@kernel.crashing.org);
MODULE_AUTHOR(Benjamin Herrenschmidt b...@kernel.crashing.org);
-MODULE_DESCRIPTION(Driver for the PowerMac serial ports.);
+MODULE_DESCRIPTION(Driver for the Mac and PowerMac serial ports.);
MODULE_LICENSE(GPL);
-#define PWRDBG(fmt, arg...)printk(KERN_DEBUG fmt , ## arg)
-
#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
#define
Re: Allocator MAX_ORDER exceeds SECTION_SIZE
On Sunday 10 January 2010 14:31:09 Michael Buesch wrote: I get the following compilation failure, if 64k pages is selected on 2.6.32.3 on a PowerMAC config: include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Any idea? Ok, I figured out that lowering CONFIG_FORCE_MAX_ZONEORDER from 13 to 9 seems to fix the problem. That error message could really need some improvement and at least a hint on what to do and why. I'm also wondering, if the kconfig entry for CONFIG_FORCE_MAX_ZONEORDER could somehow be limited to 9, if 64k pages is enabled. -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI-PCI bridge scanning broken on 460EX
On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote: I now have a custom board with 460EX and the same PLX bridge, running 2.6.23-rc3 Things look better here, as u-boot is now able to properly detect PLX and device behind it, but kernel still has problems. First, I'm still getting hard reset on pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses ~0xff); If this line is removed, PLX is detected twice, see below. I also get hard reset if pass test is modified as you requested and broken test removed. Any ideas how to fix this ? I was suspecting PLX evaluation board, but PLX on our custom board seems to be OK, so it looks like kernel needs fixing. I have no idea no. It looks like something is wrong with the PLX bridge but again, I don't know why that would cause the 460EX to hard reset like that, unless some of the PCIe error handling of the 460 has been configured to cause such a reset on some kind of errors (which it shouldn't at least not in host mode). Can you try instead of writing all the bus number related registers in one single dword write above, writing them byte by byte ? Which one is causing the reset ? Does it reset whatever the value you write there is ? It looks like something is causing a hard reset as soon as you try to configure the PLX bridge and without configuring it properly I fail to see how you'll get things working. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Allocator MAX_ORDER exceeds SECTION_SIZE
On Sun, 2010-01-10 at 19:15 +0100, Michael Buesch wrote: On Sunday 10 January 2010 14:31:09 Michael Buesch wrote: I get the following compilation failure, if 64k pages is selected on 2.6.32.3 on a PowerMAC config: include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Any idea? Ok, I figured out that lowering CONFIG_FORCE_MAX_ZONEORDER from 13 to 9 seems to fix the problem. That error message could really need some improvement and at least a hint on what to do and why. I'm also wondering, if the kconfig entry for CONFIG_FORCE_MAX_ZONEORDER could somehow be limited to 9, if 64k pages is enabled. There's some stuff in there to try to change the max order but KConfig never quite get it right I think. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI-PCI bridge scanning broken on 460EX
Benjamin Herrenschmidt wrote: On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote: I now have a custom board with 460EX and the same PLX bridge, running 2.6.23-rc3 Things look better here, as u-boot is now able to properly detect PLX and device behind it, but kernel still has problems. First, I'm still getting hard reset on pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses ~0xff); If this line is removed, PLX is detected twice, see below. I also get hard reset if pass test is modified as you requested and broken test removed. Any ideas how to fix this ? I was suspecting PLX evaluation board, but PLX on our custom board seems to be OK, so it looks like kernel needs fixing. I have no idea no. It looks like something is wrong with the PLX bridge but again, I don't know why that would cause the 460EX to hard reset like that, unless some of the PCIe error handling of the 460 has been configured to cause such a reset on some kind of errors (which it shouldn't at least not in host mode). Can you try instead of writing all the bus number related registers in one single dword write above, writing them byte by byte ? Which one is causing the reset ? Does it reset whatever the value you write there is ? It looks like something is causing a hard reset as soon as you try to configure the PLX bridge and without configuring it properly I fail to see how you'll get things working. OK, I'll try writing byte by byte. The funny thing is the u-boot also writes the same value to PCI_PRIMARY_BUS register and it doesn't cause reset. Thanks a lot. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI-PCI bridge scanning broken on 460EX
OK, I'll try writing byte by byte. The funny thing is the u-boot also writes the same value to PCI_PRIMARY_BUS register and it doesn't cause reset. Maybe the bridge doesn't want to be programmed more than once on these registers ? In any case, that's very very fishy I wonder if the bridge is causing a PCI reset -upstream- (which would really be a weird thing to do) and the 460 is turning that into a system reset ? Check if there are ways to control how the 460 reacts to PCI resets... In any case, it looks like a fucked up bridge to me. I don't suppose you've seen anything in the bridge data sheet or errata sheet that could explain what it's doing ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote: On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote: Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm) and I'll leave it to you guys to figure out what this _means_: I've failed to reproduce so far on both a Wallstreet powerbook (similar generation and chipset as your beige G3) and a G5 with an added serial port using current upstream... Can you verify it's still there ? I might be able to reproduce on a Beige G3 as well next week. It's still there on qemu 0.11.0's g3beige emulation when you use CONFIG_SERIAL_PMACZILOG as the serial console. (QEMU 0.10.x used a 16550 serial chip for its g3beige emulation instead of the actual ZILOG one.) Still dunno if it's a qemu or bug or a kernel bug, I just know that kernel patch fixes it for me, and it comes back without the patch. I tested 2.6.32. Haven't tried the 2.6.32.3 but don't see why it would change this... Ok so I compiled qemu and things are a bit strange. How do you get the output of both channels of the serial port with it ? If I use -nographics, what happens is that OpenBIOS, for some reason, tells qemu that the console on the second channel of the ESCC. I see my kernel messages in the console if I do console=ttyPZ0 but the debug stuff goes where udbg initializes it, which is where OpenBIOS says the FW console is, which is channel B and I don't know how to see that with qemu. I do see it crash due to a message from the kernel but I can't get into xmon which is a pain. If I modify the kernel to force udbg on channel A (same channel as the console), then the problem doesn't appear (it doesn't crash) :-) Cheers Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
'bd == ugeth-txBd[txQ]' has two possible statuses: 1)full queue.
2)empty queue.
Removing 'netif_queue_stopped() == 0' will make transmitting stopping
when the queue is full.
I made a new patch for this oops.
From 726765194352d01dc8ea672d97612589b67cec3f Mon Sep 17 00:00:00 2001
From: Jiajun Wu b06...@freescale.com
Date: Mon, 11 Jan 2010 10:57:22 +0800
Subject: [PATCH] ucc_geth: Fix empty TX queue processing
Signed-off-by: Jiajun Wu b06...@freescale.com
---
drivers/net/ucc_geth.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index f982220..34345f0 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3576,17 +3576,17 @@ static int ucc_geth_tx(struct net_device *dev,
u8 txQ)
while ((bd_status T_R) == 0) {
struct sk_buff *skb;
+ skb = ugeth-tx_skbuff[txQ][ugeth-skb_dirtytx[txQ]];
+
/* BD contains already transmitted buffer. */
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
- if ((bd == ugeth-txBd[txQ])
(netif_queue_stopped(dev) == 0))
+ if ((bd == ugeth-txBd[txQ]) (skb == NULL))
break;
dev-stats.tx_packets++;
- skb = ugeth-tx_skbuff[txQ][ugeth-skb_dirtytx[txQ]];
-
if (skb_queue_len(ugeth-rx_recycle) RX_BD_RING_LEN
skb_recycle_check(skb,
ugeth-ug_info-uf_info.max_rx_buf_length +
--
1.5.6.3
-Original Message-
From: linuxppc-dev-bounces+b13201=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+b13201=freescale@lists.ozlabs.org] On
Behalf Of Anton Vorontsov
Sent: Thursday, December 24, 2009 11:31 PM
To: David Miller
Cc: linuxppc-...@ozlabs.org; net...@vger.kernel.org; Lennart Sorensen
Subject: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
---
Following oops was seen with the ucc_geth driver:
Unable to handle kernel paging request for data at address 0x0058
Faulting instruction address: 0xc024f2fc
Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c024f2fc]
skb_recycle_check+0x14/0x100 LR [e30aa0a4] ucc_geth_poll+0xd8/0x4e0
[ucc_geth_driver] Call Trace:
[df857d50] [c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable)
[df857d60] [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver]
[df857dd0] [c0258cf8] net_rx_action+0xf8/0x1b8 [df857e10] [c0032a38]
__do_softirq+0xb8/0x13c [df857e60] [c00065cc] do_softirq+0xa0/0xac
[...]
This is because ucc_geth_tx() tries to process an empty queue when
queues are logically stopped. Stopping the queues doesn't disable
polling, and since nowadays ucc_geth_tx() is actually called from the
polling routine, the oops above might pop up.
Fix this by removing 'netif_queue_stopped() == 0' check.
Reported-by: Lennart Sorensen lsore...@csclub.uwaterloo.ca
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Tested-by: Lennart Sorensen lsore...@csclub.uwaterloo.ca
Cc: Stable sta...@vger.kernel.org [2.6.32]
---
drivers/net/ucc_geth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
afaf088..0f8c99e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3273,7 +3273,7 @@ static int ucc_geth_tx(struct net_device *dev, u8
txQ)
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
- if ((bd == ugeth-txBd[txQ])
(netif_queue_stopped(dev) == 0))
+ if (bd == ugeth-txBd[txQ]) /* queue empty? */
break;
dev-stats.tx_packets++;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] pmac_zilog: Workaround problem due to interrupt on closed port
It seems that in qemu, we can see an interrupt in R3 despite the
fact that it's masked in W1. The chip doesn't actually issue an
interrupt, but we can see it when taking an interrupt for the
other channel. This may be a qemu bug ... or not, so let's be
safe and avoid calling into the UART layer when that happens which
woulc cause a crash.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
David: This would affect sunzilog as well I believe. I'm not sure
if it's a bug in qemu emulation of the ESCC or if a real ESCC can
show it so I decided to be safe :-) The ESCC doc I have doesn't
appear to specify whether the interrupt status bits in R3 are
prior or post masking by W1. I can reproduce that by having the
kernel low level udbg debug console on channel B and the main
console on channel A (which is itself an uncommon setup).
diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
index 0700cd1..683e66f 100644
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -411,6 +411,17 @@ static void pmz_transmit_chars(struct uart_pmac_port *uap)
goto ack_tx_int;
}
+ /* Under some circumstances, we see interrupts reported for
+* a closed channel. The interrupt mask in R1 is clear, but
+* R3 still signals the interrupts and we see them when taking
+* an interrupt for the other channel (this could be a qemu
+* bug but since the ESCC doc doesn't specify precsiely whether
+* R3 interrup status bits are masked by R1 interrupt enable
+* bits, better safe than sorry). --BenH.
+*/
+ if (!ZS_IS_OPEN(uap))
+ goto ack_tx_int;
+
if (uap-port.x_char) {
uap-flags |= PMACZILOG_FLAG_TX_ACTIVE;
write_zsdata(uap, uap-port.x_char);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: fsldma: cleanup driver and fix async_tx compatibility
Hi Ira, I have tested your patches with async DMA memcpy support. Though I haven't captured the improvement figures. It works fine for RAID5 memcpy offload as interrupts are coming for separate DMA channels while I have ran IOZONE onto RAID partition. Regards, Dipen -Original Message- From: Dudhat Dipen-B09055 Sent: Tuesday, January 05, 2010 11:38 AM To: 'Ira W. Snyder'; dan.j.willi...@intel.com Cc: ga...@kernel.crashing.org; herb...@gondor.apana.org.au; Tabi Timur-B04825; linuxppc-...@ozlabs.org; Suresh Vishnu-B05022; Gupta Maneesh-B18878; Li Yang-R58472 Subject: RE: fsldma: cleanup driver and fix async_tx compatibility Hi Ira, I will test it on 85xx hardware and let you know once done. Thanks Dipen -Original Message- From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] Sent: Friday, January 01, 2010 11:41 AM To: dan.j.willi...@intel.com Cc: ga...@kernel.crashing.org; herb...@gondor.apana.org.au; Tabi Timur-B04825; linuxppc-...@ozlabs.org; Suresh Vishnu-B05022; Dudhat Dipen-B09055; Gupta Maneesh-B18878; Li Yang-R58472 Subject: fsldma: cleanup driver and fix async_tx compatibility This patch series cleans up the Freescale DMAEngine driver, including verifying the locking and making sure that all code paths are correct. There were a few places that seemed suspicious, and they have been fixed. I have written a quick memory-memory DMAEngine test driver, and the performance is identical before and after my changes (0.1% change). I measured both setting up the DMA operation (via device_prep_dma_interrupt() and device_prep_dma_memcpy()) and the actual DMA transfer itself. As an added bonus, the interrupt load is measurably reduced. My test driver transfers 32MB as 32x 1MB chunks + 1 interrupt descriptor, using the functions noted above. Previous to this patch series, 31 interrupts were generated. After this patch series, only a single interrupt is generated for the whole transaction. Some testing on 85xx/86xx hardware would be appreciated. Also, some testing by the users attempting to use async_tx and talitos to handle RAID offload would be great as well. Documentation/powerpc/dts-bindings/fsl/dma.txt | 17 +- drivers/dma/fsldma.c | 1036 drivers/dma/fsldma.h | 35 +- 3 files changed, 556 insertions(+), 532 deletions(-) Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
Please see my answers in line.
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, January 03, 2010 10:25 PM
To: Tirumala Reddy Marri
Cc: jwbo...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org;
linuxppc-...@ozlabs.org; writetoma...@yahoo.com
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
On Wed, 2009-12-23 at 23:28 -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
---
When 460SX configured as root as a end point E1000(Intell Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run the
traffic
with MSI interrupts.
So before I even ack or nack that patch, I need to better understand how
your HW works. I've read the doc of the 460EX twice and still don't
quite get it :-)
So my understanding so far is that when reception of MSIs is enabled,
writes to some magic address in the first 1K of BAR0 are interpreted ad
MSIs. The MSI interrupt value (low 16 bits of the 32-bit store in little
endian) is thus interpreted as an interrupt number and send to the UIC.
Is that correct ?
Marri: You are somewhat right. There are two ways to cause the interrupts.
In first case MSI is generated to root complex by writing to a Address region
from Endpoint which is mapped to root-complex side MSI Area.
In second case
root complex
writes the 64bit MSI address and data pattern in the Endpoint configuration
space. Then endpoint side cpu will write to register in the PCI-E interrupt
handler register MSIASS(MSI software assert ), this would trigger a memory
write transaction on the PCI-E bus with address from the config space and data
from data register. As soon as this trans action comes on the BUS PCI-E handler
on root complex snoops for this address and checks against the data received.
If it matches it would cause appropriate interrupt number based on the data
Received. For example for interrupt 1 , data would be 0x and interrupt
2 data would be 0x0001 .
Now, which UIC ? There are at least 3 in the 460EX for example :-)
Marri: Each of 4 MSI is mapped to UIC0 12,13,14 15 interrupt numbers
Also, UICs have a limited amount of inputs and I don't see many
interrupt sources reserved for use as MSIs, can you enlighten me a bit
more on how you get to choose an interrupt source to use as MSI ?
Marri: There are 4 MIS's or 15 MSI-X interrupts can be enabled. Each MSI is hard
Wired to UIC0 12 to 15. For MSI-X UIC-3 12 to 27.
Or is there some translation done ? IE. In the 460EX manual, there seem
to be specific interrupt numbers dedicated to PCI0 MSI 0, 1 2 and 3
spread between UIC0 and UIC1, and a block of 8 interrupts in UIC3
reserved for PCI-E MSIs. Is there a renumbering done in HW here ?
IE. Your table shows for 460EX for example that PCI-E MSI 2 is UIC3
input 26. Do I need thus to program the device to write a 2 in the MSI
message or 26 to hit that interrupt ?
IE. Are you running the input message through a binary decoder that then
spreads into various UIC input lines ?
Marri: Yes each MSI is hard wired to different interrupt number in UIC
registers.
MIS interrupt number to UIC is not programmable . It is fixed.
Now some comments:
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..6c20faf 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D
*/;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = amcc,ppc4xx-460sx-msi, ppc4xx-msi;
+ reg = 0x4 0x0030 0x100
+ 0x4 0x0030 0x100;
+ sdr-base = 0x3B0;
+ interrupts =0 1 2 3;
+ interrupt-parent = MSI;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 UIC0 0xC 1
+ 1 UIC0 0x0D 1
+ 2 UIC0 0x0E 1
+ 3 UIC0 0x0F 1;
+ };
Wow ! That's the mother of all device-tree hacks :-) So you are using
the interrupts property of the MSI node to represent the MSI
interrupts you hand out, and you make it its own interrupt-parent, using
an interrupt-map in itself to convert them into UIC interrupts :-)
Sneaky... Hell, it will work so why not ?
Marri: BTW there are some other processors using the similar way.
+static struct ppc4xx_msi *ppc4xx_msi;
+
+struct ppc4xx_msi_feature {
+ u32 ppc4xx_pic_ip;
+ u32 msiir_offset;
+};
+
+static int
Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
On Sunday 10 January 2010 21:02:16 Benjamin Herrenschmidt wrote: On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote: On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote: Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm) and I'll leave it to you guys to figure out what this _means_: I've failed to reproduce so far on both a Wallstreet powerbook (similar generation and chipset as your beige G3) and a G5 with an added serial port using current upstream... Can you verify it's still there ? I might be able to reproduce on a Beige G3 as well next week. It's still there on qemu 0.11.0's g3beige emulation when you use CONFIG_SERIAL_PMACZILOG as the serial console. (QEMU 0.10.x used a 16550 serial chip for its g3beige emulation instead of the actual ZILOG one.) Still dunno if it's a qemu or bug or a kernel bug, I just know that kernel patch fixes it for me, and it comes back without the patch. I tested 2.6.32. Haven't tried the 2.6.32.3 but don't see why it would change this... Ok so I compiled qemu and things are a bit strange. How do you get the output of both channels of the serial port with it ? If I use -nographics, what happens is that OpenBIOS, for some reason, tells qemu that the console on the second channel of the ESCC. Instead of -nographic, you could try -serial stdio instead? I see my kernel messages in the console if I do console=ttyPZ0 but the debug stuff goes where udbg initializes it, which is where OpenBIOS says the FW console is, which is channel B and I don't know how to see that with qemu. I'm just trying to get a serial console, which is why I'm booting the sucker with: qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-powerpc -hda image-powerpc.sqf -append root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttyS0 I didn't even know there were more debug messages... I have CONFIG_SERIAL_PMACZILOG_TTYS=y of course: pmac_zilog: 0.6 (Benjamin Herrenschmidt b...@kernel.crashing.org) ttyS0 at MMIO 0x80813020 (irq = 16) is a Z85c30 ESCC - Serial port ttyS1 at MMIO 0x80813000 (irq = 17) is a Z85c30 ESCC - Serial port CONFIG_SERIO=y CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y I do see it crash due to a message from the kernel but I can't get into xmon which is a pain. Does the -serial stdio thing help? (I know to switch between screens in the qemu x11 window, it's ctrl-alt-number (so ctrl-alt-1, ctrl-alt-2, and so on. I really don't use 'em much, though.) If I modify the kernel to force udbg on channel A (same channel as the console), then the problem doesn't appear (it doesn't crash) :-) You can attach gdb to qemu via the qemu -s option and then in gdb use the target remote stuff like you would with gdbserver. It acts a bit like you've connected it to a jtag through openocd, if that helps... (I know qemu has many, many options I don't really use much.) Cheers Ben. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
