* Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Benjamin Herrenschmidt @ 2013-04-25 17:35 UTC (permalink / raw)
To: Rob Herring
Cc: Roland Dreier, Arnd Bergmann, linux-rdma, netdev,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Raisch, Hoang-Nam Nguyen, Thadeu Lima de Souza Cascardo,
Grant Likely, Paul Mackerras, Sean Hefty, linuxppc-dev,
Hal Rosenstock
In-Reply-To: <CAL_JsqKDF=hPEM0Jz-zZSXBCXBZ=gBjLWL6QDvq+nFWkqY3DMw@mail.gmail.com>
On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
> Ben, Can I have your Ack for this? The change is straightforward and
> neither of the 2 drivers used the id parameter that is removed.
Didn't you get my mail about a compile failure caused by this patch ?
Or did you send an update that I missed ?
(Copy of the original email below)
Cheers,
Ben.
----
On Sun, 2013-04-21 at 21:13 -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> ibmebus is the last remaining user of of_platform_driver and the
> conversion to a regular platform driver is trivial.
A quick build test leads to:
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_probe':
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: implicit declaration of function 'to_platform_driver' [-Werror=implicit-function-declaration]
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: assignment makes pointer from integer without a cast [-Werror]
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_remove':
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: initialization makes pointer from integer without a cast [-Werror]
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_shutdown':
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: initialization makes pointer from integer without a cast [-Werror]
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_suspend':
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: initialization makes pointer from integer without a cast [-Werror]
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_resume':
/home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: initialization makes pointer from integer without a cast [-Werror]
cc1: all warnings being treated as errors
make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Haven't had a chance to look too closely today -EJETLAG :-)
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/perf: Add support for SIER
From: Sukadev Bhattiprolu @ 2013-04-25 18:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1365582765-6939-4-git-send-email-michael@ellerman.id.au>
Michael Ellerman [michael@ellerman.id.au] wrote:
| From: Michael Ellerman <michaele@au1.ibm.com>
|
| On power8 we have a new SIER (Sampled Instruction Event Register), which
| captures information about instructions when we have random sampling
| enabled.
|
| Add support for loading the SIER into pt_regs, overloading regs->dar.
| Also set the new NO_SIPR flag in regs->result if we don't have SIPR.
|
| Update regs_sihv/sipr() to look for SIPR/SIHV in SIER.
|
| Signed-off-by: Michael Ellerman <michaele@au1.ibm.com>
| ---
| arch/powerpc/include/asm/perf_event_server.h | 1 +
| arch/powerpc/perf/core-book3s.c | 19 +++++++++++++++++++
| 2 files changed, 20 insertions(+)
|
| diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
| index e287aef..a1a1ad8 100644
| --- a/arch/powerpc/include/asm/perf_event_server.h
| +++ b/arch/powerpc/include/asm/perf_event_server.h
| @@ -53,6 +53,7 @@ struct power_pmu {
| #define PPMU_NO_CONT_SAMPLING 0x00000008 /* no continuous sampling */
| #define PPMU_SIAR_VALID 0x00000010 /* Processor has SIAR Valid bit */
| #define PPMU_HAS_SSLOT 0x00000020 /* Has sampled slot in MMCRA */
| +#define PPMU_HAS_SIER 0x00000040 /* Has SIER */
|
| /*
| * Values for flags to get_alternatives()
| diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
| index 4255b12..a4bbd4d 100644
| --- a/arch/powerpc/perf/core-book3s.c
| +++ b/arch/powerpc/perf/core-book3s.c
| @@ -116,6 +116,9 @@ static bool regs_sihv(struct pt_regs *regs)
| {
| unsigned long sihv = MMCRA_SIHV;
|
| + if (ppmu->flags & PPMU_HAS_SIER)
| + return !!(regs->dar & SIER_SIHV);
| +
Were SIER_SIHV and SIER_SIPR defined in an earlier patch set ?
| if (ppmu->flags & PPMU_ALT_SIPR)
| sihv = POWER6_MMCRA_SIHV;
|
| @@ -126,6 +129,9 @@ static bool regs_sipr(struct pt_regs *regs)
| {
| unsigned long sipr = MMCRA_SIPR;
|
| + if (ppmu->flags & PPMU_HAS_SIER)
| + return !!(regs->dar & SIER_SIPR);
| +
| if (ppmu->flags & PPMU_ALT_SIPR)
| sipr = POWER6_MMCRA_SIPR;
|
| @@ -184,6 +190,7 @@ static inline u32 perf_get_misc_flags(struct pt_regs *regs)
| /*
| * Overload regs->dsisr to store MMCRA so we only need to read it once
| * on each interrupt.
| + * Overload regs->dar to store SIER if we have it.
| * Overload regs->result to specify whether we should use the MSR (result
| * is zero) or the SIAR (result is non zero).
| */
| @@ -200,6 +207,18 @@ static inline void perf_read_regs(struct pt_regs *regs)
| regs->result |= 2;
|
| /*
| + * On power8 if we're in random sampling mode, the SIER is updated.
| + * If we're in continuous sampling mode, we don't have SIPR.
| + */
| + if (ppmu->flags & PPMU_HAS_SIER) {
| + if (marked)
| + regs->dar = mfspr(SPRN_SIER);
| + else
| + regs->result |= 2;
Can we use a helper, regs_set_no_sipr() to set this - since we set and
test in more than one place ?
Other than these nits, the patchset looks good.
Sukadev
^ permalink raw reply
* Re: [RFC PATCH 1/3] powerpc: Move struct pci_controller to asm-generic
From: Bjorn Helgaas @ 2013-04-25 19:08 UTC (permalink / raw)
To: Andrew Murray
Cc: Michal Simek, Arnd Bergmann, linux-pci@vger.kernel.org,
microblaze-uclinux, linux-kernel@vger.kernel.org, linuxppc-dev
In-Reply-To: <1366883360-14061-2-git-send-email-Andrew.Murray@arm.com>
On Thu, Apr 25, 2013 at 3:49 AM, Andrew Murray <Andrew.Murray@arm.com> wrote:
> This patch moves struct pci_controller into asm-generic to allow
> for use by other architectures thus reducing code duplication in
> the kernel.
>
> Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> ---
> arch/powerpc/include/asm/pci-bridge.h | 87 +++++---------------------------
> include/asm-generic/pci-bridge.h | 68 +++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 73 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> index 205bfba..163bd40 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -8,7 +8,6 @@
> * 2 of the License, or (at your option) any later version.
> */
> #include <linux/pci.h>
> -#include <linux/list.h>
> #include <linux/ioport.h>
> #include <linux/of_pci.h>
> #include <asm-generic/pci-bridge.h>
> @@ -16,85 +15,27 @@
> struct device_node;
>
> /*
> - * Structure of a PCI controller (host bridge)
> + * Used for variants of PCI indirect handling and possible quirks:
> + * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> + * EXT_REG - provides access to PCI-e extended registers
> + * SURPRESS_PRIMARY_BUS - we suppress the setting of PCI_PRIMARY_BUS
s/SURPRESS/SUPRESS/ throughout.
I'm not sure how generic these flags will end up being. If they wind
up in a shared header file, it seems like we might want a PCI_ prefix
to anchor them.
> + * on Freescale PCI-e controllers since they used the PCI_PRIMARY_BUS
> + * to determine which bus number to match on when generating type0
> + * config cycles
> + * NO_PCIE_LINK - the Freescale PCI-e controllers have issues with
> + * hanging if we don't have link and try to do config cycles to
> + * anything but the PHB. Only allow talking to the PHB if this is
> + * set.
> + * BIG_ENDIAN - cfg_addr is a big endian register
> + * BROKEN_MRM - the 440EPx/GRx chips have an errata that causes hangs on
> + * the PLB4. Effectively disable MRM commands by setting this.
> */
> -struct pci_controller {
> - struct pci_bus *bus;
> - char is_dynamic;
> -#ifdef CONFIG_PPC64
> - int node;
> -#endif
> - struct device_node *dn;
> - struct list_head list_node;
> - struct device *parent;
> -
> - int first_busno;
> - int last_busno;
> - int self_busno;
> - struct resource busn;
> -
> - void __iomem *io_base_virt;
> -#ifdef CONFIG_PPC64
> - void *io_base_alloc;
> -#endif
> - resource_size_t io_base_phys;
> - resource_size_t pci_io_size;
> -
> - /* Some machines (PReP) have a non 1:1 mapping of
> - * the PCI memory space in the CPU bus space
> - */
> - resource_size_t pci_mem_offset;
> -
> - /* Some machines have a special region to forward the ISA
> - * "memory" cycles such as VGA memory regions. Left to 0
> - * if unsupported
> - */
> - resource_size_t isa_mem_phys;
> - resource_size_t isa_mem_size;
> -
> - struct pci_ops *ops;
> - unsigned int __iomem *cfg_addr;
> - void __iomem *cfg_data;
> -
> - /*
> - * Used for variants of PCI indirect handling and possible quirks:
> - * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> - * EXT_REG - provides access to PCI-e extended registers
> - * SURPRESS_PRIMARY_BUS - we suppress the setting of PCI_PRIMARY_BUS
> - * on Freescale PCI-e controllers since they used the PCI_PRIMARY_BUS
> - * to determine which bus number to match on when generating type0
> - * config cycles
> - * NO_PCIE_LINK - the Freescale PCI-e controllers have issues with
> - * hanging if we don't have link and try to do config cycles to
> - * anything but the PHB. Only allow talking to the PHB if this is
> - * set.
> - * BIG_ENDIAN - cfg_addr is a big endian register
> - * BROKEN_MRM - the 440EPx/GRx chips have an errata that causes hangs on
> - * the PLB4. Effectively disable MRM commands by setting this.
> - */
> #define PPC_INDIRECT_TYPE_SET_CFG_TYPE 0x00000001
> #define PPC_INDIRECT_TYPE_EXT_REG 0x00000002
> #define PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS 0x00000004
> #define PPC_INDIRECT_TYPE_NO_PCIE_LINK 0x00000008
> #define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
> #define PPC_INDIRECT_TYPE_BROKEN_MRM 0x00000020
> - u32 indirect_type;
> - /* Currently, we limit ourselves to 1 IO range and 3 mem
> - * ranges since the common pci_bus structure can't handle more
> - */
> - struct resource io_resource;
> - struct resource mem_resources[3];
> - int global_number; /* PCI domain number */
> -
> - resource_size_t dma_window_base_cur;
> - resource_size_t dma_window_size;
> -
> -#ifdef CONFIG_PPC64
> - unsigned long buid;
> -
> - void *private_data;
> -#endif /* CONFIG_PPC64 */
> -};
>
> /* These are used for config access before all the PCI probing
> has been done. */
> diff --git a/include/asm-generic/pci-bridge.h b/include/asm-generic/pci-bridge.h
> index 20db2e5..e58830e 100644
> --- a/include/asm-generic/pci-bridge.h
> +++ b/include/asm-generic/pci-bridge.h
> @@ -9,6 +9,9 @@
>
> #ifdef __KERNEL__
>
> +#include <linux/pci.h>
> +#include <linux/list.h>
> +
> enum {
> /* Force re-assigning all resources (ignore firmware
> * setup completely)
> @@ -38,6 +41,71 @@ enum {
> PCI_SCAN_ALL_PCIE_DEVS = 0x00000040,
> };
>
> +struct device_node;
> +
> +/*
> + * Structure of a PCI controller (host bridge)
> + */
> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64)
> +struct pci_controller {
> + struct pci_bus *bus;
A lot of the information here (struct pci_bus *bus, first_/last_busno,
busn, window information) is already in the struct pci_host_bridge,
and I'm not sure it makes sense to duplicate it here. I'd like to use
that structure when it makes sense, and use the sysdata pointer, i.e.,
the pointer to "struct pci_controller" here, for things that are truly
arch-specific.
> + char is_dynamic;
> +#ifdef CONFIG_PPC64
> + int node;
> +#endif
> + struct device_node *dn;
> + struct list_head list_node;
> + struct device *parent;
> +
> + int first_busno;
> + int last_busno;
> + int self_busno;
> +#if defined(CONFIG_PPC64) || defined(CONFIG_PPC32)
> + struct resource busn;
> +#endif
> +
> + void __iomem *io_base_virt;
> +#ifdef CONFIG_PPC64
> + void *io_base_alloc;
> +#endif
> + resource_size_t io_base_phys;
> + resource_size_t pci_io_size;
> +
> + /* Some machines (PReP) have a non 1:1 mapping of
> + * the PCI memory space in the CPU bus space
> + */
> + resource_size_t pci_mem_offset;
> +
> + /* Some machines have a special region to forward the ISA
> + * "memory" cycles such as VGA memory regions. Left to 0
> + * if unsupported
> + */
> + resource_size_t isa_mem_phys;
> + resource_size_t isa_mem_size;
> +
> + struct pci_ops *ops;
> + unsigned int __iomem *cfg_addr;
> + void __iomem *cfg_data;
> +
> + u32 indirect_type;
> + /* Currently, we limit ourselves to 1 IO range and 3 mem
> + * ranges since the common pci_bus structure can't handle more
> + */
> + struct resource io_resource;
> + struct resource mem_resources[3];
pci_host_bridge has a list for apertures, which contains this
information (and the offset between CPU and PCI bus addresses).
> + int global_number; /* PCI domain number */
The domain is a good candidate for going in the pci_host_bridge
structure. I'm not sure how to plumb it in there, but it is something
that's pretty generic and I'd like to get rid of all the arch-specific
pci_domain_nr() implementations that are really the same.
> +
> + resource_size_t dma_window_base_cur;
> + resource_size_t dma_window_size;
> +
> +#ifdef CONFIG_PPC64
> + unsigned long buid;
> +
> + void *private_data;
> +#endif /* CONFIG_PPC64 */
> +};
> +#endif
> +
> #ifdef CONFIG_PCI
> extern unsigned int pci_flags;
>
> --
> 1.7.0.4
>
^ permalink raw reply
* Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Rob Herring @ 2013-04-25 19:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Roland Dreier, Arnd Bergmann, linux-rdma, netdev,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Raisch, Hoang-Nam Nguyen, Thadeu Lima de Souza Cascardo,
Grant Likely, Paul Mackerras, Sean Hefty, linuxppc-dev,
Hal Rosenstock
In-Reply-To: <1366911329.2869.31.camel@pasglop>
On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
>> Ben, Can I have your Ack for this? The change is straightforward and
>> neither of the 2 drivers used the id parameter that is removed.
>
> Didn't you get my mail about a compile failure caused by this patch ?
No, and I can't find any evidence of a mail in my inbox or in the list
archives.
>
> A quick build test leads to:
>
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_probe':
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: implicit declaration of function 'to_platform_driver' [-Werror=implicit-function-declaration]
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: assignment makes pointer from integer without a cast [-Werror]
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_remove':
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: initialization makes pointer from integer without a cast [-Werror]
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_shutdown':
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: initialization makes pointer from integer without a cast [-Werror]
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_suspend':
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: initialization makes pointer from integer without a cast [-Werror]
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_resume':
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: initialization makes pointer from integer without a cast [-Werror]
> cc1: all warnings being treated as errors
> make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
>
> Haven't had a chance to look too closely today -EJETLAG :-)
You need patch 2 of this series to fix this:
driver core: move to_platform_driver to platform_device.h
which as Arnd pointed out needs to come first. I've fixed that in my
tree, but I don't think it warrants another post.
Rob
^ permalink raw reply
* Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Benjamin Herrenschmidt @ 2013-04-25 20:12 UTC (permalink / raw)
To: Rob Herring
Cc: Roland Dreier, Arnd Bergmann, linux-rdma, netdev,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Raisch, Hoang-Nam Nguyen, Thadeu Lima de Souza Cascardo,
Grant Likely, Paul Mackerras, Sean Hefty, linuxppc-dev,
Hal Rosenstock
In-Reply-To: <517980B0.3000401@gmail.com>
On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote:
> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
> >> Ben, Can I have your Ack for this? The change is straightforward and
> >> neither of the 2 drivers used the id parameter that is removed.
> >
> > Didn't you get my mail about a compile failure caused by this patch ?
>
> No, and I can't find any evidence of a mail in my inbox or in the list
> archives.
Odd...
> >
.../...
> You need patch 2 of this series to fix this:
>
> driver core: move to_platform_driver to platform_device.h
>
> which as Arnd pointed out needs to come first. I've fixed that in my
> tree, but I don't think it warrants another post.
Can I pull you tree from somewhere to test ?
Cheers,
Ben.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Rob Herring @ 2013-04-25 20:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Roland Dreier, Arnd Bergmann, linux-rdma, netdev,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Raisch, Hoang-Nam Nguyen, Thadeu Lima de Souza Cascardo,
Grant Likely, Paul Mackerras, Sean Hefty, linuxppc-dev,
Hal Rosenstock
In-Reply-To: <1366920741.2869.32.camel@pasglop>
On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote:
>> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote:
[...]
>> You need patch 2 of this series to fix this:
>>
>> driver core: move to_platform_driver to platform_device.h
>>
>> which as Arnd pointed out needs to come first. I've fixed that in my
>> tree, but I don't think it warrants another post.
>
> Can I pull you tree from somewhere to test ?
Here you go:
git://sources.calxeda.com/kernel/linux.git of-platform-removal
Rob
^ permalink raw reply
* RE: [PATCH 1/3] rapidio: make enumeration/discovery configurable
From: Bounine, Alexandre @ 2013-04-25 21:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org, Micha Nelissen,
linux-kernel@vger.kernel.org, Andre van Herk
In-Reply-To: <20130424143714.4911405aa979bff27887765a@linux-foundation.org>
On Wednesday, April 24, 2013 5:37 PM Andrew Morton wrote:
>=20
> On Wed, 24 Apr 2013 10:31:57 -0400 Alexandre Bounine
> <alexandre.bounine@idt.com> wrote:
>=20
> > Rework to implement RapidIO enumeration/discovery method selection
> > combined with ability to use enumeration/discovery as a kernel module.
> >
> > ...
> >
> > @@ -1421,3 +1295,46 @@ enum_done:
> > bail:
> > return -EBUSY;
> > }
> > +
> > +struct rio_scan rio_scan_ops =3D {
> > + .enumerate =3D rio_enum_mport,
> > + .discover =3D rio_disc_mport,
> > +};
> > +
> > +
> > +#ifdef MODULE
>=20
> Why the `ifdef MODULE'? The module parameters are still accessible if
> the driver is statically linked and we do want the driver to behave in
> the same way regardless of how it was linked and loaded.
Marked for review.
> > +static bool scan;
> > +module_param(scan, bool, 0);
> > +MODULE_PARM_DESC(scan, "Start RapidIO network enumeration/discovery
> "
> > + "(default =3D 1)");
> > +
> > +/**
> > + * rio_basic_attach:
> > + *
> > + * When this enumeration/discovery method is loaded as a module this f=
unction
> > + * registers its specific enumeration and discover routines for all av=
ailable
> > + * RapidIO mport devices. The "scan" command line parameter controls a=
bility of
> > + * the module to start RapidIO enumeration/discovery automatically.
> > + *
> > + * Returns 0 for success or -EIO if unable to register itself.
> > + *
> > + * This enumeration/discovery method cannot be unloaded and therefore =
does not
> > + * provide a matching cleanup_module routine.
> > + */
> > +
> > +int __init rio_basic_attach(void)
>=20
> static
My miss. Will fix.
> > +{
> > + if (rio_register_scan(RIO_MPORT_ANY, &rio_scan_ops))
> > + return -EIO;
> > + if (scan)
> > + rio_init_mports();
> > + return 0;
> > +}
> > +
> > +module_init(rio_basic_attach);
> > +
> > +MODULE_DESCRIPTION("Basic RapidIO enumeration/discovery");
> > +MODULE_LICENSE("GPL");
> > +
> > +#endif /* MODULE */
> > diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
> > index d553b5d..e36628a 100644
> > --- a/drivers/rapidio/rio.c
> > +++ b/drivers/rapidio/rio.c
> > @@ -31,6 +31,9 @@
> >
> > #include "rio.h"
> >
> > +LIST_HEAD(rio_devices);
>=20
> static?
>=20
> > +DEFINE_SPINLOCK(rio_global_list_lock);
>=20
> static?
These two have been very tempting for me to make them static.
But because a goal was simple code move and they have been visible
from very beginning of RapidIO code, I decided to keep the scope "as is".
While I am against using the device list directly, I am not sure that this
patch is a good place to change the existing scope.
Because keeping them global prompted your comment I will happily make them
static and see if anyone will complain about it.
=20
> > +
> > static LIST_HEAD(rio_mports);
> > static unsigned char next_portid;
> > static DEFINE_SPINLOCK(rio_mmap_lock);
> >
> > ...
> >
> > +/**
> > + * rio_switch_init - Sets switch operations for a particular vendor sw=
itch
> > + * @rdev: RIO device
> > + * @do_enum: Enumeration/Discovery mode flag
> > + *
> > + * Searches the RIO switch ops table for known switch types. If the vi=
d
> > + * and did match a switch table entry, then call switch initialization
> > + * routine to setup switch-specific routines.
> > + */
> > +void rio_switch_init(struct rio_dev *rdev, int do_enum)
> > +{
> > + struct rio_switch_ops *cur =3D __start_rio_switch_ops;
> > + struct rio_switch_ops *end =3D __end_rio_switch_ops;
>=20
> huh, I hadn't noticed that RIO has its very own vmlinux section. How
> peculair.
Yes it is there (since 2.6.15). We will address it at some point later.
At this moment just moving the code from one file to another.
=20
> > + while (cur < end) {
> > + if ((cur->vid =3D=3D rdev->vid) && (cur->did =3D=3D rdev->did)) {
> > + pr_debug("RIO: calling init routine for %s\n",
> > + rio_name(rdev));
> > + cur->init_hook(rdev, do_enum);
> > + break;
> > + }
> > + cur++;
> > + }
> > +
> > + if ((cur >=3D end) && (rdev->pef & RIO_PEF_STD_RT)) {
> > + pr_debug("RIO: adding STD routing ops for %s\n",
> > + rio_name(rdev));
> > + rdev->rswitch->add_entry =3D rio_std_route_add_entry;
> > + rdev->rswitch->get_entry =3D rio_std_route_get_entry;
> > + rdev->rswitch->clr_table =3D rio_std_route_clr_table;
> > + }
> > +
> > + if (!rdev->rswitch->add_entry || !rdev->rswitch->get_entry)
> > + printk(KERN_ERR "RIO: missing routing ops for %s\n",
> > + rio_name(rdev));
> > +}
> > +EXPORT_SYMBOL_GPL(rio_switch_init);
> >
> > ...
> >
> > +int rio_register_scan(int mport_id, struct rio_scan *scan_ops)
> > +{
> > + struct rio_mport *port;
> > + int rc =3D -EBUSY;
> > +
> > + list_for_each_entry(port, &rio_mports, node) {
>=20
> How come the driver has no locking for rio_mports? If a bugfix isn't
> needed here then a code comment is!
Locking is not needed at this moment, but has to be added sooner or later a=
nyway.
I will add it now to avoid fixing it later.=20
=20
> > + if (port->id =3D=3D mport_id || mport_id =3D=3D RIO_MPORT_ANY) {
> > + if (port->nscan && mport_id =3D=3D RIO_MPORT_ANY)
> > + continue;
> > + else if (port->nscan)
> > + break;
> > +
> > + port->nscan =3D scan_ops;
> > + rc =3D 0;
> > +
> > + if (mport_id !=3D RIO_MPORT_ANY)
> > + break;
> > + }
> > + }
> > +
> > + return rc;
> > +}
> >
> > ...
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Michael Neuling @ 2013-04-25 23:16 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <517918AB.4020508@asianux.com>
Chen Gang <gang.chen@asianux.com> wrote:
>
> When CONFIG_KVM_BOOK3S_64_PR is enabled,
> MASKABLE_EXCEPTION_PSERIES(0x900 ...) will includes __KVMTEST, it will
> exceed 0x980 which STD_EXCEPTION_HV(0x980 ...) will use, it will cause
> compiling issue.
>
> The related errors:
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> The position 0x900 and 0x980 are solid, so can not move the position
> to make room larger. The final solution is to jump to another area to
> execute the related code.
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..8997de2 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,11 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + b decrementer_pSeries_0
> +
Unfortunately you can't do this ether as we need to save the CFAR[1]
before it's overwritten by any branch. MASKABLE_EXCEPTION_PSERIES does
this.
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by any branch.
Thanks for trying.
Mikey
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +540,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer,
> + EXC_STD, SOFTEN_TEST_PR)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
> --
> 1.7.7.6
>
>
^ permalink raw reply
* why does CONFIG_NONSTATIC_KERNEL affect the boot kernel?
From: Chris Friesen @ 2013-04-25 23:33 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackerras
Hi,
Looking at the kdump code for powerpc, I see that if
CONFIG_NONSTATIC_KERNEL is not set then the load address for the capture
kernel is fixed at 32MB.
Why is this?
When using a separate capture kernel I don't see why that should
restrict where I allocate space in the boot kernel.
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com
^ permalink raw reply
* Re: [PATCH v2 12/15] powerpc/85xx: add time base sync support for e6500
From: Scott Wood @ 2013-04-26 0:07 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel, r58472
In-Reply-To: <20130425002818.GE3172@localhost.localdomain>
On 04/24/2013 07:28:18 PM, Zhao Chenhui wrote:
> On Wed, Apr 24, 2013 at 05:38:16PM -0500, Scott Wood wrote:
> > On 04/24/2013 06:29:29 AM, Zhao Chenhui wrote:
> > >On Tue, Apr 23, 2013 at 07:04:06PM -0500, Scott Wood wrote:
> > >> On 04/19/2013 05:47:45 AM, Zhao Chenhui wrote:
> > >> >From: Chen-Hui Zhao <chenhui.zhao@freescale.com>
> > >> >
> > >> >For e6500, two threads in one core share one time base. Just =20
> need
> > >> >to do time base sync on first thread of one core, and skip it on
> > >> >the other thread.
> > >> >
> > >> >Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > >> >Signed-off-by: Li Yang <leoli@freescale.com>
> > >> >Signed-off-by: Andy Fleming <afleming@freescale.com>
> > >> >---
> > >> > arch/powerpc/platforms/85xx/smp.c | 52
> > >> >+++++++++++++++++++++++++++++++-----
> > >> > 1 files changed, 44 insertions(+), 8 deletions(-)
> > >> >
> > >> >diff --git a/arch/powerpc/platforms/85xx/smp.c
> > >> >b/arch/powerpc/platforms/85xx/smp.c
> > >> >index 74d8cde..5f3eee3 100644
> > >> >--- a/arch/powerpc/platforms/85xx/smp.c
> > >> >+++ b/arch/powerpc/platforms/85xx/smp.c
> > >> >@@ -53,26 +55,40 @@ static inline u32 get_phy_cpu_mask(void)
> > >> > u32 mask;
> > >> > int cpu;
> > >> >
> > >> >- mask =3D 1 << cur_booting_core;
> > >> >- for_each_online_cpu(cpu)
> > >> >- mask |=3D 1 << get_hard_smp_processor_id(cpu);
> > >> >+ if (smt_capable()) {
> > >> >+ /* two threads in one core share one time base =20
> */
> > >> >+ mask =3D 1 << =20
> cpu_core_index_of_thread(cur_booting_core);
> > >> >+ for_each_online_cpu(cpu)
> > >> >+ mask |=3D 1 << cpu_core_index_of_thread(
> > >> >+ =20
> get_hard_smp_processor_id(cpu));
> > >> >+ } else {
> > >> >+ mask =3D 1 << cur_booting_core;
> > >> >+ for_each_online_cpu(cpu)
> > >> >+ mask |=3D 1 << =20
> get_hard_smp_processor_id(cpu);
> > >> >+ }
> > >>
> > >> Where is smt_capable defined()? I assume somewhere in the =20
> patchset
> > >> but it's a pain to search 12 patches...
> > >>
> > >
> > >It is defined in arch/powerpc/include/asm/topology.h.
> > > #define smt_capable() (cpu_has_feature(CPU_FTR_SMT))
> > >
> > >Thanks for your review again.
> >
> > We shouldn't base it on CPU_FTR_SMT. For example, e6500 doesn't
> > claim that feature yet, except in our SDK kernel. That doesn't
> > change the topology of CPU numbering.
> >
>=20
> Then, where can I get the thread information? dts?
> Or, wait for upstream of the thread suppport of e6500.
It's an inherent property of e6500 (outside of some virtualization =20
scenarios, but you wouldn't run this code under a hypervisor) that you =20
have two threads per core (whether Linux uses them or not). Or you =20
could read TMCFG0[NTHRD] if you know you're on a chip that has TMRs but =20
aren't positive it's an e6500, but I wouldn't bother. If we do ever =20
have such a chip, there are probably other things that will need =20
updating.
> > >static inline u32 get_phy_cpu_mask(void)
> > >{
> > > u32 mask;
> > > int cpu;
> > >
> > > mask =3D 1 << cpu_core_index_of_thread(cur_booting_core);
> > > for_each_online_cpu(cpu)
> > > mask |=3D 1 << cpu_core_index_of_thread(
> > > get_hard_smp_processor_id(cpu));
> > >
> > > return mask;
> > >}
> >
> > Likewise, this will get it wrong if SMT is disabled or not yet
> > implemented on a core.
> >
> > -Scott
>=20
> Let's look into cpu_core_index_of_thread() in =20
> arch/powerpc/kernel/smp.c.
>=20
> int cpu_core_index_of_thread(int cpu)
> {
> return cpu >> threads_shift;
> }
>=20
> If no thread, the threads_shift is equal to 0. It can work with no
> thread.
My point is that if threads are disabled, threads_shift will be 0, but =20
e6500 cores will still be numbered 0, 2, 4, etc.
> Perhaps, I should submit this patch after the thread patches for =20
> e6500.
Why?
-Scott=
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:06 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <30269.1366931768@ale.ozlabs.ibm.com>
On 2013年04月26日 07:16, Michael Neuling wrote:
>> > diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> > index e789ee7..8997de2 100644
>> > --- a/arch/powerpc/kernel/exceptions-64s.S
>> > +++ b/arch/powerpc/kernel/exceptions-64s.S
>> > @@ -254,7 +254,11 @@ hardware_interrupt_hv:
>> > STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
>> > KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>> >
>> > - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
>> > + . = 0x900
>> > + .globl decrementer_pSeries
>> > +decrementer_pSeries:
>> > + b decrementer_pSeries_0
>> > +
> Unfortunately you can't do this ether as we need to save the CFAR[1]
> before it's overwritten by any branch. MASKABLE_EXCEPTION_PSERIES does
> this.
>
Thanks for your checking.
> CFAR is the Come From Register. It saves the location of the last
> branch and is hence overwritten by any branch.
>
Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
. = 0x900
.globl decrementer_pSeries
decrementer_pSeries:
HMT_MEDIUM_PPR_DISCARD
SET_SCRATCH0(r13)
b decrementer_pSeries_0
...
> Thanks for trying.
>
Not at all, before get fixed by other members, I should continue trying.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:18 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <5179D302.9060203@asianux.com>
On 2013年04月26日 09:06, Chen Gang wrote:
>> CFAR is the Come From Register. It saves the location of the last
>> > branch and is hence overwritten by any branch.
>> >
> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
> . = 0x900
> .globl decrementer_pSeries
> decrementer_pSeries:
> HMT_MEDIUM_PPR_DISCARD
> SET_SCRATCH0(r13)
> b decrementer_pSeries_0
>
> ...
>
>
Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
Please check, thanks.
---------------------------diff begin-------------------------------------
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..a0a5ff2 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -254,7 +254,14 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ b decrementer_pSeries_0
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
@@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
#endif
.align 7
+ /* moved from 0x900 */
+decrementer_pSeries_0:
+ EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
+ EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
+
+ .align 7
/* moved from 0xe00 */
STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
---------------------------diff end---------------------------------------
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* [PATCH] powerpc: Fix hardware IRQs with MMU on exceptions when HV=0
From: Michael Neuling @ 2013-04-26 1:30 UTC (permalink / raw)
To: benh; +Cc: Linux PPC dev, Nishanth Aravamudan
POWER8 allows us to take interrupts with the MMU on. This gives us a
second set of vectors offset at 0x4000.
Unfortunately when coping these vectors we missed checking for MSR HV
for hardware interrupts (0x500). This results in us trying to use
HSRR0/1 when HV=0, rather than SRR0/1 on HW IRQs
The below fixes this to check CPU_FTR_HVMODE when patching the code at
0x4500.
Also we remove the check for CPU_FTR_ARCH_206 since relocation on IRQs
are only available in arch 2.07 and beyond.
Thanks to benh for helping find this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: stable@kernel.org
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 56bd923..3bbe7ed 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -797,7 +797,7 @@ hardware_interrupt_relon_hv:
_MASKABLE_RELON_EXCEPTION_PSERIES(0x502, hardware_interrupt, EXC_HV, SOFTEN_TEST_HV)
FTR_SECTION_ELSE
_MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt, EXC_STD, SOFTEN_TEST_PR)
- ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_206)
+ ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
STD_RELON_EXCEPTION_PSERIES(0x4600, 0x600, alignment)
STD_RELON_EXCEPTION_PSERIES(0x4700, 0x700, program_check)
STD_RELON_EXCEPTION_PSERIES(0x4800, 0x800, fp_unavailable)
^ permalink raw reply related
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:36 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <5179D5D8.8080102@asianux.com>
On 2013年04月26日 09:18, Chen Gang wrote:
> On 2013年04月26日 09:06, Chen Gang wrote:
>>> CFAR is the Come From Register. It saves the location of the last
>>>> branch and is hence overwritten by any branch.
>>>>
>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>> . = 0x900
>> .globl decrementer_pSeries
>> decrementer_pSeries:
>> HMT_MEDIUM_PPR_DISCARD
>> SET_SCRATCH0(r13)
>> b decrementer_pSeries_0
>>
>> ...
>>
>>
Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
---------------------------------diff v2 begin-----------------------------
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..f0489c4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -254,7 +254,15 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
+ b decrementer_pSeries_0
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
@@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
#endif
.align 7
+ /* moved from 0x900 */
+decrementer_pSeries_0:
+ EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
+
+ .align 7
/* moved from 0xe00 */
STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
---------------------------------diff v2 end-------------------------------
>
> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>
> Please check, thanks.
>
> ---------------------------diff begin-------------------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..a0a5ff2 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
> ---------------------------diff end---------------------------------------
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* Re: [PATCH 1/1] kvm:book3e: Fix a build error
From: tiejun.chen @ 2013-04-26 1:53 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3D9C33@039-SN2MPN1-013.039d.mgd.msft.net>
On 04/25/2013 08:11 PM, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>> owner@vger.kernel.org] On Behalf Of Tiejun Chen
>> Sent: Thursday, April 25, 2013 2:46 PM
>> To: galak@kernel.crashing.org
>> Cc: linuxppc-dev@lists.ozlabs.org; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: [PATCH 1/1] kvm:book3e: Fix a build error
>>
>> Commit cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", adds
>> support for AltiVec on a Book-E class processor, but while compiling
>> in the CONFIG_PPC_BOOK3E_64 and CONFIG_VIRTUALIZATION case, this
>> introduce the following error:
>>
>> arch/powerpc/kernel/exceptions-64e.S:402: undefined reference to
>> `kvmppc_handler_42_0x01B'
>> arch/powerpc/kernel/built-in.o: In function `exc_altivec_assist_book3e':
>> arch/powerpc/kernel/exceptions-64e.S:424: undefined reference to
>> `kvmppc_handler_43_0x01B'
>> make: *** [vmlinux] Error 1
>>
>> Looks we should add these altivec kvm handlers.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>> ---
>> arch/powerpc/kvm/bookehv_interrupts.S | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
>> b/arch/powerpc/kvm/bookehv_interrupts.S
>> index e8ed7d6..fa9c78a 100644
>> --- a/arch/powerpc/kvm/bookehv_interrupts.S
>> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
>> @@ -319,6 +319,11 @@ kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(DBG), \
>> SPRN_DSRR0, SPRN_DSRR1, 0
>> kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(CRIT), \
>> SPRN_CSRR0, SPRN_CSRR1, 0
>> +/* altivec */
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_UNAVAIL, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_ASSIST, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> #else
>> /*
>> * For input register values, see
>> arch/powerpc/include/asm/kvm_booke_hv_asm.h
>> --
>
> It seems that you are not using kvm-ppc-queue branch.
This is just used to fix a build error in powerpc.git when introduce commit
cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", in *powerpc.git* as I
mentioned in this patch head.
>
> I already have a patch ready for this (and AltiVec support is work
This change don't block your AltiVec support for kvm unless you think this
change is wrong. And especially, we always can reproduce this error with/without
enabling AltiVec, so I also don't think this should be suspended until support
e6500 in kvm since kvm based on e5500 should work.
Tiejun
> in progress) but we need first to pull e6500 kernel patches from
> Linux tree into agraf.git.
>
> -Mike
>
>
>
>
>
>
>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 1:58 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <51791076.9040405@asianux.com>
于 2013/4/25 19:16, Chen Gang 写道:
> On 2013年04月25日 14:25, Paul Mackerras wrote:
>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>> This has block my work now
>>>> So I hope you can take a look ASAP
>>>> Thanks
>>>> :)
>>>>
>>>> Mike
>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>> the immediate problem.
> Yes, just as my original reply to Mike to bypass it, but get no reply, I
> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>
> Now, I am just fixing it, when I finish one patch, please help check.
Actually, I have compile pass by your patch, but I see Micheal Neuling's
reply,
I just stop to do that, and wait for you new patch :)
Now I will use your V2 patch to build
Thanks
Mike
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 2:03 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DA23.8000407@asianux.com>
于 2013/4/26 9:36, Chen Gang 写道:
> On 2013年04月26日 09:18, Chen Gang wrote:
>> On 2013年04月26日 09:06, Chen Gang wrote:
>>>> CFAR is the Come From Register. It saves the location of the last
>>>>> branch and is hence overwritten by any branch.
>>>>>
>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>> . = 0x900
>>> .globl decrementer_pSeries
>>> decrementer_pSeries:
>>> HMT_MEDIUM_PPR_DISCARD
>>> SET_SCRATCH0(r13)
>>> b decrementer_pSeries_0
>>>
>>> ...
>>>
>>>
> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
I will try your diff V2, to see if the machine can boot up
> ---------------------------------diff v2 begin-----------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..f0489c4 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,15 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
>
> ---------------------------------diff v2 end-------------------------------
>
>
>> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>>
>> Please check, thanks.
>>
>> ---------------------------diff begin-------------------------------------
>>
>> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> index e789ee7..a0a5ff2 100644
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
>> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
>> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>>
>> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
>> + . = 0x900
>> + .globl decrementer_pSeries
>> +decrementer_pSeries:
>> + HMT_MEDIUM_PPR_DISCARD
>> + SET_SCRATCH0(r13) /* save r13 */
>> + EXCEPTION_PROLOG_0(PACA_EXGEN)
>> + b decrementer_pSeries_0
>> +
>> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>>
>> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
>> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
>> #endif
>>
>> .align 7
>> + /* moved from 0x900 */
>> +decrementer_pSeries_0:
>> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
>> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
>> +
>> + .align 7
>> /* moved from 0xe00 */
>> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
>> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>>
>> ---------------------------diff end---------------------------------------
>>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Chen Gang @ 2013-04-26 2:05 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DF37.8020407@linux.vnet.ibm.com>
On 2013年04月26日 09:58, Mike Qiu wrote:
> 于 2013/4/25 19:16, Chen Gang 写道:
>> On 2013年04月25日 14:25, Paul Mackerras wrote:
>>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>>> This has block my work now
>>>>> So I hope you can take a look ASAP
>>>>> Thanks
>>>>> :)
>>>>>
>>>>> Mike
>>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>>> the immediate problem.
>> Yes, just as my original reply to Mike to bypass it, but get no reply, I
>> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>>
>> Now, I am just fixing it, when I finish one patch, please help check.
> Actually, I have compile pass by your patch, but I see Micheal Neuling's
> reply,
> I just stop to do that, and wait for you new patch :)
>
I am just continuing (before get fixed, I should continue)
> Now I will use your V2 patch to build
Please see the discussion of patch v2, it still has another issues, but
I am still trying (I guess Michael is just checking).
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 2:06 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E056.2000709@linux.vnet.ibm.com>
On 2013年04月26日 10:03, Mike Qiu wrote:
> �� 2013/4/26 9:36, Chen Gang �:
>> > On 2013��04��26�� 09:18, Chen Gang wrote:
>>> >> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>> >>>> CFAR is the Come From Register. It saves the location of the last
>>>>>> >>>>> branch and is hence overwritten by any branch.
>>>>>> >>>>>
>>>> >>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>> >>> . = 0x900
>>>> >>> .globl decrementer_pSeries
>>>> >>> decrementer_pSeries:
>>>> >>> HMT_MEDIUM_PPR_DISCARD
>>>> >>> SET_SCRATCH0(r13)
>>>> >>> b decrementer_pSeries_0
>>>> >>>
>>>> >>> ...
>>>> >>>
>>>> >>>
>> > Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>> > with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
> I will try your diff V2, to see if the machine can boot up
OK, thanks. (hope it can work)
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* RE: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
From: Jia Hongtao-B38951 @ 2013-04-26 2:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1366777161.2869.0.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogV2VkbmVz
ZGF5LCBBcHJpbCAyNCwgMjAxMyAxMjoxOSBQTQ0KPiBUbzogSmlhIEhvbmd0YW8tQjM4OTUxDQo+
IENjOiBNaWNoYWVsIEVsbGVybWFuOyBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIHBvd2VycGM6IE1vdmUg
b3Bjb2RlIGRlZmluaXRpb25zIGZyb20NCj4ga3ZtL2VtdWxhdGUuYyB0byBhc20vcHBjLW9wY29k
ZS5oDQo+IA0KPiBPbiBUdWUsIDIwMTMtMDQtMjMgYXQgMDY6MzYgKzAwMDAsIEppYSBIb25ndGFv
LUIzODk1MSB3cm90ZToNCj4gPiBUaGVzZSBkZWZpbml0aW9ucyBhcmUgZmlyc3RseSB1c2VkIGJ5
IEtWTSBkZWZpbmVkIGxpa2UgT1BfMzFfWE9QX1RSQVAuDQo+ID4gVHdvIHdheXMgdG8gZXh0cmFj
dCB0aGVzZSBkZWZpbml0aW9ucyBmb3IgcHVibGljIHVzZToNCj4gPg0KPiA+IDEuIExpa2UgdGhp
cyBwYXRjaCBkaWQuIEZvciBrZWVwaW5nIHRoZSBLVk0gY29kZSB0aGF0IHVzaW5nIHRoZXNlDQo+
ID4gICAgZGVmaW5pdGlvbnMgdW5jaGFuZ2VkIHdlIGRvIG5vdCB1cGRhdGUgdGhlbSB0byBtYXRj
aC4NCj4gPg0KPiA+IDIuIE1vdmUgdGhlc2UgZGVmaW5pdGlvbnMgdG8gYW5vdGhlciAuaCBmaWxl
IGxpa2UgbXkgbGFzdCBwYXRjaCBkaWQ6DQo+ID4gICAgaHR0cDovL3BhdGNod29yay5vemxhYnMu
b3JnL3BhdGNoLzIzNTY0Ni8NCj4gPiAgICBZb3UgY2FuIHNlZSB0aGUgY29tbWVudHMgdGhlcmUu
DQo+IA0KPiBUaGVyZSdzIGEgYmV0dGVyIHdheSAuLi4gYnV0IGl0J3MgbW9yZSB3b3JrLg0KPiAN
Cj4gQWxsIG9wY29kZXMgYXJlIGJhc2VkIG9uIGEgcHJpbWFyeSBvcGNvZGUgYW5kIGEgcG90ZW50
aWFsIHNlY29uZGFyeQ0KPiBvcGNvZGUuIFlvdSBjb3VsZC9zaG91bGQgcmV3b3JrIHBwYy1vcGNv
ZGVzLmggdG8gaW4gZmFjdCBkZWZpbmUgdGhlbQ0KPiBhbGwgdGhhdCB3YXkgYXMgd2VsbCwgd2hp
Y2ggd291bGQgInJlY29uY2lsZSIgdGhlIEtWTSB3YXkgYW5kIHRoZQ0KPiBleGlzdGluZyBzdHVm
Zi4NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiANCg0KQWdyZWUuIEJ1dCBJJ20gYWZyYWlkIHRv
IHNheSB0aGF0IEknbSB0b28gYnVzeSB0byBkbyB0aGlzICJtb3JlIHdvcmsiDQpyaWdodCBub3cu
IENvdWxkIHdlIGRlZmVyIHRoaXMgd29yayBmb3Igc29tZSB0aW1lPw0KDQpUaGFua3MuDQotIEhv
bmd0YW8NCg==
^ permalink raw reply
* Re: [PATCH v4 2/13] Correct buffer parsing in update_dt_node()
From: Stephen Rothwell @ 2013-04-26 3:01 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5177FF10.4000508@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:49:36 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> @@ -134,6 +134,7 @@
> char *prop_data;
> char *rtas_buf;
> int update_properties_token;
> + u32 vd;
>
> update_properties_token = rtas_token("ibm,update-properties");
> if (update_properties_token == RTAS_UNKNOWN_SERVICE)
> @@ -160,13 +161,24 @@
>
> prop_data = rtas_buf + sizeof(*upwa);
>
> - for (i = 0; i < upwa->nprops; i++) {
> + /* The first element of the buffer is the path of the node
> + * being updated in the form of a 8 byte string length
^^^^
"bit" ?
> + * followed by the string. Skip past this to get to the
> + * properties being updated.
> + */
> + vd = *prop_data++;
> + prop_data += vd;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/13] Use ARRAY_SIZE to iterate over firmware_features_table array
From: Stephen Rothwell @ 2013-04-26 3:08 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5178005C.1070204@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:55:08 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> When iterating over the entries in firmware_features_table we only need
> to go over the actual number of entries in the array instead of declaring
> it to be bigger and checking to make sure there is a valid entry in every
> slot.
>
> This patch removes the FIRMWARE_MAX_FEATURES #define and replaces the
> array looping with the use of ARRAY_SIZE().
>
Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> @@ -77,12 +77,10 @@
> pr_debug(" -> fw_feature_init()\n");
>
> for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) {
> - for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
> + for (i = 0; i < ARRAY_SIZE(firmware_features_table); i++) {
You should explicitly include linux/kernel.h to use ARRAY_SIZE().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 3:08 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E11F.8010007@asianux.com>
于 2013/4/26 10:06, Chen Gang 写道:
> On 2013年04月26日 10:03, Mike Qiu wrote:
>> �� 2013/4/26 9:36, Chen Gang �:
>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>> CFAR is the Come From Register. It saves the location of the last
>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>
>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>>>>>> . = 0x900
>>>>>>>> .globl decrementer_pSeries
>>>>>>>> decrementer_pSeries:
>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>> b decrementer_pSeries_0
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>> I will try your diff V2, to see if the machine can boot up
> OK, thanks. (hope it can work)
It seems that the machine can be bootup in powernv mode, but I'm not
sure if my machine call that module.
At lease my machine can boot up
Thanks
Mike
>
> :-)
>
^ permalink raw reply
* Re: [PATCH V4 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8
From: Michael Neuling @ 2013-04-26 3:11 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
Anshuman,
IIRC there are new bits in the FSCR and HFSCR you need to enable for the
PMU and BRHB. Can you please check these are enabled?
Mikey
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote:
> Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM
> POWER8 processor which records the branch instructions inside the execution
> pipeline. This patchset enables the basic functionality of the feature through
> generic perf branch stack sampling framework.
>
> Sample output
> -------------
> $./perf record -b top
> $./perf report
>
> Overhead Command Source Shared Object Source Symbol Target Shared Object Target Symbol
> # ........ ....... .................... ...................................... .................... ...................................
> #
>
> 7.82% top libc-2.11.2.so [k] _IO_vfscanf libc-2.11.2.so [k] _IO_vfscanf
> 6.17% top libc-2.11.2.so [k] _IO_vfscanf [unknown] [k] 00000000
> 2.37% top [unknown] [k] 0xf7aafb30 [unknown] [k] 00000000
> 1.80% top [unknown] [k] 0x0fe07978 libc-2.11.2.so [k] _IO_vfscanf
> 1.60% top libc-2.11.2.so [k] _IO_vfscanf [kernel.kallsyms] [k] .do_task_stat
> 1.20% top [kernel.kallsyms] [k] .do_task_stat [kernel.kallsyms] [k] .do_task_stat
> 1.02% top libc-2.11.2.so [k] vfprintf libc-2.11.2.so [k] vfprintf
> 0.92% top top [k] _init [unknown] [k] 0x0fe037f4
>
> Changes in V2
> --------------
> - Added copyright messages to the newly created files
> - Modified couple of commit messages
>
> Changes in V3
> -------------
> - Incorporated review comments from Segher https://lkml.org/lkml/2013/4/16/350
> - Worked on a solution for review comment from Michael Ellerman https://lkml.org/lkml/2013/4/17/548
> - Could not move updated cpu_hw_events structure from core-book3s.c file into perf_event_server.h
> Because perf_event_server.h is pulled in first inside linux/perf_event.h before the definition of
> perf_branch_entry structure. Thats the reason why perf_branch_entry definition is not available
> inside perf_event_server.h where we define the array inside cpu_hw_events structure.
>
> - Finally have pulled in the code from perf_event_bhrb.c into core-book3s.c
>
> - Improved documentation for the patchset
>
> Changes in V4
> -------------
> - Incorporated review comments on V3 regarding new instruction encoding
>
> Anshuman Khandual (5):
> powerpc, perf: Add new BHRB related instructions for POWER8
> powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
> powerpc, perf: Add new BHRB related generic functions, data and flags
> powerpc, perf: Define BHRB generic functions, data and flags for POWER8
> powerpc, perf: Enable branch stack sampling framework
>
> arch/powerpc/include/asm/perf_event_server.h | 7 ++
> arch/powerpc/include/asm/ppc-opcode.h | 8 ++
> arch/powerpc/perf/Makefile | 2 +-
> arch/powerpc/perf/bhrb.S | 44 +++++++
> arch/powerpc/perf/core-book3s.c | 167 ++++++++++++++++++++++++++-
> arch/powerpc/perf/power8-pmu.c | 57 ++++++++-
> 6 files changed, 280 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/perf/bhrb.S
>
> --
> 1.7.11.7
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 3:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: sfr, Michael Neuling, matt, Chen Gang, linux-kernel,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20130425062539.GA421@iris.ozlabs.ibm.com>
于 2013/4/25 14:25, Paul Mackerras 写道:
> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>> This has block my work now
>> So I hope you can take a look ASAP
>> Thanks
>> :)
>>
>> Mike
> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
> the immediate problem.
Thanks
got it, I will have a try.
> Paul.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox