* Re: [PATCH 2/3] powerpc: Enable boot_vga sysfs attribute for graphics adapters on Power
From: Michael Ellerman @ 2013-04-08 5:25 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, Apr 05, 2013 at 02:11:01PM -0600, Bjorn Helgaas wrote:
> 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.
That sounds good, Brian can you confirm that works and send a new series
using that technique.
cheers
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Set default VGA device
From: Michael Ellerman @ 2013-04-08 5:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci@vger.kernel.org, klebers, sparclinux,
Lucas Kannebley Tavares, Brian King, linuxppc-dev
In-Reply-To: <CAErSpo4LsJjRkw6UektwqW8m1NXdU6BTjhTDA9eORM3z3qDcdA@mail.gmail.com>
On Fri, Apr 05, 2013 at 02:24:09PM -0600, Bjorn Helgaas wrote:
> On Thu, Apr 4, 2013 at 3:58 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
> > @@ -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.
OK.
Looking at x86, ia64 and ours, there's a fair bit of difference.
x86/ia64 both walk up the parents checking PCI_BRIDGE_CTL_VGA, which
powerpc doesn't (though maybe it should?).
x86/ia64 set IORESOURCE_ROM_SHADOW, which powerpc doesn't.
ia64 doesn't call vga_set_default_device(), x86 and powerpc do.
So we'll merge this and maybe someone can tease out the common bits, but
personally I don't see that there's an obvious chunk of generic logic.
cheers
^ 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-08 4:48 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: Leekha Shaveta-B20052=20
Sent: Friday, April 05, 2013 9:13 PM
To: 'Kumar Gala'
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
-----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
[SL] Kumar, please suggest.=20
Regards,
Shaveta
^ permalink raw reply
* [PATCH V4] powerpc/MPIC: Add get_version API both for internal and external use
From: Jia Hongtao @ 2013-04-08 2:01 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: B07421, hongtao.jia
MPIC version is useful information for both mpic_alloc() and mpic_init().
The patch provide an API to get MPIC version for reusing the code.
Also, some other IP block may need MPIC version for their own use.
The API for external use is also provided.
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Changes for V4:
* change the name of function from mpic_get_version() to
fsl_mpic_get_version().
Changes for V3:
* change the name of function from mpic_primary_get_version() to
fsl_mpic_primary_get_version().
* return 0 if mpic_primary is null.
Changes for V2:
* Using mpic_get_version() to implement mpic_primary_get_version()
arch/powerpc/include/asm/mpic.h | 3 +++
arch/powerpc/sysdev/mpic.c | 29 ++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c0f9ef9..ea6bf72 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -393,6 +393,9 @@ struct mpic
#define MPIC_REGSET_STANDARD MPIC_REGSET(0) /* Original MPIC */
#define MPIC_REGSET_TSI108 MPIC_REGSET(1) /* Tsi108/109 PIC */
+/* Get the version of primary MPIC */
+extern u32 fsl_mpic_primary_get_version(void);
+
/* Allocate the controller structure and setup the linux irq descs
* for the range if interrupts passed in. No HW initialization is
* actually performed.
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index d30e6a6..48c8fae 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1165,10 +1165,30 @@ static struct irq_domain_ops mpic_host_ops = {
.xlate = mpic_host_xlate,
};
+static u32 fsl_mpic_get_version(struct mpic *mpic)
+{
+ u32 brr1;
+
+ brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
+ MPIC_FSL_BRR1);
+
+ return brr1 & MPIC_FSL_BRR1_VER;
+}
+
/*
* Exported functions
*/
+u32 fsl_mpic_primary_get_version(void)
+{
+ struct mpic *mpic = mpic_primary;
+
+ if (mpic)
+ return fsl_mpic_get_version(mpic);
+
+ return 0;
+}
+
struct mpic * __init mpic_alloc(struct device_node *node,
phys_addr_t phys_addr,
unsigned int flags,
@@ -1315,7 +1335,6 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, mpic->paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
if (mpic->flags & MPIC_FSL) {
- u32 brr1;
int ret;
/*
@@ -1326,9 +1345,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, mpic->paddr, &mpic->thiscpuregs,
MPIC_CPU_THISBASE, 0x1000);
- brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
- MPIC_FSL_BRR1);
- fsl_version = brr1 & MPIC_FSL_BRR1_VER;
+ fsl_version = fsl_mpic_get_version(mpic);
/* Error interrupt mask register (EIMR) is required for
* handling individual device error interrupts. EIMR
@@ -1518,9 +1535,7 @@ void __init mpic_init(struct mpic *mpic)
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
if (mpic->flags & MPIC_FSL) {
- u32 brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
- MPIC_FSL_BRR1);
- u32 version = brr1 & MPIC_FSL_BRR1_VER;
+ u32 version = fsl_mpic_get_version(mpic);
/*
* Timer group B is present at the latest in MPIC 3.1 (e.g.
--
1.8.0
^ permalink raw reply related
* Re: powerpc userspace address space layout information
From: David Gibson @ 2013-04-07 5:58 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <515E58E6.9030802@genband.com>
[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]
On Thu, Apr 04, 2013 at 10:53:58PM -0600, Chris Friesen wrote:
>
> Hi,
>
> I'm running with glibc 2.11 on a 2.6.34 kernel. 32-bit userspace on 64-bit kernel.
>
> On a complicated process the memory map looks something like this:
>
> <vdso, executable, heap, etc.>
> 5b2c000-f5b38000 r-xp 00000000 00:0f 3636 /lib/libnss_files-2.11.1.so
> <lots of libraries snipped>
> f6026000-f6035000 ---p 00096000 00:0f 3628 /lib/libkrb5.so.3.3
> <lots of libraries snipped>
> f7902000-f7905000 r-xp 00000000 00:0f 3607 /lib/libdl-2.11.1.so
> f7905000-f7914000 ---p 00003000 00:0f 3607 /lib/libdl-2.11.1.so
> f7914000-f7915000 r--p 00002000 00:0f 3607 /lib/libdl-2.11.1.so
> f7915000-f7916000 rw-p 00003000 00:0f 3607 /lib/libdl-2.11.1.so
> f7918000-f7919000 rw-p 00000000 00:00 0
> f7919000-f791a000 r--p 0001a000 00:0f 3646 /lib/libpthread-2.11.1.so
> f791a000-f791b000 r--p 00001000 00:0f 2306001 /path/to/binary
> f791b000-f791c000 r--p 00001000 00:0f 2306001 /path/to/binary
> f791c000-f791d000 r--p 00001000 00:0f 2306001 /path/to/binary
> f791d000-f7923000 rw-p 00000000 00:00 0
> f7923000-f7943000 r-xp 00000000 00:0f 13323 /lib/ld-2.11.1.so
> f7943000-f7944000 r--p 00020000 00:0f 13323 /lib/ld-2.11.1.so
> f7944000-f7945000 rw-p 00021000 00:0f 13323 /lib/ld-2.11.1.so
> f9000000-fac01000 rw-p 00000000 00:00 0
> fac06000-fac07000 rw-s 00000000 00:04 327690 /SYSV41050355 (deleted)
> fad00000-fae00000 rw-s 00000000 00:04 98307 /SYSVee113d3f (deleted)
> fae00000-fb000000 rw-s 00000000 00:04 7503872 /SYSVc5050355 (deleted)
> fb000000-fb200000 rw-s 00000000 00:04 7536641 /SYSV5c050355 (deleted)
> fb200000-fb600000 rw-s 00000000 00:0d 30647 /var/log/blah
> ffa8e000-ffab0000 rwxp 00000000 00:00 0 [stack]
>
>
> I have a few questions I'm hoping someone can help me with.
>
> First, what determines where /lib/ld-2.11.1.so gets mapped? It seems like
> it never goes above 0xf8000000 or so.
I think the mapping in of the ELF interpreter just calls the mmap()
code without hint address, so it goes where get_unmapped_area() puts
things by default, which can depend on a number of configuration settings.
> Second, what is the mapping at 0xf9000000-0xfac01000? Is this just empty
> space or is it reserved for something in particular?
Looks like anonymous memory, which could have been mapped by your
program or any of the libraries.
> Third, what's the most reliable way to ensure a block of addresses around
> 0xf6000000 don't get used for shared libraries? (We want to preserve
> those addresses for emulating hardware in a virtual machine.) We have
> this working on an older system but after upgrading to new software the
> libraries now extend further down the address space.
The only reliable method I can think of would be to use a custom
linker script to give your binary an extra program header specifying
that virtual region to map. In theory it can have zero size, and
whatever mem size you need to avoid adding any data to the binary
itself. In practice you may need to set a (small) non-zero filesize,
since some kernel versions had bugs handling segments with zero
filesize.
That would bring your program up with anonymous memory mapped across
the "reserved" region. You could then remap over it using MAP_FIXED
for the stuff you really want.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
From: Wang Dongsheng-B40534 @ 2013-04-07 3:40 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1364949416.24520.30@snotra>
> -----Original Message-----
> From: Wang Dongsheng-B40534
> Sent: Wednesday, April 03, 2013 10:49 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
>=20
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 03, 2013 8:37 AM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
> >
> > On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
> > > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
> > > desc->action->flag.
> > > So the wake up interrupt will not be disable in suspend_device_irqs.
> > >
> > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > ---
> > > v2:
> > > * Add: Check freescale chip in mpic_irq_set_wake().
> > > * Remove: Support mpic_irq_set_wake() in ht_chip.
> > >
> > > arch/powerpc/sysdev/mpic.c | 18 ++++++++++++++++++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > > index 3b2efd4..50d1ee1 100644
> > > --- a/arch/powerpc/sysdev/mpic.c
> > > +++ b/arch/powerpc/sysdev/mpic.c
> > > @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
> > > unsigned int flow_type)
> > > return IRQ_SET_MASK_OK_NOCOPY;
> > > }
> > >
> > > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > > + struct irq_desc *desc =3D container_of(d, struct irq_desc,
> > > irq_data);
> > > + struct mpic *mpic =3D mpic_from_irq_data(d);
> > > +
> > > + if (!(mpic->flags & MPIC_FSL))
> > > + return -EINVAL;
> >
> > I was thinking more along the lines of using MPIC_FSL during init to
> > decide whether to write this function to .irq_set_wake,
>=20
> I think the static registration method is more reasonable. We must
> consider readability. And mpic_irq_set_wake() will not be frequent calls.
> So within
> mpic_irq_set_wake() to decide is reasonable.
>=20
> > though that could probably wait until there's a second type of MPIC
> > that needs this (if ever).
> Even if the mpic_irq_set_wake() register in the first type of MPIC that
> is not belong MPIC_FSL, the function can return errno. I think the errno
> should be "-ENXIO".
> See kernel/irq/manage.c, set_irq_wake_real() the return value.
> The desc->irq_data.chip->irq_set_wake is null, the errno is -ENXIO.
>=20
> s/-EINVAL/-ENXIO/
About patches, if there are no other suggestion I'll send the V3.
^ permalink raw reply
* Re: [PATCH 08/17] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Zhao Chenhui @ 2013-04-07 3:15 UTC (permalink / raw)
To: Tang Yuantian-B29983; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B0B1265B9@039-SN2MPN1-013.039d.mgd.msft.net>
On Sun, Apr 07, 2013 at 10:30:41AM +0800, Tang Yuantian-B29983 wrote:
> Also send this patch to cpufreq@vger.kernel.org and linux-pm@vger.kerne=
l.org
> And better to rebase it on git://git.kernel.org/pub/scm/linux/kernel/gi=
t/rafael/linux-pm.git
>=20
> Thanks,
> Yuantian
OK. Thanks.
-Chenhui
>=20
> > -----Original Message-----
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+b29983=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Zhao Ch=
enhui
> > Sent: 2013=E5=B9=B44=E6=9C=883=E6=97=A5 21:09
> > To: linuxppc-dev@lists.ozlabs.org
> > Subject: [PATCH 08/17] powerpc/85xx: add support to JOG feature using
> > cpufreq interface
> >=20
> > From: chenhui zhao <chenhui.zhao@freescale.com>
> >=20
> > Some MPC85xx SoCs like MPC8536 and P1022 have a JOG feature, which
> > provides a dynamic mechanism to lower or raise the CPU core clock at
> > runtime.
> >=20
> > This patch adds the support to change CPU frequency using the standar=
d
> > cpufreq interface. The ratio CORE to CCB can be 1:1(except MPC8536), =
3:2,
> > 2:1, 5:2, 3:1, 7:2 and 4:1.
> >=20
> > Two CPU cores on P1022 must not in the low power state during the
> > frequency transition. The driver uses a flag to meet the requirement.
> >=20
> > The jog mode frequency transition process on the MPC8536 is similar t=
o
> > the deep sleep process. The driver need save the CPU state and restor=
e it
> > after CPU warm reset.
> >=20
> > Note:
> > * The I/O peripherals such as PCIe and eTSEC may lose packets during
> > the jog mode frequency transition.
> > * The driver doesn't support MPC8536 Rev 1.0 due to a JOG erratum.
> > Subsequent revisions of MPC8536 have corrected the erratum.
> >=20
> > Signed-off-by: Dave Liu <daveliu@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
^ permalink raw reply
* RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
From: Wang Dongsheng-B40534 @ 2013-04-07 3:01 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Johannes Berg, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1365020140.25627.9@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, April 04, 2013 4:16 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
>=20
> On 04/03/2013 12:36:41 AM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, April 03, 2013 8:35 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH] powerpc: add Book E support to 64-bit
> > hibernation
> > >
> > > On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote:
> > > > Hi scott & Johannes,
> > > >
> > > > Thanks for reviewing.
> > > >
> > > > @scott, About this patch, could you please help ack this patch?
> > >
> > > Please investigate the issue of whether we are loading kernel module
> > > code in this step, and whether cache flushing is needed as a result.
> > >
> > Sorry, I am not very clear what you mean.
> > When the kernel boot end, modprobe some xx.ko?
>=20
> Suppose, before the kernel was suspended, modules had been loaded. At
> what point do those modules get restored, and when does the cache get
> flushed?
>=20
Before the kernel was suspended, modules had been loaded, the modules is
already in memory. And /lib/modules/* is belong to vfs.
When suspend to disk, all used pages will be saved.(Include VFS, Loaded mod=
ules)
When restore, the kernel will not modprobe again.
The non-bootcpu will restore all pages.(Include VFS, Loaded modules)
So, It does not need to flush.
^ permalink raw reply
* RE: [PATCH 08/17] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Tang Yuantian-B29983 @ 2013-04-07 2:30 UTC (permalink / raw)
To: Zhao Chenhui-B35336, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1364994565-16010-8-git-send-email-chenhui.zhao@freescale.com>
QWxzbyBzZW5kIHRoaXMgcGF0Y2ggdG8gY3B1ZnJlcUB2Z2VyLmtlcm5lbC5vcmcgYW5kIGxpbnV4
LXBtQHZnZXIua2VybmVsLm9yZw0KQW5kIGJldHRlciB0byByZWJhc2UgaXQgb24gZ2l0Oi8vZ2l0
Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3JhZmFlbC9saW51eC1wbS5naXQN
Cg0KVGhhbmtzLA0KWXVhbnRpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG
cm9tOiBMaW51eHBwYy1kZXYgW21haWx0bzpsaW51eHBwYy1kZXYtDQo+IGJvdW5jZXMrYjI5OTgz
PWZyZWVzY2FsZS5jb21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mIFpoYW8gQ2hlbmh1
aQ0KPiBTZW50OiAyMDEzxOo01MIzyNUgMjE6MDkNCj4gVG86IGxpbnV4cHBjLWRldkBsaXN0cy5v
emxhYnMub3JnDQo+IFN1YmplY3Q6IFtQQVRDSCAwOC8xN10gcG93ZXJwYy84NXh4OiBhZGQgc3Vw
cG9ydCB0byBKT0cgZmVhdHVyZSB1c2luZw0KPiBjcHVmcmVxIGludGVyZmFjZQ0KPiANCj4gRnJv
bTogY2hlbmh1aSB6aGFvIDxjaGVuaHVpLnpoYW9AZnJlZXNjYWxlLmNvbT4NCj4gDQo+IFNvbWUg
TVBDODV4eCBTb0NzIGxpa2UgTVBDODUzNiBhbmQgUDEwMjIgaGF2ZSBhIEpPRyBmZWF0dXJlLCB3
aGljaA0KPiBwcm92aWRlcyBhIGR5bmFtaWMgbWVjaGFuaXNtIHRvIGxvd2VyIG9yIHJhaXNlIHRo
ZSBDUFUgY29yZSBjbG9jayBhdA0KPiBydW50aW1lLg0KPiANCj4gVGhpcyBwYXRjaCBhZGRzIHRo
ZSBzdXBwb3J0IHRvIGNoYW5nZSBDUFUgZnJlcXVlbmN5IHVzaW5nIHRoZSBzdGFuZGFyZA0KPiBj
cHVmcmVxIGludGVyZmFjZS4gVGhlIHJhdGlvIENPUkUgdG8gQ0NCIGNhbiBiZSAxOjEoZXhjZXB0
IE1QQzg1MzYpLCAzOjIsDQo+IDI6MSwgNToyLCAzOjEsIDc6MiBhbmQgNDoxLg0KPiANCj4gVHdv
IENQVSBjb3JlcyBvbiBQMTAyMiBtdXN0IG5vdCBpbiB0aGUgbG93IHBvd2VyIHN0YXRlIGR1cmlu
ZyB0aGUNCj4gZnJlcXVlbmN5IHRyYW5zaXRpb24uIFRoZSBkcml2ZXIgdXNlcyBhIGZsYWcgdG8g
bWVldCB0aGUgcmVxdWlyZW1lbnQuDQo+IA0KPiBUaGUgam9nIG1vZGUgZnJlcXVlbmN5IHRyYW5z
aXRpb24gcHJvY2VzcyBvbiB0aGUgTVBDODUzNiBpcyBzaW1pbGFyIHRvDQo+IHRoZSBkZWVwIHNs
ZWVwIHByb2Nlc3MuIFRoZSBkcml2ZXIgbmVlZCBzYXZlIHRoZSBDUFUgc3RhdGUgYW5kIHJlc3Rv
cmUgaXQNCj4gYWZ0ZXIgQ1BVIHdhcm0gcmVzZXQuDQo+IA0KPiBOb3RlOg0KPiAgKiBUaGUgSS9P
IHBlcmlwaGVyYWxzIHN1Y2ggYXMgUENJZSBhbmQgZVRTRUMgbWF5IGxvc2UgcGFja2V0cyBkdXJp
bmcNCj4gICAgdGhlIGpvZyBtb2RlIGZyZXF1ZW5jeSB0cmFuc2l0aW9uLg0KPiAgKiBUaGUgZHJp
dmVyIGRvZXNuJ3Qgc3VwcG9ydCBNUEM4NTM2IFJldiAxLjAgZHVlIHRvIGEgSk9HIGVycmF0dW0u
DQo+ICAgIFN1YnNlcXVlbnQgcmV2aXNpb25zIG9mIE1QQzg1MzYgaGF2ZSBjb3JyZWN0ZWQgdGhl
IGVycmF0dW0uDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBEYXZlIExpdSA8ZGF2ZWxpdUBmcmVlc2Nh
bGUuY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBMaSBZYW5nIDxsZW9saUBmcmVlc2NhbGUuY29tPg0K
PiBTaWduZWQtb2ZmLWJ5OiBKZXJyeSBIdWFuZyA8Q2hhbmctTWluZy5IdWFuZ0BmcmVlc2NhbGUu
Y29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBaaGFvIENoZW5odWkgPGNoZW5odWkuemhhb0BmcmVlc2Nh
bGUuY29tPg0KPiAtLS0NCj4gIGFyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9NYWtlZmlsZSB8
ICAgIDEgKw0KPiAgYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfc29jLmggICAgICAgIHwgICAgNSAr
DQo+ICBkcml2ZXJzL2NwdWZyZXEvS2NvbmZpZy5wb3dlcnBjICAgICAgfCAgIDEwICsNCj4gIGRy
aXZlcnMvY3B1ZnJlcS9NYWtlZmlsZSAgICAgICAgICAgICB8ICAgIDEgKw0KPiAgZHJpdmVycy9j
cHVmcmVxL2NwdWZyZXEtam9nLmMgICAgICAgIHwgIDQxNg0KPiArKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrDQo+ICBpbmNsdWRlL2xpbnV4L2NwdS5oICAgICAgICAgICAgICAgICAg
fCAgICA0ICsNCj4gIGtlcm5lbC9jcHUuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNjAg
KysrLS0tDQo+ICA3IGZpbGVzIGNoYW5nZWQsIDQ2NyBpbnNlcnRpb25zKCspLCAzMCBkZWxldGlv
bnMoLSkgIGNyZWF0ZSBtb2RlIDEwMDY0NA0KPiBkcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS1qb2cu
Yw0KPiANCj4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9NYWtlZmls
ZQ0KPiBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9NYWtlZmlsZQ0KPiBpbmRleCAyZjQ3
MTNmLi40OTQ2YmU3IDEwMDY0NA0KPiAtLS0gYS9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgv
TWFrZWZpbGUNCj4gKysrIGIvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy84NXh4L01ha2VmaWxlDQo+
IEBAIC0zLDYgKzMsNyBAQA0KPiAgIw0KPiAgb2JqLSQoQ09ORklHX1NNUCkgKz0gc21wLm8NCj4g
IG9iai0kKENPTkZJR19GU0xfUE1DKQkrPSBzbGVlcC5vDQo+ICtvYmotJChDT05GSUdfTVBDODV4
eF9DUFVGUkVRKSArPSBzbGVlcC5vDQo+IA0KPiAgb2JqLXkgKz0gY29tbW9uLm8NCj4gDQo+IGRp
ZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9zb2MuaA0KPiBiL2FyY2gvcG93ZXJw
Yy9zeXNkZXYvZnNsX3NvYy5oIGluZGV4IDI5YTg3ZWUuLmI3ZDVlZjcgMTAwNjQ0DQo+IC0tLSBh
L2FyY2gvcG93ZXJwYy9zeXNkZXYvZnNsX3NvYy5oDQo+ICsrKyBiL2FyY2gvcG93ZXJwYy9zeXNk
ZXYvZnNsX3NvYy5oDQo+IEBAIC02Miw1ICs2MiwxMCBAQCB2b2lkIGZzbF9odl9oYWx0KHZvaWQp
Ow0KPiAgICogY29kZSBjYW4gYmUgY29tcGF0aWJsZSB3aXRoIGJvdGggMzItYml0ICYgMzYtYml0
Lg0KPiAgICovDQo+ICBleHRlcm4gdm9pZCBtcGM4NXh4X2VudGVyX2RlZXBfc2xlZXAodTY0IGNj
c3JiYXIsIHUzMiBwb3dtZ3RyZXEpOw0KPiArDQo+ICtzdGF0aWMgaW5saW5lIHZvaWQgbXBjODV4
eF9lbnRlcl9qb2codTY0IGNjc3JiYXIsIHUzMiBwb3dtZ3RyZXEpIHsNCj4gKwltcGM4NXh4X2Vu
dGVyX2RlZXBfc2xlZXAoY2NzcmJhciwgcG93bWd0cmVxKTsgfQ0KPiAgI2VuZGlmDQo+ICAjZW5k
aWYNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvY3B1ZnJlcS9LY29uZmlnLnBvd2VycGMNCj4gYi9k
cml2ZXJzL2NwdWZyZXEvS2NvbmZpZy5wb3dlcnBjIGluZGV4IGU3Njk5MmYuLmM0N2E2NjIgMTAw
NjQ0DQo+IC0tLSBhL2RyaXZlcnMvY3B1ZnJlcS9LY29uZmlnLnBvd2VycGMNCj4gKysrIGIvZHJp
dmVycy9jcHVmcmVxL0tjb25maWcucG93ZXJwYw0KPiBAQCAtNSwzICs1LDEzIEBAIGNvbmZpZyBD
UFVfRlJFUV9NQVBMRQ0KPiAgCWhlbHANCj4gIAkgIFRoaXMgYWRkcyBzdXBwb3J0IGZvciBmcmVx
dWVuY3kgc3dpdGNoaW5nIG9uIE1hcGxlIDk3MEZYDQo+ICAJICBFdmFsdWF0aW9uIEJvYXJkIGFu
ZCBjb21wYXRpYmxlIGJvYXJkcyAoSUJNIEpTMnggYmxhZGVzKS4NCj4gKw0KPiArY29uZmlnIE1Q
Qzg1eHhfQ1BVRlJFUQ0KPiArCWJvb2wgIlN1cHBvcnQgZm9yIEZyZWVzY2FsZSBNUEM4NXh4IENQ
VSBmcmVxIg0KPiArCWRlcGVuZHMgb24gUFBDXzg1eHggJiYgUFBDMzIgJiYgIVBQQ19FNTAwTUMN
Cj4gKwlzZWxlY3QgQ1BVX0ZSRVFfVEFCTEUNCj4gKwloZWxwDQo+ICsJICBUaGlzIGFkZHMgc3Vw
cG9ydCBmb3IgZHluYW1pYyBmcmVxdWVuY3kgc3dpdGNoaW5nIG9uDQo+ICsJICBGcmVlc2NhbGUg
TVBDODV4eCBieSBjcHVmcmVxIGludGVyZmFjZS4gTVBDODUzNiBhbmQgUDEwMjINCj4gKwkgIGhh
dmUgYSBKT0cgZmVhdHVyZSwgd2hpY2ggcHJvdmlkZXMgYSBkeW5hbWljIG1lY2hhbmlzbQ0KPiAr
CSAgdG8gbG93ZXIgb3IgcmFpc2UgdGhlIENQVSBjb3JlIGNsb2NrIGF0IHJ1bnRpbWUuDQo+IGRp
ZmYgLS1naXQgYS9kcml2ZXJzL2NwdWZyZXEvTWFrZWZpbGUgYi9kcml2ZXJzL2NwdWZyZXEvTWFr
ZWZpbGUgaW5kZXgNCj4gODYzZmQxOC4uNjI4ZmEwZSAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy9j
cHVmcmVxL01ha2VmaWxlDQo+ICsrKyBiL2RyaXZlcnMvY3B1ZnJlcS9NYWtlZmlsZQ0KPiBAQCAt
NjEsMyArNjEsNCBAQCBvYmotJChDT05GSUdfQVJNX0lNWDZRX0NQVUZSRVEpCQkrPSBpbXg2cS0N
Cj4gY3B1ZnJlcS5vDQo+IA0KPiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQo+ICMjIyMjIyMjIw0KPiAgIyBQ
b3dlclBDIHBsYXRmb3JtIGRyaXZlcnMNCj4gIG9iai0kKENPTkZJR19DUFVfRlJFUV9NQVBMRSkJ
CSs9IG1hcGxlLWNwdWZyZXEubw0KPiArb2JqLSQoQ09ORklHX01QQzg1eHhfQ1BVRlJFUSkJCSs9
IGNwdWZyZXEtam9nLm8NCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvY3B1ZnJlcS9jcHVmcmVxLWpv
Zy5jIGIvZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEtDQo+IGpvZy5jIG5ldyBmaWxlIG1vZGUgMTAw
NjQ0IGluZGV4IDAwMDAwMDAuLjU2NTZkNDgNCj4gLS0tIC9kZXYvbnVsbA0KPiArKysgYi9kcml2
ZXJzL2NwdWZyZXEvY3B1ZnJlcS1qb2cuYw0KPiBAQCAtMCwwICsxLDQxNiBAQA0KPiArLyoNCj4g
KyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDEyIEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMu
DQo+ICsgKiBBdXRob3I6IERhdmUgTGl1IDxkYXZlbGl1QGZyZWVzY2FsZS5jb20+DQo+ICsgKiBN
b2RpZmllcjogQ2hlbmh1aSBaaGFvIDxjaGVuaHVpLnpoYW9AZnJlZXNjYWxlLmNvbT4NCj4gKyAq
DQo+ICsgKiBUaGUgY3B1ZnJlcSBkcml2ZXIgaXMgZm9yIEZyZWVzY2FsZSA4NXh4IHByb2Nlc3Nv
ciwNCj4gKyAqIGJhc2VkIG9uIGFyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvY2VsbC9jYmVfY3B1ZnJl
cS5jDQo+ICsgKiAoQykgQ29weXJpZ2h0IElCTSBEZXV0c2NobGFuZCBFbnR3aWNrbHVuZyBHbWJI
IDIwMDUtMjAwNw0KPiArICoJQ2hyaXN0aWFuIEtyYWZmdCA8a3JhZmZ0QGRlLmlibS5jb20+DQo+
ICsgKg0KPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0
cmlidXRlIGl0IGFuZC9vciBtb2RpZnkNCj4gKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQo+ICsgKiB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRp
b24pDQo+ICsgKiBhbnkgbGF0ZXIgdmVyc2lvbi4NCj4gKyAqDQo+ICsgKiBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCj4gKyAq
IGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJh
bnR5IG9mDQo+ICsgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS
IFBVUlBPU0UuICBTZWUgdGhlDQo+ICsgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3Ig
bW9yZSBkZXRhaWxzLg0KPiArICoNCj4gKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv
cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlDQo+ICsgKiBhbG9uZyB3aXRoIHRo
aXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KPiArICogRm91
bmRhdGlvbiwgSW5jLiwgNjc1IE1hc3MgQXZlLCBDYW1icmlkZ2UsIE1BIDAyMTM5LCBVU0EuDQo+
ICsgKi8NCj4gKw0KPiArI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KPiArI2luY2x1ZGUgPGxp
bnV4L2NwdWZyZXEuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9vZl9wbGF0Zm9ybS5oPg0KPiArI2lu
Y2x1ZGUgPGxpbnV4L3N1c3BlbmQuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9jcHUuaD4NCj4gKyNp
bmNsdWRlIDxsaW51eC9pby5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L3RpbWUuaD4NCj4gKyNpbmNs
dWRlIDxsaW51eC9zbXAuaD4NCj4gKw0KPiArI2luY2x1ZGUgPGFzbS9wcm9tLmg+DQo+ICsjaW5j
bHVkZSA8YXNtL3JlZy5oPg0KPiArI2luY2x1ZGUgPGFzbS9tYWNoZGVwLmg+DQo+ICsNCj4gKyNp
bmNsdWRlIDxzeXNkZXYvZnNsX3NvYy5oPg0KPiArDQo+ICtzdGF0aWMgREVGSU5FX01VVEVYKG1w
Yzg1eHhfc3dpdGNoX211dGV4KTsNCj4gK3N0YXRpYyB2b2lkIF9faW9tZW0gKmd1dHM7DQo+ICsN
Cj4gK3N0YXRpYyB1MzIgc3lzZnJlcTsNCj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgbWF4X3BsbFsy
XTsNCj4gK3N0YXRpYyBhdG9taWNfdCBpbl9qb2dfcHJvY2VzczsNCj4gK3N0YXRpYyBzdHJ1Y3Qg
Y3B1ZnJlcV9mcmVxdWVuY3lfdGFibGUgKm1wYzg1eHhfZnJlcXM7IHN0YXRpYyBpbnQNCj4gKygq
c2V0X3BsbCkodW5zaWduZWQgaW50IGNwdSwgdW5zaWduZWQgaW50IHBsbCk7DQo+ICsNCj4gK3N0
YXRpYyBzdHJ1Y3QgY3B1ZnJlcV9mcmVxdWVuY3lfdGFibGUgbXBjODUzNl9mcmVxc190YWJsZVtd
ID0gew0KPiArCXszLAkwfSwNCj4gKwl7NCwJMH0sDQo+ICsJezUsCTB9LA0KPiArCXs2LAkwfSwN
Cj4gKwl7NywJMH0sDQo+ICsJezgsCTB9LA0KPiArCXswLAlDUFVGUkVRX1RBQkxFX0VORH0sDQo+
ICt9Ow0KPiArDQo+ICtzdGF0aWMgc3RydWN0IGNwdWZyZXFfZnJlcXVlbmN5X3RhYmxlIHAxMDIy
X2ZyZXFzX3RhYmxlW10gPSB7DQo+ICsJezIsCTB9LA0KPiArCXszLAkwfSwNCj4gKwl7NCwJMH0s
DQo+ICsJezUsCTB9LA0KPiArCXs2LAkwfSwNCj4gKwl7NywJMH0sDQo+ICsJezgsCTB9LA0KPiAr
CXswLAlDUFVGUkVRX1RBQkxFX0VORH0sDQo+ICt9Ow0KPiArDQo+ICsjZGVmaW5lIEZSRVFfNTAw
TUh6CTUwMDAwMDAwMA0KPiArI2RlZmluZSBGUkVRXzgwME1Iegk4MDAwMDAwMDANCj4gKw0KPiAr
I2RlZmluZSBDT1JFX1JBVElPX1NUUklERQk4DQo+ICsjZGVmaW5lIENPUkVfUkFUSU9fTUFTSwkJ
MHgzZg0KPiArI2RlZmluZSBDT1JFX1JBVElPX1NISUZUCTE2DQo+ICsNCj4gKyNkZWZpbmUgUE9S
UExMU1IJMHgwCS8qIFBvd2VyLU9uIFJlc2V0IFBMTCByYXRpbyBzdGF0dXMgcmVnaXN0ZXIgKi8N
Cj4gKw0KPiArI2RlZmluZSBQTUpDUgkJMHg3YwkvKiBQb3dlciBNYW5hZ2VtZW50IEpvZyBDb250
cm9sIFJlZ2lzdGVyICovDQo+ICsjZGVmaW5lIFBNSkNSX0NPUkUwX1NQRAkweDAwMDAxMDAwDQo+
ICsjZGVmaW5lIFBNSkNSX0NPUkVfU1BECTB4MDAwMDIwMDANCj4gKw0KPiArI2RlZmluZSBQT1dN
R1RDU1IJMHg4MCAvKiBQb3dlciBtYW5hZ2VtZW50IGNvbnRyb2wgYW5kIHN0YXR1cw0KPiByZWdp
c3RlciAqLw0KPiArI2RlZmluZSBQT1dNR1RDU1JfSk9HCQkweDAwMjAwMDAwDQo+ICsjZGVmaW5l
IFBPV01HVENTUl9JTlRfTUFTSwkweDAwMDAwZjAwDQo+ICsNCj4gK3N0YXRpYyB2b2lkIHNwaW5f
d2hpbGVfam9nZ2luZyh2b2lkICpkdW1teSkgew0KPiArCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQo+
ICsNCj4gKwlsb2NhbF9pcnFfc2F2ZShmbGFncyk7DQo+ICsNCj4gKwlhdG9taWNfaW5jKCZpbl9q
b2dfcHJvY2Vzcyk7DQo+ICsNCj4gKwl3aGlsZSAoYXRvbWljX3JlYWQoJmluX2pvZ19wcm9jZXNz
KSAhPSAwKQ0KPiArCQliYXJyaWVyKCk7DQo+ICsNCj4gKwlsb2NhbF9pcnFfcmVzdG9yZShmbGFn
cyk7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbnQgZ2V0X3BsbChpbnQgaHdfY3B1KQ0KPiArew0K
PiArCWludCBzaGlmdDsNCj4gKwl1MzIgdmFsID0gaW5fYmUzMihndXRzICsgUE9SUExMU1IpOw0K
PiArDQo+ICsJc2hpZnQgPSBod19jcHUgKiBDT1JFX1JBVElPX1NUUklERSArIENPUkVfUkFUSU9f
U0hJRlQ7DQo+ICsNCj4gKwlyZXR1cm4gKHZhbCA+PiBzaGlmdCkgJiBDT1JFX1JBVElPX01BU0s7
IH0NCj4gKw0KPiArc3RhdGljIGludCBtcGM4NTM2X3NldF9wbGwodW5zaWduZWQgaW50IGNwdSwg
dW5zaWduZWQgaW50IHBsbCkgew0KPiArCXUzMiBjb3JlZnJlcSwgdmFsLCBtYXNrOw0KPiArCXVu
c2lnbmVkIGludCBjdXJfcGxsID0gZ2V0X3BsbCgwKTsNCj4gKwl1bnNpZ25lZCBsb25nIGZsYWdz
Ow0KPiArDQo+ICsJaWYgKHBsbCA9PSBjdXJfcGxsKQ0KPiArCQlyZXR1cm4gMDsNCj4gKw0KPiAr
CXZhbCA9IChwbGwgJiBDT1JFX1JBVElPX01BU0spIDw8IENPUkVfUkFUSU9fU0hJRlQ7DQo+ICsN
Cj4gKwljb3JlZnJlcSA9IHN5c2ZyZXEgKiBwbGwgLyAyOw0KPiArCS8qDQo+ICsJICogU2V0IHRo
ZSBDT1JFeF9TUEQgYml0IGlmIHRoZSByZXF1ZXN0ZWQgY29yZSBmcmVxdWVuY3kNCj4gKwkgKiBp
cyBsYXJnZXIgdGhhbiB0aGUgdGhyZXNob2xkIGZyZXF1ZW5jeS4NCj4gKwkgKi8NCj4gKwlpZiAo
Y29yZWZyZXEgPiBGUkVRXzgwME1IeikNCj4gKwkJCXZhbCB8PSBQTUpDUl9DT1JFX1NQRDsNCj4g
Kw0KPiArCW1hc2sgPSAoQ09SRV9SQVRJT19NQVNLIDw8IENPUkVfUkFUSU9fU0hJRlQpIHwgUE1K
Q1JfQ09SRV9TUEQ7DQo+ICsJY2xyc2V0Yml0c19iZTMyKGd1dHMgKyBQTUpDUiwgbWFzaywgdmFs
KTsNCj4gKw0KPiArCS8qIHJlYWRiYWNrIHRvIHN5bmMgd3JpdGUgKi8NCj4gKwlpbl9iZTMyKGd1
dHMgKyBQTUpDUik7DQo+ICsNCj4gKwlsb2NhbF9pcnFfc2F2ZShmbGFncyk7DQo+ICsJbXBjODV4
eF9lbnRlcl9qb2coZ2V0X2ltbXJiYXNlKCksIFBPV01HVENTUl9KT0cpOw0KPiArCWxvY2FsX2ly
cV9yZXN0b3JlKGZsYWdzKTsNCj4gKw0KPiArCS8qIHZlcmlmeSAqLw0KPiArCWN1cl9wbGwgPSAg
Z2V0X3BsbCgwKTsNCj4gKwlpZiAoY3VyX3BsbCAhPSBwbGwpIHsNCj4gKwkJcHJfZXJyKCIlczog
ZXJyb3IuIFRoZSBjdXJyZW50IFBMTCBvZiBjb3JlIDAgaXMgJWQgaW5zdGVhZA0KPiBvZiAlZC5c
biIsDQo+ICsJCQkJX19mdW5jX18sIGN1cl9wbGwsIHBsbCk7DQo+ICsJCXJldHVybiAtMTsNCj4g
Kwl9DQo+ICsNCj4gKwlyZXR1cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBwMTAyMl9z
ZXRfcGxsKHVuc2lnbmVkIGludCBjcHUsIHVuc2lnbmVkIGludCBwbGwpIHsNCj4gKwlpbnQgaW5k
ZXgsIGh3X2NwdSA9IGdldF9oYXJkX3NtcF9wcm9jZXNzb3JfaWQoY3B1KTsNCj4gKwlpbnQgc2hp
ZnQ7DQo+ICsJdTMyIGNvcmVmcmVxLCB2YWwsIG1hc2sgPSAwOw0KPiArCXVuc2lnbmVkIGludCBj
dXJfcGxsID0gZ2V0X3BsbChod19jcHUpOw0KPiArCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQo+ICsJ
aW50IHJldCA9IDA7DQo+ICsNCj4gKwlpZiAocGxsID09IGN1cl9wbGwpDQo+ICsJCXJldHVybiAw
Ow0KPiArDQo+ICsJc2hpZnQgPSBod19jcHUgKiBDT1JFX1JBVElPX1NUUklERSArIENPUkVfUkFU
SU9fU0hJRlQ7DQo+ICsJdmFsID0gKHBsbCAmIENPUkVfUkFUSU9fTUFTSykgPDwgc2hpZnQ7DQo+
ICsNCj4gKwljb3JlZnJlcSA9IHN5c2ZyZXEgKiBwbGwgLyAyOw0KPiArCS8qDQo+ICsJICogU2V0
IHRoZSBDT1JFeF9TUEQgYml0IGlmIHRoZSByZXF1ZXN0ZWQgY29yZSBmcmVxdWVuY3kNCj4gKwkg
KiBpcyBsYXJnZXIgdGhhbiB0aGUgdGhyZXNob2xkIGZyZXF1ZW5jeS4NCj4gKwkgKi8NCj4gKwlp
ZiAoY29yZWZyZXEgPiBGUkVRXzUwME1IeikNCj4gKwkJdmFsIHw9IFBNSkNSX0NPUkUwX1NQRCA8
PCBod19jcHU7DQo+ICsNCj4gKwltYXNrID0gKENPUkVfUkFUSU9fTUFTSyA8PCBzaGlmdCkgfCAo
UE1KQ1JfQ09SRTBfU1BEIDw8IGh3X2NwdSk7DQo+ICsJY2xyc2V0Yml0c19iZTMyKGd1dHMgKyBQ
TUpDUiwgbWFzaywgdmFsKTsNCj4gKw0KPiArCS8qIHJlYWRiYWNrIHRvIHN5bmMgd3JpdGUgKi8N
Cj4gKwlpbl9iZTMyKGd1dHMgKyBQTUpDUik7DQo+ICsNCj4gKwljcHVfaG90cGx1Z19kaXNhYmxl
X2JlZm9yZV9mcmVlemUoKTsNCj4gKwkvKg0KPiArCSAqIEEgSm9nIHJlcXVlc3QgY2FuIG5vdCBi
ZSBhc3NlcnRlZCB3aGVuIGFueSBjb3JlIGlzIGluIGEgbG93DQo+ICsJICogcG93ZXIgc3RhdGUg
b24gUDEwMjIuIEJlZm9yZSBleGVjdXRpbmcgYSBqb2cgcmVxdWVzdCwgYW55DQo+ICsJICogY29y
ZSB3aGljaCBpcyBpbiBhIGxvdyBwb3dlciBzdGF0ZSBtdXN0IGJlIHdha2VkIGJ5IGENCj4gKwkg
KiBpbnRlcnJ1cHQsIGFuZCBrZWVwIHdha2luZyB1cCB1bnRpbCB0aGUgc2VxdWVuY2UgaXMNCj4g
KwkgKiBmaW5pc2hlZC4NCj4gKwkgKi8NCj4gKwlmb3JfZWFjaF9wcmVzZW50X2NwdShpbmRleCkg
ew0KPiArCQlpZiAoIWNwdV9vbmxpbmUoaW5kZXgpKSB7DQo+ICsJCQljcHVfaG90cGx1Z19lbmFi
bGVfYWZ0ZXJfdGhhdygpOw0KPiArCQkJcHJfZXJyKCIlczogZXJyb3IsIGNvcmUlZCBpcyBkb3du
LlxuIiwgX19mdW5jX18sIGluZGV4KTsNCj4gKwkJCXJldHVybiAtMTsNCj4gKwkJfQ0KPiArCX0N
Cj4gKw0KPiArCWF0b21pY19zZXQoJmluX2pvZ19wcm9jZXNzLCAwKTsNCj4gKwlzbXBfY2FsbF9m
dW5jdGlvbihzcGluX3doaWxlX2pvZ2dpbmcsIE5VTEwsIDApOw0KPiArDQo+ICsJbG9jYWxfaXJx
X3NhdmUoZmxhZ3MpOw0KPiArDQo+ICsJLyogV2FpdCBmb3IgdGhlIG90aGVyIGNvcmUgdG8gd2Fr
ZS4gKi8NCj4gKwlpZiAoIXNwaW5fZXZlbnRfdGltZW91dChhdG9taWNfcmVhZCgmaW5fam9nX3By
b2Nlc3MpID09IDEsIDEwMDAsDQo+IDEwMCkpIHsNCj4gKwkJcHJfZXJyKCIlczogdGltZW91dCwg
dGhlIG90aGVyIGNvcmUgaXMgbm90IGF0IHJ1bm5pbmcNCj4gc3RhdGUuXG4iLA0KPiArCQkJCQlf
X2Z1bmNfXyk7DQo+ICsJCXJldCA9IC0xOw0KPiArCQlnb3RvIGVycjsNCj4gKwl9DQo+ICsNCj4g
KwlvdXRfYmUzMihndXRzICsgUE9XTUdUQ1NSLCBQT1dNR1RDU1JfSk9HIHwgUE9XTUdUQ1NSX0lO
VF9NQVNLKTsNCj4gKw0KPiArCWlmICghc3Bpbl9ldmVudF90aW1lb3V0KA0KPiArCQkoaW5fYmUz
MihndXRzICsgUE9XTUdUQ1NSKSAmIFBPV01HVENTUl9KT0cpID09IDAsIDEwMDAsIDEwMCkpDQo+
IHsNCj4gKwkJcHJfZXJyKCIlczogdGltZW91dCwgZmFpbCB0byBzd2l0Y2ggdGhlIGNvcmUgZnJl
cXVlbmN5LlxuIiwNCj4gKwkJCQlfX2Z1bmNfXyk7DQo+ICsJCXJldCA9IC0xOw0KPiArCQlnb3Rv
IGVycjsNCj4gKwl9DQo+ICsNCj4gKwljbHJiaXRzMzIoZ3V0cyArIFBPV01HVENTUiwgUE9XTUdU
Q1NSX0lOVF9NQVNLKTsNCj4gKwlpbl9iZTMyKGd1dHMgKyBQT1dNR1RDU1IpOw0KPiArDQo+ICsJ
YXRvbWljX3NldCgmaW5fam9nX3Byb2Nlc3MsIDApOw0KPiArZXJyOg0KPiArCWxvY2FsX2lycV9y
ZXN0b3JlKGZsYWdzKTsNCj4gKwljcHVfaG90cGx1Z19lbmFibGVfYWZ0ZXJfdGhhdygpOw0KPiAr
DQo+ICsJLyogdmVyaWZ5ICovDQo+ICsJY3VyX3BsbCA9ICBnZXRfcGxsKGh3X2NwdSk7DQo+ICsJ
aWYgKGN1cl9wbGwgIT0gcGxsKSB7DQo+ICsJCXByX2VycigiJXM6IGVycm9yLCB0aGUgY3VycmVu
dCBQTEwgb2YgY29yZSAlZCBpcyAlZCBpbnN0ZWFkDQo+IG9mICVkLlxuIiwNCj4gKwkJCQlfX2Z1
bmNfXywgaHdfY3B1LCBjdXJfcGxsLCBwbGwpOw0KPiArCQlyZXR1cm4gLTE7DQo+ICsJfQ0KPiAr
DQo+ICsJcmV0dXJuIHJldDsNCj4gK30NCj4gKw0KPiArLyoNCj4gKyAqIGNwdWZyZXEgZnVuY3Rp
b25zDQo+ICsgKi8NCj4gK3N0YXRpYyBpbnQgbXBjODV4eF9jcHVmcmVxX2NwdV9pbml0KHN0cnVj
dCBjcHVmcmVxX3BvbGljeSAqcG9saWN5KSB7DQo+ICsJdW5zaWduZWQgaW50IGksIGN1cl9wbGw7
DQo+ICsJaW50IGh3X2NwdSA9IGdldF9oYXJkX3NtcF9wcm9jZXNzb3JfaWQocG9saWN5LT5jcHUp
Ow0KPiArDQo+ICsJaWYgKCFjcHVfcHJlc2VudChwb2xpY3ktPmNwdSkpDQo+ICsJCXJldHVybiAt
RU5PREVWOw0KPiArDQo+ICsJLyogdGhlIGxhdGVuY3kgb2YgYSB0cmFuc2l0aW9uLCB0aGUgdW5p
dCBpcyBucyAqLw0KPiArCXBvbGljeS0+Y3B1aW5mby50cmFuc2l0aW9uX2xhdGVuY3kgPSAyMDAw
Ow0KPiArDQo+ICsJY3VyX3BsbCA9IGdldF9wbGwoaHdfY3B1KTsNCj4gKw0KPiArCS8qIGluaXRp
YWxpemUgZnJlcXVlbmN5IHRhYmxlICovDQo+ICsJcHJfZGVidWcoImNvcmUlZCBmcmVxdWVuY3kg
dGFibGU6XG4iLCBod19jcHUpOw0KPiArCWZvciAoaSA9IDA7IG1wYzg1eHhfZnJlcXNbaV0uZnJl
cXVlbmN5ICE9IENQVUZSRVFfVEFCTEVfRU5EOyBpKyspIHsNCj4gKwkJaWYgKG1wYzg1eHhfZnJl
cXNbaV0uaW5kZXggPD0gbWF4X3BsbFtod19jcHVdKSB7DQo+ICsJCQkvKiBUaGUgZnJlcXVlbmN5
IHVuaXQgaXMga0h6LiAqLw0KPiArCQkJbXBjODV4eF9mcmVxc1tpXS5mcmVxdWVuY3kgPQ0KPiAr
CQkJCShzeXNmcmVxICogbXBjODV4eF9mcmVxc1tpXS5pbmRleCAvIDIpIC8gMTAwMDsNCj4gKwkJ
fSBlbHNlIHsNCj4gKwkJCW1wYzg1eHhfZnJlcXNbaV0uZnJlcXVlbmN5ID0gQ1BVRlJFUV9FTlRS
WV9JTlZBTElEOw0KPiArCQl9DQo+ICsNCj4gKwkJcHJfZGVidWcoIiVkOiAlZGtIelxuIiwgaSwg
bXBjODV4eF9mcmVxc1tpXS5mcmVxdWVuY3kpOw0KPiArDQo+ICsJCWlmIChtcGM4NXh4X2ZyZXFz
W2ldLmluZGV4ID09IGN1cl9wbGwpDQo+ICsJCQlwb2xpY3ktPmN1ciA9IG1wYzg1eHhfZnJlcXNb
aV0uZnJlcXVlbmN5Ow0KPiArCX0NCj4gKwlwcl9kZWJ1ZygiY3VycmVudCBwbGwgaXMgYXQgJWQs
IGFuZCBjb3JlIGZyZXEgaXMlZFxuIiwNCj4gKwkJCWN1cl9wbGwsIHBvbGljeS0+Y3VyKTsNCj4g
Kw0KPiArCWNwdWZyZXFfZnJlcXVlbmN5X3RhYmxlX2dldF9hdHRyKG1wYzg1eHhfZnJlcXMsIHBv
bGljeS0+Y3B1KTsNCj4gKw0KPiArCS8qDQo+ICsJICogVGhpcyBlbnN1cmVzIHRoYXQgcG9saWN5
LT5jcHVpbmZvX21pbg0KPiArCSAqIGFuZCBwb2xpY3ktPmNwdWluZm9fbWF4IGFyZSBzZXQgY29y
cmVjdGx5Lg0KPiArCSAqLw0KPiArCXJldHVybiBjcHVmcmVxX2ZyZXF1ZW5jeV90YWJsZV9jcHVp
bmZvKHBvbGljeSwgbXBjODV4eF9mcmVxcyk7IH0NCj4gKw0KPiArc3RhdGljIGludCBtcGM4NXh4
X2NwdWZyZXFfY3B1X2V4aXQoc3RydWN0IGNwdWZyZXFfcG9saWN5ICpwb2xpY3kpIHsNCj4gKwlj
cHVmcmVxX2ZyZXF1ZW5jeV90YWJsZV9wdXRfYXR0cihwb2xpY3ktPmNwdSk7DQo+ICsNCj4gKwly
ZXR1cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBtcGM4NXh4X2NwdWZyZXFfdmVyaWZ5
KHN0cnVjdCBjcHVmcmVxX3BvbGljeSAqcG9saWN5KSB7DQo+ICsJcmV0dXJuIGNwdWZyZXFfZnJl
cXVlbmN5X3RhYmxlX3ZlcmlmeShwb2xpY3ksIG1wYzg1eHhfZnJlcXMpOyB9DQo+ICsNCj4gK3N0
YXRpYyBpbnQgbXBjODV4eF9jcHVmcmVxX3RhcmdldChzdHJ1Y3QgY3B1ZnJlcV9wb2xpY3kgKnBv
bGljeSwNCj4gKwkJCSAgICAgIHVuc2lnbmVkIGludCB0YXJnZXRfZnJlcSwNCj4gKwkJCSAgICAg
IHVuc2lnbmVkIGludCByZWxhdGlvbikNCj4gK3sNCj4gKwlzdHJ1Y3QgY3B1ZnJlcV9mcmVxcyBm
cmVxczsNCj4gKwl1bnNpZ25lZCBpbnQgbmV3Ow0KPiArCWludCByZXQgPSAwOw0KPiArDQo+ICsJ
aWYgKCFzZXRfcGxsKQ0KPiArCQlyZXR1cm4gLUVOT0RFVjsNCj4gKw0KPiArCWNwdWZyZXFfZnJl
cXVlbmN5X3RhYmxlX3RhcmdldChwb2xpY3ksDQo+ICsJCQkJICAgICAgIG1wYzg1eHhfZnJlcXMs
DQo+ICsJCQkJICAgICAgIHRhcmdldF9mcmVxLA0KPiArCQkJCSAgICAgICByZWxhdGlvbiwNCj4g
KwkJCQkgICAgICAgJm5ldyk7DQo+ICsNCj4gKwlmcmVxcy5vbGQgPSBwb2xpY3ktPmN1cjsNCj4g
KwlmcmVxcy5uZXcgPSBtcGM4NXh4X2ZyZXFzW25ld10uZnJlcXVlbmN5Ow0KPiArCWZyZXFzLmNw
dSA9IHBvbGljeS0+Y3B1Ow0KPiArDQo+ICsJbXV0ZXhfbG9jaygmbXBjODV4eF9zd2l0Y2hfbXV0
ZXgpOw0KPiArCWNwdWZyZXFfbm90aWZ5X3RyYW5zaXRpb24oJmZyZXFzLCBDUFVGUkVRX1BSRUNI
QU5HRSk7DQo+ICsNCj4gKwlyZXQgPSBzZXRfcGxsKHBvbGljeS0+Y3B1LCBtcGM4NXh4X2ZyZXFz
W25ld10uaW5kZXgpOw0KPiArCWlmICghcmV0KSB7DQo+ICsJCXByX2luZm8oImNwdWZyZXE6IFNl
dHRpbmcgY29yZSVkIGZyZXF1ZW5jeSB0byAlZCBrSHogYW5kIFBMTA0KPiByYXRpbyB0byAlZDoy
XG4iLA0KPiArCQkJIHBvbGljeS0+Y3B1LCBtcGM4NXh4X2ZyZXFzW25ld10uZnJlcXVlbmN5LA0K
PiArCQkJIG1wYzg1eHhfZnJlcXNbbmV3XS5pbmRleCk7DQo+ICsNCj4gKwkJcHBjX3Byb2NfZnJl
cSA9IGZyZXFzLm5ldyAqIDEwMDB1bDsNCj4gKwl9DQo+ICsJY3B1ZnJlcV9ub3RpZnlfdHJhbnNp
dGlvbigmZnJlcXMsIENQVUZSRVFfUE9TVENIQU5HRSk7DQo+ICsJbXV0ZXhfdW5sb2NrKCZtcGM4
NXh4X3N3aXRjaF9tdXRleCk7DQo+ICsNCj4gKwlyZXR1cm4gcmV0Ow0KPiArfQ0KPiArDQo+ICtz
dGF0aWMgc3RydWN0IGNwdWZyZXFfZHJpdmVyIG1wYzg1eHhfY3B1ZnJlcV9kcml2ZXIgPSB7DQo+
ICsJLnZlcmlmeQkJPSBtcGM4NXh4X2NwdWZyZXFfdmVyaWZ5LA0KPiArCS50YXJnZXQJCT0gbXBj
ODV4eF9jcHVmcmVxX3RhcmdldCwNCj4gKwkuaW5pdAkJPSBtcGM4NXh4X2NwdWZyZXFfY3B1X2lu
aXQsDQo+ICsJLmV4aXQJCT0gbXBjODV4eF9jcHVmcmVxX2NwdV9leGl0LA0KPiArCS5uYW1lCQk9
ICJtcGM4NXh4LUpPRyIsDQo+ICsJLm93bmVyCQk9IFRISVNfTU9EVUxFLA0KPiArCS5mbGFncwkJ
PSBDUFVGUkVRX0NPTlNUX0xPT1BTLA0KPiArfTsNCj4gKw0KPiArc3RhdGljIGludCBtcGM4NXh4
X2pvYl9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpvZmRldikgew0KPiArCXN0cnVjdCBk
ZXZpY2Vfbm9kZSAqbnAgPSBvZmRldi0+ZGV2Lm9mX25vZGU7DQo+ICsJdW5zaWduZWQgaW50IHN2
cjsNCj4gKw0KPiArCWlmIChvZl9kZXZpY2VfaXNfY29tcGF0aWJsZShucCwgImZzbCxtcGM4NTM2
LWd1dHMiKSkgew0KPiArCQlzdnIgPSBtZnNwcihTUFJOX1NWUik7DQo+ICsJCWlmICgoc3ZyICYg
MHg3ZmZmKSA9PSAweDEwKSB7DQo+ICsJCQlwcl9lcnIoIk1QQzg1MzYgUmV2IDEuMCBkbyBub3Qg
c3VwcG9ydCBKT0cuXG4iKTsNCj4gKwkJCXJldHVybiAtRU5PREVWOw0KPiArCQl9DQo+ICsJCW1w
Yzg1eHhfZnJlcXMgPSBtcGM4NTM2X2ZyZXFzX3RhYmxlOw0KPiArCQlzZXRfcGxsID0gbXBjODUz
Nl9zZXRfcGxsOw0KPiArCX0gZWxzZSBpZiAob2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobnAsICJm
c2wscDEwMjItZ3V0cyIpKSB7DQo+ICsJCW1wYzg1eHhfZnJlcXMgPSBwMTAyMl9mcmVxc190YWJs
ZTsNCj4gKwkJc2V0X3BsbCA9IHAxMDIyX3NldF9wbGw7DQo+ICsJfSBlbHNlIHsNCj4gKwkJcmV0
dXJuIC1FTk9ERVY7DQo+ICsJfQ0KPiArDQo+ICsJc3lzZnJlcSA9IGZzbF9nZXRfc3lzX2ZyZXEo
KTsNCj4gKw0KPiArCWd1dHMgPSBvZl9pb21hcChucCwgMCk7DQo+ICsJaWYgKCFndXRzKQ0KPiAr
CQlyZXR1cm4gLUVOT0RFVjsNCj4gKw0KPiArCW1heF9wbGxbMF0gPSBnZXRfcGxsKDApOw0KPiAr
CWlmIChtcGM4NXh4X2ZyZXFzID09IHAxMDIyX2ZyZXFzX3RhYmxlKQ0KPiArCQltYXhfcGxsWzFd
ID0gZ2V0X3BsbCgxKTsNCj4gKw0KPiArCXByX2luZm8oIkZyZWVzY2FsZSBNUEM4NXh4IENQVSBm
cmVxdWVuY3kgc3dpdGNoaW5nKEpPRykgZHJpdmVyXG4iKTsNCj4gKw0KPiArCXJldHVybiBjcHVm
cmVxX3JlZ2lzdGVyX2RyaXZlcigmbXBjODV4eF9jcHVmcmVxX2RyaXZlcik7DQo+ICt9DQo+ICsN
Cj4gK3N0YXRpYyBpbnQgbXBjODV4eF9qb2dfcmVtb3ZlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug
Km9mZGV2KSB7DQo+ICsJaW91bm1hcChndXRzKTsNCj4gKwljcHVmcmVxX3VucmVnaXN0ZXJfZHJp
dmVyKCZtcGM4NXh4X2NwdWZyZXFfZHJpdmVyKTsNCj4gKw0KPiArCXJldHVybiAwOw0KPiArfQ0K
PiArDQo+ICtzdGF0aWMgc3RydWN0IG9mX2RldmljZV9pZCBtcGM4NXh4X2pvZ19pZHNbXSA9IHsN
Cj4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxtcGM4NTM2LWd1dHMiLCB9LA0KPiArCXsgLmNvbXBh
dGlibGUgPSAiZnNsLHAxMDIyLWd1dHMiLCB9LA0KPiArCXt9DQo+ICt9Ow0KPiArDQo+ICtzdGF0
aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBtcGM4NXh4X2pvZ19kcml2ZXIgPSB7DQo+ICsJLmRy
aXZlciA9IHsNCj4gKwkJLm5hbWUgPSAibXBjODV4eF9jcHVmcmVxX2pvZyIsDQo+ICsJCS5vd25l
ciA9IFRISVNfTU9EVUxFLA0KPiArCQkub2ZfbWF0Y2hfdGFibGUgPSBtcGM4NXh4X2pvZ19pZHMs
DQo+ICsJfSwNCj4gKwkucHJvYmUgPSBtcGM4NXh4X2pvYl9wcm9iZSwNCj4gKwkucmVtb3ZlID0g
bXBjODV4eF9qb2dfcmVtb3ZlLA0KPiArfTsNCj4gKw0KPiArc3RhdGljIGludCBfX2luaXQgbXBj
ODV4eF9qb2dfaW5pdCh2b2lkKSB7DQo+ICsJcmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9yZWdpc3Rl
cigmbXBjODV4eF9qb2dfZHJpdmVyKTsNCj4gK30NCj4gKw0KPiArc3RhdGljIHZvaWQgX19leGl0
IG1wYzg1eHhfam9nX2V4aXQodm9pZCkgew0KPiArCXBsYXRmb3JtX2RyaXZlcl91bnJlZ2lzdGVy
KCZtcGM4NXh4X2pvZ19kcml2ZXIpOw0KPiArfQ0KPiArDQo+ICttb2R1bGVfaW5pdChtcGM4NXh4
X2pvZ19pbml0KTsNCj4gK21vZHVsZV9leGl0KG1wYzg1eHhfam9nX2V4aXQpOw0KPiArDQo+ICtN
T0RVTEVfTElDRU5TRSgiR1BMIik7DQo+ICtNT0RVTEVfQVVUSE9SKCJEYXZlIExpdSA8ZGF2ZWxp
dUBmcmVlc2NhbGUuY29tPiIpOw0KPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9jcHUuaCBi
L2luY2x1ZGUvbGludXgvY3B1LmggaW5kZXgNCj4gY2U3YTA3NC4uZGY4ZjczZCAxMDA2NDQNCj4g
LS0tIGEvaW5jbHVkZS9saW51eC9jcHUuaA0KPiArKysgYi9pbmNsdWRlL2xpbnV4L2NwdS5oDQo+
IEBAIC0xNDYsNiArMTQ2LDggQEAgdm9pZCBub3RpZnlfY3B1X3N0YXJ0aW5nKHVuc2lnbmVkIGlu
dCBjcHUpOyAgZXh0ZXJuDQo+IHZvaWQgY3B1X21hcHNfdXBkYXRlX2JlZ2luKHZvaWQpOyAgZXh0
ZXJuIHZvaWQgY3B1X21hcHNfdXBkYXRlX2RvbmUodm9pZCk7DQo+IA0KPiArZXh0ZXJuIHZvaWQg
Y3B1X2hvdHBsdWdfZGlzYWJsZV9iZWZvcmVfZnJlZXplKHZvaWQpOw0KPiArZXh0ZXJuIHZvaWQg
Y3B1X2hvdHBsdWdfZW5hYmxlX2FmdGVyX3RoYXcodm9pZCk7DQo+ICAjZWxzZQkvKiBDT05GSUdf
U01QICovDQo+IA0KPiAgI2RlZmluZSBjcHVfbm90aWZpZXIoZm4sIHByaSkJZG8geyAodm9pZCko
Zm4pOyB9IHdoaWxlICgwKQ0KPiBAQCAtMTY3LDYgKzE2OSw4IEBAIHN0YXRpYyBpbmxpbmUgdm9p
ZCBjcHVfbWFwc191cGRhdGVfZG9uZSh2b2lkKSAgeyAgfQ0KPiANCj4gK3N0YXRpYyBpbmxpbmUg
dm9pZCBjcHVfaG90cGx1Z19kaXNhYmxlX2JlZm9yZV9mcmVlemUodm9pZCkJe30NCj4gK3N0YXRp
YyBpbmxpbmUgdm9pZCBjcHVfaG90cGx1Z19lbmFibGVfYWZ0ZXJfdGhhdyh2b2lkKQl7fQ0KPiAg
I2VuZGlmIC8qIENPTkZJR19TTVAgKi8NCj4gIGV4dGVybiBzdHJ1Y3QgYnVzX3R5cGUgY3B1X3N1
YnN5czsNCj4gDQo+IGRpZmYgLS1naXQgYS9rZXJuZWwvY3B1LmMgYi9rZXJuZWwvY3B1LmMgaW5k
ZXggYjVlNGFiMi4uNmZkYzZkZiAxMDA2NDQNCj4gLS0tIGEva2VybmVsL2NwdS5jDQo+ICsrKyBi
L2tlcm5lbC9jcHUuYw0KPiBAQCAtNDU0LDYgKzQ1NCwzNiBAQCBvdXQ6DQo+ICB9DQo+ICBFWFBP
UlRfU1lNQk9MX0dQTChjcHVfdXApOw0KPiANCj4gKy8qDQo+ICsgKiBQcmV2ZW50IHJlZ3VsYXIg
Q1BVIGhvdHBsdWcgZnJvbSByYWNpbmcgd2l0aCB0aGUgZnJlZXplciwgYnkNCj4gK2Rpc2FibGlu
ZyBDUFUNCj4gKyAqIGhvdHBsdWcgd2hlbiB0YXNrcyBhcmUgYWJvdXQgdG8gYmUgZnJvemVuLiBB
bHNvLCBkb24ndCBhbGxvdyB0aGUNCj4gK2ZyZWV6ZXINCj4gKyAqIHRvIGNvbnRpbnVlIHVudGls
IGFueSBjdXJyZW50bHkgcnVubmluZyBDUFUgaG90cGx1ZyBvcGVyYXRpb24gZ2V0cw0KPiArICog
Y29tcGxldGVkLg0KPiArICogVG8gbW9kaWZ5IHRoZSAnY3B1X2hvdHBsdWdfZGlzYWJsZWQnIGZs
YWcsIHdlIG5lZWQgdG8gYWNxdWlyZSB0aGUNCj4gKyAqICdjcHVfYWRkX3JlbW92ZV9sb2NrJy4g
QW5kIHRoaXMgc2FtZSBsb2NrIGlzIGFsc28gdGFrZW4gYnkgdGhlDQo+ICtyZWd1bGFyDQo+ICsg
KiBDUFUgaG90cGx1ZyBwYXRoIGFuZCByZWxlYXNlZCBvbmx5IGFmdGVyIGl0IGlzIGNvbXBsZXRl
LiBUaHVzLCB3ZQ0KPiArICogKGFuZCBoZW5jZSB0aGUgZnJlZXplcikgd2lsbCBibG9jayBoZXJl
IHVudGlsIGFueSBjdXJyZW50bHkgcnVubmluZw0KPiArQ1BVDQo+ICsgKiBob3RwbHVnIG9wZXJh
dGlvbiBnZXRzIGNvbXBsZXRlZC4NCj4gKyAqLw0KPiArdm9pZCBjcHVfaG90cGx1Z19kaXNhYmxl
X2JlZm9yZV9mcmVlemUodm9pZCkNCj4gK3sNCj4gKwljcHVfbWFwc191cGRhdGVfYmVnaW4oKTsN
Cj4gKwljcHVfaG90cGx1Z19kaXNhYmxlZCA9IDE7DQo+ICsJY3B1X21hcHNfdXBkYXRlX2RvbmUo
KTsNCj4gK30NCj4gKw0KPiArDQo+ICsvKg0KPiArICogV2hlbiB0YXNrcyBoYXZlIGJlZW4gdGhh
d2VkLCByZS1lbmFibGUgcmVndWxhciBDUFUgaG90cGx1ZyAod2hpY2gNCj4gK2hhZCBiZWVuDQo+
ICsgKiBkaXNhYmxlZCB3aGlsZSBiZWdpbm5pbmcgdG8gZnJlZXplIHRhc2tzKS4NCj4gKyAqLw0K
PiArdm9pZCBjcHVfaG90cGx1Z19lbmFibGVfYWZ0ZXJfdGhhdyh2b2lkKQ0KPiArew0KPiArCWNw
dV9tYXBzX3VwZGF0ZV9iZWdpbigpOw0KPiArCWNwdV9ob3RwbHVnX2Rpc2FibGVkID0gMDsNCj4g
KwljcHVfbWFwc191cGRhdGVfZG9uZSgpOw0KPiArfQ0KPiArDQo+ICAjaWZkZWYgQ09ORklHX1BN
X1NMRUVQX1NNUA0KPiAgc3RhdGljIGNwdW1hc2tfdmFyX3QgZnJvemVuX2NwdXM7DQo+IA0KPiBA
QCAtNTQxLDM2ICs1NzEsNiBAQCBzdGF0aWMgaW50IF9faW5pdCBhbGxvY19mcm96ZW5fY3B1cyh2
b2lkKQ0KPiBjb3JlX2luaXRjYWxsKGFsbG9jX2Zyb3plbl9jcHVzKTsNCj4gDQo+ICAvKg0KPiAt
ICogUHJldmVudCByZWd1bGFyIENQVSBob3RwbHVnIGZyb20gcmFjaW5nIHdpdGggdGhlIGZyZWV6
ZXIsIGJ5DQo+IGRpc2FibGluZyBDUFUNCj4gLSAqIGhvdHBsdWcgd2hlbiB0YXNrcyBhcmUgYWJv
dXQgdG8gYmUgZnJvemVuLiBBbHNvLCBkb24ndCBhbGxvdyB0aGUNCj4gZnJlZXplcg0KPiAtICog
dG8gY29udGludWUgdW50aWwgYW55IGN1cnJlbnRseSBydW5uaW5nIENQVSBob3RwbHVnIG9wZXJh
dGlvbiBnZXRzDQo+IC0gKiBjb21wbGV0ZWQuDQo+IC0gKiBUbyBtb2RpZnkgdGhlICdjcHVfaG90
cGx1Z19kaXNhYmxlZCcgZmxhZywgd2UgbmVlZCB0byBhY3F1aXJlIHRoZQ0KPiAtICogJ2NwdV9h
ZGRfcmVtb3ZlX2xvY2snLiBBbmQgdGhpcyBzYW1lIGxvY2sgaXMgYWxzbyB0YWtlbiBieSB0aGUN
Cj4gcmVndWxhcg0KPiAtICogQ1BVIGhvdHBsdWcgcGF0aCBhbmQgcmVsZWFzZWQgb25seSBhZnRl
ciBpdCBpcyBjb21wbGV0ZS4gVGh1cywgd2UNCj4gLSAqIChhbmQgaGVuY2UgdGhlIGZyZWV6ZXIp
IHdpbGwgYmxvY2sgaGVyZSB1bnRpbCBhbnkgY3VycmVudGx5IHJ1bm5pbmcNCj4gQ1BVDQo+IC0g
KiBob3RwbHVnIG9wZXJhdGlvbiBnZXRzIGNvbXBsZXRlZC4NCj4gLSAqLw0KPiAtdm9pZCBjcHVf
aG90cGx1Z19kaXNhYmxlX2JlZm9yZV9mcmVlemUodm9pZCkNCj4gLXsNCj4gLQljcHVfbWFwc191
cGRhdGVfYmVnaW4oKTsNCj4gLQljcHVfaG90cGx1Z19kaXNhYmxlZCA9IDE7DQo+IC0JY3B1X21h
cHNfdXBkYXRlX2RvbmUoKTsNCj4gLX0NCj4gLQ0KPiAtDQo+IC0vKg0KPiAtICogV2hlbiB0YXNr
cyBoYXZlIGJlZW4gdGhhd2VkLCByZS1lbmFibGUgcmVndWxhciBDUFUgaG90cGx1ZyAod2hpY2gg
aGFkDQo+IGJlZW4NCj4gLSAqIGRpc2FibGVkIHdoaWxlIGJlZ2lubmluZyB0byBmcmVlemUgdGFz
a3MpLg0KPiAtICovDQo+IC12b2lkIGNwdV9ob3RwbHVnX2VuYWJsZV9hZnRlcl90aGF3KHZvaWQp
DQo+IC17DQo+IC0JY3B1X21hcHNfdXBkYXRlX2JlZ2luKCk7DQo+IC0JY3B1X2hvdHBsdWdfZGlz
YWJsZWQgPSAwOw0KPiAtCWNwdV9tYXBzX3VwZGF0ZV9kb25lKCk7DQo+IC19DQo+IC0NCj4gLS8q
DQo+ICAgKiBXaGVuIGNhbGxiYWNrcyBmb3IgQ1BVIGhvdHBsdWcgbm90aWZpY2F0aW9ucyBhcmUg
YmVpbmcgZXhlY3V0ZWQsIHdlDQo+IG11c3QNCj4gICAqIGVuc3VyZSB0aGF0IHRoZSBzdGF0ZSBv
ZiB0aGUgc3lzdGVtIHdpdGggcmVzcGVjdCB0byB0aGUgdGFza3MgYmVpbmcNCj4gZnJvemVuDQo+
ICAgKiBvciBub3QsIGFzIHJlcG9ydGVkIGJ5IHRoZSBub3RpZmljYXRpb24sIHJlbWFpbnMgdW5j
aGFuZ2VkDQo+ICp0aHJvdWdob3V0IHRoZQ0KPiAtLQ0KPiAxLjcuMw0KPiANCj4gDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IExpbnV4cHBjLWRl
diBtYWlsaW5nIGxpc3QNCj4gTGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gaHR0cHM6
Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4cHBjLWRldg0KDQo=
^ permalink raw reply
* [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
* [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
* 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 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: 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
* 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
* [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 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
* 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] [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 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 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: [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 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: [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 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
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