Memory mapped IO and Direct File IO
Greetings, everyone, I'm trying to save some data block from a memory mapped device into a file - real fast, i.e., without any copying. My approach so far was to get a pointer to the io memory via mmap-ing /dev/mem, and then writing this pointer to a file (in user space). This works, if I don't use O_DIRECT, but this is slow of course. Using O_DIRECT, write returns EFAULT (bad address). Coyping the data to a user-space buffer and then writing with O_DIRECT works, though. I tracked this down to __get_user_pages in mm/memory.c where IO pages are refused. And this is as deep as my current knowledge allows me to go into the kernel. I don't understand why IO pointers are not allowed. Ultra-Fast disk IO is a requirement for our project, so any copying in between is not an option. Any hint is appreciated. Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Mon, 2009-08-03 at 12:57 -0500, Dave Kleikamp wrote:
cpu_last_thread_in_core(cpu) is a moving target. You want something
like:
cpu = cpu_first_thread_in_core(cpu);
last = cpu_last_thread_in_core(cpu);
while (cpu = last) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
Or, keeping the for loop:
for (cpu = cpu_first_thread_in_core(cpu), last =
cpu_last_thread_in_core(cpu);
cpu = last; cpu++)
cpu++;
Yeah, whatever form is good, I had a brain fart and didn't see that in
the end of loop, cpu would have actually crossed the boundary to the
next core and so cpu_last_thread_in_core() would change. Just some short
circuit in a neuron somewhere.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
AW: Kernel fault with simple UIO interrupt driver in 2.6.30.4
Oh okay, I didnt think anybody would need it :)
= bootm 200 - 300
## Booting image at 0200 ...
Image Name: Linux-2.6.30.4
Created: 2009-08-04 7:06:18 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:3978238 Bytes = 3.8 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x300
Using MPC831x RDB machine description
Linux version 2.6.30.4 (r...@vmlinux) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0))
#25 Tue Aug 4 09:05:58 CEST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc831x_rdb_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x - 0x8000
Normal 0x8000 - 0x8000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x8000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: BOOTLOADER_VER=MCU_bl_BPT_1.0.4
NR_IRQS:512
IPIC (128 IRQ sources) at fdffd700
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[781] shift[22] registered
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 123888k/131072k available (5560k kernel code, 7020k reserved, 184k
data, 93k bss, 2476k init)
Kernel virtual memory layout:
* 0xe000..0xf000 : fixmap
* 0xfdffc000..0xfe00 : early ioremap
* 0xc900..0xfdffc000 : vmalloc ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 66.56 BogoMIPS (lpj=133120)
Mount-cache hash table entries: 512
net_namespace: 716 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
bio: create slab bio-0 at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 242
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] - real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
brd: module loaded
loop: module loaded
eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:33
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:7e:21
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Fixed MDIO Bus: probed
IRQ 20/IRQ3 Kernel Driver: IRQF_DISABLED is not guaranteed on shared IRQs
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
MPC831x RDB
Modules linked in:
NIP: LR: c004755c CTR:
REGS: c7827d50 TRAP: 0400 Not tainted (2.6.30.4)
MSR: 20001032 ME,IR,DR CR: 2822 XER: 2000
TASK = c7828000[1] 'swapper' THREAD: c7826000
GPR00: 0002 c7827e00 c7828000 0014 0002 0014 c73adb7c c06bb460
GPR08: 0014 07fff000 0001
GPR16: 007fff00 07ff9794 007ffeb0
GPR24: c73ad180 c02d70a4 c0574f28 9032 0014 c73adb40 c0574f08
Call Trace:
[c7827e00] [c00474e4] 0xc00474e4 (unreliable)
[c7827e20] [c0047754] 0xc0047754
[c7827e50] [c019c568] 0xc019c568
[c7827e90] [c019c7f8] 0xc019c7f8
[c7827ea0] [c0177a80] 0xc0177a80
[c7827ec0] [c0177b94] 0xc0177b94
[c7827ee0] [c01764d8] 0xc01764d8
[c7827f10] [c0177590] 0xc0177590
[c7827f20] [c017703c] 0xc017703c
[c7827f40] [c0178080] 0xc0178080
[c7827f60] [c0319884] 0xc0319884
[c7827f70] [c00038dc] 0xc00038dc
[c7827fe0] [c03037c0] 0xc03037c0
[c7827ff0] [c0010778] 0xc0010778
Instruction dump:
---[ end trace 747097271ea314a9 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone: +49 731 88 00 71 58
Fax: +49 731 88 00 71 99
Email: frank.prepel...@ubidyne.com
Homepage: www.ubidyne.com
Registered office: Ulm
AW: Kernel fault with simple UIO interrupt driver in 2.6.30.4
Additional information: The kernel fault already happens in 2.6.25 The driver works fine in 2.6.24 (Interrupt available in /proc/interrupts and /sys/class/uio/uio0) Are there changes in 2.6.25 which could cause the kernel fault? Any hint is appreaciated! Thx and kind regards Frank Prepelica Software Design Engineer Ubidyne GmbH Lise-Meitner-Str.-14 89081 Ulm - Germany Phone: +49 731 88 00 71 58 Fax: +49 731 88 00 71 99 Email: frank.prepel...@ubidyne.com Homepage: www.ubidyne.com Registered office: Ulm District court of Ulm: HRB 5295 Managing Directors: Dipl. Ing. Ken Hawk Dipl. Ing. Beat Müller Dipl. Ing. Mike Levis -Ursprüngliche Nachricht- Von: linuxppc-dev-bounces+frank.prepelica=ubidyne@lists.ozlabs.org [mailto:linuxppc-dev-bounces+frank.prepelica=ubidyne@lists.ozlabs.org] Im Auftrag von Frank Prepelica Gesendet: Dienstag, 4. August 2009 09:24 An: mich...@ellerman.id.au Cc: linuxppc-...@ozlabs.org Betreff: AW: Kernel fault with simple UIO interrupt driver in 2.6.30.4 Oh okay, I didnt think anybody would need it :) = bootm 200 - 300 ## Booting image at 0200 ... Image Name: Linux-2.6.30.4 Created: 2009-08-04 7:06:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:3978238 Bytes = 3.8 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x300 Using MPC831x RDB machine description Linux version 2.6.30.4 (r...@vmlinux) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #25 Tue Aug 4 09:05:58 CEST 2009 console [udbg0] enabled setup_arch: bootmem mpc831x_rdb_setup_arch() arch: exit Zone PFN ranges: DMA 0x - 0x8000 Normal 0x8000 - 0x8000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x8000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: BOOTLOADER_VER=MCU_bl_BPT_1.0.4 NR_IRQS:512 IPIC (128 IRQ sources) at fdffd700 PID hash table entries: 512 (order: 9, 2048 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 123888k/131072k available (5560k kernel code, 7020k reserved, 184k data, 93k bss, 2476k init) Kernel virtual memory layout: * 0xe000..0xf000 : fixmap * 0xfdffc000..0xfe00 : early ioremap * 0xc900..0xfdffc000 : vmalloc ioremap SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 66.56 BogoMIPS (lpj=133120) Mount-cache hash table entries: 512 net_namespace: 716 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware bio: create slab bio-0 at 0 SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 Freescale PowerQUICC MII Bus: probed Freescale PowerQUICC MII Bus: probed JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. msgmni has been set to 242 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A console handover: boot [udbg0] - real [ttyS0] serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A brd: module loaded loop: module loaded eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:33 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:7e:21 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation Fixed MDIO Bus: probed IRQ 20/IRQ3 Kernel Driver: IRQF_DISABLED is not guaranteed on shared IRQs Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x Oops: Kernel access of bad area, sig: 11 [#1] MPC831x RDB Modules linked in: NIP: LR: c004755c CTR: REGS: c7827d50 TRAP: 0400 Not tainted (2.6.30.4) MSR: 20001032 ME,IR,DR CR: 2822 XER: 2000 TASK = c7828000[1] 'swapper' THREAD: c7826000 GPR00: 0002 c7827e00 c7828000 0014 0002 0014 c73adb7c c06bb460 GPR08: 0014 07fff000 0001 GPR16: 007fff00 07ff9794 007ffeb0
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31: On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote: [...] But any users of the legacy bindings should be in-tree. ehh, it was working until you made it OF only. Why do call the native way legacy? It is the method all non OF arch uses. It's legacy because there are no in-tree users anymore. Nowadays we're trying to pass all needed information via OF, and we're trying to avoid ugly platform-dependant hacks. Your SPI scheme can be easily described via OF, but sure, it's hard to implement it with the current SPI/OF subsystem. Sorry for the long delay, I have been on vaction and been busy with other stuff. Tell me, how does this new OF SPI device scheme work out if you want to use the bitbanged SPI driver? [...] http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg34738.html ^^^ I'm dreaming about this framework. I.e. true addressing for chip-selects. :-) This is probably needed to support most SPI users out there, but until such framework is in place I think the native methods need to stay, right? I'm not the right person to ask. I can only express my opinions. The maintainer make final decision. But if you ask for my opinion, I don't think that they should stay unless we'll see a user in the mainline. As is now, SPI has regressed w.r.t earlier releases. Yes and no. Yes, it has regressed for out-of-tree code, and no, I don't feel sorry about that. :-) That is a Yes and some bla bla so the answer is yes. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
On Tue, 2009-08-04 at 19:13 +0530, Sachin Sant wrote: Forgot to copy netdev in my original message. Forwarding .. I have a power6 blade [IBM,7998-61X] running 2.6.31-rc5-git2 kernel (a33a052f19a21d727847391c8c1aff3fb221c472). After some period of inactivity the machine drops into xmon with following traces. cpu 0x0: Vector: 700 (Program Check) at [ca90] pc: c060: .flow_cache_new_hashrnd+0x3c/0xcc lr: c00c6038: .run_timer_softirq+0x20c/0x2f4 sp: cd10 msr: 80089032 current = 0xc0f58b70 paca= 0xc10b2400 pid = 0, comm = swapper enter ? for help [cda0] c00c6038 .run_timer_softirq+0x20c/0x2f4 [cea0] c00be8a0 .__do_softirq+0x174/0x2c8 [cf90] c00307b0 .call_do_softirq+0x14/0x24 [c1013870] c000ecf8 .do_softirq+0xa0/0x104 [c1013910] c00be1d0 .irq_exit+0x74/0xd4 [c1013990] c002ce20 .timer_interrupt+0x1cc/0x200 [c1013a30] c0003728 decrementer_common+0x128/0x180 --- Exception: 901 (Decrementer) at c000ec3c .raw_local_irq_restore+0xc0/0xdc [c1013dc0] c0015824 .cpu_idle+0x13c/0x1e0 [c1013e60] c0009fe8 .rest_init+0x94/0xcc [c1013ee0] c0990cf4 .start_kernel+0x484/0x4a8 [c1013f90] c0008408 .start_here_common+0x2c/0xa4 0:mon di $.flow_cache_new_hashrnd c05fffc4 7c0802a6 mflrr0 c05fffc8 f8010010 std r0,16(r1) c05fffcc fb81ffe0 std r28,-32(r1) c05fffd0 fba1ffe8 std r29,-24(r1) c05fffd4 fbc1fff0 std r30,-16(r1) c05fffd8 fbe1fff8 std r31,-8(r1) c05fffdc f821ff71 stdur1,-144(r1) c05fffe0 7c3f0b78 mr r31,r1 c05fffe4 ebc2dc90 ld r30,-9072(r2) c05fffe8 3b81 li r28,1 c05fffec 6000 nop ... c054 e93e8048 ld r9,-32696(r30) c058 38a0 li r5,-1 c05c eba9 ld r29,0(r9) c060 1010 .long 0x1010 0:mon c064 0008 .long 0x8 c068 1013 .long 0x1013 c06c 000f .long 0xf c0600010 7961626f rldimi. r1,r11,44,41 c0600014 6f74 xoris r20,r27,0 c0600018 00101600 .long 0x101600 c060001c 0c00 .long 0xc00 c0600020 0400 .long 0x400 c0600024 00101100 .long 0x101100 c0600028 08e9 .long 0x8e9 What's going on here? How does the above disassembly compare with an objdump -d of your vmlinux? It looks like either: * gcc is generating some weird code sequences * xmon doesn't know how to disassemble those instructions * someone crapped on your kernel text cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2.6.31] ehea: Fix napi list corruption on ifconfig down
This patch fixes the napi list handling when an ehea interface is shut down to
avoid corruption of the napi list.
Signed-off-by: Hannes Hering heri...@de.ibm.com
---
diff -Nurp -X dontdiff linux-2.6.31-rc5/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.31-rc5/drivers/net/ehea/ehea.h2009-08-01 02:40:45.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2009-08-03 17:59:26.696079433
+0200
@@ -40,7 +40,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0101
+#define DRV_VERSIONEHEA_0102
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.31-rc5/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.31-rc5/drivers/net/ehea/ehea_main.c 2009-08-01
02:40:45.0 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2009-08-03 17:59:26.696079433
+0200
@@ -1545,6 +1545,9 @@ static int ehea_clean_portres(struct ehe
{
int ret, i;
+ if (pr-qp)
+ netif_napi_del(pr-napi);
+
ret = ehea_destroy_qp(pr-qp);
if (!ret) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
On Tue, Aug 04, 2009 at 03:38:40PM +0200, Joakim Tjernlund wrote:
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31:
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
[...]
But any users of the legacy bindings should be in-tree.
ehh, it was working until you made it OF only. Why do call the native
way legacy? It is the method all non OF arch uses.
It's legacy because there are no in-tree users anymore. Nowadays
we're trying to pass all needed information via OF, and we're
trying to avoid ugly platform-dependant hacks. Your SPI scheme
can be easily described via OF, but sure, it's hard to implement
it with the current SPI/OF subsystem.
Sorry for the long delay, I have been on vaction and been busy with other
stuff.
Tell me, how does this new OF SPI device scheme work out if you want
to use the bitbanged SPI driver?
spi-controller {
...
compatible = generic-bitbang-spi;
gpios = GPIO_CLK GPIO_MOSI GPIO_MISO;
spi,chip-select-machines = gpio_csm board_csm;
gpio_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatible = generic-gpio-csm;
gpios = GPIO_CS1 GPIO_CS2;
touchscr...@0 {
reg = 0; /* using GPIO CS1 */
};
eep...@1 {
reg = 1; /* using GPIO CS2 */
};
};
};
localbus {
...
board_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatibe = board-specific-csm;
light-sen...@0 {
reg = 0; /* using board-specific CS3 */
};
batt...@1 {
reg = 1; /* using board-specific CS4 */
};
};
};
--
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: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
Anton Vorontsov avoront...@ru.mvista.com wrote on 04/08/2009 16:22:50:
On Tue, Aug 04, 2009 at 03:38:40PM +0200, Joakim Tjernlund wrote:
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31:
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
[...]
But any users of the legacy bindings should be in-tree.
ehh, it was working until you made it OF only. Why do call the native
way legacy? It is the method all non OF arch uses.
It's legacy because there are no in-tree users anymore. Nowadays
we're trying to pass all needed information via OF, and we're
trying to avoid ugly platform-dependant hacks. Your SPI scheme
can be easily described via OF, but sure, it's hard to implement
it with the current SPI/OF subsystem.
Sorry for the long delay, I have been on vaction and been busy with other
stuff.
Tell me, how does this new OF SPI device scheme work out if you want
to use the bitbanged SPI driver?
spi-controller {
...
compatible = generic-bitbang-spi;
gpios = GPIO_CLK GPIO_MOSI GPIO_MISO;
spi,chip-select-machines = gpio_csm board_csm;
gpio_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatible = generic-gpio-csm;
gpios = GPIO_CS1 GPIO_CS2;
touchscr...@0 {
reg = 0; /* using GPIO CS1 */
};
eep...@1 {
reg = 1; /* using GPIO CS2 */
};
};
};
localbus {
...
board_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatibe = board-specific-csm;
light-sen...@0 {
reg = 0; /* using board-specific CS3 */
};
batt...@1 {
reg = 1; /* using board-specific CS4 */
};
};
};
hmm, this looks promising. Can I write my own board-specific-csm
and attach it to the SPI CS engine? I don't quite
se how, the 8xxx SPI driver only looks for gpio functions.
Perhaps this is something that you are working on?
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
* wilbur.chan | 2009-08-02 09:25:43 [+0800]: Hi, Sebastian, Hi Wilbur, In your patch of Booke support for kexec , it setup a 1GB TMP mapping and jump to it. But I saw that, the max size for an e500 entry is 256M??so I changed your code to setup 4*256M entries, and it works well on mpc8541. The e500 core family reference manual [0] in chapter 12.2.2 (Variable-Sized Pages) says e500v1 supports only up to 256MiB and e500v2 supports up to 4GiB. So this code is e500v2 but not on purpose. Howerver,it didn't work on mpc8548(e500 v2) and P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also setup a 1:1 mapping for serial ,so I can trap the flowchart in relocate_new_kernel) Any suggestions about this ? Thank you very much. There is no SMP support. The other CPUs are not halted/resumed. At the time of writing it I did not have a SMP machine so I did not implement it. In general it should work on e500v2 boxes. There is one ugly thing: I did not setup the stack in the purgatory code. That means the purgatory code (and everything after it) is using kernel's old stack. This might corrupt things. I don't let purgatory code jump to the kernel code. Instead I jump to a tiny wrapper that is linked at 8Mib and takes the device tree which was handed over, uncompresses the kernel to 0x0 and jumps there. Since there is a gap betwwen 0 and 8MiB I usually have my purgatory stack there. Therefore the wrapper around kernel has to bring its own stack. regards, wilbur [0] E500CORERM.pdf Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] agp/uninorth: Simplify cache flushing.
From: Michel Dänzer daen...@vmware.com
Map the GART table uncached, so we don't always need to flush the CPU caches
explicitly after updates.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index eed2195..bc8b43a 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -7,6 +7,7 @@
#include linux/pagemap.h
#include linux/agp_backend.h
#include linux/delay.h
+#include linux/vmalloc.h
#include asm/uninorth.h
#include asm/pci-bridge.h
#include asm/prom.h
@@ -184,8 +185,6 @@ static int uninorth_insert_memory(struct agp_memory *mem,
off_t pg_start,
}
(void)in_le32((volatile u32*)agp_bridge-gatt_table[pg_start]);
mb();
- flush_dcache_range((unsigned long)agp_bridge-gatt_table[pg_start],
- (unsigned long)agp_bridge-gatt_table[pg_start +
mem-page_count]);
uninorth_tlbflush(mem);
return 0;
@@ -232,7 +231,6 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
(unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
}
mb();
- flush_dcache_range((unsigned long)gp, (unsigned long) gp[i]);
uninorth_tlbflush(mem);
return 0;
@@ -260,7 +258,6 @@ int u3_remove_memory(struct agp_memory *mem, off_t
pg_start, int type)
for (i = 0; i mem-page_count; ++i)
gp[i] = 0;
mb();
- flush_dcache_range((unsigned long)gp, (unsigned long) gp[i]);
uninorth_tlbflush(mem);
return 0;
@@ -413,6 +410,7 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
int i;
void *temp;
struct page *page;
+ struct page **pages;
/* We can't handle 2 level gatt's */
if (bridge-driver-size_type == LVL2_APER_SIZE)
@@ -441,21 +439,39 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
if (table == NULL)
return -ENOMEM;
+ pages = kmalloc((1 page_order) * sizeof(struct page*), GFP_KERNEL);
+ if (pages == NULL)
+ goto enomem;
+
table_end = table + ((PAGE_SIZE * (1 page_order)) - 1);
- for (page = virt_to_page(table); page = virt_to_page(table_end);
page++)
+ for (page = virt_to_page(table), i = 0; page = virt_to_page(table_end);
+page++, i++) {
SetPageReserved(page);
+ pages[i] = page;
+ }
bridge-gatt_table_real = (u32 *) table;
- bridge-gatt_table = (u32 *)table;
+ /* Need to clear out any dirty data still sitting in caches */
+ flush_dcache_range((unsigned long)table,
+ (unsigned long)(table_end + PAGE_SIZE));
+ bridge-gatt_table = vmap(pages, (1 page_order), 0, PAGE_KERNEL_NCG);
+
+ if (bridge-gatt_table == NULL)
+ goto enomem;
+
bridge-gatt_bus_addr = virt_to_gart(table);
for (i = 0; i num_entries; i++)
bridge-gatt_table[i] = 0;
- flush_dcache_range((unsigned long)table, (unsigned long)table_end);
-
return 0;
+
+enomem:
+ kfree(pages);
+ if (table)
+ free_pages((unsigned long)table, page_order);
+ return -ENOMEM;
}
static int uninorth_free_gatt_table(struct agp_bridge_data *bridge)
@@ -473,6 +489,7 @@ static int uninorth_free_gatt_table(struct agp_bridge_data
*bridge)
* from the table.
*/
+ vunmap(bridge-gatt_table);
table = (char *) bridge-gatt_table_real;
table_end = table + ((PAGE_SIZE * (1 page_order)) - 1);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 64 +++
1 files changed, 11 insertions(+), 53 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index bc8b43a..75aa33a 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -144,53 +144,7 @@ static int uninorth_configure(void)
return 0;
}
-static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
- int type)
-{
- int i, j, num_entries;
- void *temp;
- int mask_type;
-
- if (type != mem-type)
- return -EINVAL;
-
- mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
- if (mask_type != 0) {
- /* We know nothing of memory types */
- return -EINVAL;
- }
-
- if (mem-page_count == 0)
- return 0;
-
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
- if ((pg_start + mem-page_count) num_entries)
- return -EINVAL;
-
- j = pg_start;
-
- while (j (pg_start + mem-page_count)) {
- if (agp_bridge-gatt_table[j])
- return -EBUSY;
- j++;
- }
-
- for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge-gatt_table[j] =
- cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) | 0x1UL);
- flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
- (unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
- }
- (void)in_le32((volatile u32*)agp_bridge-gatt_table[pg_start]);
- mb();
-
- uninorth_tlbflush(mem);
- return 0;
-}
-
-static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
+static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start, int
type)
{
int i, num_entries;
void *temp;
@@ -219,14 +173,18 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
for (i = 0; i mem-page_count; ++i) {
if (gp[i]) {
dev_info(agp_bridge-dev-dev,
-u3_insert_memory: entry 0x%x occupied (%x)\n,
+uninorth_insert_memory: entry 0x%x occupied
(%x)\n,
i, gp[i]);
return -EBUSY;
}
}
for (i = 0; i mem-page_count; i++) {
- gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ if (is_u3)
+ gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ else
+ gp[i] = cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) |
+ 0x1UL);
flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
(unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
}
@@ -236,7 +194,7 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
return 0;
}
-int u3_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
+int uninorth_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
{
size_t i;
u32 *gp;
@@ -551,7 +509,7 @@ const struct agp_bridge_driver uninorth_agp_driver = {
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
.insert_memory = uninorth_insert_memory,
- .remove_memory = agp_generic_remove_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -577,8 +535,8 @@ const struct agp_bridge_driver u3_agp_driver = {
.agp_enable = uninorth_agp_enable,
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
- .insert_memory = u3_insert_memory,
- .remove_memory = u3_remove_memory,
+ .insert_memory = uninorth_insert_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] agp/uninorth: Allow larger aperture sizes on pre-U3 bridges.
From: Michel Dänzer daen...@vmware.com
Using the radeon KMS test functionality, I verified that the AGP bridge of the
Intrepid2 chipset in my PowerBook supports aperture sizes up to 256M. So allow
aperture sizes up to 256M on pre-U3 bridges as well, and bump the default size
to 256M. It's possible that older revisions only support smaller sizes, but
it'll be easy to verify that with the raden KMS test functionality. Also,
there's only a problem on an actual attempt to access the aperture beyond the
maximum size supported by the hardware, and non-KMS X still defaults to using
only 32M.
Also use ARRAY_SIZE for the aperture size arrays.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 7d0a93e..eed2195 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -27,6 +27,8 @@
static int uninorth_rev;
static int is_u3;
+#define DEFAULT_APERTURE_SIZE 256
+#define DEFAULT_APERTURE_STRING 256
static char *aperture = NULL;
static int uninorth_fetch_size(void)
@@ -55,7 +57,7 @@ static int uninorth_fetch_size(void)
if (!size) {
for (i = 0; i agp_bridge-driver-num_aperture_sizes; i++)
- if (values[i].size == 32)
+ if (values[i].size == DEFAULT_APERTURE_SIZE)
break;
}
@@ -489,13 +491,11 @@ void null_cache_flush(void)
/* Setup function */
-static const struct aper_size_info_32 uninorth_sizes[7] =
+static const struct aper_size_info_32 uninorth_sizes[] =
{
-#if 0 /* Not sure uninorth supports that high aperture sizes */
{256, 65536, 6, 64},
{128, 32768, 5, 32},
{64, 16384, 4, 16},
-#endif
{32, 8192, 3, 8},
{16, 4096, 2, 4},
{8, 2048, 1, 2},
@@ -506,7 +506,7 @@ static const struct aper_size_info_32 uninorth_sizes[7] =
* Not sure that u3 supports that high aperture sizes but it
* would strange if it did not :)
*/
-static const struct aper_size_info_32 u3_sizes[8] =
+static const struct aper_size_info_32 u3_sizes[] =
{
{512, 131072, 7, 128},
{256, 65536, 6, 64},
@@ -522,7 +522,7 @@ const struct agp_bridge_driver uninorth_agp_driver = {
.owner = THIS_MODULE,
.aperture_sizes = (void *)uninorth_sizes,
.size_type = U32_APER_SIZE,
- .num_aperture_sizes = 4,
+ .num_aperture_sizes = ARRAY_SIZE(uninorth_sizes),
.configure = uninorth_configure,
.fetch_size = uninorth_fetch_size,
.cleanup= uninorth_cleanup,
@@ -549,7 +549,7 @@ const struct agp_bridge_driver u3_agp_driver = {
.owner = THIS_MODULE,
.aperture_sizes = (void *)u3_sizes,
.size_type = U32_APER_SIZE,
- .num_aperture_sizes = 8,
+ .num_aperture_sizes = ARRAY_SIZE(u3_sizes),
.configure = uninorth_configure,
.fetch_size = uninorth_fetch_size,
.cleanup= uninorth_cleanup,
@@ -732,7 +732,7 @@ module_param(aperture, charp, 0);
MODULE_PARM_DESC(aperture,
Aperture size, must be power of two between 4MB and an\n
\t\tupper limit specific to the UniNorth revision.\n
-\t\tDefault: 32M);
+\t\tDefault: DEFAULT_APERTURE_STRING M);
MODULE_AUTHOR(Ben Herrenschmidt Paul Mackerras);
MODULE_LICENSE(GPL);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
kexec on e300 core / mpc5121
I've tried kexec on e300 core which should be easy since it is possible to disable the MMU on that core. However it does not work. Once I disable the MMU, I can't access my MBAR and print chars on the serial port. Is this normal or do I have still some caches on? After I've setup two BATs one for SDRAM and the other for MBAR and enabled the MMU again, I could trace it and see that it jumped into the new kernel. I got lost after the turn off mmu part. So the new kernel does not boot but it gets there. I noticed that if I boot from u-boot, my I Dcache are switched off and in kexec mode there are on. So I tried to disable them in my kernel wrapper with the following sequence which I borrowed from u-boot: |icache_disable: |mfspr r3, HID0 |lis r4, 0 |ori r4, r4, HID0_ICE|HID0_ILOCK |andcr3, r3, r4 |ori r4, r3, HID0_ICFI |isync |mtspr HID0, r4 /* sets invalidate, clears enable and lock*/ |isync |mtspr HID0, r3/* clears invalidate */ |blr |dcache_disable: |mfspr r3, HID0 |lis r4, 0 |ori r4, r4, HID0_DCE|HID0_DLOCK |andcr3, r3, r4 |ori r4, r3, HID0_DCI |sync |mtspr HID0, r4/* sets invalidate, clears enable and lock */ |sync |mtspr HID0, r3/* clears invalidate */ |blr First icache, followed by dcache. This has the side effect that my LR which was saved on stack suddenly become 0x0 in the function where I disable the caches. So it looks like the sequence above is not correct and it is probably a cache thing why the kernel does not boot. So I tried not to enable I Dcache in first place. The kernel booted uncached and then I tried to kexec into my kernel. This did not succeed, I saw my last char printed in kernel code but nothing more. So it looks like the same result like the cached attempt. The HID0 register differs only in powermanagement, MSR differs in IR,DR and PR. Is there another register which could be different? There should be one, since I can't write anything on my serial line unless I setup BATs and enable data address translation. Does someone have an idea? Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/7] Device table matching for SPI subsystem
On Wednesday 29 July 2009, Anton Vorontsov wrote: platform_data is overkill for m25p80 chips, the driver only needs to know exact chip model, and that's what device tables are for. To be fair, the platform_data also supports partitioning and labeling e.g. for cmdlinepart ... though I'd tend to agree that most SPI flash chips are kind of small (so they're mostly just one smallish partition). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] spi: Add support for device table matching
On Wednesday 29 July 2009, Ben Dooks wrote:
struct spi_driver {
+ const struct spi_device_id *id_table;
+ int (*probe_id)(struct spi_device *spi,
+ const struct spi_device_id *id);
how about leaving it at just probe and have either a call or a field
in the device that you can look at to see if this was a new style of
call?
int (*probe)(struct spi_device *spi);
For the record, if this is going to happen I think the
appropriate long-term solution is to have probe() take
the device_id just as it does with other busses.
Of course that involves changing *every* SPI driver...
and I'd rather not do that quite yet.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
On Thursday 30 July 2009, Anton Vorontsov wrote:
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as m25p80).
I suspect detect is a misnomer there. It only detects JEDEC chips.
All others got explicit declarations ... so if there's misbehavior for
other chips, it's because those declarations were poorly handled. Maybe
they were not properly flagged as non-JDEC
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
I'd rather keep the warning, so there's a clue about what's really
going on: JEDEC chip found, but its ID is not handled.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/mtd/devices/m25p80.c | 146
+++---
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
... deletia ...
@@ -481,74 +480,83 @@ struct flash_info {
#define SECT_4K 0x01/* OPCODE_BE_4K works uniformly
*/
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)(struct flash_info) { \
+ .jedec_id = (_jedec_id),\
+ .ext_id = (_ext_id),\
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
Anonymous inlined structures ... kind of ugly, but I can
understand why you might not want to declare and name a
few dozen single-use structures.
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as DataFlash */
- { at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { at25fs010, INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { at25fs040, INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
... deletia ...
@@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct
spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id;
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi-dev.platform_data;
if (data data-type) {
At this point I wonder why you're not changing the probe sequence
more. Get id and then id here. If it's for m25p80 assume
it's an old-style board init and do the current logic. Else just
verify info.
There's a new error case of course: new-style but data-type
doesn't match id-name.
- for (i = 0, info = m25p_data;
- i ARRAY_SIZE(m25p_data);
- i++, info++) {
- if (strcmp(data-type, info-name) == 0)
- break;
+ for (i = 0; i ARRAY_SIZE(m25p_ids) - 1; i++) {
+ id = m25p_ids[i];
+ info = (void *)m25p_ids[i].driver_data;
+ if (strcmp(data-type, id-name))
+ continue;
+ break;
}
/* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_data)) {
+ if (i == ARRAY_SIZE(m25p_ids) - 1) {
Better: if (info == NULL) ... You've got all the pointers
in hand; don't use indices.
DEBUG(MTD_DEBUG_LEVEL0, %s: unrecognized id %s\n,
dev_name(spi-dev), data-type);
info = NULL;
/* recognized; is that chip really what's there? */
} else if (info-jedec_id) {
- struct flash_info *chip = jedec_probe(spi);
+ id = jedec_probe(spi);
- if (!chip || chip != info) {
+ if (id != m25p_ids[i]) {
Again, don't use indices except during the lookup.
Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
On Mon, 03 Aug 2009 09:13:37 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2009-08-02 at 10:52 +0200, Stef Simoens wrote: Hey Benjamin, Thanks for the bisection. I'll have a look when I'm back from skiing :-) In the meantime, maybe Fujita has an idea ? The commit just removes the unused functions. So I'm not sure how this patch could cause any regression. Looks like that READ CAPACITY fails. We use kmalloc'ed buffer for READ CAPACITY so I'm not sure about an alignment issue that you mentioned in this thread earlier. You said your machine with a MESH appears to work. Did you confirm it? Mesh is an old crappy piece of HW with an old driver full of dark secrets that Paulus wrote eons ago, so I'd rather avoid cracking it open :-) Cheers, Ben. Benjamin Herrenschmidt schreef: On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote: What would be the best approach? - if the kernel boots, it's obviously 'good' - but what if the kernel hits the 'BUG', should I apply your patch then? If it doesn't work with your patch, would it be 'bad' then? A few reboots later... As you said, during my bisecting, at a certain moment I needed your patch (I booted, got a problem, patched the tree with your patch, rebooted, it worked). Then, git says: f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit commit f078727b250c2653fc9a564f15547c17ebac3f99 Author: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Date: Sun Dec 14 01:23:45 2008 +0900 [SCSI] remove scsi_req_map_sg No one uses scsi_execute_async with data transfer now. We can remove scsi_req_map_sg. Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door doesn't handle sense and the callback. So we can remove scsi_io_context too. Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Signed-off-by: James Bottomley james.bottom...@hansenpartnership.com :04 04 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44 3ffca800399e52ef12f1001721c0c7ff431efafd Mdrivers :04 04 805c02c4ad3c63c45dffa18f413e92bfca99caf6 6fb58bb5fb19c4198fa7d626d6241086655c6307 Minclude At this moment, the reason for the crash is different then in v2.6.30 I noted the following (I hope to have written the most important stuff). driver 'sd' needs update mesh: lost arbitration sd 0:0:0:0 sda read CAPACITY failed sd ... sd 0:0:0:0 sdb read CAPACITY failed sd ... mice sd ... mice: PS/2 ... TCP cubic ... Initializing XFRM ... NET ... protcol 17 XFS ... VFS : unable to mount root FS If you want more input ... please let me know. -- Kr, Stef Simoens plain text document attachment (git-bisect-log) git bisect start # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29 git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1 git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555 # bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410. git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62 # good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/ git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6 # good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2 git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22 # bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30 git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30 # good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917 # good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a # bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response git bisect bad 21283916322f579a580e413652cdefbfa3ec676f # good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f # bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e # bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6 # bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
On Wed, 2009-08-05 at 10:04 +0900, FUJITA Tomonori wrote: Looks like that READ CAPACITY fails. We use kmalloc'ed buffer for READ CAPACITY so I'm not sure about an alignment issue that you mentioned in this thread earlier. You said your machine with a MESH appears to work. Did you confirm it? Not yet. It's a fishy machine that needs other patches to get back to working condition, I haven't had time yet (everybody's sick at home so I've been mostly off the office and the machine is there). I'm pretty sure the MESH will have issues though if the DMA buffers aren't at least 16 (or maybe it's 32) bytes aligned. I don't think it's a cache alignment issue, I suspect it's an issue with the DBDMA engine queue on those chips though (it -could- be cache coherency bugs too, never know with those old Apple home made chipsets). I remember we had problems in the past with IDENTIFY iirc, which would work normally as kmalloc() would return something cache line aligned... until one enabled SLAB debugging. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
On Tue, Aug 04, 2009 at 02:23:16AM +0530, K.Prasad wrote: On Fri, Jul 31, 2009 at 04:10:13PM +1000, David Gibson wrote: On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote: edited Reasons - Signal delivery before execution of instruction requires complex workarounds - One of the plausible workarounds is a two-pass hw-breakpoint handler which delivers the signal after the first pass (with the breakpoints enabled). In the second pass, it follows the existing semantics of disable_hbp--enable_ss--single_step--disable_ss--enable_hbp. Yes, that's the only way I can see to do it. - Possibility of nested exceptions is a problem here. Ok, why? Reason as described in the para below. - Proper identification of a second-pass of first exception and a new nested exception is difficult. Possibility of stray exceptions due to accesses in neighbouring memory regions of the breakpoint address further complicates it. To elaborate, consider a case where a user-space address 'x' is monitored for read or write, and the following happens (assume the existence of the two-pass method for signal delivery). - Instruction 'i' attempts to read/write in address 'x' - hw-bkpt exception generated (pass I) - Signal generated and hw-bkpt exception returns to user-space - Signal is handled before 'i' is executed. Handler code reads/writes data in 'x' again. Generates nested exception. - hw-breakpoint handler code is unable to distinguish if the new exception is from signal handler (nested) or due to second-pass (as per design above). Ah, ok, I understand now. Hrm. I'll have to think about this. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
On Tue, Aug 04, 2009 at 02:29:38AM +0530, K.Prasad wrote: On Fri, Jul 31, 2009 at 04:16:46PM +1000, David Gibson wrote: On Mon, Jul 27, 2009 at 05:43:17AM +0530, K.Prasad wrote: [snip] + /* Verify if dar lies within the address range occupied by the symbol + * being watched. Since we cannot get the symbol size for + * user-space requests we skip this check in that case + */ + if (is_kernel + !((bp-info.address = dar) + (dar = (bp-info.address + bp-info.symbolsize + /* + * This exception is triggered not because of a memory access on + * the monitored variable but in the double-word address range + * in which it is contained. We will consume this exception, + * considering it as 'noise'. + */ + goto out; + + (bp-triggered)(bp, regs); It bothers me that the trigger function is executed before the trapping instruction, but the SIGTRAP occurs afterwards. Since they're both responses to the trap, it seems logical to me that they should occur at the same time (from the trapping program's point of view, at least). How about moving the triggered function to the single-step handler code for both kernel- and user-space? That would make it behave like a trigger-after-execute (and synchronised with the signal-delivery timing). I think that would be an improvement, yes. I definitely think the SIGTRAP and the callback function should happen at the same time in all cases. Possibly even have the callback function issue the SIGTRAP rather than special casing that. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Fix switch_mmu_context to iterate of the proper list of cpus
Introduced a temporary variable into our iterating over the list cpus
that are threads on the same core. For some reason Ben forgot how for
loops work.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/mm/mmu_context_nohash.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c
b/arch/powerpc/mm/mmu_context_nohash.c
index 6e8d2d9..9859dcd 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -190,7 +190,7 @@ static void context_check_map(void) { }
void switch_mmu_context(struct mm_struct *prev, struct mm_struct *next)
{
- unsigned int id, cpu = smp_processor_id();
+ unsigned int i, id, cpu = smp_processor_id();
unsigned long *map;
/* No lockless fast path .. yet */
@@ -268,9 +268,10 @@ void switch_mmu_context(struct mm_struct *prev, struct
mm_struct *next)
local_flush_tlb_mm(next);
/* XXX This clear should ultimately be part of
local_flush_tlb_mm */
- for (cpu = cpu_first_thread_in_core(cpu);
-cpu = cpu_last_thread_in_core(cpu); cpu++)
- __clear_bit(id, stale_map[cpu]);
+ for (i = cpu_first_thread_in_core(cpu);
+i = cpu_last_thread_in_core(cpu); i++) {
+ __clear_bit(id, stale_map[i]);
+ }
}
/* Flick the MMU and release lock */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
On Mon, Aug 3, 2009 at 12:46 PM, Albrecht Dreßalbrecht.dr...@arcor.de wrote: Am 03.08.09 19:50 schrieb(en) Grant Likely: Just about all mpc5200 device trees have the fsl,has-wdt property on GPT0 even when it isn't used as a watchdog. Sorry, I do not understand... The file Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says snip On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board design supports the internal wdt, then the device node for GPT0 should include the empty property 'fsl,has-wdt'. /snip I interpreted this as if you don't want to have the wdt function of gpt0, remove this property. If this assumption is wrong, how is the kernel supposed to decide if a device shall be used as gpt or as wdt? That just states whether or not the functionality is there. In fact, the device can be used as both a WDT and a GPIO pin at the same time. The kernel should decide how to use it based on what userspace asks it to do. If the WDT interface is opened, then it should be used as a WDT. If the GPIO interface is opened, then it should be used as a GPIO (and not disturb the WDT settings). If the gpt timer API is called (not yet merged), then it should be used as a timer; but only if it hasn't already been set up as a WDT. The boards using GPT0 as a GPIO or timer will be broken by this patch. A wdt is a security device which will (IMHO) either not be used as such, or it is a *must not* be used for something else on a particular board (you may even want u-boot to activate it, e.g. to detect a hanging boot process). In both cases, a tuned device tree is needed. There is no property in the current binding that provides that data to the kernel. It works for it to be implicit based on how userspace accesses the device, but if you want added assurance to ensure that nothing else can use the WDT then you can define a new property to state that explicitly and inhibit other uses. That way no older boards remain broken regardless of how they currently use GPT0 In fact, it probably makes sense to have a property to describe a timeout value to preload into the WDT at boot time, or respect a watchdog value already initialized by firmware (so that even if userspace fails to start the watchdog daemon, the system will still get reset). I know it is a lot more work, but the correct solution is to merge the GPT watchdog driver into the regular GPT driver so that we don't have two device drivers trying to bind against the same device. I see the benefit of removing some duplicate code and of having gpio access in parallel with the wdt, but it wouldn't solve the general confusion above! Will look into that, though... I took a look at the code this evening, and it actually shouldn't be too difficult to rework. Most of the work would be relocating the functions in the wdt driver into the gpt driver and wiring it into the GPT probe/remove functions. 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
[PATCH -v2 2/7] powerpc: remove swiotlb_pci_dma_ops
Now swiotlb_pci_dma_ops is identical to swiotlb_dma_ops; we can use
swiotlb_dma_ops with any devices. This removes swiotlb_pci_dma_ops.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/swiotlb.h |1 -
arch/powerpc/kernel/dma-swiotlb.c | 14 --
arch/powerpc/platforms/85xx/mpc8536_ds.c |2 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c |2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 +-
6 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/swiotlb.h
b/arch/powerpc/include/asm/swiotlb.h
index 31e0e43..21ce0a3 100644
--- a/arch/powerpc/include/asm/swiotlb.h
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -14,7 +14,6 @@
#include linux/swiotlb.h
extern struct dma_mapping_ops swiotlb_dma_ops;
-extern struct dma_mapping_ops swiotlb_pci_dma_ops;
static inline void dma_mark_clean(void *addr, size_t size) {}
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/powerpc/kernel/dma-swiotlb.c
index c9f6a30..ca141e1 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -45,20 +45,6 @@ struct dma_mapping_ops swiotlb_dma_ops = {
.sync_sg_for_device = swiotlb_sync_sg_for_device
};
-struct dma_mapping_ops swiotlb_pci_dma_ops = {
- .alloc_coherent = dma_direct_alloc_coherent,
- .free_coherent = dma_direct_free_coherent,
- .map_sg = swiotlb_map_sg_attrs,
- .unmap_sg = swiotlb_unmap_sg_attrs,
- .dma_supported = swiotlb_dma_supported,
- .map_page = swiotlb_map_page,
- .unmap_page = swiotlb_unmap_page,
- .sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
- .sync_single_range_for_device = swiotlb_sync_single_range_for_device,
- .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
- .sync_sg_for_device = swiotlb_sync_sg_for_device
-};
-
void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
{
struct pci_controller *hose;
diff --git a/arch/powerpc/platforms/85xx/mpc8536_ds.c
b/arch/powerpc/platforms/85xx/mpc8536_ds.c
index bf052c0..004b7d3 100644
--- a/arch/powerpc/platforms/85xx/mpc8536_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc8536_ds.c
@@ -96,7 +96,7 @@ static void __init mpc8536_ds_setup_arch(void)
#ifdef CONFIG_SWIOTLB
if (lmb_end_of_DRAM() max) {
ppc_swiotlb_enable = 1;
- set_pci_dma_ops(swiotlb_pci_dma_ops);
+ set_pci_dma_ops(swiotlb_dma_ops);
ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
}
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index c6f92cc..544011a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -192,7 +192,7 @@ static void __init mpc85xx_ds_setup_arch(void)
#ifdef CONFIG_SWIOTLB
if (lmb_end_of_DRAM() max) {
ppc_swiotlb_enable = 1;
- set_pci_dma_ops(swiotlb_pci_dma_ops);
+ set_pci_dma_ops(swiotlb_dma_ops);
ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
}
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e1f82f8..5ea1b68 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -254,7 +254,7 @@ static void __init mpc85xx_mds_setup_arch(void)
#ifdef CONFIG_SWIOTLB
if (lmb_end_of_DRAM() max) {
ppc_swiotlb_enable = 1;
- set_pci_dma_ops(swiotlb_pci_dma_ops);
+ set_pci_dma_ops(swiotlb_dma_ops);
ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
}
#endif
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 8032301..2aa69a6 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -105,7 +105,7 @@ mpc86xx_hpcn_setup_arch(void)
#ifdef CONFIG_SWIOTLB
if (lmb_end_of_DRAM() max) {
ppc_swiotlb_enable = 1;
- set_pci_dma_ops(swiotlb_pci_dma_ops);
+ set_pci_dma_ops(swiotlb_dma_ops);
ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
}
#endif
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -v2 0/7] powerpc: use asm-generic/dma-mapping-common.h
This is the second version of the patchset to convert POWERPC to use asm-generic/dma-mapping-common.h: http://marc.info/?l=linux-kernelm=124840628128189w=2 There are some minor changes since the first version are: - removed unused CONFIG_PPC_NEED_DMA_SYNC_OPS [5/7] (Becky pointed out). - added Becky's Acked-by - added two new patches ([6/7] and [7/7]). [6/7] fixes SWIOTLB's dma_mapping_error(). [7/7] addes CONFIG_DMA_API_DEBUG support. This is on the top of my swiotlb cleanup patchset: http://marc.info/?l=linuxppc-embeddedm=124718920320951w=2 The above swiotlb patchset was merged in -tip so I think that merging this patchset via -tip too is the easiest way to handle this patchset. The patchset also is available via a git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git powerpc = arch/powerpc/Kconfig |7 +- arch/powerpc/include/asm/device.h |7 +- arch/powerpc/include/asm/dma-mapping.h | 318 +++- arch/powerpc/include/asm/pci.h |4 +- arch/powerpc/include/asm/swiotlb.h |8 +- arch/powerpc/kernel/dma-iommu.c|2 +- arch/powerpc/kernel/dma-swiotlb.c | 53 ++--- arch/powerpc/kernel/dma.c | 13 +- arch/powerpc/kernel/ibmebus.c |2 +- arch/powerpc/kernel/pci-common.c |6 +- arch/powerpc/kernel/vio.c |2 +- arch/powerpc/platforms/85xx/mpc8536_ds.c |3 +- arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 +- arch/powerpc/platforms/85xx/mpc85xx_mds.c |3 +- arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |3 +- arch/powerpc/platforms/cell/iommu.c|2 +- arch/powerpc/platforms/ps3/system-bus.c|4 +- include/linux/dma-mapping.h|1 + 18 files changed, 89 insertions(+), 352 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -v2 5/7] powerpc: use asm-generic/dma-mapping-common.h
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/Kconfig |6 +-
arch/powerpc/include/asm/dma-mapping.h | 242 +---
2 files changed, 7 insertions(+), 241 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d00131c..fb3f4ff 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -120,7 +120,7 @@ config PPC
select HAVE_KRETPROBES
select HAVE_ARCH_TRACEHOOK
select HAVE_LMB
- select HAVE_DMA_ATTRS if PPC64
+ select HAVE_DMA_ATTRS
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
@@ -307,10 +307,6 @@ config SWIOTLB
platforms where the size of a physical address is larger
than the bus address. Not all platforms support this.
-config PPC_NEED_DMA_SYNC_OPS
- def_bool y
- depends on (NOT_COHERENT_CACHE || SWIOTLB)
-
config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
depends on SMP HOTPLUG EXPERIMENTAL (PPC_PSERIES || PPC_PMAC)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 8ca2b51..91217e4 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -14,6 +14,7 @@
#include linux/mm.h
#include linux/scatterlist.h
#include linux/dma-attrs.h
+#include linux/dma-debug.h
#include asm/io.h
#include asm/swiotlb.h
@@ -89,6 +90,11 @@ static inline void set_dma_ops(struct device *dev, struct
dma_map_ops *ops)
dev-archdata.dma_ops = ops;
}
+/* this will be removed soon */
+#define flush_write_buffers()
+
+#include asm-generic/dma-mapping-common.h
+
static inline int dma_supported(struct device *dev, u64 mask)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
@@ -117,87 +123,6 @@ static inline int dma_set_mask(struct device *dev, u64
dma_mask)
return 0;
}
-/*
- * map_/unmap_single actually call through to map/unmap_page now that all the
- * dma_map_ops have been converted over. We just have to get the page and
- * offset to pass through to map_page
- */
-static inline dma_addr_t dma_map_single_attrs(struct device *dev,
- void *cpu_addr,
- size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- BUG_ON(!dma_ops);
-
- return dma_ops-map_page(dev, virt_to_page(cpu_addr),
-(unsigned long)cpu_addr % PAGE_SIZE, size,
-direction, attrs);
-}
-
-static inline void dma_unmap_single_attrs(struct device *dev,
- dma_addr_t dma_addr,
- size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- BUG_ON(!dma_ops);
-
- dma_ops-unmap_page(dev, dma_addr, size, direction, attrs);
-}
-
-static inline dma_addr_t dma_map_page_attrs(struct device *dev,
- struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- BUG_ON(!dma_ops);
-
- return dma_ops-map_page(dev, page, offset, size, direction, attrs);
-}
-
-static inline void dma_unmap_page_attrs(struct device *dev,
- dma_addr_t dma_address,
- size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- BUG_ON(!dma_ops);
-
- dma_ops-unmap_page(dev, dma_address, size, direction, attrs);
-}
-
-static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- BUG_ON(!dma_ops);
- return dma_ops-map_sg(dev, sg, nents, direction, attrs);
-}
-
-static inline void dma_unmap_sg_attrs(struct device *dev,
- struct scatterlist *sg,
- int nhwentries,
- enum dma_data_direction direction,
-
[PATCH -v2 3/7] add set_dma_mask hook to struct dma_map_ops
POWERPC needs this hook. SPARC could use it too.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Becky Bruce bec...@kernel.crashing.org
---
include/linux/dma-mapping.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c0f6c3c..91b7618 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -58,6 +58,7 @@ struct dma_map_ops {
enum dma_data_direction dir);
int (*mapping_error)(struct device *dev, dma_addr_t dma_addr);
int (*dma_supported)(struct device *dev, u64 mask);
+ int (*set_dma_mask)(struct device *dev, u64 mask);
int is_phys;
};
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -v2 4/7] powerpc: use dma_map_ops struct
This converts uses dma_map_ops struct (in include/linux/dma-mapping.h)
instead of POWERPC homegrown dma_mapping_ops.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/device.h |4 +-
arch/powerpc/include/asm/dma-mapping.h | 84 ---
arch/powerpc/include/asm/pci.h |4 +-
arch/powerpc/include/asm/swiotlb.h |2 +-
arch/powerpc/kernel/dma-iommu.c |2 +-
arch/powerpc/kernel/dma-swiotlb.c |2 +-
arch/powerpc/kernel/dma.c |2 +-
arch/powerpc/kernel/ibmebus.c |2 +-
arch/powerpc/kernel/pci-common.c|6 +-
arch/powerpc/kernel/vio.c |2 +-
arch/powerpc/platforms/cell/iommu.c |2 +-
arch/powerpc/platforms/ps3/system-bus.c |4 +-
12 files changed, 37 insertions(+), 79 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 0086f8d..67fcd7f 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -6,7 +6,7 @@
#ifndef _ASM_POWERPC_DEVICE_H
#define _ASM_POWERPC_DEVICE_H
-struct dma_mapping_ops;
+struct dma_map_ops;
struct device_node;
struct dev_archdata {
@@ -14,7 +14,7 @@ struct dev_archdata {
struct device_node *of_node;
/* DMA operations on that device */
- struct dma_mapping_ops *dma_ops;
+ struct dma_map_ops *dma_ops;
void*dma_data;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 1765c37..8ca2b51 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -64,56 +64,14 @@ static inline unsigned long device_to_mask(struct device
*dev)
}
/*
- * DMA operations are abstracted for G5 vs. i/pSeries, PCI vs. VIO
- */
-struct dma_mapping_ops {
- void * (*alloc_coherent)(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag);
- void(*free_coherent)(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle);
- int (*map_sg)(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- struct dma_attrs *attrs);
- void(*unmap_sg)(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- struct dma_attrs *attrs);
- int (*dma_supported)(struct device *dev, u64 mask);
- int (*set_dma_mask)(struct device *dev, u64 dma_mask);
- dma_addr_t (*map_page)(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs);
- void(*unmap_page)(struct device *dev,
- dma_addr_t dma_address, size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs);
-#ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
- void(*sync_single_range_for_cpu)(struct device *hwdev,
- dma_addr_t dma_handle, unsigned long offset,
- size_t size,
- enum dma_data_direction direction);
- void(*sync_single_range_for_device)(struct device *hwdev,
- dma_addr_t dma_handle, unsigned long offset,
- size_t size,
- enum dma_data_direction direction);
- void(*sync_sg_for_cpu)(struct device *hwdev,
- struct scatterlist *sg, int nelems,
- enum dma_data_direction direction);
- void(*sync_sg_for_device)(struct device *hwdev,
- struct scatterlist *sg, int nelems,
- enum dma_data_direction direction);
-#endif
-};
-
-/*
* Available generic sets of operations
*/
#ifdef CONFIG_PPC64
-extern struct dma_mapping_ops dma_iommu_ops;
+extern struct dma_map_ops dma_iommu_ops;
#endif
-extern struct dma_mapping_ops dma_direct_ops;
+extern struct dma_map_ops dma_direct_ops;
-static inline struct dma_mapping_ops *get_dma_ops(struct device *dev)
+static inline struct dma_map_ops *get_dma_ops(struct device *dev)
{
/* We don't handle the NULL dev case for ISA for now. We could
* do it via an out of line call but it is not needed for now. The
@@ -126,14 +84,14 @@ static inline struct
[PATCH -v2 6/7] powerpc: handle SWIOTLB mapping error properly
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/powerpc/include/asm/dma-mapping.h |5 +
arch/powerpc/kernel/dma-swiotlb.c |3 ++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 91217e4..4bd41b4 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -143,6 +143,11 @@ static inline void dma_free_coherent(struct device *dev,
size_t size,
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
+ struct dma_map_ops *dma_ops = get_dma_ops(dev);
+
+ if (dma_ops-mapping_error)
+ return dma_ops-mapping_error(dev, dma_addr);
+
#ifdef CONFIG_PPC64
return (dma_addr == DMA_ERROR_CODE);
#else
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/powerpc/kernel/dma-swiotlb.c
index d1143a6..e96cbbd 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -42,7 +42,8 @@ struct dma_map_ops swiotlb_dma_ops = {
.sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
.sync_single_range_for_device = swiotlb_sync_single_range_for_device,
.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
- .sync_sg_for_device = swiotlb_sync_sg_for_device
+ .sync_sg_for_device = swiotlb_sync_sg_for_device,
+ .mapping_error = swiotlb_dma_mapping_error,
};
void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -v2 7/7] powerpc: add CONFIG_DMA_API_DEBUG support
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/powerpc/Kconfig |1 +
arch/powerpc/include/asm/dma-mapping.h | 11 ++-
arch/powerpc/kernel/dma.c | 11 +++
3 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fb3f4ff..4459b78 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -121,6 +121,7 @@ config PPC
select HAVE_ARCH_TRACEHOOK
select HAVE_LMB
select HAVE_DMA_ATTRS
+ select HAVE_DMA_API_DEBUG
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 4bd41b4..cb2ca41 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -127,9 +127,15 @@ static inline void *dma_alloc_coherent(struct device *dev,
size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
+ void *cpu_addr;
BUG_ON(!dma_ops);
- return dma_ops-alloc_coherent(dev, size, dma_handle, flag);
+
+ cpu_addr = dma_ops-alloc_coherent(dev, size, dma_handle, flag);
+
+ debug_dma_alloc_coherent(dev, size, *dma_handle, cpu_addr);
+
+ return cpu_addr;
}
static inline void dma_free_coherent(struct device *dev, size_t size,
@@ -138,6 +144,9 @@ static inline void dma_free_coherent(struct device *dev,
size_t size,
struct dma_map_ops *dma_ops = get_dma_ops(dev);
BUG_ON(!dma_ops);
+
+ debug_dma_free_coherent(dev, size, cpu_addr, dma_handle);
+
dma_ops-free_coherent(dev, size, cpu_addr, dma_handle);
}
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 3e8bb9a..c6d730e 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -7,6 +7,7 @@
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/dma-debug.h
#include asm/bug.h
#include asm/abs_addr.h
@@ -156,3 +157,13 @@ struct dma_map_ops dma_direct_ops = {
#endif
};
EXPORT_SYMBOL(dma_direct_ops);
+
+#define PREALLOC_DMA_DEBUG_ENTRIES (1 16)
+
+static int __init dma_init(void)
+{
+ dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
+
+ return 0;
+}
+fs_initcall(dma_init);
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -v2 1/7] powerpc: remove addr_needs_map in struct dma_mapping_ops
This patch adds max_direct_dma_addr to struct dev_archdata to remove
addr_needs_map in struct dma_mapping_ops. It also converts
dma_capable() to use max_direct_dma_addr.
max_direct_dma_addr is initialized in pci_dma_dev_setup_swiotlb(),
called via ppc_md.pci_dma_dev_setup hook.
For further information:
http://marc.info/?t=12471906021r=1w=2
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Acked-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/device.h |3 ++
arch/powerpc/include/asm/dma-mapping.h |8 +++---
arch/powerpc/include/asm/swiotlb.h |5 +--
arch/powerpc/kernel/dma-swiotlb.c | 36 +++
arch/powerpc/platforms/85xx/mpc8536_ds.c |1 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c |1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |1 +
8 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 7d2277c..0086f8d 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -16,6 +16,9 @@ struct dev_archdata {
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
void*dma_data;
+#ifdef CONFIG_SWIOTLB
+ dma_addr_t max_direct_dma_addr;
+#endif
};
static inline void dev_archdata_set_node(struct dev_archdata *ad,
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 0c34371..1765c37 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -87,8 +87,6 @@ struct dma_mapping_ops {
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
- int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
- size_t size);
#ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
void(*sync_single_range_for_cpu)(struct device *hwdev,
dma_addr_t dma_handle, unsigned long offset,
@@ -426,10 +424,12 @@ static inline int dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
size)
{
- struct dma_mapping_ops *ops = get_dma_ops(dev);
+#ifdef CONFIG_SWIOTLB
+ struct dev_archdata *sd = dev-archdata;
- if (ops-addr_needs_map ops-addr_needs_map(dev, addr, size))
+ if (sd-max_direct_dma_addr addr + size sd-max_direct_dma_addr)
return 0;
+#endif
if (!dev-dma_mask)
return 0;
diff --git a/arch/powerpc/include/asm/swiotlb.h
b/arch/powerpc/include/asm/swiotlb.h
index 30891d6..31e0e43 100644
--- a/arch/powerpc/include/asm/swiotlb.h
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -16,12 +16,11 @@
extern struct dma_mapping_ops swiotlb_dma_ops;
extern struct dma_mapping_ops swiotlb_pci_dma_ops;
-int swiotlb_arch_address_needs_mapping(struct device *, dma_addr_t,
- size_t size);
-
static inline void dma_mark_clean(void *addr, size_t size) {}
extern unsigned int ppc_swiotlb_enable;
int __init swiotlb_setup_bus_notifier(void);
+extern void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev);
+
#endif /* __ASM_SWIOTLB_H */
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/powerpc/kernel/dma-swiotlb.c
index e8a57de..c9f6a30 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -25,26 +25,6 @@ int swiotlb __read_mostly;
unsigned int ppc_swiotlb_enable;
/*
- * Determine if an address is reachable by a pci device, or if we must bounce.
- */
-static int
-swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
-{
- dma_addr_t max;
- struct pci_controller *hose;
- struct pci_dev *pdev = to_pci_dev(hwdev);
-
- hose = pci_bus_to_host(pdev-bus);
- max = hose-dma_window_base_cur + hose-dma_window_size;
-
- /* check that we're within mapped pci window space */
- if ((addr + size max) | (addr hose-dma_window_base_cur))
- return 1;
-
- return 0;
-}
-
-/*
* At the moment, all platforms that use this code only require
* swiotlb to be used if we're operating on HIGHMEM. Since
* we don't ever call anything other than map_sg, unmap_sg,
@@ -73,22 +53,36 @@ struct dma_mapping_ops swiotlb_pci_dma_ops = {
.dma_supported = swiotlb_dma_supported,
.map_page = swiotlb_map_page,
.unmap_page = swiotlb_unmap_page,
- .addr_needs_map = swiotlb_pci_addr_needs_map,
.sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
.sync_single_range_for_device = swiotlb_sync_single_range_for_device,
.sync_sg_for_cpu =
