[git pull] Please pull powerpc.git merge branch
Hi Linus ! I would have hoped to get that stuff in before -rc1 but heh, I got sick for a couple of days, a distracted by some other stuff for a couple more and here we are, I missed it :-) Anyway, here are a bunch of relatively small ppc bits, almost all are bug fixes, mostly regressions, with the notable exception of one patch which I decided was worth taking a chance, which is the addition of lockdep/irqtrace support for ppc32 which has been around for 2 or 3 weeks and seems to be working well (it already found a couple of bugs !). The following changes since commit 987fed3bf6982f2627d4fa242caa9026ef61132a: Linus Torvalds (1): Merge branch 'drm-fixes' of git://git.kernel.org/.../airlied/drm-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Adrian Reber (1): powerpc/rtas: Fix watchdog driver temperature read functionality Anton Vorontsov (1): powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS Benjamin Herrenschmidt (13): powerpc/mpic: Fix mapping of DCR based MPIC variants powerpc/pmac: Fix issues with PowerMac PowerSurge SMP powerpc/mm: Make k(un)map_atomic out of line powerpc/pmac: Fix DMA ops for MacIO devices powerpc: Map more memory early on 601 processors powerpc: Add irqtrace support for 32-bit powerpc powerpc/rtas: Turn rtas lock into a raw spinlock powerpc: Use one common impl. of RTAS timebase sync and use raw spinlock powerpc/pasemi: Use raw spinlock in SMP TB sync powerpc/of: Fix usage of dev_set_name() in of_device_alloc() powerpc/440: Fix warning early debug code powerpc/mm: Fix potential access to freed pages when using hugetlbfs Merge commit 'kumar/next' into merge Gerhard Pircher (1): powerpc/amigaone: Limit ISA I/O range to 4k in the device tree Huang Weiyi (1): powerpc/85xx: remove duplicated #include Jon Smirl (1): powerpc: Have git ignore generated files from dtc compile Kumar Gala (6): powerpc/cpm1: Remove IMAP_ADDR powerpc/85xx: Stop using ppc_md.init on socrates powerpc/85xx: Fix issue found by lockdep trace in smp_85xx_kick_cpu powerpc: Refactor device tree binding powerpc: Fix output from show_regs powerpc: Fix mpic alloc warning Michael Ellerman (1): powerpc: Swiotlb breaks pseries Randy Vinson (1): powerpc/85xx: Fix FSL RapidIO probing on MDS boards Sean MacLennan (1): powerpc/warp: Platform fix for i2c change Sonny Rao (2): powerpc/BSR: add 4096 byte BSR size powerpc/BSR: Fix BSR to allow mmap of small BSR on 64k kernel Timur Tabi (1): powerpc/qe: add polling timeout to qe_issue_cmd() Documentation/powerpc/booting-without-of.txt | 1168 +- Documentation/powerpc/dts-bindings/4xx/emac.txt | 148 +++ Documentation/powerpc/dts-bindings/gpio/gpio.txt | 50 + Documentation/powerpc/dts-bindings/gpio/mdio.txt | 19 + Documentation/powerpc/dts-bindings/marvell.txt | 521 ++ Documentation/powerpc/dts-bindings/phy.txt | 25 + Documentation/powerpc/dts-bindings/spi-bus.txt | 57 ++ Documentation/powerpc/dts-bindings/usb-ehci.txt | 25 + Documentation/powerpc/dts-bindings/xilinx.txt| 295 ++ arch/powerpc/Kconfig |1 - arch/powerpc/boot/.gitignore | 10 + arch/powerpc/boot/dts/amigaone.dts |4 +- arch/powerpc/boot/dts/mpc8569mds.dts |1 + arch/powerpc/include/asm/cpm1.h |2 - arch/powerpc/include/asm/dma-mapping.h | 24 +- arch/powerpc/include/asm/highmem.h | 57 +- arch/powerpc/include/asm/hw_irq.h| 20 +- arch/powerpc/include/asm/pte-hash64-64k.h|3 +- arch/powerpc/include/asm/rtas.h |5 +- arch/powerpc/kernel/entry_32.S | 127 +++- arch/powerpc/kernel/head_32.S| 17 +- arch/powerpc/kernel/of_device.c |2 +- arch/powerpc/kernel/process.c|2 +- arch/powerpc/kernel/rtas.c | 69 ++- arch/powerpc/kernel/setup_32.c |2 + arch/powerpc/kernel/smp.c|3 +- arch/powerpc/kernel/udbg_16550.c |2 +- arch/powerpc/mm/Makefile |1 + arch/powerpc/mm/highmem.c| 77 ++ arch/powerpc/platforms/44x/warp.c| 44 +- arch/powerpc/platforms/85xx/mpc85xx_mds.c|1 + arch/powerpc/platforms/85xx/smp.c|9 +- arch/powerpc/platforms/85xx/socrates.c |6 +- arch/powerpc/platforms/85xx/xes_mpc85xx.c|1 - arch/powerpc/platforms/cell/smp.c| 30 +- arch/powerpc/platforms/chrp/smp.c| 33 +- arch/powerpc/platforms/pasemi/setup.c| 15
Re: ALSA fixes for non-coherent ppc32 again
Original-Nachricht Datum: Wed, 24 Jun 2009 11:47:13 +0200 Von: Takashi Iwai ti...@suse.de An: Gerhard Pircher gerhard_pirc...@gmx.net CC: b...@kernel.crashing.org, linuxppc-...@ozlabs.org Betreff: Re: ALSA fixes for non-coherent ppc32 again At Wed, 24 Jun 2009 10:46:01 +0200, Gerhard Pircher wrote: Original-Nachricht Datum: Tue, 23 Jun 2009 23:42:24 +0200 Von: Gerhard Pircher gerhard_pirc...@gmx.net An: b...@kernel.crashing.org, ti...@suse.de CC: linuxppc-...@ozlabs.org Betreff: Re: ALSA fixes for non-coherent ppc32 again Okay, that's wrong. I somehow messed up the .config file. It doesn't compile, too. I got it to compile now and it seems to work fine. I overlooked a typo in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.) Gah, thanks, fixed now on the git tree too. The Kconfig option still needs to be fixed, otherwise SND_COHERENT_DMA isn't selected for my PPC32 NOT_COHERENT_CACHE machine. config SND_NONCOHERENT_DMA def_bool n -- should be y depends on (PPC32 NOT_COHERENT_CACHE)... BTW: Can you put me on CC: please, if you bring up this topic on linux-arch or so? Gerhard -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Remove 'SBC8240 Wind River' Device Driver Code
Hi David/Scott, Today's next tree(20090626) produced the following build error: CC [M] drivers/mtd/maps/sbc8240.o drivers/mtd/maps/sbc8240.c:31:1: warning: DEBUG redefined In file included from drivers/mtd/maps/sbc8240.c:23: include/linux/mtd/mtd.h:333:1: warning: this is the location of the previous definition drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd': drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module' make[3]: *** [drivers/mtd/maps/sbc8240.o] Error 1 make[2]: *** [drivers/mtd/maps] Error 2 make[1]: *** [drivers/mtd] Error 2 make: *** [drivers] Error 2 I remember reporting this log back in April, when you suggested in removing it: http://lkml.org/lkml/2009/4/21/476, On Tue, 2009-04-21 at 15:00 -0500, Scott Wood wrote: Subrata Modak wrote: This is a very old one. Doesn´t seem to go away. Reported this earlier on 14th April: http://lkml.org/lkml/2009/4/14/483, CC [M] drivers/mtd/maps/sbc8240.o drivers/mtd/maps/sbc8240.c:31:1: warning: DEBUG redefined In file included from drivers/mtd/maps/sbc8240.c:23: include/linux/mtd/mtd.h:339:1: warning: this is the location of the previous definition drivers/mtd/maps/sbc8240.c: In function âinit_sbc8240_mtdâ: drivers/mtd/maps/sbc8240.c:172: error: âsbc8240_mtdâ undeclared (first use in this function) drivers/mtd/maps/sbc8240.c:172: error: (Each undeclared identifier is reported only once drivers/mtd/maps/sbc8240.c:172: error: for each function it appears in.) drivers/mtd/maps/sbc8240.c: In function âcleanup_sbc8240_mtdâ: drivers/mtd/maps/sbc8240.c:233: error: âsbc8240_mtdâ undeclared (first use in this function) This looks like an arch/ppc orphan. It's not enabled by any defconfig, and it doesn't look like it does anything that physmap_of can't do. I'd just remove it. -Scott I tried to gather some more info about this driver from the link mentioned in Kconfig: http://www.windriver.com/products/sbc8240/, without much success. If there are no issues, can you please apply this patch to remove it ? To: David Woodhouse dw...@infradead.org, To: Scott Wood scottw...@freescale.com, Cc: Jim Cromie jim.cro...@gmail.com, Cc: carolyn.j.sm...@exgate.tek.com, Cc: Adrian Bunk b...@kernel.org, Cc: Sachin P Sant sach...@linux.vnet.ibm.com, Cc: Balbir Singh bal...@linux.vnet.ibm.com, Cc: Stephen Rothwell s...@canb.auug.org.au, Cc: linux-kernel linux-ker...@vger.kernel.org, Cc: Linuxppc-dev linuxppc-...@ozlabs.org, Cc: linux-next linux-n...@vger.kernel.org, Cc: Alexander Beregalov a.berega...@gmail.com Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com Tested-on-PPC64-by: Subrata Modak subr...@linux.vnet.ibm.com --- diff -uprN a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig --- a/drivers/mtd/maps/Kconfig 2009-06-26 07:36:23.0 -0500 +++ b/drivers/mtd/maps/Kconfig 2009-06-26 07:39:34.0 -0500 @@ -284,13 +284,6 @@ config MTD_L440GX BE VERY CAREFUL. -config MTD_SBC8240 - tristate Flash device on SBC8240 - depends on MTD_JEDECPROBE 8260 - help - Flash access on the SBC8240 board from Wind River. See - http://www.windriver.com/products/sbc8240/ - config MTD_TQM8XXL tristate CFI Flash device mapped on TQM8XXL depends on MTD_CFI TQM8xxL diff -uprN a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile --- a/drivers/mtd/maps/Makefile 2009-06-26 07:36:23.0 -0500 +++ b/drivers/mtd/maps/Makefile 2009-06-26 07:40:03.0 -0500 @@ -50,7 +50,6 @@ obj-$(CONFIG_MTD_UCLINUX) += uclinux.o obj-$(CONFIG_MTD_NETtel) += nettel.o obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o obj-$(CONFIG_MTD_H720X)+= h720x-flash.o -obj-$(CONFIG_MTD_SBC8240) += sbc8240.o obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o obj-$(CONFIG_MTD_IXP2000) += ixp2000.o obj-$(CONFIG_MTD_WRSBC8260)+= wr_sbc82xx_flash.o diff -uprN a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c --- a/drivers/mtd/maps/sbc8240.c2009-06-26 07:36:23.0 -0500 +++ b/drivers/mtd/maps/sbc8240.c1969-12-31 18:00:00.0 -0600 @@ -1,250 +0,0 @@ -/* - * Handle mapping of the flash memory access routines on the SBC8240 board. - * - * Carolyn Smith, Tektronix, Inc. - * - * This code is GPLed - */ - -/* - * The SBC8240 has 2 flash banks. - * Bank 0 is a 512 KiB AMD AM29F040B; 8 x 64 KiB sectors. - * It contains the U-Boot code (7 sectors) and the environment (1 sector). - * Bank 1 is 4 x 1 MiB AMD AM29LV800BT; 15 x 64 KiB sectors, 1 x 32 KiB sector, - * 2 x 8 KiB sectors, 1 x 16 KiB sectors. - * Both parts are JEDEC compatible. - */ - -#include linux/module.h -#include linux/types.h -#include linux/kernel.h -#include asm/io.h - -#include linux/mtd/mtd.h -#include linux/mtd/map.h -#include linux/mtd/cfi.h - -#ifdef CONFIG_MTD_PARTITIONS -#include
[PATCH] sky2: Fix checksum endianness
sky2 driver on PowerPC targets floods kernel log with following errors:
eth1: hw csum failure.
Call Trace:
[ef84b8a0] [c00075e4] show_stack+0x50/0x160 (unreliable)
[ef84b8d0] [c02fa178] netdev_rx_csum_fault+0x3c/0x5c
[ef84b8f0] [c02f6920] __skb_checksum_complete_head+0x7c/0x84
[ef84b900] [c02f693c] __skb_checksum_complete+0x14/0x24
[ef84b910] [c0337e08] tcp_v4_rcv+0x4c8/0x6f8
[ef84b940] [c031a9c8] ip_local_deliver+0x98/0x210
[ef84b960] [c031a788] ip_rcv+0x38c/0x534
[ef84b990] [c0300338] netif_receive_skb+0x260/0x36c
[ef84b9c0] [c025de00] sky2_poll+0x5dc/0xcf8
[ef84ba20] [c02fb7fc] net_rx_action+0xc0/0x144
The NIC is Yukon-2 EC chip revision 1.
Converting checksum field from le16 to CPU byte order fixes the issue.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/sky2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 7681d28..daf961a 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2495,7 +2495,7 @@ static int sky2_status_intr(struct sky2_hw *hw, int
to_do, u16 idx)
if (likely(status 16 == (status 0x))) {
skb = sky2-rx_ring[sky2-rx_next].skb;
skb-ip_summed = CHECKSUM_COMPLETE;
- skb-csum = status 0x;
+ skb-csum = le16_to_cpu(status);
} else {
printk(KERN_NOTICE PFX %s: hardware receive
checksum problem (status = %#x)\n,
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
On Fri, 26 Jun 2009, abhishekkumar wrote: PFA I am attaching dmesg file taken from /var/log/ and also the lines which I got from dmesg command in different file named dmesgafter.txt. I still don't see any lines about the headphone device in the log. Was the headphone plugged in during boot, or did you plug it in later? Then , periodic and registers files and also the usbmon log. Here's what your registers file says: bus ps3_system_bus, device sb_05 (driver 10 Dec 2004) PS3 EHCI Host Controller EHCI ff.ff, hcd state 1 structural params 0x capability params 0x status Async Periodic Recl Halt IAA FATAL FLR PCD ERR INT command park=3 ithresh=63 LReset IAAD Async Periodic period=?? Reset R intrenable IAA FATAL FLR PCD ERR INT uframe port 1 status POWER OWNER sig=? RESET SUSPEND RESUME OCC OC PEC PE CSC port 2 status POWER OWNER sig=? RESET SUSPEND RESUME OCC OC PEC PE CSC irq normal 30832 err 30 reclaim 84 (lost 1) complete 31221 unlink 10 This is very bad. It indicates that the CPU was unable to communicate with the EHCI controller at all! All the memory-mapped I/O reads returned 0x. No wonder the keyboard and mouse stopped working. I have no idea what could have caused this to happen. Even if the controller had suffered a fatal error, you wouldn't see this. It looks like the bus's connection to the controller was turned off. I'm CC-ing the PS3 maintainer and mailing list. Maybe people there can help. I am even not able to kill the application because it's not showing when I use top command. I addition to that I get some messages during boot up . they are Unable to accept address for port 1 (error -62) usb cable may be bad Unable to accept address for port 2 (error -62) Those are normal. They occur because your system loads ohci-hcd before ehci-hcd. It should load ehci-hcd first. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Trouble Transferring control to Linux (at address 00000000)
Hello, I'm trying to load Linux from U-Boot. I am using ELDK 4.2 with U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 cpu, 64MB RAM, 32MB FLASH). The linux kernel sources were obtained from instructions at http://www.denx.de/wiki/view/DULG/LinuxConfiguration#Section_6.1.; and the FDT blob (dtb) was generated from linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts. Below is my output from boot to hang: U-Boot 2009.03-svn8591 (Jun 25 2009 - 11:08:09) CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz] 8 kB I-Cache 8 kB D-Cache FEC present clock 1Hz != 30Hz Board: EP88xC 1.1 CPLD revision 2 DRAM: 64 MB Top of RAM usable for U-Boot at: 0400 Reserving 208k for U-Boot at: 03fcb000 Reserving 384k for malloc() at: 03f6b000 Reserving 60 Bytes for Board Info at: 03f6afc4 Reserving 56 Bytes for Global Data at: 03f6af8c Stack Pointer at: 03f6af68 New Stack Pointer is: 03f6af68 Now running in RAM - U-Boot at: 03fcb000 FLASH: flash detect cfi fwc addr fc00 cmd f0 f0 8bit x 8 bit ... ... some output skipped ... ... is= cmd 59(Y) addr fc48 is= 00590059 00590059 device interface is 2 found port 4 chip 2 port 32 bits chip 16 bits 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07 qr...@.'6... ... ... some output skipped ... ... fwc addr fc000154 cmd 98 00980098 32bit x 16 bit manufacturer is 2 manufacturer id is 0x1 device id is 0x227e device id2 is 0x0 cfi version is 0x3133 size_ratio 2 port 32 bits chip 16 bits found 1 erase regions erase region 0: 0x027f erase_region_count = 128 erase_region_size = 131072 fwc addr fc00 cmd f0 00f000f0 32bit x 16 bit flash_protect ON: from 0xFC00 to 0xFC02DFFF protect on 0 flash_protect ON: from 0xFC04 to 0xFC07 protect on 1 32 MB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial U-Boot relocated to 03fcb000 Net: FEC ETHERNET, FEC2 ETHERNET ### main_loop entered: bootdelay=2 ### main_loop: bootcmd=bootm fc08 Hit any key to stop autoboot: 0 ## Current stack ends at 0x03f6ad50 * kernel: cmdline image address = 0xfc08 Wrong Image Format for bootm command ERROR: can't get kernel image! = setenv ipaddr 10.0.54.150 = setenv serverip 10.0.54.129 = setenv bootargs root=/dev/ram0 rw = setenv ethaddr 00-e0-86-0c-84-fd eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd) Setting new HW address on FEC ETHERNET New Address is 00:E0:86:0C:84:FD eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd) Setting new HW address on FEC ETHERNET New Address is 00:E0:86:0C:84:FD = tftp 40 ep88x_uimage2 Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_uimage2'. Load address: 0x40 Loading: # done Bytes transferred = 1061544 (1032a8 hex) = tftp 55 ep88x_ramdisk3 Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_ramdisk3'. Load address: 0x55 Loading: # # done Bytes transferred = 1846099 (1c2b53 hex) = tftp 75 ep88x_dtb Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_dtb'. Load address: 0x75 Loading: # done Bytes transferred = 12288 (3000 hex) = bootm 40 55 75 ## Current stack ends at 0x03f6ad60 * kernel: cmdline image address = 0x0040 ## Booting kernel from Legacy Image at 0040 ... Image Name: Linux-2.6.30-rc2-01402-gd4e2f68- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1061480 Bytes = 1 MB Load Address: Entry Point: Entry Point: kernel data at 0x00400040, len = 0x00103268 (1061480) * ramdisk: cmdline image address = 0x0055 ## Loading init Ramdisk from Legacy Image at 0055 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1846035 Bytes = 1.8 MB Load Address: Entry Point: Verifying Checksum ... OK ramdisk start = 0x00550040, ramdisk end = 0x00712b53 * fdt: cmdline image address = 0x0075 ## Checking for 'FDT'/'FDT Image' at 0075 * fdt: raw FDT blob ## Flattened Device Tree blob at 0075 Booting using the fdt blob at 0x75 of_flat_tree at 0x0075 size 0x3000 Uncompressing Kernel Image ... OK kernel loaded at 0x, end = 0x00226224 ## initrd_high = 0x, copy_to_ram = 1 Loading Ramdisk to 03da7000, end 03f69b13 ... OK ramdisk load start = 0x03da7000, ramdisk load end = 0x03f69b13 ## Transferring control to Linux (at address ) ... Booting using OF flat tree... I did a post-mortem analysis (http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis) and came up with
Re: Subject: [PATCH v7] spi: Add PPC4xx SPI driver
David Brownell wrote:
On Thursday 25 June 2009, Steven A. Falco wrote:
+ if (spi-mode ~MODEBITS) {
+ dev_dbg(spi-dev, setup: unsupported mode bits %x\n,
+ spi-mode ~MODEBITS);
+ return -EINVAL;
+ }
This wasn't tested against 2.6.30-rc1 was it?
I tested against Ben's next branch, plus your fix for bitbang_work.
But the new version I'll post is tested against Linus' master branch
(2.6.31-rc1) to take advantage of your mode_bits addition. If you need
this driver to be based on something else, please say so.
See the recent fixup patch I sent. There's a spi_master-modebits
mask that should have been initialized, and which eliminates the
need for tests like that ...
Done.
+ dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n,
+ __func__, spi-mode, spi-bits_per_word,
+ spi-max_speed_hz);
+
... also the SPI core now provides a *standard* format debug
message for that stuff. It also handles one more thing, which
I expect to see fixed in a v8 of this patch ... :)
Ok - I removed that dev_dbg(). Also, I noticed that spi_setup sets
bits_per_word to 8, so I've removed that as well. Did I pass your
test? :-)
Version 8 will follow shortly. BTW, this driver is dependent on your
bitbang_work fix. Not sure if that means it should be added via your
tree. But since we are in an rc phase, I'm guessing this won't merge
until 2.6.32, by which time your fix should be in the mainline.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Subject: [PATCH v8] spi: Add PPC4xx SPI driver
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Wolfgang Ocker w...@reccoware.de
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
Signed-off-by: Steven A. Falco sfa...@harris.com
---
Changes in v8:
- Removed redundant dbg messages
- Using new master-mode_line variable
- Removed redundant test and assignment of bits_per_word
- Some white-space fixes from checkpatch
Changes in v7:
- Additional comments as per David Brownell's review
- Corrected phase in mode 2 and 3
- Corrected speed and bits_per_word logic in spi_ppc4xx_setupxfer
- Removed extraneous tests as per David's review
- Added support for holes in the chip-select list
- Using dynamic bus allocation
- Corrected initialization logic
Changes in v6:
- Moved comment about high interrupt load to top of file and extended it
by explaining that the 4xx SPI controller has no FIFOs.
- Added parameter checking to setup() routine.
- Removed comment about LSB
- Used of_gpio_count() instead creating own static implementation as
suggested by Anton.
Changes in v5:
- Don't call setupxfer() from setup() so that the baudrate etc
won't get changed while another transfer is active, as suggested
by David Brownell.
- module_{init,exit} moved directly to the functions to which they
apply.
- Use __func__ instead of __FUNCTION__.
Changes in v4:
- Added fixes suggested by Josh Boyer
- Changed compatible property from ibm,spi to ibm,ppc4xx-spi
Changes in v3:
- When the device is removed the GPIOs are released. The memory
for the GPIO array is freed.
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/spi_ppc4xx.c | 612 ++
3 files changed, 620 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi_ppc4xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..1dd9f94 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -178,6 +178,13 @@ config SPI_PL022
controller. If you have an embedded system with an AMBA(R)
bus and a PL022 controller, say Y or M here.
+config SPI_PPC4xx
+ tristate PPC4xx SPI Controller
+ depends on 4xx SPI_MASTER
+ select SPI_BITBANG
+ help
+ This selects a driver for the PPC4xx SPI Controller.
+
config SPI_PXA2XX
tristate PXA2xx SSP SPI master
depends on ARCH_PXA EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3de408d..cc9a420 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_SPI_ORION) += orion_spi.o
obj-$(CONFIG_SPI_PL022)+= amba-pl022.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC8xxx) += spi_mpc8xxx.o
+obj-$(CONFIG_SPI_PPC4xx) += spi_ppc4xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..140a18d
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
@@ -0,0 +1,612 @@
+/*
+ * SPI_PPC4XX SPI controller driver.
+ *
+ * Copyright (C) 2007 Gary Jennejohn ga...@denx.de
+ * Copyright 2008 Stefan Roese s...@denx.de, DENX Software Engineering
+ * Copyright 2009 Harris Corporation, Steven A. Falco sfa...@harris.com
+ *
+ * Based in part on drivers/spi/spi_s3c24xx.c
+ *
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+/*
+ * The PPC4xx SPI controller has no FIFO so each sent/received byte will
+ * generate an interrupt to the CPU. This can cause high CPU utilization.
+ * This driver allows platforms to reduce the interrupt load on the CPU
+ * during SPI transfers by setting max_speed_hz via the device tree.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/of_platform.h
+#include linux/of_spi.h
+#include linux/of_gpio.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include asm/io.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+
+/* bits in mode register - bit 0 is MSb */
+
+/*
+ * SPI_PPC4XX_MODE_SCP = 0 means data latched on trailing edge of clock
+ * SPI_PPC4XX_MODE_SCP = 1 means data latched on leading edge of clock
+ * Note: This is the inverse of CPHA.
+ */
+#define SPI_PPC4XX_MODE_SCP(0x80 3)
Re: [PATCH] sky2: Fix checksum endianness
From: Anton Vorontsov avoront...@ru.mvista.com Date: Fri, 26 Jun 2009 18:51:59 +0400 sky2 driver on PowerPC targets floods kernel log with following errors: eth1: hw csum failure. Call Trace: [ef84b8a0] [c00075e4] show_stack+0x50/0x160 (unreliable) [ef84b8d0] [c02fa178] netdev_rx_csum_fault+0x3c/0x5c [ef84b8f0] [c02f6920] __skb_checksum_complete_head+0x7c/0x84 [ef84b900] [c02f693c] __skb_checksum_complete+0x14/0x24 [ef84b910] [c0337e08] tcp_v4_rcv+0x4c8/0x6f8 [ef84b940] [c031a9c8] ip_local_deliver+0x98/0x210 [ef84b960] [c031a788] ip_rcv+0x38c/0x534 [ef84b990] [c0300338] netif_receive_skb+0x260/0x36c [ef84b9c0] [c025de00] sky2_poll+0x5dc/0xcf8 [ef84ba20] [c02fb7fc] net_rx_action+0xc0/0x144 The NIC is Yukon-2 EC chip revision 1. Converting checksum field from le16 to CPU byte order fixes the issue. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Applied, thank you! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Trouble Transferring control to Linux (at address 00000000)
Mikhail Zaturenskiy wrote: Hello, I'm trying to load Linux from U-Boot. I am using ELDK 4.2 with U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 cpu, 64MB RAM, 32MB FLASH). The linux kernel sources were obtained from instructions at http://www.denx.de/wiki/view/DULG/LinuxConfiguration#Section_6.1.; and the FDT blob (dtb) was generated from linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts. Below is my output from boot to hang: This isn't the denx list; what kernel version is that, and with what modifications from mainline? Note that ep88xc.dts in mainline is intended for use with PlanetCore, which is what ships on that board. You may need to make modifications for it to work with u-boot (at the least, the IMMR base is probably different). This is why u-boot should be maintaining its own repository of trees that it passes... Also, make sure u-boot is properly updating the memory size in the device tree. Can you dump the post-fixup device tree in u-boot? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Trouble Transferring control to Linux (at address 00000000)
Hi Scott, This isn't the denx list; I've noticed :) but I'm still learning about this whole process so I though I could get some general suggestions. what kernel version is that, and with what modifications from mainline? Kernel is v2.6.30, I'm not yet familiar enough with it to know what's been modified from mainline, just following instructions. Note that ep88xc.dts in mainline is intended for use with PlanetCore, which is what ships on that board. You may need to make modifications for it to work with u-boot (at the least, the IMMR base is probably different). Hmm, this hasn't occurred to me, thank you for pointing it out. Also, make sure u-boot is properly updating the memory size in the device tree. Can you dump the post-fixup device tree in u-boot? Not sure, but I'll try to find out if that's possible. It'd certainly answer a lot of questions... Thanks, Mikhail Zaturenskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
Hi, On 06/26/2009 08:54 AM, Alan Stern wrote: On Fri, 26 Jun 2009, abhishekkumar wrote: bus ps3_system_bus, device sb_05 (driver 10 Dec 2004) PS3 EHCI Host Controller EHCI ff.ff, hcd state 1 structural params 0x capability params 0x status Async Periodic Recl Halt IAA FATAL FLR PCD ERR INT command park=3 ithresh=63 LReset IAAD Async Periodic period=?? Reset R intrenable IAA FATAL FLR PCD ERR INT uframe port 1 status POWER OWNER sig=? RESET SUSPEND RESUME OCC OC PEC PE CSC port 2 status POWER OWNER sig=? RESET SUSPEND RESUME OCC OC PEC PE CSC irq normal 30832 err 30 reclaim 84 (lost 1) complete 31221 unlink 10 This is very bad. It indicates that the CPU was unable to communicate with the EHCI controller at all! All the memory-mapped I/O reads returned 0x. No wonder the keyboard and mouse stopped working. I have no idea what could have caused this to happen. Even if the controller had suffered a fatal error, you wouldn't see this. It looks like the bus's connection to the controller was turned off. I'm CC-ing the PS3 maintainer and mailing list. Maybe people there can help. Alan Stern There is a known but yet unfixed bug for the PS3's EHCI Async Periodic (typically audio recording) device handling. There are a few related hardware errata that I have not yet implemented driver fixes for that I think are causing it. I guess it is the same problem as reported by Abhishek since Andrew's dmesg (http://www.osl.iu.edu/~afriedle/dmesg.txt) shows similar results. More info is here: http://ozlabs.org/pipermail/cbe-oss-dev/2009-February/006365.html I have bought a ART Tube USB device but have not had time to fix this bug. It is on my todo list. Please feel free to make an attempt. Alan, thanks for your effort on this so far, sorry you didn't know about the previous report. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
On Fri, 26 Jun 2009, Geoff Levand wrote: There is a known but yet unfixed bug for the PS3's EHCI Async Periodic (typically audio recording) device handling. There are a few related hardware errata that I have not yet implemented driver fixes for that I think are causing it. I guess it is the same problem as reported by Abhishek since Andrew's dmesg (http://www.osl.iu.edu/~afriedle/dmesg.txt) shows similar results. Yes, it definitely looks the same. More info is here: http://ozlabs.org/pipermail/cbe-oss-dev/2009-February/006365.html I have bought a ART Tube USB device but have not had time to fix this bug. It is on my todo list. Please feel free to make an attempt. Where is the information about the hardware errata you mentioned? Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
On 06/26/2009 01:42 PM, Alan Stern wrote: On Fri, 26 Jun 2009, Geoff Levand wrote: There is a known but yet unfixed bug for the PS3's EHCI Async Periodic (typically audio recording) device handling. There are a few related hardware errata that I have not yet implemented driver fixes for that I think are causing it. I guess it is the same problem as reported by Abhishek since Andrew's dmesg (http://www.osl.iu.edu/~afriedle/dmesg.txt) shows similar results. Yes, it definitely looks the same. More info is here: http://ozlabs.org/pipermail/cbe-oss-dev/2009-February/006365.html I have bought a ART Tube USB device but have not had time to fix this bug. It is on my todo list. Please feel free to make an attempt. Where is the information about the hardware errata you mentioned? Sorry, I should have mentioned it. Unfortunately, that info is not in the public as far as I know. I think only someone with access to those will be able to work on this fix. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/4 for 2.6.31] NET: Revive fixed link support
Hi all, The fixed link support is broken since The Big OF MDIO Rework, the rework simply removed most of the code that was needed for fixed links. Too bad I didn't notice this earlier, I saw a bunch of patches on the ml, but unfortunately I didn't look very close presuming that Grant knew what he was doing. :-) And obviously I didn't test linux-next on anything that requires a fixed link. Anyway, here are four patches. The first one adds the fixed link support to a framework, otherwise we'd duplicate the code across the drivers (as we did previously), and I tried to keep drivers' changes minimal. Patches 2 and 3 are for the drivers that I tested in run-time, with normal PHYs, and fixed links. Patch #4 was build-tested, but I believe it should work in run-time too. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] of/mdio: Add fixed link support
Currently the fixed link support is broken for all OF ethernet drivers,
an OF MDIO rework removed most of the support. Instead of re-adding
fixed-link stuff to the drivers, add the support to a framework, so we
won't duplicate any code.
With this patch, if a node pointer is NULL, then of_phy_connect() will
try to find ethernet device's node, then will look for fixed-link
property, and if specified, it connects PHY as usual, via bus_id (fixed
link PHYs do not have any device tree nodes associated with them).
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/of/of_mdio.c | 45 +
1 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index aee967d..cfd876a 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -9,6 +9,10 @@
* out of the OpenFirmware device tree and using it to populate an mii_bus.
*/
+#include linux/kernel.h
+#include linux/device.h
+#include linux/netdevice.h
+#include linux/err.h
#include linux/phy.h
#include linux/of.h
#include linux/of_mdio.h
@@ -129,11 +133,44 @@ struct phy_device *of_phy_connect(struct net_device *dev,
void (*hndlr)(struct net_device *), u32 flags,
phy_interface_t iface)
{
- struct phy_device *phy = of_phy_find_device(phy_np);
+ struct phy_device *phy = NULL;
+
+ if (phy_np) {
+ int ret;
+
+ phy = of_phy_find_device(phy_np);
+ if (!phy)
+ return NULL;
+
+ ret = phy_connect_direct(dev, phy, hndlr, flags, iface);
+ if (ret)
+ return NULL;
+ } else if (dev-dev.parent) {
+ struct device_node *net_np;
+ const u32 *phy_id;
+ char *bus_id;
+ int sz;
+
+ net_np = dev_archdata_get_node(dev-dev.parent-archdata);
+ if (!net_np)
+ return NULL;
+
+ phy_id = of_get_property(net_np, fixed-link, sz);
+ if (!phy_id || sz sizeof(*phy_id))
+ return NULL;
+
+ bus_id = kasprintf(GFP_KERNEL, PHY_ID_FMT, 0, phy_id[0]);
+ if (!bus_id) {
+ dev_err(dev-dev, could not allocate memory\n);
+ return NULL;
+ }
- if (!phy)
- return NULL;
+ phy = phy_connect(dev, bus_id, hndlr, 0, iface);
+ kfree(bus_id);
+ if (IS_ERR(phy))
+ return NULL;
+ }
- return phy_connect_direct(dev, phy, hndlr, flags, iface) ? NULL : phy;
+ return phy;
}
EXPORT_SYMBOL(of_phy_connect);
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] ucc_geth: Revive fixed link support
Since commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 (Rework
ucc_geth driver to use of_mdio infrastructure) the fixed-link
support is broken.
This patch fixes the support by removing !ug_info-phy_node check,
today the of_phy_connect() will try to find a fixed PHY if the
phy_node appears to be NULL.
Also, remove an old fixed-link code that we don't use any longer.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/ucc_geth.c | 18 +++---
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 40c6eba..2dc83b1 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1590,9 +1590,6 @@ static int init_phy(struct net_device *dev)
priv-oldspeed = 0;
priv-oldduplex = -1;
- if (!ug_info-phy_node)
- return 0;
-
phydev = of_phy_connect(dev, ug_info-phy_node, adjust_link, 0,
priv-phy_interface);
if (!phydev) {
@@ -3608,9 +3605,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
struct ucc_geth_private *ugeth = NULL;
struct ucc_geth_info *ug_info;
struct resource res;
- struct device_node *phy;
int err, ucc_num, max_speed = 0;
- const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
const void *mac_addr;
@@ -3708,15 +3703,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
ug_info-uf_info.regs = res.start;
ug_info-uf_info.irq = irq_of_parse_and_map(np, 0);
- fixed_link = of_get_property(np, fixed-link, NULL);
- if (fixed_link) {
- phy = NULL;
- } else {
- phy = of_parse_phandle(np, phy-handle, 0);
- if (phy == NULL)
- return -ENODEV;
- }
- ug_info-phy_node = phy;
+
+ ug_info-phy_node = of_parse_phandle(np, phy-handle, 0);
/* Find the TBI PHY node. If it's not there, we don't support SGMII */
ug_info-tbi_node = of_parse_phandle(np, tbi-handle, 0);
@@ -3725,7 +3713,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
prop = of_get_property(np, phy-connection-type, NULL);
if (!prop) {
/* handle interface property present in old trees */
- prop = of_get_property(phy, interface, NULL);
+ prop = of_get_property(ug_info-phy_node, interface, NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
max_speed = enet_to_speed[*prop];
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] fs_enet: Revive fixed link support
Since commit aa73832c5a80d6c52c69b18af858d88fa595dd3c (Rework
fs_enet driver to use of_mdio infrastructure) the fixed-link support
is broken in the fs_enet driver.
This patch fixes the support by removing a check for phy_node, today
of_phy_connect() tries to find fixed PHY if phy_node appears to be
NULL.
Also set netdev parent device via SET_NETDEV_DEV() call, this is needed
so that OF MDIO core could find a node pointer for a device.
Plus, fix if (IS_ERR(phydev)) check, in case of errors,
of_phy_connect() returns NULL, not ERR_PTR as phy_connect().
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/fs_enet/fs_enet-main.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index b892c3a..1fea39e 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -754,15 +754,10 @@ static int fs_init_phy(struct net_device *dev)
fep-oldlink = 0;
fep-oldspeed = 0;
fep-oldduplex = -1;
- if(fep-fpi-phy_node)
- phydev = of_phy_connect(dev, fep-fpi-phy_node,
- fs_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
- else {
- printk(No phy bus ID specified in BSP code\n);
- return -EINVAL;
- }
- if (IS_ERR(phydev)) {
+
+ phydev = of_phy_connect(dev, fep-fpi-phy_node, fs_adjust_link, 0,
+ PHY_INTERFACE_MODE_MII);
+ if (!phydev) {
printk(KERN_ERR %s: Could not attach to PHY\n, dev-name);
return PTR_ERR(phydev);
}
@@ -1005,6 +1000,7 @@ static int __devinit fs_enet_probe(struct of_device
*ofdev,
goto out_free_fpi;
}
+ SET_NETDEV_DEV(ndev, ofdev-dev);
dev_set_drvdata(ofdev-dev, ndev);
fep = netdev_priv(ndev);
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4 for 2.6.31] NET: Revive fixed link support
On Fri, Jun 26, 2009 at 4:29 PM, Anton Vorontsovavoront...@ru.mvista.com wrote: Hi all, The fixed link support is broken since The Big OF MDIO Rework, the rework simply removed most of the code that was needed for fixed links. Too bad I didn't notice this earlier, I saw a bunch of patches on the ml, but unfortunately I didn't look very close presuming that Grant knew what he was doing. :-) And obviously I didn't test linux-next on anything that requires a fixed link. Apparently I didn't. sorry. Anyway, here are four patches. The first one adds the fixed link support to a framework, otherwise we'd duplicate the code across the drivers (as we did previously), and I tried to keep drivers' changes minimal. As I described in my previous email, I don't think this is a good approach and I don't think it should be merged. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] of/mdio: Add fixed link support
On Fri, Jun 26, 2009 at 05:33:26PM -0600, Grant Likely wrote: On Fri, Jun 26, 2009 at 4:29 PM, Anton Vorontsovavoront...@ru.mvista.com wrote: Currently the fixed link support is broken for all OF ethernet drivers, an OF MDIO rework removed most of the support. Instead of re-adding fixed-link stuff to the drivers, add the support to a framework, so we won't duplicate any code. With this patch, if a node pointer is NULL, then of_phy_connect() will try to find ethernet device's node, then will look for fixed-link property, and if specified, it connects PHY as usual, via bus_id (fixed link PHYs do not have any device tree nodes associated with them). Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Ugh. I do not like this approach. I did not intend to break fixed links, but I do not think that this approach is the right fix. There are several problems. I don't like the fixed.c approach of creating a dummy phy to begin with. I think it is an abuse of the device model to register a dummy mii_bus and have dummy devices registered on it. It is a lot of code for what should be a very simple thing. In particular, if a PHY is not specified, then the driver should use a static link configuration. This is trivial to implement in an Ethernet driver and I do not think the dummy phy adds anything. Dummy PHYs add more than you think, for example you'll have to refactor or duplicate the code that is responsible for MAC settings for a given mode (10/100/100, duplex, pause), and you'll have to do netif_carrier_* handling yourself. Not a problem per se, but you'll have to address this, and you'll have two paths in the drivers. It hooks into the initialization path of *all* OF enabled net drivers, whether it wants it or not. ie. The MPC5200 FEC driver does not want it because the fixed-link property is not part of the mpc5200-fec binding; it uses a current-speed property instead. 'fixed-link' has not been agreed upon to be applicable to all Ethernet bindings, and I'm not convinced that the format of it won't need to be changed for future Ethernet bindings. A function for parsing fixed-link should be a library function that a driver can choose to call out to. It should not be welded into the init path. I also think parsing the device tree at device open time (when of_phy_connect is usually called) is best to be avoided. fixed-link parsing should really happen at probe time and the values cached IMHO. It's probably not significant, but I'd like to keep device tree reads constrained in the cold path (driver probe time) as opposed to the hot (or slightly less cool) device open path. open() time isn't a hot path at all. Instead, I think that each driver should be more graceful about missing phy pointers and the init path should call out to a fixed-link parser function that sets the initial link settings. Probably less than 5 lines of code per driver. I'm sorry about breaking it. It was my fault, and I'd be happy to fix it if you'd like me to, Please do. but I don't think that this patch is the right approach. OK, fine by me if you think you can do this stuff better. :-) -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
On Fri, 26 Jun 2009, Geoff Levand wrote: Where is the information about the hardware errata you mentioned? Sorry, I should have mentioned it. Unfortunately, that info is not in the public as far as I know. I think only someone with access to those will be able to work on this fix. Okay, then I guess there's nothing more I can do regarding Bug #13304. Can you take it over? Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Allow perf_counters to access user memory at interrupt time
This provides a mechanism to allow the perf_counters code to access
user memory in a PMU interrupt routine on a 64-bit kernel. Such an
access can cause a SLB miss interrupt and/or a MMU hash table miss
interrupt.
An SLB miss interrupt on a user address will update the slb_cache and
slb_cache_ptr fields in the paca. This is OK except in the case where
a PMU interrupt occurs in switch_slb, which also accesses those fields.
To prevent this, we hard-disable interrupts in switch_slb. Interrupts
are already soft-disabled in switch-slb, and will get hard-enabled
when they get soft-enabled later.
If a MMU hashtable miss interrupt occurs, normally we would call
hash_page to look up the Linux PTE for the address and create a HPTE.
However, hash_page is fairly complex and takes some locks, so to
avoid the possibility of deadlock, we add a flag to the paca to
indicate to the MMU hashtable miss handler that it should not call
hash_page but instead treat it like a bad access that will get
reported up through the exception table mechanism. The PMU interrupt
code should then set this flag (get_paca()-in_pmu_nmi) and use
__get_user_inatomic to read user memory. If there is no HPTE for
the address, __get_user_inatomic will return -EFAULT.
On a 32-bit processor, there is no SLB. The 32-bit hash_page appears
to be safe to call in an interrupt handler since we don't do soft
disabling of interrupts on 32-bit, and the only lock that hash_page
takes is the mmu_hash_lock, which is always taken with interrupts
hard-disabled.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/paca.h |3 ++-
arch/powerpc/kernel/asm-offsets.c|2 ++
arch/powerpc/kernel/exceptions-64s.S | 21 +
arch/powerpc/mm/slb.c| 10 +-
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index c8a3cbf..17b29b1 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -105,7 +105,8 @@ struct paca_struct {
u8 soft_enabled;/* irq soft-enable flag */
u8 hard_enabled;/* set if irqs are enabled in MSR */
u8 io_sync; /* writel() needs spin_unlock sync */
- u8 perf_counter_pending;/* PM interrupt while soft-disabled */
+ u8 perf_counter_pending;/* perf_counter stuff needs wakeup */
+ u8 in_pmu_nmi; /* PM interrupt while soft-disabled */
/* Stuff for accurate time accounting */
u64 user_time; /* accumulated usermode TB ticks */
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 561b646..5347780 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -130,6 +130,7 @@ int main(void)
DEFINE(PACASOFTIRQEN, offsetof(struct paca_struct, soft_enabled));
DEFINE(PACAHARDIRQEN, offsetof(struct paca_struct, hard_enabled));
DEFINE(PACAPERFPEND, offsetof(struct paca_struct,
perf_counter_pending));
+ DEFINE(PACAPERFNMI, offsetof(struct paca_struct, in_pmu_nmi));
DEFINE(PACACONTEXTID, offsetof(struct paca_struct, context.id));
#ifdef CONFIG_PPC_MM_SLICES
DEFINE(PACALOWSLICESPSIZE, offsetof(struct paca_struct,
@@ -398,6 +399,7 @@ int main(void)
DEFINE(VCPU_TIMING_LAST_ENTER_TBL, offsetof(struct kvm_vcpu,
arch.timing_last_enter.tv32.tbl));
#endif
+ DEFINE(SIGSEGV, SIGSEGV);
return 0;
}
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index eb89811..02d96b0 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -722,6 +722,12 @@ _STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
+#ifdef CONFIG_PERF_COUNTERS
+ lbz r0,PACAPERFNMI(r13)
+ cmpwi r0,0
+ bne 77f /* if we don't want to hash_page now */
+#endif /* CONFIG_PERF_COUNTERS */
+
andis. r0,r4,0xa450/* weird error? */
bne-handle_page_fault /* if not, try to insert a HPTE */
BEGIN_FTR_SECTION
@@ -833,6 +839,21 @@ handle_page_fault:
bl .low_hash_fault
b .ret_from_except
+#ifdef CONFIG_PERF_COUNTERS
+/*
+ * We come here as a result of a DSI when accessing memory (possibly
+ * user memory) inside a PMU interrupt that occurred while interrupts
+ * were soft-disabled, so we just want to invoke the exception handler
+ * for the access, or panic if there isn't a handler.
+ */
+77:bl .save_nvgprs
+ mr r4,r3
+ addir3,r1,STACK_FRAME_OVERHEAD
+ li r5,SIGSEGV
+ bl .bad_page_fault
+ b .ret_from_except
+#endif
+
/* here we have a segment miss */
do_ste_alloc:
bl .ste_allocate /* try to
[PATCH 2/2] perf_counter: powerpc: Add callchain support
This adds support for tracing callchains for powerpc, both 32-bit
and 64-bit, and both in the kernel and userspace, from PMU interrupt
context.
The first three entries stored for each callchain are the NIP (next
instruction pointer), LR (link register), and the contents of the LR
save area in the second stack frame (the first is ignored because the
ABI convention on powerpc is that functions save their return address
in their caller's stack frame). Because functions don't have to save
their return address (LR value) and don't have to establish a stack
frame, it's possible for either or both of LR and the second stack
frame's LR save area to have valid return addresses in them. This
is basically impossible to disambiguate without either reading the
code or looking at auxiliary information such as CFI tables. Since
we don't want to do that at interrupt time, we store both LR and the
second stack frame's LR save area.
Once we get past the second stack frame, there is no ambiguity; all
return addresses we get are reliable.
For kernel traces, we check whether they are valid kernel instruction
addresses and store zero instead if they are not (rather than
omitting them, which would make it impossible for userspace to know
which was which). We also store zero instead of the second stack
frame's LR save area value if it is the same as LR.
For kernel traces, we check for interrupt frames, and for user traces,
we check for signal frames. In each case, since we're starting a new
trace, we store a PERF_CONTEXT_KERNEL/USER marker so that userspace
knows that the next three entries are NIP, LR and the second stack frame
for the interrupted context.
We read user memory with __get_user_inatomic. On 64-bit, we set a flag
to indicate that the data storage exception handler shouldn't call
hash_page on a MMU hashtable miss. Instead we get a -EFAULT from
__get_user_inatomic and then read the Linux PTE and access the page
via the kernel linear mapping. Since 64-bit doesn't use (or need)
highmem there is no need to do kmap_atomic.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/perf_callchain.c | 544 ++
2 files changed, 545 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/kernel/perf_callchain.c
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index b73396b..9619285 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -97,7 +97,7 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
-obj-$(CONFIG_PPC_PERF_CTRS)+= perf_counter.o
+obj-$(CONFIG_PPC_PERF_CTRS)+= perf_counter.o perf_callchain.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o
obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
diff --git a/arch/powerpc/kernel/perf_callchain.c
b/arch/powerpc/kernel/perf_callchain.c
new file mode 100644
index 000..3cc1487
--- /dev/null
+++ b/arch/powerpc/kernel/perf_callchain.c
@@ -0,0 +1,544 @@
+/*
+ * Performance counter callchain support - powerpc architecture code
+ *
+ * Copyright © 2009 Paul Mackerras, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/perf_counter.h
+#include linux/percpu.h
+#include linux/uaccess.h
+#include linux/mm.h
+#include asm/ptrace.h
+#include asm/pgtable.h
+#include asm/sigcontext.h
+#include asm/ucontext.h
+#include asm/vdso.h
+#ifdef CONFIG_PPC64
+#include ppc32.h
+#endif
+
+/*
+ * Store another value in a callchain_entry.
+ */
+static inline void callchain_store(struct perf_callchain_entry *entry, u64 ip)
+{
+ unsigned int nr = entry-nr;
+
+ if (nr PERF_MAX_STACK_DEPTH) {
+ entry-ip[nr] = ip;
+ entry-nr = nr + 1;
+ }
+}
+
+/*
+ * Is sp valid as the address of the next kernel stack frame after prev_sp?
+ * The next frame may be in a different stack area but should not go
+ * back down in the same stack area.
+ */
+static int valid_next_sp(unsigned long sp, unsigned long prev_sp)
+{
+ if (sp 0xf)
+ return 0; /* must be 16-byte aligned */
+ if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD))
+ return 0;
+ if (sp = prev_sp + STACK_FRAME_OVERHEAD)
+ return 1;
+ /*
+* sp could decrease when we jump off an interrupt stack
+* back to the regular process stack.
+*/
+ if ((sp ~(THREAD_SIZE - 1)) != (prev_sp ~(THREAD_SIZE - 1)))
+ return 1;
+ return 0;
+}
+
