Re: [git pull] Please pull powerpc.git next branch (updated)
[ pulled in a few additional patches, and fixed the fsl_pci change to build on ppc64 platforms as well ] The following changes since commit dc28518f7d7dfd93cd44edb44f9b8e961f5a5c1b: powerpc: Fix doorbell type shift (2011-06-20 11:21:48 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next Ashish Kalra (2): powerpc/85xx: Save scratch registers to thread info instead of using SPRGs. powerpc: introduce the ePAPR embedded hypervisor vmpic driver Baruch Siach (1): MAINTAINERS: add arch/powerpc/platforms/85xx/ to the 85xx entry Dmitry Eremin-Solenikov (2): powerpc/85xx: tqm8540 - add description for onboard flash powerpc/85xx: specify interrupt for pq3-localbus devices Kumar Gala (11): powerpc: Rename e55xx_smp_defconfig to corenet64_smp_defconfig powerpc: Add a defconfig for 'corenet' 32-bit platforms powerpc/85xx: Add P5020DS device tree powerpc/85xx: Add P3041DS device tree powerpc/85xx: Updates to P4080DS device tree powerpc/85xx: Cleanup PCIe support on corenet_ds boards powerpc/fsl_pci: Simplify matching logic for PCI_FIXUP_HEADER powerpc/pci: Move FSL fixup from 32-bit to common powerpc/85xx: Add PCI support in 64-bit mode on P5020DS powerpc/qe: Limit QE support to ppc32 powerpc/85xx: Add P4080 SoC device tree include stub Lei Xu (2): powerpc/85xx: Update device tree to add nand info for p5020ds powerpc/85xx: Update device tree to add nand info for p3041ds Prabhakar Kushwaha (2): powerpc/85xx: Add host-pci(e) bridge only for RC powerpc/85xx: Add P1010RDB board support Roy Zang (1): powerpc/85xx: Add basic P1023RDS board support Scott Wood (2): powerpc/85xx: Set up doorbells even with no mpic powerpc/e500mc: Add support for the wait instruction in e500_idle Stuart Yoder (1): powerpc: make irq_choose_cpu() available to all PIC drivers Timur Tabi (9): powerpc: introduce ePAPR embedded hypervisor hcall interface powerpc: add Freescale hypervisor partition control functions powerpc/85xx: add board support for the Freescale hypervisor powerpc/p1022ds: add missing iounmap calls to platform file powerpc/85xx: clamp the P1022DS DIU pixel clock to allowed values powerpc/85xx: enable the framebuffer console for the defconfigs powerpc/86xx: improve calculation of DIU pixel clock on the MPC8610 HPCD powerpc/86xx: enable the framebuffer console on the MPC8610 HPCD powerpc/85xx: disable timebase synchronization under the hypervisor MAINTAINERS|1 + arch/powerpc/boot/dts/mpc8568mds.dts |2 + arch/powerpc/boot/dts/p1010rdb.dts | 280 +++ arch/powerpc/boot/dts/p1010si.dtsi | 376 ++ arch/powerpc/boot/dts/p1023rds.dts | 546 ++ arch/powerpc/boot/dts/p3041ds.dts | 791 arch/powerpc/boot/dts/p4080ds.dts | 533 +- arch/powerpc/boot/dts/p4080si.dtsi | 661 arch/powerpc/boot/dts/p5020ds.dts | 784 +++ arch/powerpc/boot/dts/socrates.dts |2 + arch/powerpc/boot/dts/tqm8540.dts | 42 + arch/powerpc/boot/dts/tqm8548-bigflash.dts |2 + arch/powerpc/boot/dts/tqm8548.dts |2 + arch/powerpc/boot/dts/tqm8560.dts |2 + arch/powerpc/boot/dts/xpedite5200.dts |2 + arch/powerpc/boot/dts/xpedite5200_xmon.dts |2 + arch/powerpc/configs/85xx/p1023rds_defconfig | 173 + arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |5 + arch/powerpc/configs/corenet32_smp_defconfig | 183 + ...e55xx_smp_defconfig = corenet64_smp_defconfig} |0 arch/powerpc/configs/mpc85xx_defconfig | 12 +- arch/powerpc/configs/mpc85xx_smp_defconfig | 10 +- arch/powerpc/include/asm/ehv_pic.h | 40 + arch/powerpc/include/asm/epapr_hcalls.h| 502 + arch/powerpc/include/asm/fsl_hcalls.h | 655 arch/powerpc/include/asm/irq.h |2 + arch/powerpc/include/asm/processor.h |5 + arch/powerpc/include/asm/reg.h |4 +- arch/powerpc/kernel/asm-offsets.c |3 + arch/powerpc/kernel/head_booke.h | 42 +- arch/powerpc/kernel/head_fsl_booke.S | 49 +- arch/powerpc/kernel/idle_e500.S| 12 + arch/powerpc/kernel/irq.c | 35 + arch/powerpc/kernel/pci-common.c | 18 + arch/powerpc/kernel/pci_32.c | 19 - arch/powerpc/platforms/85xx/Kconfig| 19 +
[PATCH] powerpc/85xx: Add p2040 RDB board support
P2040RDB Specification:
---
2Gbyte unbuffered DDR3 SDRAM SO-DIMM(64bit bus)
128 Mbyte NOR flash single-chip memory
256 Kbit M24256 I2C EEPROM
16 Mbyte SPI memory
SD connector to interface with the SD memory card
dTSEC1: connected to the Vitesse SGMII PHY (VSC8221)
dTSEC2: connected to the Vitesse SGMII PHY (VSC8221)
dTSEC3: connected to the Vitesse SGMII PHY (VSC8221)
dTSEC4: connected to the Vitesse RGMII PHY (VSC8641)
dTSEC5: connected to the Vitesse RGMII PHY (VSC8641)
I2C1: Real time clock, Temperature sensor
I2C2: Vcore Regulator, 256Kbit I2C Bus EEPROM
SATA: Lanes C and Land D of Bank2 are connected to two SATA connectors
UART: supports two UARTs up to 115200 bps for console
USB 2.0: connected via a internal UTMI PHY to two TYPE-A interfaces
PCIe:
- Lanes E, F, G and H of Bank1 are connected to one x4 PCIe SLOT1
- Lanes C and Land D of Bank2 are connected to one x4 PCIe SLOT2
Signed-off-by: Mingkai Hu mingkai...@freescale.com
---
Based on http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2040rdb.dts | 166 +++
arch/powerpc/boot/dts/p2040si.dtsi | 623 ++
arch/powerpc/configs/corenet32_smp_defconfig |1 +
arch/powerpc/platforms/85xx/Kconfig | 12 +
arch/powerpc/platforms/85xx/Makefile |1 +
arch/powerpc/platforms/85xx/p2040_rdb.c | 88
6 files changed, 891 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2040rdb.dts
create mode 100644 arch/powerpc/boot/dts/p2040si.dtsi
create mode 100644 arch/powerpc/platforms/85xx/p2040_rdb.c
diff --git a/arch/powerpc/boot/dts/p2040rdb.dts
b/arch/powerpc/boot/dts/p2040rdb.dts
new file mode 100644
index 000..7d84e39
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2040rdb.dts
@@ -0,0 +1,166 @@
+/*
+ * P2040RDB Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``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 Freescale Semiconductor 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.
+ */
+
+/include/ p2040si.dtsi
+
+/ {
+ model = fsl,P2040RDB;
+ compatible = fsl,P2040RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ memory {
+ device_type = memory;
+ };
+
+ soc: soc@ffe00 {
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25sl12801;
+ reg = 0;
+ spi-max-frequency = 4000; /* input clock
*/
+ partition@u-boot {
+ label = u-boot;
+ reg = 0x 0x0010;
+ read-only;
+ };
+ partition@kernel {
+ label = kernel;
+ reg = 0x0010 0x0050;
+ read-only;
+ };
+ partition@dtb {
+ label = dtb;
+
Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
On Mon, Jun 27, 2011 at 03:31:05PM +0530, Ananth N Mavinakayanahalli wrote: On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote: (2011/06/24 19:29), Steven Rostedt wrote: On Fri, 2011-06-24 at 17:21 +0800, Yong Zhang wrote: Hi, When I use kprobe to do something, I found some wired thing. When CONFIG_FUNCTION_TRACER is disabled: (gdb) disassemble do_fork Dump of assembler code for function do_fork: 0xc0037390 +0: mflrr0 0xc0037394 +4: stwur1,-64(r1) 0xc0037398 +8: mfcrr12 0xc003739c +12: stmwr27,44(r1) Then I: modprobe kprobe_example func=do_fork offset=4 ls Things works well. But when CONFIG_FUNCTION_TRACER is enabled: (gdb) disassemble do_fork Dump of assembler code for function do_fork: 0xc0040334 +0: mflrr0 0xc0040338 +4: stw r0,4(r1) 0xc004033c +8: bl 0xc00109d4 mcount 0xc0040340 +12: stwur1,-80(r1) 0xc0040344 +16: mflrr0 0xc0040348 +20: stw r0,84(r1) 0xc004034c +24: mfcrr12 Then I: modprobe kprobe_example func=do_fork offset=12 ls 'ls' will never retrun. system freeze. My access to a 32bit powerpc box is very limited. Also, embedded powerpc has had issues with gcc-4.6 while gcc-4.5 worked fine. I'm not sure if x86 had a similar issue. Masami, have any ideas to why this happened? No, I don't familiar with ppc implementation. I guess that single-step resume code failed to emulate the instruction, but it strongly depends on ppc arch. Maybe IBM people may know what happened. Ananth, Jim, would you have any ideas? On powerpc, we emulate sstep whenever possible. Only recently support to emulate loads and stores got added. I don't have access to a powerpc box today... but will try to recreate the problem ASAP and see what could be happening in the presence of mcount. I tried to recreate this problem on a 64-bit pSeries box without success. Every one of the instructions in the stream at .do_fork are emulated and work fine there -- no hangs/crashes with or without function tracer. Yong, I am copying Kumar to see if he knows of any issues with 32-bit kprobes (he wrote it) or with the function tracer, or with the toolchain itself. You may want to check if, in the failure case, the instruction in question is single-stepped or emulated (print out the value of kprobe-ainsn.boostable in the post_handler) and see if you can find a pattern to the failure. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, 460gt: Add 460gt as compatible in the check for 460ex-compatible crypto
On Fri, Jun 24, 2011 at 04:14:07AM +0200, Segher Boessenkool wrote:
- if (of_find_compatible_node(NULL, NULL,
amcc,ppc460ex-crypto)) {
+ if (of_find_compatible_node(NULL, NULL,
amcc,ppc460ex-crypto) ||
+ of_find_compatible_node(NULL, NULL,
amcc,ppc460gt-crypto)) {
If the device is actually compatible, the device tree node should
claim
it is, and you do not need this code change.
That was actually my first instinct, however I tried to follow the
current convention in the glacier and canyonlands DTS files, which is
to set every device compatible to 460gt or 460ex, depending on the
processor. Many of the devices are identical between the two, since
they are variations of the same SoC, so which is the preferred method?
Follow the device tree convention and add the compatibility check in
the driver,
That is not the convention.
or alter the device trees? I'll send another patch if it's
the latter.
You say
compatible = amcc,ppc460gt-crypto, amcc,ppc460ex-crypto;
I went ahead and modified the addition of the node to the glacier DTS
file to do this instead. I think this specific patch can be dropped.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, 460gt: Add 460gt as compatible in the check for 460ex-compatible crypto
On Tue, Jun 28, 2011 at 7:48 AM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote:
On Fri, Jun 24, 2011 at 04:14:07AM +0200, Segher Boessenkool wrote:
- if (of_find_compatible_node(NULL, NULL,
amcc,ppc460ex-crypto)) {
+ if (of_find_compatible_node(NULL, NULL,
amcc,ppc460ex-crypto) ||
+ of_find_compatible_node(NULL, NULL,
amcc,ppc460gt-crypto)) {
If the device is actually compatible, the device tree node should
claim
it is, and you do not need this code change.
That was actually my first instinct, however I tried to follow the
current convention in the glacier and canyonlands DTS files, which is
to set every device compatible to 460gt or 460ex, depending on the
processor. Many of the devices are identical between the two, since
they are variations of the same SoC, so which is the preferred method?
Follow the device tree convention and add the compatibility check in
the driver,
That is not the convention.
or alter the device trees? I'll send another patch if it's
the latter.
You say
compatible = amcc,ppc460gt-crypto, amcc,ppc460ex-crypto;
I went ahead and modified the addition of the node to the glacier DTS
file to do this instead. I think this specific patch can be dropped.
josh
Thanks, go ahead and drop it. I got buried here at work with our
fiscal year ending.
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Ben, A small pull request to add some DTS entries to bind to the new HW RNG driver for 4xx. I know Eric has the Bluegene stuff being worked on, and there are patches from Michal Simek for relocatable kernel support out for RFC. I need to review those a bit more closely, so they will probably be pushed out to the 3.2 merge window. josh The following changes since commit dc28518f7d7dfd93cd44edb44f9b8e961f5a5c1b: powerpc: Fix doorbell type shift (2011-06-20 11:21:48 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Josh Boyer (1): ppc4xx: Add crypto and RNG entries to Sequoia DTS Mike Williams (1): powerpc/4xx: Update Canyonlands and Glacier boards DTS to add HW RNG support arch/powerpc/boot/dts/canyonlands.dts |5 + arch/powerpc/boot/dts/glacier.dts |8 +++- arch/powerpc/boot/dts/sequoia.dts | 12 3 files changed, 24 insertions(+), 1 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug#630845: linux-image-2.6.39-2-powerpc: CHRP Pegasos2 boot failure
On Sun, Jun 26, 2011 at 11:14:13PM +0100, Ben Hutchings wrote: On Thu, 2011-06-23 at 20:36 +0800, Andrew Buckeridge wrote: Package: linux-image-3.0.0-rc3-powerpc Version: 3.0.0~rc3-1~experimental.1 On Wed, 22 Jun 2011 04:01:38 +0100 Ben Hutchings b...@decadent.org.uk wrote: linux-image-2.6.36-trunk-powerpc_2.6.36-1~experimental.1_powerpc.deb linux-image-2.6.37-1-powerpc_2.6.37-1_powerpc.deb linux-image-2.6.37-2-powerpc_2.6.37-2_powerpc.deb These failed to boot. In all cases stuck at the spinner. At a guess, this may be fixed by a change in Linux 3.0-rc1: Please can you test Linux 3.0-rc3, currently available in experimental? linux-image-3.0.0-rc3-powerpc_3.0.0~rc3-1~experimental.1_powerpc.deb Also failed to boot and got stuck at spinner. Gabriel, Michael, do you recognise this bug? Are there any fixes for Pegasos that are missing from 3.0-rc3? What do you mean by the spinner? I've had very long boot times with an apparently dead machine depending on graphics options. For now I'm running 2.6.39 with one patch for keyboard/mouse handling which is now upstream. I can try a more recent kernel on Thursday. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
On Tue, 2011-06-28 at 16:11 +0530, Ananth N Mavinakayanahalli wrote: My access to a 32bit powerpc box is very limited. Also, embedded powerpc has had issues with gcc-4.6 while gcc-4.5 worked fine. I'd work to debug this too, but I don't have access to a 32bit ppc either. Although I've been told that people would send me one ;) -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dtc: Remove unused variable in flat_read_mem_reserve
The *p variable is declared and used to save inb-ptr, however p is
later never used. This has been the case since commit 6c0f3676 and can
lead to build failures with -Werror=unused-but-set-variable:
flattree.c: In function 'flat_read_mem_reserve':
flattree.c:700:14: error: variable 'p' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [flattree.o] Error 1
Remove the variable.
Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
diff --git a/dtc.c b/dtc.c
index cbc0193..15d2fc2 100644
--- a/dtc.c
+++ b/dtc.c
@@ -99,7 +99,7 @@ int main(int argc, char *argv[])
const char *inform = dts;
const char *outform = dts;
const char *outname = -;
- int force = 0, check = 0, sort = 0;
+ int force = 0, sort = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -111,7 +111,7 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
- while ((opt = getopt(argc, argv, hI:O:o:V:R:S:p:fcqb:vH:s)) != EOF) {
+ while ((opt = getopt(argc, argv, hI:O:o:V:R:S:p:fqb:vH:s)) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -137,9 +137,6 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
- case 'c':
- check = 1;
- break;
case 'q':
quiet++;
break;
diff --git a/flattree.c b/flattree.c
index ead0332..28d0b23 100644
--- a/flattree.c
+++ b/flattree.c
@@ -697,7 +697,6 @@ static struct reserve_info *flat_read_mem_reserve(struct
inbuf *inb)
{
struct reserve_info *reservelist = NULL;
struct reserve_info *new;
- const char *p;
struct fdt_reserve_entry re;
/*
@@ -706,7 +705,6 @@ static struct reserve_info *flat_read_mem_reserve(struct
inbuf *inb)
*
* First pass, count entries.
*/
- p = inb-ptr;
while (1) {
flat_read_chunk(inb, re, sizeof(re));
re.address = fdt64_to_cpu(re.address);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dtc: Remove unused variable in flat_read_mem_reserve
On Tue, Jun 28, 2011 at 09:42:53AM -0400, Josh Boyer wrote: The *p variable is declared and used to save inb-ptr, however p is later never used. This has been the case since commit 6c0f3676 and can lead to build failures with -Werror=unused-but-set-variable: flattree.c: In function 'flat_read_mem_reserve': flattree.c:700:14: error: variable 'p' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [flattree.o] Error 1 Remove the variable. Whoops. I had a dirty git tree on this that had the other change in it still. I'll resend. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] dtc: Remove unused variable in flat_read_mem_reserve
The *p variable is declared and used to save inb-ptr, however p is
later never used. This has been the case since commit 6c0f3676 and can
lead to build failures with -Werror=unused-but-set-variable:
flattree.c: In function 'flat_read_mem_reserve':
flattree.c:700:14: error: variable 'p' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [flattree.o] Error 1
Remove the variable.
Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
diff --git a/flattree.c b/flattree.c
index ead0332..28d0b23 100644
--- a/flattree.c
+++ b/flattree.c
@@ -697,7 +697,6 @@ static struct reserve_info *flat_read_mem_reserve(struct
inbuf *inb)
{
struct reserve_info *reservelist = NULL;
struct reserve_info *new;
- const char *p;
struct fdt_reserve_entry re;
/*
@@ -706,7 +705,6 @@ static struct reserve_info *flat_read_mem_reserve(struct
inbuf *inb)
*
* First pass, count entries.
*/
- p = inb-ptr;
while (1) {
flat_read_chunk(inb, re, sizeof(re));
re.address = fdt64_to_cpu(re.address);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dtc: Remove unused check variable
Commit 376ab6f2 removed the old style check functionality from DTC,
however the check option and variable were not removed. This leads to
build failures when -Werror=unused-but-set-variable is specified:
dtc.c: In function 'main':
dtc.c:102:17: error: variable 'check' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [dtc.o] Error 1
make: *** Waiting for unfinished jobs
Remove the check variable.
Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
t a/dtc.c b/dtc.c
index cbc0193..15d2fc2 100644
--- a/dtc.c
+++ b/dtc.c
@@ -99,7 +99,7 @@ int main(int argc, char *argv[])
const char *inform = dts;
const char *outform = dts;
const char *outname = -;
- int force = 0, check = 0, sort = 0;
+ int force = 0, sort = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -111,7 +111,7 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
- while ((opt = getopt(argc, argv, hI:O:o:V:R:S:p:fcqb:vH:s)) != EOF) {
+ while ((opt = getopt(argc, argv, hI:O:o:V:R:S:p:fqb:vH:s)) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -137,9 +137,6 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
- case 'c':
- check = 1;
- break;
case 'q':
quiet++;
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v13 09/10] USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and Makefile
On Sun, Apr 03, 2011 at 04:17:24PM -0700, tmarri at apm.com wrote: +choice + prompt DWC Mode Selection + depends on USB_DWC_OTG + default DWC_HOST_ONLY + help + Select the DWC Core in OTG, Host only, or Device only mode. + +config DWC_HOST_ONLY + bool DWC Host Only Mode + +config DWC_OTG_MODE + bool DWC OTG Mode + select USB_GADGET_SELECTED It appears this depends on host support? I get compile errors when I have this selected and no host support enabled. + +config DWC_DEVICE_ONLY + bool DWC Device Only Mode + select USB_GADGET_SELECTED + +endchoice Thanks, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to supportlarge-page Nand chip
Any boot ideas ? Will the FCM load 2k and run it? Thanks for any insight you might have. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
On Tue, 28 Jun 2011 10:45:43 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2011-06-27 at 16:56 -0500, Scott Wood wrote: As is done in read_tsc() on x86, make sure that we don't return a timebase value smaller than cycle_last, which can happen on SMP if the timebases are not perfectly synchronized. It is less expensive than total enforcement of monotonicity, since we don't need to add another variable and update it on each read, but it will prevent core timekeeping functions from translating a small timebase regression into a large jump forward. Based on commit d8bb6f4c1670c8324e4135c61ef07486f7f17379 for x86. You are applying a bandage on a wooden leg here userspace (vDSO) will see the time going backward if you aren't well synchronized as well, so you're stuffed anyways. Sure -- but we should avoid turning a slight backwards drift into a huge positive offset in the kernel's calculations. One way to do that is for the generic timekeeping code to be robust against this, for all time sources. The other is to apply this sort of hack on time sources that are known to possibly go backwards. The former is the better fix IMHO, but the latter is what was already done for TSC on x86, so I went with the less intrusive change. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to supportlarge-page Nand chip
On Tue, 28 Jun 2011 11:35:12 -0400 Mike Hench mhe...@elutions.com wrote: Any boot ideas ? Will the FCM load 2k and run it? The 4K boot region will have to be split over pages 0 and 2 (2k view) or the first half of pages 0 and 1 (4k view). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] fs/hugetlbfs/inode.c: Fix pgoff alignment checking on 32-bit
From: Becky Bruce bec...@kernel.crashing.org This: vma-vm_pgoff ~(huge_page_mask(h) PAGE_SHIFT) is incorrect on 32-bit. It causes us to the pgoff with something that looks like this (for a 4m hugepage): 0xfff003ff. The mask should be flipped and *then* shifted, to give you 0x_03fff. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- fs/hugetlbfs/inode.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 7aafeb8..537a209 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -94,7 +94,7 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) vma-vm_flags |= VM_HUGETLB | VM_RESERVED; vma-vm_ops = hugetlb_vm_ops; - if (vma-vm_pgoff ~(huge_page_mask(h) PAGE_SHIFT)) + if (vma-vm_pgoff (~huge_page_mask(h) PAGE_SHIFT)) return -EINVAL; vma_len = (loff_t)(vma-vm_end - vma-vm_start); -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] hugetlb: add phys addr to struct huge_bootmem_page
From: Becky Bruce bec...@kernel.crashing.org
This is needed on HIGHMEM systems - we don't always have a virtual
address so store the physical address and map it in as needed.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
include/linux/hugetlb.h |3 +++
mm/hugetlb.c|8 +++-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 59225ef..19644e0 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -231,6 +231,9 @@ struct hstate {
struct huge_bootmem_page {
struct list_head list;
struct hstate *hstate;
+#ifdef CONFIG_HIGHMEM
+ phys_addr_t phys;
+#endif
};
struct page *alloc_huge_page_node(struct hstate *h, int nid);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6402458..2db81ea 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1105,8 +1105,14 @@ static void __init gather_bootmem_prealloc(void)
struct huge_bootmem_page *m;
list_for_each_entry(m, huge_boot_pages, list) {
- struct page *page = virt_to_page(m);
struct hstate *h = m-hstate;
+#ifdef CONFIG_HIGHMEM
+ struct page *page = pfn_to_page(m-phys PAGE_SHIFT);
+ free_bootmem_late((unsigned long)m,
+ sizeof(struct huge_bootmem_page));
+#else
+ struct page *page = virt_to_page(m);
+#endif
__ClearPageReserved(page);
WARN_ON(page_count(page) != 1);
prep_compound_huge_page(page, h-order);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc: mem_init should call memblock_is_reserved with phys_addr_t
From: Becky Bruce bec...@kernel.crashing.org
This has been broken for a while but hasn't been an issue until
now because nobody was reserving regions at high addresses.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/mm/mem.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 57e545b..097b288 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -337,8 +337,9 @@ void __init mem_init(void)
highmem_mapnr = lowmem_end_addr PAGE_SHIFT;
for (pfn = highmem_mapnr; pfn max_mapnr; ++pfn) {
+ phys_addr_t paddr = (phys_addr_t)pfn PAGE_SHIFT;
struct page *page = pfn_to_page(pfn);
- if (memblock_is_reserved(pfn PAGE_SHIFT))
+ if (memblock_is_reserved(paddr))
continue;
ClearPageReserved(page);
init_page_count(page);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5] powerpc: Create next_tlbcam_idx percpu variable for FSL_BOOKE
From: Becky Bruce bec...@kernel.crashing.org
This is used to round-robin TLBCAM entries.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/mmu.h |5 +
arch/powerpc/kernel/smp.c |4
arch/powerpc/mm/mem.c |9 +
arch/powerpc/mm/tlb_nohash.c |6 ++
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 4138b21..b427a55 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -115,6 +115,11 @@
#ifndef __ASSEMBLY__
#include asm/cputable.h
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#include asm/percpu.h
+DECLARE_PER_CPU(int, next_tlbcam_idx);
+#endif
+
static inline int mmu_has_feature(unsigned long feature)
{
return (cur_cpu_spec-mmu_features feature);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 2975f64..3c9681a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -313,6 +313,10 @@ struct thread_info *current_set[NR_CPUS];
static void __devinit smp_store_cpu_info(int id)
{
per_cpu(cpu_pvr, id) = mfspr(SPRN_PVR);
+#ifdef CONFIG_PPC_FSL_BOOK3E
+ per_cpu(next_tlbcam_idx, id)
+ = (mfspr(SPRN_TLB1CFG) TLBnCFG_N_ENTRY) - 1;
+#endif
}
void __init smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 097b288..7209901 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -353,6 +353,15 @@ void __init mem_init(void)
}
#endif /* CONFIG_HIGHMEM */
+#if defined(CONFIG_PPC_FSL_BOOK3E) !defined(CONFIG_SMP)
+ /*
+* If smp is enabled, next_tlbcam_idx is initialized in the cpu up
+* functions do it here for the non-smp case.
+*/
+ per_cpu(next_tlbcam_idx, smp_processor_id()) =
+ (mfspr(SPRN_TLB1CFG) TLBnCFG_N_ENTRY) - 1;
+#endif
+
printk(KERN_INFO Memory: %luk/%luk available (%luk kernel code,
%luk reserved, %luk data, %luk bss, %luk init)\n,
nr_free_pages() (PAGE_SHIFT-10),
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 5693499..ea037ba 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -102,6 +102,12 @@ unsigned long linear_map_top; /* Top of linear
mapping */
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_PPC_FSL_BOOK3E
+/* next_tlbcam_idx is used to round-robin tlbcam entry assignment */
+DEFINE_PER_CPU(int, next_tlbcam_idx);
+EXPORT_PER_CPU_SYMBOL(next_tlbcam_idx);
+#endif
+
/*
* Base TLB flushing operations:
*
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] powerpc: Hugetlb for BookE
From: Becky Bruce bec...@kernel.crashing.org
Enable hugepages on Freescale BookE processors. This allows the kernel to
use huge TLB entries to map pages, which can greatly reduce the number of
TLB misses and the amount of TLB thrashing experienced by applications with
large memory footprints. Care should be taken when using this on FSL
processors, as the number of large TLB entries supported by the core is low
(16-64) on current processors.
The supported set of hugepage sizes include 4m, 16m, 64m, 256m, and 1g.
Page sizes larger than the max zone size are called gigantic pages and
must be allocated on the command line (and cannot be deallocated).
This is currently only fully implemented for Freescale 32-bit BookE
processors, but there is some infrastructure in the code for
64-bit BooKE.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
arch/powerpc/Kconfig |3 +-
arch/powerpc/include/asm/hugetlb.h | 63 +-
arch/powerpc/include/asm/mmu-book3e.h |7 +
arch/powerpc/include/asm/mmu-hash64.h |3 +-
arch/powerpc/include/asm/mmu.h | 18 +-
arch/powerpc/include/asm/page.h| 31 +++-
arch/powerpc/include/asm/page_64.h | 11 -
arch/powerpc/include/asm/pte-book3e.h |3 +
arch/powerpc/kernel/head_fsl_booke.S | 133 ++--
arch/powerpc/mm/Makefile |1 +
arch/powerpc/mm/hash_utils_64.c|3 -
arch/powerpc/mm/hugetlbpage-book3e.c | 121 ++
arch/powerpc/mm/hugetlbpage.c | 379
arch/powerpc/mm/init_32.c |9 +
arch/powerpc/mm/mem.c |5 +
arch/powerpc/mm/mmu_context_nohash.c |5 +
arch/powerpc/mm/pgtable.c |3 +-
arch/powerpc/mm/tlb_low_64e.S | 24 +-
arch/powerpc/mm/tlb_nohash.c | 46 -
arch/powerpc/platforms/Kconfig.cputype |4 +-
20 files changed, 766 insertions(+), 106 deletions(-)
create mode 100644 arch/powerpc/mm/hugetlbpage-book3e.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2729c66..b7af257 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -426,8 +426,7 @@ config ARCH_POPULATES_NODE_MAP
def_bool y
config SYS_SUPPORTS_HUGETLBFS
- def_bool y
- depends on PPC_BOOK3S_64
+ bool
source mm/Kconfig
diff --git a/arch/powerpc/include/asm/hugetlb.h
b/arch/powerpc/include/asm/hugetlb.h
index 5856a66..8600493 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -1,15 +1,60 @@
#ifndef _ASM_POWERPC_HUGETLB_H
#define _ASM_POWERPC_HUGETLB_H
+#ifdef CONFIG_HUGETLB_PAGE
#include asm/page.h
+extern struct kmem_cache *hugepte_cache;
+extern void __init reserve_hugetlb_gpages(void);
+
+static inline pte_t *hugepd_page(hugepd_t hpd)
+{
+ BUG_ON(!hugepd_ok(hpd));
+ return (pte_t *)((hpd.pd ~HUGEPD_SHIFT_MASK) | PD_HUGE);
+}
+
+static inline unsigned int hugepd_shift(hugepd_t hpd)
+{
+ return hpd.pd HUGEPD_SHIFT_MASK;
+}
+
+static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
+ unsigned pdshift)
+{
+ /*
+* On 32-bit, we have multiple higher-level table entries that point to
+* the same hugepte. Just use the first one since they're all
+* identical. So for that case, idx=0.
+*/
+ unsigned long idx = 0;
+
+ pte_t *dir = hugepd_page(*hpdp);
+#ifdef CONFIG_PPC64
+ idx = (addr ((1UL pdshift) - 1)) hugepd_shift(*hpdp);
+#endif
+
+ return dir + idx;
+}
+
pte_t *huge_pte_offset_and_shift(struct mm_struct *mm,
unsigned long addr, unsigned *shift);
void flush_dcache_icache_hugepage(struct page *page);
+#if defined(CONFIG_PPC_MM_SLICES) || defined(CONFIG_PPC_SUBPAGE_PROT)
int is_hugepage_only_range(struct mm_struct *mm, unsigned long addr,
unsigned long len);
+#else
+static inline int is_hugepage_only_range(struct mm_struct *mm,
+unsigned long addr,
+unsigned long len)
+{
+ return 0;
+}
+#endif
+
+void book3e_hugetlb_preload(struct mm_struct *mm, unsigned long ea, pte_t pte);
+void flush_hugetlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void hugetlb_free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
unsigned long end, unsigned long floor,
@@ -50,8 +95,11 @@ static inline void set_huge_pte_at(struct mm_struct *mm,
unsigned long addr,
static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
{
- unsigned long old = pte_update(mm, addr, ptep, ~0UL, 1);
- return __pte(old);
+#ifdef CONFIG_PPC64
+ return __pte(pte_update(mm, addr, ptep, ~0UL, 1));
+#else
+ return
Re: [PATCH 2/5] hugetlb: add phys addr to struct huge_bootmem_page
On Tue, 2011-06-28 at 14:54 -0500, Becky Bruce wrote:
struct page *alloc_huge_page_node(struct hstate *h, int nid);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6402458..2db81ea 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1105,8 +1105,14 @@ static void __init
gather_bootmem_prealloc(void)
struct huge_bootmem_page *m;
list_for_each_entry(m, huge_boot_pages, list) {
- struct page *page = virt_to_page(m);
struct hstate *h = m-hstate;
+#ifdef CONFIG_HIGHMEM
+ struct page *page = pfn_to_page(m-phys
PAGE_SHIFT);
+ free_bootmem_late((unsigned long)m,
+ sizeof(struct huge_bootmem_page));
+#else
+ struct page *page = virt_to_page(m);
+#endif
__ClearPageReserved(page);
Why do you add free_bootmem_late() in the highmem case and not the
normal case ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4]PPC4xx: Adding PCI(E) MSI support
On Thu, May 26, 2011 at 03:24:44PM +1000, Benjamin Herrenschmidt wrote:
Please check the result and send any fixup patch that might be
necessary.
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+struct resource res, struct ppc4xx_msi *msi)
+{
+
snip
+
+ msi-msi_dev = of_find_node_by_name(NULL, ppc4xx-msi);
+ if (msi-msi_dev)
+ return -ENODEV;
This does not look correct. I guess it should probably read
if (!msi-msi_dev) .
Ayman
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4]PPC4xx: Adding PCI(E) MSI support
On Tue, 2011-06-28 at 17:31 -0500, Ayman El-Khashab wrote:
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+struct resource res, struct
ppc4xx_msi *msi)
+{
+
snip
+
+ msi-msi_dev = of_find_node_by_name(NULL, ppc4xx-msi);
+ if (msi-msi_dev)
+ return -ENODEV;
This does not look correct. I guess it should probably read
if (!msi-msi_dev) .
Indeed, that looks bogus. Rupjyoti, please test and send fixes if
necessary, obviously this code has not been tested.
This is not part of the bits I fixed up so I looks to me like the
original patch was wrong (and thus obviously untested !!!)
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
On Tue, 2011-06-28 at 11:14 -0500, Scott Wood wrote: You are applying a bandage on a wooden leg here userspace (vDSO) will see the time going backward if you aren't well synchronized as well, so you're stuffed anyways. Sure -- but we should avoid turning a slight backwards drift into a huge positive offset in the kernel's calculations. One way to do that is for the generic timekeeping code to be robust against this, for all time sources. The other is to apply this sort of hack on time sources that are known to possibly go backwards. The former is the better fix IMHO, but the latter is what was already done for TSC on x86, so I went with the less intrusive change. Ok two things. One is first fix the comments then to stop mentioning TSC :-) Second is, I still don't think it's right. There's an expectation on powerpc that the timebase works properly. If not, you have a userspace visible breakage. There's no such thing as a small drift. We assume no difference is visible to software, period. We make hard assumptions here and in various places actually. So if you want to do that test, I would require that you also add a warning, of the _rate_limited or _once, kind, indicating to the user that something's badly wrong. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
On Wed, 29 Jun 2011 09:25:08 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2011-06-28 at 11:14 -0500, Scott Wood wrote: You are applying a bandage on a wooden leg here userspace (vDSO) will see the time going backward if you aren't well synchronized as well, so you're stuffed anyways. Sure -- but we should avoid turning a slight backwards drift into a huge positive offset in the kernel's calculations. One way to do that is for the generic timekeeping code to be robust against this, for all time sources. The other is to apply this sort of hack on time sources that are known to possibly go backwards. The former is the better fix IMHO, but the latter is what was already done for TSC on x86, so I went with the less intrusive change. Ok two things. One is first fix the comments then to stop mentioning TSC :-) Doh, sorry... Second is, I still don't think it's right. There's an expectation on powerpc that the timebase works properly. If not, you have a userspace visible breakage. As the changelog notes, this isn't a full enforement of monotonicity, it's a way to avoid specific problems where the generic kernel timekeeping code blows up if it goes backwards. Fixing userspace reads to be fully monotonic would be nice too, but it's a separate issue from the kernel throwing a timer into the distant future because the timebase went backwards one tick. There's no such thing as a small drift. We assume no difference is visible to software, period. On what do we base this assumption, and what does making the assumption buy us? Will smp-tbsync.c always converge on perfect sync (it has a limit on how long it will try, and the only indication it failed is a pr_debug)? Will the timebase always increment on all cores at the same time, including on emulated hardware? We had a bug in U-Boot's timebase sync where the boot core would sometimes be one tick faster than the other cores. It's been fixed, but there are probably people still running the old U-Boot. It seems like the kind of thing where defensive robustness is called for, like timing out instead of hanging if a hardware register never flips the bit we're waiting for. We make hard assumptions here and in various places actually. Are there any in the kernel that this doesn't cover? So if you want to do that test, I would require that you also add a warning, of the _rate_limited or _once, kind, indicating to the user that something's badly wrong. OK. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
Ok two things. One is first fix the comments then to stop mentioning TSC :-) Doh, sorry... Second is, I still don't think it's right. There's an expectation on powerpc that the timebase works properly. If not, you have a userspace visible breakage. As the changelog notes, this isn't a full enforement of monotonicity, it's a way to avoid specific problems where the generic kernel timekeeping code blows up if it goes backwards. Fixing userspace reads to be fully monotonic would be nice too, but it's a separate issue from the kernel throwing a timer into the distant future because the timebase went backwards one tick. I don't think we ever want to fix userspace... how would you fix the vDSO gettimeofday implementation for example since the vDSO has no storage ? There's no such thing as a small drift. We assume no difference is visible to software, period. On what do we base this assumption, and what does making the assumption buy us? We base this assumption on what I believe is an architectural requirement tho of course it's not worded very explicitely, and probably just derived from the architecture statement that the timebase can always be used as a monotonic source of time. It has always been the assumption of Linux/ppc port that the timebase cannot be observed going backward accross the SMP fabric. They -MUST- be sourced from the same clock (not drift) and the initial synchronization must be good enough to make it impossible to observe it going backward. What it does buy us is a lot of complexity avoided in the time keeping code and the ability to have things like vDSO gettimeofday/clock_gettime, ie, a very fast path to reliably timestamp things (which is among others a serious benefit for networking). Will smp-tbsync.c always converge on perfect sync (it has a limit on how long it will try, and the only indication it failed is a pr_debug)? Will the timebase always increment on all cores at the same time, including on emulated hardware? smp-tbsync.c is and has always been a workaround for broken HW. Anybody with half a clue should follow the recommendation of the architecture (this one is actually spelled out, but as a recommendation only) to have a TB enable pin and use it to perform a perfect sync at boot time. We had a bug in U-Boot's timebase sync where the boot core would sometimes be one tick faster than the other cores. It's scary to think that your cores TBs seem to be soured from different clock sources... ie even if you fix uBoot, can you guarantee they won't drift ? I hope so ... I would consider that an unfixable architecture violation and I am not at this stage keen on implementing the necessary workarounds in Linux (the userspace case is nasty, really nasty). PowerPC always prided itself on having a sane time base mechanism unlike x86, please don't tell me that you guys are now breaking that assumption. It's been fixed, but there are probably people still running the old U-Boot. It seems like the kind of thing where defensive robustness is called for, like timing out instead of hanging if a hardware register never flips the bit we're waiting for. No, you'll just hide the problem from the kernel and horrible unexplainable things will happen in userspace. At the VERY LEAST you must warn very loudly if you detect this is happening. We make hard assumptions here and in various places actually. Are there any in the kernel that this doesn't cover? Check gtod implementation, I'm not sure whether that's enough at this stage or not for it, and then there's the vDSO of course. Not sure what's up with sched_clock() and whether that has similar constraints. So if you want to do that test, I would require that you also add a warning, of the _rate_limited or _once, kind, indicating to the user that something's badly wrong. OK. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/4xx: Regression failed on sil24 (and other) drivers
On Mon, 2011-06-27 at 06:31 -0500, Ayman El-Khashab wrote:
On Mon, Jun 27, 2011 at 08:19:56PM +1000, Benjamin Herrenschmidt wrote:
On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote:
I noticed during a recent development with the 460SX that a
simple device that once worked stopped. I did a bisect to
find the offending commit and it turns out to be this one:
0e52247a2ed1f211f0c4f682dc999610a368903f is the first bad
commit
commit 0e52247a2ed1f211f0c4f682dc999610a368903f
Author: Cam Macdonell c...@cs.ualberta.ca
Date: Tue Sep 7 17:25:20 2010 -0700
PCI: fix pci_resource_alignment prototype
Ok, let's see what I can dig out of those logs (sorry for the delay)
Let's start with iomem ioport, stripped of the legacy common stuff:
/proc/iomem, bad:
e-e7fff : /plb/pciex@d
e-e7fff : :40:00.0
e8000-e : /plb/pciex@d2000
e8000-e : 0001:80:00.0
good:
e-e7fff : /plb/pciex@d
e8000-e : /plb/pciex@d2000
e8000-e800f : PCI Bus 0001:81
e8000-e80001fff : 0001:81:00.0
e8000-e80001fff : sata_sil24
e80002000-e8000207f : 0001:81:00.0
e80002000-e8000207f : sata_sil24
So now that's interesting, you have a device at :40:00.0 that
appears on your first PHB in the bad case and doesn't show up in the
good case.
In addition, on the other PHB, the bus itself doesn't show up in the
bad case. (Let's ignore IOs and focus on mem. for now).
Let's see what lead us to that from the logs. First setup before probing
is all identical. The device at :40:00.0 is detected in both cases,
it's the root complex bridge. So the scanning is identical as expected.
Now the fixup/resource allocation, we start seeing some differences:
Bad:
pci :40:00.0: BAR 0: assigned [mem 0xe-0xe7fff pref]
pci :40:00.0: BAR 0: set to [mem 0xe-0xe7fff pref] (PCI address
[0x8000-0x]
vs Good:
pci :40:00.0: BAR 0: can't assign mem pref (size 0x8000)
So the bad case succeeds in giving out resources to the root complex,
while the good case fails... fun.
And similarily for the other PHB, bad:
pci 0001:80:00.0: BAR 0: assigned [mem 0xe8000-0xe pref]
pci 0001:80:00.0: BAR 0: set to [mem 0xe8000-0xe pref] (PCI address
[0x8000-0x]
vs good:
pci 0001:80:00.0: BAR 0: can't assign mem pref (size 0x8000)
This then goes down to the bad case:
pci 0001:80:00.0: BAR 8: can't assign mem (size 0x10)
pci 0001:80:00.0: BAR 7: assigned [io 0xfffe1000-0xfffe1fff]
pci 0001:81:00.0: BAR 2: can't assign mem (size 0x2000)
pci 0001:81:00.0: BAR 0: can't assign mem (size 0x80)
while the good one succeeds assigning BAR 8,2 and 0 :
pci 0001:80:00.0: BAR 8: assigned [mem 0xe8000-0xe800f]
pci 0001:81:00.0: BAR 2: assigned [mem 0xe8000-0xe80001fff 64bit]
pci 0001:81:00.0: BAR 2: set to [mem 0xe8000-0xe80001fff 64bit] (PCI
address [0x8000-0x80001fff]
pci 0001:81:00.0: BAR 0: assigned [mem 0xe80002000-0xe8000207f 64bit]
pci 0001:81:00.0: BAR 0: set to [mem 0xe80002000-0xe8000207f 64bit] (PCI
address [0x80002000-0x8000207f]
It looks to me like the BAR 0 of the host bridges are basically taking the
resource aways from the rest of the devices. Now BAR 0 are not bridge
resources, which would have been OK, but they are MMIO resources of the
bridge itself.
On 44x, the problem is that those bridges (stupidly) expose BARs that represent
main memory (inbound DMA). It would make sense if these weren't host bridges
but in this case that's totally non sensical (and thus IMHO a HW bug).
I thought we had code to hide them to avoid that problem, so I wonder what's
going on... If you look at arch/powerpc/sysdev/ppc4xx_pci.c, there's this
quirk:
static void fixup_ppc4xx_pci_bridge(struct pci_dev *dev)
{
struct pci_controller *hose;
int i;
if (dev-devfn != 0 || dev-bus-self != NULL)
return;
hose = pci_bus_to_host(dev-bus);
if (hose == NULL)
return;
if (!of_device_is_compatible(hose-dn, ibm,plb-pciex)
!of_device_is_compatible(hose-dn, ibm,plb-pcix)
!of_device_is_compatible(hose-dn, ibm,plb-pci))
return;
if (of_device_is_compatible(hose-dn, ibm,plb440epx-pci) ||
of_device_is_compatible(hose-dn, ibm,plb440grx-pci)) {
hose-indirect_type |= PPC_INDIRECT_TYPE_BROKEN_MRM;
}
/* Hide the PCI host BARs from the kernel as their content doesn't
* fit well in the resource management
*/
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
dev-resource[i].start = dev-resource[i].end = 0;
dev-resource[i].flags = 0;
}
printk(KERN_INFO PCI: Hiding 4xx host bridge resources %s\n,
pci_name(dev));
}
DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID,
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
Before I comment on this last one, a quick Q. for Dave: Do you want to
handle this or should I merge it via powerpc.git ? (It depends on
another change to the arch code to expose the SCOM functions that it
uses, and that patch is going to be in my -next branch).
Now some remaining small nits:
On Fri, 2011-06-17 at 17:10 +0400, Dmitry Eremin-Solenikov wrote:
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
drivers/cpufreq/Kconfig |5 +
drivers/cpufreq/Kconfig.powerpc |7 +
drivers/cpufreq/Makefile|5 +
drivers/cpufreq/maple-cpufreq.c | 314
+++
If we're going to have a Kconfig.powerpc, should we maybe just have a
powerpc subdirectory instead with the driver in it ?
I'm happy at some later point to try moving some of my other ones there.
.../...
+ /* Look for the powertune data in the device-tree */
+ maple_pmode_data = of_get_property(cpunode, power-mode-data, psize);
+ if (!maple_pmode_data) {
+ DBG(No power-mode-data !\n);
+ goto bail_noprops;
+ }
+ maple_pmode_max = psize / sizeof(u32) - 1;
Do you get that property in your device-tree ? Or have you modified your
firmware ? If that requires a modified firmware, you should probably put
at least a link indicating where to get it somewhere and display a nicer
error code.
Also this driver is specific to the Maple HW, you don't want it to kick
in and mess around on ... an Apple G5 for example. So stick somewhere a
if (!machine_is(maple))
return 0;
+ printk(KERN_INFO Registering G5 CPU frequency driver\n);
s/G5/Maple
+ printk(KERN_INFO Frequency method: SCOM, Voltage method: none\n);
This is useless.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mm: Move definition of MIN_MEMORY_BLOCK_SIZE to a header
On Tue, 2011-06-14 at 10:57 +1000, Benjamin Herrenschmidt wrote:
The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c
files, and I need it in a third one to fix a powerpc bug, so let's
first move it into a header
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Ingo, Thomas: Who needs to ack the x86 bit ? I'd like to send that
to Linus asap with the powerpc fix.
Anybody ? Allo ?
I'm happy to send that to Linus myself but I'd like at least on or two
acks :-)
Cheers,
Ben.
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index d865c4a..bbaaa00 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -28,6 +28,7 @@
#include linux/poison.h
#include linux/dma-mapping.h
#include linux/module.h
+#include linux/memory.h
#include linux/memory_hotplug.h
#include linux/nmi.h
#include linux/gfp.h
@@ -895,8 +896,6 @@ const char *arch_vma_name(struct vm_area_struct *vma)
}
#ifdef CONFIG_X86_UV
-#define MIN_MEMORY_BLOCK_SIZE (1 SECTION_SIZE_BITS)
-
unsigned long memory_block_size_bytes(void)
{
if (is_uv_system()) {
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 9f9b235..45d7c8f 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -30,7 +30,6 @@
static DEFINE_MUTEX(mem_sysfs_mutex);
#define MEMORY_CLASS_NAMEmemory
-#define MIN_MEMORY_BLOCK_SIZE(1 SECTION_SIZE_BITS)
static int sections_per_block;
diff --git a/include/linux/memory.h b/include/linux/memory.h
index e1e3b2b..935699b 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -20,6 +20,8 @@
#include linux/compiler.h
#include linux/mutex.h
+#define MIN_MEMORY_BLOCK_SIZE (1 SECTION_SIZE_BITS)
+
struct memory_block {
unsigned long start_section_nr;
unsigned long end_section_nr;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
On Wed, Jun 29, 2011 at 01:28:30PM +1000, Ben Herrenschmidt wrote: Before I comment on this last one, a quick Q. for Dave: Do you want to handle this or should I merge it via powerpc.git ? (It depends on another change to the arch code to expose the SCOM functions that it uses, and that patch is going to be in my -next branch). If you're carrying the dependancy, it sounds like it would make more sense for you to carry this too. There are some changes to the Kconfig/Makefile in drivers/cpufreq in my tree for 3.1 already, so you might get a collision when both trees end up in next subsequently Linus' tree. Just trivial changes though. --- drivers/cpufreq/Kconfig |5 + drivers/cpufreq/Kconfig.powerpc |7 + drivers/cpufreq/Makefile|5 + drivers/cpufreq/maple-cpufreq.c | 314 +++ If we're going to have a Kconfig.powerpc, should we maybe just have a powerpc subdirectory instead with the driver in it ? I'm happy at some later point to try moving some of my other ones there. So far we haven't bothered with additional subarch drivers/ directories for x86/arm. I'm not against the idea. As more archs move over, I could see drivers/cpufreq/ getting more cluttered. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
perf_event_open system call support in powerpc
Hello, I am new to the powerpc architecture and I am trying to use perf_event_open() system call for power pc architecture (e500mc) using 2.6.32 kernel distribution. Is this system call number supported for power pc architecture? If yes, is there something similar to arch/x86/kernel/syscall_table_32.S listing for powerpc that indicates the number for the above system call? Thanks in advance for assisting me. Please email me at ashwath.narasim...@oneconvergence.com -- -Ash ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] Kexec support for PPC440x
On 06/03/11 19:23, Sebastian Andrzej Siewior wrote: Suzuki Poulose wrote: The way you setup the 1:1 mapping should be close to what you are doing on kernel entry.Isn't it possible to include the file here and in the entry code? I will make this change and resend the patch. I took a look at the way we do it at kernel entry. It looks more cleaner to leave it untouched. Especially, when we add the support for 47x in the future, the code will become more unreadable. What do you think ? So the entry code has one 256MiB mapping, you need 8 of those. Entry goes for TLB 63 and you need to be flexible and avoid TLB 63 :). So after all you don't have that much in common with the entry code. If you look at the FSL-book code then you will notice that I tried to share some code. I don't understand why you don't flip the address space bit. On fsl we setup the tmp mapping in the other address space so we don't have two mappings for the same address. The entry code could be doing this with STS bit, I'm not sure. I am not sure if I understood this correctly. Could you explain how could there be two mappings for the same address ? We are setting up 1:1 mapping for 0-2GiB and the only mapping that could exist (in other words, not invalidated) is PAGE_OFFSET mapping. Since PAGE_OFFSET 2GiB we won't have multiple mappings. Or in other words we could limit KEXEC_*_MEMORY_LIMIT to PAGE_OFFSET to make sure the crossing doesn't occur. The kernel entry code sets up the mapping without a tmp mapping in 44x. i.e, it uses the mapping setup by the firmware/boot loader. Thanks Suzuki ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
