* RE: userspace o/p to kernel buffer
From: Jenkins, Clive @ 2012-04-13 11:15 UTC (permalink / raw)
To: Sumesh Kaana, linuxppc-dev
In-Reply-To: <BLU124-W23D62A308B2F33EC51A3D2B43B0@phx.gbl>
> How do I capture all the output of user-space programs into
> a kernel buffer so that I can later read it using debugger ?
>=A0My board doesn't have a console (no serial, no network).
Assuming you are using a shell to start your user-space
programs, you could easily redirect output to /dev/kmsg
then find it in the dmesg buffer afterwards. You may need
to increase the buffer size.
Clive
^ permalink raw reply
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Jeff Garzik @ 2012-04-13 14:20 UTC (permalink / raw)
To: Thang Nguyen
Cc: Sergei Shtylyov, Phong Vo, devicetree-discuss, linux-kernel,
Rob Herring, linux-ide, Paul Mackerras, linuxppc-dev
In-Reply-To: <3445364d6d28c2b6ae19817fe6851452@mail.gmail.com>
On 04/13/2012 03:18 AM, Thang Nguyen wrote:
> Thanks Jeff and Sergei,
>
> As your suggestion, I will separate the patch into smaller patches and
> support more features on the SATA DWC driver. The patches I intend to do
> on the SATA DWC are as below:
> - Support hardreset: currently the hardreset is not supported. This
> causes sometime the SATA driver does cause kernel crash because of
> not-determined state.
> - Let device tree specified DMA channel: currently only channel 0 is
> supported (number of channel is set to 1). If device tree not specified
> DMA channel, channel 0 will be used as default.
> - Support ATAPI.
> - Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
> for QC completion: transfer completion and DMA transfer completion
> interrupt. The current code wait for both 2 interrupts occur before
> calling qc_complete. This will make out-of-sync state when an interrupt
> lost or when errors occur. The change will process DMA register when DMA
> transfer complete interrupt occur and call qc_issue when command
> completion interrupt occur.
> - Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
> - Support Port Multiplier.
> - Support 2 SATA ports on Maui.
Sounds good, thanks for splitting up the patch into smaller pieces. The
main goal is that separate logical changes should go into separate patches.
Jeff
^ permalink raw reply
* Re: [PATCH] powerpc/e6500: add CPU_FTR_EMB_HV to CPU table
From: Kumar Gala @ 2012-04-13 15:29 UTC (permalink / raw)
To: Scott Wood; +Cc: Marcelo Tosatti, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20120411202752.GA12204@schlenkerla.am.freescale.net>
On Apr 11, 2012, at 3:27 PM, Scott Wood wrote:
> e6500 support (commit 10241842fbe900276634fee8d37ec48a7d8a762f,
> "powerpc: Add initial e6500 cpu support" and the introduction of
> CPU_FTR_EMB_HV (commit 73196cd364a2d972d73fa08da9d81ca3215bed68,
> "KVM: PPC: e500mc support") collided during merge, leaving e6500's CPU
> table entry missing CPU_FTR_EMB_HV.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Fixup patch for the KVM merge as requested by Marcelo.
>
> arch/powerpc/include/asm/cputable.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* patch "TTY: hvc, fix TTY refcounting" added to tty tree
From: gregkh @ 2012-04-13 17:54 UTC (permalink / raw)
To: jslaby, gregkh, linuxppc-dev, mikey, sfr
This is a note to let you know that I've just added the patch titled
TTY: hvc, fix TTY refcounting
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also will be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From a2f892060f174e5f90041167ca00eb9e68badcb8 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:31:32 +0200
Subject: TTY: hvc, fix TTY refcounting
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.10
^ permalink raw reply related
* P4080 target has 16G memory stability issues ...
From: Robert Sciuk @ 2012-04-13 20:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: u-boot-request
Dear list(s),
Our P4080 target board is using 2 SODIMM's on each of 2 Controllers
(4x4G DDR3), and we are seeing some memory problems (linux panics) when
beating up large amounts of memory (just under the 16G), on multiple
threads (7 or 8 CPUs).
Our DDR3 configuration is derived from the SPD dump of U-Boot, and we
are using a version based upon the 2011.09 release of U-Boot. Our
firmware memory test, limited as it is to 2G chunks, and a single CPU
shows no problem, it is only using a small test program under Linux and
using multiple cpu's that we see the problems, and we can reproduce the
problem at will, although reducing our memory speed via the RCW does
seem to ameliorate the problem somewhat.
Questions:
- is anyone using a similar configuration?
- is anyone aware of limitations in the U-Boot 2011.09R version
of the mpc8xxx/ddr/* code we need to be aware of?
- any ideas?
We've been pounding our heads on this for a while now, and I'm just
wondering if we are covering old territory here.
Cheers,
Rob.
Robert Sciuk
Senior Designer, R&D.
905.738.3741 xt 22621
^ permalink raw reply
* [PATCH] powerpc/fsl: Distribute interrupts on all CPUs by default
From: Kim Phillips @ 2012-04-13 22:26 UTC (permalink / raw)
To: linuxppc-dev
At least for crypto/IPSec, doing so provides users with a better
performance experience out of the box.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..13e7f3c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -32,6 +32,7 @@ CONFIG_HIGH_RES_TIMERS=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_KEXEC=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_FSL_LBC=y
CONFIG_PCI=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 7ed8d4c..00c49b9 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -23,6 +23,7 @@ CONFIG_P5020_DS=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_RAPIDIO=y
CONFIG_FSL_RIO=y
CONFIG_NET=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index abdcd31..608ccc6 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -45,6 +45,7 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
CONFIG_MATH_EMULATION=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_PCI=y
CONFIG_PCI_MSI=y
--
1.7.10
^ permalink raw reply related
* [PATCH 1/4] powerpc/mpic_msgr: fix compile error when SMP disabled
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0:
~/arch/powerpc/include/asm/mpic_msgr.h: In function 'mpic_msgr_set_destination':
~/arch/powerpc/include/asm/mpic_msgr.h:117:2:
error: implicit declaration of function 'get_hard_smp_processor_id'
make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/include/asm/mpic_msgr.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
index 3ec37dc..326d33c 100644
--- a/arch/powerpc/include/asm/mpic_msgr.h
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/spinlock.h>
+#include <asm/smp.h>
struct mpic_msgr {
u32 __iomem *base;
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/4] powerpc/mpic_msgr: add lock for MPIC message global variable
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-1-git-send-email-Mingkai.hu@freescale.com>
Also fix issue of accessing invalid msgr pointer issue. The local
msgr pointer in fucntion mpic_msgr_get will be accessed before
getting a valid address which will cause kernel crash.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 6e7fa38..dc1cfe3 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -27,6 +27,7 @@
static struct mpic_msgr **mpic_msgrs;
static unsigned int mpic_msgr_count;
+static DEFINE_RAW_SPINLOCK(msgrs_lock);
static inline void _mpic_msgr_mer_write(struct mpic_msgr *msgr, u32 value)
{
@@ -56,12 +57,11 @@ struct mpic_msgr *mpic_msgr_get(unsigned int reg_num)
if (reg_num >= mpic_msgr_count)
return ERR_PTR(-ENODEV);
- raw_spin_lock_irqsave(&msgr->lock, flags);
- if (mpic_msgrs[reg_num]->in_use == MSGR_FREE) {
- msgr = mpic_msgrs[reg_num];
+ raw_spin_lock_irqsave(&msgrs_lock, flags);
+ msgr = mpic_msgrs[reg_num];
+ if (msgr->in_use == MSGR_FREE)
msgr->in_use = MSGR_INUSE;
- }
- raw_spin_unlock_irqrestore(&msgr->lock, flags);
+ raw_spin_unlock_irqrestore(&msgrs_lock, flags);
return msgr;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/4] powerpc/mpic_msgr: fix offset error when setting mer register
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-2-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index dc1cfe3..483d8fa 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -228,7 +228,7 @@ static __devinit int mpic_msgr_probe(struct platform_device *dev)
reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
- msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
+ msgr->mer = (u32 *)((u8 *)msgr->base + MPIC_MSGR_MER_OFFSET);
msgr->in_use = MSGR_FREE;
msgr->num = i;
raw_spin_lock_init(&msgr->lock);
--
1.7.5.1
^ permalink raw reply related
* [PATCH 4/4] powerpc/mpc85xx: add MPIC message dts node
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-3-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 +++++
2 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
new file mode 100644
index 0000000..1cf0b77
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
@@ -0,0 +1,43 @@
+/*
+ * PQ3 MPIC Message (Group B) device tree stub [ controller @ offset 0x42400 ]
+ *
+ * Copyright 2012 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.
+ */
+
+message@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ interrupts = <
+ 0xb4 2 0 0
+ 0xb5 2 0 0
+ 0xb6 2 0 0
+ 0xb7 2 0 0>;
+};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
index fdedf7b..71c30eb 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
@@ -53,6 +53,16 @@ timer@41100 {
3 0 3 0>;
};
+message@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ interrupts = <
+ 0xb0 2 0 0
+ 0xb1 2 0 0
+ 0xb2 2 0 0
+ 0xb3 2 0 0>;
+};
+
msi@41600 {
compatible = "fsl,mpic-msi";
reg = <0x41600 0x80>;
--
1.7.5.1
^ permalink raw reply related
* PPC / USB: kernel hangs in warm boot on 8513 in fsl-ehci
From: Anthony Foiani @ 2012-04-16 4:45 UTC (permalink / raw)
To: linux-usb, linuxppc-dev
Greetings.
I'm working on an embedded board using the MPC8315E processor. After
many (10-20+) warm boots, the kernel boot sequence will eventually
hang here:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
/immr@e0000000/usb@23000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
On a normal boot, it continues with the irq/iomem message:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
/immr@e0000000/usb@23000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io mem 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
I found a recent conversation about a similar hang on the 5020,
including one patch that had made it into -stable, along with a few
other patches that didn't but maybe should; please see my exchange
with Greg KH here:
https://lkml.org/lkml/2012/4/13/10
I did apply the most obvious set of patches to my kernel, but I'm
still seeing hangs. I'm using 3.0.6 with vendor patches and a few
other odds and ends applied. The only relevant change to fsl-ehci is
the one inspired by the patches mentioned in the above message:
------------------------------------------------------------------------
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index f380bf9..ac4ca27 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -217,6 +217,9 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
{
u32 portsc;
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ void __iomem *non_ehci = hcd->regs;
+
portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
portsc &= ~(PORT_PTS_MSK | PORT_PTS_PTW);
@@ -231,6 +234,9 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
portsc |= PORT_PTS_PTW;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ /* enable UTMI PHY */
+ setbits32(non_ehci + FSL_SOC_USB_CTRL, CTRL_UTMI_PHY_EN);
+ msleep(10);
portsc |= PORT_PTS_UTMI;
break;
case FSL_USB2_PHY_NONE:
@@ -252,21 +258,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
+ }
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 4918062..16665a4 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -45,5 +45,6 @@
#define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
#define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
#define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
+#define CTRL_UTMI_PHY_EN (1 << 9)
#define SNOOP_SIZE_2GB 0x1e
#endif /* _EHCI_FSL_H */
------------------------------------------------------------------------
But I'm still seeing the hang. (And I realize, now that I'm not head
down on the project, that the snooping fixes are probably irrelevant
for a single-core system like mine.)
Does anyone have suggestions on where I can go from here?
I could try the latest kernels, but due to our vendor not upstreaming
their patches, there could be some pain in that transition.
Thanks in advance for any suggestions.
Best regards,
Anthony Foiani
^ permalink raw reply related
* [PATCH] powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]
From: Paul Gortmaker @ 2012-04-16 5:04 UTC (permalink / raw)
To: benh; +Cc: David Howells, Paul Gortmaker, linuxppc-dev
The following shows up in chroma_defconfig:
CC arch/powerpc/sysdev/scom.o
arch/powerpc/sysdev/scom.c: In function 'scom_debug_init':
arch/powerpc/sysdev/scom.c:182:36: error: 'powerpc_debugfs_root' undeclared (first use in this function)
arch/powerpc/sysdev/scom.c:182:36: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [arch/powerpc/sysdev/scom.o] Error 1
make[1]: *** [arch/powerpc/sysdev/scom.o] Error 2
A bisect leads to commit 9ffc93f203c18a70623f21950f1dd473c9ec48cd
"Remove all #inclusions of asm/system.h"
Add the debug header which contains powerpc_debugfs_root.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[Ben, let me know if you want to take this or have me keep it.]
diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/sysdev/scom.c
index 49a3ece..702256a 100644
--- a/arch/powerpc/sysdev/scom.c
+++ b/arch/powerpc/sysdev/scom.c
@@ -22,6 +22,7 @@
#include <linux/debugfs.h>
#include <linux/slab.h>
#include <linux/export.h>
+#include <asm/debug.h>
#include <asm/prom.h>
#include <asm/scom.h>
--
1.7.9.1
^ permalink raw reply related
* [PATCH 1/2] powerpc: Remove empty giveup_altivec function on book3e CPUs
From: Anton Blanchard @ 2012-04-16 6:54 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Use an empty inline instead of an empty function to implement
giveup_altivec on book3e CPUs, similar to flush_altivec_to_thread.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:11.000000000 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:45.149313158 +1000
@@ -21,7 +21,6 @@ extern void disable_kernel_fp(void);
extern void enable_kernel_fp(void);
extern void flush_fp_to_thread(struct task_struct *);
extern void enable_kernel_altivec(void);
-extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
extern void __giveup_vsx(struct task_struct *);
@@ -40,10 +39,14 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
+extern void giveup_altivec(struct task_struct *);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
}
+static inline void giveup_altivec(struct task_struct *t)
+{
+}
#endif
#ifdef CONFIG_VSX
Index: linux-build/arch/powerpc/kernel/head_44x.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/head_44x.S 2012-04-16 12:56:11.976708702 +1000
+++ linux-build/arch/powerpc/kernel/head_44x.S 2012-04-16 12:56:45.153313231 +1000
@@ -778,14 +778,6 @@ _GLOBAL(__fixup_440A_mcheck)
blr
/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The 44x core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
-/*
* extern void giveup_fpu(struct task_struct *prev)
*
* The 44x core does not have an FPU.
Index: linux-build/arch/powerpc/kernel/head_fsl_booke.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/head_fsl_booke.S 2012-04-16 12:56:11.940708046 +1000
+++ linux-build/arch/powerpc/kernel/head_fsl_booke.S 2012-04-16 12:56:45.153313231 +1000
@@ -874,14 +874,6 @@ _GLOBAL(__setup_e500mc_ivors)
sync
blr
-/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The e500 core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
#ifdef CONFIG_SPE
/*
* extern void giveup_spe(struct task_struct *prev)
^ permalink raw reply
* [PATCH 2/2] powerpc: Optimise enable_kernel_altivec
From: Anton Blanchard @ 2012-04-16 6:56 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120416165459.6da18f9c@kryten>
Add two optimisations to enable_kernel_altivec:
- enable_kernel_altivec has already determined if we need to
save the previous task's state but we call giveup_altivec
in both cases, requiring an extra branch in giveup_altivec. Create
giveup_altivec_notask which only turns on the VMX bit in the
MSR.
- We write the VMX MSR bit each time we call enable_kernel_altivec
even it was already set. Check the bit and branch out if we have
already set it. The classic case for this is vectored IO
where we have to copy multiple buffers to or from userspace.
The following testcase was used to confirm this patch improves
performance:
http://ozlabs.org/~anton/junkcode/copy_to_user.c
Since the current breakpoint for using VMX in copy_tofrom_user is
4096 bytes, I'm using buffers of 4096 + 1 cacheline (4224) bytes.
A benchmark of 16 entry readvs (-s 16):
time copy_to_user -l 4224 -s 16 -i 1000000
completes 5.2% faster on a POWER7 PS700.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2012-04-16 11:35:19.000000000 +1000
+++ linux-build/arch/powerpc/kernel/process.c 2012-04-16 12:56:47.489355793 +1000
@@ -124,7 +124,7 @@ void enable_kernel_altivec(void)
if (current->thread.regs && (current->thread.regs->msr & MSR_VEC))
giveup_altivec(current);
else
- giveup_altivec(NULL); /* just enable AltiVec for kernel - force */
+ giveup_altivec_notask();
#else
giveup_altivec(last_task_used_altivec);
#endif /* CONFIG_SMP */
Index: linux-build/arch/powerpc/kernel/vector.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/vector.S 2012-04-12 20:06:21.000000000 +1000
+++ linux-build/arch/powerpc/kernel/vector.S 2012-04-16 12:56:47.489355793 +1000
@@ -89,6 +89,16 @@ _GLOBAL(load_up_altivec)
/* restore registers and return */
blr
+_GLOBAL(giveup_altivec_notask)
+ mfmsr r3
+ andis. r4,r3,MSR_VEC@h
+ bnelr /* Already enabled? */
+ oris r3,r3,MSR_VEC@h
+ SYNC
+ MTMSRD(r3) /* enable use of VMX now */
+ isync
+ blr
+
/*
* giveup_altivec(tsk)
* Disable VMX for the task given as the argument,
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:45.149313158 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:47.489355793 +1000
@@ -40,6 +40,7 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
extern void giveup_altivec(struct task_struct *);
+extern void giveup_altivec_notask(void);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
^ permalink raw reply
* Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
From: Linus Walleij @ 2012-04-16 7:21 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arch, Grant Likely, linux-ia64, Linus Walleij, Chris Zankel,
microblaze-uclinux, linux, linux-kernel, linux-alpha, sparclinux,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1334483574-3997-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Sun, Apr 15, 2012 at 11:52 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> Rather than requiring architectures that use gpiolib but don't have any
> need to define anything custom to copy an asm/gpio.h provide a Kconfig
> symbol which architectures must select in order to include gpio.h and
> for other architectures just provide the trivial implementation directly.
>
> This makes it much easier to do gpiolib updates and is also a step toward=
s
> making gpiolib APIs available on every architecture.
>
> For architectures with existing boilerplate code leave a stub header in
> place which warns on direct inclusion of asm/gpio.h and includes
> linux/gpio.h to catch code that's doing this. =A0Direct inclusion of
> asm/gpio.h has long been deprecated.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> =A0arch/alpha/include/asm/gpio.h =A0 =A0 =A0| =A0 59 ++------------------=
----------
> =A0arch/arm/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/avr32/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/blackfin/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A0arch/ia64/include/asm/gpio.h =A0 =A0 =A0 | =A0 59 ++------------------=
----------
> =A0arch/m68k/Kconfig.cpu =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A0arch/microblaze/include/asm/gpio.h | =A0 57 ++------------------------=
---
> =A0arch/mips/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A0arch/openrisc/include/asm/gpio.h =A0 | =A0 69 ++----------------------=
-----------
> =A0arch/powerpc/include/asm/gpio.h =A0 =A0| =A0 57 ++--------------------=
-------
> =A0arch/sh/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A0arch/sparc/include/asm/gpio.h =A0 =A0 =A0| =A0 40 ++------------------=
-
> =A0arch/unicore32/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/x86/include/asm/gpio.h =A0 =A0 =A0 =A0| =A0 57 ++----------------=
-----------
> =A0arch/xtensa/include/asm/gpio.h =A0 =A0 | =A0 60 ++--------------------=
---------
> =A0drivers/gpio/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A08 ++++
> =A0include/linux/gpio.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 34 ++++++++++++=
+++++
> =A017 files changed, 81 insertions(+), 426 deletions(-)
This looks good but I think we need to page the alpha, ia64, m68k, microbla=
ze,
openrisc etc subarch maintainers on this patch so they have their say.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] [44x][KEXEC] Fix/Initialize PID to kernel PID before the TLB search
From: Suzuki K. Poulose @ 2012-04-16 7:48 UTC (permalink / raw)
To: linuxppc-dev
Initialize the PID register with kernel pid (0) before we start
setting the TLB mapping for KEXEC. Also set the MMUCR[TID] to kernel
PID.
This was spotted while testing the kexec on ISS for 47x. ISS doesn't
return a successful tlbsx for a kernel address with PID set to a user PID.
Though the hardware/qemu/simics work fine.
This patch is harmless and initializes the PID to 0 (kernel PID) which
is usually the case during a normal kernel boot. This would fix the kexec
on ISS for 440. I have tested this patch on sequoia board.
Signed-off-by: Suzuki K Poulose <suzuki@in.ibm.com>
Cc: Josh Boyer <jwboyer@us.ibm.com>
---
arch/powerpc/kernel/misc_32.S | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 7cd07b4..d7e05d2 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -761,8 +761,12 @@ relocate_new_kernel:
mr r30, r4
mr r31, r5
- /* Load our MSR_IS and TID to MMUCR for TLB search */
- mfspr r3,SPRN_PID
+ /*
+ * Load the PID with kernel PID (0).
+ * Also load our MSR_IS and TID to MMUCR for TLB search.
+ */
+ li r3, 0
+ mtspr SPRN_PID, r3
mfmsr r4
andi. r4,r4,MSR_IS@l
beq wmmucr
^ permalink raw reply related
* Re: [ORLinux] [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
From: Jonas Bonn @ 2012-04-16 7:53 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arch, Grant Likely, linux-alpha, linux-ia64, Linus Walleij,
Chris Zankel, microblaze-uclinux, Mark Brown, linux-kernel, linux,
sparclinux, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <CACRpkdZ8yH1ZSG-nQ9dLm0TipHS-jZDuxwqohUC=LGH9V-5q4w@mail.gmail.com>
Acked-by: Jonas Bonn <jonas@southpole.se> (for OpenRISC)
On Mon, 2012-04-16 at 09:21 +0200, Linus Walleij wrote:
> On Sun, Apr 15, 2012 at 11:52 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>
> > Rather than requiring architectures that use gpiolib but don't have any
> > need to define anything custom to copy an asm/gpio.h provide a Kconfig
> > symbol which architectures must select in order to include gpio.h and
> > for other architectures just provide the trivial implementation directly.
> >
> > This makes it much easier to do gpiolib updates and is also a step towards
> > making gpiolib APIs available on every architecture.
> >
> > For architectures with existing boilerplate code leave a stub header in
> > place which warns on direct inclusion of asm/gpio.h and includes
> > linux/gpio.h to catch code that's doing this. Direct inclusion of
> > asm/gpio.h has long been deprecated.
> >
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > ---
> > arch/alpha/include/asm/gpio.h | 59 ++----------------------------
> > arch/arm/Kconfig | 1 +
> > arch/avr32/Kconfig | 1 +
> > arch/blackfin/Kconfig | 1 +
> > arch/ia64/include/asm/gpio.h | 59 ++----------------------------
> > arch/m68k/Kconfig.cpu | 1 +
> > arch/microblaze/include/asm/gpio.h | 57 ++---------------------------
> > arch/mips/Kconfig | 1 +
> > arch/openrisc/include/asm/gpio.h | 69 ++---------------------------------
> > arch/powerpc/include/asm/gpio.h | 57 ++---------------------------
> > arch/sh/Kconfig | 1 +
> > arch/sparc/include/asm/gpio.h | 40 ++-------------------
> > arch/unicore32/Kconfig | 1 +
> > arch/x86/include/asm/gpio.h | 57 ++---------------------------
> > arch/xtensa/include/asm/gpio.h | 60 ++-----------------------------
> > drivers/gpio/Kconfig | 8 ++++
> > include/linux/gpio.h | 34 +++++++++++++++++
> > 17 files changed, 81 insertions(+), 426 deletions(-)
>
> This looks good but I think we need to page the alpha, ia64, m68k, microblaze,
> openrisc etc subarch maintainers on this patch so they have their say.
>
> Yours,
> Linus Walleij
> _______________________________________________
> Linux mailing list
> Linux@lists.openrisc.net
> http://lists.openrisc.net/listinfo/linux
^ permalink raw reply
* Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
From: Mark Brown @ 2012-04-16 8:15 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arch, Grant Likely, linux-ia64, Linus Walleij, Chris Zankel,
microblaze-uclinux, linux, linux-kernel, linux-alpha, sparclinux,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <CACRpkdZ8yH1ZSG-nQ9dLm0TipHS-jZDuxwqohUC=LGH9V-5q4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote:
> This looks good but I think we need to page the alpha, ia64, m68k, microblaze,
> openrisc etc subarch maintainers on this patch so they have their say.
That's why I CCed linux-arch, to get all the architecture maintainers
included. vger would get upset if I CCed everyone individually.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
From: Linus Walleij @ 2012-04-16 8:26 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arch, Grant Likely, linux-ia64, Linus Walleij, Chris Zankel,
microblaze-uclinux, linux, linux-kernel, linux-alpha, sparclinux,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <20120416081532.GA3238@opensource.wolfsonmicro.com>
On Mon, Apr 16, 2012 at 10:15 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote:
>
>> This looks good but I think we need to page the alpha, ia64, m68k, micro=
blaze,
>> openrisc etc subarch maintainers on this patch so they have their say.
>
> That's why I CCed linux-arch, to get all the architecture maintainers
> included. =A0vger would get upset if I CCed everyone individually.
Oh I missed it. I looped in a few maintainers and arch lists anyway.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Kdump support for 47x
From: Suzuki K. Poulose @ 2012-04-16 8:26 UTC (permalink / raw)
To: linuxppc-dev
The following series implements Kexec/Kdump support for
PPC_47x based platforms. Doesn't support SMP yet.
I have tested these patches on the following simulators:
1) simics
2) IBM ISS for ppc476.
Changes since V1:
* Initialize the SPRN_PID to kernel pid (0) before the TLB operations in
setup_map_47x
---
Suzuki K. Poulose (2):
[47x] Enable CRASH_DUMP
[47x] Kernel support for KEXEC
arch/powerpc/Kconfig | 4 -
arch/powerpc/kernel/misc_32.S | 195 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 191 insertions(+), 8 deletions(-)
--
Suzuki K. Poulose
^ permalink raw reply
* [PATCH 1/2] [47x] Kernel support for KEXEC
From: Suzuki K. Poulose @ 2012-04-16 8:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20120416082449.27331.12488.stgit@suzukikp.in.ibm.com>
This patch adds support for creating 1:1 mapping for the
PPC_47x during a KEXEC. The implementation is similar
to that of the PPC440x which is described here :
http://patchwork.ozlabs.org/patch/104323/
PPC_47x MMU :
The 47x uses Unified TLB 1024 entries, with 4-way associative
mapping (4 x 256 entries). The index to be used is calculated
by the MMU by hashing the PID, EPN and TS. The software can
choose to specify the way by setting bit 0(enable way select)
and the way in bits 1-2 in the TLB Word 0.
Implementation:
The patch erases all the UTLB entries which includes the tlb
covering the mapping for our code. The shadow TLB caches the
mapping for the running code which helps us to continue the
execution until we do isync/rfi. We then create a tmp mapping
for the current code in the other address space (TS) and switch
to it.
Then we create a 1:1 mapping(EPN=RPN) for 0-2GiB in the original
address space and switch to the new mapping.
TODO: Add SMP support.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
arch/powerpc/Kconfig | 2
arch/powerpc/kernel/misc_32.S | 195 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 190 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 613eacf..4f64860 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -351,7 +351,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
- depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP && !PPC_47x)) && EXPERIMENTAL
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) && EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index d7e05d2..386d57f 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -738,8 +738,23 @@ relocate_new_kernel:
mr r5, r31
li r0, 0
-#elif defined(CONFIG_44x) && !defined(CONFIG_PPC_47x)
+#elif defined(CONFIG_44x)
+ /* Save our parameters */
+ mr r29, r3
+ mr r30, r4
+ mr r31, r5
+
+#ifdef CONFIG_PPC_47x
+ /* Check for 47x cores */
+ mfspr r3,SPRN_PVR
+ srwi r3,r3,16
+ cmplwi cr0,r3,PVR_476@h
+ beq setup_map_47x
+ cmplwi cr0,r3,PVR_476_ISS@h
+ beq setup_map_47x
+#endif /* CONFIG_PPC_47x */
+
/*
* Code for setting up 1:1 mapping for PPC440x for KEXEC
*
@@ -753,13 +768,8 @@ relocate_new_kernel:
* 5) Invalidate the tmp mapping.
*
* - Based on the kexec support code for FSL BookE
- * - Doesn't support 47x yet.
*
*/
- /* Save our parameters */
- mr r29, r3
- mr r30, r4
- mr r31, r5
/*
* Load the PID with kernel PID (0).
@@ -904,6 +914,179 @@ next_tlb:
li r3, 0
tlbwe r3, r24, PPC44x_TLB_PAGEID
sync
+ b ppc44x_map_done
+
+#ifdef CONFIG_PPC_47x
+
+ /* 1:1 mapping for 47x */
+
+setup_map_47x:
+
+ /*
+ * Load the kernel pid (0) to PID and also to MMUCR[TID].
+ * Also set the MSR IS->MMUCR STS
+ */
+ li r3, 0
+ mtspr SPRN_PID, r3 /* Set PID */
+ mfmsr r4 /* Get MSR */
+ andi. r4, r4, MSR_IS@l /* TS=1? */
+ beq 1f /* If not, leave STS=0 */
+ oris r3, r3, PPC47x_MMUCR_STS@h /* Set STS=1 */
+1: mtspr SPRN_MMUCR, r3 /* Put MMUCR */
+ sync
+
+ /* Find the entry we are running from */
+ bl 2f
+2: mflr r23
+ tlbsx r23, 0, r23
+ tlbre r24, r23, 0 /* TLB Word 0 */
+ tlbre r25, r23, 1 /* TLB Word 1 */
+ tlbre r26, r23, 2 /* TLB Word 2 */
+
+
+ /*
+ * Invalidates all the tlb entries by writing to 256 RPNs(r4)
+ * of 4k page size in all 4 ways (0-3 in r3).
+ * This would invalidate the entire UTLB including the one we are
+ * running from. However the shadow TLB entries would help us
+ * to continue the execution, until we flush them (rfi/isync).
+ */
+ addis r3, 0, 0x8000 /* specify the way */
+ addi r4, 0, 0 /* TLB Word0 = (EPN=0, VALID = 0) */
+ addi r5, 0, 0
+ b clear_utlb_entry
+
+ /* Align the loop to speed things up. from head_44x.S */
+ .align 6
+
+clear_utlb_entry:
+
+ tlbwe r4, r3, 0
+ tlbwe r5, r3, 1
+ tlbwe r5, r3, 2
+ addis r3, r3, 0x2000 /* Increment the way */
+ cmpwi r3, 0
+ bne clear_utlb_entry
+ addis r3, 0, 0x8000
+ addis r4, r4, 0x100 /* Increment the EPN */
+ cmpwi r4, 0
+ bne clear_utlb_entry
+
+ /* Create the entries in the other address space */
+ mfmsr r5
+ rlwinm r7, r5, 27, 31, 31 /* Get the TS (Bit 26) from MSR */
+ xori r7, r7, 1 /* r7 = !TS */
+
+ insrwi r24, r7, 1, 21 /* Change the TS in the saved TLB word 0 */
+
+ /*
+ * write out the TLB entries for the tmp mapping
+ * Use way '0' so that we could easily invalidate it later.
+ */
+ lis r3, 0x8000 /* Way '0' */
+
+ tlbwe r24, r3, 0
+ tlbwe r25, r3, 1
+ tlbwe r26, r3, 2
+
+ /* Update the msr to the new TS */
+ insrwi r5, r7, 1, 26
+
+ bl 1f
+1: mflr r6
+ addi r6, r6, (2f-1b)
+
+ mtspr SPRN_SRR0, r6
+ mtspr SPRN_SRR1, r5
+ rfi
+
+ /*
+ * Now we are in the tmp address space.
+ * Create a 1:1 mapping for 0-2GiB in the original TS.
+ */
+2:
+ li r3, 0
+ li r4, 0 /* TLB Word 0 */
+ li r5, 0 /* TLB Word 1 */
+ li r6, 0
+ ori r6, r6, PPC47x_TLB2_S_RWX /* TLB word 2 */
+
+ li r8, 0 /* PageIndex */
+
+ xori r7, r7, 1 /* revert back to original TS */
+
+write_utlb:
+ rotlwi r5, r8, 28 /* RPN = PageIndex * 256M */
+ /* ERPN = 0 as we don't use memory above 2G */
+
+ mr r4, r5 /* EPN = RPN */
+ ori r4, r4, (PPC47x_TLB0_VALID | PPC47x_TLB0_256M)
+ insrwi r4, r7, 1, 21 /* Insert the TS to Word 0 */
+
+ tlbwe r4, r3, 0 /* Write out the entries */
+ tlbwe r5, r3, 1
+ tlbwe r6, r3, 2
+ addi r8, r8, 1
+ cmpwi r8, 8 /* Have we completed ? */
+ bne write_utlb
+
+ /* make sure we complete the TLB write up */
+ isync
+
+ /*
+ * Prepare to jump to the 1:1 mapping.
+ * 1) Extract page size of the tmp mapping
+ * DSIZ = TLB_Word0[22:27]
+ * 2) Calculate the physical address of the address
+ * to jump to.
+ */
+ rlwinm r10, r24, 0, 22, 27
+
+ cmpwi r10, PPC47x_TLB0_4K
+ bne 0f
+ li r10, 0x1000 /* r10 = 4k */
+ bl 1f
+
+0:
+ /* Defaults to 256M */
+ lis r10, 0x1000
+
+ bl 1f
+1: mflr r4
+ addi r4, r4, (2f-1b) /* virtual address of 2f */
+
+ subi r11, r10, 1 /* offsetmask = Pagesize - 1 */
+ not r10, r11 /* Pagemask = ~(offsetmask) */
+
+ and r5, r25, r10 /* Physical page */
+ and r6, r4, r11 /* offset within the current page */
+
+ or r5, r5, r6 /* Physical address for 2f */
+
+ /* Switch the TS in MSR to the original one */
+ mfmsr r8
+ insrwi r8, r7, 1, 26
+
+ mtspr SPRN_SRR1, r8
+ mtspr SPRN_SRR0, r5
+ rfi
+
+2:
+ /* Invalidate the tmp mapping */
+ lis r3, 0x8000 /* Way '0' */
+
+ clrrwi r24, r24, 12 /* Clear the valid bit */
+ tlbwe r24, r3, 0
+ tlbwe r25, r3, 1
+ tlbwe r26, r3, 2
+
+ /* Make sure we complete the TLB write and flush the shadow TLB */
+ isync
+
+#endif
+
+ppc44x_map_done:
+
/* Restore the parameters */
mr r3, r29
^ permalink raw reply related
* [PATCH 2/2] [47x] Enable CRASH_DUMP
From: Suzuki K. Poulose @ 2012-04-16 8:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20120416082449.27331.12488.stgit@suzukikp.in.ibm.com>
Now that we have KEXEC and relocatable kernel working on 47x (!SMP)
enable CRASH_DUMP.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4f64860..629543a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -368,7 +368,7 @@ config KEXEC
config CRASH_DUMP
bool "Build a kdump crash kernel"
- depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP && !PPC_47x)
+ depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
select RELOCATABLE if PPC64 || 44x
select DYNAMIC_MEMSTART if FSL_BOOKE
help
^ permalink raw reply related
* Re: [PATCH] powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]
From: David Howells @ 2012-04-16 8:37 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: dhowells, linuxppc-dev
In-Reply-To: <1334552674-24107-1-git-send-email-paul.gortmaker@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> The following shows up in chroma_defconfig:
>
> CC arch/powerpc/sysdev/scom.o
> arch/powerpc/sysdev/scom.c: In function 'scom_debug_init':
> arch/powerpc/sysdev/scom.c:182:36: error: 'powerpc_debugfs_root' undeclared (first use in this function)
> arch/powerpc/sysdev/scom.c:182:36: note: each undeclared identifier is reported only once for each function it appears in
> make[2]: *** [arch/powerpc/sysdev/scom.o] Error 1
> make[1]: *** [arch/powerpc/sysdev/scom.o] Error 2
>
> A bisect leads to commit 9ffc93f203c18a70623f21950f1dd473c9ec48cd
>
> "Remove all #inclusions of asm/system.h"
>
> Add the debug header which contains powerpc_debugfs_root.
>
> Cc: David Howells <dhowells@redhat.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes
From: Alexander Graf @ 2012-04-16 9:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20110629102307.GN25406@bloggs.ozlabs.ibm.com>
On 29.06.2011, at 12:23, Paul Mackerras wrote:
> This lifts the restriction that book3s_hv guests can only run one
> hardware thread per core, and allows them to use up to 4 threads
> per core on POWER7. The host still has to run single-threaded.
>=20
> This capability is advertised to qemu through a new KVM_CAP_PPC_SMT
> capability. The return value of the ioctl querying this capability
> is the number of vcpus per virtual CPU core (vcore), currently 4.
>=20
> To use this, the host kernel should be booted with all threads
> active, and then all the secondary threads should be offlined.
> This will put the secondary threads into nap mode. KVM will then
> wake them from nap mode and use them for running guest code (while
> they are still offline). To wake the secondary threads, we send
> them an IPI using a new xics_wake_cpu() function, implemented in
> arch/powerpc/sysdev/xics/icp-native.c. In other words, at this stage
> we assume that the platform has a XICS interrupt controller and
> we are using icp-native.c to drive it. Since the woken thread will
> need to acknowledge and clear the IPI, we also export the base
> physical address of the XICS registers using kvmppc_set_xics_phys()
> for use in the low-level KVM book3s code.
>=20
> When a vcpu is created, it is assigned to a virtual CPU core.
> The vcore number is obtained by dividing the vcpu number by the
> number of threads per core in the host. This number is exported
> to userspace via the KVM_CAP_PPC_SMT capability. If qemu wishes
> to run the guest in single-threaded mode, it should make all vcpu
> numbers be multiples of the number of threads per core.
>=20
> We distinguish three states of a vcpu: runnable (i.e., ready to =
execute
> the guest), blocked (that is, idle), and busy in host. We currently
> implement a policy that the vcore can run only when all its threads
> are runnable or blocked. This way, if a vcpu needs to execute =
elsewhere
> in the kernel or in qemu, it can do so without being starved of CPU
> by the other vcpus.
>=20
> When a vcore starts to run, it executes in the context of one of the
> vcpu threads. The other vcpu threads all go to sleep and stay asleep
> until something happens requiring the vcpu thread to return to qemu,
> or to wake up to run the vcore (this can happen when another vcpu
> thread goes from busy in host state to blocked).
>=20
> It can happen that a vcpu goes from blocked to runnable state (e.g.
> because of an interrupt), and the vcore it belongs to is already
> running. In that case it can start to run immediately as long as
> the none of the vcpus in the vcore have started to exit the guest.
> We send the next free thread in the vcore an IPI to get it to start
> to execute the guest. It synchronizes with the other threads via
> the vcore->entry_exit_count field to make sure that it doesn't go
> into the guest if the other vcpus are exiting by the time that it
> is ready to actually enter the guest.
>=20
> Note that there is no fixed relationship between the hardware thread
> number and the vcpu number. Hardware threads are assigned to vcpus
> as they become runnable, so we will always use the lower-numbered
> hardware threads in preference to higher-numbered threads if not all
> the vcpus in the vcore are runnable, regardless of which vcpus are
> runnable.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
[...]
> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
> index 5616e39..0d6d569 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -25,10 +25,14 @@
> #include <linux/interrupt.h>
> #include <linux/types.h>
> #include <linux/kvm_types.h>
> +#include <linux/threads.h>
> +#include <linux/spinlock.h>
> #include <linux/kvm_para.h>
> #include <asm/kvm_asm.h>
> +#include <asm/processor.h>
>=20
> -#define KVM_MAX_VCPUS 1
> +#define KVM_MAX_VCPUS NR_CPUS
> +#define KVM_MAX_VCORES NR_CPUS
Hey Paul,
While trying to trace down why some BookE systems were only able to do =
as many guest vcpus as there were host cpus available, we stumbled over =
this one. Is there any limitation on book3s_hv that would limit the =
available vcpus to configured host vcpus? Or could we just make this a =
static define like on x86?
Alex
^ permalink raw reply
* Re: [PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes
From: Paul Mackerras @ 2012-04-16 12:13 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <056AF183-5218-457B-9501-B0FF5ED455E9@suse.de>
On Mon, Apr 16, 2012 at 11:45:44AM +0200, Alexander Graf wrote:
> While trying to trace down why some BookE systems were only able to
> do as many guest vcpus as there were host cpus available, we
> stumbled over this one. Is there any limitation on book3s_hv that
> would limit the available vcpus to configured host vcpus? Or could
> we just make this a static define like on x86?
There is no limitation. I did it like that so that we would be able
to have a large number of vcpus on kernels configured for large
systems, while not using up large amounts of memory if the kernel is
configured for a small system. The memory consumption is 8 bytes per
vcore in each struct kvm if book3s_hv is configured.
We can make it a fixed constant if you like, but then the question is
how do you choose that constant so as to allow us to have many vcpus
on large systems but still not waste too much memory on small systems.
Or it could be max(N, NR_CPUS) for a suitable N (e.g. 16 or 32).
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox