[PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
Hello,
This patch extends DMA ranges for PCI(X) to 4GB, so that it could
work on Katmais with 4GB RAM installed.
Add new nodes for the PPC440SPe DMA, XOR engines to
be used in the PPC440SPe ADMA driver, and the SysACE
controller, which connects Compact Flash to Katmai.
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/katmai.dts | 46 +++--
1 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 077819b..7749478 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -245,8 +245,8 @@
ranges = 0x0200 0x 0x8000 0x000d
0x8000 0x 0x8000
0x0100 0x 0x 0x000c
0x0800 0x 0x0001;
- /* Inbound 2GB range starting at 0 */
- dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0
0x8000;
+ /* Inbound 4GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x1
0x;
/* This drives busses 0 to 0xf */
bus-range = 0x0 0xf;
@@ -289,8 +289,8 @@
ranges = 0x0200 0x 0x8000 0x000e
0x 0x 0x8000
0x0100 0x 0x 0x000f
0x8000 0x 0x0001;
- /* Inbound 2GB range starting at 0 */
- dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0
0x8000;
+ /* Inbound 4GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x1
0x;
/* This drives busses 10 to 0x1f */
bus-range = 0x10 0x1f;
@@ -330,8 +330,8 @@
ranges = 0x0200 0x 0x8000 0x000e
0x8000 0x 0x8000
0x0100 0x 0x 0x000f
0x8001 0x 0x0001;
- /* Inbound 2GB range starting at 0 */
- dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0
0x8000;
+ /* Inbound 4GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x1
0x;
/* This drives busses 10 to 0x1f */
bus-range = 0x20 0x2f;
@@ -371,8 +371,8 @@
ranges = 0x0200 0x 0x8000 0x000f
0x 0x 0x8000
0x0100 0x 0x 0x000f
0x8002 0x 0x0001;
- /* Inbound 2GB range starting at 0 */
- dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0
0x8000;
+ /* Inbound 4GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x1
0x;
/* This drives busses 10 to 0x1f */
bus-range = 0x30 0x3f;
@@ -392,6 +392,36 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D
*/;
};
+ DMA0: dma0 {
+ interrupt-parent = DMA0;
+ interrupts = 0 1;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map =
+ 0 UIC0 0x14 4
+ 1 UIC1 0x16 4;
+ };
+ DMA1: dma1 {
+ interrupt-parent = DMA1;
+ interrupts = 0 1;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map =
+ 0 UIC0 0x16 4
+ 1 UIC1 0x16 4;
+ };
+ xor {
+ interrupt-parent = UIC1;
+ interrupts = 0x1f 4;
+ };
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
+ interrupt-parent = UIC2;
+ interrupts = 0x19 4;
+ reg = 0x0004 0xfe00 0x100;
+ };
};
chosen {
--
1.5.6.1
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
On Thu, 2008-11-13 at 11:49 +0300, Yuri Tikhonov wrote: Hello, This patch extends DMA ranges for PCI(X) to 4GB, so that it could work on Katmais with 4GB RAM installed. And where do you put MMIO ? The 32 bit part of the PCI space need to be split between MMIO and DMA. Ideally, for 64-bit capable DMA, device, we should create a second DMA range mapping the whole memory at something like 1T or so on PCI, and keep a smaller (ie. 2G) DMA range for 32-bit only devices backed with swiotlb. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] Use of_find_node_with_property() in pmac_setup_arch()
On Thu, 2008-11-13 at 15:20 +1100, Michael Ellerman wrote:
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
---
arch/powerpc/platforms/powermac/setup.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 82c14d2..1293772 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -310,9 +310,7 @@ static void __init pmac_setup_arch(void)
}
/* See if newworld or oldworld */
- for (ic = NULL; (ic = of_find_all_nodes(ic)) != NULL; )
- if (of_get_property(ic, interrupt-controller, NULL))
- break;
+ ic = of_find_node_with_property(NULL, interrupt-controller);
if (ic) {
pmac_newworld = 1;
of_node_put(ic);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
On Thu, 13 Nov 2008 11:49:14 +0300
Yuri Tikhonov [EMAIL PROTECTED] wrote:
Hello,
This patch extends DMA ranges for PCI(X) to 4GB, so that it could
work on Katmais with 4GB RAM installed.
Add new nodes for the PPC440SPe DMA, XOR engines to
be used in the PPC440SPe ADMA driver, and the SysACE
controller, which connects Compact Flash to Katmai.
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
---
+ DMA0: dma0 {
+ interrupt-parent = DMA0;
+ interrupts = 0 1;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map =
+ 0 UIC0 0x14 4
+ 1 UIC1 0x16 4;
+ };
+ DMA1: dma1 {
+ interrupt-parent = DMA1;
+ interrupts = 0 1;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map =
+ 0 UIC0 0x16 4
+ 1 UIC1 0x16 4;
+ };
+ xor {
+ interrupt-parent = UIC1;
+ interrupts = 0x1f 4;
+ };
You have no compatible property in these 3 nodes. How are drivers
supposed to bind to them?
You also have no reg or dcr-reg properties. What exactly are these
nodes for?
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
Odd. This isn't a xilinx board by any means. This should probably
look something like:
compatible = amcc,sysace-440spe, xlnx,opb-sysace-1.00.b;
Though I'm curious about it in general. The xilinx bindings have the
versioning numbers on them to match particular bit-streams in the FPGAs
if I remember correctly. Does that really apply here?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] usb/fsl_qe_udc: Report disconnect before unbinding
Gadgets disable endpoints in their disconnect callbacks, so we must call disconnect before unbinding. This also fixes muram memory leak, since we free muram in the qe_ep_disable(). But mainly the patch fixes following badness: [EMAIL PROTECTED]:~# insmod fsl_qe_udc.ko fsl_qe_udc: Freescale QE/CPM USB Device Controller driver, 1.0 fsl_qe_udc e01006c0.usb: QE USB controller initialized as device [EMAIL PROTECTED]:~# insmod g_ether.ko g_ether gadget: using random self ethernet address g_ether gadget: using random host ethernet address usb0: MAC be:2d:3c:fa:be:f0 usb0: HOST MAC 62:b8:6a:df:38:66 g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 g_ether gadget: g_ether ready fsl_qe_udc e01006c0.usb: fsl_qe_udc bind to driver g_ether g_ether gadget: high speed config #1: CDC Ethernet (ECM) [EMAIL PROTECTED]:~# rmmod g_ether.ko [ cut here ] Badness at drivers/usb/gadget/composite.c:871 [...] NIP [d10c1374] composite_unbind+0x24/0x15c [g_ether] LR [d10a82f4] usb_gadget_unregister_driver+0x128/0x168 [fsl_qe_udc] Call Trace: [cfb93e80] [cfb1f3a0] 0xcfb1f3a0 (unreliable) [cfb93eb0] [d10a82f4] usb_gadget_unregister_driver+0x128/0x168 [fsl_qe_udc] [cfb93ed0] [d10c2a3c] usb_composite_unregister+0x3c/0x4c [g_ether] [cfb93ee0] [c006bde0] sys_delete_module+0x130/0x19c [cfb93f40] [c00142d8] ret_from_syscall+0x0/0x38 [...] fsl_qe_udc e01006c0.usb: unregistered gadget driver 'g_ether' Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- v2: - Comment update per Alan Stern review. replaces usb.current/usb-fsl_qe_udc-report-disconnect-before-unbinding-fixing-oopses.patch drivers/usb/gadget/fsl_qe_udc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c index 37c8575..3d6c956 100644 --- a/drivers/usb/gadget/fsl_qe_udc.c +++ b/drivers/usb/gadget/fsl_qe_udc.c @@ -2382,6 +2382,9 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver) nuke(loop_ep, -ESHUTDOWN); spin_unlock_irqrestore(udc_controller-lock, flags); + /* report disconnect; the controller is already quiesced */ + driver-disconnect(udc_controller-gadget); + /* unbind gadget and unhook driver. */ driver-unbind(udc_controller-gadget); udc_controller-gadget.dev.driver = NULL; -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] usb/fsl_usb2_udc: Report disconnect before unbinding
Gadgets disable endpoints in their disconnect callbacks, so we must call disconnect before unbinding. The patch fixes following badness: [EMAIL PROTECTED]:~# insmod fsl_usb2_udc.ko Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007) [EMAIL PROTECTED]:~# insmod g_ether.ko g_ether gadget: using random self ethernet address g_ether gadget: using random host ethernet address usb0: MAC 26:07:ba:c0:44:33 usb0: HOST MAC 96:81:0c:05:4d:e3 g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 g_ether gadget: g_ether ready fsl-usb2-udc: bind to driver g_ether g_ether gadget: high speed config #1: CDC Ethernet (ECM) [EMAIL PROTECTED]:~# rmmod g_ether.ko [ cut here ] Badness at drivers/usb/gadget/composite.c:871 [...] NIP [e10c3454] composite_unbind+0x24/0x15c [g_ether] LR [e10aa454] usb_gadget_unregister_driver+0x13c/0x164 [fsl_usb2_udc] Call Trace: [df145e80] [ff94] 0xff94 (unreliable) [df145eb0] [e10aa454] usb_gadget_unregister_driver+0x13c/0x164 [fsl_usb2_udc] [df145ed0] [e10c4c40] usb_composite_unregister+0x3c/0x4c [g_ether] [df145ee0] [c006bcc0] sys_delete_module+0x130/0x19c [df145f40] [c00142d8] ret_from_syscall+0x0/0x38 [...] unregistered gadget driver 'g_ether' Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- v2: - Comment update per Alan Stern review. drivers/usb/gadget/fsl_usb2_udc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c b/drivers/usb/gadget/fsl_usb2_udc.c index 091bb55..f3c6703 100644 --- a/drivers/usb/gadget/fsl_usb2_udc.c +++ b/drivers/usb/gadget/fsl_usb2_udc.c @@ -1836,6 +1836,9 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver) nuke(loop_ep, -ESHUTDOWN); spin_unlock_irqrestore(udc_controller-lock, flags); + /* report disconnect; the controller is already quiesced */ + driver-disconnect(udc_controller-gadget); + /* unbind gadget and unhook driver. */ driver-unbind(udc_controller-gadget); udc_controller-gadget.dev.driver = NULL; -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/85xx: Don't reset the MPIC for CAMP mode on MPC8572DS
From: Haiying Wang [EMAIL PROTECTED]
The flag MPIC_WANTS_RESET shouldn't be set if reading the new cpu compatible
fsl,MPC8572DS-CAMP returns 1.
Signed-off-by: Haiying Wang [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index a03c839..7326d90 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -63,6 +63,7 @@ void __init mpc85xx_ds_pic_init(void)
struct device_node *cascade_node = NULL;
int cascade_irq;
#endif
+ unsigned long root = of_get_flat_dt_root();
np = of_find_node_by_type(NULL, open-pic);
if (np == NULL) {
@@ -76,11 +77,19 @@ void __init mpc85xx_ds_pic_init(void)
return;
}
- mpic = mpic_alloc(np, r.start,
+ if (of_flat_dt_is_compatible(root, fsl,MPC8572DS-CAMP)) {
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ 0, 256, OpenPIC );
+ } else {
+ mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
MPIC_SINGLE_DEST_CPU,
0, 256, OpenPIC );
+ }
+
BUG_ON(mpic == NULL);
of_node_put(np);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: Create dts for each core in CAMP mode for MPC8572DS
From: Haiying Wang [EMAIL PROTECTED]
Signed-off-by: Haiying Wang [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 484
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 233
2 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
new file mode 100644
index 000..427e96e
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
@@ -0,0 +1,484 @@
+/*
+ * MPC8572 DS Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, dma1, global-util, eth0,
+ * eth1, crypto, pci0, pci1.
+ *
+ * Copyright 2007, 2008 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,MPC8572DS;
+ compatible = fsl,MPC8572DS, fsl,MPC8572DS-CAMP;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ serial0 = serial0;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0x0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ next-level-cache = L2;
+ };
+
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x0;// Filled by U-Boot
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
+ ranges = 0x0 0xffe0 0x10;
+ reg = 0xffe0 0x1000; // CCSRBAR soc regs, remove
once parse code for immrbase fixed
+ bus-frequency = 0;// Filled out by uboot.
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8572-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8572-memory-controller;
+ reg = 0x6000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,mpc8572-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8572-dma, fsl,eloplus-dma;
+ reg = 0x21300 0x4;
+ ranges = 0x0 0x21100 0x200;
+ cell-index = 0;
+
[PATCH 03/11] async_tx: add support for asynchronous RAID6 recovery operations
This patch extends async_tx API with two operations for recovery
operations on RAID6 array with two failed disks using new async_pqxor()
operation. New functions:
async_r6_dd_recov() recovers after double data disk failure
async_r6_dp_recov() recovers after D+P failure
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
crypto/async_tx/Kconfig |5 +
crypto/async_tx/Makefile|1 +
crypto/async_tx/async_r6recov.c | 275 +++
include/linux/async_tx.h| 10 ++
4 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 crypto/async_tx/async_r6recov.c
diff --git a/crypto/async_tx/Kconfig b/crypto/async_tx/Kconfig
index b1705d1..31a0aae 100644
--- a/crypto/async_tx/Kconfig
+++ b/crypto/async_tx/Kconfig
@@ -18,3 +18,8 @@ config ASYNC_PQXOR
tristate
select ASYNC_CORE
+config ASYNC_R6RECOV
+ tristate
+ select ASYNC_CORE
+ select ASYNC_PQXOR
+
diff --git a/crypto/async_tx/Makefile b/crypto/async_tx/Makefile
index 32d6ce2..76fcd43 100644
--- a/crypto/async_tx/Makefile
+++ b/crypto/async_tx/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ASYNC_MEMCPY) += async_memcpy.o
obj-$(CONFIG_ASYNC_MEMSET) += async_memset.o
obj-$(CONFIG_ASYNC_XOR) += async_xor.o
obj-$(CONFIG_ASYNC_PQXOR) += async_pqxor.o
+obj-$(CONFIG_ASYNC_R6RECOV) += async_r6recov.o
diff --git a/crypto/async_tx/async_r6recov.c b/crypto/async_tx/async_r6recov.c
new file mode 100644
index 000..4c6b100
--- /dev/null
+++ b/crypto/async_tx/async_r6recov.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright(c) 2007 Yuri Tikhonov [EMAIL PROTECTED]
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * Asynchronous RAID-6 recovery calculations ASYNC_TX API.
+ *
+ * based on async_xor.c code written by:
+ * Dan Williams [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/raid/xor.h
+#include linux/async_tx.h
+
+#include ../drivers/md/raid6.h
+
+/**
+ * async_r6_dd_recov - attempt to calculate two data misses using dma engines.
+ * @disks: number of disks in the RAID-6 array
+ * @bytes: size of strip
+ * @faila: first failed drive index
+ * @failb: second failed drive index
+ * @ptrs: array of pointers to strips (last two must be p and q, respectively)
+ * @flags: ASYNC_TX_ACK, ASYNC_TX_DEP_ACK
+ * @depend_tx: depends on the result of this transaction.
+ * @cb: function to call when the operation completes
+ * @cb_param: parameter to pass to the callback routine
+ */
+struct dma_async_tx_descriptor *
+async_r6_dd_recov(int disks, size_t bytes, int faila, int failb,
+ struct page **ptrs, enum async_tx_flags flags,
+ struct dma_async_tx_descriptor *depend_tx,
+ dma_async_tx_callback cb, void *cb_param)
+{
+ struct dma_async_tx_descriptor *tx = NULL;
+ struct page *lptrs[disks];
+ unsigned char lcoef[disks - 2];
+ int i = 0, k = 0, fc = -1;
+ uint8_t bc[2];
+ dma_async_tx_callback lcb = NULL;
+ void *lcb_param = NULL;
+
+ /* Assume that failb faila */
+ if (faila failb) {
+ fc = faila;
+ faila = failb;
+ failb = fc;
+ }
+
+ /*
+* Try to compute missed data asynchronously.
+*/
+
+ if (disks == 4) {
+ /* Pxy and Qxy are zero in this case so we already have
+* P+Pxy and Q+Qxy in P and Q strips respectively.
+*/
+ tx = depend_tx;
+ lcb = cb;
+ lcb_param = cb_param;
+ goto do_mult;
+ }
+
+ /* (1) Calculate Qxy and Pxy:
+* Qxy = A(0)*D(0) + ... + A(n-1)*D(n-1) + A(n+1)*D(n+1) + ... +
+*A(m-1)*D(m-1) + A(m+1)*D(m+1) + ... + A(disks-1)*D(disks-1),
+* where n = faila, m = failb.
+*/
+ for (i = 0, k = 0; i disks - 2; i++) {
+ if (i != faila i != failb) {
+ lptrs[k] = ptrs[i];
+ lcoef[k] = raid6_gfexp[i];
+ k++;
+
[PATCH 02/11] async_tx: add support for asynchronous GF multiplication
This adds support for doing asynchronous GF multiplication by adding
four additional functions to async_tx API:
async_pqxor() does simultaneous XOR of sources and XOR of sources
GF-multiplied by given coefficients.
async_pqxor_zero_sum() checks if results of calculations match given
ones.
async_gen_syndrome() does sumultaneous XOR and R/S syndrome of sources.
async_syndrome_zerosum() checks if results of XOR/syndrome calculation
matches given ones.
Latter two functions just use pqxor with approprite coefficients in
asynchronous case but have significant optimizations if synchronous
case.
To support this API dmaengine driver should set DMA_PQ_XOR and
DMA_PQ_ZERO_SUM capabilities and provide device_prep_dma_pqxor and
device_prep_dma_pqzero_sum methods in dma_device structure.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
crypto/async_tx/Kconfig |4 +
crypto/async_tx/Makefile |1 +
crypto/async_tx/async_pqxor.c | 532 +
include/linux/async_tx.h | 31 +++
include/linux/dmaengine.h | 11 +
5 files changed, 579 insertions(+), 0 deletions(-)
create mode 100644 crypto/async_tx/async_pqxor.c
diff --git a/crypto/async_tx/Kconfig b/crypto/async_tx/Kconfig
index d8fb391..b1705d1 100644
--- a/crypto/async_tx/Kconfig
+++ b/crypto/async_tx/Kconfig
@@ -14,3 +14,7 @@ config ASYNC_MEMSET
tristate
select ASYNC_CORE
+config ASYNC_PQXOR
+ tristate
+ select ASYNC_CORE
+
diff --git a/crypto/async_tx/Makefile b/crypto/async_tx/Makefile
index 27baa7d..32d6ce2 100644
--- a/crypto/async_tx/Makefile
+++ b/crypto/async_tx/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_ASYNC_CORE) += async_tx.o
obj-$(CONFIG_ASYNC_MEMCPY) += async_memcpy.o
obj-$(CONFIG_ASYNC_MEMSET) += async_memset.o
obj-$(CONFIG_ASYNC_XOR) += async_xor.o
+obj-$(CONFIG_ASYNC_PQXOR) += async_pqxor.o
diff --git a/crypto/async_tx/async_pqxor.c b/crypto/async_tx/async_pqxor.c
new file mode 100644
index 000..547d72a
--- /dev/null
+++ b/crypto/async_tx/async_pqxor.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright(c) 2007 Yuri Tikhonov [EMAIL PROTECTED]
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * Asynchronous GF-XOR calculations ASYNC_TX API.
+ *
+ * based on async_xor.c code written by:
+ * Dan Williams [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/raid/xor.h
+#include linux/async_tx.h
+
+#include ../drivers/md/raid6.h
+
+/**
+ * The following static variables are used in cases of synchronous
+ * zero sum to save the values to check. Two pages used for zero sum and
+ * the third one is for dumb P destination when calling gen_syndrome()
+ */
+static spinlock_t spare_lock;
+struct page *spare_pages[3];
+
+/**
+ * do_async_pqxor - asynchronously calculate P and/or Q
+ */
+static struct dma_async_tx_descriptor *
+do_async_pqxor(struct dma_chan *chan, struct page *pdest, struct page *qdest,
+ struct page **src_list, unsigned char *scoef_list,
+ unsigned int offset, unsigned int src_cnt, size_t len,
+ enum async_tx_flags flags, struct dma_async_tx_descriptor *depend_tx,
+ dma_async_tx_callback cb_fn, void *cb_param)
+{
+ struct dma_device *dma = chan-device;
+ struct page *dest;
+ dma_addr_t dma_dest[2];
+ dma_addr_t dma_src[src_cnt];
+ unsigned char *scf = qdest ? scoef_list : NULL;
+ struct dma_async_tx_descriptor *tx;
+ int i, dst_cnt = 0;
+ unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
+
+ if (flags ASYNC_TX_XOR_ZERO_DST)
+ dma_prep_flags |= DMA_PREP_ZERO_DST;
+
+ /* One parity (P or Q) calculation is initiated always;
+* first always try Q
+*/
+ dest = qdest ? qdest : pdest;
+ dma_dest[dst_cnt++] = dma_map_page(dma-dev, dest, offset, len,
+ DMA_FROM_DEVICE);
+
+ /* Switch to the next destination */
+ if (qdest pdest) {
+ /* Both destinations are set, thus here we deal with P
[PATCH 04/11] md: run stripe operations outside the lock
The raid_run_ops routine uses the asynchronous offload api and
the stripe_operations member of a stripe_head to carry out xor+pqxor+copy
operations asynchronously, outside the lock.
The operations performed by RAID-6 are the same as in the RAID-5 case
except for no support of STRIPE_OP_PREXOR operations. All the others
are supported:
STRIPE_OP_BIOFILL
- copy data into request buffers to satisfy a read request
STRIPE_OP_COMPUTE_BLK
- generate missing blocks (1 or 2) in the cache from the other blocks
STRIPE_OP_BIODRAIN
- copy data out of request buffers to satisfy a write request
STRIPE_OP_POSTXOR
- recalculate parity for new data that has entered the cache
STRIPE_OP_CHECK
- verify that the parity is correct
The flow is the same as in the RAID-5 case.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
drivers/md/Kconfig |2 +
drivers/md/raid5.c | 286
include/linux/raid/raid5.h |6 +-
3 files changed, 269 insertions(+), 25 deletions(-)
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 2281b50..7731472 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -123,6 +123,8 @@ config MD_RAID456
depends on BLK_DEV_MD
select ASYNC_MEMCPY
select ASYNC_XOR
+ select ASYNC_PQXOR
+ select ASYNC_R6RECOV
---help---
A RAID-5 set of N drives with a capacity of C MB per drive provides
the capacity of C * (N - 1) MB, and protects against a failure
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index a36a743..5b44d71 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -584,18 +584,26 @@ static void ops_run_biofill(struct stripe_head *sh)
ops_complete_biofill, sh);
}
-static void ops_complete_compute5(void *stripe_head_ref)
+static void ops_complete_compute(void *stripe_head_ref)
{
struct stripe_head *sh = stripe_head_ref;
- int target = sh-ops.target;
- struct r5dev *tgt = sh-dev[target];
+ int target, i;
+ struct r5dev *tgt;
pr_debug(%s: stripe %llu\n, __func__,
(unsigned long long)sh-sector);
- set_bit(R5_UPTODATE, tgt-flags);
- BUG_ON(!test_bit(R5_Wantcompute, tgt-flags));
- clear_bit(R5_Wantcompute, tgt-flags);
+ /* mark the computed target(s) as uptodate */
+ for (i = 0; i 2; i++) {
+ target = (!i) ? sh-ops.target : sh-ops.target2;
+ if (target 0)
+ continue;
+ tgt = sh-dev[target];
+ set_bit(R5_UPTODATE, tgt-flags);
+ BUG_ON(!test_bit(R5_Wantcompute, tgt-flags));
+ clear_bit(R5_Wantcompute, tgt-flags);
+ }
+
clear_bit(STRIPE_COMPUTE_RUN, sh-state);
if (sh-check_state == check_state_compute_run)
sh-check_state = check_state_compute_result;
@@ -627,15 +635,158 @@ static struct dma_async_tx_descriptor
*ops_run_compute5(struct stripe_head *sh)
if (unlikely(count == 1))
tx = async_memcpy(xor_dest, xor_srcs[0], 0, 0, STRIPE_SIZE,
- 0, NULL, ops_complete_compute5, sh);
+ 0, NULL, ops_complete_compute, sh);
else
tx = async_xor(xor_dest, xor_srcs, 0, count, STRIPE_SIZE,
ASYNC_TX_XOR_ZERO_DST, NULL,
- ops_complete_compute5, sh);
+ ops_complete_compute, sh);
+
+ return tx;
+}
+
+static struct dma_async_tx_descriptor *
+ops_run_compute6_1(struct stripe_head *sh)
+{
+ /* kernel stack size limits the total number of disks */
+ int disks = sh-disks;
+ struct page *srcs[disks];
+ int target = sh-ops.target 0 ? sh-ops.target2 : sh-ops.target;
+ struct r5dev *tgt = sh-dev[target];
+ struct page *dest = sh-dev[target].page;
+ int count = 0;
+ int pd_idx = sh-pd_idx, qd_idx = raid6_next_disk(pd_idx, disks);
+ int d0_idx = raid6_next_disk(qd_idx, disks);
+ struct dma_async_tx_descriptor *tx;
+ int i;
+
+ pr_debug(%s: stripe %llu block: %d\n,
+ __func__, (unsigned long long)sh-sector, target);
+ BUG_ON(!test_bit(R5_Wantcompute, tgt-flags));
+
+ atomic_inc(sh-count);
+
+ if (target == qd_idx) {
+ /* We are actually computing the Q drive*/
+ i = d0_idx;
+ do {
+ srcs[count++] = sh-dev[i].page;
+ i = raid6_next_disk(i, disks);
+ } while (i != pd_idx);
+ /* Synchronous calculations need two destination pages,
+* so use P-page too
+*/
+ tx = async_gen_syndrome(sh-dev[pd_idx].page, dest,
+ srcs, 0, count, STRIPE_SIZE,
+ ASYNC_TX_XOR_ZERO_DST, NULL,
+ ops_complete_compute, sh);
+ }
[PATCH 06/11] md: change handle_stripe_fill6 to work in asynchronous way
Change handle_stripe_fill6 to work asynchronously and introduce helper
fetch_block6 function for this.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
drivers/md/raid5.c | 154
1 files changed, 106 insertions(+), 48 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 4495df6..2ccecfa 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2226,61 +2226,119 @@ static void handle_stripe_fill5(struct stripe_head *sh,
set_bit(STRIPE_HANDLE, sh-state);
}
-static void handle_stripe_fill6(struct stripe_head *sh,
- struct stripe_head_state *s, struct r6_state *r6s,
- int disks)
+/* fetch_block6 - checks the given member device to see if its data needs
+ * to be read or computed to satisfy a request.
+ *
+ * Returns 1 when no more member devices need to be checked, otherwise returns
+ * 0 to tell the loop in handle_stripe_fill6 to continue
+ */
+static int fetch_block6(struct stripe_head *sh, struct stripe_head_state *s,
+struct r6_state *r6s, int disk_idx, int disks)
{
- int i;
- for (i = disks; i--; ) {
- struct r5dev *dev = sh-dev[i];
- if (!test_bit(R5_LOCKED, dev-flags)
- !test_bit(R5_UPTODATE, dev-flags)
- (dev-toread || (dev-towrite
-!test_bit(R5_OVERWRITE, dev-flags)) ||
-s-syncing || s-expanding ||
-(s-failed = 1
- (sh-dev[r6s-failed_num[0]].toread ||
- s-to_write)) ||
-(s-failed = 2
- (sh-dev[r6s-failed_num[1]].toread ||
- s-to_write {
- /* we would like to get this block, possibly
-* by computing it, but we might not be able to
+ struct r5dev *dev = sh-dev[disk_idx];
+ struct r5dev *fdev[2] = { sh-dev[r6s-failed_num[0]],
+ sh-dev[r6s-failed_num[1]] };
+
+ if (!test_bit(R5_LOCKED, dev-flags)
+ !test_bit(R5_UPTODATE, dev-flags)
+ (dev-toread ||
+(dev-towrite !test_bit(R5_OVERWRITE, dev-flags)) ||
+s-syncing || s-expanding ||
+(s-failed = 1
+ (fdev[0]-toread || s-to_write)) ||
+(s-failed = 2
+ (fdev[1]-toread || s-to_write {
+ /* we would like to get this block, possibly by computing it,
+* otherwise read it if the backing disk is insync
+*/
+ BUG_ON(test_bit(R5_Wantcompute, dev-flags));
+ BUG_ON(test_bit(R5_Wantread, dev-flags));
+ if ((s-uptodate == disks - 1)
+ (s-failed (disk_idx == r6s-failed_num[0] ||
+ disk_idx == r6s-failed_num[1]))) {
+ /* have disk failed, and we're requested to fetch it;
+* do compute it
*/
- if ((s-uptodate == disks - 1)
- (s-failed (i == r6s-failed_num[0] ||
- i == r6s-failed_num[1]))) {
- pr_debug(Computing stripe %llu block %d\n,
- (unsigned long long)sh-sector, i);
- compute_block_1(sh, i, 0);
- s-uptodate++;
- } else if ( s-uptodate == disks-2 s-failed = 2 ) {
- /* Computing 2-failure is *very* expensive; only
-* do it if failed = 2
+ pr_debug(Computing stripe %llu block %d\n,
+ (unsigned long long)sh-sector, disk_idx);
+ set_bit(STRIPE_COMPUTE_RUN, sh-state);
+ set_bit(STRIPE_OP_COMPUTE_BLK, s-ops_request);
+ set_bit(R5_Wantcompute, dev-flags);
+ sh-ops.target = disk_idx;
+ sh-ops.target2 = -1; /* no 2nd target */
+ s-req_compute = 1;
+ s-uptodate++;
+ return 1;
+ } else if ( s-uptodate == disks-2 s-failed = 2 ) {
+ /* Computing 2-failure is *very* expensive; only
+* do it if failed = 2
+*/
+ int other;
+ for (other = disks; other--; ) {
+ if (other == disk_idx)
+ continue;
+ if (!test_bit(R5_UPTODATE,
+ sh-dev[other].flags))
+ break;
+ }
+ BUG_ON(other 0);
+
[PATCH 08/11] md: asynchronous handle_parity_check6
This patch introduces the state machine for handling the RAID-6 parities
check and repair functionality.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
drivers/md/raid5.c | 163 +++-
1 files changed, 110 insertions(+), 53 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index c1125cd..963bc4b 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2623,91 +2623,148 @@ static void handle_parity_checks6(raid5_conf_t *conf,
struct stripe_head *sh,
struct r6_state *r6s, struct page *tmp_page,
int disks)
{
- int update_p = 0, update_q = 0;
- struct r5dev *dev;
+ int i;
+ struct r5dev *devs[2] = {NULL, NULL};
int pd_idx = sh-pd_idx;
int qd_idx = r6s-qd_idx;
set_bit(STRIPE_HANDLE, sh-state);
BUG_ON(s-failed 2);
- BUG_ON(s-uptodate disks);
+
/* Want to check and possibly repair P and Q.
* However there could be one 'failed' device, in which
* case we can only check one of them, possibly using the
* other to generate missing data
*/
- /* If !tmp_page, we cannot do the calculations,
-* but as we have set STRIPE_HANDLE, we will soon be called
-* by stripe_handle with a tmp_page - just wait until then.
-*/
- if (tmp_page) {
+ switch (sh-check_state) {
+ case check_state_idle:
+ /* start a new check operation if there are 2 failures */
if (s-failed == r6s-q_failed) {
/* The only possible failed device holds 'Q', so it
* makes sense to check P (If anything else were failed,
* we would have used P to recreate it).
*/
- compute_block_1(sh, pd_idx, 1);
- if (!page_is_zero(sh-dev[pd_idx].page)) {
- compute_block_1(sh, pd_idx, 0);
- update_p = 1;
- }
+ sh-check_state = check_state_run;
+ set_bit(STRIPE_OP_CHECK_PP, s-ops_request);
+ clear_bit(R5_UPTODATE, sh-dev[pd_idx].flags);
+ s-uptodate--;
}
if (!r6s-q_failed s-failed 2) {
/* q is not failed, and we didn't use it to generate
* anything, so it makes sense to check it
*/
- memcpy(page_address(tmp_page),
- page_address(sh-dev[qd_idx].page),
- STRIPE_SIZE);
- compute_parity6(sh, UPDATE_PARITY);
- if (memcmp(page_address(tmp_page),
- page_address(sh-dev[qd_idx].page),
- STRIPE_SIZE) != 0) {
- clear_bit(STRIPE_INSYNC, sh-state);
- update_q = 1;
- }
+ sh-check_state = check_state_run;
+ set_bit(STRIPE_OP_CHECK_QP, s-ops_request);
+ clear_bit(R5_UPTODATE, sh-dev[qd_idx].flags);
+ s-uptodate--;
}
- if (update_p || update_q) {
- conf-mddev-resync_mismatches += STRIPE_SECTORS;
- if (test_bit(MD_RECOVERY_CHECK, conf-mddev-recovery))
- /* don't try to repair!! */
- update_p = update_q = 0;
+ if (sh-check_state == check_state_run) {
+ break;
}
- /* now write out any block on a failed drive,
-* or P or Q if they need it
-*/
+ /* we have 2-disk failure */
+ BUG_ON(s-failed != 2);
+ devs[0] = sh-dev[r6s-failed_num[0]];
+ devs[1] = sh-dev[r6s-failed_num[1]];
+ /* fall through */
+ case check_state_compute_result:
+ sh-check_state = check_state_idle;
- if (s-failed == 2) {
- dev = sh-dev[r6s-failed_num[1]];
- s-locked++;
- set_bit(R5_LOCKED, dev-flags);
- set_bit(R5_Wantwrite, dev-flags);
+ BUG_ON((devs[0] !devs[1]) ||
+ (!devs[0] devs[1]));
+
+ BUG_ON(s-uptodate (disks - 1));
+
+ if (!devs[0]) {
+ if (s-failed = 1)
+ devs[0] = sh-dev[r6s-failed_num[0]];
+ else
+ devs[0] = sh-dev[pd_idx];
}
- if (s-failed = 1) {
-
[PATCH 10/11] md: remove unused functions
Some clean-up of the replaced or already unnecessary functions.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
drivers/md/raid5.c | 246
1 files changed, 0 insertions(+), 246 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 79e8c74..6bde4da 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1647,245 +1647,6 @@ static sector_t compute_blocknr(struct stripe_head *sh,
int i)
}
-
-/*
- * Copy data between a page in the stripe cache, and one or more bion
- * The page could align with the middle of the bio, or there could be
- * several bion, each with several bio_vecs, which cover part of the page
- * Multiple bion are linked together on bi_next. There may be extras
- * at the end of this list. We ignore them.
- */
-static void copy_data(int frombio, struct bio *bio,
-struct page *page,
-sector_t sector)
-{
- char *pa = page_address(page);
- struct bio_vec *bvl;
- int i;
- int page_offset;
-
- if (bio-bi_sector = sector)
- page_offset = (signed)(bio-bi_sector - sector) * 512;
- else
- page_offset = (signed)(sector - bio-bi_sector) * -512;
- bio_for_each_segment(bvl, bio, i) {
- int len = bio_iovec_idx(bio,i)-bv_len;
- int clen;
- int b_offset = 0;
-
- if (page_offset 0) {
- b_offset = -page_offset;
- page_offset += b_offset;
- len -= b_offset;
- }
-
- if (len 0 page_offset + len STRIPE_SIZE)
- clen = STRIPE_SIZE - page_offset;
- else clen = len;
-
- if (clen 0) {
- char *ba = __bio_kmap_atomic(bio, i, KM_USER0);
- if (frombio)
- memcpy(pa+page_offset, ba+b_offset, clen);
- else
- memcpy(ba+b_offset, pa+page_offset, clen);
- __bio_kunmap_atomic(ba, KM_USER0);
- }
- if (clen len) /* hit end of page */
- break;
- page_offset += len;
- }
-}
-
-#define check_xor()do { \
- if (count == MAX_XOR_BLOCKS) {\
- xor_blocks(count, STRIPE_SIZE, dest, ptr);\
- count = 0;\
- } \
- } while(0)
-
-static void compute_parity6(struct stripe_head *sh, int method)
-{
- raid6_conf_t *conf = sh-raid_conf;
- int i, pd_idx = sh-pd_idx, qd_idx, d0_idx, disks = sh-disks, count;
- struct bio *chosen;
- / FIX THIS: This could be very bad if disks is close to 256 /
- void *ptrs[disks];
-
- qd_idx = raid6_next_disk(pd_idx, disks);
- d0_idx = raid6_next_disk(qd_idx, disks);
-
- pr_debug(compute_parity, stripe %llu, method %d\n,
- (unsigned long long)sh-sector, method);
-
- switch(method) {
- case READ_MODIFY_WRITE:
- BUG(); /* READ_MODIFY_WRITE N/A for RAID-6 */
- case RECONSTRUCT_WRITE:
- for (i= disks; i-- ;)
- if ( i != pd_idx i != qd_idx sh-dev[i].towrite )
{
- chosen = sh-dev[i].towrite;
- sh-dev[i].towrite = NULL;
-
- if (test_and_clear_bit(R5_Overlap,
sh-dev[i].flags))
- wake_up(conf-wait_for_overlap);
-
- BUG_ON(sh-dev[i].written);
- sh-dev[i].written = chosen;
- }
- break;
- case CHECK_PARITY:
- BUG(); /* Not implemented yet */
- }
-
- for (i = disks; i--;)
- if (sh-dev[i].written) {
- sector_t sector = sh-dev[i].sector;
- struct bio *wbi = sh-dev[i].written;
- while (wbi wbi-bi_sector sector + STRIPE_SECTORS)
{
- copy_data(1, wbi, sh-dev[i].page, sector);
- wbi = r5_next_bio(wbi, sector);
- }
-
- set_bit(R5_LOCKED, sh-dev[i].flags);
- set_bit(R5_UPTODATE, sh-dev[i].flags);
- }
-
-// switch(method) {
-// case RECONSTRUCT_WRITE:
-// case CHECK_PARITY:
-// case UPDATE_PARITY:
- /* Note that unlike RAID-5, the ordering of the disks matters
greatly. */
- /* FIX: Is this ordering of drives even remotely optimal? */
-
Please pull 'merge' branch of powerpc-4xx git tree
Hi Paul, Please pull the merge branch of the powerpc-4xx git tree. It contains two small fixes that should go into .28. thx, josh The following changes since commit cb8fdc69a2a80e81e1280ec58afd2c3217ac8a7f: Paul Mackerras (1): powerpc: Update desktop/server defconfigs are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Benjamin Herrenschmidt (1): powerpc/44x: Fix 460EX/460GT machine check handling Grant Erickson (1): powerpc/40x: Limit allocable DRAM during early mapping arch/powerpc/kernel/cpu_setup_44x.S |7 ++- arch/powerpc/mm/40x_mmu.c | 16 ++-- 2 files changed, 20 insertions(+), 3 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/11] ppc440spe-adma: ADMA driver for PPC440SP(e) systems
On Thu, 13 Nov 2008 20:50:43 +0300 Ilya Yanok [EMAIL PROTECTED] wrote: Josh Boyer wrote: On Thu, Nov 13, 2008 at 06:16:04PM +0300, Ilya Yanok wrote: Adds the platform device definitions and the architecture specific support routines for the ppc440spe adma driver. Any board equipped with PPC440SP(e) controller may utilize this driver. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Ilya Yanok [EMAIL PROTECTED] Before I really dig into reviewing this driver, I'm going to ask you as simple question. This looks like a 1/2 completed port of an arch/ppc driver that uses the device tree (incorrectly) to get the interrupt resources and that's about it. Otherwise, it's just a straight up platform device driver. Is that correct? Yep, that's correct. OK. If that is the case, I think the driver needs more work before it can be merged. It should get the DCR and MMIO resources from the device tree as well. It should be binding on compatible properties and not based on device tree paths. And it should probably be an of_platform device driver. Surely, you're right. I agree with you in that this driver isn't ready for merging. But it works so we'd like to publish it so interested people could use it and test it. And that's fine. I just wanted to see where you were headed with this one for now. I'll try to do a review in the next few days. Thanks for posting. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] net/ucc_geth: Fix oops in uec_get_ethtool_stats()
p_{tx,rx}_fw_statistics_pram are special: they're available only when
a device is open. If the device is closed, we should just fill the data
with zeroes.
Fixes the following oops:
[EMAIL PROTECTED]:~# ifconfig eth1 down
[EMAIL PROTECTED]:~# ethtool -S eth1
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc01e1dcc
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [c01e1dcc] uec_get_ethtool_stats+0x98/0x124
LR [c0287cc8] ethtool_get_stats+0xfc/0x23c
Call Trace:
[cfaadde0] [c0287ca8] ethtool_get_stats+0xdc/0x23c (unreliable)
[cfaade20] [c0288340] dev_ethtool+0x2fc/0x588
[cfaade50] [c0285648] dev_ioctl+0x290/0x33c
[cfaadea0] [c0272238] sock_ioctl+0x80/0x2ec
[cfaadec0] [c00b5ae4] vfs_ioctl+0x40/0xc0
[cfaadee0] [c00b5fa8] do_vfs_ioctl+0x78/0x20c
[cfaadf10] [c00b617c] sys_ioctl+0x40/0x74
[cfaadf40] [c00142d8] ret_from_syscall+0x0/0x38
[...]
---[ end trace b941007b2dfb9759 ]---
Segmentation fault
p.s. While at it, also remove u64 casts, they aren't needed.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/net/ucc_geth_ethtool.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth_ethtool.c b/drivers/net/ucc_geth_ethtool.c
index cfbbfee..7ed1638 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -324,17 +324,17 @@ static void uec_get_ethtool_stats(struct net_device
*netdev,
if (stats_mode UCC_GETH_STATISTICS_GATHERING_MODE_HARDWARE) {
base = (u32 __iomem *)ugeth-ug_regs-tx64;
for (i = 0; i UEC_HW_STATS_LEN; i++)
- data[j++] = (u64)in_be32(base[i]);
+ data[j++] = in_be32(base[i]);
}
if (stats_mode UCC_GETH_STATISTICS_GATHERING_MODE_FIRMWARE_TX) {
base = (u32 __iomem *)ugeth-p_tx_fw_statistics_pram;
for (i = 0; i UEC_TX_FW_STATS_LEN; i++)
- data[j++] = (u64)in_be32(base[i]);
+ data[j++] = base ? in_be32(base[i]) : 0;
}
if (stats_mode UCC_GETH_STATISTICS_GATHERING_MODE_FIRMWARE_RX) {
base = (u32 __iomem *)ugeth-p_rx_fw_statistics_pram;
for (i = 0; i UEC_RX_FW_STATS_LEN; i++)
- data[j++] = (u64)in_be32(base[i]);
+ data[j++] = base ? in_be32(base[i]) : 0;
}
}
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v1] RS485 support for MPC5200x_psc_uart
Hello Hans, On Thu, Nov 13, 2008 at 04:48:30PM +0100, Lehmann, Hans (Ritter Elektronik) wrote: Adds rs485 support for MPC52xx_psc_uart Please be more specific. What exactly was done/modified to have RS485-support. Please also read SubmittingPatches and CodingStyle in the Documentation directory and adapt your patch accordingly. For example: Send patches inlined, this makes reviewing a lot easier. Don't use magic numbers. Use spaces around operators. All this helps maintaining your code in the future. COM1 is console and not selectable. COM1 is rarely selectable in Linux ;) Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
On Thu, 2008-11-13 at 07:44 +1100, Benjamin Herrenschmidt wrote: Again, why can't we just stick something in the kernel code that reserves the last page ? It could be in prom.c or it could be called by affected 4xx platforms by the platform code, whatever, but the reserve map isn't really meant for that and will not be passed over from kernel to kernel by kexec. Reserving a page is overkill; only the last 256 bytes are affected. We need to intercept at the LMB level, because allocations are already done there, so by the time we hit bootmem it's way too late. I simply don't see a good place to do this in the kernel. It would have to be before the first lmb_alloc() call, which for safety would put it inside early_init_devtree() -- along with the other lmb_reserve() calls.[1] However, ppc_md.probe() hasn't even been called yet, so there's no way of knowing if we're on an affected system, unless you want to add a special of_scan_flat_dt() call here. I'm open to suggestions, but I don't see a better way than what I already sent. I think the important part is to call lmb_add() for all memory, but lmb_reserve() the last 256 bytes before lmb_alloc() happens. It sounds like kexec must have some knowledge of the platform and device tree already, so is this really a big deal? At any rate, this conversation is somewhat academic, since there is no kexec on 44x... so maybe this can be re-addressed when that becomes a real issue. [1] This is exactly where flat device tree reservations are done, and that's why the patch I submitted works. -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pmac_zilog debugging ...
On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote: 12,206 PowerMac Zilog interrupts Interrupt load is higher without the DMA support. Is it possible that this hardware was not meant to be used without the DMA (i.e. it does not work quite right?)? Well, the HW Rx buffer is only 3 bytes so if you have high interrupt latencies you are more likely to loose data... Now, as I said, have you looked at flow control ? It's a likely cause of problems and it's possible that pmac_zilog doesn't do it the way macserial did... Regarding DMA, it's possible to implement, though there were interesting issues with the way it was done in macserial, it should be done differently in pmac_zilog. I think the only approach that really works properly (though it's fugly) is what Apple does in OSX I think, which is to have a DMA descriptor per input byte (no need for a huge DMA buffer anyway). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pmac_zilog debugging ...
Benjamin Herrenschmidt wrote: On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote: 12,206 PowerMac Zilog interrupts Interrupt load is higher without the DMA support. Is it possible that this hardware was not meant to be used without the DMA (i.e. it does not work quite right?)? Well, the HW Rx buffer is only 3 bytes so if you have high interrupt latencies you are more likely to loose data... These are not real 8530s any more, right? How certain are we of this? Is it possible that there is a larger buffer when used with the DMA capability ... somehow? Now, as I said, have you looked at flow control ? It's a likely cause of problems and it's possible that pmac_zilog doesn't do it the way macserial did... I tried to put some debug statements where the flow lines are managed. I could have goofed it up. They never produce any output. The latest attempt used nortscts which should have disabled flow control. That coupled with the fact that a 250 MHz 750GX is talking to a 486dx4 at 1200 - 9600 baud I would have thought would reduce the chance the PowerMac would fall behind? Regarding DMA, it's possible to implement, though there were interesting issues with the way it was done in macserial, it should be done differently in pmac_zilog. I think the only approach that really works properly (though it's fugly) is what Apple does in OSX I think, which is to have a DMA descriptor per input byte (no need for a huge DMA buffer anyway). You would need to explain to me the advantage of doing DMA in this case??? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc832x_rdb: fix swapped ethernet ids
On Thu, Nov 13, 2008 at 10:18:28AM -0500, Michael Barkowski wrote:
ethernet0 (called FSL UEC0 in U-Boot) should be enet1 (UCC3/eth1), and
ethernet1 should be enet0 (UCC2/eth0), to be consistent with U-Boot so
that the interfaces do not swap addresses when control passes from
U-Boot to the kernel.
Um.. why is just swapping the aliases, rather than the enet labels the
right approach here?
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 226ff06..dea3091 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -18,8 +18,8 @@
#size-cells = 1;
aliases {
- ethernet0 = enet0;
- ethernet1 = enet1;
+ ethernet0 = enet1;
+ ethernet1 = enet0;
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [2/2] powerpc: support for 256K pages on PPC 44x
Hello Milton, On Tuesday, November 11, 2008 Milton Miller wrote: [snip] #ifdef CONFIG_PTE_64BIT typedef unsigned long long pte_basic_t; +#ifdef CONFIG_PPC_256K_PAGES +#define PTE_SHIFT (PAGE_SHIFT - 7) This seems to be missing the comment on how many ptes are actually in the page that are in the other if and else cases. Ok. I'll fix this. Actually it's another hack: we don't use full page for PTE table because we need to reserve something for PGD I don't understand we need to reserve something for PGD. Do you mean that you would not require a second page for the PGD because the full pagetable could fit in one page? My first reaction was to say then create pgtable-nopgd.h like the other two. The page walkers support this with the advent of gigantic pages. Then I realized that might not be optimal: while the page table might fit in one page, it would mean you always allocate the pte space to cover the full address space. Even if your processes spread out over the 3G of address space allocated to them (32 bit kernel), you will allocate space for 4G, wasting 1/4 of the pte space. That does imply you want to allocate the pte page from a slab instead of pgalloc. Is that covered? Well, in case of 256K PAGE_SIZE we do not need the PGD level indeed (18 bits are used for offset, and remaining 14 bits are for PTE index inside the PTE table). Even the full 256K PTE page isn't necessary to cover the full range: only half of it would be enough (with 14 bits we can address only 16K PTEs). But the head_44x.S code is essentially based on the assumption of 2-level page addressing. Also, I may guess that eliminating of the PGD level won't be as easy as just a re-implementation of the TLB-miss handlers in head_44x.S. So, the current approach for 256K-pages support was just a compromise between the required for the project functionality, and the effort necessary to achieve it. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] xsysace: use resource_size_t instead of unsigned long
Hello Stephen, On Thursday, November 13, 2008 you wrote: Hi Yuri, On Thu, 13 Nov 2008 11:43:17 +0300 Yuri Tikhonov [EMAIL PROTECTED] wrote: - dev_dbg(ace-dev, physaddr=0x%lx irq=%i\n, ace-physaddr, ace-irq); + dev_dbg(ace-dev, physaddr=0x%llx irq=%i\n, (u64)ace-physaddr, ace-irq); You should cast the physaddr to unsigned long long as u64 is unsigned long on some architectures. The same is needed in other places as well. Thanks for your comment. We'll fix this. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
On Thu, Nov 13, 2008 at 06:45:33AM -0500, Josh Boyer wrote:
On Thu, 13 Nov 2008 11:49:14 +0300
Yuri Tikhonov [EMAIL PROTECTED] wrote:
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
Odd. This isn't a xilinx board by any means. This should probably
look something like:
compatible = amcc,sysace-440spe, xlnx,opb-sysace-1.00.b;
Actually, if there is a sysace, it is definitely a xilinx part. It
won't be on the SoC. However, compatible = xlnx,opb-sysace-1.00.b
isn't really accurate. It should really be compatible = xlnx,sysace
and the driver modified to accept this string. xlnx,opb-sysace-1.00.b
is an FPGA block used to interface to the system ace which is
definitely not in use here.
So while it does get things to work, it is not a clean description of
the hardware.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
Hello Josh,
On Thursday, November 13, 2008 you wrote:
[snip]
You have no compatible property in these 3 nodes. How are drivers
supposed to bind to them?
You also have no reg or dcr-reg properties. What exactly are these
nodes for?
Probably we (me and Ilya) overdone with posting katmai.dts-related
changes to ML, and duplicated the same patches in different posts.
Sorry for the confusion. These nodes are necessary for the ppc440spe
ADMA driver:
http://www.nabble.com/-PATCH-11-11--ppc440spe-adma:-ADMA-driver-for-PPC440SP(e)-td20488049.html
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
Odd. This isn't a xilinx board by any means. This should probably
look something like:
compatible = amcc,sysace-440spe, xlnx,opb-sysace-1.00.b;
Though I'm curious about it in general. The xilinx bindings have the
versioning numbers on them to match particular bit-streams in the FPGAs
if I remember correctly. Does that really apply here?
No, we just selected the description which looked more appropriate
for our case: SysAce is connected to the External Bus Controller of
440SPe, which in turns is attached as a slave to OPB (on-chip
peripheral).
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
Hello Grant,
On Friday, November 14, 2008 you wrote:
On Thu, Nov 13, 2008 at 06:45:33AM -0500, Josh Boyer wrote:
On Thu, 13 Nov 2008 11:49:14 +0300
Yuri Tikhonov [EMAIL PROTECTED] wrote:
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
Odd. This isn't a xilinx board by any means. This should probably
look something like:
compatible = amcc,sysace-440spe, xlnx,opb-sysace-1.00.b;
Actually, if there is a sysace, it is definitely a xilinx part. It
won't be on the SoC. However, compatible = xlnx,opb-sysace-1.00.b
isn't really accurate. It should really be compatible = xlnx,sysace
and the driver modified to accept this string.
OK, we'll do this, and then re-post together with the cleaned-up
[PATCH] xsysace: use resource_size_t instead of unsigned long patch.
xlnx,opb-sysace-1.00.b
is an FPGA block used to interface to the system ace which is
definitely not in use here.
So while it does get things to work, it is not a clean description of
the hardware.
g.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re[2]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
On Thu, Nov 13, 2008 at 10:27 PM, Yuri Tikhonov [EMAIL PROTECTED] wrote:
Hello Grant,
On Friday, November 14, 2008 you wrote:
On Thu, Nov 13, 2008 at 06:45:33AM -0500, Josh Boyer wrote:
On Thu, 13 Nov 2008 11:49:14 +0300
Yuri Tikhonov [EMAIL PROTECTED] wrote:
+ [EMAIL PROTECTED] {
+ compatible = xlnx,opb-sysace-1.00.b;
Odd. This isn't a xilinx board by any means. This should probably
look something like:
compatible = amcc,sysace-440spe, xlnx,opb-sysace-1.00.b;
Actually, if there is a sysace, it is definitely a xilinx part. It
won't be on the SoC. However, compatible = xlnx,opb-sysace-1.00.b
isn't really accurate. It should really be compatible = xlnx,sysace
and the driver modified to accept this string.
OK, we'll do this, and then re-post together with the cleaned-up
[PATCH] xsysace: use resource_size_t instead of unsigned long patch.
Please cc: me on the next version of the xsysace patch.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re[2]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
My understanding was that the dma-ranges property is responsible for setting up the inbound ranges of RAM's physical addresses, where PCI could DMA to/from. As regarding the outbound property, this patch doesn't change this, and there we have the PCI space split (2 GB of memory, and 64K of I/O spaces mapped from the 64-bit physical addresses into 32-bit PCI address space). Am I missing something ? The PCI memory space doesn't differenciate inbound and outbound. For example, if you take the example of a PCI 2.0 or PCI-X setup (I'm leaving PCI-E alone in the discussion because it's a bit special in that area, but the problem is fundamentally the same), and you have on the PCI bus of that thing a device X configured to respond to MMIO at address, for example, 0x8000. Now, what happens if another device, let's call it Y, tries to DMA to that same address ? Who will pick up the memory write at address 0x8000 ? The host controller or device X ? There is no concept of inbound here.. it's just a memory cycle to address A that gets decoded by whoever tries to decode it on that bus segment. Thus DMA ranges must -not- overlap areas of memory used for MMIO, it just won't work. With the default 2GB dma-ranges we just get the following on Katmai with 4GB of SDRAM installed: Because that is simply not supported at the moment unless we add what I've talked about earlier, ie basically, swiotlb support (which Becky is working on at the moment). You might be able to work around it somewhat if your PCI device supports 64-bit BARs in which case you can set your outbound regions above the 32-bit space. Note that I haven't verified whether the 32-bit linux kernel supports that tho. There used to be issues with 32-bit PCI BARs on 32-bit kernel, at least it wouldn't assign them but that may have been fixed. Another option you can try if you device only does 32-bit BARs but supports 64-bit DMA, is to move the DMA window away from the 32-bit MMIO space. Stick it at 1T or so in PCI space. You might need a little bit of kernel tweaking to make the dma-ops pick that up properly but that shouldnt be too hard. If you really need 32-bit DMA support, you'll have to wait for swiotlb from Becky or work with her in bringing it to powerpc so that we can do bounce buffering for those devices. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
