* [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Piotr Ziecik @ 2009-03-16 10:05 UTC (permalink / raw)
To: LinuxPPC Mailing List; +Cc: Piotr Ziecik
In-Reply-To: <20090311222615.63410@gmx.net>
BestComm, a DMA engine in MPC52xx SoC, requires snooping when
CPU caches are enabled to work properly.
Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code'.
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
---
This patch was succesfully tested on our MPC5200-based.
Ben, Gerhard could you ack this patch, as it implements your suggestion.
arch/powerpc/include/asm/cputable.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index b18358f..22dc2d8 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -241,9 +241,11 @@ extern const char *powerpc_base_platform;
/* We need to mark all pages as being coherent if we're SMP or we have a
* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
* require it for PCI "streaming/prefetch" to work properly.
+ * This is also required by 52xx family.
*/
#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
- || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
+ || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260) \
+ || defined(CONFIG_PPC_MPC52xx)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
--
1.6.0.6
^ permalink raw reply related
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-16 9:42 UTC (permalink / raw)
To: Roderick Colenbrander, linuxppc-dev, gerhard_pircher
In-Reply-To: <20090316081854.215310@gmx.net>
-------- Original-Nachricht --------
> Datum: Mon, 16 Mar 2009 09:18:54 +0100
> Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> -------- Original-Nachricht --------
> > Datum: Sun, 15 Mar 2009 11:43:13 +0100
> > Von: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> > An: "Roderick Colenbrander" <thunderbird2k@gmx.net>,
> linuxppc-dev@ozlabs.org
> > Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> >
> > -------- Original-Nachricht --------
> > > Datum: Sun, 15 Mar 2009 09:38:26 +0100
> > > Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> > > An: "Gerhard Pircher" <gerhard_pircher@gmx.net>,
> linuxppc-dev@ozlabs.org
> > > Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
> >
> > > > > At some point in the file they create some (dummy?) pcie section
> in
> > > > > which they define a uli1575, an isa bus and attached to that isa
> bus
> > > > > a i8259. Is this the correct way of doing things? The i8259 driver
> > > > > seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
> > > > > defined below but how are those mapped to the south bridge? I have
> > > > > seen some code in kernel/isa-bridge, is that code indeed
> responsible
> > > > > for setting up these ports?
> > > > Yes, the pcie node is the PCI host bridge node and the uli1571 node
> > > > acts as PCI2ISA bridge node. AFAIK their ranges properties are
> parsed
> > > > by pci_process_bridge_OF_ranges().
> > > > IIRC the code in kernel/isa-bridge is used for 64bit PPC machines
> only
> > > > for now. The I/O addresses for the i8259 PIC are currently hardcoded
> > > > and setup (request_resource()) in sysdev/i8259.c.
> > >
> > > I got the i8259 south bridge working now after adding an io_base_virt
> > > offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
> > > the troubles to add ppc32 support to isa-bridge.c? The whole point of
> > > the code is basically to remap the io memory to low addresses for
> these
> > > 64-bit ppc systems (mainly freescale boards with a i8259 and pseries
> > > systems with a i8259).
> > pci_process_bridge_OF_ranges() should "ioremap" io_base_virt for you,
> > if your board has only one PCI I/O space. It also sets isa_io_base to
> > io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
> > PCI I/O address 0x0. Isn't that the case for your board?
> >
> > > As far as I have seen it is only needed for i8259 interrupt
> controllers.
> > > Personally I think it would be better to pass a io base offset to
> > > i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
> > > I'm not sure what the proper layout would be for this in the dts file
> > > though.
> > I think adding an io base offset parameter to i8259_setup isn't the
> > right way to do it. I would expect other problems too, if ISA I/O space
> > isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
> > experienced kernel developer can comment on this?
>
> I'm now back behind my ML510 board and have been doing some tests. As I
> mentioned before I was doing inb(isa_io_base + port) / outb(val, isa_io_base
> + port) which worked fine. As far as I see it the problem is the definition
> of inb/outb on ppc32 they don't take isa_io_base into account. They are:
> __do_in_asm(_rec_inb, "lbzx")
> __do_out_asm(_rec_outb, "stbx")
> #define __do_outb(val, port) _rec_outb(val, port)
> #define __do_inb(port) _rec_inb(port)
>
> While on 64-bit ppc they are:
> #define __do_outb(val, port) writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
> #define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port);
>
> (On ppc32 _IO_BASE is isa_io_base but on 64-bit it is set to pci_io_base)
>
> Am I correct that inb/outb are broken on ppc32? If so what is the right
> way to fix them?
>
> Regards,
> Roderick
I just talked about this on IRC with Benjamin Herrenschmidt and I misunderstood the inb/outb command. the commands are using _IO_PORTS and I must be doing something wrong.
Roderick
--
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* [PATCH 3/3] PowerPC: MPC85xx: TQM8548: update defconfig
From: Wolfgang Grandegger @ 2009-03-16 8:57 UTC (permalink / raw)
To: linuxppc-dev
Enable highmem support for the TQM8548-AG modules and NAND support for
the TQM8548-BE modules. Furthermore disable USB, Wireless and IDE support
because it's not available on the STK85xx starter kit.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/configs/85xx/tqm8548_defconfig | 164 ++++++++-------------------
1 files changed, 48 insertions(+), 116 deletions(-)
diff --git a/arch/powerpc/configs/85xx/tqm8548_defconfig b/arch/powerpc/configs/85xx/tqm8548_defconfig
index 0bc4597..43030fe 100644
--- a/arch/powerpc/configs/85xx/tqm8548_defconfig
+++ b/arch/powerpc/configs/85xx/tqm8548_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.29-rc2
-# Mon Jan 26 15:36:20 2009
+# Linux kernel version: 2.6.29-rc7
+# Mon Mar 16 09:03:28 2009
#
# CONFIG_PPC64 is not set
@@ -22,6 +22,7 @@ CONFIG_FSL_EMB_PERFMON=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
CONFIG_PPC_MMU_NOHASH=y
+CONFIG_PPC_BOOK3E_MMU=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
@@ -75,6 +76,15 @@ CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_GROUP_SCHED=y
@@ -152,11 +162,6 @@ CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
-CONFIG_CLASSIC_RCU=y
-# CONFIG_TREE_RCU is not set
-# CONFIG_PREEMPT_RCU is not set
-# CONFIG_TREE_RCU_TRACE is not set
-# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_FREEZER is not set
#
@@ -202,7 +207,7 @@ CONFIG_MPIC=y
#
# Kernel options
#
-# CONFIG_HIGHMEM is not set
+CONFIG_HIGHMEM=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
@@ -244,6 +249,7 @@ CONFIG_UNEVICTABLE_LRU=y
CONFIG_PPC_4K_PAGES=y
# CONFIG_PPC_16K_PAGES is not set
# CONFIG_PPC_64K_PAGES is not set
+# CONFIG_PPC_256K_PAGES is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
@@ -259,6 +265,7 @@ CONFIG_ZONE_DMA=y
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_FSL_SOC=y
CONFIG_FSL_PCI=y
+CONFIG_FSL_LBC=y
CONFIG_PPC_PCI_CHOICE=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
@@ -284,10 +291,11 @@ CONFIG_ARCH_SUPPORTS_MSI=y
# Default settings for advanced configuration options are used
#
CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_LOWMEM_CAM_NUM=3
CONFIG_PAGE_OFFSET=0xc0000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_PHYSICAL_START=0x00000000
-CONFIG_PHYSICAL_ALIGN=0x10000000
+CONFIG_PHYSICAL_ALIGN=0x04000000
CONFIG_TASK_SIZE=0xc0000000
CONFIG_NET=y
@@ -363,12 +371,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
-CONFIG_WIRELESS=y
-# CONFIG_CFG80211 is not set
-CONFIG_WIRELESS_OLD_REGULATORY=y
-# CONFIG_WIRELESS_EXT is not set
-# CONFIG_LIB80211 is not set
-# CONFIG_MAC80211 is not set
+# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
@@ -471,27 +474,18 @@ CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_NAND_FSL_ELBC is not set
-# CONFIG_MTD_NAND_FSL_UPM is not set
+CONFIG_MTD_NAND_FSL_UPM=y
# CONFIG_MTD_ONENAND is not set
#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
-# CONFIG_MTD_QINFO_PROBE is not set
#
# UBI - Unsorted block images
#
-CONFIG_MTD_UBI=m
-CONFIG_MTD_UBI_WL_THRESHOLD=4096
-CONFIG_MTD_UBI_BEB_RESERVE=1
-# CONFIG_MTD_UBI_GLUEBI is not set
-
-#
-# UBI debugging options
-#
-# CONFIG_MTD_UBI_DEBUG is not set
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
# CONFIG_PARPORT is not set
@@ -515,69 +509,21 @@ CONFIG_BLK_DEV_RAM_SIZE=32768
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_PHANTOM is not set
-# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_C2PORT is not set
+
+#
+# EEPROM support
+#
+# CONFIG_EEPROM_AT24 is not set
+# CONFIG_EEPROM_LEGACY is not set
+# CONFIG_EEPROM_93CX6 is not set
CONFIG_HAVE_IDE=y
-CONFIG_IDE=y
-
-#
-# Please see Documentation/ide/ide.txt for help/info on IDE drives
-#
-CONFIG_IDE_TIMINGS=y
-# CONFIG_BLK_DEV_IDE_SATA is not set
-CONFIG_IDE_GD=y
-CONFIG_IDE_GD_ATA=y
-# CONFIG_IDE_GD_ATAPI is not set
-# CONFIG_BLK_DEV_IDECD is not set
-# CONFIG_BLK_DEV_IDETAPE is not set
-# CONFIG_IDE_TASK_IOCTL is not set
-CONFIG_IDE_PROC_FS=y
-
-#
-# IDE chipset support/bugfixes
-#
-# CONFIG_BLK_DEV_PLATFORM is not set
-CONFIG_BLK_DEV_IDEDMA_SFF=y
-
-#
-# PCI IDE chipsets support
-#
-CONFIG_BLK_DEV_IDEPCI=y
-CONFIG_IDEPCI_PCIBUS_ORDER=y
-# CONFIG_BLK_DEV_OFFBOARD is not set
-CONFIG_BLK_DEV_GENERIC=y
-# CONFIG_BLK_DEV_OPTI621 is not set
-CONFIG_BLK_DEV_IDEDMA_PCI=y
-# CONFIG_BLK_DEV_AEC62XX is not set
-# CONFIG_BLK_DEV_ALI15X3 is not set
-# CONFIG_BLK_DEV_AMD74XX is not set
-# CONFIG_BLK_DEV_CMD64X is not set
-# CONFIG_BLK_DEV_TRIFLEX is not set
-# CONFIG_BLK_DEV_CS5520 is not set
-# CONFIG_BLK_DEV_CS5530 is not set
-# CONFIG_BLK_DEV_HPT366 is not set
-# CONFIG_BLK_DEV_JMICRON is not set
-# CONFIG_BLK_DEV_SC1200 is not set
-# CONFIG_BLK_DEV_PIIX is not set
-# CONFIG_BLK_DEV_IT8172 is not set
-# CONFIG_BLK_DEV_IT8213 is not set
-# CONFIG_BLK_DEV_IT821X is not set
-# CONFIG_BLK_DEV_NS87415 is not set
-# CONFIG_BLK_DEV_PDC202XX_OLD is not set
-# CONFIG_BLK_DEV_PDC202XX_NEW is not set
-# CONFIG_BLK_DEV_SVWKS is not set
-# CONFIG_BLK_DEV_SIIMAGE is not set
-# CONFIG_BLK_DEV_SL82C105 is not set
-# CONFIG_BLK_DEV_SLC90E66 is not set
-# CONFIG_BLK_DEV_TRM290 is not set
-CONFIG_BLK_DEV_VIA82CXXX=y
-# CONFIG_BLK_DEV_TC86C001 is not set
-CONFIG_BLK_DEV_IDEDMA=y
+# CONFIG_IDE is not set
#
# SCSI device support
@@ -650,7 +596,7 @@ CONFIG_MII=y
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
-CONFIG_E1000=y
+# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
@@ -668,6 +614,7 @@ CONFIG_GIANFAR=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
+# CONFIG_ATL1C is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
@@ -835,8 +782,6 @@ CONFIG_I2C_MPC=y
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
-# CONFIG_EEPROM_AT24 is not set
-# CONFIG_EEPROM_LEGACY is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
@@ -975,26 +920,7 @@ CONFIG_HID=y
# Special HID drivers
#
CONFIG_HID_COMPAT=y
-CONFIG_USB_SUPPORT=y
-CONFIG_USB_ARCH_HAS_HCD=y
-CONFIG_USB_ARCH_HAS_OHCI=y
-CONFIG_USB_ARCH_HAS_EHCI=y
-# CONFIG_USB is not set
-# CONFIG_USB_OTG_WHITELIST is not set
-# CONFIG_USB_OTG_BLACKLIST_HUB is not set
-
-#
-# Enable Host or Gadget support to see Inventra options
-#
-
-#
-# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed;
-#
-# CONFIG_USB_GADGET is not set
-
-#
-# OTG and related infrastructure
-#
+# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
@@ -1064,16 +990,9 @@ CONFIG_RTC_DRV_DS1307=y
#
# File systems
#
-CONFIG_EXT2_FS=y
-# CONFIG_EXT2_FS_XATTR is not set
-# CONFIG_EXT2_FS_XIP is not set
-CONFIG_EXT3_FS=y
-CONFIG_EXT3_FS_XATTR=y
-# CONFIG_EXT3_FS_POSIX_ACL is not set
-# CONFIG_EXT3_FS_SECURITY is not set
+# CONFIG_EXT2_FS is not set
+# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
-CONFIG_JBD=y
-CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
@@ -1122,8 +1041,17 @@ CONFIG_MISC_FILESYSTEMS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
-# CONFIG_JFFS2_FS is not set
-# CONFIG_UBIFS_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+# CONFIG_JFFS2_LZO is not set
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
@@ -1184,6 +1112,8 @@ CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
@@ -1219,6 +1149,7 @@ CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
+# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
@@ -1236,6 +1167,7 @@ CONFIG_DEBUG_MUTEXES=y
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FUNCTION_TRACER=y
+CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/3] PowerPC: MPC85xx: TQM8548: use proper phy-handles for enet2 and enet3
From: Wolfgang Grandegger @ 2009-03-16 8:57 UTC (permalink / raw)
To: linuxppc-dev
For enet2 and enet3 the wrong phy-handles have been used in DTS files
of the TQM8548 modules.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 4 ++--
arch/powerpc/boot/dts/tqm8548.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index dd43dbe..29a2b6f 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -262,7 +262,7 @@
interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
tbi-handle = <&tbi2>;
- phy-handle = <&phy3>;
+ phy-handle = <&phy4>;
};
enet3: ethernet@27000 {
@@ -275,7 +275,7 @@
interrupts = <37 2 38 2 39 2>;
interrupt-parent = <&mpic>;
tbi-handle = <&tbi3>;
- phy-handle = <&phy4>;
+ phy-handle = <&phy5>;
};
serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index b949a8c..81d3fbb 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -262,7 +262,7 @@
interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
tbi-handle = <&tbi2>;
- phy-handle = <&phy3>;
+ phy-handle = <&phy4>;
};
enet3: ethernet@27000 {
@@ -275,7 +275,7 @@
interrupts = <37 2 38 2 39 2>;
interrupt-parent = <&mpic>;
tbi-handle = <&tbi3>;
- phy-handle = <&phy4>;
+ phy-handle = <&phy5>;
};
serial0: serial@4500 {
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/3] PowerPC: MPC85xx: TQM85xx: correct address of LM75 I2C device nodes
From: Wolfgang Grandegger @ 2009-03-16 8:56 UTC (permalink / raw)
To: linuxppc-dev
Commit 0f73a449a649acfca91404a98a35353a618b9555 added I2C device nodes
for the LM75 thermal sensor on the TQM85xx modules, unfortunately with
the wrong I2C address. The LM75s are located at address 0x48.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8540.dts | 4 ++--
arch/powerpc/boot/dts/tqm8541.dts | 4 ++--
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 4 ++--
arch/powerpc/boot/dts/tqm8548.dts | 4 ++--
arch/powerpc/boot/dts/tqm8555.dts | 4 ++--
arch/powerpc/boot/dts/tqm8560.dts | 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8540.dts b/arch/powerpc/boot/dts/tqm8540.dts
index 39e55ab..da137d8 100644
--- a/arch/powerpc/boot/dts/tqm8540.dts
+++ b/arch/powerpc/boot/dts/tqm8540.dts
@@ -84,9 +84,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/tqm8541.dts b/arch/powerpc/boot/dts/tqm8541.dts
index 58ae8bc..b25fc4c 100644
--- a/arch/powerpc/boot/dts/tqm8541.dts
+++ b/arch/powerpc/boot/dts/tqm8541.dts
@@ -83,9 +83,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index bff380a..dd43dbe 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -85,9 +85,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 112ac90..b949a8c 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -85,9 +85,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/tqm8555.dts b/arch/powerpc/boot/dts/tqm8555.dts
index 4b7da89..fd3777e 100644
--- a/arch/powerpc/boot/dts/tqm8555.dts
+++ b/arch/powerpc/boot/dts/tqm8555.dts
@@ -83,9 +83,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/tqm8560.dts b/arch/powerpc/boot/dts/tqm8560.dts
index 3fa552f..89a7beb 100644
--- a/arch/powerpc/boot/dts/tqm8560.dts
+++ b/arch/powerpc/boot/dts/tqm8560.dts
@@ -85,9 +85,9 @@
interrupt-parent = <&mpic>;
dfsrr;
- dtt@50 {
+ dtt@48 {
compatible = "national,lm75";
- reg = <0x50>;
+ reg = <0x48>;
};
rtc@68 {
--
1.6.0.6
^ permalink raw reply related
* [PATCH 0/3] PowerPC: MPC85xx: TQM85xx: dts and defconfig fixes
From: Wolfgang Grandegger @ 2009-03-16 8:54 UTC (permalink / raw)
To: linuxppc-dev
The following patch series fixes some issues with the DTS files of the
TQM85xx modules and the defconfig for the TQM8548 modules.
The patches are against the "next" branch of Kumar's "powerpc" GIT tree.
Wolfgang.
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-16 8:18 UTC (permalink / raw)
To: Gerhard Pircher, linuxppc-dev
In-Reply-To: <20090315104313.72510@gmx.net>
-------- Original-Nachricht --------
> Datum: Sun, 15 Mar 2009 11:43:13 +0100
> Von: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> An: "Roderick Colenbrander" <thunderbird2k@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> -------- Original-Nachricht --------
> > Datum: Sun, 15 Mar 2009 09:38:26 +0100
> > Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> > An: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> > Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> > > > At some point in the file they create some (dummy?) pcie section in
> > > > which they define a uli1575, an isa bus and attached to that isa bus
> > > > a i8259. Is this the correct way of doing things? The i8259 driver
> > > > seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
> > > > defined below but how are those mapped to the south bridge? I have
> > > > seen some code in kernel/isa-bridge, is that code indeed responsible
> > > > for setting up these ports?
> > > Yes, the pcie node is the PCI host bridge node and the uli1571 node
> > > acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed
> > > by pci_process_bridge_OF_ranges().
> > > IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
> > > for now. The I/O addresses for the i8259 PIC are currently hardcoded
> > > and setup (request_resource()) in sysdev/i8259.c.
> >
> > I got the i8259 south bridge working now after adding an io_base_virt
> > offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
> > the troubles to add ppc32 support to isa-bridge.c? The whole point of
> > the code is basically to remap the io memory to low addresses for these
> > 64-bit ppc systems (mainly freescale boards with a i8259 and pseries
> > systems with a i8259).
> pci_process_bridge_OF_ranges() should "ioremap" io_base_virt for you,
> if your board has only one PCI I/O space. It also sets isa_io_base to
> io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
> PCI I/O address 0x0. Isn't that the case for your board?
>
> > As far as I have seen it is only needed for i8259 interrupt controllers.
> > Personally I think it would be better to pass a io base offset to
> > i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
> > I'm not sure what the proper layout would be for this in the dts file
> > though.
> I think adding an io base offset parameter to i8259_setup isn't the
> right way to do it. I would expect other problems too, if ISA I/O space
> isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
> experienced kernel developer can comment on this?
I'm now back behind my ML510 board and have been doing some tests. As I mentioned before I was doing inb(isa_io_base + port) / outb(val, isa_io_base + port) which worked fine. As far as I see it the problem is the definition of inb/outb on ppc32 they don't take isa_io_base into account. They are:
__do_in_asm(_rec_inb, "lbzx")
__do_out_asm(_rec_outb, "stbx")
#define __do_outb(val, port) _rec_outb(val, port)
#define __do_inb(port) _rec_inb(port)
While on 64-bit ppc they are:
#define __do_outb(val, port) writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
#define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port);
(On ppc32 _IO_BASE is isa_io_base but on 64-bit it is set to pci_io_base)
Am I correct that inb/outb are broken on ppc32? If so what is the right way to fix them?
Regards,
Roderick
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* [PATCH] powerpc/cell: fix unused variable warning in interrupt.c
From: Stephen Rothwell @ 2009-03-16 7:52 UTC (permalink / raw)
To: Ingo Molnar; +Cc: ppc-dev, linux-next, Yinghai Lu, LKML
In-Reply-To: <20090202174817.dd4a26f0.sfr@canb.auug.org.au>
arch/powerpc/platforms/cell/interrupt.c: In function 'handle_iic_irq':
arch/powerpc/platforms/cell/interrupt.c:240: warning: unused variable 'cpu'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/cell/interrupt.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
On Mon, 2 Feb 2009 17:48:17 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
>
> arch/powerpc/platforms/cell/interrupt.c: In function 'handle_iic_irq':
> arch/powerpc/platforms/cell/interrupt.c:240: warning: unused variable 'cpu'
>
> Caused by commit dee4102a9a5882b4f7d5cc165ba29e8cc63cf92e ("sparseirq:
> use kstat_irqs_cpu instead").
This patch is relative to next-20090312 and updates the sparseirq tree.
diff --git a/arch/powerpc/platforms/cell/interrupt.c b/arch/powerpc/platforms/cell/interrupt.c
index 1f0d774..882e470 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -237,8 +237,6 @@ extern int noirqdebug;
static void handle_iic_irq(unsigned int irq, struct irq_desc *desc)
{
- const unsigned int cpu = smp_processor_id();
-
spin_lock(&desc->lock);
desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
--
1.6.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Michael Neuling @ 2009-03-16 6:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Will Schmidt, Steven Munroe
In-Reply-To: <1237164566.25062.114.camel@pasglop>
> > We can do some VMX testing on existing POWER6 machines. The VSX
> > instruction set hasn't been fully implemented in GCC yet so we'll need
> > to wait a bit for that. Does anyone have an idea for a good VMX/Altivec
> > benchmark?
>
> Note that there are two aspects to the problem:
>
> - Lazy save/restore on SMP. This would avoid both the save and restore
> phases, thus is where the most potential gain is to be made. At the
> expense of some tricky IPI work when processes migrate between CPUs.
>
> However, it will only be useful -if- a process using FP/VMX/VSX is
> "interrupted" by another process that isn't using them. For example, a
> kernel thread. So it's unclear whether that's worth it in practice, ie,
> does this happen that often ?
>
> - Always restoring the FP/VMX/VSX state on context switch "in" rather
> than taking a fault. This is reasonably simple, but at the potential
> expense of adding the save/restore overhead to applications that only
> seldomly use these facilities. (Some heuristics might help here).
>
> However, the question here what do this buy us ?
>
> IE, In the worst case scenario, which is HZ=1000, so every 1ms, the
> process would have the overhead of an interrupt to do the restore of the
> state. IE. The restore state itself doesn't count since it would be done
> either way (at context switch vs. in the unavailable interrupt), so all
> we win here is the overhead of the actual interrupt, which is
> implemented as a fast interrupt in assembly. So we have what here ? 1000
> cycles to be pessimistic ? On a 1Ghz CPU, that is 1/1000 of the time
> slice, and both of these are rather pessimistic numbers.
>
> So that leaves us with the possible case of 2 tasks using the facility
> and running a fraction of the timeslice each, for example because they
> are ping-ponging with each other.
>
> Is that something that happens in practice to make it noticeable ?
I hacked up the below to put stats in /proc/self/sched.
A quick grep through /proc on a rhel5.2 machine (egrep
'(fp_count|switch_count)' /proc/*/sched) shows a few apps use fp a few
dozen times but then stop. This is only init apps like hald, so need to
check some real world apps too.
Ryan: let me know if this allows you to collect some useful stats.
Subject: [PATCH] powerpc: add context switch, fpr & vr stats to /proc/self/sched.
Add a counter for every task switch, fp and vr exception to
/proc/self/sched.
[root@p5-20-p6-e0 ~]# cat /proc/3422/sched |tail -3
switch_count : 559
fp_count : 317
vr_count : 0
[root@p5-20-p6-e0 ~]#
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/processor.h | 3 +++
arch/powerpc/kernel/asm-offsets.c | 3 +++
arch/powerpc/kernel/fpu.S | 3 +++
arch/powerpc/kernel/process.c | 3 +++
arch/powerpc/kernel/setup-common.c | 10 ++++++++++
include/linux/seq_file.h | 12 ++++++++++++
kernel/sched_debug.c | 16 ++++------------
7 files changed, 38 insertions(+), 12 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/processor.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/processor.h
@@ -174,11 +174,13 @@ struct thread_struct {
} fpscr;
int fpexc_mode; /* floating-point exception mode */
unsigned int align_ctl; /* alignment handling control */
+ unsigned long fp_count; /* FP restore count */
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
#endif
unsigned long dabr; /* Data address breakpoint register */
+ unsigned long switch_count; /* switch count */
#ifdef CONFIG_ALTIVEC
/* Complete AltiVec register set */
vector128 vr[32] __attribute__((aligned(16)));
@@ -186,6 +188,7 @@ struct thread_struct {
vector128 vscr __attribute__((aligned(16)));
unsigned long vrsave;
int used_vr; /* set if process has used altivec */
+ unsigned long vr_count; /* VSX restore count */
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
/* VSR status */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
@@ -74,14 +74,17 @@ int main(void)
DEFINE(KSP, offsetof(struct thread_struct, ksp));
DEFINE(KSP_LIMIT, offsetof(struct thread_struct, ksp_limit));
DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
+ DEFINE(THREAD_SWITCHCOUNT, offsetof(struct thread_struct, switch_count));
DEFINE(THREAD_FPEXC_MODE, offsetof(struct thread_struct, fpexc_mode));
DEFINE(THREAD_FPR0, offsetof(struct thread_struct, fpr[0]));
DEFINE(THREAD_FPSCR, offsetof(struct thread_struct, fpscr));
+ DEFINE(THREAD_FPCOUNT, offsetof(struct thread_struct, fp_count));
#ifdef CONFIG_ALTIVEC
DEFINE(THREAD_VR0, offsetof(struct thread_struct, vr[0]));
DEFINE(THREAD_VRSAVE, offsetof(struct thread_struct, vrsave));
DEFINE(THREAD_VSCR, offsetof(struct thread_struct, vscr));
DEFINE(THREAD_USED_VR, offsetof(struct thread_struct, used_vr));
+ DEFINE(THREAD_VRCOUNT, offsetof(struct thread_struct, vr_count));
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
DEFINE(THREAD_VSR0, offsetof(struct thread_struct, fpr));
Index: linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/fpu.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S
@@ -102,6 +102,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
ori r12,r12,MSR_FP
or r12,r12,r4
std r12,_MSR(r1)
+ ld r4,THREAD_FPCOUNT(r5)
+ addi r4, r4, 1
+ std r4,THREAD_FPCOUNT(r5)
#endif
lfd fr0,THREAD_FPSCR(r5)
MTFSF_L(fr0)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c
@@ -744,17 +744,20 @@ void start_thread(struct pt_regs *regs,
#endif
discard_lazy_cpu_state();
+ current->thread.switch_count = 0;
#ifdef CONFIG_VSX
current->thread.used_vsr = 0;
#endif
memset(current->thread.fpr, 0, sizeof(current->thread.fpr));
current->thread.fpscr.val = 0;
+ current->thread.fp_count = 0;
#ifdef CONFIG_ALTIVEC
memset(current->thread.vr, 0, sizeof(current->thread.vr));
memset(¤t->thread.vscr, 0, sizeof(current->thread.vscr));
current->thread.vscr.u[3] = 0x00010000; /* Java mode disabled */
current->thread.vrsave = 0;
current->thread.used_vr = 0;
+ current->thread.vr_count = 0;
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_SPE
memset(current->thread.evr, 0, sizeof(current->thread.evr));
Index: linux-2.6-ozlabs/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/setup-common.c
@@ -669,3 +669,13 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+void arch_proc_sched_show_task(struct task_struct *p, struct seq_file *m) {
+ SEQ_printf(m, "%-35s:%21Ld\n",
+ "switch_count", (long long)p->thread.switch_count);
+ SEQ_printf(m, "%-35s:%21Ld\n",
+ "fp_count", (long long)p->thread.fp_count);
+ SEQ_printf(m, "%-35s:%21Ld\n",
+ "vr_count", (long long)p->thread.vr_count);
+}
+
Index: linux-2.6-ozlabs/include/linux/seq_file.h
===================================================================
--- linux-2.6-ozlabs.orig/include/linux/seq_file.h
+++ linux-2.6-ozlabs/include/linux/seq_file.h
@@ -95,4 +95,16 @@ extern struct list_head *seq_list_start_
extern struct list_head *seq_list_next(void *v, struct list_head *head,
loff_t *ppos);
+/*
+ * This allows printing both to /proc/sched_debug and
+ * to the console
+ */
+#define SEQ_printf(m, x...) \
+ do { \
+ if (m) \
+ seq_printf(m, x); \
+ else \
+ printk(x); \
+ } while (0)
+
#endif
Index: linux-2.6-ozlabs/kernel/sched_debug.c
===================================================================
--- linux-2.6-ozlabs.orig/kernel/sched_debug.c
+++ linux-2.6-ozlabs/kernel/sched_debug.c
@@ -17,18 +17,6 @@
#include <linux/utsname.h>
/*
- * This allows printing both to /proc/sched_debug and
- * to the console
- */
-#define SEQ_printf(m, x...) \
- do { \
- if (m) \
- seq_printf(m, x); \
- else \
- printk(x); \
- } while (0)
-
-/*
* Ease the printing of nsec fields:
*/
static long long nsec_high(unsigned long long nsec)
@@ -370,6 +358,9 @@ static int __init init_sched_debug_procf
__initcall(init_sched_debug_procfs);
+void __attribute__ ((weak))
+arch_proc_sched_show_task(struct task_struct *p, struct seq_file *m) {}
+
void proc_sched_show_task(struct task_struct *p, struct seq_file *m)
{
unsigned long nr_switches;
@@ -473,6 +464,7 @@ void proc_sched_show_task(struct task_st
SEQ_printf(m, "%-35s:%21Ld\n",
"clock-delta", (long long)(t1-t0));
}
+ arch_proc_sched_show_task(p, m);
}
void proc_sched_set_task(struct task_struct *p)
^ permalink raw reply
* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Vijay Nikam @ 2009-03-16 5:41 UTC (permalink / raw)
To: Mark Bishop; +Cc: linuxppc-dev
In-Reply-To: <20090311142708.olkbrtn5hws0cg8w@www.bish.net>
Hi Mark,
Could you please let me know how you booted the latest Linux kernel on
MPC8313ERDB board ? ? ? As I tried but was not successful. It hangs or
does nothing and waits at network configuration, mean to determine IP
address (as I have used dhcp).
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 3/11/09, Mark Bishop <mark@bish.net> wrote:
>
> Quoting Scott Wood <scottwood@freescale.com>:
>
>
> > On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
> >
> > > Yes I have actually. =A0I have booted a 2.6.28.6. =A0Same problem.
> > >
> >
> > I've booted many recent kernels on revA 8313ERDB; networking works fine=
.
> > I'll try 2.6.28.6 specifically, though u-boot is acting up at the momen=
t
> > so I have to address that first. :-(
> >
> > Are you using the stock config and device tree from 2.6.28.6, or have y=
ou
> > made any changes?
> >
> >
> > > Also, is it me but at some point from 2.6.23 to 2.6.28 did they
> > > started using hex numbers in the .dts file for "interrupts =3D " with=
out
> > > the 0x preamble?
> > >
> >
> > Yes. =A0dts version 0 had hex by default (with OF-like radix prefixes),=
and version 1 (indicated by
> > /dts-v1/; at the top of the file) has decimal by default (with C-like
> > radix prefixes).
> >
> >
> > > I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this
> > > board and .28 looked way different in the interrupt section for the
> > > eTSEC.
> > >
> > > Quoting Kumar Gala <galak@kernel.crashing.org>:
> > >
> >
> > Please don't top-post.
> >
> >
> > > >>The boards we received didn't have SPI compiled into the kernel and
> > > >>when we went to go re-compile the kernel using the 20081222 and
> > > >>20080711 BSPs. =A0I realize that the interrupts were reversed for
> > > >>eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no
> > > >>longer hang when I ping, etc. =A0 But I still can't get the board o=
n
> > > >>the network. =A0I've verified it isn't the network settings.
> > >
> >
> > You're sure you're not trying to talk to the switch (which will claim
> > link-up regardless of what's plugged into it)? =A0The non-switch ethern=
et
> > port is eTSEC2.
> >
> > What *does* it do when you ping, if neither hang nor work?
> >
> > -Scott
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> >
>
> After remapping the IRQs, it is working now.
>
> Any idea on what I need to do to get SPI working? =A0I've compiled it int=
o the kernel but don't see anything in /proc/bus
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: DTS device tree node for dual port RAM
From: Grant Likely @ 2009-03-16 4:57 UTC (permalink / raw)
To: EXTERNAL Lange Matthias (AA-DGW/ENG1); +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <44C5CFA72BC0E242A53B64DC1E67DEB80A695E7512@SI-MBX10.de.bosch.com>
On Thu, Mar 12, 2009 at 9:19 AM, EXTERNAL Lange Matthias (AA-DGW/ENG1)
<Matthias.Lange@beissbarth.com> wrote:
>> What hardware irq# are you using? =A0See this link for a description of
>> what the interrupts property should look like for external IRQs:
>
> I am using hardware irq# 0 which is wired to the critical input line. Tha=
t's why I was defining the interrupts property to <0 0 0>. So my device tre=
e node now looks like this
Okay, good. I just wanted to make sure.
> dpram@40000000 {
> =A0 =A0 =A0 =A0compatible =3D "beissbarth,orion-dpram";
> =A0 =A0 =A0 =A0interrupts =3D <0 0 0>;
> =A0 =A0 =A0 =A0interrupt-parent =3D <&mpc5200_pic>;
> };
This is unrelated to your question, but I'm wondering why you don't
have a reg property in your node.
> If I am understanding it correctly I now need to implement a OF platform =
driver in which I can use irq_of_parse_and_map() to get the virq for my dev=
ice.
That is the easiest way, yes. Actually, all you need to call
irq_of_parse_and_map() is a pointer to the device_node which can be
obtained by directly searching the tree. However, writing an
of_platform driver is a better way to get the device_node in this
case.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] cpumask: use mm_cpumask() wrapper: powerpc
From: Rusty Russell @ 2009-03-16 4:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
Makes code futureproof against the impending change to mm->cpu_vm_mask.
It's also a chance to use the new cpumask_ ops which take a pointer
(the older ones are deprecated, but there's no hurry for arch code).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
arch/powerpc/include/asm/mmu_context.h | 2 +-
arch/powerpc/mm/hash_utils_64.c | 10 ++++------
arch/powerpc/mm/mmu_context_nohash.c | 2 +-
arch/powerpc/mm/pgtable.c | 3 +--
arch/powerpc/mm/tlb_hash64.c | 6 +++---
arch/powerpc/mm/tlb_nohash.c | 18 +++++++++---------
arch/powerpc/platforms/cell/spu_base.c | 2 +-
7 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -31,7 +31,7 @@ static inline void switch_mm(struct mm_s
struct task_struct *tsk)
{
/* Mark this context has been used on the new CPU */
- cpu_set(smp_processor_id(), next->cpu_vm_mask);
+ cpumask_set_cpu(smp_processor_id(), mm_cpumask(next));
/* 32-bit keeps track of the current PGDIR in the thread struct */
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -858,7 +858,7 @@ int hash_page(unsigned long ea, unsigned
unsigned long vsid;
struct mm_struct *mm;
pte_t *ptep;
- cpumask_t tmp;
+ const struct cpumask *tmp;
int rc, user_region = 0, local = 0;
int psize, ssize;
@@ -906,8 +906,8 @@ int hash_page(unsigned long ea, unsigned
return 1;
/* Check CPU locality */
- tmp = cpumask_of_cpu(smp_processor_id());
- if (user_region && cpus_equal(mm->cpu_vm_mask, tmp))
+ tmp = cpumask_of(smp_processor_id());
+ if (user_region && cpumask_equal(mm_cpumask(mm), tmp))
local = 1;
#ifdef CONFIG_HUGETLB_PAGE
@@ -1023,7 +1023,6 @@ void hash_preload(struct mm_struct *mm,
unsigned long vsid;
void *pgdir;
pte_t *ptep;
- cpumask_t mask;
unsigned long flags;
int local = 0;
int ssize;
@@ -1066,8 +1065,7 @@ void hash_preload(struct mm_struct *mm,
local_irq_save(flags);
/* Is that local to this CPU ? */
- mask = cpumask_of_cpu(smp_processor_id());
- if (cpus_equal(mm->cpu_vm_mask, mask))
+ if (cpumask_equal(mm_cpumask(mm), cpumask_of(smp_processor_id())))
local = 1;
/* Hash it in */
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -97,7 +97,7 @@ static unsigned int steal_context_smp(un
mm->context.id = MMU_NO_CONTEXT;
/* Mark it stale on all CPUs that used this mm */
- for_each_cpu_mask_nr(cpu, mm->cpu_vm_mask)
+ for_each_cpu(cpu, mm_cpumask(mm))
__set_bit(id, stale_map[cpu]);
return id;
}
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -81,11 +81,10 @@ void pgtable_free_tlb(struct mmu_gather
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
/* This is safe since tlb_gather_mmu has disabled preemption */
- cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
- cpus_equal(tlb->mm->cpu_vm_mask, local_cpumask)) {
+ cpumask_equal(mm_cpumask(tlb->mm), cpumask_of(smp_processor_id()))){
pgtable_free(pgf);
return;
}
diff --git a/arch/powerpc/mm/tlb_hash64.c b/arch/powerpc/mm/tlb_hash64.c
--- a/arch/powerpc/mm/tlb_hash64.c
+++ b/arch/powerpc/mm/tlb_hash64.c
@@ -139,12 +139,12 @@ void hpte_need_flush(struct mm_struct *m
*/
void __flush_tlb_pending(struct ppc64_tlb_batch *batch)
{
- cpumask_t tmp;
+ const struct cpumask *tmp;
int i, local = 0;
i = batch->index;
- tmp = cpumask_of_cpu(smp_processor_id());
- if (cpus_equal(batch->mm->cpu_vm_mask, tmp))
+ tmp = cpumask_of(smp_processor_id());
+ if (cpumask_equal(mm_cpumask(batch->mm), tmp))
local = 1;
if (i == 1)
flush_hash_page(batch->vaddr[0], batch->pte[0],
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -132,11 +132,11 @@ void flush_tlb_mm(struct mm_struct *mm)
pid = mm->context.id;
if (unlikely(pid == MMU_NO_CONTEXT))
goto no_context;
- cpu_mask = mm->cpu_vm_mask;
- cpu_clear(smp_processor_id(), cpu_mask);
- if (!cpus_empty(cpu_mask)) {
+ if (!cpumask_equal(mm_cpumask(mm), cpumask_of(smp_processor_id()))) {
struct tlb_flush_param p = { .pid = pid };
- smp_call_function_mask(cpu_mask, do_flush_tlb_mm_ipi, &p, 1);
+ /* Ignores smp_processor_id() even if set. */
+ smp_call_function_many(mm_cpumask(mm),
+ do_flush_tlb_mm_ipi, &p, 1);
}
_tlbil_pid(pid);
no_context:
@@ -146,16 +146,15 @@ EXPORT_SYMBOL(flush_tlb_mm);
void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr)
{
- cpumask_t cpu_mask;
+ struct cpumask *cpu_mask;
unsigned int pid;
preempt_disable();
pid = vma ? vma->vm_mm->context.id : 0;
if (unlikely(pid == MMU_NO_CONTEXT))
goto bail;
- cpu_mask = vma->vm_mm->cpu_vm_mask;
- cpu_clear(smp_processor_id(), cpu_mask);
- if (!cpus_empty(cpu_mask)) {
+ cpu_mask = mm_cpumask(vma->vm_mm);
+ if (!cpumask_equal(cpu_mask, cpumask_of(smp_processor_id()))) {
/* If broadcast tlbivax is supported, use it */
if (mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)) {
int lock = mmu_has_feature(MMU_FTR_LOCK_BCAST_INVAL);
@@ -167,7 +166,8 @@ void flush_tlb_page(struct vm_area_struc
goto bail;
} else {
struct tlb_flush_param p = { .pid = pid, .addr = vmaddr };
- smp_call_function_mask(cpu_mask,
+ /* Ignores smp_processor_id() even if set in cpu_mask */
+ smp_call_function_many(cpu_mask,
do_flush_tlb_page_ipi, &p, 1);
}
}
diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -114,7 +114,7 @@ static inline void mm_needs_global_tlbie
int nr = (NR_CPUS > 1) ? NR_CPUS : NR_CPUS + 1;
/* Global TLBIE broadcast required with SPEs. */
- __cpus_setall(&mm->cpu_vm_mask, nr);
+ bitmap_fill(cpumask_bits(mm_cpumask(mm)), nr);
}
void spu_associate_mm(struct spu *spu, struct mm_struct *mm)
^ permalink raw reply
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Benjamin Herrenschmidt @ 2009-03-16 0:49 UTC (permalink / raw)
To: rsa; +Cc: linuxppc-dev, Will Schmidt, Steven Munroe
In-Reply-To: <1237042739.8874.3.camel@localhost.localdomain>
On Sat, 2009-03-14 at 09:58 -0500, Ryan Arnold wrote:
> We can do some VMX testing on existing POWER6 machines. The VSX
> instruction set hasn't been fully implemented in GCC yet so we'll need
> to wait a bit for that. Does anyone have an idea for a good VMX/Altivec
> benchmark?
Note that there are two aspects to the problem:
- Lazy save/restore on SMP. This would avoid both the save and restore
phases, thus is where the most potential gain is to be made. At the
expense of some tricky IPI work when processes migrate between CPUs.
However, it will only be useful -if- a process using FP/VMX/VSX is
"interrupted" by another process that isn't using them. For example, a
kernel thread. So it's unclear whether that's worth it in practice, ie,
does this happen that often ?
- Always restoring the FP/VMX/VSX state on context switch "in" rather
than taking a fault. This is reasonably simple, but at the potential
expense of adding the save/restore overhead to applications that only
seldomly use these facilities. (Some heuristics might help here).
However, the question here what do this buy us ?
IE, In the worst case scenario, which is HZ=1000, so every 1ms, the
process would have the overhead of an interrupt to do the restore of the
state. IE. The restore state itself doesn't count since it would be done
either way (at context switch vs. in the unavailable interrupt), so all
we win here is the overhead of the actual interrupt, which is
implemented as a fast interrupt in assembly. So we have what here ? 1000
cycles to be pessimistic ? On a 1Ghz CPU, that is 1/1000 of the time
slice, and both of these are rather pessimistic numbers.
So that leaves us with the possible case of 2 tasks using the facility
and running a fraction of the timeslice each, for example because they
are ping-ponging with each other.
Is that something that happens in practice to make it noticeable ?
Cheers,
Ben.
^ permalink raw reply
* Re: use generic pci_assign_unassign_resources
From: Benjamin Herrenschmidt @ 2009-03-15 23:56 UTC (permalink / raw)
To: Mark Takatz; +Cc: linuxppc-dev
In-Reply-To: <49BAE147.4060102@pericle.com>
On Fri, 2009-03-13 at 16:42 -0600, Mark Takatz wrote:
> Ben,
>
> We're looking at the fixes you put in place for the various PCI errors
> and we think this is the solution we need for our system, a GE Fanuc CM6
> PPC board (single 8641), but your patches appear to apply either to
> 2.6.24 or 2.6.25, and we have 2.6.23. Do you know of any similar work
> done on the 2.6.23 release?
>
> Thanks in advance for any help you can provide,
No, you would have to backport major chunks of the PCI rework I did in
between, along with fixes I did after that. At this stage I would
recommend considering an update to 2.6.27 or 2.6.28.
Cheers,
Ben.
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Gerhard Pircher @ 2009-03-15 13:40 UTC (permalink / raw)
To: Roderick Colenbrander, linuxppc-dev
In-Reply-To: <20090315110017.202010@gmx.net>
-------- Original-Nachricht --------
> Datum: Sun, 15 Mar 2009 12:00:17 +0100
> Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
> > > I got the i8259 south bridge working now after adding an io_base_virt
> > > offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
> > > the troubles to add ppc32 support to isa-bridge.c? The whole point of
> > > the code is basically to remap the io memory to low addresses for
> > > these 64-bit ppc systems (mainly freescale boards with a i8259 and
> > > pseries systems with a i8259).
> > pci_process_bridge_OF_ranges() should "ioremap" io_base_virt for you,
> > if your board has only one PCI I/O space. It also sets isa_io_base to
> > io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
> > PCI I/O address 0x0. Isn't that the case for your board?
> >
>
> Ah then perhaps that is my problem. I'm using my own pci implementation
> for Xilinx their plbv46 soft core. The soft core might be compatible
> with a generic ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm
> doing something like which is done in powermac/pci.c e.g. creating the
> pci_controller and filling it with cfg_addr / cfg_data pointers, io
> ranges, resource ranges and so on. The data is obtained from the dts
> file but from some xilinx generated fields and doesn't have the generic
> ranges fields and some others. I guess it is time to fix this part of
> the DTS file.
I don't know much about this plb2pci bridge, but if you take a look at ppc4xx_probe_pci_bridge() in sysdev/ppc4xx_pci.c, you'll see that it
calls pci_process_bridge_OF_ranges() too. Thus the "ranges" properties
are required to setup PCI correctly.
> Some other issue I had which might be related to my DTS file bugs is
> some i/o port conflict. The M1553 south bridge is just a peripheral on
> the ML510 primary pci bus there are no PCI slots connected to it. There
> are four other pci slots of which two are directly connected to the fpga
> (they are on the same bus as the M1553) and two are connected using a
> pci-to-pci bridge because they use 5V instead of 3.3V. The bridge chip
> wanted 0x0-0xfff while some south bridge devices wanted low addresses
> (if I remember correctly the IDE controller wants 0x1f0-0x1f1 and some
> 0x3** ports). This generated some "Cannot allocate resource region ..
The I/O ports within 0x0-0xfff are somehow reserved for legacy ISA
devices (in the M1553 southbridge), if I remember the PCI spec correctly.
That will conflict with the PCI2PCI bridge anyway, if both claim PCI I/O
transactions for this range. I guess you have to relocate the PCI I/O
window of the PCI2PCI bridge.
> will remap" messages from kernel/pci-common.c. This remapping didn't
> happen. Should a proper DTS file prevent this issue? If not where is the
> remapping done (I didn't see it). For that reason I'm ignoring the
> pci-to-pci bridge for now.
AFAIK bridge windows are not relocated. The firmware should setup them
correctly. Also, you don't have to add the PCI2PCI bridge to the DTS,
if the bridge uses the standardized register set to define the I/O and
memory windows. A general rule (for PCI) is to only define the
information that cannot be probed by the kernel itself.
regards,
Gerhard
--
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-15 11:00 UTC (permalink / raw)
To: Gerhard Pircher, linuxppc-dev
In-Reply-To: <20090315104313.72510@gmx.net>
> > I got the i8259 south bridge working now after adding an io_base_virt
> > offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
> > the troubles to add ppc32 support to isa-bridge.c? The whole point of
> > the code is basically to remap the io memory to low addresses for these
> > 64-bit ppc systems (mainly freescale boards with a i8259 and pseries
> > systems with a i8259).
> pci_process_bridge_OF_ranges() should "ioremap" io_base_virt for you,
> if your board has only one PCI I/O space. It also sets isa_io_base to
> io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
> PCI I/O address 0x0. Isn't that the case for your board?
>
Ah then perhaps that is my problem. I'm using my own pci implementation for Xilinx their plbv46 soft core. The soft core might be compatible with a generic ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm doing something like which is done in powermac/pci.c e.g. creating the pci_controller and filling it with cfg_addr / cfg_data pointers, io ranges, resource ranges and so on. The data is obtained from the dts file but from some xilinx generated fields and doesn't have the generic ranges fields and some others. I guess it is time to fix this part of the DTS file.
Some other issue I had which might be related to my DTS file bugs is some i/o port conflict. The M1553 south bridge is just a peripheral on the ML510 primary pci bus there are no PCI slots connected to it. There are four other pci slots of which two are directly connected to the fpga (they are on the same bus as the M1553) and two are connected using a pci-to-pci bridge because they use 5V instead of 3.3V. The bridge chip wanted 0x0-0xfff while some south bridge devices wanted low addresses (if I remember correctly the IDE controller wants 0x1f0-0x1f1 and some 0x3** ports). This generated some "Cannot allocate resource region .. will remap" messages from kernel/pci-common.c. This remapping didn't happen. Should a proper DTS file prevent this issue? If not where is the remapping done (I didn't see it). For that reason I'm ignoring the pci-to-pci bridge for now.
Thanks,
Roderick Colenbrander
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Gerhard Pircher @ 2009-03-15 10:43 UTC (permalink / raw)
To: Roderick Colenbrander, linuxppc-dev
In-Reply-To: <20090315083826.302680@gmx.net>
-------- Original-Nachricht --------
> Datum: Sun, 15 Mar 2009 09:38:26 +0100
> Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
> > > At some point in the file they create some (dummy?) pcie section in
> > > which they define a uli1575, an isa bus and attached to that isa bus
> > > a i8259. Is this the correct way of doing things? The i8259 driver
> > > seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
> > > defined below but how are those mapped to the south bridge? I have
> > > seen some code in kernel/isa-bridge, is that code indeed responsible
> > > for setting up these ports?
> > Yes, the pcie node is the PCI host bridge node and the uli1571 node
> > acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed
> > by pci_process_bridge_OF_ranges().
> > IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
> > for now. The I/O addresses for the i8259 PIC are currently hardcoded
> > and setup (request_resource()) in sysdev/i8259.c.
>
> I got the i8259 south bridge working now after adding an io_base_virt
> offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
> the troubles to add ppc32 support to isa-bridge.c? The whole point of
> the code is basically to remap the io memory to low addresses for these
> 64-bit ppc systems (mainly freescale boards with a i8259 and pseries
> systems with a i8259).
pci_process_bridge_OF_ranges() should "ioremap" io_base_virt for you,
if your board has only one PCI I/O space. It also sets isa_io_base to
io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
PCI I/O address 0x0. Isn't that the case for your board?
> As far as I have seen it is only needed for i8259 interrupt controllers.
> Personally I think it would be better to pass a io base offset to
> i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
> I'm not sure what the proper layout would be for this in the dts file
> though.
I think adding an io base offset parameter to i8259_setup isn't the
right way to do it. I would expect other problems too, if ISA I/O space
isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
experienced kernel developer can comment on this?
> With those changes I mentioned to i8259.c I got some PCI devices of my
> ali m1553 south bridge working. The code is ugly and I need to do
> cleanups. When it is done I will submit some patches.
IMHO that doesn't matter, as long as it helps people to understand your
problem. :-)
regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-15 8:38 UTC (permalink / raw)
To: Gerhard Pircher, linuxppc-dev
In-Reply-To: <20090314215439.8080@gmx.net>
> > At some point in the file they create some (dummy?) pcie section in
> > which they define a uli1575, an isa bus and attached to that isa bus a
> > i8259. Is this the correct way of doing things? The i8259 driver seems
> > to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined
> > below but how are those mapped to the south bridge? I have seen some
> > code in kernel/isa-bridge, is that code indeed responsible for setting
> > up these ports?
> Yes, the pcie node is the PCI host bridge node and the uli1571 node acts
> as PCI2ISA bridge node. AFAIK their ranges properties are parsed by
> pci_process_bridge_OF_ranges().
> IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
> for now. The I/O addresses for the i8259 PIC are currently hardcoded and
> setup (request_resource()) in sysdev/i8259.c.
I got the i8259 south bridge working now after adding an io_base_virt offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add ppc32 support to isa-bridge.c? The whole point of the code is basically to remap the io memory to low addresses for these 64-bit ppc systems (mainly freescale boards with a i8259 and pseries systems with a i8259). As far as I have seen it is only needed for i8259 interrupt controllers. Personally I think it would be better to pass a io base offset to i8259_setup or so. Or perhaps do some dts file parsing in i8259.c. I'm not sure what the proper layout would be for this in the dts file though.
With those changes I mentioned to i8259.c I got some PCI devices of my ali m1553 south bridge working. The code is ugly and I need to do cleanups. When it is done I will submit some patches.
Regards,
Roderick Colenbrander
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: [PATCH] powerpc: Remove extra semicolon in fsl_soc.c (2nd try)
From: Grant Likely @ 2009-03-15 2:01 UTC (permalink / raw)
To: jdaniel; +Cc: greg, afleming, stable, linuxppc-dev
In-Reply-To: <49BBC757.7090001@computer.org>
On Sat, Mar 14, 2009 at 9:03 AM, Johns Daniel <jdaniel@computer.org> wrote:
> TSEC/MDIO will not work with older device trees because of a semicolon at
> the end of a macro resulting in an empty for loop body.
>
> This fix only applies to 2.6.28; this code is gone in 2.6.29, according t=
o
> Grant Likely!
>
> Signed-off-by: Johns Daniel <johns.daniel@gmail.com
> <mailto:johns.daniel@gmail.com>>
Your signed-off-by line is odd. I assume your mailer did this to you.
But in case Greg picks it up anyway:
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig =A0 2009-02-20
> 16:41:27.000000000 -0600
> +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c =A0 =A0 =A0 =A02009-03-1=
4
> 09:01:38.994630400 -0500
> @@ -257,7 +257,7 @@ static int __init gfar_mdio_of_init(void
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfar_mdio_of_init_one(np);
>
> =A0 =A0 =A0 =A0/* try the deprecated version */
> - =A0 =A0 =A0 for_each_compatible_node(np, "mdio", "gianfar");
> + =A0 =A0 =A0 for_each_compatible_node(np, "mdio", "gianfar")
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfar_mdio_of_init_one(np);
>
> =A0 =A0 =A0 =A0return 0;
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: DTS file PCI / i8259 for Xilinx ML510
From: Gerhard Pircher @ 2009-03-14 21:54 UTC (permalink / raw)
To: Roderick Colenbrander, linuxppc-dev
In-Reply-To: <20090312103219.228100@gmx.net>
-------- Original-Nachricht --------
> Datum: Thu, 12 Mar 2009 11:32:19 +0100
> Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> An: linuxppc-dev@ozlabs.org
> Betreff: DTS file PCI / i8259 for Xilinx ML510
> ...
> The freescale boards define the pci bus like below and connect ULI M1575
> peripherals to the i8259 controller. Regarding the entries in the pci
> interrupt-map what does the fourth column mean? According to source code
> it means 'interrupt specifier' but what does it mean? In a lot of cases
> it is 1.
IIRC the fourth column is the PCI interrupt line (INTA..D = 1..4). The
Freescale boards may have a number of onboard PCI devices, which are
usually connected to a single PCI interrupt line only (INTA). In this
case a PCI unit address (1. column) is specified only once within the
interrupt-map table and the corresponding interrupt specifier is set
to 1 for INTA.
On the other side PCI slots can have up to four entries (INTA..D) for a
specific PCI unit address.
Please take a look at this document here:
http://playground.sun.com/1275/practice/imap/imap0_9d.html
> Further I believe in this case the entries behind 'mpic' correspond to
> the inta/b/c/d lines, is that correct? On my board inta is connected to
> interrupt 5 (intb=4, intc=3, intd=2) of the xilinx intc, so I would need
> to use those numbers there for my board?
No, the last two columns specify the real interrupt (IRQ line, level or
edge triggered). They're values depend on the type of interrupt
controller and its #interrupt-cells property.
> pci0: pcie@f8008000
> {
> device_type = "pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> ..
> ..
> interrupt-map-mask = <0xff00 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x11 func 0 - PCI slot 1 */
> 0x8800 0 0 1 &mpic 2 1
> 0x8800 0 0 2 &mpic 3 1
> 0x8800 0 0 3 &mpic 4 1
> 0x8800 0 0 4 &mpic 1 1
> ..
> ..
> // IDSEL 0x1c USB
> 0xe000 0 0 1 &i8259 12 2
> 0xe100 0 0 2 &i8259 9 2
> >;
>
> At some point in the file they create some (dummy?) pcie section in
> which they define a uli1575, an isa bus and attached to that isa bus a
> i8259. Is this the correct way of doing things? The i8259 driver seems
> to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined
> below but how are those mapped to the south bridge? I have seen some
> code in kernel/isa-bridge, is that code indeed responsible for setting
> up these ports?
Yes, the pcie node is the PCI host bridge node and the uli1571 node acts
as PCI2ISA bridge node. AFAIK their ranges properties are parsed by
pci_process_bridge_OF_ranges().
IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
for now. The I/O addresses for the i8259 PIC are currently hardcoded and
setup (request_resource()) in sysdev/i8259.c.
> pcie@0 {
> reg = <0 0 0 0 0>;
> #size-cells = <2>;
> #address-cells = <3>;
> device_type = "pci";
> ranges = <0x02000000 0x0 0x80000000
> 0x02000000 0x0 0x80000000
> 0x0 0x20000000
>
> 0x01000000 0x0 0x00000000
> 0x01000000 0x0 0x00000000
> 0x0 0x00100000>;
> uli1575@0 {
> reg = <0 0 0 0 0>;
> #size-cells = <2>;
> #address-cells = <3>;
> ranges = <0x02000000 0x0 0x80000000
> 0x02000000 0x0 0x80000000
> 0x0 0x20000000
> 0x01000000 0x0 0x00000000
> 0x01000000 0x0 0x00000000
> 0x0 0x00100000>;
> isa@1e {
> device_type = "isa";
> #interrupt-cells = <2>;
> #size-cells = <1>;
> #address-cells = <2>;
> reg = <0xf000 0 0 0 0>;
> ranges = <1 0 0x01000000 0 0
> 0x00001000>;
> interrupt-parent = <&i8259>;
>
> i8259: interrupt-controller@20 {
> reg = <1 0x20 2
> 1 0xa0 2
> 1 0x4d0 2>;
> interrupt-controller;
> device_type = "interrupt-controller";
> #address-cells = <0>;
> #interrupt-cells = <2>;
> compatible = "chrp,iic";
> interrupts = <9 2>;
> interrupt-parent = <&mpic>;
> };
> };
> };
> };
>
> Thanks,
> Roderick Colenbrander
best regards,
Gerhard
--
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* [PATCH] powerpc: Remove extra semicolon in fsl_soc.c (2nd try)
From: Johns Daniel @ 2009-03-14 15:03 UTC (permalink / raw)
To: greg; +Cc: linuxppc-dev, afleming, stable
TSEC/MDIO will not work with older device trees because of a semicolon
at the end of a macro resulting in an empty for loop body.
This fix only applies to 2.6.28; this code is gone in 2.6.29, according
to Grant Likely!
Signed-off-by: Johns Daniel <johns.daniel@gmail.com
<mailto:johns.daniel@gmail.com>>
======================================
--- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20 16:41:27.000000000 -0600
+++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c 2009-03-14 09:01:38.994630400 -0500
@@ -257,7 +257,7 @@ static int __init gfar_mdio_of_init(void
gfar_mdio_of_init_one(np);
/* try the deprecated version */
- for_each_compatible_node(np, "mdio", "gianfar");
+ for_each_compatible_node(np, "mdio", "gianfar")
gfar_mdio_of_init_one(np);
return 0;
^ permalink raw reply
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Ryan Arnold @ 2009-03-14 14:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Will Schmidt, Steven Munroe, linuxppc-dev
In-Reply-To: <FFBC9638-D064-43F9-B764-243739289710@kernel.crashing.org>
On Sat, 2009-03-14 at 14:49 +0100, Segher Boessenkool wrote:
> > Another option might be simply to say that if an app has used FP,
> > VMX or
> > VSX -once-, then it's likely to do it again and just keep re-enabling
> > it :-)
> >
> > I'm serious here, do we know that many cases where these things are
> > used
> > seldomly once in a while ?
>
> For FP, I believe many apps use it only sporadically. But for VMX
> and VSX,
> yeah, it might well be optimal to keep it enabled all the time. Someone
> should do some profiling...
We can do some VMX testing on existing POWER6 machines. The VSX
instruction set hasn't been fully implemented in GCC yet so we'll need
to wait a bit for that. Does anyone have an idea for a good VMX/Altivec
benchmark?
Ryan
^ permalink raw reply
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Segher Boessenkool @ 2009-03-14 13:55 UTC (permalink / raw)
To: rsa; +Cc: Will Schmidt, Steven Munroe, linuxppc-dev
In-Reply-To: <1236997906.3346.8.camel@localhost.localdomain>
>> It's very likely that a process which results in the
> enabling of FP,VMX, or VSX may continue to use the facility for the
> duration of it's lifetime. Threads would be even more likely to
> exhibit
> this behavior.
>
> The case where this might not be true is if we use VMX or VSX for
> string
> routine optimization in GLIBC. This will require metrics to prove
> it's
> utility of course.
OTOH, the main cost of using VMX etc. is exactly this register save/
restore,
and it's a win otherwise pretty much always. I.e., as soon as you take
that initial hit, almost anything can get a speedup from VMX. So
even if
you do not see an overall speedup from, say, only some optimised string
routines, it probably is worth it anyway as it pays the initial cost for
enabling more optimisations later.
Segher
^ permalink raw reply
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Segher Boessenkool @ 2009-03-14 13:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Will Schmidt, Steven Munroe
In-Reply-To: <1236984351.25062.71.camel@pasglop>
> Another option might be simply to say that if an app has used FP,
> VMX or
> VSX -once-, then it's likely to do it again and just keep re-enabling
> it :-)
>
> I'm serious here, do we know that many cases where these things are
> used
> seldomly once in a while ?
For FP, I believe many apps use it only sporadically. But for VMX
and VSX,
yeah, it might well be optimal to keep it enabled all the time. Someone
should do some profiling...
Segher
^ permalink raw reply
* Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
From: Michael Neuling @ 2009-03-14 8:20 UTC (permalink / raw)
To: rsa; +Cc: linuxppc-dev, Will Schmidt, Steven Munroe
In-Reply-To: <1236975831.3137.61.camel@localhost.localdomain>
> Hi all,
>
> Those of us working on the POWER toolchain can envision a certain class
> of customers who may benefit from intelligently disabling certain
> register class enable bits on context switches, i.e. not disabling by
> default.
>
> Currently, per process, if the MSR enable bits for FPs, VRs or VSRs are
> set to disabled, an interrupt will be generated as soon as an FP, VMX,
> or VSX instruction is encountered. At this point the kernel enables the
> relevant bits in the MSR and returns.
>
> Currently, the kernel will disable all of the bits on a context switch.
>
> If a customer _knows_ a process will be using a register class
> extensively, e.g. VRs, they're paying the interrupt->enable-VMX price
> with every context switch. It'd be nice if we could intelligently leave
> the bits enabled.
>
> Solutions:
> - A boot flag which always enables VSRs, VRs, FPRs, etc. These are
> cumulative, i.e. VSRs implies VRs and FPRS; VRs implies FPRs.
>
> - A heuristic which permanently enables said register classes for a
> process if they've been enabled during the previous X interrupts.
>
> - The same heuristic could disable the register class bits after a
> certain criteria is met.
Another option is to look at getting lazy save working on SMP. We
currently only enable it on UP compiles.
This would probably have the biggest performance impact when there is
only 1 FP/VSX/VMX application running per CPU.
Mikey
>
> We have some ideas on how to benchmark this to verify the expense of the
> interrupt->enable. As it presently works this stands in the way of
> using VMX or VSX for optimized string routines in GLIBC.
>
> Regards,
>
> Ryan S. Arnold
> IBM Linux Technology Center
> Linux Toolchain Development
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox