* [PATCH 4/4][v2] powerpc/85xx: Update corenet64_smp_defconfig for B4_QDS
From: Shaveta Leekha @ 2013-04-05 6:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
In-Reply-To: <1365143632-19362-1-git-send-email-shaveta@freescale.com>
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 1c6eb66..6c8b020 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -21,6 +21,7 @@ CONFIG_MODVERSIONS=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
+CONFIG_B4_QDS=y
CONFIG_P5020_DS=y
CONFIG_P5040_DS=y
CONFIG_T4240_QDS=y
--
1.7.6.GIT
^ permalink raw reply related
* [PATCH 3/4][v2] powerpc/fsl-booke: Add B4_QDS board support
From: Shaveta Leekha @ 2013-04-05 6:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
In-Reply-To: <1365143632-19362-1-git-send-email-shaveta@freescale.com>
- Add support for B4 board in board file b4_qds.c,
It is common for B4860, B4420 and B4220QDS as they share same QDS board
- Add B4QDS support in Kconfig and Makefile
B4860QDS is a high-performance computing evaluation, development and
test platform supporting the B4860 QorIQ Power Architecture processor,
with following major features:
- Four dual-threaded e6500 Power Architecture processors
organized in one cluster-each core runs up to 1.8 GHz
- Two DDR3/3L controllers for high-speed memory interface each
runs at up to 1866.67 MHz
- CoreNet fabric that fully supports coherency using MESI protocol
between the e6500 cores, SC3900 FVP cores, memories and
external interfaces.
- Data Path Acceleration Architecture having FMAN, QMan, BMan,
SEC 5.3 and RMAN
- Large internal cache memory with snooping and stashing capabilities
- Sixteen 10-GHz SerDes lanes that serve:
- Two SRIO interfaces. Each supports up to 4 lanes and
a total of up to 8 lanes
- Up to 8-lanes Common Public Radio Interface (CPRI) controller
for glue-less antenna connection
- Two 10-Gbit Ethernet controllers (10GEC)
- Six 1G/2.5-Gbit Ethernet controllers for network communications
- PCI Express controller
- Debug (Aurora)
- Various system peripherals
B4420 and B4220 have some differences in comparison to B4860 with fewer
core/clusters(both SC3900 and e6500), fewer DDR controllers,
fewer serdes lanes, fewer SGMII interfaces and reduced target frequencies.
Key differences between B4860 and B4420:
B4420 has:
- Fewer e6500 cores:
1 cluster with 2 e6500 cores
- Fewer SC3900 cores/clusters:
1 cluster with 2 SC3900 cores per cluster
- Single DDRC @ 1.6GHz
- 2 X 4 lane serdes
- 3 SGMII interfaces
- no sRIO
- no 10G
Key differences between B4860 and B4220:
B4220 has:
- Fewer e6500 cores:
1 cluster with 1 e6500 core
- Fewer SC3900 cores/clusters:
1 cluster with 2 SC3900 cores per cluster
- Single DDRC @ 1.33GHz
- 2 X 2 lane serdes
- 2 SGMII interfaces
- no sRIO
- no 10G
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
v2: lines of commit message wrapped at 75 chars max
arch/powerpc/platforms/85xx/Kconfig | 17 ++++++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/b4_qds.c | 102 ++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 31dc066..8f02b05 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -321,6 +321,23 @@ config T4240_QDS
help
This option enables support for the T4240 QDS board
+config B4_QDS
+ bool "Freescale B4 QDS"
+ select DEFAULT_UIMAGE
+ select E500
+ select PPC_E500MC
+ select PHYS_64BIT
+ select SWIOTLB
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ select HAS_RAPIDIO
+ select PPC_EPAPR_HV_PIC
+ help
+ This option enables support for the B4 QDS board
+ The B4 application development system B4 QDS is a complete
+ debugging environment intended for engineers developing
+ applications for the B4.
+
endif
endif # FSL_SOC_BOOKE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 712e233..2eab37e 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS) += p5020_ds.o corenet_ds.o
obj-$(CONFIG_P5040_DS) += p5040_ds.o corenet_ds.o
obj-$(CONFIG_T4240_QDS) += t4240_qds.o corenet_ds.o
+obj-$(CONFIG_B4_QDS) += b4_qds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/b4_qds.c b/arch/powerpc/platforms/85xx/b4_qds.c
new file mode 100644
index 0000000..0c6702f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/b4_qds.c
@@ -0,0 +1,102 @@
+/*
+ * B4 QDS Setup
+ * Should apply for QDS platform of B4860 and it's personalities.
+ * viz B4860/B4420/B4220QDS
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/phy.h>
+
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include <asm/ehv_pic.h>
+
+#include "corenet_ds.h"
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init b4_qds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
+
+ if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS")) ||
+ (of_flat_dt_is_compatible(root, "fsl,B4420QDS")) ||
+ (of_flat_dt_is_compatible(root, "fsl,B4220QDS")))
+ return 1;
+
+ /* Check if we're running under the Freescale hypervisor */
+ if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS-hv")) ||
+ (of_flat_dt_is_compatible(root, "fsl,B4420QDS-hv")) ||
+ (of_flat_dt_is_compatible(root, "fsl,B4220QDS-hv"))) {
+ ppc_md.init_IRQ = ehv_pic_init;
+ ppc_md.get_irq = ehv_pic_get_irq;
+ ppc_md.restart = fsl_hv_restart;
+ ppc_md.power_off = fsl_hv_halt;
+ ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
+ return 1;
+ }
+
+ return 0;
+}
+
+define_machine(b4_qds) {
+ .name = "B4 QDS",
+ .probe = b4_qds_probe,
+ .setup_arch = corenet_ds_setup_arch,
+ .init_IRQ = corenet_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
+#ifdef CONFIG_PPC64
+ .get_irq = mpic_get_irq,
+#else
+ .get_irq = mpic_get_coreint_irq,
+#endif
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+#ifdef CONFIG_PPC64
+ .power_save = book3e_idle,
+#else
+ .power_save = e500_idle,
+#endif
+};
+
+machine_arch_initcall(b4_qds, corenet_ds_publish_devices);
+
+#ifdef CONFIG_SWIOTLB
+machine_arch_initcall(b4_qds, swiotlb_setup_bus_notifier);
+#endif
--
1.7.6.GIT
^ permalink raw reply related
* Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-04-05 6:46 UTC (permalink / raw)
To: rjw, deepthi
Cc: robin.randhawa, linux-pm, Viresh Kumar, patches, Liviu.Dudau,
linux-kernel, cpufreq, Steve.Bannister, Paul Mackerras,
Olof Johansson, arvind.chauhan, linuxppc-dev, linaro-kernel,
charles.garcia-tobin
In-Reply-To: <027e8f1d4ac8de6351115f15a408431558510abb.1365079581.git.viresh.kumar@linaro.org>
On 4 April 2013 18:24, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Compile Tested only.
>
> arch/powerpc/platforms/Kconfig | 31 ----------------------
> arch/powerpc/platforms/pasemi/Makefile | 1 -
> arch/powerpc/platforms/powermac/Makefile | 2 --
> drivers/cpufreq/Kconfig.powerpc | 26 ++++++++++++++++++
> drivers/cpufreq/Makefile | 3 +++
> .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0
> .../cpufreq/pmac32-cpufreq.c | 0
> .../cpufreq/pmac64-cpufreq.c | 0
> 8 files changed, 29 insertions(+), 34 deletions(-)
> rename arch/powerpc/platforms/pasemi/cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c (100%)
> rename arch/powerpc/platforms/powermac/cpufreq_32.c => drivers/cpufreq/pmac32-cpufreq.c (100%)
> rename arch/powerpc/platforms/powermac/cpufreq_64.c => drivers/cpufreq/pmac64-cpufreq.c (100%)
Hi Deepthi,
Can you help testing this please?
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Set default VGA device
From: Michael Ellerman @ 2013-04-05 6:52 UTC (permalink / raw)
To: Brian King; +Cc: klebers, linux-pci, bhelgaas, linuxppc-dev, lucaskt
In-Reply-To: <201304042158.r34LwGPg010714@d03av02.boulder.ibm.com>
Hi Brian,
On Thu, Apr 04, 2013 at 04:58:17PM -0500, Brian King wrote:
>
> Add a PCI quirk for VGA devices on Power to set the default VGA device.
> Ensures a default VGA is always set if a graphics adapter is present,
> even if firmware did not initialize it. If more than one graphics
> adapter is present, ensure the one initialized by firmware is set
> as the default VGA device. This ensures that X autoconfiguration
> will work.
So a few things:
- You are doing this on all power systems, not just pseries which is I
assume what you're testing on - that seems OK to me, but just
checking.
- What is the "initialized by firmware" test? Just that IO & MEM are
enabled?
- You potentially override an existing default, is that a problem? Can
the user set the default? (no AFAICS).
- The x86 code is slightly different, they don't override an existing
default, why do we?
cheers
^ permalink raw reply
* Re: [PATCH 1/3] pci: Export pci_dev_type
From: Michael Ellerman @ 2013-04-05 6:55 UTC (permalink / raw)
To: Brian King; +Cc: klebers, linux-pci, bhelgaas, linuxppc-dev, lucaskt
In-Reply-To: <201304042158.r34LwDHx010466@d03av02.boulder.ibm.com>
Hi Bjorn,
Should we take this series via the powerpc tree, assuming you're OK with
this patch?
cheers
On Thu, Apr 04, 2013 at 04:58:13PM -0500, Brian King wrote:
>
> Export pci_dev_type so that arch specific PCI probing code can
> initialize a new PCI device struct.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> drivers/pci/pci.h | 1 -
> include/linux/pci.h | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/pci/pci.h~pci_export_pci_dev_type drivers/pci/pci.h
> --- linux/drivers/pci/pci.h~pci_export_pci_dev_type 2013-04-02 17:01:25.000000000 -0500
> +++ linux-bjking1/drivers/pci/pci.h 2013-04-02 17:02:31.000000000 -0500
> @@ -153,7 +153,6 @@ static inline int pci_no_d1d2(struct pci
> }
> extern struct device_attribute pci_dev_attrs[];
> extern struct device_attribute pcibus_dev_attrs[];
> -extern struct device_type pci_dev_type;
> extern struct bus_attribute pci_bus_attrs[];
>
>
> diff -puN include/linux/pci.h~pci_export_pci_dev_type include/linux/pci.h
> --- linux/include/linux/pci.h~pci_export_pci_dev_type 2013-04-02 17:01:59.000000000 -0500
> +++ linux-bjking1/include/linux/pci.h 2013-04-02 17:02:29.000000000 -0500
> @@ -670,6 +670,7 @@ enum pcie_bus_config_types {
> extern enum pcie_bus_config_types pcie_bus_config;
>
> extern struct bus_type pci_bus_type;
> +extern struct device_type pci_dev_type;
>
> /* Do NOT directly access these two variables, unless you are arch specific pci
> * code, or pci core code. */
> _
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: Add HWCAP2 aux entry
From: Michael Ellerman @ 2013-04-05 7:06 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: michaele, vda.linux, Steve Munroe, linux-kernel, paulus, viro,
Ryan Arnold, linuxppc-dev, akpm
In-Reply-To: <20130402212204.GA30438@linux.vnet.ibm.com>
Hi guys,
Added some folks to CC, blame scripts/get_maintainer.pl.
Comment below ..
On Tue, Apr 02, 2013 at 02:22:05PM -0700, Nishanth Aravamudan wrote:
> From: Michael Neuling <michael.neuling@au1.ibm.com>
>
> We are currently out of free bits in AT_HWCAP. With POWER8, we have
> several hardware features that we need to advertise. Tested on POWER and
> x86.
>
> Signed-off-by: Michael Neuling <michael.neuling@au1.ibm.com>
> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index fb3245e..ccadad6 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -52,6 +52,7 @@ struct cpu_spec {
> char *cpu_name;
> unsigned long cpu_features; /* Kernel features */
> unsigned int cpu_user_features; /* Userland features */
> + unsigned int cpu_user_features2; /* Userland features v2 */
> unsigned int mmu_features; /* MMU features */
>
> /* cache line sizes */
> diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
> index ac9790f..cc0655a 100644
> --- a/arch/powerpc/include/asm/elf.h
> +++ b/arch/powerpc/include/asm/elf.h
> @@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
> instruction set this cpu supports. This could be done in userspace,
> but it's not easy, and we've already done it here. */
> # define ELF_HWCAP (cur_cpu_spec->cpu_user_features)
> +# define ELF_HWCAP2 (cur_cpu_spec->cpu_user_features2)
>
> /* This yields a string that ld.so will use to load implementation
> specific libraries for optimization. This is more specific in
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 3939829..51adc23 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -140,6 +140,13 @@ static int padzero(unsigned long elf_bss)
> #define ELF_BASE_PLATFORM NULL
> #endif
>
> +/*
> + * Most archs don't need this
> + */
> +#ifndef ELF_HWCAP2
> +#define ELF_HWCAP2 (0)
> +#endif
> +
> static int
> create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> unsigned long load_addr, unsigned long interp_load_addr)
> @@ -240,6 +247,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
> NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
> NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
> + NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
Wouldn't it be safer to not emit AT_HWCAP2 unless it is defined by the arch?
That way the change would only impact powerpc.
cheers
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index 9c13e02..0b553d3 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -469,6 +469,13 @@ error_kill:
> #endif
>
> /*
> + * Most archs don't need this
> + */
> +#ifndef ELF_HWCAP2
> +#define ELF_HWCAP2 (0)
> +#endif
> +
> +/*
> * present useful information to the program by shovelling it onto the new
> * process's stack
> */
> @@ -483,7 +490,6 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
> size_t platform_len = 0, len;
> char *k_platform, *k_base_platform;
> char __user *u_platform, *u_base_platform, *p;
> - long hwcap;
> int loop;
> int nr; /* reset for each csp adjustment */
>
> @@ -502,8 +508,6 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
> return -EFAULT;
> #endif
>
> - hwcap = ELF_HWCAP;
> -
> /*
> * If this architecture has a platform capability string, copy it
> * to userspace. In some cases (Sparc), this info is impossible
> @@ -617,7 +621,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
>
> nr = 0;
> csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
> - NEW_AUX_ENT(AT_HWCAP, hwcap);
> + NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> + NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
> NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
> NEW_AUX_ENT(AT_PHDR, exec_params->ph_addr);
> diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
> index 61594d5..835c065 100644
> --- a/include/uapi/linux/auxvec.h
> +++ b/include/uapi/linux/auxvec.h
> @@ -28,6 +28,7 @@
> #define AT_BASE_PLATFORM 24 /* string identifying real platform, may
> * differ from AT_PLATFORM. */
> #define AT_RANDOM 25 /* address of 16 random bytes */
> +#define AT_HWCAP2 26 /* extension of AT_HWCAP */
>
> #define AT_EXECFN 31 /* filename of program */
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [PATCH] bookehv: Handle debug exception on guest exit
From: Bhushan Bharat-R65777 @ 2013-04-05 7:53 UTC (permalink / raw)
To: Alexander Graf, Kumar Gala, Benjamin Herrenschmidt
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D06FC04D4@039-SN2MPN1-013.039d.mgd.msft.net>
Hi Kumar/Benh,
After further looking into the code I think that if we correct the vector r=
ange below in DebugDebug handler then we do not need the change I provided =
in this patch.
Here is the snapshot for 32 bit (head_booke.h, same will be true for 64 bit=
):
#define DEBUG_DEBUG_EXCEPTION =
\
START_EXCEPTION(DebugDebug); =
\
DEBUG_EXCEPTION_PROLOG; =
\
=
\
/* =
\
* If there is a single step or branch-taken exception in an =
\
* exception entry sequence, it was probably meant to apply to =
\
* the code where the exception occurred (since exception entry =
\
* doesn't turn off DE automatically). We simulate the effect =
\
* of turning off DE on entry to an exception handler by turning =
\
* off DE in the DSRR1 value and clearing the debug status. =
\
*/ =
\
mfspr r10,SPRN_DBSR; /* check single-step/branch taken *=
/ \
andis. r10,r10,(DBSR_IC|DBSR_BT)@h; =
\
beq+ 2f; =
\
=
\
lis r10,KERNELBASE@h; /* check if exception in vectors */=
\
ori r10,r10,KERNELBASE@l; =
\
cmplw r12,r10; =
\
blt+ 2f; /* addr below exception vectors */ =
\
=
\
lis r10,DebugDebug@h; \
ori r10,r10,DebugDebug@l; =
\
^^^^
Here we assume all exception vector ends at DebugDebug, which is not corre=
ct.
We probably should get proper end by using some start_vector and end_vecto=
r lebels
or at least use end at Ehvpriv (which is last defined in head_fsl_booke.S =
for PowerPC. Is that correct?
=09
cmplw r12,r10; =
\
bgt+ 2f; /* addr above exception vectors */ =
\
Thanks
-Bharat
> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org=
] On
> Behalf Of Bhushan Bharat-R65777
> Sent: Thursday, April 04, 2013 8:29 PM
> To: Alexander Graf
> Cc: linuxppc-dev@lists.ozlabs.org; kvm@vger.kernel.org; kvm-ppc@vger.kern=
el.org;
> Wood Scott-B07421
> Subject: RE: [PATCH] bookehv: Handle debug exception on guest exit
>=20
>=20
>=20
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Thursday, April 04, 2013 6:55 PM
> > To: Bhushan Bharat-R65777
> > Cc: linuxppc-dev@lists.ozlabs.org; kvm@vger.kernel.org;
> > kvm-ppc@vger.kernel.org; Wood Scott-B07421; Bhushan Bharat-R65777
> > Subject: Re: [PATCH] bookehv: Handle debug exception on guest exit
> >
> >
> > On 20.03.2013, at 18:45, Bharat Bhushan wrote:
> >
> > > EPCR.DUVD controls whether the debug events can come in hypervisor
> > > mode or not. When KVM guest is using the debug resource then we do
> > > not want debug events to be captured in guest entry/exit path. So we
> > > set EPCR.DUVD when entering and clears EPCR.DUVD when exiting from gu=
est.
> > >
> > > Debug instruction complete is a post-completion debug exception but
> > > debug event gets posted on the basis of MSR before the instruction
> > > is executed. Now if the instruction switches the context from guest
> > > mode (MSR.GS =3D 1) to hypervisor mode (MSR.GS =3D 0) then the xSRR0
> > > points to first instruction of KVM handler and xSRR1 points that
> > > MSR.GS is clear (hypervisor context). Now as xSRR1.GS is used to
> > > decide whether KVM handler will be invoked to handle the exception
> > > or host host kernel debug handler will be invoked to handle the excep=
tion.
> > > This leads to host kernel debug handler handling the exception which
> > > should either be handled by KVM.
> > >
> > > This is tested on e500mc in 32 bit mode
> > >
> > > Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> > > ---
> > > v0:
> > > - Do not apply this change for debug_crit as we do not know those
> > > chips have
> > issue or not.
> > > - corrected 64bit case branching
> > >
> > > arch/powerpc/kernel/exceptions-64e.S | 29 +++++++++++++++++++++++++=
+++-
> > > arch/powerpc/kernel/head_booke.h | 26 +++++++++++++++++++++++++=
+
> > > 2 files changed, 54 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/exceptions-64e.S
> > > b/arch/powerpc/kernel/exceptions-64e.S
> > > index 4684e33..8b26294 100644
> > > --- a/arch/powerpc/kernel/exceptions-64e.S
> > > +++ b/arch/powerpc/kernel/exceptions-64e.S
> > > @@ -516,6 +516,33 @@ kernel_dbg_exc:
> > > andis. r15,r14,DBSR_IC@h
> > > beq+ 1f
> > >
> > > +#ifdef CONFIG_KVM_BOOKE_HV
> > > + /*
> > > + * EPCR.DUVD controls whether the debug events can come in
> > > + * hypervisor mode or not. When KVM guest is using the debug
> > > + * resource then we do not want debug events to be captured
> > > + * in guest entry/exit path. So we set EPCR.DUVD when entering
> > > + * and clears EPCR.DUVD when exiting from guest.
> > > + * Debug instruction complete is a post-completion debug
> > > + * exception but debug event gets posted on the basis of MSR
> > > + * before the instruction is executed. Now if the instruction
> > > + * switches the context from guest mode (MSR.GS =3D 1) to hyperviso=
r
> > > + * mode (MSR.GS =3D 0) then the xSRR0 points to first instruction o=
f
> >
> > Can't we just execute that code path with MSR.DE=3D0?
>=20
> Single stepping uses DBCR0.IC (instruction complete).
> Can you describe how MSR.DE =3D 0 will work?
>=20
> >
> >
> > Alex
> >
> > > + * KVM handler and xSRR1 points that MSR.GS is clear
> > > + * (hypervisor context). Now as xSRR1.GS is used to decide whether
> > > + * KVM handler will be invoked to handle the exception or host
> > > + * host kernel debug handler will be invoked to handle the exceptio=
n.
> > > + * This leads to host kernel debug handler handling the exception
> > > + * which should either be handled by KVM.
> > > + */
> > > + mfspr r10, SPRN_EPCR
> > > + andis. r10,r10,SPRN_EPCR_DUVD@h
> > > + beq+ 2f
> > > +
> > > + andis. r10,r9,MSR_GS@h
> > > + beq+ 3f
> > > +2:
> > > +#endif
> > > LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
> > > LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
> > > cmpld cr0,r10,r14
> > > @@ -523,7 +550,7 @@ kernel_dbg_exc:
> > > blt+ cr0,1f
> > > bge+ cr1,1f
> > >
> > > - /* here it looks like we got an inappropriate debug exception. */
> > > +3: /* here it looks like we got an inappropriate debug exception. */
> > > lis r14,DBSR_IC@h /* clear the IC event */
> > > rlwinm r11,r11,0,~MSR_DE /* clear DE in the DSRR1 value */
> > > mtspr SPRN_DBSR,r14
> > > diff --git a/arch/powerpc/kernel/head_booke.h
> > > b/arch/powerpc/kernel/head_booke.h
> > > index 5f051ee..edc6a3b 100644
> > > --- a/arch/powerpc/kernel/head_booke.h
> > > +++ b/arch/powerpc/kernel/head_booke.h
> > > @@ -285,7 +285,33 @@ label:
> > > mfspr r10,SPRN_DBSR; /* check single-step/branch taken */ \
> > > andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \
> > > beq+ 2f; \
> > > +#ifdef CONFIG_KVM_BOOKE_HV \
> > > + /* \
> > > + * EPCR.DUVD controls whether the debug events can come in \
> > > + * hypervisor mode or not. When KVM guest is using the debug =
\
> > > + * resource then we do not want debug events to be captured =
\
> > > + * in guest entry/exit path. So we set EPCR.DUVD when entering =
\
> > > + * and clears EPCR.DUVD when exiting from guest. \
> > > + * Debug instruction complete is a post-completion debug \
> > > + * exception but debug event gets posted on the basis of MSR =
\
> > > + * before the instruction is executed. Now if the instruction =
\
> > > + * switches the context from guest mode (MSR.GS =3D 1) to hyperviso=
r \
> > > + * mode (MSR.GS =3D 0) then the xSRR0 points to first instruction o=
f \
> > > + * KVM handler and xSRR1 points that MSR.GS is clear \
> > > + * (hypervisor context). Now as xSRR1.GS is used to decide whether =
\
> > > + * KVM handler will be invoked to handle the exception or host =
\
> > > + * host kernel debug handler will be invoked to handle the exceptio=
n. \
> > > + * This leads to host kernel debug handler handling the exception =
\
> > > + * which should either be handled by KVM. \
> > > + */ \
> > > + mfspr r10, SPRN_EPCR; \
> > > + andis. r10,r10,SPRN_EPCR_DUVD@h; \
> > > + beq+ 3f; \
> > > \
> > > + andis. r10,r9,MSR_GS@h; \
> > > + beq+ 1f; \
> > > +3: \
> > > +#endif \
> > > lis r10,KERNELBASE@h; /* check if exception in vectors */ \
> > > ori r10,r10,KERNELBASE@l; \
> > > cmplw r12,r10; \
> > > --
> > > 1.7.0.4
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe kvm-ppc"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the=
body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Fix cpu unit address to match reg on
From: Kumar Gala @ 2013-04-05 14:20 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
index 9b39a43..a93c55a 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
@@ -69,57 +69,57 @@
reg = <0 1>;
next-level-cache = <&L2_1>;
};
- cpu1: PowerPC,e6500@1 {
+ cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
next-level-cache = <&L2_1>;
};
- cpu2: PowerPC,e6500@2 {
+ cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
next-level-cache = <&L2_1>;
};
- cpu3: PowerPC,e6500@3 {
+ cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
next-level-cache = <&L2_1>;
};
- cpu4: PowerPC,e6500@4 {
+ cpu4: PowerPC,e6500@8 {
device_type = "cpu";
reg = <8 9>;
next-level-cache = <&L2_2>;
};
- cpu5: PowerPC,e6500@5 {
+ cpu5: PowerPC,e6500@10 {
device_type = "cpu";
reg = <10 11>;
next-level-cache = <&L2_2>;
};
- cpu6: PowerPC,e6500@6 {
+ cpu6: PowerPC,e6500@12 {
device_type = "cpu";
reg = <12 13>;
next-level-cache = <&L2_2>;
};
- cpu7: PowerPC,e6500@7 {
+ cpu7: PowerPC,e6500@14 {
device_type = "cpu";
reg = <14 15>;
next-level-cache = <&L2_2>;
};
- cpu8: PowerPC,e6500@8 {
+ cpu8: PowerPC,e6500@16 {
device_type = "cpu";
reg = <16 17>;
next-level-cache = <&L2_3>;
};
- cpu9: PowerPC,e6500@9 {
+ cpu9: PowerPC,e6500@18 {
device_type = "cpu";
reg = <18 19>;
next-level-cache = <&L2_3>;
};
- cpu10: PowerPC,e6500@10 {
+ cpu10: PowerPC,e6500@20 {
device_type = "cpu";
reg = <20 21>;
next-level-cache = <&L2_3>;
};
- cpu11: PowerPC,e6500@11 {
+ cpu11: PowerPC,e6500@22 {
device_type = "cpu";
reg = <22 23>;
next-level-cache = <&L2_3>;
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Kumar Gala @ 2013-04-05 14:22 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1365143632-19362-1-git-send-email-shaveta@freescale.com>
On Apr 5, 2013, at 1:33 AM, Shaveta Leekha wrote:
> B4860 and B4420 are similar that share some commonalities
>=20
> * common features have been added in b4si-pre.dtsi and b4si-post.dtsi
> * differences are added in respective silicon files of B4860 and B4420
>=20
> There are several things missing from the device trees of B4860 and =
B4420:
>=20
> * DPAA related nodes (Qman, Bman, Fman, Rman)
> * DSP related nodes/information
> * serdes, sfp(security fuse processor), thermal,
> gpio, maple, cpri, quad timers nodes
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> v2:=20
> - incorporated review comments on commits message
> - change unit address of cpu nodes to match the reg property
>=20
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 94 ++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 49 +++++
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 138 ++++++++++++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 59 ++++++
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 262 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/b4si-pre.dtsi | 65 +++++++
> 6 files changed, 667 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
Is there a reason you didn't get rid of b4si-pre.dtsi and just merge it =
into b4860si-pre.dtsi & b4420-pre.dtsi?
- k=
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Set default VGA device
From: Brian King @ 2013-04-05 15:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: klebers, linux-pci, bhelgaas, linuxppc-dev, lucaskt
In-Reply-To: <20130405065238.GC5082@concordia>
On 04/05/2013 01:52 AM, Michael Ellerman wrote:
> Hi Brian,
>
>
> On Thu, Apr 04, 2013 at 04:58:17PM -0500, Brian King wrote:
>>
>> Add a PCI quirk for VGA devices on Power to set the default VGA device.
>> Ensures a default VGA is always set if a graphics adapter is present,
>> even if firmware did not initialize it. If more than one graphics
>> adapter is present, ensure the one initialized by firmware is set
>> as the default VGA device. This ensures that X autoconfiguration
>> will work.
>
> So a few things:
>
> - You are doing this on all power systems, not just pseries which is I
> assume what you're testing on - that seems OK to me, but just
> checking.
Correct. I've only tested on pseries, but figured it would make sense for
this to be more generic. I'm happy to make this pseries specific if that
is preferred.
> - What is the "initialized by firmware" test? Just that IO & MEM are
> enabled?
Correct. This is what the x86 code does. Alternatively, its possible
there is a chosen attribute in the device tree we could look at.
> - You potentially override an existing default, is that a problem? Can
> the user set the default? (no AFAICS).
I couldn't find anywhere that this could be set by the user and wanted to
be able to handle both the case of a single adapter that wasn't initialized
by firmware as well as the multi adapter case where only one of the adapters was
initialized by firmware. I could have made this smarter so that we only
override the default if the previous default was not initialized by firmware,
but opted for the simpler patch.
> - The x86 code is slightly different, they don't override an existing
> default, why do we?
I wanted to be able to handle the case of a single graphics adapter installed in a system
that has not been initialized by firmware, since I have a system like this. This generally
isn't something that x86 would need to do since all graphics adapters should have x86 boot
code in them, but very few current graphics adapters have fcode in them today.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* RE: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Leekha Shaveta-B20052 @ 2013-04-05 15:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <62911773-1FC6-49B5-993F-88DD0F8F845A@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, April 05, 2013 7:53 PM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org list
Subject: Re: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device =
tree files for B4860 and B4420
On Apr 5, 2013, at 1:33 AM, Shaveta Leekha wrote:
> B4860 and B4420 are similar that share some commonalities
>=20
> * common features have been added in b4si-pre.dtsi and b4si-post.dtsi
> * differences are added in respective silicon files of B4860 and B4420
>=20
> There are several things missing from the device trees of B4860 and B4420=
:
>=20
> * DPAA related nodes (Qman, Bman, Fman, Rman)
> * DSP related nodes/information
> * serdes, sfp(security fuse processor), thermal, gpio, maple, cpri,=20
> quad timers nodes
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> v2:=20
> - incorporated review comments on commits message
> - change unit address of cpu nodes to match the reg property
>=20
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 94 ++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 49 +++++
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 138 ++++++++++++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 59 ++++++
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 262 ++++++++++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/b4si-pre.dtsi | 65 +++++++
> 6 files changed, 667 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
Is there a reason you didn't get rid of b4si-pre.dtsi and just merge it int=
o b4860si-pre.dtsi & b4420-pre.dtsi?
[SL] No particular reason. I have just tried to re-factored these files as =
you have suggested. Hence managed the commonalities in B4 files and differe=
nces in B4860's and B4420's respective files to reduce duplicity.
Regards,
Shaveta=20
- k
^ permalink raw reply
* Re: [PATCH v2 2/11] Add PRRN Event Handler
From: Nathan Fontenot @ 2013-04-05 15:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130404033436.GC19443@drongo>
On 04/03/2013 10:34 PM, Paul Mackerras wrote:
> On Mon, Mar 25, 2013 at 01:52:32PM -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> A PRRN event is signaled via the RTAS event-scan mechanism, which
>> returns a Hot Plug Event message "fixed part" indicating "Platform
>> Resource Reassignment". In response to the Hot Plug Event message,
>> we must call ibm,update-nodes to determine which resources were
>> reassigned and then ibm,update-properties to obtain the new affinity
>> information about those resources.
>>
>> The PRRN event-scan RTAS message contains only the "fixed part" with
>> the "Type" field set to the value 160 and no Extended Event Log. The
>> four-byte Extended Event Log Length field is repurposed (since no
>> Extended Event Log message is included) to pass the "scope" parameter
>> that causes the ibm,update-nodes to return the nodes affected by the
>> specific resource reassignment.
>>
>> This patch adds a handler in rtasd for PRRN RTAS events. The function
>> pseries_devicetree_update() (from mobility.c) is used to make the
>> ibm,update-nodes/ibm,update-properties RTAS calls. Updating the NUMA maps
>> (handled by a subsequent patch) will require significant processing,
>> so pseries_devicetree_update() is called from an asynchronous workqueue
>> to allow rtasd to continue processing events. Since we flush all work
>> on the queue before handling any new work there should only be one event
>> in flight of being handled at a time.
> ^^ "of" is superfluous
will remove it.
>
> In the worst case where PRRN events come close together in time, the
> flush_work will block for however long it takes to do this
> "significant processing", meaning that we're no better off using a
> workqueue. Do we have any reason to think that these PRRN events will
> normally be widely spaced in time? If so you should mention it in the
> patch description.
Yes. PRRN events can only be triggered from the HMC by an IBM tech who has
to actualy log into a customer system and initiate the PRRN event. There
is no method for a user to initiate a PRRN event. Given this is is safe
to assume that these events will be widely spaced in time.
>
> Also, rtasd isn't actually a task, it's just a function that gets run
> via schedule_delayed_work_on() and re-schedules itself each time it
> runs. Is there any deadlock possibility in calling flush_work from a
> work function?
I don't know of any but I will investigate.
Thanks for the feedback.
-Nathan
^ permalink raw reply
* Re: [RFC][PATCH 2/2] powerpc/fsl-pci Make PCIe hotplug work with Freescale
From: Kumar Gala @ 2013-04-05 17:37 UTC (permalink / raw)
To: Rojhalat Ibrahim; +Cc: linuxppc-dev
In-Reply-To: <2139831.oouZXZo4xk@pcimr>
On Apr 3, 2013, at 2:09 AM, Rojhalat Ibrahim wrote:
> Hi Kumar,
>=20
> what about this patch? Any reasons not to apply?
>=20
> Rojhalat
Was on vacation, getting back to it now. Do send a proper patch =
w/commit message & signed-off-by.
- k
>=20
>=20
> On Monday 18 March 2013 10:22:40 Rojhalat Ibrahim wrote:
>> On Thursday 14 March 2013 15:35:40 Kumar Gala wrote:
>>> On Mar 14, 2013, at 4:43 AM, Rojhalat Ibrahim wrote:
>>>> On Wednesday 13 March 2013 14:07:16 Kumar Gala wrote:
>>>>> diff --git a/arch/powerpc/sysdev/fsl_pci.c
>>>>> b/arch/powerpc/sysdev/fsl_pci.c
>>>>> index 41bbcc4..b18c377 100644
>>>>> --- a/arch/powerpc/sysdev/fsl_pci.c
>>>>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>>>>> @@ -74,6 +74,35 @@ static int __init fsl_pcie_check_link(struct
>>>>> pci_controller *hose) return 0;
>>>>> }
>>>>>=20
>>>>> +static int fsl_indirect_read_config(struct pci_bus *bus, unsigned =
int
>>>>> devfn, + int offset, int len, u32 =
*val)
>>>>> +{
>>>>> + struct pci_controller *hose =3D pci_bus_to_host(bus);
>>>>> +
>>>>> + /* check the link status */
>>>>> + if ((bus->number =3D=3D hose->first_busno) && (devfn =3D=3D 0)) =
{
>>>>> + if (fsl_pcie_check_link(hose))
>>>>> + hose->indirect_type |=3D =
PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>>>>> + else
>>>>> + hose->indirect_type &=3D =
~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>>>>> + }
>>>>> + return indirect_read_config(bus, devfn, offset, len, val);
>>>>> +}
>>>>> +
>>>>=20
>>>> This does not work because fsl_indirect_read_config calls
>>>> fsl_pcie_check_link which calls early_read_config_dword which =
eventually
>>>> calls fsl_indirect_read_config, so the kernel hangs in a recursion =
loop.
>>>> Below is a modified patch that does work.
>>>=20
>>> ok, that makes sense, but I guess now its making me question the =
following=20
> statement:
>>>> if ((bus->number =3D=3D hose->first_busno) && (devfn =3D=3D 0)) {
>>>=20
>>> Why do we have this conditional?
>>>=20
>>> - k
>>=20
>> Right. This is not necessary anymore. I modified the patch =
accordingly.
>>=20
>>=20
>> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
>> ---
>> arch/powerpc/include/asm/pci-bridge.h | 6 ++++
>> arch/powerpc/sysdev/fsl_pci.c | 51
>> +++++++++++++++++++++++++++++----- arch/powerpc/sysdev/indirect_pci.c =
|=20
>> 10 ++----
>> 3 files changed, 54 insertions(+), 13 deletions(-)
>>=20
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h
>> b/arch/powerpc/include/asm/pci-bridge.h index c0278f0..ffbc5fd 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -120,6 +120,12 @@ extern void setup_indirect_pci(struct =
pci_controller*
>> hose, resource_size_t cfg_addr,
>> resource_size_t cfg_data, u32 flags);
>>=20
>> +extern int indirect_read_config(struct pci_bus *bus, unsigned int =
devfn,
>> + int offset, int len, u32 *val);
>> +
>> +extern int indirect_write_config(struct pci_bus *bus, unsigned int =
devfn,
>> + int offset, int len, u32 val);
>> +
>> static inline struct pci_controller *pci_bus_to_host(const struct =
pci_bus
>> *bus) {
>> return bus->sysdata;
>> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
>> index 41bbcc4..9c0fcc9 100644
>> --- a/arch/powerpc/sysdev/fsl_pci.c
>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>> @@ -54,12 +54,22 @@ static void quirk_fsl_pcie_header(struct pci_dev =
*dev)
>> return;
>> }
>>=20
>> -static int __init fsl_pcie_check_link(struct pci_controller *hose)
>> +static int fsl_indirect_read_config(struct pci_bus *, unsigned int,
>> + int, int, u32 *);
>> +
>> +static int fsl_pcie_check_link(struct pci_controller *hose)
>> {
>> - u32 val;
>> + u32 val =3D 0;
>>=20
>> if (hose->indirect_type & PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
>> - early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
>> + if (hose->ops->read =3D=3D fsl_indirect_read_config) {
>> + struct pci_bus bus;
>> + bus.number =3D 0;
>> + bus.sysdata =3D hose;
>> + bus.ops =3D hose->ops;
>> + indirect_read_config(&bus, 0, PCIE_LTSSM, 4, =
&val);
>> + } else
>> + early_read_config_dword(hose, 0, 0, PCIE_LTSSM, =
&val);
>> if (val < PCIE_LTSSM_L0)
>> return 1;
>> } else {
>> @@ -74,6 +84,33 @@ static int __init fsl_pcie_check_link(struct
>> pci_controller *hose) return 0;
>> }
>>=20
>> +static int fsl_indirect_read_config(struct pci_bus *bus, unsigned =
int
>> devfn, + int offset, int len, u32 =
*val)
>> +{
>> + struct pci_controller *hose =3D pci_bus_to_host(bus);
>> +
>> + if (fsl_pcie_check_link(hose))
>> + hose->indirect_type |=3D PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>> + else
>> + hose->indirect_type &=3D =
~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>> +
>> + return indirect_read_config(bus, devfn, offset, len, val);
>> +}
>> +
>> +static struct pci_ops fsl_indirect_pci_ops =3D
>> +{
>> + .read =3D fsl_indirect_read_config,
>> + .write =3D indirect_write_config,
>> +};
>> +
>> +static void __init fsl_setup_indirect_pci(struct pci_controller* =
hose,
>> + resource_size_t cfg_addr,
>> + resource_size_t cfg_data, u32 =
flags)
>> +{
>> + setup_indirect_pci(hose, cfg_addr, cfg_data, flags);
>> + hose->ops =3D &fsl_indirect_pci_ops;
>> +}
>> +
>> #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
>>=20
>> #define MAX_PHYS_ADDR_BITS 40
>> @@ -469,8 +506,8 @@ int __init fsl_add_bridge(struct platform_device =
*pdev,
>> int is_primary) if (!hose->private_data)
>> goto no_bridge;
>>=20
>> - setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
>> - PPC_INDIRECT_TYPE_BIG_ENDIAN);
>> + fsl_setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
>> + PPC_INDIRECT_TYPE_BIG_ENDIAN);
>>=20
>> if (in_be32(&pci->block_rev1) < PCIE_IP_REV_3_0)
>> hose->indirect_type |=3D =
PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK;
>> @@ -779,8 +816,8 @@ int __init mpc83xx_add_bridge(struct device_node =
*dev)
>> if (ret)
>> goto err0;
>> } else {
>> - setup_indirect_pci(hose, rsrc_cfg.start,
>> - rsrc_cfg.start + 4, 0);
>> + fsl_setup_indirect_pci(hose, rsrc_cfg.start,
>> + rsrc_cfg.start + 4, 0);
>> }
>>=20
>> printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
>> diff --git a/arch/powerpc/sysdev/indirect_pci.c
>> b/arch/powerpc/sysdev/indirect_pci.c index 82fdad8..c6c8b52 100644
>> --- a/arch/powerpc/sysdev/indirect_pci.c
>> +++ b/arch/powerpc/sysdev/indirect_pci.c
>> @@ -20,9 +20,8 @@
>> #include <asm/pci-bridge.h>
>> #include <asm/machdep.h>
>>=20
>> -static int
>> -indirect_read_config(struct pci_bus *bus, unsigned int devfn, int =
offset,
>> - int len, u32 *val)
>> +int indirect_read_config(struct pci_bus *bus, unsigned int devfn,
>> + int offset, int len, u32 *val)
>> {
>> struct pci_controller *hose =3D pci_bus_to_host(bus);
>> volatile void __iomem *cfg_data;
>> @@ -78,9 +77,8 @@ indirect_read_config(struct pci_bus *bus, unsigned =
int
>> devfn, int offset, return PCIBIOS_SUCCESSFUL;
>> }
>>=20
>> -static int
>> -indirect_write_config(struct pci_bus *bus, unsigned int devfn, int =
offset,
>> - int len, u32 val)
>> +int indirect_write_config(struct pci_bus *bus, unsigned int devfn,
>> + int offset, int len, u32 val)
>> {
>> struct pci_controller *hose =3D pci_bus_to_host(bus);
>> volatile void __iomem *cfg_data;
>>=20
>>=20
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2 6/11] Update CPU Maps
From: Nathan Fontenot @ 2013-04-05 18:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130404044240.GG19443@drongo>
On 04/03/2013 11:42 PM, Paul Mackerras wrote:
> On Mon, Mar 25, 2013 at 01:57:08PM -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> Platform events such as partition migration or the new PRRN firmware
>> feature can cause the NUMA characteristics of a CPU to change, and these
>> changes will be reflected in the device tree nodes for the affected
>> CPUs.
>>
>> This patch registers a handler for Open Firmware device tree updates
>> and reconfigures the CPU and node maps whenever the associativity
>> changes. Currently, this is accomplished by marking the affected CPUs in
>> the cpu_associativity_changes_mask and allowing
>> arch_update_cpu_topology() to retrieve the new associativity information
>> using hcall_vphn().
>>
>> Protecting the NUMA cpu maps from concurrent access during an update
>> operation will be addressed in a subsequent patch in this series.
>>
>> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
>
> [snip]
>
>> + if (firmware_has_feature(OV5_PRRN)) {
>
> Shouldn't this be FW_FEATURE_PRRN? How well has this patch been
> tested? :-/
Yes this should have been FW_FEATURE_PRRN.
I know I tested this and it took some digging to find out why my test succeeded
even though I used the wrong value in the call to firmware_has_feature. The value
for OV5_PRRN (0x0540) just happens to match some of he bits that are set in
powerpc_firmware_features bit field and cause the check to return true. My test
worked out of sheer luck. I'll update this patch and re-test to ensure it works
with the real value.
This does make me think, should we update firmware_has_feature() to avoid this
kind of false positive in the future. something like
#define firmware_has_feature(feature) \
((FW_FEATURE_ALWAYS & (feature)) == (feature) || \
(FW_FEATURE_POSSIBLE & powerpc_firmware_features & (feature)) == (feature)
-Nathan
^ permalink raw reply
* Re: [PATCH v2 7/11] Use stop machine to update cpu maps
From: Nathan Fontenot @ 2013-04-05 18:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130404044654.GH19443@drongo>
On 04/03/2013 11:46 PM, Paul Mackerras wrote:
> On Mon, Mar 25, 2013 at 01:58:04PM -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> The new PRRN firmware feature allows CPU and memory resources to be
>> transparently reassigned across NUMA boundaries. When this happens, the
>> kernel must update the node maps to reflect the new affinity
>> information.
>>
>> Although the NUMA maps can be protected by locking primitives during the
>> update itself, this is insufficient to prevent concurrent accesses to these
>> structures. Since cpumask_of_node() hands out a pointer to these
>> structures, they can still be modified outside of the lock. Furthermore,
>> tracking down each usage of these pointers and adding locks would be quite
>> invasive and difficult to maintain.
>>
>> Situations like these are best handled using stop_machine(). Since the NUMA
>> affinity updates are exceptionally rare events, this approach has the
>> benefit of not adding any overhead while accessing the NUMA maps during
>> normal operation.
>
> I notice you do one stop_machine() call for every cpu whose affinity
> has changed. Couldn't we update the affinity for them all in one
> stop_machine call? Given that stopping the whole machine can be quite
> slow, wouldn't it be better to do one call rather than potentially
> many?
>
Agreed, having to call stop_machine() for each cpu that gets updated is
pretty brutal. The plus side is that PRRN events should a rare occurrence
and not cause too much pain.
The current design ties into the of notification chain so that we can do
the affinity update when the affinity property in the device tree is updated.
Switching to doing one stop and updating all of the cpus would require a
design change....and....
I went back and looked at the code again and there is another issue with
way this is done. Tying into the of notification chain is great for
being informed of when a property changes but the code (from patch 6/11)
+ case OF_RECONFIG_ADD_PROPERTY:
+ case OF_RECONFIG_UPDATE_PROPERTY:
+ update = (struct of_prop_reconfig *)data;
+ if (!of_prop_cmp(update->dn->type, "cpu")) {
+ u32 core_id;
+ of_property_read_u32(update->dn, "reg", &core_id);
+ stage_topology_update(core_id);
+ rc = NOTIFY_OK;
+ }
+ break;
Does not check to see which property is being updated and just assumes
the affinity is being updated. This code as is will do an affinity update
every time any property of a cpu is updated or added.
Since this needs an update I will also look at possibly doing this so
that we call stop_machine only once.
--
-Nathan
^ permalink raw reply
* Re: [PATCH] [RFC] powerpc: Add VDSO version of time
From: Adhemerval Zanella @ 2013-04-05 18:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20130405062137.GA5082@concordia>
On 04/05/2013 03:21 AM, Michael Ellerman wrote:
> On Tue, Mar 19, 2013 at 04:55:31PM -0300, Adhemerval Zanella wrote:
>> Hi all,
>>
>> This patch implement the time syscall as vDSO. I have a glibc patch
>> to use it as IFUNC (as latest gettimeofday patch). Below the perf
>> numbers:
>>
>> Baseline PPC32: 380 nsec
>> Baseline PPC64: 352 nsec
>> vdso PPC32: 20 nsec
>> vdso PPC64: 20 nsec
>>
>> I focused on 64 bit kernel, do I need to provide a scheme for 32 bits
>> as well?
> You did provide a 32-bit implementation. I take it you haven't tested
> that though? Can you test it?
I haven't test it yet and I believe it won't be troublesome to do so.
>
> What happens if I don't have the glibc patch?
GLIBC current behavior is to use the syscall.
>
> cheers
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Enable boot_vga sysfs attribute for graphics adapters on Power
From: Bjorn Helgaas @ 2013-04-05 20:11 UTC (permalink / raw)
To: Brian King
Cc: linux-pci@vger.kernel.org, klebers, Lucas Kannebley Tavares,
sparclinux, linuxppc-dev
In-Reply-To: <201304042158.r34LwEOV010607@d03av02.boulder.ibm.com>
On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
>
> Initialize dev->dev.type such that the PCI group attributes for boot_vga
> and SR-IOV can be displayed if appropriate. This fixes an issue seen on
> Power preventing X from auto initializing a graphics adapter when using KMS.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> arch/powerpc/kernel/pci_of_scan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -puN arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type arch/powerpc/kernel/pci_of_scan.c
> --- linux/arch/powerpc/kernel/pci_of_scan.c~powerpc_set_pci_dev_type 2013-04-03 09:43:19.000000000 -0500
> +++ linux-bjking1/arch/powerpc/kernel/pci_of_scan.c 2013-04-03 09:43:19.000000000 -0500
> @@ -141,6 +141,7 @@ struct pci_dev *of_create_pci_dev(struct
> dev->dev.of_node = of_node_get(node);
> dev->dev.parent = bus->bridge;
> dev->dev.bus = &pci_bus_type;
> + dev->dev.type = &pci_dev_type;
> dev->devfn = devfn;
> dev->multifunction = 0; /* maybe a lie? */
> dev->needs_freset = 0; /* pcie fundamental reset required */
I think sparc has the same issue in its own copy of of_create_pci_dev().
Of course, both of_create_pci_dev() implementations are basically
copies of the generic pci_setup_device() that most arches use. That's
the reason why I wish sparc and powerpc had used config space
accessors that hid the OF mangling internally so they could use the
generic pci_setup_device() instead of cloning it.
Of course, they don't, and that's too much work for fixing this issue,
but if anybody wanted to work on that, I think it would be an
interesting project.
But what if you set dev->dev.type in alloc_pci_dev()? I think if you
did that, you wouldn't need to export "pci_dev_type," and it should
fix this for both powerpc and sparc.
Bjorn
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Set default VGA device
From: Bjorn Helgaas @ 2013-04-05 20:24 UTC (permalink / raw)
To: Brian King
Cc: linux-pci@vger.kernel.org, klebers, Lucas Kannebley Tavares,
sparclinux, linuxppc-dev
In-Reply-To: <201304042158.r34LwGPg010714@d03av02.boulder.ibm.com>
On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
>
> Add a PCI quirk for VGA devices on Power to set the default VGA device.
> Ensures a default VGA is always set if a graphics adapter is present,
> even if firmware did not initialize it. If more than one graphics
> adapter is present, ensure the one initialized by firmware is set
> as the default VGA device. This ensures that X autoconfiguration
> will work.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> arch/powerpc/kernel/pci-common.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff -puN arch/powerpc/kernel/pci-common.c~powerpc_vga_default_device arch/powerpc/kernel/pci-common.c
> --- linux/arch/powerpc/kernel/pci-common.c~powerpc_vga_default_device 2013-04-03 09:50:33.000000000 -0500
> +++ linux-bjking1/arch/powerpc/kernel/pci-common.c 2013-04-03 09:50:33.000000000 -0500
> @@ -30,6 +30,7 @@
> #include <linux/irq.h>
> #include <linux/vmalloc.h>
> #include <linux/slab.h>
> +#include <linux/vgaarb.h>
>
> #include <asm/processor.h>
> #include <asm/io.h>
> @@ -1725,3 +1726,15 @@ static void fixup_hide_host_resource_fsl
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_hide_host_resource_fsl);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, fixup_hide_host_resource_fsl);
> +
> +static void fixup_vga(struct pci_dev *pdev)
> +{
> + u16 cmd;
> +
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if ((cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) || !vga_default_device())
> + vga_set_default_device(pdev);
> +
> +}
> +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
> + PCI_CLASS_DISPLAY_VGA, 8, fixup_vga);
This not really an arch-specific issue, so it's a shame to add another
arch-specific quirk for it (in addition to the x86 and ia64 ones we
already have).
In b5e4efe7e0, Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> tried to
make this quirk generic, but the implementation was naive and it
didn't work for sparc64. There's a good thread about the sparc issue
at https://lkml.org/lkml/2006/10/19/17
The outcome was to basically revert back to arch-specific quirks with
6b5c76b8e2, but I think the generic version probably could have been
made to work, possibly with a pcibios hook or something for anything
that really is arch-dependent, like the shadowed ROM image.
This particular patch is arch-specific, and I'm not going to try to
nack it because I'm not the powerpc maintainer, but I will certainly
try to help you if you want to push on making a generic version.
Bjorn
^ permalink raw reply
* [PATCH] powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test
From: Michael Wolf @ 2013-04-05 20:41 UTC (permalink / raw)
To: linuxppc-dev
Some versions pHyp will perform the adjunct partition test before the
ANDCOND test. The result of this is that H_RESOURCE can be returned and
cause the BUG_ON condition to occur. The HPTE is not removed. So add a
check for H_RESOURCE, it is ok if this HPTE is not removed as
pSeries_lpar_hpte_remove is looking for an HPTE to remove and not a
specific HPTE to remove. So it is ok to just move on to the next slot
and try again.
Signed-off-by: Michael Wolf <mjw@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index c9a29da..724fa0b 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -185,7 +185,13 @@ static long pSeries_lpar_hpte_remove(unsigned long hpte_group)
(0x1UL << 4), &dummy1, &dummy2);
if (lpar_rc == H_SUCCESS)
return i;
- BUG_ON(lpar_rc != H_NOT_FOUND);
+
+ /*
+ * The test for adjunct partition is performed before the
+ * ANDCOND test. H_RESOURCE may be returned, so we need to
+ * check for that as well.
+ */
+ BUG_ON(lpar_rc != H_NOT_FOUND && lpar_rc != H_RESOURCE);
slot_offset++;
slot_offset &= 0x7;
^ permalink raw reply related
* Re: [PATCH 2/3] powerpc: Enable boot_vga sysfs attribute for graphics adapters on Power
From: Benjamin Herrenschmidt @ 2013-04-06 8:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci@vger.kernel.org, klebers, sparclinux,
Lucas Kannebley Tavares, Brian King, linuxppc-dev
In-Reply-To: <CAErSpo5ReUcSPvyBs_u0HLh=90anEREZn4p6EUX4yO52bDBaeg@mail.gmail.com>
On Fri, 2013-04-05 at 14:11 -0600, Bjorn Helgaas wrote:
>
> I think sparc has the same issue in its own copy of
> of_create_pci_dev().
>
> Of course, both of_create_pci_dev() implementations are basically
> copies of the generic pci_setup_device() that most arches use. That's
> the reason why I wish sparc and powerpc had used config space
> accessors that hid the OF mangling internally so they could use the
> generic pci_setup_device() instead of cloning it.
I disagree :-) I want the config space accessors to actually do the
config space access (it might be necessary for some reasons, if anything
for diagnostic). Also one of the reasons we create devices that way
originally iirc, is that on older pre-PCIe setups, we could have cases
of a bridge showing up at function N > 0 without anything at function
0.
We are also not allowed to mess with bridge BARs on old EADS bridges,
and similar issues where the hypervisor can get upset.
A "filtering" config space code would be a lot messier than just
creating them like we do.
However we could/should probably make the code more common between
powerpc and sparc and maybe move the bulk of it to a generic place more
easily grepped by the PCI folks.
> Of course, they don't, and that's too much work for fixing this issue,
> but if anybody wanted to work on that, I think it would be an
> interesting project.
>
> But what if you set dev->dev.type in alloc_pci_dev()? I think if you
> did that, you wouldn't need to export "pci_dev_type," and it should
> fix this for both powerpc and sparc.
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.9-rc5
From: Geert Uytterhoeven @ 2013-04-06 11:26 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Linux/PPC Development
In-Reply-To: <alpine.DEB.2.00.1304061323250.9581@ayla.of.borg>
On Sat, 6 Apr 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.9-rc5 to v3.9-rc4[3], the summaries are:
> - build errors: +129/-0
> Note that there may be false regressions, as some logs are incomplete.
> Still, they're build errors/warnings.
I think the only real one (in powerpc-randconfig) is:
+ arch/powerpc/kernel/tm.S: Error: unsupported relocation against THREAD_VR0: => 323
+ arch/powerpc/kernel/tm.S: Error: unsupported relocation against THREAD_VSCR: => 320
> [1] http://kisskb.ellerman.id.au/kisskb/head/6041/ (118 out of 117 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6015/ (80 out of 117 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4, part3 31/41] mm/ppc: prepare for removing num_physpages and simplify mem_init()
From: Jiang Liu @ 2013-04-06 14:32 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, James Bottomley, David Howells, Jiang Liu,
Wen Congyang, linux-mm, Mark Salter, linux-kernel, Michal Hocko,
Minchan Kim, Paul Mackerras, Mel Gorman, David Rientjes,
linuxppc-dev, Sergei Shtylyov, KAMEZAWA Hiroyuki, Jianguo Wu
In-Reply-To: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
Prepare for removing num_physpages and simplify mem_init().
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/powerpc/mm/mem.c | 56 +++++++++++--------------------------------------
1 file changed, 12 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 8ddef0a..07663de 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -300,46 +300,27 @@ void __init paging_init(void)
void __init mem_init(void)
{
-#ifdef CONFIG_NEED_MULTIPLE_NODES
- int nid;
-#endif
- pg_data_t *pgdat;
- unsigned long i;
- struct page *page;
- unsigned long reservedpages = 0, codesize, initsize, datasize, bsssize;
-
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
- num_physpages = memblock_phys_mem_size() >> PAGE_SHIFT;
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
#ifdef CONFIG_NEED_MULTIPLE_NODES
- for_each_online_node(nid) {
- if (NODE_DATA(nid)->node_spanned_pages != 0) {
- printk("freeing bootmem node %d\n", nid);
- free_all_bootmem_node(NODE_DATA(nid));
- }
+ {
+ pg_data_t *pgdat;
+
+ for_each_online_pgdat(pgdat)
+ if (pgdat->node_spanned_pages != 0) {
+ printk("freeing bootmem node %d\n",
+ pgdat->node_id);
+ free_all_bootmem_node(pgdat);
+ }
}
#else
max_mapnr = max_pfn;
free_all_bootmem();
#endif
- for_each_online_pgdat(pgdat) {
- for (i = 0; i < pgdat->node_spanned_pages; i++) {
- if (!pfn_valid(pgdat->node_start_pfn + i))
- continue;
- page = pgdat_page_nr(pgdat, i);
- if (PageReserved(page))
- reservedpages++;
- }
- }
-
- codesize = (unsigned long)&_sdata - (unsigned long)&_stext;
- datasize = (unsigned long)&_edata - (unsigned long)&_sdata;
- initsize = (unsigned long)&__init_end - (unsigned long)&__init_begin;
- bsssize = (unsigned long)&__bss_stop - (unsigned long)&__bss_start;
#ifdef CONFIG_HIGHMEM
{
@@ -349,13 +330,9 @@ void __init mem_init(void)
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT;
struct page *page = pfn_to_page(pfn);
- if (memblock_is_reserved(paddr))
- continue;
- free_highmem_page(page);
- reservedpages--;
+ if (!memblock_is_reserved(paddr))
+ free_highmem_page(page);
}
- printk(KERN_DEBUG "High memory: %luk\n",
- totalhigh_pages << (PAGE_SHIFT-10));
}
#endif /* CONFIG_HIGHMEM */
@@ -368,16 +345,7 @@ void __init mem_init(void)
(mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) - 1;
#endif
- printk(KERN_INFO "Memory: %luk/%luk available (%luk kernel code, "
- "%luk reserved, %luk data, %luk bss, %luk init)\n",
- nr_free_pages() << (PAGE_SHIFT-10),
- num_physpages << (PAGE_SHIFT-10),
- codesize >> 10,
- reservedpages << (PAGE_SHIFT-10),
- datasize >> 10,
- bsssize >> 10,
- initsize >> 10);
-
+ mem_init_print_info(NULL);
#ifdef CONFIG_PPC32
pr_info("Kernel virtual memory layout:\n");
pr_info(" * 0x%08lx..0x%08lx : fixmap\n", FIXADDR_START, FIXADDR_TOP);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] powerpc: Enable boot_vga sysfs attribute for graphics adapters on Power
From: Bjorn Helgaas @ 2013-04-06 16:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci@vger.kernel.org, klebers, sparclinux,
Lucas Kannebley Tavares, Brian King, linuxppc-dev
In-Reply-To: <1365235201.31207.9.camel@pasglop>
On Sat, Apr 6, 2013 at 2:00 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-04-05 at 14:11 -0600, Bjorn Helgaas wrote:
>>
>> I think sparc has the same issue in its own copy of
>> of_create_pci_dev().
>>
>> Of course, both of_create_pci_dev() implementations are basically
>> copies of the generic pci_setup_device() that most arches use. That's
>> the reason why I wish sparc and powerpc had used config space
>> accessors that hid the OF mangling internally so they could use the
>> generic pci_setup_device() instead of cloning it.
>
> I disagree :-) I want the config space accessors to actually do the
> config space access (it might be necessary for some reasons, if anything
> for diagnostic). Also one of the reasons we create devices that way
> originally iirc, is that on older pre-PCIe setups, we could have cases
> of a bridge showing up at function N > 0 without anything at function
> 0.
>
> We are also not allowed to mess with bridge BARs on old EADS bridges,
> and similar issues where the hypervisor can get upset.
>
> A "filtering" config space code would be a lot messier than just
> creating them like we do.
Yeah, maybe so. I guess it's just hard for me to let go of ideas
until I've tried myself and failed :)
Anyway, I hope putting a little more into alloc_pci_dev() will resolve
this particular issue.
Bjorn
^ permalink raw reply
* [PATCH] perf: Power7: Make CPI stack events available in sysfs
From: Sukadev Bhattiprolu @ 2013-04-06 16:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, linux-kernel,
Arnaldo Carvalho de Melo
>From bdeacf7175241f6c79b5b2be0fa6b20b0d0b7d1c Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Sat, 6 Apr 2013 08:48:26 -0700
Subject: [PATCH] perf: Power7: Make CPI stack events available in sysfs
A set of Power7 events are often used for Cycles Per Instruction (CPI) stack
analysis. Make these events available in sysfs (/sys/devices/cpu/events/) so
they can be identified using their symbolic names:
perf stat -e 'cpu/PM_CMPLU_STALL_DCACHE_MISS/' /bin/ls
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/perf/power7-pmu.c | 73 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 3c475d6..13c3f0e 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -62,6 +62,29 @@
#define PME_PM_BRU_FIN 0x10068
#define PME_PM_BRU_MPRED 0x400f6
+#define PME_PM_CMPLU_STALL_FXU 0x20014
+#define PME_PM_CMPLU_STALL_DIV 0x40014
+#define PME_PM_CMPLU_STALL_SCALAR 0x40012
+#define PME_PM_CMPLU_STALL_SCALAR_LONG 0x20018
+#define PME_PM_CMPLU_STALL_VECTOR 0x2001c
+#define PME_PM_CMPLU_STALL_VECTOR_LONG 0x4004a
+#define PME_PM_CMPLU_STALL_LSU 0x20012
+#define PME_PM_CMPLU_STALL_REJECT 0x40016
+#define PME_PM_CMPLU_STALL_ERAT_MISS 0x40018
+#define PME_PM_CMPLU_STALL_DCACHE_MISS 0x20016
+#define PME_PM_CMPLU_STALL_STORE 0x2004a
+#define PME_PM_CMPLU_STALL_THRD 0x1001c
+#define PME_PM_CMPLU_STALL_IFU 0x4004c
+#define PME_PM_CMPLU_STALL_BRU 0x4004e
+#define PME_PM_GCT_NOSLOT_IC_MISS 0x2001a
+#define PME_PM_GCT_NOSLOT_BR_MPRED 0x4001a
+#define PME_PM_GCT_NOSLOT_BR_MPRED_IC_MISS 0x4001c
+#define PME_PM_GRP_CMPL 0x30004
+#define PME_PM_1PLUS_PPC_CMPL 0x100f2
+#define PME_PM_CMPLU_STALL_DFU 0x2003c
+#define PME_PM_RUN_CYC 0x200f4
+#define PME_PM_RUN_INST_CMPL 0x400fa
+
/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
@@ -393,6 +416,31 @@ POWER_EVENT_ATTR(LD_MISS_L1, LD_MISS_L1);
POWER_EVENT_ATTR(BRU_FIN, BRU_FIN)
POWER_EVENT_ATTR(BRU_MPRED, BRU_MPRED);
+POWER_EVENT_ATTR(CMPLU_STALL_FXU, CMPLU_STALL_FXU);
+POWER_EVENT_ATTR(CMPLU_STALL_DIV, CMPLU_STALL_DIV);
+POWER_EVENT_ATTR(CMPLU_STALL_SCALAR, CMPLU_STALL_SCALAR);
+POWER_EVENT_ATTR(CMPLU_STALL_SCALAR_LONG, CMPLU_STALL_SCALAR_LONG);
+POWER_EVENT_ATTR(CMPLU_STALL_VECTOR, CMPLU_STALL_VECTOR);
+POWER_EVENT_ATTR(CMPLU_STALL_VECTOR_LONG, CMPLU_STALL_VECTOR_LONG);
+POWER_EVENT_ATTR(CMPLU_STALL_LSU, CMPLU_STALL_LSU);
+POWER_EVENT_ATTR(CMPLU_STALL_REJECT, CMPLU_STALL_REJECT);
+
+POWER_EVENT_ATTR(CMPLU_STALL_ERAT_MISS, CMPLU_STALL_ERAT_MISS);
+POWER_EVENT_ATTR(CMPLU_STALL_DCACHE_MISS, CMPLU_STALL_DCACHE_MISS);
+POWER_EVENT_ATTR(CMPLU_STALL_STORE, CMPLU_STALL_STORE);
+POWER_EVENT_ATTR(CMPLU_STALL_THRD, CMPLU_STALL_THRD);
+POWER_EVENT_ATTR(CMPLU_STALL_IFU, CMPLU_STALL_IFU);
+POWER_EVENT_ATTR(CMPLU_STALL_BRU, CMPLU_STALL_BRU);
+POWER_EVENT_ATTR(GCT_NOSLOT_IC_MISS, GCT_NOSLOT_IC_MISS);
+
+POWER_EVENT_ATTR(GCT_NOSLOT_BR_MPRED, GCT_NOSLOT_BR_MPRED);
+POWER_EVENT_ATTR(GCT_NOSLOT_BR_MPRED_IC_MISS, GCT_NOSLOT_BR_MPRED_IC_MISS);
+POWER_EVENT_ATTR(GRP_CMPL, GRP_CMPL);
+POWER_EVENT_ATTR(1PLUS_PPC_CMPL, 1PLUS_PPC_CMPL);
+POWER_EVENT_ATTR(CMPLU_STALL_DFU, CMPLU_STALL_DFU);
+POWER_EVENT_ATTR(RUN_CYC, RUN_CYC);
+POWER_EVENT_ATTR(RUN_INST_CMPL, RUN_INST_CMPL);
+
static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(CYC),
GENERIC_EVENT_PTR(GCT_NOSLOT_CYC),
@@ -411,6 +459,31 @@ static struct attribute *power7_events_attr[] = {
POWER_EVENT_PTR(LD_MISS_L1),
POWER_EVENT_PTR(BRU_FIN),
POWER_EVENT_PTR(BRU_MPRED),
+
+ POWER_EVENT_PTR(CMPLU_STALL_FXU),
+ POWER_EVENT_PTR(CMPLU_STALL_DIV),
+ POWER_EVENT_PTR(CMPLU_STALL_SCALAR),
+ POWER_EVENT_PTR(CMPLU_STALL_SCALAR_LONG),
+ POWER_EVENT_PTR(CMPLU_STALL_VECTOR),
+ POWER_EVENT_PTR(CMPLU_STALL_VECTOR_LONG),
+ POWER_EVENT_PTR(CMPLU_STALL_LSU),
+ POWER_EVENT_PTR(CMPLU_STALL_REJECT),
+
+ POWER_EVENT_PTR(CMPLU_STALL_ERAT_MISS),
+ POWER_EVENT_PTR(CMPLU_STALL_DCACHE_MISS),
+ POWER_EVENT_PTR(CMPLU_STALL_STORE),
+ POWER_EVENT_PTR(CMPLU_STALL_THRD),
+ POWER_EVENT_PTR(CMPLU_STALL_IFU),
+ POWER_EVENT_PTR(CMPLU_STALL_BRU),
+ POWER_EVENT_PTR(GCT_NOSLOT_IC_MISS),
+ POWER_EVENT_PTR(GCT_NOSLOT_BR_MPRED),
+
+ POWER_EVENT_PTR(GCT_NOSLOT_BR_MPRED_IC_MISS),
+ POWER_EVENT_PTR(GRP_CMPL),
+ POWER_EVENT_PTR(1PLUS_PPC_CMPL),
+ POWER_EVENT_PTR(CMPLU_STALL_DFU),
+ POWER_EVENT_PTR(RUN_CYC),
+ POWER_EVENT_PTR(RUN_INST_CMPL),
NULL
};
--
1.7.1
^ permalink raw reply related
* [PATCH] perf: Power7 Update testing ABI to list CPI-stack events
From: Sukadev Bhattiprolu @ 2013-04-06 17:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20130406164803.GA408@us.ibm.com>
>From 03a785f9d19249d2e524f31d8ead539f15d28a9f Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Sat, 6 Apr 2013 09:52:05 -0700
Subject: [PATCH] perf: Power7 Update testing ABI to list CPI-stack events
Following patch added several Power7 events into /sys/devices/cpu/events.
Document those events in the testing ABI.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/105167.html
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
.../testing/sysfs-bus-event_source-devices-events | 32 ++++++++++++++++---
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 0adeb52..8b25ffb 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -27,14 +27,36 @@ Description: Generic performance monitoring events
"basename".
-What: /sys/devices/cpu/events/PM_LD_MISS_L1
- /sys/devices/cpu/events/PM_LD_REF_L1
- /sys/devices/cpu/events/PM_CYC
+What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
- /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_BRU_MPRED
- /sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_CMPLU_STALL
+ /sys/devices/cpu/events/PM_CMPLU_STALL_BRU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DFU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DIV
+ /sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
+ /sys/devices/cpu/events/PM_CMPLU_STALL_FXU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_IFU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_LSU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
+ /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
+ /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
+ /sys/devices/cpu/events/PM_CMPLU_STALL_STORE
+ /sys/devices/cpu/events/PM_CMPLU_STALL_THRD
+ /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
+ /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
+ /sys/devices/cpu/events/PM_CYC
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
+ /sys/devices/cpu/events/PM_GRP_CMPL
+ /sys/devices/cpu/events/PM_INST_CMPL
+ /sys/devices/cpu/events/PM_LD_MISS_L1
+ /sys/devices/cpu/events/PM_LD_REF_L1
+ /sys/devices/cpu/events/PM_RUN_CYC
+ /sys/devices/cpu/events/PM_RUN_INST_CMPL
Date: 2013/01/08
--
1.7.1
^ 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