RE: FSL DMA engine transfer to PCI memory
What was the ppc you used? The 8315E PowerQUIICC II On 85xx/QorIQ-family chips such as P2020, there is no DMA controller inside the PCIe controller itself (or are you talking about bus mastering by the PCIe device[1]? interface is a bit ambiguous), though it was considered part of the PCI controller on 82xx. The DMA engine and PCIe are both on OCeaN, so the traffic does not need to pass through the e500 Coherency Module. My understanding -- for what it's worth, coming from a software person :-) -- is that you should be able to get large transfer chunks using the DMA engine. It might be possible - but the ppc's pcie would need to know the length of the dma (or at least be told that there was more data to arrive) before even starting the pcie transfer. I used 128 bytes per pcie transfer (which the altera slave can handle) but that is longer than you want a burst on the internal (CSB in my case) bus on the ppc. It is also longer than a cache line - so the dma engine's memory reads might induce a cache flush. I suggest getting things working, and then seeing whether the performance is acceptable. The only reason for using dma (instead of pio) is to get long pcie transfers - otherwise it isn't really worth the effort. Transfers are unlikely to take long enough to make it worth taking an interrupt at the end of the dma. My device driver implements read() and write() (and poll() to wait for interrupts). So I do overlap the copy_to/from_user with the next dma. The generic dma controller can't even generate 64bit cycles into the ppc's PCIe engine. Could you elaborate? The pcie is (apparantly) a 64bit interface, to a single 32bit transfer is actually a 64bit one with only 4 byte enables driven. I couldn't see anything that would allow a CSB master to generate two 32bit cycles (since it is a 32bit bus) that the pcie hardware could convert into a single 64bit pcie transfer. The fpga target is likely to have 32bit targets (it could have 64 bit ones, but if you've instantiated a NiosII cpu it wont!) so you get a bus width adapter (which carefully does the cycle with no byte enables driven) as well as the clock crossing bridge. These both make the slave even slower than it would otherwise be! IIRC We managed to get 2us for a read and 500ns for a write cycle. The per byte costs are relatively small in comparison. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: About mpc85xx flash memory allocation
On Tue, Jan 25, 2011 at 11:17 AM, Mitsutaka Amano mitsutaka.am...@gmail.com wrote: On Tue, Jan 25, 2011 at 11:05 AM, tiejun.chen tiejun.c...@windriver.com wrote: Mitsutaka Amano wrote: On Mon, Jan 24, 2011 at 3:48 PM, tiejun.chen tiejun.c...@windriver.com wrote: Mitsutaka Amano wrote: Hi all, I'm testing the ppc platform is based on mpc85xx. 256MB Flash memory has been installed. Then I found this entries. /proc/vmallocinfo ~~~ 0xc910-0xd9101000 268439552 of_flash_probe+0x290/0x814 ioremap physmap_of allocated 268MB over to the vmalloc. vmalloc space is tight. Why does we need mpc platforms to flash memory allocation? I know This should not be dedicated to so-called mpc platform. And we always use ioremap() to map the device space. And on PPC ioremap also use the same space as vmalloc(). While bootstrap you also can see this associated message like the follows, -- .. * 0xd100..0xffbe9000 : vmalloc ioremap Yeah. My platform says the follow message. * 0xc900..0xdf00 : vmalloc ioremap Any reason why you don't access 0xdf00? Higher than 0xdf00 has to map TLB for using other peripherals. it's 400MB over. The default vmalloc ioremap space was about 200MB. so I increased that by decreasing lowmem. But If possible, I hope to keep default maps. So I don't want to use vmalloc ioremap other architectures don't allocate to the vmalloc. The design of the hardware? or Is there the way to use the flash You can open /dev/mem then mmap() with a appropriate offset to access the device space including flash. I use the device tree(dts) and define flash partitions. Also I use CFI driver and CFI_PHYSMAP_OF for device tree. Is there the reference driver in what uses mmap() kernel tree? I think I have to write a driver what can support dts and mmap() with a appropriate offset to access the device. You should not write anything again. And you can access any physical address directly via /dev/mem from the user space like the following: fd = open(/dev/mem,); mmap(fd + offset); Thanks for letting me know. I want to use in combination with device tree. So I'll write a driver based on physmap_of.c(such as mmap_of.c) I confused and misunderstand that. it has to use as a rootfs. so It can't use a userland program. Of cource, it can be force mapping to the userspace. but system will be unstable. I think. Mitsutaka Thanks, Mitsutaka Tiejun Thanks, Mitsutaka Tiejun memory without vmalloc? Thanks, Mitsutaka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/476: Workaround for PLB6 hang
The 476FP core may hang if an instruction fetch happens during an msync following a tlbsync. This workaround makes sure that enough instruction cache lines are pre-fetched before executing the msync. (sync and msync are the same to the compiler.) Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com --- arch/powerpc/mm/tlb_nohash_low.S | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S index af405ee..7c63c0e 100644 --- a/arch/powerpc/mm/tlb_nohash_low.S +++ b/arch/powerpc/mm/tlb_nohash_low.S @@ -189,6 +189,13 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) blr #ifdef CONFIG_PPC_47x + +/* + * 47x variant of icbt + */ +# define ICBT(CT,RA,RB)\ + .long 0x7c2c | ((CT) 21) | ((RA) 16) | ((RB) 11) + /* * _tlbivax_bcast is only on 47x. We don't bother doing a runtime * check though, it will blow up soon enough if we mistakenly try @@ -206,7 +213,35 @@ _GLOBAL(_tlbivax_bcast) isync eieio tlbsync +BEGIN_FTR_SECTION + b 1f +END_FTR_SECTION_IFSET(CPU_FTR_476_DD2) + sync + wrtee r10 + blr +/* + * DD2 HW could hang if in instruction fetch happens before msync completes. + * Touch enough instruction cache lines to ensure cache hits + */ +1: mflrr9 + bl 2f +2: mflrr6 + li r7,32 + ICBT(0,r6,r7) /* touch next cache line */ + add r6,r6,r7 + ICBT(0,r6,r7) /* touch next cache line */ + add r6,r6,r7 + ICBT(0,r6,r7) /* touch next cache line */ sync + nop + nop + nop + nop + nop + nop + nop + nop + mtlrr9 wrtee r10 blr #endif /* CONFIG_PPC_47x */ -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Workaround for PowerPC 476FP hardware bug
These patches add a workaround to avoid a hang on the DD2 level of the 476FP core. This hardware bug will be fixed in future products, but this particular core will used in production. Dave Kleikamp (2): powerpc/476: define specific cpu table entry DD2 core powerpc/476: Workaround for PLB6 hang arch/powerpc/include/asm/cputable.h |3 ++- arch/powerpc/kernel/cputable.c | 22 ++ arch/powerpc/mm/tlb_nohash_low.S| 35 +++ 3 files changed, 55 insertions(+), 5 deletions(-) -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V8 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer
В Wed, 19 Jan 2011 14:57:32 -0800
tma...@apm.com пишет:
From: Tirumala Marri tma...@apm.com
Core Interface Layer Common provides common functions for both host
controller and peripheral controller. CIL manages the memory map
for the core. It also handles basic tasks like reading/writing the
registers and data FIFOs in the controller. CIL performs basic
services that are not specific to either the host or device modes
of operation. These services include management of the OTG Host
Negotiation Protocol (HNP) and Session Request Protocol (SRP).
Signed-off-by: Tirumala R Marri tma...@apm.com
Signed-off-by: Fushen Chen fc...@apm.com
Signed-off-by: Mark Miesfeld mmiesf...@apm.com
---
drivers/usb/dwc_otg/dwc_otg_cil.c | 972 +
drivers/usb/dwc_otg/dwc_otg_cil.h | 1220
drivers/usb/dwc_otg/dwc_otg_cil_intr.c | 616
3 files changed, 2808 insertions(+), 0 deletions(-)
[snip drivers/usb/dwc_otg/dwc_otg_cil.c]
diff --git a/drivers/usb/dwc_otg/dwc_otg_cil.h
b/drivers/usb/dwc_otg/dwc_otg_cil.h
new file mode 100644
index 000..d97a8db
--- /dev/null
+++ b/drivers/usb/dwc_otg/dwc_otg_cil.h
@@ -0,0 +1,1220 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld mmiesf...@apm.com
+ * Modified by Stefan Roese s...@denx.de, DENX Software Engineering
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
IS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#if !defined(__DWC_CIL_H__)
+#define __DWC_CIL_H__
+#include linux/io.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include linux/interrupt.h
+#include linux/dmapool.h
+#include linux/spinlock.h
+#include linux/usb/otg.h
+
+#include dwc_otg_regs.h
+
+#ifdef CONFIG_DWC_DEBUG
+#define DEBUG
+#endif
+
+/**
+ * Reads the content of a register.
+ */
+static inline u32 dwc_read32(u32 reg)
+{
+#ifdef CONFIG_DWC_OTG_REG_LE
+ return in_le32((unsigned __iomem *)reg);
+#else
+ return in_be32((unsigned __iomem *)reg);
+#endif
+};
+static inline u32 dwc_read_reg32(u32 *reg)
+{
+#ifdef CONFIG_DWC_OTG_REG_LE
+ return in_le32(reg);
+#else
+ return in_be32(reg);
+#endif
+};
+
dwc_read_reg32 is used nowhere throughout the code. One of dwc_read32
and dwc_read_reg32 should be removed IMO. There was once only
dwc_read_reg32. In version 5 of your patchset I believe. Why did you
add another function? AFAIK it is not correct to store pointers in u32
because they need 8 bytes on 64-bit archs. So it was ok with the old
dwc_read_reg32.
+/**
+ * Writes a register with a 32 bit value.
+ */
+static inline void dwc_write32(u32 reg, const u32 value)
+{
+#ifdef CONFIG_DWC_OTG_REG_LE
+ out_le32((unsigned __iomem *)reg, value);
+#else
+ out_be32((unsigned __iomem *)reg, value);
+#endif
+};
+static inline void dwc_write_reg32(u32 *reg, const u32 value)
+{
+#ifdef CONFIG_DWC_OTG_REG_LE
+ out_le32(reg, value);
+#else
+ out_be32(reg, value);
+#endif
+};
+
Same thing here. dwc_write_reg32 is never used. And it should be used
instead of dwc_write32 probably.
+/**
+ * This function modifies bit values in a register. Using the
+ * algorithm: (reg_contents ~clear_mask) | set_mask.
+ */
+static inline
+ void dwc_modify_reg32(u32 *_reg, const u32 _clear_mask,
+ const u32 _set_mask)
+{
[PATCH 1/2] powerpc/476: define specific cpu table entry DD2 core
The DD2 core still has some unstability. Define CPU_FTR_476_DD2 to
enable workarounds in later patches.
This is based on an earlier, unreleased patch for DD1 by Ben Herrenschmidt.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/cputable.h |3 ++-
arch/powerpc/kernel/cputable.c | 22 ++
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index f0a211d..be3cdf9 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -154,6 +154,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_NAP_DISABLE_L2_PR ASM_CONST(0x2000)
#define CPU_FTR_DUAL_PLL_750FX ASM_CONST(0x4000)
#define CPU_FTR_NO_DPM ASM_CONST(0x8000)
+#define CPU_FTR_476_DD2ASM_CONST(0x0001)
#define CPU_FTR_NEED_COHERENT ASM_CONST(0x0002)
#define CPU_FTR_NO_BTICASM_CONST(0x0004)
#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0010)
@@ -465,7 +466,7 @@ enum {
CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_PPC_47x
- CPU_FTRS_47X |
+ CPU_FTRS_47X | CPU_FTR_476_DD2 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 8d74a24..436e1e5 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1811,11 +1811,11 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = ppc440,
},
- { /* 476 core */
- .pvr_mask = 0x,
- .pvr_value = 0x11a5,
+ { /* 476 DD2 core */
+ .pvr_mask = 0x,
+ .pvr_value = 0x11a52080,
.cpu_name = 476,
- .cpu_features = CPU_FTRS_47X,
+ .cpu_features = CPU_FTRS_47X | CPU_FTR_476_DD2,
.cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
.mmu_features = MMU_FTR_TYPE_47x |
@@ -1839,6 +1839,20 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_47x,
.platform = ppc470,
},
+ { /* 476 others */
+ .pvr_mask = 0x,
+ .pvr_value = 0x11a5,
+ .cpu_name = 476,
+ .cpu_features = CPU_FTRS_47X,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_FPU,
+ .mmu_features = MMU_FTR_TYPE_47x |
+ MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL,
+ .icache_bsize = 32,
+ .dcache_bsize = 128,
+ .machine_check = machine_check_47x,
+ .platform = ppc470,
+ },
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V8 04/10] USB/ppc4xx: Add Synopsys DWC OTG HCD function
Hi, Please consider squashing this little patch into yours. The driver currently prints 0x as the register base. This patch will fix that. commit 2f850fe637101be287f116a37282b6b1a09e6a98 Author: Alexander Gordeev lasa...@lvk.cs.msu.su Date: Mon Nov 29 15:15:25 2010 +0300 dwc_otg: set usb hcd resource address and length Signed-off-by: Alexander Gordeev lasa...@lvk.cs.msu.su diff --git a/drivers/usb/dwc_otg/dwc_otg_hcd.c b/drivers/usb/dwc_otg/dwc_otg_hcd.c index 240ab0b..e420a8d 100644 --- a/drivers/usb/dwc_otg/dwc_otg_hcd.c +++ b/drivers/usb/dwc_otg/dwc_otg_hcd.c @@ -1269,6 +1269,8 @@ int __devinit dwc_otg_hcd_init(struct device *_dev, } dev_set_drvdata(_dev, dwc_otg_device); hcd-regs = otg_dev-base; + hcd-rsrc_start = otg_dev-phys_addr; + hcd-rsrc_len = otg_dev-base_len; hcd-self.otg_port = 1; /* Initialize the DWC OTG HCD. */ -- Alexander signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V8 03/10] USB/ppc4xx: Add Synopsys DWC OTG CoreInterface Layer
Also in_le32/out_le32/in_be32/out_be32 are architecture-specific AFAIK. Isn't the whole patch architecture-specific ? I'd suggest using readl/writel for LE ops and __be32_to_cpu(__raw_readl(addr))/__raw_writel(__cpu_to_be32(b),addr) for BE ops. Since the ppc doesn't have a byteswap instruction (and the LE memory transfers might even be slow!) you really don't want to be doing software byteswap. Not to mention the horrific synchronistion instructions that in_le32() and out_le32() actually contain. I didn't find __raw_readl() when I was looking for asm patterns that byteswapped memory transfers. I did find st_le32() and ld_le32() in arch/powerpc/include/asm/swab.h but that file is actually quite difficult to #include because there is another swab.h that gets included instead. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dt: Move device tree documentation out of powerpc directory
The device tree is used by more than just PowerPC. Make the documentation
directory available to all.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
Assuming nobody has an issue with this, I'll push it out to Linus for
2.6.38 since it is only a documentation change.
g.
.../bindings}/4xx/cpm.txt |0
.../bindings}/4xx/emac.txt |0
.../bindings}/4xx/ndfc.txt |0
.../bindings}/4xx/ppc440spe-adma.txt |0
.../bindings}/4xx/reboot.txt |0
.../bindings}/can/sja1000.txt |0
.../dts-bindings = devicetree/bindings}/ecm.txt |0
.../bindings}/eeprom.txt |0
.../bindings}/fsl/83xx-512x-pci.txt|0
.../bindings}/fsl/8xxx_gpio.txt|0
.../bindings}/fsl/board.txt|0
.../bindings}/fsl/can.txt |0
.../bindings}/fsl/cpm_qe/cpm.txt |0
.../bindings}/fsl/cpm_qe/cpm/brg.txt |0
.../bindings}/fsl/cpm_qe/cpm/i2c.txt |0
.../bindings}/fsl/cpm_qe/cpm/pic.txt |0
.../bindings}/fsl/cpm_qe/cpm/usb.txt |0
.../bindings}/fsl/cpm_qe/gpio.txt |0
.../bindings}/fsl/cpm_qe/network.txt |0
.../bindings}/fsl/cpm_qe/qe.txt|0
.../bindings}/fsl/cpm_qe/qe/firmware.txt |0
.../bindings}/fsl/cpm_qe/qe/par_io.txt |0
.../bindings}/fsl/cpm_qe/qe/pincfg.txt |0
.../bindings}/fsl/cpm_qe/qe/ucc.txt|0
.../bindings}/fsl/cpm_qe/qe/usb.txt|0
.../bindings}/fsl/cpm_qe/serial.txt|0
.../bindings}/fsl/diu.txt |0
.../bindings}/fsl/dma.txt |0
.../bindings}/fsl/esdhc.txt|0
.../bindings}/fsl/gtm.txt |0
.../bindings}/fsl/guts.txt |0
.../bindings}/fsl/i2c.txt |0
.../bindings}/fsl/lbc.txt |0
.../bindings}/fsl/mcm.txt |0
.../bindings}/fsl/mcu-mpc8349emitx.txt |0
.../bindings}/fsl/mpc5121-psc.txt |0
.../bindings}/fsl/mpc5200.txt |0
.../bindings}/fsl/mpic.txt |0
.../bindings}/fsl/msi-pic.txt |0
.../bindings}/fsl/pmc.txt |0
.../bindings}/fsl/sata.txt |0
.../bindings}/fsl/sec.txt |0
.../bindings}/fsl/spi.txt |0
.../bindings}/fsl/ssi.txt |0
.../bindings}/fsl/tsec.txt |0
.../bindings}/fsl/upm-nand.txt |0
.../bindings}/fsl/usb.txt |0
.../bindings}/gpio/gpio.txt|0
.../bindings}/gpio/led.txt |0
.../bindings}/gpio/mdio.txt|0
.../bindings}/marvell.txt |0
.../bindings}/mmc-spi-slot.txt |0
.../bindings}/mtd-physmap.txt |0
.../bindings}/nintendo/gamecube.txt|0
.../bindings}/nintendo/wii.txt |0
.../dts-bindings = devicetree/bindings}/phy.txt |0
.../bindings}/spi-bus.txt |0
.../bindings}/usb-ehci.txt |0
.../bindings}/xilinx.txt |0
.../{powerpc = devicetree}/booting-without-of.txt |0
60 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/{powerpc/dts-bindings = devicetree/bindings}/4xx/cpm.txt
(100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/4xx/emac.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/4xx/ndfc.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/4xx/ppc440spe-adma.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/4xx/reboot.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/can/sja1000.txt (100%)
rename Documentation/{powerpc/dts-bindings = devicetree/bindings}/ecm.txt
(100%)
rename Documentation/{powerpc/dts-bindings = devicetree/bindings}/eeprom.txt
(100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/fsl/83xx-512x-pci.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/fsl/8xxx_gpio.txt (100%)
rename Documentation/{powerpc/dts-bindings =
devicetree/bindings}/fsl/board.txt (100%)
rename Documentation/{powerpc/dts-bindings = devicetree/bindings}/fsl/can.txt
(100%)
rename Documentation/{powerpc/dts-bindings =
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Tue, Jan 25, 2011 at 10:32 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: What are exception 700 901? 700 is a program check (illegal instruction or BUG_ON() statement) 900 is decrementer (aka timer) interrupt. The 0x1000c694 address looks fishy? That's userspace. So you took a timer interrupt, which got into hrtimer, and something you did caused cpufreq_notify_transition to crash, probably with a BUG_ON This should prove quite useful! Thanks! (which you can probably see above what you pasted, unless you don't have access to that part of the backtrace). This is kind of my problem. ANY suggestions (applicable to an old world PowerMac) would be appreciated on how to get access to the rest of the information. This thing appears completely dead at this point. Thanks! kevin P.S.: There are 2 columns of numbers: [xxx] [yyy] One of these is the PC. What is the other? stack? Cheers, Ben. Thanks! kevin ___ 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: [PATCH V8 03/10] USB/ppc4xx: Add Synopsys DWC OTG CoreInterface Layer
В Wed, 26 Jan 2011 16:35:05 - David Laight david.lai...@aculab.com пишет: Also in_le32/out_le32/in_be32/out_be32 are architecture-specific AFAIK. Isn't the whole patch architecture-specific ? I use this driver on MIPS board right now. :) This core from Synopsys is used in many SOCs with various architectures. I'd suggest using readl/writel for LE ops and __be32_to_cpu(__raw_readl(addr))/__raw_writel(__cpu_to_be32(b),addr) for BE ops. Since the ppc doesn't have a byteswap instruction (and the LE memory transfers might even be slow!) you really don't want to be doing software byteswap. Not to mention the horrific synchronistion instructions that in_le32() and out_le32() actually contain. I didn't find __raw_readl() when I was looking for asm patterns that byteswapped memory transfers. I did find st_le32() and ld_le32() in arch/powerpc/include/asm/swab.h but that file is actually quite difficult to #include because there is another swab.h that gets included instead. I see. readl/writel are defined in asm-generic/io.h. So IMHO there should be also le and be versions that can be redefined in arch-specific code. -- Alexander signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
On Wed, 26 Jan 2011 10:18:01 + David Laight david.lai...@aculab.com wrote: What was the ppc you used? The 8315E PowerQUIICC II Ah. The interconnect between the DMA engine and PCIe is different on 83xx. The DMA engine and PCIe are both on OCeaN, so the traffic does not need to pass through the e500 Coherency Module. My understanding -- for what it's worth, coming from a software person :-) -- is that you should be able to get large transfer chunks using the DMA engine. It might be possible - but the ppc's pcie would need to know the length of the dma (or at least be told that there was more data to arrive) before even starting the pcie transfer. On 85xx/QorIQ, I believe the connection between the DMA engine and the PCIe controller allows the data to arrive in suitably large chunks. I suggest getting things working, and then seeing whether the performance is acceptable. The only reason for using dma (instead of pio) is to get long pcie transfers - otherwise it isn't really worth the effort. Transfers are unlikely to take long enough to make it worth taking an interrupt at the end of the dma. But in the absence of specific knowledge about this specific chip, implementing it and testing is a good way of determining whether you get those large PCIe transactions on this particular hardware. And even if the transfers aren't particularly fast, if the total transfer size (not the size of the chunks that go on the bus) is large enough, it could be worth freeing up the core to do something else. It could also avoid running the data through the core's caches, or be a transfer from one PCIe device to another, etc. Don't be too quick to say don't bother. :-) The generic dma controller can't even generate 64bit cycles into the ppc's PCIe engine. Could you elaborate? The pcie is (apparantly) a 64bit interface, to a single 32bit transfer is actually a 64bit one with only 4 byte enables driven. My understanding is that PCIe is an aggregation of one or more serial links, over which packets are sent. I'm not sure to what extent it makes sense to call it a 64-bit interface, other than addressing. I couldn't see anything that would allow a CSB master to generate two 32bit cycles (since it is a 32bit bus) that the pcie hardware could convert into a single 64bit pcie transfer. Again, that's an 83xx thing, 85xx/QorIQ is different. Though from the 8315 manual it looks like the CSB can do 64-bit data (but not addresses). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt: Move device tree documentation out of powerpc directory
On Wed, Jan 26, 2011 at 10:20:34AM -0700, Grant Likely wrote: The device tree is used by more than just PowerPC. Make the documentation directory available to all. How does the planned stucture look like for this new directory? I see that in your move the architecture is dropped. But some of these looks like they are arch candidates. The 4xx/* for example looks like powerpc stuff that should be in a powerpc directory. Another is sja1000. This is obviously a can driver. So how about mirroring the kernel structure: Proposal: drivers/net/can === sja1000.txt drivers/ata/ === fsl/sata.txt arch/powerpc === powerpc specific stuff This is a bit more effort but then we end up with a well-known structure. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt: Move device tree documentation out of powerpc directory
On Wed, Jan 26, 2011 at 10:20:34AM -0700, Grant Likely wrote: The device tree is used by more than just PowerPC. Make the documentation directory available to all. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- Assuming nobody has an issue with this, I'll push it out to Linus for 2.6.38 since it is only a documentation change. g. .../bindings}/4xx/cpm.txt |0 .../bindings}/4xx/emac.txt |0 .../bindings}/4xx/ndfc.txt |0 .../bindings}/4xx/ppc440spe-adma.txt |0 .../bindings}/4xx/reboot.txt |0 This should probably be renamed to ...bindings}/powerpc4xx/ in that case. Similarly for fsl (even more so since they have ARM parts too). Also the booting-without-of.txt file is very powerpc specific. So I would suggest either creating a powerpc/ directory under /bindings or something similar. Opinions? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt: Move device tree documentation out of powerpc directory
On Wed, Jan 26, 2011 at 12:43 PM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Wed, Jan 26, 2011 at 10:20:34AM -0700, Grant Likely wrote: The device tree is used by more than just PowerPC. Make the documentation directory available to all. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- Assuming nobody has an issue with this, I'll push it out to Linus for 2.6.38 since it is only a documentation change. g. .../bindings}/4xx/cpm.txt | 0 .../bindings}/4xx/emac.txt | 0 .../bindings}/4xx/ndfc.txt | 0 .../bindings}/4xx/ppc440spe-adma.txt | 0 .../bindings}/4xx/reboot.txt | 0 This should probably be renamed to ...bindings}/powerpc4xx/ in that case. Similarly for fsl (even more so since they have ARM parts too). okay, I'll look at reorganizing. Also the booting-without-of.txt file is very powerpc specific. So I would suggest either creating a powerpc/ directory under /bindings or something similar. Actually, it isn't. Very little of it is powerpc-specific, and after I looked at it I decided that it still made sense to keep it in this file and add additional sections for arm, x86, mips and microblaze entry. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
dump_stack doc
Hi,
Does this content look ok:
kevdig@SatelliteA75:/usr/src/linux-2.6.36/arch/powerpc/kernel$ diff
-U3 process.c process-new_c
--- process.c 2010-10-23 20:01:13.0 -0500
+++ process-new_c 2011-01-26 14:04:17.0 -0600
@@ -1107,6 +1107,27 @@
static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
+/**
+ * void show_stack() - dump the contents of the stack in readable format
+ * @struct task_struct *tsk: pointer to task struct owning stack frame
+ * @unsigned long *stack: pointer to stack frame
+ *
+ * Dump the stack in bipedal carbon unit readable form. Format is:
+ * Call Trace:
+ * [[ --- Exception: trap id (%lx) at trap handler (%pS) ]]
+ * [[ LR = trapping routine (%pS) ]]
+ * [stack (REG)] [instruction (REG)] instruction (%pS) [[
(unreliable)]]
+ *
+ * Information between '[[' ']]' is optional. Additional information is
+ * printed at the beginning of what are believed to be exception frames.
+ *
+ * The first frame is considered unreliable and will have (unreliable)
+ * tacked on the end.
+ *
+ * kstack_depth_to_print determines how many frames to show.
+ *
+ * Value in parenthesis is the format specifier used. See printk().
+ */
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
unsigned long sp, ip, lr, newsp;
@@ -1177,6 +1198,11 @@
} while (count++ kstack_depth_to_print);
}
+/**
+ * void dump_stack(void) - dump the contents of the stack in readable form
+ *
+ * See process.c`show_stack() for details
+ */
void dump_stack(void)
{
show_stack(current, NULL);
kevin
--- process.c 2010-10-23 20:01:13.0 -0500
+++ process-new_c 2011-01-26 14:04:17.0 -0600
@@ -1107,6 +1107,27 @@
static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
+/**
+ * void show_stack() - dump the contents of the stack in readable format
+ * @struct task_struct *tsk: pointer to task struct owning stack frame
+ * @unsigned long *stack: pointer to stack frame
+ *
+ * Dump the stack in bipedal carbon unit readable form. Format is:
+ * Call Trace:
+ * [[ --- Exception: trap id (%lx) at trap handler (%pS) ]]
+ * [[ LR = trapping routine (%pS) ]]
+ * [stack (REG)] [instruction (REG)] instruction (%pS) [[ (unreliable)]]
+ *
+ * Information between '[[' ']]' is optional. Additional information is
+ * printed at the beginning of what are believed to be exception frames.
+ *
+ * The first frame is considered unreliable and will have (unreliable)
+ * tacked on the end.
+ *
+ * kstack_depth_to_print determines how many frames to show.
+ *
+ * Value in parenthesis is the format specifier used. See printk().
+ */
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
unsigned long sp, ip, lr, newsp;
@@ -1177,6 +1198,11 @@
} while (count++ kstack_depth_to_print);
}
+/**
+ * void dump_stack(void) - dump the contents of the stack in readable form
+ *
+ * See process.c`show_stack() for details
+ */
void dump_stack(void)
{
show_stack(current, NULL);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Wed, 2011-01-26 at 11:20 -0600, kevin diggs wrote: This is kind of my problem. ANY suggestions (applicable to an old world PowerMac) would be appreciated on how to get access to the rest of the information. This thing appears completely dead at this point. You don't have a serial port ? If you do, use sccdbg on the kernel command line to route xmon to it, and boot with console=ttyPZ0,38400 (I think the old things default to 38400 bauds). Use the modem port. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] powerpc/44x: allow override to hard-coded uart address
Allow the early debug uart address to be overridden from the kernel
command line.
I would have preferred use the uart's virtual-reg property, but the device
tree hasn't been unflatted yet, and I don't know a reliable way to find it.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/kernel/udbg_16550.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
index b4b167b..d36021a 100644
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -219,6 +219,19 @@ void udbg_init_pas_realmode(void)
#ifdef CONFIG_PPC_EARLY_DEBUG_44x
#include platforms/44x/44x.h
+static unsigned long udbg_44x_comport = PPC44x_EARLY_DEBUG_VIRTADDR;
+
+static int __init early_parse_comport(char *p)
+{
+ if (!p || !(*p))
+ return 0;
+
+ udbg_44x_comport = simple_strtoul(p, 0, 16);
+
+ return 0;
+}
+early_param(uart_addr, early_parse_comport);
+
static void udbg_44x_as1_flush(void)
{
if (udbg_comport) {
@@ -249,9 +262,7 @@ static int udbg_44x_as1_getc(void)
void __init udbg_init_44x_as1(void)
{
- udbg_comport =
- (struct NS16550 __iomem *)PPC44x_EARLY_DEBUG_VIRTADDR;
-
+ udbg_comport = (struct NS16550 __iomem *)udbg_44x_comport;
udbg_putc = udbg_44x_as1_putc;
udbg_flush = udbg_44x_as1_flush;
udbg_getc = udbg_44x_as1_getc;
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] powerpc: AMP support for 47x
These patches add Asynchonous MultiProcessing support for the 47x chipset. This allows independent OS instances to run on separate cores. Dave Kleikamp (5): powerpc: Move udbg_early_init() after early_init_devtree() powerpc/44x: allow override to hard-coded uart address powerpc/47x: allow kernel to be loaded in higher physical memory powerpc/44x: don't use tlbivax on AMP systems powerpc/476: Create a dts files for two 476 AMP instances under ISS arch/powerpc/Kconfig |2 +- arch/powerpc/boot/Makefile|9 ++- arch/powerpc/boot/dts/iss476-amp1.dts | 119 arch/powerpc/boot/dts/iss476-amp2.dts | 123 + arch/powerpc/boot/treeboot-iss4xx-hi.c| 65 + arch/powerpc/boot/wrapper |7 ++ arch/powerpc/configs/44x/iss476-smp_defconfig |6 +- arch/powerpc/include/asm/mmu.h|2 +- arch/powerpc/kernel/head_44x.S| 42 +++-- arch/powerpc/kernel/setup_32.c|6 +- arch/powerpc/kernel/udbg_16550.c | 17 +++- arch/powerpc/mm/44x_mmu.c | 13 ++- arch/powerpc/mm/tlb_nohash.c | 21 - 13 files changed, 408 insertions(+), 24 deletions(-) create mode 100644 arch/powerpc/boot/dts/iss476-amp1.dts create mode 100644 arch/powerpc/boot/dts/iss476-amp2.dts create mode 100644 arch/powerpc/boot/treeboot-iss4xx-hi.c -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] powerpc/476: Create a dts files for two 476 AMP instances under ISS
These are completely independent OS instances, each running on 2 cores.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/boot/Makefile |9 ++-
arch/powerpc/boot/dts/iss476-amp1.dts | 119 ++
arch/powerpc/boot/dts/iss476-amp2.dts | 123
arch/powerpc/boot/treeboot-iss4xx-hi.c | 65 +
arch/powerpc/boot/wrapper |7 ++
5 files changed, 321 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/iss476-amp1.dts
create mode 100644 arch/powerpc/boot/dts/iss476-amp2.dts
create mode 100644 arch/powerpc/boot/treeboot-iss4xx-hi.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8917816..417502a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -45,6 +45,8 @@ $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-iss4xx.o: BOOTCFLAGS += -mcpu=405
+$(obj)/treeboot-iss476-amp1.o: BOOTCFLAGS += -mcpu=405
+$(obj)/treeboot-iss476-amp2.o: BOOTCFLAGS += -mcpu=405
$(obj)/virtex405-head.o: BOOTAFLAGS += -mcpu=405
@@ -78,7 +80,8 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c
\
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \
- gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c
+ gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \
+ treeboot-iss4xx-hi.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -208,7 +211,9 @@ image-$(CONFIG_KATMAI) +=
cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
image-$(CONFIG_YOSEMITE) += cuImage.yosemite
image-$(CONFIG_ISS4xx) += treeImage.iss4xx \
- treeImage.iss4xx-mpic
+ treeImage.iss4xx-mpic \
+ treeImage.iss476-amp1 \
+ treeImage.iss476-amp2
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_MPC86XADS) += cuImage.mpc866ads
diff --git a/arch/powerpc/boot/dts/iss476-amp1.dts
b/arch/powerpc/boot/dts/iss476-amp1.dts
new file mode 100644
index 000..7de3485
--- /dev/null
+++ b/arch/powerpc/boot/dts/iss476-amp1.dts
@@ -0,0 +1,119 @@
+/*
+ * Device Tree Source for IBM Embedded PPC 476 Platform
+ *
+ * Copyright 2010 Torez Smith, IBM Corporation.
+ *
+ * Based on earlier code:
+ * Copyright (c) 2006, 2007 IBM Corp.
+ * Josh Boyer jwbo...@linux.vnet.ibm.com, David Gibson d...@au1.ibm.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x01f0 0x0010;
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = ibm,iss-4xx;
+ compatible = ibm,iss-4xx, ibm,47x-AMP;
+ dcr-parent = {/cpus/cpu@0};
+
+ aliases {
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ model = PowerPC,4xx; // real CPU changed in sim
+ reg = 0;
+ clock-frequency = 1; // 100Mhz :-)
+ timebase-frequency = 1;
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ status = ok;
+ };
+ cpu@1 {
+ device_type = cpu;
+ model = PowerPC,4xx; // real CPU changed in sim
+ reg = 1;
+ clock-frequency = 1; // 100Mhz :-)
+ timebase-frequency = 1;
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ status = disabled;
+ enable-method = spin-table;
+ cpu-release-addr = 0 0x01f00100;
+ };
+ };
+
+ memory {
+ device_type = memory;
+
[PATCH 1/5] powerpc: Move udbg_early_init() after early_init_devtree()
so that it can use information from the device tree.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/kernel/setup_32.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 1d2fbc9..d1ca976 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -120,12 +120,12 @@ notrace void __init machine_init(unsigned long dt_ptr)
{
lockdep_init();
- /* Enable early debugging if any specified (see udbg.h) */
- udbg_early_init();
-
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
+ /* Enable early debugging if any specified (see udbg.h) */
+ udbg_early_init();
+
probe_machine();
setup_kdump_trampoline();
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5] powerpc/44x: don't use tlbivax on AMP systems
Since other OS's may be running on the other cores don't use tlbivax
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/mmu.h |2 +-
arch/powerpc/kernel/setup_32.c |2 ++
arch/powerpc/mm/tlb_nohash.c | 21 -
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index bb40a06..f3a7c65 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -80,7 +80,7 @@ static inline int mmu_has_feature(unsigned long feature)
extern unsigned int __start___mmu_ftr_fixup, __stop___mmu_ftr_fixup;
-/* MMU initialization (64-bit only fo now) */
+/* MMU initialization */
extern void early_init_mmu(void);
extern void early_init_mmu_secondary(void);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index d1ca976..e50ead7 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -126,6 +126,8 @@ notrace void __init machine_init(unsigned long dt_ptr)
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ early_init_mmu();
+
probe_machine();
setup_kdump_trampoline();
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 2a030d8..b33c5e6 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -35,6 +35,7 @@
#include linux/preempt.h
#include linux/spinlock.h
#include linux/memblock.h
+#include linux/of_fdt.h
#include asm/tlbflush.h
#include asm/tlb.h
@@ -153,6 +154,17 @@ EXPORT_SYMBOL(local_flush_tlb_page);
*/
#ifdef CONFIG_SMP
+static int amp;
+
+#ifdef CONFIG_44x
+void __init early_init_mmu_44x(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, ibm,47x-AMP))
+ amp = 1;
+}
+#endif /* CONFIG_44x */
+
static DEFINE_RAW_SPINLOCK(tlbivax_lock);
static int mm_is_core_local(struct mm_struct *mm)
@@ -232,7 +244,7 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned long
vmaddr,
cpu_mask = mm_cpumask(mm);
if (!mm_is_core_local(mm)) {
/* If broadcast tlbivax is supported, use it */
- if (mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)) {
+ if (!amp mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)) {
int lock = mmu_has_feature(MMU_FTR_LOCK_BCAST_INVAL);
if (lock)
raw_spin_lock(tlbivax_lock);
@@ -587,4 +599,11 @@ void setup_initial_memory_limit(phys_addr_t
first_memblock_base,
/* Finally limit subsequent allocations */
memblock_set_current_limit(first_memblock_base + ppc64_rma_size);
}
+#else /* ! CONFIG_PPC64 */
+void __init early_init_mmu(void)
+{
+#if defined(CONFIG_SMP) defined(CONFIG_44x)
+ early_init_mmu_44x();
+#endif
+}
#endif /* CONFIG_PPC64 */
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc/47x: allow kernel to be loaded in higher physical memory
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/configs/44x/iss476-smp_defconfig |6 ++--
arch/powerpc/kernel/head_44x.S| 42 -
arch/powerpc/mm/44x_mmu.c | 13 ++--
4 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7d69e9b..fa41026 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -827,7 +827,7 @@ config LOWMEM_CAM_NUM
config RELOCATABLE
bool Build a relocatable kernel (EXPERIMENTAL)
- depends on EXPERIMENTAL ADVANCED_OPTIONS FLATMEM FSL_BOOKE
+ depends on EXPERIMENTAL ADVANCED_OPTIONS FLATMEM (FSL_BOOKE ||
PPC_47x)
help
This builds a kernel image that is capable of running at the
location the kernel is loaded at (some alignment restrictions may
diff --git a/arch/powerpc/configs/44x/iss476-smp_defconfig
b/arch/powerpc/configs/44x/iss476-smp_defconfig
index 92f863a..a6eb6ad 100644
--- a/arch/powerpc/configs/44x/iss476-smp_defconfig
+++ b/arch/powerpc/configs/44x/iss476-smp_defconfig
@@ -3,8 +3,8 @@ CONFIG_SMP=y
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_SPARSE_IRQ=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
@@ -21,10 +21,11 @@ CONFIG_ISS4xx=y
CONFIG_HZ_100=y
CONFIG_MATH_EMULATION=y
CONFIG_IRQ_ALL_CPUS=y
-CONFIG_SPARSE_IRQ=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=root=/dev/issblk0
# CONFIG_PCI is not set
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_RELOCATABLE=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -67,7 +68,6 @@ CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
-CONFIG_INOTIFY=y
CONFIG_PROC_KCORE=y
CONFIG_TMPFS=y
CONFIG_CRAMFS=y
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index cbb3436..1da9b7e 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -93,6 +93,30 @@ _ENTRY(_start);
bl early_init
+#ifdef CONFIG_RELOCATABLE
+ /*
+* r25 will contain RPN/ERPN for the start address of memory
+*
+* Add the difference between KERNELBASE and PAGE_OFFSET to the
+* start of physical memory to get kernstart_addr.
+*/
+ lis r3,kernstart_addr@ha
+ la r3,kernstart_addr@l(r3)
+
+ lis r4,KERNELBASE@h
+ ori r4,r4,KERNELBASE@l
+ lis r5,PAGE_OFFSET@h
+ ori r5,r5,PAGE_OFFSET@l
+ subfr4,r5,r4
+
+ rlwinm r6,r25,0,28,31 /* ERPN */
+ rlwinm r7,r25,0,0,3/* RPN - assuming 256 MB page size */
+ add r7,r7,r4
+
+ stw r6,0(r3)
+ stw r7,4(r3)
+#endif
+
/*
* Decide what sort of machine this is and initialize the MMU.
*/
@@ -1001,9 +1025,6 @@ clear_utlb_entry:
lis r3,PAGE_OFFSET@h
ori r3,r3,PAGE_OFFSET@l
- /* Kernel is at the base of RAM */
- li r4, 0/* Load the kernel physical address */
-
/* Load the kernel PID = 0 */
li r0,0
mtspr SPRN_PID,r0
@@ -1013,9 +1034,8 @@ clear_utlb_entry:
clrrwi r3,r3,12/* Mask off the effective page number */
ori r3,r3,PPC47x_TLB0_VALID | PPC47x_TLB0_256M
- /* Word 1 */
- clrrwi r4,r4,12/* Mask off the real page number */
- /* ERPN is 0 for first 4GB page */
+ /* Word 1 - use r25. RPN is the same as the original entry */
+
/* Word 2 */
li r5,0
ori r5,r5,PPC47x_TLB2_S_RWX
@@ -1026,7 +1046,7 @@ clear_utlb_entry:
/* We write to way 0 and bolted 0 */
lis r0,0x8800
tlbwe r3,r0,0
- tlbwe r4,r0,1
+ tlbwe r25,r0,1
tlbwe r5,r0,2
/*
@@ -1124,7 +1144,13 @@ head_start_common:
lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
mtspr SPRN_IVPR,r4
- addis r22,r22,KERNELBASE@h
+ /*
+* If the kernel was loaded at a non-zero 256 MB page, we need to
+* mask off the most significant 4 bits to get the relative address
+* from the start of physical memory
+*/
+ rlwinm r22,r22,0,4,31
+ addis r22,r22,PAGE_OFFSET@h
mtlrr22
isync
blr
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index 024acab..f60e006 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -186,10 +186,11 @@ void __init MMU_init_hw(void)
unsigned long __init mmu_mapin_ram(unsigned long top)
{
unsigned long addr;
+ unsigned long memstart = memstart_addr ~(PPC_PIN_SIZE - 1);
/* Pin in enough TLBs to cover any lowmem not covered by the
* initial 256M
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Wed, Jan 26, 2011 at 3:43 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: You don't have a serial port ? Yeah, just did not know what to do with them? If you do, use sccdbg on the kernel command line to route xmon to it, and boot with console=ttyPZ0,38400 (I think the old things default to 38400 bauds). Use the modem port. Ok! Thanks! One thing. The 2.6 driver for the serial ports on this machine does not work very well. Can I use a slower speed to avoid missing stuff? And I'll need to build the serial stuff into the kernel, right? Thanks for the reply! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Wed, 2011-01-26 at 21:59 -0600, kevin diggs wrote: Ok! Thanks! One thing. The 2.6 driver for the serial ports on this machine does not work very well. Can I use a slower speed to avoid missing stuff? pmac zilog ? It should work fine on tx... unless your receiving side is the one with a problem or we have a bug :-) And I'll need to build the serial stuff into the kernel, right? Yes. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
