* Re: oprofile callgraph support missing for common cpus
From: Joakim Tjernlund @ 2011-12-05 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <1322198672.32635.24.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2011/11/25 06:24:32:
>
> On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
>
> > I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> > correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> > Isn't frame pointers needed for pcc? what about user space?
>
> PowerPC always has frame pointers, ignore that :-)
A bit late but consider this:
int leaf(int x)
{
return x+3;
}
which yields(with gcc -O2 -S):
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
addi 3,3,3
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
(With gcc -O2 -S -fno-omit-frame-pointer)
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
stwu 1,-16(1)
addi 3,3,3
lwz 11,0(1)
stw 31,12(1)
mr 31,1
lwz 31,-4(11)
mr 1,11
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Benjamin Herrenschmidt @ 2011-12-05 9:01 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <OFE1FEF3EC.6B76BECC-ONC125795D.002F3766-C125795D.00308AEE@transmode.se>
On Mon, 2011-12-05 at 09:50 +0100, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2011/11/25 06:24:32:
> >
> > On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
> >
> > > I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> > > correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> > > Isn't frame pointers needed for pcc? what about user space?
> >
> > PowerPC always has frame pointers, ignore that :-)
>
> A bit late but consider this:
.../...
Right I wasn't clear. We do have frame pointers for non-leaf functions,
and we can trace from LR when we are on a leaf function, we can use
__builtin_return_address as well.
We also explicitely prevent -fno-omit-frame-pointer, iirc, due to a bug
with older versions of gcc which could cause miscompiles under some
circumstances (though I don't remember the details).
Cheers,
Ben.
> int leaf(int x)
> {
> return x+3;
> }
>
> which yields(with gcc -O2 -S):
> .file "leaf.c"
> .section ".text"
> .align 2
> .globl leaf
> .type leaf, @function
> leaf:
> addi 3,3,3
> blr
> .size leaf, .-leaf
> .section .note.GNU-stack,"",@progbits
> .ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
>
>
> Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
> (With gcc -O2 -S -fno-omit-frame-pointer)
>
> .file "leaf.c"
> .section ".text"
> .align 2
> .globl leaf
> .type leaf, @function
> leaf:
> stwu 1,-16(1)
> addi 3,3,3
> lwz 11,0(1)
> stw 31,12(1)
> mr 31,1
> lwz 31,-4(11)
> mr 1,11
> blr
> .size leaf, .-leaf
> .section .note.GNU-stack,"",@progbits
> .ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
^ permalink raw reply
* [PATCH] mmc: sdhci-pltfm: Added sdhci-adjust-timeout quirk
From: Xie Xiaobo @ 2011-12-05 8:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: avorontsov, linux-mmc, Xie Xiaobo
Some controller provides an incorrect timeout value for transfers,
So it need the quirk to adjust timeout value to 0xE.
E.g. eSDHC of MPC8536, P1010, and P2020.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
drivers/mmc/host/sdhci-pltfm.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a9e12ea..b5d6b3f 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -2,7 +2,7 @@
* sdhci-pltfm.c Support for SDHCI platform devices
* Copyright (c) 2009 Intel Corporation
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2011 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
*
* Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -68,6 +68,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
if (of_get_property(np, "sdhci,1-bit-only", NULL))
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
+ if (of_get_property(np, "sdhci,sdhci-adjust-timeout", NULL))
+ host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
--
1.6.4
^ permalink raw reply related
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Amit Shah @ 2011-12-05 10:54 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Mike Waychison,
ppc-dev, Greg Kroah-Hartman, Eric Northrup
In-Reply-To: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
> Good grief! Sorry for the spacing mess-up! Here's a resend with reformatting.
>
> Amit,
> We aren't using either QEMU or kvmtool, but we are using KVM. All
So it's a different userspace? Any chance this different userspace is
causing these problems to appear? Esp. since I couldn't reproduce
with qemu.
> the issues we are seeing happen when we try to establish multiple
> virtioconsoles at boot time. The command line isn't relevant, but I
> can tell you the protocol that's passing between the host (kvm) and
> the guest (see the end of this message).
>
> We do go through the control_work_handler(), but it's not
> providing synchronization. Here's a trace of the
> control_work_handler() and handle_control_message() calls; note that
> there are two concurrent calls to control_work_handler().
Ah; how does that happen? control_work_handler() should just be
invoked once, and if there are any more pending work items to be
consumed, they should be done within the loop inside
control_work_handler().
> I decorated control_work_handler() with a "lifetime" marker, and
> passed this value to handle_control_message(), so we can see which
> control messages are being handled from which instance of
> the control_work_handler() thread.
>
> Notice that we enter control_work_handler() a second time before
> the handling of the second PORT_ADD message is complete. The
> first CONSOLE_PORT message is handled by the second
> control_work_handler() call, but the second is handled by the first
> control_work_handler() call.
>
> root@myubuntu:~# dmesg | grep MBH
> [3371055.808738] control_work_handler #1
> [3371055.809372] + #1 handle_control_message PORT_ADD
> [3371055.810169] - handle_control_message PORT_ADD
> [3371055.810170] + #1 handle_control_message PORT_ADD
> [3371055.810244] control_work_handler #2
> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
> [3371055.810246] got hvc_ports_mutex
> [3371055.810578] - handle_control_message PORT_ADD
> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
> [3371055.810580] trylock of hvc_ports_mutex failed
> [3371055.811352] got hvc_ports_mutex
> [3371055.811370] - handle_control_message CONSOLE_PORT
> [3371055.816609] - handle_control_message CONSOLE_PORT
>
> So, I'm guessing the bug is that there shouldn't be two instances of
> control_work_handler() running simultaneously?
Yep, I assumed we did that but apparently not. Do you plan to chase
this one down?
Amit
^ permalink raw reply
* [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Shengzhou Liu @ 2011-12-05 10:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, dwmw2, kumar.gala, linux-mtd, Shengzhou Liu
There was a bug for fmr initialization, which lead to fmr was always 0x100
in fsl_elbc_chip_init() and caused FCM command timeout before calling
fsl_elbc_chip_init_tail().
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index eedd8ee..742bf73 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
if (chip->pagemask & 0xff000000)
al++;
- /* add to ECCM mode set in fsl_elbc_init */
- priv->fmr |= (12 << FMR_CWTO_SHIFT) | /* Timeout > 12 ms */
- (al << FMR_AL_SHIFT);
+ priv->fmr |= al << FMR_AL_SHIFT;
dev_dbg(priv->dev, "fsl_elbc_init: nand->numchips = %d\n",
chip->numchips);
@@ -764,8 +762,8 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
priv->mtd.priv = chip;
priv->mtd.owner = THIS_MODULE;
- /* Set the ECCM according to the settings in bootloader.*/
- priv->fmr = in_be32(&lbc->fmr) & FMR_ECCM;
+ /* Set fmr according to the settings in bootloader.*/
+ priv->fmr = in_be32(&lbc->fmr);
/* fill in nand_chip structure */
/* set up function call table */
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] mtd/nand: Add ONFI support for FSL NAND controller
From: Shengzhou Liu @ 2011-12-05 10:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, dwmw2, kumar.gala, linux-mtd, Shengzhou Liu
In-Reply-To: <1323082493-22617-1-git-send-email-Shengzhou.Liu@freescale.com>
- fix NAND_CMD_READID command for ONFI detect.
- add NAND_CMD_PARAM command to read the ONFI parameter page.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 742bf73..08a3aba 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -349,19 +349,24 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
fsl_elbc_run_command(mtd);
return;
- /* READID must read all 5 possible bytes while CEB is active */
case NAND_CMD_READID:
- dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_READID.\n");
+ case NAND_CMD_PARAM:
+ dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD %x\n", command);
out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |
(FIR_OP_UA << FIR_OP1_SHIFT) |
(FIR_OP_RBW << FIR_OP2_SHIFT));
- out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT);
- /* nand_get_flash_type() reads 8 bytes of entire ID string */
- out_be32(&lbc->fbcr, 8);
- elbc_fcm_ctrl->read_bytes = 8;
+ out_be32(&lbc->fcr, command << FCR_CMD0_SHIFT);
+ /* reads 8 bytes of entire ID string */
+ if (NAND_CMD_READID == command) {
+ out_be32(&lbc->fbcr, 8);
+ elbc_fcm_ctrl->read_bytes = 8;
+ } else {
+ out_be32(&lbc->fbcr, 256);
+ elbc_fcm_ctrl->read_bytes = 256;
+ }
elbc_fcm_ctrl->use_mdr = 1;
- elbc_fcm_ctrl->mdr = 0;
+ elbc_fcm_ctrl->mdr = column;
set_addr(mtd, 0, 0, 0);
fsl_elbc_run_command(mtd);
--
1.6.4
^ permalink raw reply related
* RE: Re: [PATCHv5] atomic: add *_dec_not_zero
From: David Laight @ 2011-12-05 11:44 UTC (permalink / raw)
To: Russell King - ARM Linux, Sven Eckelmann
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-doc, Heiko Carstens,
Randy Dunlap, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-arch, linux-s390, user-mode-linux-devel, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar, Matt Turner,
Fenghua Yu, Arnd Bergma nn, Jeff Dike, linux-alpha, Chris Metcalf,
Tony Luck, Ivan Kokshaysky, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, linux-m32r, linux-parisc, b.a.t.m.a.n,
linux-kernel, Ralf Baechle, David S. Miller, Kyle McMartin,
Richard Weinberger, Martin Schwidefsky, linux390, Andrew Morton,
linuxppc-dev, Hirokazu Takata
In-Reply-To: <20111204221850.GC14542@n2100.arm.linux.org.uk>
Looking at this:
> #ifndef atomic_inc_unless_negative
> static inline int atomic_inc_unless_negative(atomic_t *p)
> {
> int v, v1;
> for (v =3D 0; v >=3D 0; v =3D v1) {
> v1 =3D atomic_cmpxchg(p, v, v + 1);
> if (likely(v1 =3D=3D v))
> return 1;
> }
> return 0;
> }
> #endif
why is it optimised for '*p' being zero??
I'd have though the initial assignment to 'v' should
be made by reading '*p' without any memory barriers (etc).
David
^ permalink raw reply
* Re: [PATCH 0/6] RFCv2 Fix Fsl 8250 BRK bug
From: Alan Cox @ 2011-12-05 12:18 UTC (permalink / raw)
To: Paul Gortmaker
Cc: gregkh, linux-kernel, linux-serial, scottwood, linuxppc-dev
In-Reply-To: <1323042143-25330-1-git-send-email-paul.gortmaker@windriver.com>
> Anyway, have a look and see if this version of things is acceptable
> to all. (Again, the dts update from Kumar isn't shown here).
>
> Thanks to all who provided the feedback on v1.
Looks good to me
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Problem with eLBC?
From: Alexander Lyasin @ 2011-12-05 14:02 UTC (permalink / raw)
To: galak, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5705 bytes --]
Dear Kumar Gala!
Our company is a client Freescale company, we use mpc8308, mpc8321 and other
microprocessors.
I have a board on the mpc8308 chip. This board runs the Linux kernel.
On this board there is NAND flash and DSP proc. on the Local Bus.
Chunk from DTS-file is below:
localbus@e0005000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
reg = <0xe0005000 0x1000>;
interrupts = <77 0x8>;
interrupt-parent = <&ipic>;
// CS0 and CS1 are swapped when
// booting from nand, but the
// addresses are the same.
ranges = <0x0 0x0 0xfe000000 0x00800000
0x1 0x0 0xe0600000 0x00002000
0x2 0x0 0xf0000000 0x00020000
0x3 0x0 0xfa000000 0x00008000>;
nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8315-fcm-nand",
"fsl,elbc-fcm-nand";
reg = <0x1 0x0 0x2000>;
u-boot@0 {
reg = <0x0 0x100000>;
read-only;
label = "U-Boot-NAND";
};
dtb@100000 {
reg = <0x100000 0x40000>;
read-only;
label = "DTB-NAND";
};
kernel@140000 {
reg = <0x140000 0x200000>;
read-only;
label = "Kernel-NAND";
};
jffs2@340000 {
reg = <0x00340000 0x01c00000>;
label = "JFFS2-NAND";
};
reserve@1f40000 {
reg = <0x01f40000 0x000c0000>;
label = "Reserve";
};
};
dsp0@D0020000 {
reg = <0xD0020000 0x10000>;
interrupts = <18 0x8>;
interrupt-parent = <&ipic>;
dsp0;
};
dsp1@D0030000 {
reg = <0xD0030000 0x10000>;
interrupts = <19 0x8>;
interrupt-parent = <&ipic>;
dsp1;
};
User-level application periodically reads data from the DSP and writes the
data to the DSP via a character device. When the application is reading from
DSP or writing to the DSP, file system calls to cause errors:
[root@mpc8308-kd-124 /root]# ls -l
mtd->read(0xdc bytes from 0x8af524) returned ECC error
mtd->read(0x1fc bytes from 0x8aee04) returned ECC error
mtd->read(0xac bytes from 0x8ae554) returned ECC error
mtd->read(0x200 bytes from 0x8adc00) returned ECC error
..............
..............
...............
when writing to flash errors occur following items:
Write of 1662 bytes at 0x01935244 failed. returned -5, retlen 0
Not marking the space at 0x01935244 as dirty because the flash driver returned
retlen zero
Write of 1662 bytes at 0x01930000 failed. returned -5, retlen 0
Not marking the space at 0x01930000 as dirty because the flash driver returned
retlen zero
nand_erase: start = 0x000001c70000, len = 16384
nand_isbad_bbt(): bbt info for offs 0x01c70000: (block 1820) 0x00
nand_write_oob: to = 0x01c70000, len = 8
cannot write OOB for EB at 01930000, requested 8 bytes, read 0 bytes, error -5
I write to support this problem and I was told the following:
In reply to your Service Request SR 1-807899446:
Yes, due to several design peculiarities in local bus nand controller,
simultaneous accesses to nand flash and to other local bus memory
controller may cause nand flash controller access failure. Our linux team
suggested to use "software lock" method to avoid this problem - please do
not use other local bus controllers, when nand flash is accessed.
Thank you for your interest in Freescale Semiconductor products and for
the opportunity to serve you.
Best regards.
Do you think, Kumar, how can solve this problem? Perhaps this problem is not
in eLBS?
Alexander V. Lyasin <alexander.lyasin@gmail.com>
Linux system developer
TAKT Inc
[-- Attachment #2: Type: text/html, Size: 20689 bytes --]
^ permalink raw reply
* Powerbook G4 and sound
From: Петр метель @ 2011-12-05 15:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jrnieder, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
Hello,
I've got problem with sound on my Powerbook G4 Titanium
(PowerBook3,5). Sound always cranks and skips when I moving my
touchpad, regardless of the source of sound. It happens in all my
programs, including vlc, mplayer, e-uae and ioquake3 - they show in
the log messeges like "underrun occured" and "broken pipe".
If I remember correctly, this bug appears on kernel 2.6.32-5 (from
Debian Sqeeze) and later. On kernel 2.6.38 from Ubuntu sound works
_almost_ normally (cranks occur rarely).
I used also mpd server, but it breaks after sound cranks (ncmpc shows
"Timeout") and I can only restart mpd server (/etc/init.d/mpd restart)
to get mpd working (for some time).
Log from alsa-test.sh in attachement.
Sorry for my English :)
Best regards,
Петр метель
[-- Attachment #2: alsa-info.txt.zUlUP5eQPO --]
[-- Type: application/octet-stream, Size: 8046 bytes --]
upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.60
!!################################
!!Script ran on: Mon Dec 5 15:32:32 UTC 2011
!!Linux Distribution
!!------------------
Debian GNU/Linux wheezy/sid \n \l
!!DMI Information
!!---------------
Manufacturer:
Product Name:
Product Version:
!!Kernel Information
!!------------------
Kernel release: 3.1.0-1-powerpc
Operating System: GNU/Linux
Architecture: ppc
Processor: unknown
SMP Enabled: No
!!ALSA Version
!!------------
Driver version: 1.0.24
Library version: 1.0.24.1
Utilities version: 1.0.24.2
!!Loaded ALSA modules
!!-------------------
snd_powermac
!!Sound Servers on this system
!!----------------------------
No sound servers found.
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Snapper ]: PMac Snapper - PowerMac Snapper
PowerMac Snapper (Dev 26) Sub-frame 0
!!PCI Soundcards installed in the system
!!--------------------------------------
!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!--------------------------------------------------------
!!Modprobe options (Sound related)
!!--------------------------------
snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-pcsp: index=-2
snd-usb-audio: index=-2
!!Loaded sound module options
!!--------------------------
!!Module: snd_powermac
enable_beep : Y
id : (null)
index : -1
!!ALSA Device nodes
!!-----------------
crw-rw---T 1 root audio 116, 4 Dec 5 15:14 /dev/snd/controlC0
crw-rw---T 1 root audio 116, 3 Dec 5 15:14 /dev/snd/pcmC0D0c
crw-rw---T 1 root audio 116, 2 Dec 5 16:08 /dev/snd/pcmC0D0p
crw-rw---T 1 root audio 116, 1 Dec 5 15:14 /dev/snd/seq
crw-rw---T 1 root audio 116, 33 Dec 5 15:14 /dev/snd/timer
/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root 60 Dec 5 15:14 .
drwxr-xr-x 3 root root 160 Dec 5 15:14 ..
lrwxrwxrwx 1 root root 12 Dec 5 15:14 platform-snd_powermac -> ../controlC0
!!Aplay/Arecord output
!!------------
APLAY
**** List of PLAYBACK Hardware Devices ****
card 0: Snapper [PowerMac Snapper], device 0: PMac Snapper [PowerMac Snapper]
Subdevices: 0/1
Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices ****
card 0: Snapper [PowerMac Snapper], device 0: PMac Snapper [PowerMac Snapper]
Subdevices: 1/1
Subdevice #0: subdevice #0
!!Amixer output
!!-------------
!!-------Mixer controls for card 0 [Snapper]
Card hw:0 'Snapper'/'PowerMac Snapper (Dev 26) Sub-frame 0'
Mixer name : 'PowerMac Snapper'
Components : ''
Controls : 15
Simple ctrls : 14
Simple mixer control 'Master',0
Capabilities: pvolume pswitch penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 128 [73%] [on]
Front Right: Playback 128 [73%] [on]
Simple mixer control 'Headphone',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Headphone Detection',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Speaker',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'Bass',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 72
Mono: 0 [0%]
Simple mixer control 'Treble',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 72
Mono: 0 [0%]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 124 [70%]
Front Right: Playback 124 [70%]
Simple mixer control 'Mic',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 0 [0%]
Front Right: Playback 0 [0%]
Simple mixer control 'Beep',0
Capabilities: pvolume pvolume-joined penum
Playback channels: Mono
Limits: Playback 0 - 100
Mono: Playback 15 [15%]
Simple mixer control 'Auto Mute',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'DRC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'DRC Range',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 239
Mono: 143 [60%]
Simple mixer control 'Input Source',0
Capabilities: cenum
Items: 'Line' 'Mic'
Item0: 'Line'
Simple mixer control 'Monitor Mix',0
Capabilities: volume penum
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 176
Front Left: 0 [0%]
Front Right: 0 [0%]
!!Alsactl output
!!-------------
--startcollapse--
state.Snapper {
control.1 {
iface MIXER
name 'Master Playback Volume'
value.0 128
value.1 128
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.2 {
iface MIXER
name 'Master Playback Switch'
value.0 true
value.1 true
comment {
access 'read write'
type BOOLEAN
count 2
}
}
control.3 {
iface MIXER
name 'PCM Playback Volume'
value.0 124
value.1 124
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.4 {
iface MIXER
name 'Mic Playback Volume'
value.0 0
value.1 0
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.5 {
iface MIXER
name 'Monitor Mix Volume'
value.0 0
value.1 0
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.6 {
iface MIXER
name 'Tone Control - Bass'
value 0
comment {
access 'read write'
type INTEGER
count 1
range '0 - 72'
}
}
control.7 {
iface MIXER
name 'Tone Control - Treble'
value 0
comment {
access 'read write'
type INTEGER
count 1
range '0 - 72'
}
}
control.8 {
iface MIXER
name 'DRC Range'
value 143
comment {
access 'read write'
type INTEGER
count 1
range '0 - 239'
}
}
control.9 {
iface MIXER
name 'Input Source'
value Line
comment {
access 'read write'
type ENUMERATED
count 1
item.0 Line
item.1 Mic
}
}
control.10 {
iface MIXER
name 'Headphone Playback Switch'
value true
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.11 {
iface MIXER
name 'Speaker Playback Switch'
value false
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.12 {
iface MIXER
name 'DRC Switch'
value false
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.13 {
iface MIXER
name 'Auto Mute Switch'
value true
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.14 {
iface MIXER
name 'Headphone Detection'
value true
comment {
access read
type BOOLEAN
count 1
}
}
control.15 {
iface MIXER
name 'Beep Playback Volume'
value 15
comment {
access 'read write'
type INTEGER
count 1
range '0 - 100'
}
}
}
--endcollapse--
!!All Loaded Modules
!!------------------
Module
usbhid
hid
aes_generic
uinput
cpufreq_conservative
cpufreq_powersave
cpufreq_ondemand
cpufreq_userspace
cpufreq_stats
nls_utf8
hfsplus
snd_powermac
loop
firewire_sbp2
arc4
b43
mac80211
cfg80211
rfkill
bcma
rng_core
ssb
mmc_core
snd_aoa_i2sbus
snd_pcm_oss
snd_mixer_oss
snd_pcm
snd_page_alloc
snd_seq_midi
snd_rawmidi
snd_seq_midi_event
snd_seq
radeon
ttm
snd_timer
drm_kms_helper
snd_seq_device
pcmcia
evdev
snd
drm
i2c_powermac
soundcore
power_supply
snd_aoa_soundbus
yenta_socket
pcmcia_rsrc
pcmcia_core
ext4
mbcache
jbd2
crc16
sr_mod
cdrom
sd_mod
crc_t10dif
ohci_hcd
ehci_hcd
usbcore
firewire_ohci
sungem
sungem_phy
firewire_core
crc_itu_t
!!ALSA/HDA dmesg
!!------------------
^ permalink raw reply
* [PATCH] sbc834x: put full compat string in board match check
From: Paul Gortmaker @ 2011-12-05 16:41 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The commit 883c2cfc8bcc0fd00c5d9f596fb8870f481b5bda:
"fix of_flat_dt_is_compatible() to match the full compatible string"
causes silent boot death on the sbc8349 board because it was
just looking for 8349 and not 8349E -- as originally there
were non-E (no SEC/encryption) chips available. Just add the
E to the board detection string since all boards I've seen
were manufactured with the E versions.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/arch/powerpc/platforms/83xx/sbc834x.c b/arch/powerpc/platforms/83xx/sbc834x.c
index af41d8c..f5a783a 100644
--- a/arch/powerpc/platforms/83xx/sbc834x.c
+++ b/arch/powerpc/platforms/83xx/sbc834x.c
@@ -102,11 +102,11 @@ static int __init sbc834x_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "SBC834x");
+ return of_flat_dt_is_compatible(root, "SBC834xE");
}
define_machine(sbc834x) {
- .name = "SBC834x",
+ .name = "SBC834xE",
.probe = sbc834x_probe,
.setup_arch = sbc834x_setup_arch,
.init_IRQ = sbc834x_init_IRQ,
--
1.7.7
^ permalink raw reply related
* Re: [PATCH v3 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Moffett, Kyle D @ 2011-12-05 18:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev, Michael Ellerman
In-Reply-To: <6AB1179B-FB0B-4E43-AE94-43D3D6FF80CE@kernel.crashing.org>
On Dec 03, 2011, at 10:53, Kumar Gala wrote:
> On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
>> Instead of using the open-coded "reg" property lookup and address
>> translation in mpic_alloc(), directly call of_address_to_resource().
>> This includes various workarounds for special cases which the naive
>> of_address_translate() does not.
>>=20
>> Afterwards it is possible to remove the copiously copy-pasted calls to
>> of_address_translate() from the 85xx/86xx/powermac platforms.
>>=20
>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/platforms/85xx/corenet_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/ksi8560.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc8536_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 +----
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 11 +----
>> arch/powerpc/platforms/85xx/p1010rdb.c | 9 +----
>> arch/powerpc/platforms/85xx/p1022_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/p1023_rds.c | 9 +----
>> arch/powerpc/platforms/85xx/sbc8548.c | 9 +----
>> arch/powerpc/platforms/85xx/sbc8560.c | 9 +----
>> arch/powerpc/platforms/85xx/socrates.c | 9 +----
>> arch/powerpc/platforms/85xx/stx_gp3.c | 9 +----
>> arch/powerpc/platforms/85xx/tqm85xx.c | 9 +----
>> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 9 +----
>> arch/powerpc/platforms/86xx/pic.c | 4 +-
>> arch/powerpc/platforms/powermac/pic.c | 8 +---
>> arch/powerpc/sysdev/mpic.c | 61 ++++++++++++++++-------=
------
>> 20 files changed, 55 insertions(+), 175 deletions(-)
>=20
> What about cleaning up:
>=20
> arch/powerpc/platforms/chrp/setup.c: chrp_mpic =3D mpic_alloc(np, opad=
dr, MPIC_PRIMARY,
> arch/powerpc/platforms/embedded6xx/holly.c: mpic =3D mpic_alloc(tsi_p=
ic, mpic_paddr,
> arch/powerpc/platforms/embedded6xx/linkstation.c: mpic =3D mpic_all=
oc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c: mpic =3D mpic_all=
oc(tsi_pic, mpic_paddr,
> arch/powerpc/platforms/embedded6xx/storcenter.c: mpic =3D mpic_all=
oc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/maple/setup.c: mpic =3D mpic_alloc(mpic_node, op=
enpic_addr, flags,
> arch/powerpc/platforms/pasemi/setup.c: mpic =3D mpic_alloc(mpic_node, op=
enpic_addr,
> arch/powerpc/platforms/pseries/setup.c: mpic =3D mpic_alloc(pSeries_mpic_=
node, openpic_addr,
>=20
> Seems like we should be able to remove the 'phys_addr' argument altogethe=
r.
Well, ideally the MPIC code would just be a OF platform_driver with a
bit of supplementary platform_data to deal with device-tree flaws.
Unfortunately it's quite a long way from that.
Some platforms seem to prefer to use a "platform-open-pic" property on
the root node instead of setting up the "reg" node of the open-pic
itself.
Furthermore, the ISU configuration seems to be board-specific. pSeries
seems to have all of the ISUs configured as additional cells in the
"platform-open-pic" property, but almost all of the rest are just
hard-coded offsets from the PIC address in the board-support code.
If it was possible to fix the device-trees on the systems with hardcoded
offsets then we could put the ISU addresses into the "platform-open-pic"
property and test that in mpic_alloc().
Otherwise there's still going to be a fair amount of hardcoding for
specific boards.
Regardless, I think this patch series is a good first cut and cleaning
up some of the more egregious code duplication there.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v3 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Kumar Gala @ 2011-12-05 19:22 UTC (permalink / raw)
To: Moffett, Kyle D; +Cc: Paul Mackerras, linuxppc-dev, Michael Ellerman
In-Reply-To: <14B81DE9-6C77-4914-873B-050C33876FF2@boeing.com>
On Dec 5, 2011, at 12:41 PM, Moffett, Kyle D wrote:
> On Dec 03, 2011, at 10:53, Kumar Gala wrote:
>> On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
>>> Instead of using the open-coded "reg" property lookup and address
>>> translation in mpic_alloc(), directly call of_address_to_resource().
>>> This includes various workarounds for special cases which the naive
>>> of_address_translate() does not.
>>>=20
>>> Afterwards it is possible to remove the copiously copy-pasted calls =
to
>>> of_address_translate() from the 85xx/86xx/powermac platforms.
>>>=20
>>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: Grant Likely <grant.likely@secretlab.ca>
>>> Cc: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> arch/powerpc/platforms/85xx/corenet_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/ksi8560.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc8536_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 11 +----
>>> arch/powerpc/platforms/85xx/p1010rdb.c | 9 +----
>>> arch/powerpc/platforms/85xx/p1022_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/p1023_rds.c | 9 +----
>>> arch/powerpc/platforms/85xx/sbc8548.c | 9 +----
>>> arch/powerpc/platforms/85xx/sbc8560.c | 9 +----
>>> arch/powerpc/platforms/85xx/socrates.c | 9 +----
>>> arch/powerpc/platforms/85xx/stx_gp3.c | 9 +----
>>> arch/powerpc/platforms/85xx/tqm85xx.c | 9 +----
>>> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 9 +----
>>> arch/powerpc/platforms/86xx/pic.c | 4 +-
>>> arch/powerpc/platforms/powermac/pic.c | 8 +---
>>> arch/powerpc/sysdev/mpic.c | 61 =
++++++++++++++++-------------
>>> 20 files changed, 55 insertions(+), 175 deletions(-)
>>=20
>> What about cleaning up:
>>=20
>> arch/powerpc/platforms/chrp/setup.c: chrp_mpic =3D mpic_alloc(np, =
opaddr, MPIC_PRIMARY,
>> arch/powerpc/platforms/embedded6xx/holly.c: mpic =3D =
mpic_alloc(tsi_pic, mpic_paddr,
>> arch/powerpc/platforms/embedded6xx/linkstation.c: mpic =3D =
mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
>> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c: mpic =3D =
mpic_alloc(tsi_pic, mpic_paddr,
>> arch/powerpc/platforms/embedded6xx/storcenter.c: mpic =3D =
mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
>> arch/powerpc/platforms/maple/setup.c: mpic =3D =
mpic_alloc(mpic_node, openpic_addr, flags,
>> arch/powerpc/platforms/pasemi/setup.c: mpic =3D =
mpic_alloc(mpic_node, openpic_addr,
>> arch/powerpc/platforms/pseries/setup.c: mpic =3D =
mpic_alloc(pSeries_mpic_node, openpic_addr,
>>=20
>> Seems like we should be able to remove the 'phys_addr' argument =
altogether.
>=20
> Well, ideally the MPIC code would just be a OF platform_driver with a
> bit of supplementary platform_data to deal with device-tree flaws.
> Unfortunately it's quite a long way from that.
>=20
> Some platforms seem to prefer to use a "platform-open-pic" property on
> the root node instead of setting up the "reg" node of the open-pic
> itself.
>=20
> Furthermore, the ISU configuration seems to be board-specific. =
pSeries
> seems to have all of the ISUs configured as additional cells in the
> "platform-open-pic" property, but almost all of the rest are just
> hard-coded offsets from the PIC address in the board-support code.
>=20
> If it was possible to fix the device-trees on the systems with =
hardcoded
> offsets then we could put the ISU addresses into the =
"platform-open-pic"
> property and test that in mpic_alloc().
>=20
> Otherwise there's still going to be a fair amount of hardcoding for
> specific boards.
>=20
> Regardless, I think this patch series is a good first cut and cleaning
> up some of the more egregious code duplication there.
>=20
> Cheers,
> Kyle Moffett
Agreed its a good first pass cleanup but it doesn't seem like we're that =
far off from remove the 'phys_addr' being passed in.
- k=
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Scott Wood @ 2011-12-05 19:31 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323082493-22617-1-git-send-email-Shengzhou.Liu@freescale.com>
On 12/05/2011 04:54 AM, Shengzhou Liu wrote:
> There was a bug for fmr initialization, which lead to fmr was always 0x100
> in fsl_elbc_chip_init() and caused FCM command timeout before calling
> fsl_elbc_chip_init_tail().
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/mtd/nand/fsl_elbc_nand.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index eedd8ee..742bf73 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
> if (chip->pagemask & 0xff000000)
> al++;
>
> - /* add to ECCM mode set in fsl_elbc_init */
> - priv->fmr |= (12 << FMR_CWTO_SHIFT) | /* Timeout > 12 ms */
> - (al << FMR_AL_SHIFT);
> + priv->fmr |= al << FMR_AL_SHIFT;
>
> dev_dbg(priv->dev, "fsl_elbc_init: nand->numchips = %d\n",
> chip->numchips);
> @@ -764,8 +762,8 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
> priv->mtd.priv = chip;
> priv->mtd.owner = THIS_MODULE;
>
> - /* Set the ECCM according to the settings in bootloader.*/
> - priv->fmr = in_be32(&lbc->fmr) & FMR_ECCM;
> + /* Set fmr according to the settings in bootloader.*/
> + priv->fmr = in_be32(&lbc->fmr);
>
> /* fill in nand_chip structure */
> /* set up function call table */
We shouldn't be relying on the bootloader to provide a sane value here
-- the bootloader may not have used/initialized NAND at all.
It's sort of OK for ECCM, since unless you're trying to match an
externally programmed flash, or the bootloader uses the flash, all we
really care about is that the value stay consistent. The timeout, OTOH,
must not be set too low or things won't work.
We should just set a value that we believe to be high enough for all uses.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-05 19:46 UTC (permalink / raw)
To: dedekind1
Cc: Artem.Bityutskiy, dwmw2, linux-kernel, shuo.liu, linux-mtd, akpm,
linuxppc-dev
In-Reply-To: <1323067628.2316.29.camel@koala>
On 12/05/2011 12:47 AM, Artem Bityutskiy wrote:
> On Sun, 2011-12-04 at 12:31 +0800, shuo.liu@freescale.com wrote:
>> + /*
>> + * Freescale FCM controller has a 2K size limitation of buffer
>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
>> + * of chip is greater than 2048.
>> + * We malloc a large enough buffer (maximum page size is 16K).
>> + */
>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
>> + if (!elbc_fcm_ctrl->buffer) {
>> + dev_err(dev, "failed to allocate memory\n");
>> + mutex_unlock(&fsl_elbc_nand_mutex);
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>
> Sorry for returning to this again and agian - I do not have time to dig
> suggest you the right solutions on the one hand, you do not provide me a
> good answer on the other hand (or I forgot?).
>
> 16KiB pages do not even exist I believe.
Googling turns up some hints of it, but nothing concrete such as a
datasheet. We can assume 8K max for now and adjust it later, as the
need becomes clear.
> And you kmalloc 33KiB or RAM
17KiB, or 9KiB if we forget about 16K-page NAND.
> although in most cases you need only 5KiB. I think this is wrong -
> what is the very strong reason of wasting RAM you have?
>
> Why you cannot allocate exactly the required amount of RAM after
> 'nand_scan_ident()' finishes and you know the page size?
Because this is a controller resource, shared by multiple NAND chips
that may be different page sizes (even if not, it's adding another point
of synchronization required between initialization of different chips).
I don't think it's worth the gymnastics to save a few KiB.
-Scott
^ permalink raw reply
* Re: Problem with eLBC?
From: Scott Wood @ 2011-12-05 21:08 UTC (permalink / raw)
To: Alexander Lyasin; +Cc: linuxppc-dev
In-Reply-To: <201112051902.35285.alexander.lyasin@gmail.com>
On 12/05/2011 08:02 AM, Alexander Lyasin wrote:
> In reply to your Service Request SR 1-807899446:
>
> Yes, due to several design peculiarities in local bus nand controller,
> simultaneous accesses to nand flash and to other local bus memory
> controller may cause nand flash controller access failure. Our linux
> team suggested to use "software lock" method to avoid this problem -
> please do not use other local bus controllers, when nand flash is accessed.
What kernel version are you using? The latest mainline kernel should
not have this issue.
Make sure you have these patches:
commit d08e44570ed611c527a1062eb4f8c6ac61832e6e
Author: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Date: Thu May 19 18:48:01 2011 +0800
powerpc/fsl_lbc: Add workaround for ELBC-A001 erratum
Simultaneous FCM and GPCM or UPM operation may erroneously trigger
bus monitor timeout.
Set the local bus monitor timeout value to the maximum by setting
LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
and
commit 476459a6cf46d20ec73d9b211f3894ced5f9871e
Author: Scott Wood <scottwood@freescale.com>
Date: Fri Nov 13 14:13:01 2009 -0600
mtd: eLBC NAND: use recommended command sequences
Currently, the program and erase sequences do not wait for completion,
instead relying on a subsequent waitfunc() callback. However, this
causes
the chipselect to be deasserted while the NAND chip is still
asserting the
busy pin, which can corrupt activity on other chipselects.
This patch switches to using the sequences recommended by the manual,
in which a wait is performed within the initial command sequence.
We can
now re-use the status byte from the initial command sequence, rather
than
having to do another status read in the waitfunc.
Since we're already touching the command sequences, it also cleans
up some
cruft in SEQIN that isn't needed since we cannot program partial pages
outside of OOB.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reported-by: Suchit Lepcha <suchit.lepcha@freescale.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-Scott
^ permalink raw reply
* [PATCH] rapidio/tsi721: switch to dma_zalloc_coherent
From: Alexandre Bounine @ 2011-12-05 22:33 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Replaces pair dma_alloc_coherent()+memset() with new dma_zalloc_coherent()
added by Andrew Morton for kernel version 3.2
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 17 ++++-------------
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 5225930..514c28c 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -851,14 +851,12 @@ static int tsi721_doorbell_init(struct tsi721_device *priv)
INIT_WORK(&priv->idb_work, tsi721_db_dpc);
/* Allocate buffer for inbound doorbells queue */
- priv->idb_base = dma_alloc_coherent(&priv->pdev->dev,
+ priv->idb_base = dma_zalloc_coherent(&priv->pdev->dev,
IDB_QSIZE * TSI721_IDB_ENTRY_SIZE,
&priv->idb_dma, GFP_KERNEL);
if (!priv->idb_base)
return -ENOMEM;
- memset(priv->idb_base, 0, IDB_QSIZE * TSI721_IDB_ENTRY_SIZE);
-
dev_dbg(&priv->pdev->dev, "Allocated IDB buffer @ %p (phys = %llx)\n",
priv->idb_base, (unsigned long long)priv->idb_dma);
@@ -904,7 +902,7 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
*/
/* Allocate space for DMA descriptors */
- bd_ptr = dma_alloc_coherent(&priv->pdev->dev,
+ bd_ptr = dma_zalloc_coherent(&priv->pdev->dev,
bd_num * sizeof(struct tsi721_dma_desc),
&bd_phys, GFP_KERNEL);
if (!bd_ptr)
@@ -913,8 +911,6 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
priv->bdma[chnum].bd_phys = bd_phys;
priv->bdma[chnum].bd_base = bd_ptr;
- memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
-
dev_dbg(&priv->pdev->dev, "DMA descriptors @ %p (phys = %llx)\n",
bd_ptr, (unsigned long long)bd_phys);
@@ -922,7 +918,7 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
sts_size = (bd_num >= TSI721_DMA_MINSTSSZ) ?
bd_num : TSI721_DMA_MINSTSSZ;
sts_size = roundup_pow_of_two(sts_size);
- sts_ptr = dma_alloc_coherent(&priv->pdev->dev,
+ sts_ptr = dma_zalloc_coherent(&priv->pdev->dev,
sts_size * sizeof(struct tsi721_dma_sts),
&sts_phys, GFP_KERNEL);
if (!sts_ptr) {
@@ -938,8 +934,6 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
priv->bdma[chnum].sts_base = sts_ptr;
priv->bdma[chnum].sts_size = sts_size;
- memset(sts_ptr, 0, sts_size);
-
dev_dbg(&priv->pdev->dev,
"desc status FIFO @ %p (phys = %llx) size=0x%x\n",
sts_ptr, (unsigned long long)sts_phys, sts_size);
@@ -1400,7 +1394,7 @@ static int tsi721_open_outb_mbox(struct rio_mport *mport, void *dev_id,
/* Outbound message descriptor status FIFO allocation */
priv->omsg_ring[mbox].sts_size = roundup_pow_of_two(entries + 1);
- priv->omsg_ring[mbox].sts_base = dma_alloc_coherent(&priv->pdev->dev,
+ priv->omsg_ring[mbox].sts_base = dma_zalloc_coherent(&priv->pdev->dev,
priv->omsg_ring[mbox].sts_size *
sizeof(struct tsi721_dma_sts),
&priv->omsg_ring[mbox].sts_phys, GFP_KERNEL);
@@ -1412,9 +1406,6 @@ static int tsi721_open_outb_mbox(struct rio_mport *mport, void *dev_id,
goto out_desc;
}
- memset(priv->omsg_ring[mbox].sts_base, 0,
- entries * sizeof(struct tsi721_dma_sts));
-
/*
* Configure Outbound Messaging Engine
*/
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/85xx: add a 32-bit P1022DS device tree
From: Timur Tabi @ 2011-12-05 23:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <D5BD2D7D-4549-42A7-8BA6-9B3C84DB5E85@freescale.com>
Kumar Gala wrote:
> look at how mpc8572ds handles 36b.dts we put common definitions in a shared file.
Ok, I've made those changes, but when I boot the kernel, I'm seeing this. Can you give me a clue as to what's wrong?
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
pci 0002:05:00.0: [8086:10d3] type 0 class 0x000200
pci 0002:05:00.0: reg 10: [mem 0x80000000-0x8001ffff]
pci 0002:05:00.0: reg 14: [mem 0x80080000-0x800fffff]
pci 0002:05:00.0: reg 18: [io 0x1000-0x101f]
pci 0002:05:00.0: reg 1c: [mem 0x80100000-0x80103fff]
pci 0002:05:00.0: reg 30: [mem 0x00000000-0x0003ffff pref]
pci 0002:05:00.0: PME# supported from D0 D3hot D3cold
pci 0002:05:00.0: PME# disabled
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x801fffff]
PCI: Cannot allocate resource region 0 of device 0002:05:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0002:05:00.0, will remap
PCI: Cannot allocate resource region 3 of device 0002:05:00.0, will remap
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xffbdb000-0xffbdbfff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xffbc9000-0xffbc9fff]
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xffbdb000-0xffbeafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0002:04:00.0: BAR 9: can't assign mem pref (size 0x100000)
pci 0002:05:00.0: BAR 1: assigned [mem 0x80000000-0x8007ffff]
pci 0002:05:00.0: BAR 1: set to [mem 0x80000000-0x8007ffff] (PCI address [0xe000
0000-0xe007ffff])
pci 0002:05:00.0: BAR 6: assigned [mem 0x80080000-0x800bffff pref]
pci 0002:05:00.0: BAR 0: assigned [mem 0x800c0000-0x800dffff]
pci 0002:05:00.0: BAR 0: set to [mem 0x800c0000-0x800dffff] (PCI address [0xe00c
0000-0xe00dffff])
pci 0002:05:00.0: BAR 3: assigned [mem 0x800e0000-0x800e3fff]
pci 0002:05:00.0: BAR 3: set to [mem 0x800e0000-0x800e3fff] (PCI address [0xe00e
0000-0xe00e3fff])
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xffbc9000-0xffbd8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xffbdb000-0xffbeafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xffbdb000-0xffbeafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xffbc9000-0xffbd8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xffbc9000-0xffbd8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* next BUG: using smp_processor_id() in preemptible
From: Hugh Dickins @ 2011-12-05 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: Call Trace:
Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Hugh
^ permalink raw reply
* "KVM: PPC: booke: Improve timer register emulation" breaks Book3s HV
From: Paul Mackerras @ 2011-12-06 4:03 UTC (permalink / raw)
To: Alexander Graf, Scott Wood; +Cc: linuxppc-dev, kvm-ppc
I'm not sure why yet, but commit 8a97c432 ("KVM: PPC: booke: Improve
timer register emulation") in Alex's kvm-ppc-next branch is breaking
Book3S HV KVM on POWER7. Guest cpus fail to spin up, and even with
just one cpu, the guest stalls every so often. If I stop the guest
and inspect the state with qemu, PC is at 0x900. Reverting 8a97c432
makes it work properly again.
Paul.
^ permalink raw reply
* [PATCH] powerpc/powernv: Fix problems in onlining CPUs
From: Paul Mackerras @ 2011-12-06 5:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Alexander Graf
At present, on the powernv platform, if you off-line a CPU that was
online, and then try to on-line it again, the kernel generates a
warning message "OPAL Error -1 starting CPU n". Furthermore, if the
CPU is a secondary thread that was used by KVM while it was off-line,
the CPU fails to come online.
The first problem is fixed by only calling OPAL to start the CPU the
first time it is on-lined, as indicated by the cpu_start field of its
PACA being zero. The second problem is fixed by restoring the
cpu_start field to 1 instead of 0 when using the CPU within KVM.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e37f8f4..ca9b733 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -65,7 +65,7 @@ BEGIN_FTR_SECTION
lbz r0,PACAPROCSTART(r13)
cmpwi r0,0x80
bne 1f
- li r0,0
+ li r0,1
stb r0,PACAPROCSTART(r13)
b kvm_start_guest
1:
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index e877366..17210c5 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -75,7 +75,7 @@ int __devinit pnv_smp_kick_cpu(int nr)
/* On OPAL v2 the CPU are still spinning inside OPAL itself,
* get them back now
*/
- if (firmware_has_feature(FW_FEATURE_OPALv2)) {
+ if (!paca[nr].cpu_start && firmware_has_feature(FW_FEATURE_OPALv2)) {
pr_devel("OPAL: Starting CPU %d (HW 0x%x)...\n", nr, pcpu);
rc = opal_start_cpu(pcpu, start_here);
if (rc != OPAL_SUCCESS)
^ permalink raw reply related
* [PATCH] powerpc: Provide a way for KVM to indicate that NV GPR values are lost
From: Paul Mackerras @ 2011-12-06 5:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Alexander Graf; +Cc: linuxppc-dev, kvm-ppc
This fixes a problem where a CPU thread coming out of nap mode can
think it has valid values in the nonvolatile GPRs (r14 - r31) as saved
away in power7_idle, but in fact the values have been trashed because
the thread was used for KVM in the mean time. The result is that the
thread crashes because code that called power7_idle (e.g.,
pnv_smp_cpu_kill_self()) goes to use values in registers that have
been trashed.
The bit field in SRR1 that tells whether state was lost only reflects
the most recent nap, which may not have been the nap instruction in
power7_idle. So we need an extra PACA field to indicate that state
has been lost even if SRR1 indicates that the most recent nap didn't
lose state. We clear this field when saving the state in power7_idle,
we set it to a non-zero value when we use the thread for KVM, and we
test it in power7_wakeup_noloss.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
I assume this should go via Ben's tree, since it touches more powerpc
code than PPC KVM code.
arch/powerpc/include/asm/paca.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/idle_power7.S | 4 ++++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 3 +++
4 files changed, 9 insertions(+)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 17722c7..269c05a 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -135,6 +135,7 @@ struct paca_struct {
u8 hard_enabled; /* set if irqs are enabled in MSR */
u8 io_sync; /* writel() needs spin_unlock sync */
u8 irq_work_pending; /* IRQ_WORK interrupt while soft-disable */
+ u8 nap_state_lost; /* NV GPR values lost in power7_idle */
#ifdef CONFIG_PPC_POWERNV
/* Pointer to OPAL machine check event structure set by the
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index ec24b36..8e0db0b 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -208,6 +208,7 @@ int main(void)
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
+ DEFINE(PACA_NAPSTATELOST, offsetof(struct paca_struct, nap_state_lost));
#endif /* CONFIG_PPC64 */
/* RTAS */
diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S
index 3a70845..fcdff19 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -54,6 +54,7 @@ _GLOBAL(power7_idle)
li r0,0
stb r0,PACASOFTIRQEN(r13) /* we'll hard-enable shortly */
stb r0,PACAHARDIRQEN(r13)
+ stb r0,PACA_NAPSTATELOST(r13)
/* Continue saving state */
SAVE_GPR(2, r1)
@@ -86,6 +87,9 @@ _GLOBAL(power7_wakeup_loss)
rfid
_GLOBAL(power7_wakeup_noloss)
+ lbz r0,PACA_NAPSTATELOST(r13)
+ cmpwi r0,0
+ bne .power7_wakeup_loss
ld r1,PACAR1(r13)
ld r4,_MSR(r1)
ld r5,_NIP(r1)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 7b8dbf6..b70bf22 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -112,6 +112,9 @@ kvm_start_guest:
stbcix r0, r5, r6 /* clear it */
stwcix r8, r5, r7 /* EOI it */
+ /* NV GPR values from power7_idle() will no longer be valid */
+ stb r0, PACA_NAPSTATELOST(r13)
+
.global kvmppc_hv_entry
kvmppc_hv_entry:
^ permalink raw reply related
* [PATCH 0/13] KVM: PPC: Update Book3S HV memory handling
From: Paul Mackerras @ 2011-12-06 6:01 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
This series of patches updates the Book3S-HV KVM code that manages the
guest hashed page table (HPT) to enable several things:
* MMIO emulation and MMIO pass-through
* Use of small pages (4kB or 64kB, depending on config) to back the
guest memory
* Pageable guest memory - i.e. backing pages can be removed from the
guest and reinstated on demand, using the MMU notifier mechanism.
* Guests can be given read-only access to pages even though they think
they have mapped them read/write. When they try to write to them
their access is upgraded to read/write. This allows KSM to share
pages between guests.
On PPC970 we have no way to get DSIs and ISIs to come to the
hypervisor, so we can't do MMIO emulation or pageable guest memory.
On POWER7 we set the VPM1 bit in the LPCR to make all DSIs and ISIs
come to the hypervisor (host) as HDSIs or HISIs.
This code is working well in my tests. The sporadic crashes that I
was seeing earlier are fixed by the first patch in the series.
Somewhat to my surprise, when I implemented the last patch in the
series I started to see KSM coalescing pages without any further
effort on my part -- my tests were on a machine with Fedora 16
installed, and it has ksmtuned running by default.
This series is on top of Alex Graf's kvm-ppc-next branch, although the
last patch on that branch ("KVM: PPC: booke: Improve timer register
emulation") is causing the decrementer not to work properly in Book3S
HV guests, for reasons that I haven't fully determined yet.
These patches only touch arch/powerpc except for patch 11, which adds
a couple of barriers to allow mmu_notifier_retry() to be used outside
of the kvm->mmu_lock.
Unlike the previous version of these patches, we don't look at what's
mapped in the user address space at the time that
kvmppc_core_prepare_memory_region or kvmppc_core_commit_memory_region
gets called; we look up pages only when they are needed, either
because the guest wants to map them with an H_ENTER hypercall, or for
the pages needed for the virtual real-mode area (VRMA), at the time of
the first VCPU_RUN ioctl.
Paul.
^ permalink raw reply
* [PATCH 01/13] KVM: PPC: Move kvm_vcpu_ioctl_[gs]et_one_reg down to platform-specific code
From: Paul Mackerras @ 2011-12-06 6:02 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20111206060156.GD12389@drongo>
This moves the get/set_one_reg implementation down from powerpc.c into
booke.c, book3s_pr.c and book3s_hv.c. This avoids #ifdefs in C code,
but more importantly, it fixes a bug on Book3s HV where we were
accessing beyond the end of the kvm_vcpu struct (via the to_book3s()
macro) and corrupting memory, causing random crashes and file corruption.
On Book3s HV we only accept setting the HIOR to zero, since the guest
runs in supervisor mode and its vectors are never offset from zero.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/kvm_ppc.h | 3 ++
arch/powerpc/kvm/book3s_hv.c | 33 ++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_pr.c | 33 ++++++++++++++++++++++++++++++
arch/powerpc/kvm/booke.c | 10 +++++++++
arch/powerpc/kvm/powerpc.c | 39 ------------------------------------
5 files changed, 79 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 5192c2e..fc2d696 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -176,6 +176,9 @@ int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
void kvmppc_get_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int kvmppc_set_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg);
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg);
+
void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 pid);
#ifdef CONFIG_KVM_BOOK3S_64_HV
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index ecc77fa..5efdd5b 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -390,6 +390,39 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return 0;
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg->id) {
+ case KVM_ONE_REG_PPC_HIOR:
+ reg->u.reg64 = 0;
+ r = 0;
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg->id) {
+ case KVM_ONE_REG_PPC_HIOR:
+ /* Only allow this to be set to zero */
+ if (reg->u.reg64 == 0)
+ r = 0;
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvmppc_core_check_processor_compat(void)
{
if (cpu_has_feature(CPU_FTR_HVMODE))
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index cbb7051..1abe35c 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -837,6 +837,39 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return 0;
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg->id) {
+ case KVM_ONE_REG_PPC_HIOR:
+ reg->u.reg64 = to_book3s(vcpu)->hior;
+ r = 0;
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg->id) {
+ case KVM_ONE_REG_PPC_HIOR:
+ to_book3s(vcpu)->hior = reg->u.reg64;
+ to_book3s(vcpu)->hior_explicit = true;
+ r = 0;
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvmppc_core_check_processor_compat(void)
{
return 0;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 9e41f45..ee9e1ee 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -887,6 +887,16 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return kvmppc_core_set_sregs(vcpu, sregs);
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ return -EINVAL;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ return -EINVAL;
+}
+
int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
return -ENOTSUPP;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 34515e8..1239c6f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -620,45 +620,6 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return r;
}
-static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
- struct kvm_one_reg *reg)
-{
- int r = -EINVAL;
-
- switch (reg->id) {
-#ifdef CONFIG_PPC_BOOK3S
- case KVM_ONE_REG_PPC_HIOR:
- reg->u.reg64 = to_book3s(vcpu)->hior;
- r = 0;
- break;
-#endif
- default:
- break;
- }
-
- return r;
-}
-
-static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
- struct kvm_one_reg *reg)
-{
- int r = -EINVAL;
-
- switch (reg->id) {
-#ifdef CONFIG_PPC_BOOK3S
- case KVM_ONE_REG_PPC_HIOR:
- to_book3s(vcpu)->hior = reg->u.reg64;
- to_book3s(vcpu)->hior_explicit = true;
- r = 0;
- break;
-#endif
- default:
- break;
- }
-
- return r;
-}
-
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
--
1.7.5.4
^ permalink raw reply related
* [PATCH 02/13] KVM: PPC: Keep a record of HV guest view of hashed page table entries
From: Paul Mackerras @ 2011-12-06 6:03 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20111206060156.GD12389@drongo>
This adds an array that parallels the guest hashed page table (HPT),
that is, it has one entry per HPTE, used to store the guest's view
of the second doubleword of the corresponding HPTE. The first
doubleword in the HPTE is the same as the guest's idea of it, so we
don't need to store a copy, but the second doubleword in the HPTE has
the real page number rather than the guest's logical page number.
This allows us to remove the back_translate() and reverse_xlate()
functions.
This "reverse mapping" array is vmalloc'd, meaning that to access it
in real mode we have to walk the kernel's page tables explicitly.
That is done by the new real_vmalloc_addr() function. (In fact this
returns an address in the linear mapping, so the result is usable
both in real mode and in virtual mode.)
There are also some minor cleanups here: moving the definitions of
HPT_ORDER etc. to a header file and defining HPT_NPTE for HPT_NPTEG << 3.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/kvm_book3s_64.h | 8 +++
arch/powerpc/include/asm/kvm_host.h | 10 ++++
arch/powerpc/kvm/book3s_64_mmu_hv.c | 44 +++++++++++----
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 87 ++++++++++++++++++------------
4 files changed, 103 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index d0ac94f..23bb17e 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -29,6 +29,14 @@ static inline struct kvmppc_book3s_shadow_vcpu *to_svcpu(struct kvm_vcpu *vcpu)
#define SPAPR_TCE_SHIFT 12
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+/* For now use fixed-size 16MB page table */
+#define HPT_ORDER 24
+#define HPT_NPTEG (1ul << (HPT_ORDER - 7)) /* 128B per pteg */
+#define HPT_NPTE (HPT_NPTEG << 3) /* 8 PTEs per PTEG */
+#define HPT_HASH_MASK (HPT_NPTEG - 1)
+#endif
+
static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
unsigned long pte_index)
{
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 66c75cd..629df2e 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -166,9 +166,19 @@ struct kvmppc_rma_info {
atomic_t use_count;
};
+/*
+ * The reverse mapping array has one entry for each HPTE,
+ * which stores the guest's view of the second word of the HPTE
+ * (including the guest physical address of the mapping).
+ */
+struct revmap_entry {
+ unsigned long guest_rpte;
+};
+
struct kvm_arch {
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
+ struct revmap_entry *revmap;
unsigned long ram_npages;
unsigned long ram_psize;
unsigned long ram_porder;
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index bc3a2ea..80ece8d 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -23,6 +23,7 @@
#include <linux/gfp.h>
#include <linux/slab.h>
#include <linux/hugetlb.h>
+#include <linux/vmalloc.h>
#include <asm/tlbflush.h>
#include <asm/kvm_ppc.h>
@@ -33,11 +34,6 @@
#include <asm/ppc-opcode.h>
#include <asm/cputable.h>
-/* For now use fixed-size 16MB page table */
-#define HPT_ORDER 24
-#define HPT_NPTEG (1ul << (HPT_ORDER - 7)) /* 128B per pteg */
-#define HPT_HASH_MASK (HPT_NPTEG - 1)
-
/* Pages in the VRMA are 16MB pages */
#define VRMA_PAGE_ORDER 24
#define VRMA_VSID 0x1ffffffUL /* 1TB VSID reserved for VRMA */
@@ -51,7 +47,9 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
{
unsigned long hpt;
unsigned long lpid;
+ struct revmap_entry *rev;
+ /* Allocate guest's hashed page table */
hpt = __get_free_pages(GFP_KERNEL|__GFP_ZERO|__GFP_REPEAT|__GFP_NOWARN,
HPT_ORDER - PAGE_SHIFT);
if (!hpt) {
@@ -60,12 +58,20 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
}
kvm->arch.hpt_virt = hpt;
+ /* Allocate reverse map array */
+ rev = vmalloc(sizeof(struct revmap_entry) * HPT_NPTE);
+ if (!rev) {
+ pr_err("kvmppc_alloc_hpt: Couldn't alloc reverse map array\n");
+ goto out_freehpt;
+ }
+ kvm->arch.revmap = rev;
+
+ /* Allocate the guest's logical partition ID */
do {
lpid = find_first_zero_bit(lpid_inuse, NR_LPIDS);
if (lpid >= NR_LPIDS) {
pr_err("kvm_alloc_hpt: No LPIDs free\n");
- free_pages(hpt, HPT_ORDER - PAGE_SHIFT);
- return -ENOMEM;
+ goto out_freeboth;
}
} while (test_and_set_bit(lpid, lpid_inuse));
@@ -74,11 +80,18 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
pr_info("KVM guest htab at %lx, LPID %lx\n", hpt, lpid);
return 0;
+
+ out_freeboth:
+ vfree(rev);
+ out_freehpt:
+ free_pages(hpt, HPT_ORDER - PAGE_SHIFT);
+ return -ENOMEM;
}
void kvmppc_free_hpt(struct kvm *kvm)
{
clear_bit(kvm->arch.lpid, lpid_inuse);
+ vfree(kvm->arch.revmap);
free_pages(kvm->arch.hpt_virt, HPT_ORDER - PAGE_SHIFT);
}
@@ -89,14 +102,16 @@ void kvmppc_map_vrma(struct kvm *kvm, struct kvm_userspace_memory_region *mem)
unsigned long pfn;
unsigned long *hpte;
unsigned long hash;
+ unsigned long porder = kvm->arch.ram_porder;
+ struct revmap_entry *rev;
struct kvmppc_pginfo *pginfo = kvm->arch.ram_pginfo;
if (!pginfo)
return;
/* VRMA can't be > 1TB */
- if (npages > 1ul << (40 - kvm->arch.ram_porder))
- npages = 1ul << (40 - kvm->arch.ram_porder);
+ if (npages > 1ul << (40 - porder))
+ npages = 1ul << (40 - porder);
/* Can't use more than 1 HPTE per HPTEG */
if (npages > HPT_NPTEG)
npages = HPT_NPTEG;
@@ -113,15 +128,20 @@ void kvmppc_map_vrma(struct kvm *kvm, struct kvm_userspace_memory_region *mem)
* at most one HPTE per HPTEG, we just assume entry 7
* is available and use it.
*/
- hpte = (unsigned long *) (kvm->arch.hpt_virt + (hash << 7));
- hpte += 7 * 2;
+ hash = (hash << 3) + 7;
+ hpte = (unsigned long *) (kvm->arch.hpt_virt + (hash << 4));
/* HPTE low word - RPN, protection, etc. */
hpte[1] = (pfn << PAGE_SHIFT) | HPTE_R_R | HPTE_R_C |
HPTE_R_M | PP_RWXX;
- wmb();
+ smp_wmb();
hpte[0] = HPTE_V_1TB_SEG | (VRMA_VSID << (40 - 16)) |
(i << (VRMA_PAGE_ORDER - 16)) | HPTE_V_BOLTED |
HPTE_V_LARGE | HPTE_V_VALID;
+
+ /* Reverse map info */
+ rev = &kvm->arch.revmap[hash];
+ rev->guest_rpte = (i << porder) | HPTE_R_R | HPTE_R_C |
+ HPTE_R_M | PP_RWXX;
}
}
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index bacb0cf..6148493 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -20,10 +20,19 @@
#include <asm/synch.h>
#include <asm/ppc-opcode.h>
-/* For now use fixed-size 16MB page table */
-#define HPT_ORDER 24
-#define HPT_NPTEG (1ul << (HPT_ORDER - 7)) /* 128B per pteg */
-#define HPT_HASH_MASK (HPT_NPTEG - 1)
+/* Translate address of a vmalloc'd thing to a linear map address */
+static void *real_vmalloc_addr(void *x)
+{
+ unsigned long addr = (unsigned long) x;
+ pte_t *p;
+
+ p = find_linux_pte(swapper_pg_dir, addr);
+ if (!p || !pte_present(*p))
+ return NULL;
+ /* assume we don't have huge pages in vmalloc space... */
+ addr = (pte_pfn(*p) << PAGE_SHIFT) | (addr & ~PAGE_MASK);
+ return __va(addr);
+}
#define HPTE_V_HVLOCK 0x40UL
@@ -52,6 +61,8 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
struct kvm *kvm = vcpu->kvm;
unsigned long i, lpn, pa;
unsigned long *hpte;
+ struct revmap_entry *rev;
+ unsigned long g_ptel = ptel;
/* only handle 4k, 64k and 16M pages for now */
porder = 12;
@@ -82,7 +93,7 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
pteh &= ~0x60UL;
ptel &= ~(HPTE_R_PP0 - kvm->arch.ram_psize);
ptel |= pa;
- if (pte_index >= (HPT_NPTEG << 3))
+ if (pte_index >= HPT_NPTE)
return H_PARAMETER;
if (likely((flags & H_EXACT) == 0)) {
pte_index &= ~7UL;
@@ -95,18 +106,22 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
break;
hpte += 2;
}
+ pte_index += i;
} else {
- i = 0;
hpte = (unsigned long *)(kvm->arch.hpt_virt + (pte_index << 4));
if (!lock_hpte(hpte, HPTE_V_HVLOCK | HPTE_V_VALID))
return H_PTEG_FULL;
}
+
+ /* Save away the guest's idea of the second HPTE dword */
+ rev = real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
+ if (rev)
+ rev->guest_rpte = g_ptel;
hpte[1] = ptel;
eieio();
hpte[0] = pteh;
asm volatile("ptesync" : : : "memory");
- atomic_inc(&kvm->arch.ram_pginfo[lpn].refcnt);
- vcpu->arch.gpr[4] = pte_index + i;
+ vcpu->arch.gpr[4] = pte_index;
return H_SUCCESS;
}
@@ -138,7 +153,7 @@ long kvmppc_h_remove(struct kvm_vcpu *vcpu, unsigned long flags,
unsigned long *hpte;
unsigned long v, r, rb;
- if (pte_index >= (HPT_NPTEG << 3))
+ if (pte_index >= HPT_NPTE)
return H_PARAMETER;
hpte = (unsigned long *)(kvm->arch.hpt_virt + (pte_index << 4));
while (!lock_hpte(hpte, HPTE_V_HVLOCK))
@@ -193,7 +208,7 @@ long kvmppc_h_bulk_remove(struct kvm_vcpu *vcpu)
if (req == 3)
break;
if (req != 1 || flags == 3 ||
- pte_index >= (HPT_NPTEG << 3)) {
+ pte_index >= HPT_NPTE) {
/* parameter error */
args[i * 2] = ((0xa0 | flags) << 56) + pte_index;
ret = H_PARAMETER;
@@ -256,9 +271,10 @@ long kvmppc_h_protect(struct kvm_vcpu *vcpu, unsigned long flags,
{
struct kvm *kvm = vcpu->kvm;
unsigned long *hpte;
- unsigned long v, r, rb;
+ struct revmap_entry *rev;
+ unsigned long v, r, rb, mask, bits;
- if (pte_index >= (HPT_NPTEG << 3))
+ if (pte_index >= HPT_NPTE)
return H_PARAMETER;
hpte = (unsigned long *)(kvm->arch.hpt_virt + (pte_index << 4));
while (!lock_hpte(hpte, HPTE_V_HVLOCK))
@@ -271,11 +287,21 @@ long kvmppc_h_protect(struct kvm_vcpu *vcpu, unsigned long flags,
if (atomic_read(&kvm->online_vcpus) == 1)
flags |= H_LOCAL;
v = hpte[0];
- r = hpte[1] & ~(HPTE_R_PP0 | HPTE_R_PP | HPTE_R_N |
- HPTE_R_KEY_HI | HPTE_R_KEY_LO);
- r |= (flags << 55) & HPTE_R_PP0;
- r |= (flags << 48) & HPTE_R_KEY_HI;
- r |= flags & (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO);
+ bits = (flags << 55) & HPTE_R_PP0;
+ bits |= (flags << 48) & HPTE_R_KEY_HI;
+ bits |= flags & (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO);
+
+ /* Update guest view of 2nd HPTE dword */
+ mask = HPTE_R_PP0 | HPTE_R_PP | HPTE_R_N |
+ HPTE_R_KEY_HI | HPTE_R_KEY_LO;
+ rev = real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
+ if (rev) {
+ r = (rev->guest_rpte & ~mask) | bits;
+ rev->guest_rpte = r;
+ }
+ r = (hpte[1] & ~mask) | bits;
+
+ /* Update HPTE */
rb = compute_tlbie_rb(v, r, pte_index);
hpte[0] = v & ~HPTE_V_VALID;
if (!(flags & H_LOCAL)) {
@@ -298,38 +324,31 @@ long kvmppc_h_protect(struct kvm_vcpu *vcpu, unsigned long flags,
return H_SUCCESS;
}
-static unsigned long reverse_xlate(struct kvm *kvm, unsigned long realaddr)
-{
- long int i;
- unsigned long offset, rpn;
-
- offset = realaddr & (kvm->arch.ram_psize - 1);
- rpn = (realaddr - offset) >> PAGE_SHIFT;
- for (i = 0; i < kvm->arch.ram_npages; ++i)
- if (rpn == kvm->arch.ram_pginfo[i].pfn)
- return (i << PAGE_SHIFT) + offset;
- return HPTE_R_RPN; /* all 1s in the RPN field */
-}
-
long kvmppc_h_read(struct kvm_vcpu *vcpu, unsigned long flags,
unsigned long pte_index)
{
struct kvm *kvm = vcpu->kvm;
unsigned long *hpte, r;
int i, n = 1;
+ struct revmap_entry *rev = NULL;
- if (pte_index >= (HPT_NPTEG << 3))
+ if (pte_index >= HPT_NPTE)
return H_PARAMETER;
if (flags & H_READ_4) {
pte_index &= ~3;
n = 4;
}
+ if (flags & H_R_XLATE)
+ rev = real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
for (i = 0; i < n; ++i, ++pte_index) {
hpte = (unsigned long *)(kvm->arch.hpt_virt + (pte_index << 4));
r = hpte[1];
- if ((flags & H_R_XLATE) && (hpte[0] & HPTE_V_VALID))
- r = reverse_xlate(kvm, r & HPTE_R_RPN) |
- (r & ~HPTE_R_RPN);
+ if (hpte[0] & HPTE_V_VALID) {
+ if (rev)
+ r = rev[i].guest_rpte;
+ else
+ r = hpte[1] | HPTE_R_RPN;
+ }
vcpu->arch.gpr[4 + i * 2] = hpte[0];
vcpu->arch.gpr[5 + i * 2] = r;
}
--
1.7.5.4
^ permalink raw reply related
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