Re: [PATCH] powerpc: change the Book-E watchdog driver default timeout into a Kconfig option
On Oct 13, 2010, at 2:19 PM, Timur Tabi wrote: The PowerPC Book-E watchdog driver (booke_wdt.c) defines a default timeout value in the code based on whether it's a Freescale Book-E part of not. Instead of having hard-coded values in the driver, make it a Kconfig option. As newer chips gets faster, the current default values become less appropriate, since the timeout sometimes occurs before the kernel finishes booting. Making the value a Kconfig option allows BSPs to configure a new value with requiring the wdt_period command-line parameter to be set. Signed-off-by: Timur Tabi ti...@freescale.com --- drivers/watchdog/Kconfig | 17 + drivers/watchdog/booke_wdt.c |8 +--- 2 files changed, 18 insertions(+), 7 deletions(-) applied to next, fixed commit message. Also, in general I believe commit messages should be about 75 columns so they dont wrap if you do a git log in an 80 column terminal. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] fsl_rio: Add comments for sRIO registers.
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: Add some comments to make sRIO registers map better readable. Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c | 65 + 1 files changed, 40 insertions(+), 25 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC + /* Ensure that RFXE is set on e500 v1/v2 */ + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); +#endif /* !PPC_E500MC */ +#endif /* E500 */ I've never really been happy with this code. We really should set HID1_RFXE in cpu_setup_fsl_booke.S instead. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 14, 2010, at 1:14 AM, Kumar Gala wrote: On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif -/* Ensure that RFXE is set */ -mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC +/* Ensure that RFXE is set on e500 v1/v2 */ +mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); +#endif /* !PPC_E500MC */ +#endif /* E500 */ I've never really been happy with this code. We really should set HID1_RFXE in cpu_setup_fsl_booke.S instead. We should also change this so we just call fsl_rio_mcheck_exception() from machine_check_e500 machine_check_e500mc and get rid of this ppc_md.machine_check_exception manipulation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch (updated)
[ should fix the compile issue and pulled in 2 other minor patches ] The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876: powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next Harninder Rai (1): powerpc/85xx: add cache-sram support Ilya Yanok (1): powerpc/mpc83xx: Support for MPC8308 P1M board Kumar Gala (10): powerpc/fsl-pci: Fix MSI support on 83xx platforms powerpc/mpc8xxx_gpio: Add support for 'qoriq-gpio' controllers powerpc/fsl-booke: Add PCI device ids for P2040/P3041/P5010/P5020 QoirQ chips powerpc/fsl-booke: Add p3041 DS board support powerpc: Fix compile error with paca code on ppc64e powerpc/fsl-booke: Add support for FSL 64-bit e5500 core powerpc/fsl-booke: Add support for FSL Arch v1.0 MMU in setup_page_sizes powerpc/fsl-booke64: Use TLB CAMs to cover linear mapping on FSL 64-bit chips powerpc/fsl-booke: Add p5020 DS board support powerpc/fsl-booke: Add e55xx (64-bit) smp defconfig Matthew McClintock (6): powerpc/kexec: make masking/disabling interrupts generic powerpc/85xx: Remove call to mpic_teardown_this_cpu in kexec powerpc/85xx: Minor fixups for kexec on 85xx powerpc/85xx: flush dcache before resetting cores powerpc/fsl_soc: Search all global-utilities nodes for rstccr powerpc/fsl_booke: Add support to boot from core other than 0 Paul Gortmaker (1): powerpc: Fix invalid page flags in create TLB CAM path for PTE_64BIT Scott Wood (1): oprofile/fsl emb: Don't set MSR[PMM] until after clearing the interrupt. Shaohui Xie (1): fsl_rio: Add comments for sRIO registers. Timur Tabi (5): powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols powerpc/watchdog: Allow the Book-E driver to be compiled as a module powerpc/p1022: Add probing for individual DMA channels powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board powerpc/watchdog: Make default timeout for Book-E watchdog a Kconfig option arch/powerpc/boot/dts/mpc8308_p1m.dts | 332 arch/powerpc/boot/dts/p1022ds.dts | 11 + arch/powerpc/configs/e55xx_smp_defconfig | 84 ++ arch/powerpc/configs/ppc64e_defconfig |4 +- arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 arch/powerpc/include/asm/kexec.h |1 + arch/powerpc/include/asm/mmu-book3e.h | 15 + arch/powerpc/include/asm/pte-common.h |7 + arch/powerpc/kernel/Makefile |4 +- arch/powerpc/kernel/asm-offsets.c |4 +- arch/powerpc/kernel/cpu_setup_fsl_booke.S | 15 + arch/powerpc/kernel/cputable.c | 28 ++- arch/powerpc/kernel/crash.c| 13 +- arch/powerpc/kernel/head_fsl_booke.S | 10 +- arch/powerpc/kernel/machine_kexec.c| 24 ++ arch/powerpc/kernel/machine_kexec_32.c |4 + arch/powerpc/kernel/paca.c |2 +- arch/powerpc/kernel/setup_32.c |2 +- arch/powerpc/kernel/time.c |3 +- arch/powerpc/kernel/traps.c|5 + arch/powerpc/mm/Makefile |2 +- arch/powerpc/mm/fsl_booke_mmu.c| 15 +- arch/powerpc/mm/mmu_decl.h |5 +- arch/powerpc/mm/tlb_nohash.c | 56 - arch/powerpc/mm/tlb_nohash_low.S |2 +- arch/powerpc/oprofile/op_model_fsl_emb.c | 15 +- arch/powerpc/platforms/83xx/Kconfig|4 +- arch/powerpc/platforms/83xx/mpc830x_rdb.c |3 +- arch/powerpc/platforms/85xx/Kconfig| 28 ++- arch/powerpc/platforms/85xx/Makefile |2 + arch/powerpc/platforms/85xx/p1022_ds.c |2 + arch/powerpc/platforms/85xx/p3041_ds.c | 64 + arch/powerpc/platforms/85xx/p5020_ds.c | 69 + arch/powerpc/platforms/85xx/smp.c | 76 +- arch/powerpc/platforms/Kconfig.cputype |8 +- arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 101 +++ arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 159 +++ arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 231 arch/powerpc/sysdev/fsl_msi.c |9 +- arch/powerpc/sysdev/fsl_pci.c | 60 - arch/powerpc/sysdev/fsl_pci.h |1 + arch/powerpc/sysdev/fsl_rio.c | 65 +++-- arch/powerpc/sysdev/fsl_soc.c | 20 +- arch/powerpc/sysdev/mpc8xxx_gpio.c |3 + drivers/watchdog/Kconfig | 22 ++- drivers/watchdog/booke_wdt.c | 47 +++-
RE: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
-Original Message-
From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
Sent: Monday, September 20, 2010 23:37 PM
To: Zang Roy-R61911
Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
B11780; linuxppc-...@ozlabs.org
Subject: Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common
to elbc devices
On Fri, Sep 17, 2010 at 03:01:07PM +0800, Roy Zang wrote:
[snip]
int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32
mar)
{
int ret = 0;
unsigned long flags;
[...]
+static int __devinit fsl_lbc_ctrl_probe(struct platform_device *dev)
+{
+ int ret;
+
+ if (!dev-dev.of_node) {
+ dev_err(dev-dev, Device OF-Node is NULL);
+ return -EFAULT;
+ }
+ fsl_lbc_ctrl_dev = kzalloc(sizeof(*fsl_lbc_ctrl_dev), GFP_KERNEL);
Btw, the code in the NAND driver checks for !fsl_lbc_ctrl_dev.
So it might make sense to assign the global variable after the
struct is fully initialized.
What struct?
assign the global variable in nand driver?
I'd prefer init it in the lbc code.
There may be other lbc device, who will use this global variable.
+ if (!fsl_lbc_ctrl_dev)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev-dev, fsl_lbc_ctrl_dev);
+
+ spin_lock_init(fsl_lbc_ctrl_dev-lock);
+ init_waitqueue_head(fsl_lbc_ctrl_dev-irq_wait);
+
+ fsl_lbc_ctrl_dev-regs = of_iomap(dev-dev.of_node, 0);
+ if (!fsl_lbc_ctrl_dev-regs) {
+ dev_err(dev-dev, failed to get memory region\n);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ fsl_lbc_ctrl_dev-irq = irq_of_parse_and_map(dev-dev.of_node, 0);
+ if (fsl_lbc_ctrl_dev-irq == NO_IRQ) {
+ dev_err(dev-dev, failed to get irq resource\n);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ fsl_lbc_ctrl_dev-dev = dev-dev;
+
+ ret = fsl_lbc_ctrl_init(fsl_lbc_ctrl_dev);
+ if (ret 0)
+ goto err;
+
+ ret = request_irq(fsl_lbc_ctrl_dev-irq, fsl_lbc_ctrl_irq, 0,
+ fsl-lbc, fsl_lbc_ctrl_dev);
+ if (ret != 0) {
+ dev_err(dev-dev, failed to install irq (%d)\n,
+ fsl_lbc_ctrl_dev-irq);
+ ret = fsl_lbc_ctrl_dev-irq;
+ goto err;
+ }
+
+ return 0;
+
+err:
+ iounmap(fsl_lbc_ctrl_dev-regs);
+ kfree(fsl_lbc_ctrl_dev);
+ return ret;
+}
+
+static const struct of_device_id fsl_lbc_match[] = {
#include linux/mod_devicetable.h is needed for this.
Plus, I think the patch is not runtime bisectable (i.e. you
now do request_irq() here, but not removing it from the nand
driver, so nand will fail to probe).
Nand driver does not need to request irq. It will use the irq requested by lbc.
remember, other lbc device may also need to use this registered irq.
It should not be removed in nand driver.
Thanks.
Roy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif -/* Ensure that RFXE is set */ -mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC +/* Ensure that RFXE is set on e500 v1/v2 */ +mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /* +!PPC_E500MC */ #endif /* E500 */ I've never really been happy with this code. We really should set HID1_RFXE in cpu_setup_fsl_booke.S instead. But this bit is not recommended to be set unless necessary. And it is only required by SRIO for now. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/fsl: 85xx: add cache-sram support
Oct 13, 2010 at 8:00 PM, harninder@freescale.com wrote: From: Harninder Rai harninder@freescale.com It adds cache-sram support in P1/P2 QorIQ platforms as under: * A small abstraction over powerpc's remote heap allocator * Exports mpc85xx_cache_sram_alloc()/free() APIs * Supports only one contiguous SRAM window * Drivers can do the following in Kconfig to use these APIs select FSL_85XX_CACHE_SRAM if MPC85xx You are missing the definition of this option in Kconfig like: +config FSL_85XX_CACHE_SRAM + bool + select PPC_LIB_RHEAP + The select won't work actually. Furthermore, MPC85xx config has been changed to FSL_SOC_BOOKE - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Thu, Oct 14, 2010 at 11:56:15AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2010-10-13 at 09:16 -0400, Josh Boyer wrote: On Tue, Sep 28, 2010 at 09:09:41AM -0400, Josh Boyer wrote: Hi Ben, A few small updates for the next branch. A new board/SoC from AMCC, and some 476 changes from Shaggy. Please pull. OK, below is a fixed up tree that drops the patch Shaggy said was broken, and rebases on top of your new -next branch. Please pull. please, rebase again without Shaggy's lazy flush patch. I'll handle that one separately, I think it needs a little bit more massaging. The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876: powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Josh Boyer (1): powerpc/44x: Update ppc44x_defconfig Tirumala Marri (1): powerpc/44x: Add support for the AMCC APM821xx SoC arch/powerpc/boot/dts/bluestone.dts | 254 ++ arch/powerpc/configs/44x/bluestone_defconfig | 68 +++ arch/powerpc/configs/ppc44x_defconfig|9 +- arch/powerpc/kernel/cpu_setup_44x.S |1 + arch/powerpc/kernel/cputable.c | 15 ++ arch/powerpc/platforms/44x/Kconfig | 16 ++ arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 7 files changed, 360 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/bluestone.dts create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 14, 2010, at 2:10 AM, Li Yang-R58472 wrote: Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC + /* Ensure that RFXE is set on e500 v1/v2 */ + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /* +!PPC_E500MC */ #endif /* E500 */ I've never really been happy with this code. We really should set HID1_RFXE in cpu_setup_fsl_booke.S instead. But this bit is not recommended to be set unless necessary. And it is only required by SRIO for now. Than wrap it in a CONFIG_RAPIDIO in cpu_setup_fsl_booke.S - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
On Thu, Oct 14, 2010 at 8:25 AM, Kumar Gala ga...@kernel.crashing.org wrote: +CONFIG_MATH_EMULATION=y Don't these chips have hardware FP? +CONFIG_E1000=y +CONFIG_E1000E=y Are you sure you want these on by default? We may use the E1000 cards in-house, but I don't know if our customers do. +CONFIG_MSDOS_FS=m +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=y These should probably be off as well. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
We get the following when building on ppc64 due to lack of include of
asm/io.h:
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
'out_be32'
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
'in_be32'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
integer without a cast
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/spi/spi_fsl_lib.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
index 15aa6c2..281e060 100644
--- a/drivers/spi/spi_fsl_lib.h
+++ b/drivers/spi/spi_fsl_lib.h
@@ -18,6 +18,8 @@
#ifndef __SPI_FSL_LIB_H__
#define __SPI_FSL_LIB_H__
+#include asm/io.h
+
/* SPI/eSPI Controller driver's private data. */
struct mpc8xxx_spi {
struct device *dev;
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RTC rtc-cmos.c : Fix warning on PowerPC
From 8435e5876fc3d629406c63b85bff82c25fc4bf75 Mon Sep 17 00:00:00 2001 From: Srikanth Krishnakar skris...@mvista.com Date: Fri, 8 Oct 2010 18:07:06 +0530 Subject: [PATCH] RTC: rtc-cmos.c: Fix warning on PowerPC The following warning is seen while compilation of PowerPC kernel: CC drivers/rtc/rtc-cmos.o drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes. Fix it by adding defined(__powerpc__). Signed-off-by: Srikanth Krishnakar skris...@mvista.com --- drivers/rtc/rtc-cmos.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 5856167..7e6ce62 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -687,7 +687,8 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq) #ifdefined(CONFIG_ATARI) address_space = 64; #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) \ - || defined(__sparc__) || defined(__mips__) + || defined(__sparc__) || defined(__mips__) \ + || defined(__powerpc__) address_space = 128; #else #warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes. -- 1.6.3.3.333.gdf68 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
We get the following when building on ppc64 due to lack of include of
asm/io.h:
Is this an immediate problem (merge for .36), or is it a linux-next thing?
g.
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
'out_be32'
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
'in_be32'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
integer without a cast
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/spi/spi_fsl_lib.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
index 15aa6c2..281e060 100644
--- a/drivers/spi/spi_fsl_lib.h
+++ b/drivers/spi/spi_fsl_lib.h
@@ -18,6 +18,8 @@
#ifndef __SPI_FSL_LIB_H__
#define __SPI_FSL_LIB_H__
+#include asm/io.h
+
/* SPI/eSPI Controller driver's private data. */
struct mpc8xxx_spi {
struct device *dev;
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Oct 14, 2010, at 9:12 AM, Grant Likely wrote: On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote: We get the following when building on ppc64 due to lack of include of asm/io.h: Is this an immediate problem (merge for .36), or is it a linux-next thing? g. .37 / next is fine. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
We get the following when building on ppc64 due to lack of include of
asm/io.h:
Applied.
g.
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
'out_be32'
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
'in_be32'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
integer without a cast
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/spi/spi_fsl_lib.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
index 15aa6c2..281e060 100644
--- a/drivers/spi/spi_fsl_lib.h
+++ b/drivers/spi/spi_fsl_lib.h
@@ -18,6 +18,8 @@
#ifndef __SPI_FSL_LIB_H__
#define __SPI_FSL_LIB_H__
+#include asm/io.h
+
/* SPI/eSPI Controller driver's private data. */
struct mpc8xxx_spi {
struct device *dev;
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
eSDHC controller driver on MPC8308rdb
Hello,
(apologies for writing such a long e-mail, hope you can bother to read it all ☺
)
I have some difficulties with the eSDHC controller driver used on a MPC8308
evaluation board with kernel 2.6.36-rc7, and hope that some of you may be able
to help me with the debugging.
The driver is loaded properly, and binds to the eSDHC controller without
problems. When inserting a sd-card it is bound to the mmcblk-driver, so no
problems there either.
However, I am not able to read nor write to the card, I have attached output
with error messages below:
**
mmc0: new SDHC card at address 9155
mmcblk0: mmc0:9155 SD04G 3.69 GiB
mmc0: Too large timeout requested!
mmcblk0: retrying using single block read
mmc0: Too large timeout requested!
mmcblk0: error -84 sending status comand
mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
end_request: I/O error, dev mmcblk0, sector 0
mmc0: Too large timeout requested!
mmcblk0: error -84 sending status comand
mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
end_request: I/O error, dev mmcblk0, sector 1
…..this continues up to sector 7 before starting anew
Debug output with no SD-card:
**
mmc0: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc0: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
of:sdhci-of e002e000.sdhci: desired SD clock: 40, actual: 0
mmc0: starting CMD52 arg 0c00 flags 0195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD52): -110:
mmc0: starting CMD52 arg 8c08 flags 0195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD52): -110:
mmc0: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc0: starting CMD0 arg flags 00c0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD0): 0:
mmc0: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc0: starting CMD8 arg 01aa flags 02f5
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD8): -110:
mmc0: starting CMD5 arg flags 02e1
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
…
I have the following in my dts:
sd...@2e000 {
compatible = fsl,mpc8308-esdhc, fsl,esdhc;
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
clock-frequency = 0;
};
Could this be a problem related the eSDHC controller (or the driver), or is it
the memory card? (a 4GB SanDisk Extreme SDHC card, which unfortunately is the
only card I have available at the moment.)
I will keep digging into drivers/mmc/host/sdhci.c in search of a solution, and
any tips to how I should proceed would be greatly appreciated!
--
Maria
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
Hi Grant, On Wed, 15 Sep 2010 22:12:57 +0200 Anatolij Gustschin ag...@denx.de wrote: Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension breaks touch screen support on this board since the GPIO interrupt will be mapped to 8xxx GPIO irq host resulting in a not requestable interrupt in the touch screen driver. Fix it by mapping the touch interrupt on 8xxx GPIO irq host. Signed-off-by: Anatolij Gustschin ag...@denx.de --- arch/powerpc/platforms/512x/pdm360ng.c | 26 ++ 1 files changed, 22 insertions(+), 4 deletions(-) Can this patch go in for 2.6.37 ? Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 11:27:09 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
tiejun.chen wrote:
Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
Scott Wood wrote:
The crash is happening somewhere in mpic_set_irq_type():
Agreed. That is just where I pointed out on my email replied for OOPS. To
enable
DBG to figure out 'src' and 'mpic-irq_count' from the file,
arch/powerpc/sysdev/mpic.c,.
==
int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
..
if (src = mpic-irq_count)
return -EINVAL;
^
I think this OOPS may be from here.
No, it's after that. His board code is using the mpic's isu remapping
I means OOPS is *from* here. According to David's call trace,
mpic_set_irq_type() is the last issued function. And that corresponding
return
value, R3, is '0xffea', -22, and also '-EINVAL'.
Just because that value is in r3 doesn't mean that src =
mpic-irq_count.
Consider something like:
cmplw r4, r5
li r3, -EINVAL
bgelr
...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
I may have a clue (you might not think so, but...): I've configured the init thusly: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 0, 256, MPIC ); Which, as I read the code, should disable the ISU stuff. I've seeing this on boot: mpic: Setting up MPIC MPIC version 1.2 at e004, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources Now, since the interrupt number I want is 224, which, last time I checked, was 88, this may be the root cause. As I read the code: /* Read feature register, calculate num CPUs and, for non-ISU * MPICs, num sources as well. On ISU MPICs, sources are counted * as ISUs are added */ greg_feature = mpic_read(mpic-gregs, MPIC_INFO(GREG_FEATURE_0)); mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK) MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1; if (isu_size == 0) mpic-num_sources = ((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK) MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1; So it would seem to me that the greg_feature is saying I have 88 interrupts. I've tried setting the ISU size to 256: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 256, 256, MPIC ); And that kills the kernel as we init the mpic. SO, I guess the question in, what sets greg_feature, as it would seem to be incorrect. Or, am I on the wrong trail? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Wed, 13 Oct 2010 20:09:02 -0700 Zang Roy-R61911 r61...@freescale.com wrote: + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL; No need for = NULL. Any harm? Or just personal habit or style? Can you explain about why? Besides not wanting superfluous code on general principle, it could hide a bug if in the future the real initialization is missing on some code path. It would become a runtime NULL dereference rather than a compiler warning. Not exactly. Per my understand, if the pointer will definitely be assigned in code path, it is not necessary to init it when define. for example, char c; char b; char *a; if (condition) a = c; else a = b; ... for other case, if the path will not ensure the pointer assignment, it will be inited when define to avoid warning. for example, char c; char *a = NULL; if (condition) a = c; ... Yes, but this patch looks like the former case, not the latter. Is GCC giving a warning without the initializer? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 11:22:45 -0500 david.hag...@gmail.com wrote: As I read the code: /* Read feature register, calculate num CPUs and, for non-ISU * MPICs, num sources as well. On ISU MPICs, sources are counted * as ISUs are added */ greg_feature = mpic_read(mpic-gregs, MPIC_INFO(GREG_FEATURE_0)); mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK) MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1; if (isu_size == 0) mpic-num_sources = ((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK) MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1; So it would seem to me that the greg_feature is saying I have 88 interrupts. I've tried setting the ISU size to 256: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 256, 256, MPIC ); And that kills the kernel as we init the mpic. SO, I guess the question in, what sets greg_feature, as it would seem to be incorrect. It comes from FRR[NIRQ]. It seems that this chip takes a less-than-useful interpretation of what that field means -- it gives the actual number of sources, not the size of the sparsely populated array. If you look at current kernels, you'll find an MPIC_BROKEN_FRR_NIRQS flag to work around this. It's not very clear to me what distinction the MPIC code is trying to make between irq_count and num_sources in the first place, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
Hallelujah and Huzzah! I finally got my vector! I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and the kernel is now letting me have my vector! Now I can actually see if the dang thing works! THANK YOU EVERYBODY for putting up with me on this! It comes from FRR[NIRQ]. It seems that this chip takes a less-than-useful interpretation of what that field means -- it gives the actual number of sources, not the size of the sparsely populated array. Perhaps you might want to have a talk with your cow-orkers there, Scott, since this is a Freescale part. It's not very clear to me what distinction the MPIC code is trying to make between irq_count and num_sources in the first place, though. /me looks at Scott's email again. If you, working FOR Freescale, and following the Linux development (presumably for some time) are confused, imagine what I've been going through! Hot damn, and time for a quick version control commit, a hot lunch, and really testing the code. Thanks again! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
These files undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages! Signed-off-by: Nishanth Aravamudan n...@us.ibm.com --- Because the lpar and pci_dlpar code is pretty low-level verbose, perhaps it makes sense to add another Kconfig variable for really low-level stuff? But it's annoying to have DEBUG *somewhat* effective, especially in the EEH area when doing PCI stuff. --- arch/powerpc/platforms/pseries/eeh.c |2 -- arch/powerpc/platforms/pseries/lpar.c |3 --- arch/powerpc/platforms/pseries/pci_dlpar.c |2 -- 3 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c index 34b7dc1..17a11c8 100644 --- a/arch/powerpc/platforms/pseries/eeh.c +++ b/arch/powerpc/platforms/pseries/eeh.c @@ -21,8 +21,6 @@ * Please address comments and feedback to Linas Vepstas li...@austin.ibm.com */ -#undef DEBUG - #include linux/delay.h #include linux/init.h #include linux/list.h diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c index cf79b46..4b31a66 100644 --- a/arch/powerpc/platforms/pseries/lpar.c +++ b/arch/powerpc/platforms/pseries/lpar.c @@ -19,9 +19,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -/* Enables debugging of low-level hash table routines - careful! */ -#undef DEBUG - #include linux/kernel.h #include linux/dma-mapping.h #include linux/console.h diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c index 4b7a062..5fcc92a 100644 --- a/arch/powerpc/platforms/pseries/pci_dlpar.c +++ b/arch/powerpc/platforms/pseries/pci_dlpar.c @@ -25,8 +25,6 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG - #include linux/pci.h #include asm/pci-bridge.h #include asm/ppc-pci.h -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 12:20:55 -0500 david.hag...@gmail.com wrote: It comes from FRR[NIRQ]. It seems that this chip takes a less-than-useful interpretation of what that field means -- it gives the actual number of sources, not the size of the sparsely populated array. Perhaps you might want to have a talk with your cow-orkers there, Scott, since this is a Freescale part. Well, it was a coworker who added the workaround, so I assume we're already aware of the issue. The description of NIRQ is vague enough that it's hard to argue that Linux's expectations of what it means are justified. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
On Oct 13, 2010, at 8:39 PM, Tabi Timur-B04825 wrote: Kumar Gala wrote: arch/powerpc/configs/mpc85xx_defconfig |3 + arch/powerpc/configs/mpc85xx_smp_defconfig |3 + arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++- 3 files changed, 217 insertions(+), 2 deletions(-) I dropped this because of chicken/egg issue with guts.h If you pull from alsa-next, it should resolve that. Either that, or ask the alsa guys to apply this patch instead. Can you ask the alsa guys to pick it up. I'm happy to ack. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
Mark, can you pick up this patch for us? Because it depends on powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support, it will break the build if we apply to powerpc-next. You can grab the patch from http://patchwork.ozlabs.org/patch/67095/ On Thu, Oct 7, 2010 at 2:36 PM, Timur Tabi ti...@freescale.com wrote: The Freescale P1022DS has an on-chip video controller called the DIU, and a driver for this device already exists. Update the platform file for the P1022DS reference board to enable the driver, and update the defconfig for Freescale MPC85xx boards to add the driver. Signed-off-by: Timur Tabi ti...@freescale.com --- -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
Well, it was a coworker who added the workaround, so I assume we're already aware of the issue. The description of NIRQ is vague enough that it's hard to argue that Linux's expectations of what it means are justified. Well, I now can actually interrupt the PPC from my host processor! (well, it segfaulted, but's my fault for not actually initializing my work queue structure. But I can get the interrupt into the part!) So thanks to all. I hope to get my code working, get past my delivery deadline on it, clean it up so it matches The One True Way Of Laying Out Kernel Code, and post it here for everybody to point and laugh at. Maybe around Christmas. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix warning when compiling immap_qe.h
Fix the warnings genereted by arch/powerpc/include/asm/immap_qe.h when
CONFIG_PHYS_ADDR_T_64BIT is defined:
immap_qe.h: In function 'immrbar_virt_to_phys':
immap_qe.h:472:8: warning: cast from pointer to integer of different size
immap_qe.h:472:24: warning: cast from pointer to integer of different size
immap_qe.h:473:5: warning: cast from pointer to integer of different size
immap_qe.h:473:21: warning: cast from pointer to integer of different size
immap_qe.h:474:36: warning: cast from pointer to integer of different size
Note that the QE does not support 36-bit physical addresses, so even when
CONFIG_PHYS_ADDR_T_64BIT is defined, the QE MURAM must be located below the
4GB boundary.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/immap_qe.h | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
index 4e10f50..0edb684 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -467,13 +467,22 @@ struct qe_immap {
extern struct qe_immap __iomem *qe_immr;
extern phys_addr_t get_qe_base(void);
-static inline unsigned long immrbar_virt_to_phys(void *address)
+/*
+ * Returns the offset within the QE address space of the given pointer.
+ *
+ * Note that the QE does not support 36-bit physical addresses, so if
+ * get_qe_base() returns a number above 4GB, the caller will probably fail.
+ */
+static inline phys_addr_t immrbar_virt_to_phys(void *address)
{
- if ( ((u32)address = (u32)qe_immr)
- ((u32)address ((u32)qe_immr + QE_IMMAP_SIZE)) )
- return (unsigned long)(address - (u32)qe_immr +
- (u32)get_qe_base());
- return (unsigned long)virt_to_phys(address);
+ void *q = (void *)qe_immr;
+
+ /* Is it a MURAM address? */
+ if ((address = q) (address (q + QE_IMMAP_SIZE)))
+ return get_qe_base() + (address - q);
+
+ /* It's an address returned by kmalloc */
+ return virt_to_phys(address);
}
#endif /* __KERNEL__ */
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Possible kernel stack overflow due to fast interrupts
Hi, all, I am looking at the kernel source of 2.6.32. It appears to me that kernel stack can be easily getting overflowed in case of fast interrupts. Here is my observation, any comments? Thanks, Let's assume task A triggers the fast interrupts, and task B was running when the fast interrupt occur. In the context of task B (according to entry_32.S) 0. Assume task B's ksp = X 1. the interrupt causes exception, allocate exception frame space from the task B'stack (ksp = X - INT_FRAME_SIZE). 2. interrupt handler is invoked 3. ret_from_except, and resume_kernel is invoked 4. then preempt_schedule_irq is called, which in trun, __schedule() and context_switch is called. Assume it switches to task A. In this step, task B's stack is pushed another INT_FRAME_SIZE to save its context, so task B's ksp = X - 2 * INT_FRAME_SIZE now. In the context of task A a. NIP would point to the instruction after switch_to(). b. MSR_EE is enabled in the call trace (finish_task_switch --finish_lock_switch--spin_unlock_irq) c. do something that would trigger an interrupt later on (such as timer) d. call schedule() for context switch to task B. In this step, task B's stack is popped INT_FRAME_SIZE size for context restore. Note that task B's ksp = X - INT_FRAME_SIZE In the context of task B again a1. similar to step a above b1. similar to step b above c1. interrupt occurs, go to step 1 above, and repeat!!! As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE on each loop. It will eventually overflow. Thanks for your input. Rick ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
divya dipra...@linux.vnet.ibm.com writes: While running systemtap tests on the p6 machine , against the kernel version 2.6.36-rc7-git3 Oops occured , here are the call trace Did the oops happen during a systemtap module startup vs. operation vs. shutdown? stap -V version string? BUG: spinlock bad magic on CPU#6, stapio/20398 -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res lock: c0fcfa18, .magic: , .owner:none/-1, .owner_cpu: 0 Call Trace: [c001effbfab0] [c0011934] .show_stack+0x6c/0x16c (unreliable) [c001effbfb60] [c02c9274] .spin_bug+0xb0/0xd4 [c001effbfbf0] [c02c953c] .do_raw_spin_lock+0x48/0x184 [c001effbfc90] [c054af78] ._raw_spin_lock+0x10/0x24 [c001effbfd00] [d3015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [...] kernel BUG at kernel/timer.c:681! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA pSeries [...] [c001effbfc50] [c001effbfd00] 0xc001effbfd00 (unreliable) [c001effbfd00] [d301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [c001effbfdc0] [c009c2f8] .run_timer_softirq+0x1d8/0x2a8 We have had occasional problems in the past with something like this: http://sourceware.org/PR10651, but it never was tracked down to a systemtap bug per se, as opposed to suspicions that the kernel was not satisfying one of its guarantees w.r.t. del_timer_sync(). - FChE ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote: Mark, can you pick up this patch for us? Because it depends on powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support, it will break the build if we apply to powerpc-next. You can grab the patch from http://patchwork.ozlabs.org/patch/67095/ Done, but I had to fix up what looked like an add/add conflict with headers in the file. Since I was editing that area of the file anyway I also dropped the #define DEBUG as it looked like a mistake. Please send followup patch(es) correcting things if I messed up any of that. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Possible kernel stack overflow due to fast interrupts
On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote: Hi, all, .../... In the context of task A a. NIP would point to the instruction after switch_to(). b. MSR_EE is enabled in the call trace (finish_task_switch --finish_lock_switch--spin_unlock_irq) c. do something that would trigger an interrupt later on (such as timer) d. call schedule() for context switch to task B. In this step, task B's stack is popped INT_FRAME_SIZE size for context restore. Note that task B's ksp = X - INT_FRAME_SIZE In the context of task B again a1. similar to step a above b1. similar to step b above c1. interrupt occurs, go to step 1 above, and repeat!!! As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE on each loop. It will eventually overflow. So if I follow you correctly, you are worried that by the time execution resumes in B, and before it pops the second frame off, it might get another interrupt and re-preempt... Now unless I missed something, that cannot happen because preempt_schedule_irq() does increment the preempt count: add_preempt_count(PREEMPT_ACTIVE); local_irq_enable(); schedule(); local_irq_disable(); sub_preempt_count(PREEMPT_ACTIVE); Which means that it won't preempt again in finish_task_switch, and so will eventually come back, turn EE back off, and pop off the stack frame. Or am I missing something ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
msi_bitmap.c question
Hi, I am trying to resubmit a patch for MSI support for ppc4xx devices. One of the review feedback was not to use the bit map as it is only for the devices which don’t have hard wired mapping between interrupt controller interrupts and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked freescale SoCs and cell SoCs they have interrupts hard wired to MSI interrupts. Why do they have to use the bitmap and create irqhost, even though they are one-to-one mapped between interrupt controller numbers and MSI ? Thx, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: These files undef DEBUG, but I think they were added before the ability to control this from Kconfig. Perhaps. Some people, *cough*, have a tendency to merge those back in again from time to time :) It's really annoying to only get some of the debug messages! True, but .. Signed-off-by: Nishanth Aravamudan n...@us.ibm.com --- Because the lpar and pci_dlpar code is pretty low-level verbose, perhaps it makes sense to add another Kconfig variable for really low-level stuff? But it's annoying to have DEBUG *somewhat* effective, especially in the EEH area when doing PCI stuff. I really don't think you want to enable the lpar debug by default. Have you tried it? It can make for a pretty unusable system, just because of the console spam. Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than all this, but requires setup at runtime. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote: On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: These files undef DEBUG, but I think they were added before the ability to control this from Kconfig. Perhaps. Some people, *cough*, have a tendency to merge those back in again from time to time :) It's really annoying to only get some of the debug messages! True, but .. Signed-off-by: Nishanth Aravamudan n...@us.ibm.com --- Because the lpar and pci_dlpar code is pretty low-level verbose, perhaps it makes sense to add another Kconfig variable for really low-level stuff? But it's annoying to have DEBUG *somewhat* effective, especially in the EEH area when doing PCI stuff. I really don't think you want to enable the lpar debug by default. Have you tried it? It can make for a pretty unusable system, just because of the console spam. Yeah, you're right. After enabling it, I had to kill my boot and start over w/o the lpar DEBUG on. I assume dlpar_pci is similar? I dunno, would a patch to a least remove the EEH one be ok? Seems like it isn't super-verbose, and does have some handy output. Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than all this, but requires setup at runtime. True, I started looking into it, but only realized today that eeh.c had that #undef! :) Thanks, Nish -- Nishanth Aravamudan n...@us.ibm.com IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: msi_bitmap.c question
On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote: Hi, I am trying to resubmit a patch for MSI support for ppc4xx devices. One of the review feedback was not to use the bit map as it is only for the devices which don’t have hard wired mapping between interrupt controller interrupts and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked freescale SoCs and cell SoCs they have interrupts hard wired to MSI interrupts. Why do they have to use the bitmap and create irqhost, even though they are one-to-one mapped between interrupt controller numbers and MSI ? I'm not quite sure I understand your question. The MSI bitmap and the irq_host are two different things. The MSI bitmap is basically an allocator for hardware numbers that can be used for MSI. On some interrupt controllers that might be any interrupt that's not used, on others there are restrictions on which numbers can be used for MSI, it depends. So it's possible you don't need to use that code, but I don't know how your hardware works. The irq_host is the struct that controls mapping hardware irq numbers into linux irq numbers. The cell MSI code has no restrictions on what the MSI value is, so it just uses the Linux irq number directly using irq_create_direct_mapping(). cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 17:23 -0700, Nishanth Aravamudan wrote: On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote: On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: Because the lpar and pci_dlpar code is pretty low-level verbose, perhaps it makes sense to add another Kconfig variable for really low-level stuff? But it's annoying to have DEBUG *somewhat* effective, especially in the EEH area when doing PCI stuff. I really don't think you want to enable the lpar debug by default. Have you tried it? It can make for a pretty unusable system, just because of the console spam. Yeah, you're right. After enabling it, I had to kill my boot and start over w/o the lpar DEBUG on. :) I assume dlpar_pci is similar? That should be OK to enable I think. Suck it and see I guess. I dunno, would a patch to a least remove the EEH one be ok? Seems like it isn't super-verbose, and does have some handy output. Yeah definitely. That undef was merged as part of a cleanup/fix patch but shouldn't have been. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
eeh and pci_dlpar #undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages from these files. Leave the lpar.c #undef alone as it produces so much output as to make the kernel unusable. Update the Kconfig text to indicate this particular quirk :) Signed-off-by: Nishanth Aravamudan n...@us.ibm.com --- arch/powerpc/platforms/pseries/Kconfig |6 ++ arch/powerpc/platforms/pseries/eeh.c |2 -- arch/powerpc/platforms/pseries/pci_dlpar.c |2 -- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index c667f0f..3139814 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -47,6 +47,12 @@ config LPARCFG config PPC_PSERIES_DEBUG depends on PPC_PSERIES PPC_EARLY_DEBUG bool Enable extra debug logging in platforms/pseries +help + Say Y here if you want the pseries core to produce a bunch of + debug messages to the system log. Select this if you are having a + problem with the pseries core and want to see more of what is + going on. This does not enable debugging in lpar.c, which must + be manually done due to its verbosity. default y config PPC_SMLPAR diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c index 34b7dc1..17a11c8 100644 --- a/arch/powerpc/platforms/pseries/eeh.c +++ b/arch/powerpc/platforms/pseries/eeh.c @@ -21,8 +21,6 @@ * Please address comments and feedback to Linas Vepstas li...@austin.ibm.com */ -#undef DEBUG - #include linux/delay.h #include linux/init.h #include linux/list.h diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c index 4b7a062..5fcc92a 100644 --- a/arch/powerpc/platforms/pseries/pci_dlpar.c +++ b/arch/powerpc/platforms/pseries/pci_dlpar.c @@ -25,8 +25,6 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG - #include linux/pci.h #include asm/pci-bridge.h #include asm/ppc-pci.h -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
Scott Wood wrote:
On Thu, 14 Oct 2010 11:27:09 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
tiejun.chen wrote:
Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
Scott Wood wrote:
The crash is happening somewhere in mpic_set_irq_type():
Agreed. That is just where I pointed out on my email replied for OOPS. To
enable
DBG to figure out 'src' and 'mpic-irq_count' from the file,
arch/powerpc/sysdev/mpic.c,.
==
int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
..
if (src = mpic-irq_count)
return -EINVAL;
^
I think this OOPS may be from here.
No, it's after that. His board code is using the mpic's isu remapping
I means OOPS is *from* here. According to David's call trace,
mpic_set_irq_type() is the last issued function. And that corresponding
return
value, R3, is '0xffea', -22, and also '-EINVAL'.
Just because that value is in r3 doesn't mean that src =
mpic-irq_count.
Consider something like:
cmplw r4, r5
lir3, -EINVAL
bgelr
Right absolutely and got it.
Thanks again
Tiejun
...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On 14 October 2010 12:48, Nishanth Aravamudan n...@us.ibm.com wrote: These files undef DEBUG, but I think they were added before the ability to control this from Kconfig. Right. It's really annoying to only get some of the debug messages! I don't get the big picture. Will there be some CONFIG_DEBUG_EEH in Kconfig? or just some option to turn on DEBUG for all powerpc-related files? Or maybe I am demonstrating my utter ignorance of some new whiz-bang Kconfig technology? Anyway, I see no harm in the EEH portion of the patch. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
On 14 October 2010 19:48, Nishanth Aravamudan n...@us.ibm.com wrote: eeh and pci_dlpar #undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages from these files. Leave the lpar.c #undef alone as it produces so much output as to make the kernel unusable. Update the Kconfig text to indicate this particular quirk :) Signed-off-by: Nishanth Aravamudan n...@us.ibm.com OK, ignore my last email. Acked by: Linas Vepstas linasveps...@gmail.com --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -47,6 +47,12 @@ config LPARCFG config PPC_PSERIES_DEBUG depends on PPC_PSERIES PPC_EARLY_DEBUG bool Enable extra debug logging in platforms/pseries + help + Say Y here if you want the pseries core to produce a bunch of + debug messages to the system log. Select this if you are having a + problem with the pseries core and want to see more of what is + going on. This does not enable debugging in lpar.c, which must + be manually done due to its verbosity. default y Umm, I see default y and you are not changing this but ... default y ?? Really? Also, I am guessing that the lpar spam is due only to a handful of printk's, while most of the rest will be infrequent. Just knock out the high-frequency ones... --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
-Original Message- From: Wood Scott-B07421 Sent: Friday, October 15, 2010 0:01 AM To: Zang Roy-R61911 Cc: Wood Scott-B07421; Anton Vorontsov; linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com; a...@linux-foundation.org; Lan Chunhe-B25806; Gala Kumar-B11780; linuxppc-...@ozlabs.org; Hu Mingkai-B21284 Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions On Wed, 13 Oct 2010 20:09:02 -0700 Zang Roy-R61911 r61...@freescale.com wrote: + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL; No need for = NULL. Any harm? Or just personal habit or style? Can you explain about why? Besides not wanting superfluous code on general principle, it could hide a bug if in the future the real initialization is missing on some code path. It would become a runtime NULL dereference rather than a compiler warning. Not exactly. Per my understand, if the pointer will definitely be assigned in code path, it is not necessary to init it when define. for example, char c; char b; char *a; if (condition) a = c; else a = b; ... for other case, if the path will not ensure the pointer assignment, it will be inited when define to avoid warning. for example, char c; char *a = NULL; if (condition) a = c; ... Yes, but this patch looks like the former case, not the latter. That is right. Is GCC giving a warning without the initializer? no. we are on the same point. Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 20:54 -0500, Linas Vepstas wrote: On 14 October 2010 19:48, Nishanth Aravamudan n...@us.ibm.com wrote: eeh and pci_dlpar #undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages from these files. Leave the lpar.c #undef alone as it produces so much output as to make the kernel unusable. Update the Kconfig text to indicate this particular quirk :) Signed-off-by: Nishanth Aravamudan n...@us.ibm.com OK, ignore my last email. Acked by: Linas Vepstas linasveps...@gmail.com I guess I'll ack it too seeing I added PPC_PSERIES_DEBUG: Acked-by: Michael Ellerman mich...@ellerman.id.au --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -47,6 +47,12 @@ config LPARCFG config PPC_PSERIES_DEBUG depends on PPC_PSERIES PPC_EARLY_DEBUG bool Enable extra debug logging in platforms/pseries +help + Say Y here if you want the pseries core to produce a bunch of + debug messages to the system log. Select this if you are having a + problem with the pseries core and want to see more of what is + going on. This does not enable debugging in lpar.c, which must + be manually done due to its verbosity. default y Umm, I see default y and you are not changing this but ... default y ?? Really? Yes, default y if early debug is enabled. Unlike DEBUG_KERNEL, PPC_EARLY_DEBUG is a pretty good indication that you are doing some kernel development - because you have to choose exactly which platform you're working on. Also, I am guessing that the lpar spam is due only to a handful of printk's, while most of the rest will be infrequent. Just knock out the high-frequency ones... No they're all related to the HPTE code, so you basically don't want any of them enabled unless you're debugging that, and most people aren't. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] add icswx support v2
On Wed, 2010-10-13 at 11:52 +1100, Michael Neuling wrote:
In message 1286855108.14049.8.ca...@flin.austin.ibm.com you wrote:
icswx is a PowerPC co-processor instruction to send data to a
co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
the owning process are registered in the window context of the
co-processor at initial time. When the icswx instruction is executed,
the L2 generates a cop-reg transaction on PowerBus. The transaction has
no address and the processor does not perform an MMU access to
authenticate the transaction. The coprocessor compares the LPAR_ID and
the PID included in the transaction and the LPAR_ID and PID held in the
window context to determine if the process is authorized to generate the
transaction.
This patch adds icswx co-processor instruction support.
Can you describe the ABI a bit?
How has this changed from version 1?
The icswx instruction itself does nothing but generating a cop-req
transaction on PowerBus. The cop-req transaction causes 1 cache
line of data (128 bytes) sent to the co-processor. This provides
a low latency mechanism for sending small amount of data without
the co-processor becoming a master on the PowerBus.
Since the transaction has no address and the processor does not
perform an MMU access to authenticate the transaction, the
co-processor relys on the the LPAR_ID and PID to determine if
the process is authorized to generate the transaction.
The OS needs to assign a 16-bit PID for the process. This
cop-PID needs needs to be updated during context switch. The
cop-PID needs to be destroied when the context is destroied.
Change log from v1:
- Change 2'nd parameter of use_cop() from struct task_struct *task
to struct mm_struct *mm.
- Check for mm == current-active_mm before calling mtspr().
- Add a lock to guard acop related operations.
- Check for POWER7 CPU.
- Move the definition of SPRN_PID from reg_booke.h to avoid
defining SPRN_PID in two different files.
- Rename pid to acop_pid.
- Change function name disuse_cop() to drop_cop().
- Add a comment to describe the two new fields in mm_context_t.
- Moving CONFIG_ICSWX from arch/powerpc/platforms/pseries/Kconfig
to arch/powerpc/platforms/Kconfig.cputype
All other comments will be addressed in a new patch.
Patch has been whitespace munged aswell.
More comments below...
Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com
Signed-off-by: Tseng-Hui (Frank) Lin th...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/mmu-hash64.h |5 ++
arch/powerpc/include/asm/mmu_context.h |6 ++
arch/powerpc/include/asm/reg.h | 12
arch/powerpc/include/asm/reg_booke.h |3 -
arch/powerpc/mm/mmu_context_hash64.c | 105
arch/powerpc/platforms/Kconfig.cputype | 16 +
6 files changed, 144 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index acac35d..6c1ab90 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -423,6 +423,11 @@ typedef struct {
#ifdef CONFIG_PPC_SUBPAGE_PROT
struct subpage_prot_table spt;
#endif /* CONFIG_PPC_SUBPAGE_PROT */
+#ifdef CONFIG_ICSWX
+ unsigned long acop; /* mask of enabled coprocessor types */
+#define HASH64_MAX_PID (0x)
+ unsigned int acop_pid; /* pid value used with coprocessors */
+#endif /* CONFIG_ICSWX */
} mm_context_t;
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 81fb412..88118de 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
#define deactivate_mm(tsk,mm) do { } while (0)
+#ifdef CONFIG_ICSWX
+extern void switch_cop(struct mm_struct *next);
+extern int use_cop(unsigned long acop, struct mm_struct *mm);
+extern void drop_cop(unsigned long acop, struct mm_struct *mm);
+#endif /* CONFIG_ICSWX */
+
/*
* After we have set current-mm to a new value, this activates
* the context for the new mm so we see the new mappings.
diff --git a/arch/powerpc/include/asm/reg.h
b/arch/powerpc/include/asm/reg.h
index ff0005eec..9bbf178 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -170,8 +170,19 @@
#define SPEFSCR_FRMC 0x0003 /* Embedded FP rounding mode co
ntrol
*/
/* Special Purpose Registers (SPRNs)*/
+
+#ifdef CONFIG_40x
+#define SPRN_PID 0x3B1 /* Process ID */
+#else
+#defineSPRN_PID0x030 /* Process ID */
+#ifdef CONFIG_BOOKE
+#defineSPRN_PID0 SPRN_PID/* Process ID Register 0 */
+#endif
+#endif
+
Why are you moving these definitions?
#define SPRN_CTR 0x009 /* Count Register */
#define
RE: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
-Original Message- From: Wood Scott-B07421 Sent: Friday, October 15, 2010 0:03 AM To: Zang Roy-R61911 Cc: Anton Vorontsov; linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com; a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott- B07421; Gala Kumar-B11780; linuxppc-...@ozlabs.org Subject: Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices On Wed, 13 Oct 2010 23:43:38 -0700 Zang Roy-R61911 r61...@freescale.com wrote: Plus, I think the patch is not runtime bisectable (i.e. you now do request_irq() here, but not removing it from the nand driver, so nand will fail to probe). Nand driver does not need to request irq. It will use the irq requested by lbc. remember, other lbc device may also need to use this registered irq. It should not be removed in nand driver. The point is that you need to make both changes in the same patch. But according to previous discussion, if lbc driver is registered successful, it will not be removed. (.remove function is dropped in the patch). that is not bisectable? nand driver will not touch the irq. all irq status process is in the lbc driver. Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
