RE: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance
-Original Message- From: dan.j.willi...@gmail.com [mailto:dan.j.willi...@gmail.com] On Behalf Of Dan Williams Sent: Wednesday, August 15, 2012 4:02 AM To: Liu Qiang-B32616 Cc: dan.j.willi...@intel.com; vinod.k...@intel.com; a...@arndb.de; herb...@gondor.apana.org.au; gre...@linuxfoundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; linux- cry...@vger.kernel.org; Ira W. Snyder Subject: Re: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance On Tue, Aug 14, 2012 at 2:04 AM, Liu Qiang-B32616 b32...@freescale.com wrote: Hi Vinod, Would you like to apply this series from patch 2/8 to 7/8) in your tree? The link as below, http://patchwork.ozlabs.org/patch/176023/ http://patchwork.ozlabs.org/patch/176024/ http://patchwork.ozlabs.org/patch/176025/ http://patchwork.ozlabs.org/patch/176026/ http://patchwork.ozlabs.org/patch/176027/ http://patchwork.ozlabs.org/patch/176028/ Hi, sorry for the recent silence I've been transitioning and am now just catching up. I'll take a look and then it's fine for these to go through Vinod's tree. Hello Dan, Please review, this issue has been continued since many years. I hope we can fix it this time. Thanks. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
-Original Message- From: Wood Scott-B07421 Sent: Saturday, August 11, 2012 12:00 AM To: Jia Hongtao-B38951 Cc: Gala Kumar-B11780; Wood Scott-B07421; Li Yang-R58472; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code On 08/10/2012 03:47 AM, Jia Hongtao-B38951 wrote: -Original Message- From: Gala Kumar-B11780 Sent: Thursday, August 09, 2012 3:04 AM To: Wood Scott-B07421 Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code As I explained before, this has to be done globally, not from the probe function, so we can assign a default primary bus if there isn't any ISA. There are bugs in the Linux PPC PCI code relating to not having any primary bus. -Scott In my way of searching ISA you can also assign a default primary bus in board specific files. That was meant for when the board file had an alternate way of searching for the primary bus (e.g. look for i8259), not as a replacement for the mechanism that guarantees there's a primary bus. You are causing a regression in the qemu_e500.c platform. Can we fix the qemu device tree to address the problem if we do make it a rule to use the ISA node to indicate the primary bus? No. There is no ISA, and we're not going to lie and say there is. But we can assign a default primary for qemu. Not in the device tree. What other mechanism do you propose? And why do you want to fix it only for QEMU and not other boards, where things happen to work but not as designed? Kumar, can you speak up here as maintainer so we can stop going back and forth endlessly? I'd rather we stick with the code that works for this purpose at this point. That would be Scott's current upstream code. Lets get the other aspects of this patchset closed (SWIOTLB, conversion to platform driver, PM, etc.). The primary bus code Scott wrote does NOT need to change at this point. - k I just submitted a new version of PCI patch in which I improve the primary part. The reasons I want to change the way of primary assignment listed below: 1. This approach is functionally equivalent to the Scott's code. In my approach there might be no primary assigned but it fixed by quick fix introduced by Ben. Please refer to this link: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html You might want to get Ben's input as to whether he actually wants to see that quick fix applied. 2. Scott's and my way could not handle the situation that the primary is not the first PCI bus detected. I found that only ge_imp3a got this problem so I fixed it by adding ISA node to its device tree. By adding this I think the solution is logically completed. How did my approach not handle this case? As I said, ge_imp3a platform code needs to set fsl_pci_primary manually before PCI init runs. Adding a node to the device tree is not the answer, since that will break compatibility with old device trees. I assume that kernel image and dtb image are from the same tree. -Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V7 0/3] PCI unification patch description
From: Benjamin Herrenschmidt b...@kernel.crashing.org In this patch set we unified the Freescale pci/pcie initialization by changing the fsl_pci to a platform driver. We also change the way of determining primary bus for fitting platform driver. The first two patches are the preparation for this. Thanks to Ben. For the first patch you can refer to the following link: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V7 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function which is architectural better. Also It's convenient for
adding PM support for PCI controller in later patch.
We also change the way of determining primary bus for fitting platform
driver. Two previous patches are the preparation for this.
Now we registered pci controllers as platform devices. So we combine two
initialization code as one platform driver.
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
Changes for V7:
- Separate V6 to three functional independent patches.
arch/powerpc/platforms/85xx/common.c | 10 +++
arch/powerpc/platforms/85xx/corenet_ds.c | 31 +
arch/powerpc/platforms/85xx/ge_imp3a.c | 48 +
arch/powerpc/platforms/85xx/mpc8536_ds.c | 36 +-
arch/powerpc/platforms/85xx/mpc85xx_ads.c |9 +--
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 14 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 38 ++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 38 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 28 +++-
arch/powerpc/platforms/85xx/p1010rdb.c | 14 +
arch/powerpc/platforms/85xx/p1022_ds.c | 34 +-
arch/powerpc/platforms/85xx/p1022_rdk.c| 34 +-
arch/powerpc/platforms/85xx/p1023_rds.c|7 +--
arch/powerpc/platforms/85xx/p2041_rdb.c|2 +-
arch/powerpc/platforms/85xx/p3041_ds.c |2 +-
arch/powerpc/platforms/85xx/p4080_ds.c |2 +-
arch/powerpc/platforms/85xx/p5020_ds.c |2 +-
arch/powerpc/platforms/85xx/p5040_ds.c |2 +-
arch/powerpc/platforms/85xx/qemu_e500.c|3 +-
arch/powerpc/platforms/85xx/sbc8548.c | 19 +-
arch/powerpc/platforms/85xx/socrates.c | 11 +---
arch/powerpc/platforms/85xx/stx_gp3.c | 11 +---
arch/powerpc/platforms/85xx/tqm85xx.c | 21 +--
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 54 ++-
arch/powerpc/platforms/86xx/gef_ppc9a.c| 10 +--
arch/powerpc/platforms/86xx/gef_sbc310.c | 11 +---
arch/powerpc/platforms/86xx/gef_sbc610.c | 10 +--
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 19 +
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 40 +--
arch/powerpc/platforms/86xx/sbc8641d.c | 12 +---
arch/powerpc/sysdev/fsl_pci.c | 102 +---
arch/powerpc/sysdev/fsl_pci.h |9 ++-
drivers/edac/mpc85xx_edac.c| 43 +++-
33 files changed, 160 insertions(+), 566 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index 67dac22..d0861a0 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -27,6 +27,16 @@ static struct of_device_id __initdata mpc85xx_common_ids[] =
{
{ .compatible = fsl,mpc8548-guts, },
/* Probably unnecessary? */
{ .compatible = gpio-leds, },
+ /* For all PCI controllers */
+ { .compatible = fsl,mpc8540-pci, },
+ { .compatible = fsl,mpc8548-pcie, },
+ { .compatible = fsl,p1022-pcie, },
+ { .compatible = fsl,p1010-pcie, },
+ { .compatible = fsl,p1023-pcie, },
+ { .compatible = fsl,p4080-pcie, },
+ { .compatible = fsl,qoriq-pcie-v2.4, },
+ { .compatible = fsl,qoriq-pcie-v2.3, },
+ { .compatible = fsl,qoriq-pcie-v2.2, },
{},
};
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 473d573..84b9d86 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -16,7 +16,6 @@
#include linux/kdev_t.h
#include linux/delay.h
#include linux/interrupt.h
-#include linux/memblock.h
#include asm/time.h
#include asm/machdep.h
@@ -52,39 +51,13 @@ void __init corenet_ds_pic_init(void)
*/
void __init corenet_ds_setup_arch(void)
{
-#ifdef CONFIG_PCI
- struct device_node *np;
- struct pci_controller *hose;
-#endif
- dma_addr_t max = 0x;
-
mpc85xx_smp_init();
-#ifdef CONFIG_PCI
- for_each_node_by_type(np, pci) {
- if (of_device_is_compatible(np, fsl,p4080-pcie) ||
- of_device_is_compatible(np, fsl,qoriq-pcie-v2.2) ||
- of_device_is_compatible(np, fsl,qoriq-pcie-v2.3) ||
- of_device_is_compatible(np, fsl,qoriq-pcie-v2.4)) {
- fsl_add_bridge(np, 0);
- hose = pci_find_hose_for_OF_device(np);
- max = min(max, hose-dma_window_base_cur +
- hose-dma_window_size);
- }
- }
-
-#ifdef CONFIG_PPC64
+#if
[PATCH V7 2/3] powerpc/ge_imp3a: Add ISA node to PCI primary bus
PCI primary bus will be determined by looking for ISA node in device tree.
Also for board ge_imp3a primary bus is the second PCI controller detected.
So we add ISA node to ge_imp3a's device tree to fit the new determination.
Adding ISA node to other boards' device tree is not necessary. The situation
that the first bus is primary have already been handled. Please refer to the
following patch:
powerpc/pci: Make sure ISA IO base is not zero
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/boot/dts/ge_imp3a.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ge_imp3a.dts
b/arch/powerpc/boot/dts/ge_imp3a.dts
index fefae41..aa2c4b5 100644
--- a/arch/powerpc/boot/dts/ge_imp3a.dts
+++ b/arch/powerpc/boot/dts/ge_imp3a.dts
@@ -248,6 +248,10 @@
0x100 0x0 0x0
0x100 0x0 0x0
0x0 0x1;
+
+ isa@1e {
+ device_type = isa;
+ };
};
};
};
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
From: Benjamin Herrenschmidt b...@kernel.crashing.org Some platforms like QEMU treat 0 as an invalid address for ISA IO base. So we make sure that ISA IO base will never be zero. By functionality this is equivalent to assgin the first pci bus detected as a primary bus. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Jia Hongtao b38...@freescale.com --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f75bd5..2a09aa5 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -734,7 +734,7 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose, hose-io_base_virt = ioremap(cpu_addr, size); /* Expect trouble if pci_addr is not 0 */ - if (primary) + if (primary || !isa_io_base) isa_io_base = (unsigned long)hose-io_base_virt; #endif /* CONFIG_PPC32 */ -- 1.7.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On Aug 14, 2012, at 10:56 PM, Jia Hongtao-B38951 b38...@freescale.com wrote: +EXPORT_SYMBOL_GPL(mpc85xx_pci_err_probe); Make this EXPORT_SYMBOL. Hi Timur and Kumar: I'm a little confused. Should we remove _GPL for upstream version too? Yes. -Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] kconfig: remove CONFIG_MTD_NAND_VERIFY_WRITE
Just as Artem suggested: Both UBI and JFFS2 are able to read verify what they wrote already. There are also MTD tests which do this verification. So I think there is no reason to keep this in the NAND layer, let alone wasting RAM in the driver to support this feature. So kill MTD_NAND_VERIFY_WRITE entirely. Please see the patch: http://lists.infradead.org/pipermail/linux-mtd/2012-August/043189.html This patch removes the CONFIG_MTD_NAND_VERIFY_WRITE in the defconfigs. Signed-off-by: Huang Shijie b32...@freescale.com --- arch/arm/configs/bcmring_defconfig |1 - arch/arm/configs/cam60_defconfig|1 - arch/arm/configs/corgi_defconfig|1 - arch/arm/configs/ep93xx_defconfig |1 - arch/arm/configs/mini2440_defconfig |1 - arch/arm/configs/mv78xx0_defconfig |1 - arch/arm/configs/nhk8815_defconfig |1 - arch/arm/configs/orion5x_defconfig |1 - arch/arm/configs/pxa3xx_defconfig |1 - arch/arm/configs/spitz_defconfig|1 - arch/blackfin/configs/BF561-ACVILON_defconfig |1 - arch/mips/configs/rb532_defconfig |1 - arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |1 - arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |1 - arch/powerpc/configs/mpc83xx_defconfig |1 - 15 files changed, 0 insertions(+), 15 deletions(-) diff --git a/arch/arm/configs/bcmring_defconfig b/arch/arm/configs/bcmring_defconfig index 9e6a8fe..6c389d9 100644 --- a/arch/arm/configs/bcmring_defconfig +++ b/arch/arm/configs/bcmring_defconfig @@ -44,7 +44,6 @@ CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_GEOMETRY=y # CONFIG_MTD_CFI_I2 is not set CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_BCM_UMI=y CONFIG_MTD_NAND_BCM_UMI_HWCS=y # CONFIG_MISC_DEVICES is not set diff --git a/arch/arm/configs/cam60_defconfig b/arch/arm/configs/cam60_defconfig index cedc92e..1457971 100644 --- a/arch/arm/configs/cam60_defconfig +++ b/arch/arm/configs/cam60_defconfig @@ -49,7 +49,6 @@ CONFIG_MTD_COMPLEX_MAPPINGS=y CONFIG_MTD_PLATRAM=m CONFIG_MTD_DATAFLASH=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_ATMEL=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y diff --git a/arch/arm/configs/corgi_defconfig b/arch/arm/configs/corgi_defconfig index e53c475..4b8a25d 100644 --- a/arch/arm/configs/corgi_defconfig +++ b/arch/arm/configs/corgi_defconfig @@ -97,7 +97,6 @@ CONFIG_MTD_BLOCK=y CONFIG_MTD_ROM=y CONFIG_MTD_COMPLEX_MAPPINGS=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_SHARPSL=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y diff --git a/arch/arm/configs/ep93xx_defconfig b/arch/arm/configs/ep93xx_defconfig index 8e97b2f..806005a 100644 --- a/arch/arm/configs/ep93xx_defconfig +++ b/arch/arm/configs/ep93xx_defconfig @@ -61,7 +61,6 @@ CONFIG_MTD_CFI_STAA=y CONFIG_MTD_ROM=y CONFIG_MTD_PHYSMAP=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_BLK_DEV_NBD=y CONFIG_EEPROM_LEGACY=y CONFIG_SCSI=y diff --git a/arch/arm/configs/mini2440_defconfig b/arch/arm/configs/mini2440_defconfig index 082175c..00630e6 100644 --- a/arch/arm/configs/mini2440_defconfig +++ b/arch/arm/configs/mini2440_defconfig @@ -102,7 +102,6 @@ CONFIG_MTD_CFI_STAA=y CONFIG_MTD_RAM=y CONFIG_MTD_ROM=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_S3C2410=y CONFIG_MTD_NAND_PLATFORM=y CONFIG_MTD_LPDDR=y diff --git a/arch/arm/configs/mv78xx0_defconfig b/arch/arm/configs/mv78xx0_defconfig index 7305ebd..1f08219 100644 --- a/arch/arm/configs/mv78xx0_defconfig +++ b/arch/arm/configs/mv78xx0_defconfig @@ -49,7 +49,6 @@ CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_ORION=y CONFIG_BLK_DEV_LOOP=y # CONFIG_SCSI_PROC_FS is not set diff --git a/arch/arm/configs/nhk8815_defconfig b/arch/arm/configs/nhk8815_defconfig index bf123c5..240b25e 100644 --- a/arch/arm/configs/nhk8815_defconfig +++ b/arch/arm/configs/nhk8815_defconfig @@ -57,7 +57,6 @@ CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ECC_SMC=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_NOMADIK=y CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y diff --git a/arch/arm/configs/orion5x_defconfig b/arch/arm/configs/orion5x_defconfig index a288d70..cd5e6ba 100644 --- a/arch/arm/configs/orion5x_defconfig +++ b/arch/arm/configs/orion5x_defconfig @@ -72,7 +72,6 @@ CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP=y CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_PLATFORM=y CONFIG_MTD_NAND_ORION=y CONFIG_BLK_DEV_LOOP=y diff --git a/arch/arm/configs/pxa3xx_defconfig b/arch/arm/configs/pxa3xx_defconfig index 1677a06..60e3138 100644 --- a/arch/arm/configs/pxa3xx_defconfig +++ b/arch/arm/configs/pxa3xx_defconfig @@ -36,7 +36,6 @@ CONFIG_MTD_CONCAT=y CONFIG_MTD_CHAR=y
[PATCH] powerpc:Update Integrated Flash controller device tree bindings
Freescale's Integrated Flash controller (IFC) may have one or two interrupts. In case of single interrupt line, it will cover all IFC interrupts. Update this information in IFC device tree bindings Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Base upon git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git Branch next .../devicetree/bindings/powerpc/fsl/ifc.txt|9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt index 939a26d..88c7a26 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt @@ -12,9 +12,12 @@ Properties: - #size-cells : Either one or two, depending on how large each chipselect can be. - reg : Offset and length of the register set for the device -- interrupts : IFC has two interrupts. The first one is the common - interrupt(CM_EVTER_STAT), and second is the NAND interrupt - (NAND_EVTER_STAT). +- interrupts: IFC may have one or two interrupts. If two interrupt + specifiers are present, the first is the common + interrupt (CM_EVTER_STAT), and the second is the NAND + interrupt (NAND_EVTER_STAT). If there is only one, + that interrupt reports both types of event. + - ranges : Each range corresponds to a single chipselect, and covers the entire access window as configured. -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
On 07/26, Ananth N Mavinakayanahalli wrote: From: Ananth N Mavinakayanahalli ana...@in.ibm.com This is the port of uprobes to powerpc. Usage is similar to x86. I am just curious why this series was ignored by powerpc maintainers... Of course I can not review this code, I know nothing about powerpc, but the patches look simple/straightforward. Paul, Benjamin? Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe UPROBE_SWBP_INSN (at least) ? (I assume that emulate_step() can't handle this case but of course I do not understand arch/powerpc/lib/sstep.c) Note that uprobe_pre_sstep_notifier() sets utask-state = UTASK_BP_HIT without any checks. This doesn't look right if it was UTASK_SSTEP... But again, I do not know what powepc will actually do if we try to single-step over UPROBE_SWBP_INSN. Oleg. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
On 08/15/2012 03:57 AM, Jia Hongtao wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Some platforms like QEMU treat 0 as an invalid address for ISA IO base. So we make sure that ISA IO base will never be zero. By functionality this is equivalent to assgin the first pci bus detected as a primary bus. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Jia Hongtao b38...@freescale.com When did Ben post this? Suggesting a temporary workaround in an e-mail is *not* the same as posting a patch, and definitely not the same as providing a signed-off-by which AFAICT you forged. Don't do that. --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f75bd5..2a09aa5 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -734,7 +734,7 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose, hose-io_base_virt = ioremap(cpu_addr, size); /* Expect trouble if pci_addr is not 0 */ - if (primary) + if (primary || !isa_io_base) isa_io_base = (unsigned long)hose-io_base_virt; #endif /* CONFIG_PPC32 */ Didn't I already point out that this has problems when the primary bus is not the first to be probed? If your answer is that you fix that in a later patch, that breaks bisectability. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 2/3] powerpc/ge_imp3a: Add ISA node to PCI primary bus
On 08/15/2012 03:57 AM, Jia Hongtao wrote:
PCI primary bus will be determined by looking for ISA node in device tree.
Also for board ge_imp3a primary bus is the second PCI controller detected.
So we add ISA node to ge_imp3a's device tree to fit the new determination.
Adding ISA node to other boards' device tree is not necessary. The situation
that the first bus is primary have already been handled. Please refer to the
following patch:
powerpc/pci: Make sure ISA IO base is not zero
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/boot/dts/ge_imp3a.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ge_imp3a.dts
b/arch/powerpc/boot/dts/ge_imp3a.dts
index fefae41..aa2c4b5 100644
--- a/arch/powerpc/boot/dts/ge_imp3a.dts
+++ b/arch/powerpc/boot/dts/ge_imp3a.dts
@@ -248,6 +248,10 @@
0x100 0x0 0x0
0x100 0x0 0x0
0x0 0x1;
+
+ isa@1e {
+ device_type = isa;
+ };
};
};
};
I believe I already said it's not acceptable to break old device trees.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On 08/15/2012 03:57 AM, Jia Hongtao wrote:
We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function which is architectural better. Also It's convenient for
adding PM support for PCI controller in later patch.
We also change the way of determining primary bus for fitting platform
driver. Two previous patches are the preparation for this.
Now we registered pci controllers as platform devices. So we combine two
initialization code as one platform driver.
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
Changes for V7:
- Separate V6 to three functional independent patches.
arch/powerpc/platforms/85xx/common.c | 10 +++
arch/powerpc/platforms/85xx/corenet_ds.c | 31 +
arch/powerpc/platforms/85xx/ge_imp3a.c | 48 +
arch/powerpc/platforms/85xx/mpc8536_ds.c | 36 +-
arch/powerpc/platforms/85xx/mpc85xx_ads.c |9 +--
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 14 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 38 ++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 38 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 28 +++-
arch/powerpc/platforms/85xx/p1010rdb.c | 14 +
arch/powerpc/platforms/85xx/p1022_ds.c | 34 +-
arch/powerpc/platforms/85xx/p1022_rdk.c| 34 +-
arch/powerpc/platforms/85xx/p1023_rds.c|7 +--
arch/powerpc/platforms/85xx/p2041_rdb.c|2 +-
arch/powerpc/platforms/85xx/p3041_ds.c |2 +-
arch/powerpc/platforms/85xx/p4080_ds.c |2 +-
arch/powerpc/platforms/85xx/p5020_ds.c |2 +-
arch/powerpc/platforms/85xx/p5040_ds.c |2 +-
arch/powerpc/platforms/85xx/qemu_e500.c|3 +-
arch/powerpc/platforms/85xx/sbc8548.c | 19 +-
arch/powerpc/platforms/85xx/socrates.c | 11 +---
arch/powerpc/platforms/85xx/stx_gp3.c | 11 +---
arch/powerpc/platforms/85xx/tqm85xx.c | 21 +--
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 54 ++-
arch/powerpc/platforms/86xx/gef_ppc9a.c| 10 +--
arch/powerpc/platforms/86xx/gef_sbc310.c | 11 +---
arch/powerpc/platforms/86xx/gef_sbc610.c | 10 +--
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 19 +
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 40 +--
arch/powerpc/platforms/86xx/sbc8641d.c | 12 +---
arch/powerpc/sysdev/fsl_pci.c | 102
+---
arch/powerpc/sysdev/fsl_pci.h |9 ++-
drivers/edac/mpc85xx_edac.c| 43 +++-
33 files changed, 160 insertions(+), 566 deletions(-)
Please separate the core changes from the conversion of boards. The
easiest way to do this is to convert them to using fsl_pci_init() first.
Which boards have you tested on?
-void __devinit fsl_pci_init(void)
+/* Checkout if PCI contains ISA node */
+static int of_pci_has_isa(struct device_node *pci_node)
+{
+ struct device_node *np;
+ int ret = 0;
+
+ if (!pci_node)
+ return 0;
+
+ read_lock(devtree_lock);
+ np = pci_node-allnext;
+
+ /* Only scan the children of PCI node */
+ for (; np != pci_node-sibling; np = np-allnext) {
+ if (np-type (of_node_cmp(np-type, isa) == 0)
+ of_node_get(np)) {
+ ret = 1;
+ break;
+ }
+ }
+
+ of_node_put(pci_node);
+ read_unlock(devtree_lock);
+
+ return ret;
+}
Didn't Kumar already say to leave this alone? Do you think you'll get
your patches merged by eternal stubornness?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On 08/15/2012 04:22 AM, Jia Hongtao-B38951 wrote: -Original Message- From: Wood Scott-B07421 Sent: Saturday, August 11, 2012 12:00 AM To: Jia Hongtao-B38951 Cc: Gala Kumar-B11780; Wood Scott-B07421; Li Yang-R58472; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code On 08/10/2012 03:47 AM, Jia Hongtao-B38951 wrote: -Original Message- From: Gala Kumar-B11780 Sent: Thursday, August 09, 2012 3:04 AM To: Wood Scott-B07421 Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code As I explained before, this has to be done globally, not from the probe function, so we can assign a default primary bus if there isn't any ISA. There are bugs in the Linux PPC PCI code relating to not having any primary bus. -Scott In my way of searching ISA you can also assign a default primary bus in board specific files. That was meant for when the board file had an alternate way of searching for the primary bus (e.g. look for i8259), not as a replacement for the mechanism that guarantees there's a primary bus. You are causing a regression in the qemu_e500.c platform. Can we fix the qemu device tree to address the problem if we do make it a rule to use the ISA node to indicate the primary bus? No. There is no ISA, and we're not going to lie and say there is. But we can assign a default primary for qemu. Not in the device tree. What other mechanism do you propose? And why do you want to fix it only for QEMU and not other boards, where things happen to work but not as designed? Kumar, can you speak up here as maintainer so we can stop going back and forth endlessly? I'd rather we stick with the code that works for this purpose at this point. That would be Scott's current upstream code. Lets get the other aspects of this patchset closed (SWIOTLB, conversion to platform driver, PM, etc.). The primary bus code Scott wrote does NOT need to change at this point. - k I just submitted a new version of PCI patch in which I improve the primary part. The reasons I want to change the way of primary assignment listed below: 1. This approach is functionally equivalent to the Scott's code. In my approach there might be no primary assigned but it fixed by quick fix introduced by Ben. Please refer to this link: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html You might want to get Ben's input as to whether he actually wants to see that quick fix applied. 2. Scott's and my way could not handle the situation that the primary is not the first PCI bus detected. I found that only ge_imp3a got this problem so I fixed it by adding ISA node to its device tree. By adding this I think the solution is logically completed. How did my approach not handle this case? As I said, ge_imp3a platform code needs to set fsl_pci_primary manually before PCI init runs. Adding a node to the device tree is not the answer, since that will break compatibility with old device trees. I assume that kernel image and dtb image are from the same tree. That's a bad assumption. Device trees get forked off for custom boards, modified by firmware, generated by firmware, etc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 0/3] tpm: Add new vTPM device driver for PPC64
On Tue, Aug 14, 2012 at 06:23:58PM -0500, Ashley Lai wrote: Change log V3: - Replaced TPM_NO_EVENT_LOG macro with stubs - Removed tpm_noeventlog.c file - Called of_node_put() before return in tpm_of.c Change log V2: - Removed unnecessary tpm_bios_log_setup and tpm_bios_log_teardown functions in tpm_eventlog.h (patch 3/3). - Added more descriptions on vTPM (patch 1/3). These patches add support for IBM vTPM for PPC64. This new device driver works on firmware that supports vTPM (firmware release 740 or higher). Tested on Power7+ system with firmware level ZM770_001. Applied to Kent Yoder tree at: https://github.com/shpedoikal/linux/tree/v3.6-rc1-tpmdd-staging Thanks Ashley, I've added the patches to that tree. Kent Ashley Lai (3): drivers/char/tpm: Add new device driver to support IBM vTPM PPC64: Add support for instantiating SML from Open Firmware drivers/char/tpm: Add securityfs support for event log arch/powerpc/kernel/prom_init.c | 62 drivers/char/tpm/Kconfig|8 + drivers/char/tpm/Makefile |6 + drivers/char/tpm/tpm.h | 13 +- drivers/char/tpm/tpm_eventlog.h | 15 + drivers/char/tpm/tpm_ibmvtpm.c | 749 +++ drivers/char/tpm/tpm_ibmvtpm.h | 83 + drivers/char/tpm/tpm_of.c | 73 8 files changed, 997 insertions(+), 12 deletions(-) create mode 100644 drivers/char/tpm/tpm_ibmvtpm.c create mode 100644 drivers/char/tpm/tpm_ibmvtpm.h create mode 100644 drivers/char/tpm/tpm_of.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rapidio/tsi721: fix inbound doorbell interrupt handling
Make sure that there is no doorbell messages left behind due to disabled interrupts during inbound doorbell processing. The most common case for this bug is loss of rionet JOIN messages in systems with three or more rionet participants and MSI or MSI-X enabled. As result, requests for packet transfers may finish with destination unreachable error message. This patch is applicable to kernel versions starting from v3.2. Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com Cc: Matt Porter mpor...@kernel.crashing.org --- drivers/rapidio/devices/tsi721.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c index 722246c..c0d6a04 100644 --- a/drivers/rapidio/devices/tsi721.c +++ b/drivers/rapidio/devices/tsi721.c @@ -435,6 +435,9 @@ static void tsi721_db_dpc(struct work_struct *work) info %4.4x\n, DBELL_SID(idb.bytes), DBELL_TID(idb.bytes), DBELL_INF(idb.bytes)); } + + wr_ptr = ioread32(priv-regs + + TSI721_IDQ_WP(IDB_QUEUE)) % IDB_QSIZE; } iowrite32(rd_ptr (IDB_QSIZE - 1), @@ -445,6 +448,10 @@ static void tsi721_db_dpc(struct work_struct *work) regval |= TSI721_SR_CHINT_IDBQRCV; iowrite32(regval, priv-regs + TSI721_SR_CHINTE(IDB_QUEUE)); + + wr_ptr = ioread32(priv-regs + TSI721_IDQ_WP(IDB_QUEUE)) % IDB_QSIZE; + if (wr_ptr != rd_ptr) + schedule_work(priv-idb_work); } /** -- 1.7.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rapidio/tsi721: fix unused variable compiler warning
Fix unused variable compiler warning when built with CONFIG_RAPIDIO_DEBUG
option off.
This patch is applicable to kernel versions starting from v3.2
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Matt Porter mpor...@kernel.crashing.org
---
drivers/rapidio/devices/tsi721.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index c0d6a04..5d44252 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2219,7 +2219,7 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct tsi721_device *priv;
- int i, cap;
+ int cap;
int err;
u32 regval;
@@ -2239,12 +2239,15 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
priv-pdev = pdev;
#ifdef DEBUG
+ {
+ int i;
for (i = 0; i = PCI_STD_RESOURCE_END; i++) {
dev_dbg(pdev-dev, res[%d] @ 0x%llx (0x%lx, 0x%lx)\n,
i, (unsigned long long)pci_resource_start(pdev, i),
(unsigned long)pci_resource_len(pdev, i),
pci_resource_flags(pdev, i));
}
+ }
#endif
/*
* Verify BAR configuration
--
1.7.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 2/3] powerpc/ge_imp3a: Add ISA node to PCI primary bus
On Aug 15, 2012, at 12:31 PM, Scott Wood wrote:
On 08/15/2012 03:57 AM, Jia Hongtao wrote:
PCI primary bus will be determined by looking for ISA node in device tree.
Also for board ge_imp3a primary bus is the second PCI controller detected.
So we add ISA node to ge_imp3a's device tree to fit the new determination.
Adding ISA node to other boards' device tree is not necessary. The situation
that the first bus is primary have already been handled. Please refer to the
following patch:
powerpc/pci: Make sure ISA IO base is not zero
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/boot/dts/ge_imp3a.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ge_imp3a.dts
b/arch/powerpc/boot/dts/ge_imp3a.dts
index fefae41..aa2c4b5 100644
--- a/arch/powerpc/boot/dts/ge_imp3a.dts
+++ b/arch/powerpc/boot/dts/ge_imp3a.dts
@@ -248,6 +248,10 @@
0x100 0x0 0x0
0x100 0x0 0x0
0x0 0x1;
+
+isa@1e {
+device_type = isa;
+};
};
};
};
I believe I already said it's not acceptable to break old device trees.
-Scott
I agree w/Scott this is NOT an acceptable solution, both because of old device
tree and its just wrong to list ISA if it doesn't exist in the device.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 2/3] powerpc/ge_imp3a: Add ISA node to PCI primary bus
On 08/15/2012 04:01 PM, Kumar Gala wrote:
On Aug 15, 2012, at 12:31 PM, Scott Wood wrote:
On 08/15/2012 03:57 AM, Jia Hongtao wrote:
PCI primary bus will be determined by looking for ISA node in device tree.
Also for board ge_imp3a primary bus is the second PCI controller detected.
So we add ISA node to ge_imp3a's device tree to fit the new determination.
Adding ISA node to other boards' device tree is not necessary. The situation
that the first bus is primary have already been handled. Please refer to the
following patch:
powerpc/pci: Make sure ISA IO base is not zero
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/boot/dts/ge_imp3a.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ge_imp3a.dts
b/arch/powerpc/boot/dts/ge_imp3a.dts
index fefae41..aa2c4b5 100644
--- a/arch/powerpc/boot/dts/ge_imp3a.dts
+++ b/arch/powerpc/boot/dts/ge_imp3a.dts
@@ -248,6 +248,10 @@
0x100 0x0 0x0
0x100 0x0 0x0
0x0 0x1;
+
+ isa@1e {
+ device_type = isa;
+ };
};
};
};
I believe I already said it's not acceptable to break old device trees.
-Scott
I agree w/Scott this is NOT an acceptable solution, both because of
old device tree and its just wrong to list ISA if it doesn't exist in
the device.
If there isn't actually ISA here, why do we care which bus is primary?
Other than the lack of hardware to sanity test the change on...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
GE IMP3a
Martyn, Do you know why ge_imp3a.c has 0x9000 as the 'primary' PCIe bus on the board? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
On Wed, 2012-08-15 at 12:29 -0500, Scott Wood wrote: --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f75bd5..2a09aa5 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -734,7 +734,7 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose, hose-io_base_virt = ioremap(cpu_addr, size); /* Expect trouble if pci_addr is not 0 */ - if (primary) + if (primary || !isa_io_base) isa_io_base = (unsigned long)hose-io_base_virt; #endif /* CONFIG_PPC32 */ Didn't I already point out that this has problems when the primary bus is not the first to be probed? If your answer is that you fix that in a later patch, that breaks bisectability. Is it though ? ie, we will override it with the real primary in the above test, so it will only very temporarily be set to the wrong bus no ? IE, the test will still trip on the actual primary if there's one. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Wed, 2012-08-15 at 19:53 +0200, Jan Engelhardt wrote: About a week ago, an XServe G5 of mine started powering off more or less randomly (after 1 hour, chances were good it for it to occur). A problematic UPS has already been cut from the loop, and today I cleaned the machine inside out with pressurized air. So far it runs, for now at least, with a load = 2.0, but I am keeping an eye on whether this is a thermal issue. To that end, I wanted to obtain some statistics. Despite sensors-detect(8) loads lm87.ko for me, running sensors(1) shows no sensors. Oddly enough, I found a kfand process running that seems to stem from therm_pm72.ko, which brings me to the sysfs files. Is there a reason sensors(1) is not supported for Rackmac3,1? Certain sysfs files have a value with an unknown unit. current is likely in Ampere, temperature must be in Celsius (because there's no way the server room is 54°F=12°C cold). Is there a way to obtain the trip points for the hardware? BTW. There's a new windfarm driver for these in recent kernels... Appart from that, the trip points are coming from a calibration EEPROM, you may want to tweak the driver to warn a bit earlier or that sort of things ? (Or just to print more things out ?) Cheers, Ben. $ cd /sys/devices/temperature; grep '' *; backside_fan_pwm:32 backside_temperature:54.000 cpu0_current:34.423 cpu0_exhaust_fan_rpm:5340 cpu0_intake_fan_rpm:5340 cpu0_temperature:72.889 cpu0_voltage:1.252 cpu1_current:34.179 cpu1_exhaust_fan_rpm:4584 cpu1_intake_fan_rpm:4584 cpu1_temperature:68.526 cpu1_voltage:1.259 dimms_temperature:53.000 grep: driver: Er en filkatalog modalias:platform:temperature grep: power: Er en filkatalog slots_fan_pwm:20 slots_temperature:38.500 grep: subsystem: Er en filkatalog uevent:DRIVER=temperature uevent:OF_NAME=fan uevent:OF_FULLNAME=/u3@0,f800/i2c@f8001000/fan@15e uevent:OF_TYPE=fcu uevent:OF_COMPATIBLE_0=fcu uevent:OF_COMPATIBLE_N=1 uevent:MODALIAS=of:NfanTfcuCfcu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
BTW... On a somewhat related note ... if you happen to have a spare Xserve G5 PSU I'm interested :-) Mine died (well I -think- it's the PSU ... it just won't power up) which means I can't test on these things anymore (the new Windfarm RackMac driver is totally untested for example). Cheers, Ben. On Wed, 2012-08-15 at 19:53 +0200, Jan Engelhardt wrote: About a week ago, an XServe G5 of mine started powering off more or less randomly (after 1 hour, chances were good it for it to occur). A problematic UPS has already been cut from the loop, and today I cleaned the machine inside out with pressurized air. So far it runs, for now at least, with a load = 2.0, but I am keeping an eye on whether this is a thermal issue. To that end, I wanted to obtain some statistics. Despite sensors-detect(8) loads lm87.ko for me, running sensors(1) shows no sensors. Oddly enough, I found a kfand process running that seems to stem from therm_pm72.ko, which brings me to the sysfs files. Is there a reason sensors(1) is not supported for Rackmac3,1? Certain sysfs files have a value with an unknown unit. current is likely in Ampere, temperature must be in Celsius (because there's no way the server room is 54°F=12°C cold). Is there a way to obtain the trip points for the hardware? $ cd /sys/devices/temperature; grep '' *; backside_fan_pwm:32 backside_temperature:54.000 cpu0_current:34.423 cpu0_exhaust_fan_rpm:5340 cpu0_intake_fan_rpm:5340 cpu0_temperature:72.889 cpu0_voltage:1.252 cpu1_current:34.179 cpu1_exhaust_fan_rpm:4584 cpu1_intake_fan_rpm:4584 cpu1_temperature:68.526 cpu1_voltage:1.259 dimms_temperature:53.000 grep: driver: Er en filkatalog modalias:platform:temperature grep: power: Er en filkatalog slots_fan_pwm:20 slots_temperature:38.500 grep: subsystem: Er en filkatalog uevent:DRIVER=temperature uevent:OF_NAME=fan uevent:OF_FULLNAME=/u3@0,f800/i2c@f8001000/fan@15e uevent:OF_TYPE=fcu uevent:OF_COMPATIBLE_0=fcu uevent:OF_COMPATIBLE_N=1 uevent:MODALIAS=of:NfanTfcuCfcu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
therm_pm72 units, interface
About a week ago, an XServe G5 of mine started powering off more or less randomly (after 1 hour, chances were good it for it to occur). A problematic UPS has already been cut from the loop, and today I cleaned the machine inside out with pressurized air. So far it runs, for now at least, with a load = 2.0, but I am keeping an eye on whether this is a thermal issue. To that end, I wanted to obtain some statistics. Despite sensors-detect(8) loads lm87.ko for me, running sensors(1) shows no sensors. Oddly enough, I found a kfand process running that seems to stem from therm_pm72.ko, which brings me to the sysfs files. Is there a reason sensors(1) is not supported for Rackmac3,1? Certain sysfs files have a value with an unknown unit. current is likely in Ampere, temperature must be in Celsius (because there's no way the server room is 54°F=12°C cold). Is there a way to obtain the trip points for the hardware? $ cd /sys/devices/temperature; grep '' *; backside_fan_pwm:32 backside_temperature:54.000 cpu0_current:34.423 cpu0_exhaust_fan_rpm:5340 cpu0_intake_fan_rpm:5340 cpu0_temperature:72.889 cpu0_voltage:1.252 cpu1_current:34.179 cpu1_exhaust_fan_rpm:4584 cpu1_intake_fan_rpm:4584 cpu1_temperature:68.526 cpu1_voltage:1.259 dimms_temperature:53.000 grep: driver: Er en filkatalog modalias:platform:temperature grep: power: Er en filkatalog slots_fan_pwm:20 slots_temperature:38.500 grep: subsystem: Er en filkatalog uevent:DRIVER=temperature uevent:OF_NAME=fan uevent:OF_FULLNAME=/u3@0,f800/i2c@f8001000/fan@15e uevent:OF_TYPE=fcu uevent:OF_COMPATIBLE_0=fcu uevent:OF_COMPATIBLE_N=1 uevent:MODALIAS=of:NfanTfcuCfcu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote: On 07/26, Ananth N Mavinakayanahalli wrote: From: Ananth N Mavinakayanahalli ana...@in.ibm.com This is the port of uprobes to powerpc. Usage is similar to x86. I am just curious why this series was ignored by powerpc maintainers... Because it arrived too late for the previous merge window considering my limited bandwidth for reviewing things and that nobody else seems to have reviewed it :-) It's still on track for the next one, and I'm hoping to dedicate most of next week going through patches doing a powerpc -next. Of course I can not review this code, I know nothing about powerpc, but the patches look simple/straightforward. Paul, Benjamin? Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe UPROBE_SWBP_INSN (at least) ? (I assume that emulate_step() can't handle this case but of course I do not understand arch/powerpc/lib/sstep.c) Note that uprobe_pre_sstep_notifier() sets utask-state = UTASK_BP_HIT without any checks. This doesn't look right if it was UTASK_SSTEP... But again, I do not know what powepc will actually do if we try to single-step over UPROBE_SWBP_INSN. Ananth ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
On 08/15/2012 04:32 PM, Benjamin Herrenschmidt wrote: On Wed, 2012-08-15 at 12:29 -0500, Scott Wood wrote: --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f75bd5..2a09aa5 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -734,7 +734,7 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose, hose-io_base_virt = ioremap(cpu_addr, size); /* Expect trouble if pci_addr is not 0 */ - if (primary) + if (primary || !isa_io_base) isa_io_base = (unsigned long)hose-io_base_virt; #endif /* CONFIG_PPC32 */ Didn't I already point out that this has problems when the primary bus is not the first to be probed? If your answer is that you fix that in a later patch, that breaks bisectability. Is it though ? ie, we will override it with the real primary in the above test, so it will only very temporarily be set to the wrong bus no ? IE, the test will still trip on the actual primary if there's one Is there no lasting remnant of that temporary wrong isa_io_base? We won't have I/O resources that were calculated relative to that, which stop working once isa_io_base changes? Or does that happen later, after this function has been called on all buses (and would that continue to be the case if we change the PCI bus to a platform device)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
On Wed, 2012-08-15 at 16:57 -0500, Scott Wood wrote: Is there no lasting remnant of that temporary wrong isa_io_base? We won't have I/O resources that were calculated relative to that, which stop working once isa_io_base changes? Or does that happen later, after this function has been called on all buses (and would that continue to be the case if we change the PCI bus to a platform device)? If you continue creating your PCI busses all at once early on you'll be fine. The platform device business is going to break that (and other things as well btw, such as pci_final_fixup). Maybe it's time to contemplate doing something more like ppc64 and reserve a piece of virtual address space (I know there isn't much, so make it 64k per bus max) and just map the busses in there with the first 64k being reserved for the ISA stuff if it exists ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
-Original Message- From: Wood Scott-B07421 Sent: Thursday, August 16, 2012 1:29 AM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; b...@kernel.crashing.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero On 08/15/2012 03:57 AM, Jia Hongtao wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Some platforms like QEMU treat 0 as an invalid address for ISA IO base. So we make sure that ISA IO base will never be zero. By functionality this is equivalent to assgin the first pci bus detected as a primary bus. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Jia Hongtao b38...@freescale.com When did Ben post this? Suggesting a temporary workaround in an e-mail is *not* the same as posting a patch, and definitely not the same as providing a signed-off-by which AFAICT you forged. Don't do that. --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f75bd5..2a09aa5 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -734,7 +734,7 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose, hose-io_base_virt = ioremap(cpu_addr, size); /* Expect trouble if pci_addr is not 0 */ - if (primary) + if (primary || !isa_io_base) isa_io_base = (unsigned long)hose-io_base_virt; #endif /* CONFIG_PPC32 */ Didn't I already point out that this has problems when the primary bus is not the first to be probed? If your answer is that you fix that in a later patch, that breaks bisectability. -Scott Sorry, my answer is not that I fix that in later patch. My answer is, without this patch there is also problem with non-first-primary. That is to say the bisectability problem has been already there. The problem is not brought by this patch. - Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Thursday, August 16, 2012 6:43 AM To: Wood Scott-B07421 Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH V7 1/3] powerpc/pci: Make sure ISA IO base is not zero On Wed, 2012-08-15 at 16:57 -0500, Scott Wood wrote: Is there no lasting remnant of that temporary wrong isa_io_base? We won't have I/O resources that were calculated relative to that, which stop working once isa_io_base changes? Or does that happen later, after this function has been called on all buses (and would that continue to be the case if we change the PCI bus to a platform device)? If you continue creating your PCI busses all at once early on you'll be fine. The platform device business is going to break that (and other things as well btw, such as pci_final_fixup). I have already done some investigation and the sequence of fixup (including early, header, final) will not be changed in platform driver. We register and init PCI controllers as platform devices at arch_initcall stage and PCI scanning (pcibios_init) is at subsys_initcall stage in which early and header fixup will be done in right sequence. The final fixup will be start at rootfs_initcall stage which is later than early and header fixup. - Hongtao. Maybe it's time to contemplate doing something more like ppc64 and reserve a piece of virtual address space (I know there isn't much, so make it 64k per bus max) and just map the busses in there with the first 64k being reserved for the ISA stuff if it exists ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx:Add new ext fields to Integrated FLash Controller
Freescale's Integrated Flash controller(IFC) v1.1.0 supports 40 bit
address bus width.
In case more than 32 bit address is used, the EXT registers should be set.
Add support of ext registers.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Base upon git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
Branch next
arch/powerpc/include/asm/fsl_ifc.h | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_ifc.h
b/arch/powerpc/include/asm/fsl_ifc.h
index b955012..b8a4b9b 100644
--- a/arch/powerpc/include/asm/fsl_ifc.h
+++ b/arch/powerpc/include/asm/fsl_ifc.h
@@ -768,22 +768,24 @@ struct fsl_ifc_gpcm {
*/
struct fsl_ifc_regs {
__be32 ifc_rev;
- u32 res1[0x3];
+ u32 res1[0x2];
struct {
+ __be32 cspr_ext;
__be32 cspr;
- u32 res2[0x2];
+ u32 res2;
} cspr_cs[FSL_IFC_BANK_COUNT];
- u32 res3[0x18];
+ u32 res3[0x19];
struct {
__be32 amask;
u32 res4[0x2];
} amask_cs[FSL_IFC_BANK_COUNT];
- u32 res5[0x18];
+ u32 res5[0x17];
struct {
+ __be32 csor_ext;
__be32 csor;
- u32 res6[0x2];
+ u32 res6;
} csor_cs[FSL_IFC_BANK_COUNT];
- u32 res7[0x18];
+ u32 res7[0x19];
struct {
__be32 ftim[4];
u32 res8[0x8];
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc/perf: hw breakpoints return ENOSPC
Hi,
I've been trying to get hardware breakpoints with perf to work on POWER7
but I'm getting the following:
% perf record -e mem:0x1000 true
Error: sys_perf_event_open() syscall returned with 28 (No space left on
device). /bin/dmesg may provide additional information.
Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
true: Terminated
(FWIW adding -a and it works fine)
Debugging it seems that __reserve_bp_slot() is returning ENOSPC because
it thinks there are no free breakpoint slots on this CPU.
I have a 2 CPUs, so perf userspace is doing two perf_event_open syscalls
to add a counter to each CPU [1]. The first syscall succeeds but the
second is failing.
On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
despite there being no breakpoint on this CPU. This is because the call
the task_bp_pinned, checks all CPUs, rather than just the current CPU.
POWER7 only has one hardware breakpoint per CPU (ie. HBP_NUM=1), so we
return ENOSPC.
The following patch fixes this by checking the associated CPU for each
breakpoint in task_bp_pinned. I'm not familiar with this code, so it's
provided as a reference to the above issue.
Mikey
1. not sure why it doesn't just do one syscall and specify all CPUs, but
that's another issue. Using two syscalls should work.
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index bb38c4d..e092daa 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -111,14 +111,16 @@ static unsigned int max_task_bp_pinned(int cpu, enum
bp_type_idx type)
* Count the number of breakpoints of the same type and same task.
* The given event must be not on the list.
*/
-static int task_bp_pinned(struct perf_event *bp, enum bp_type_idx type)
+static int task_bp_pinned(int cpu, struct perf_event *bp, enum bp_type_idx
type)
{
struct task_struct *tsk = bp-hw.bp_target;
struct perf_event *iter;
int count = 0;
list_for_each_entry(iter, bp_task_head, hw.bp_list) {
- if (iter-hw.bp_target == tsk find_slot_idx(iter) == type)
+ if (iter-hw.bp_target == tsk
+ find_slot_idx(iter) == type
+ cpu == iter-cpu)
count += hw_breakpoint_weight(iter);
}
@@ -141,7 +143,7 @@ fetch_bp_busy_slots(struct bp_busy_slots *slots, struct
perf_event *bp,
if (!tsk)
slots-pinned += max_task_bp_pinned(cpu, type);
else
- slots-pinned += task_bp_pinned(bp, type);
+ slots-pinned += task_bp_pinned(cpu, bp, type);
slots-flexible = per_cpu(nr_bp_flexible[type], cpu);
return;
@@ -154,7 +156,7 @@ fetch_bp_busy_slots(struct bp_busy_slots *slots, struct
perf_event *bp,
if (!tsk)
nr += max_task_bp_pinned(cpu, type);
else
- nr += task_bp_pinned(bp, type);
+ nr += task_bp_pinned(cpu, bp, type);
if (nr slots-pinned)
slots-pinned = nr;
@@ -188,7 +190,7 @@ static void toggle_bp_task_slot(struct perf_event *bp, int
cpu, bool enable,
int old_idx = 0;
int idx = 0;
- old_count = task_bp_pinned(bp, type);
+ old_count = task_bp_pinned(cpu, bp, type);
old_idx = old_count - 1;
idx = old_idx + weight;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote: On 07/26, Ananth N Mavinakayanahalli wrote: From: Ananth N Mavinakayanahalli ana...@in.ibm.com This is the port of uprobes to powerpc. Usage is similar to x86. I am just curious why this series was ignored by powerpc maintainers... Because it arrived too late for the previous merge window considering my limited bandwidth for reviewing things and that nobody else seems to have reviewed it :-) It's still on track for the next one, and I'm hoping to dedicate most of next week going through patches doing a powerpc -next. Thanks Ben! Of course I can not review this code, I know nothing about powerpc, but the patches look simple/straightforward. Paul, Benjamin? Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe UPROBE_SWBP_INSN (at least) ? (I assume that emulate_step() can't handle this case but of course I do not understand arch/powerpc/lib/sstep.c) Note that uprobe_pre_sstep_notifier() sets utask-state = UTASK_BP_HIT without any checks. This doesn't look right if it was UTASK_SSTEP... But again, I do not know what powepc will actually do if we try to single-step over UPROBE_SWBP_INSN. Ananth ? set_swbp() will return -EEXIST to install_breakpoint if we are trying to put a breakpoint on UPROBE_SWBP_INSN. So, the arch agnostic code itself takes care of this case... or am I missing something? However, I see that we need a powerpc specific is_swbp_insn() implementation since we will have to take care of all the trap variants. I will need to update the patches based on changes being made by Oleg and Sebastien for the single-step issues. Will incorporate the powerpc specific is_swbp_insn() change along with the changes required for the single-step part and send out the next version. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
