Mark,
On 30.07.14 16:46:26, Mark Rutland wrote:
diff --git a/arch/arm64/boot/dts/thunder-88xx.dts
b/arch/arm64/boot/dts/thunder-88xx.dts
new file mode 100644
index ..4cf20ac9138b
--- /dev/null
+++ b/arch/arm64/boot/dts/thunder-88xx.dts
@@ -0,0 +1,387 @@
+/*
+ *
Olof,
On 30.07.14 11:14:23, Olof Johansson wrote:
On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter r...@kernel.org wrote:
From: Radha Mohan Chintakuntla rchintakun...@cavium.com
Add initial device tree nodes for Cavium Thunder SoCs with support of
48 cores and gicv3. The dts file requires
Mark,
On 31.07.14 12:33:01, Mark Rutland wrote:
On Thu, Jul 31, 2014 at 12:12:33PM +0100, Ganapatrao Kulkarni wrote:
We mark RAM used by ATF as secure-RAM, however we don't support
secure/non-secure address aliasing.
i.e, a DRAM address that can be referenced from both a secure PA
On 31.07.14 10:22:19, Rob Herring wrote:
> On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter wrote:
> > On 30.07.14 11:37:38, Rob Herring wrote:
> >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland
> >> wrote:
> >> > On Wed, Jul 30, 2014 at 04:06:31PM +0
On 30.07.14 11:37:38, Rob Herring wrote:
> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland wrote:
> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote:
> >> From: Radha Mohan Chintakuntla
> >> +/ {
> >> + model = "Cavium ThunderX CN88XX
On 31.07.14 12:24:13, Arnd Bergmann wrote:
> On Wednesday 30 July 2014, Robert Richter wrote:
> > +/*
> > + * Cavium Thunder DTS file
> > + *
> > + * Copyright (C) 2013, Cavium Inc.
> > + *
> > + * This program is free software; you can redistribute it a
Rob and Arnd,
On 30.07.14 11:37:38, Rob Herring wrote:
> >> +/*
> >> + * Cavium Thunder DTS file
> >> + *
> >> + * Copyright (C) 2013, Cavium Inc.
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License
Rob and Arnd,
On 30.07.14 11:37:38, Rob Herring wrote:
+/*
+ * Cavium Thunder DTS file
+ *
+ * Copyright (C) 2013, Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by
On 31.07.14 12:24:13, Arnd Bergmann wrote:
On Wednesday 30 July 2014, Robert Richter wrote:
+/*
+ * Cavium Thunder DTS file
+ *
+ * Copyright (C) 2013, Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General
On 30.07.14 11:37:38, Rob Herring wrote:
On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote:
From: Radha Mohan Chintakuntla rchintakun...@cavium.com
+/ {
+ model = Cavium ThunderX CN88XX Family
On 31.07.14 10:22:19, Rob Herring wrote:
On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter r...@kernel.org wrote:
On 30.07.14 11:37:38, Rob Herring wrote:
On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland mark.rutl...@arm.com
wrote:
On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter
From: Robert Richter
This patch enables Thunder SoCs in the arm64 defconfig. This is
esp. useful to add Thunder platforms to automated builds based on
arm64 defconfig.
Signed-off-by: Robert Richter
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64
From: Radha Mohan Chintakuntla
This patch adds documentation for the devicetree bindings used by the
DT files of Cavium Thunder SoC platforms.
Signed-off-by: Radha Mohan Chintakuntla
Signed-off-by: Robert Richter
---
Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10
Chintakuntla
Signed-off-by: Robert Richter
---
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/thunder-88xx.dts | 387 +++
2 files changed, 388 insertions(+)
create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
diff --git a/arch/arm64/boot/dts
From: Robert Richter
Making it more convinient to run the arm64 default kernel as distros
like Ubuntu need this option.
Signed-off-by: Robert Richter
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs
From: Radha Mohan Chintakuntla
Increase maximum numbers of cpus to 32. This relates to current
maximal possible cpu number. Increasing this to 64 cpus will be a
separate patch not part of this enablement patches.
Signed-off-by: Radha Mohan Chintakuntla
Signed-off-by: Robert Richter
---
arch
From: Robert Richter
This initial patches enable Cavium Thunder SoC Family. The patches add
Kconfig and devicetree support and then add Thunder to the defconfig.
The last patch is unrelated to Thunder and enables the tmpfs mount
option for a more convinient use of defconfig with distros
From: Robert Richter rrich...@cavium.com
This initial patches enable Cavium Thunder SoC Family. The patches add
Kconfig and devicetree support and then add Thunder to the defconfig.
The last patch is unrelated to Thunder and enables the tmpfs mount
option for a more convinient use of defconfig
From: Robert Richter rrich...@cavium.com
Making it more convinient to run the arm64 default kernel as distros
like Ubuntu need this option.
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs
...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/Kconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a474de346be6..e989d8cab8c7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -128,6 +128,11 @@ source
-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/thunder-88xx.dts | 387 +++
2 files changed, 388 insertions(+)
create mode 100644 arch
From: Radha Mohan Chintakuntla rchintakun...@cavium.com
This patch adds documentation for the devicetree bindings used by the
DT files of Cavium Thunder SoC platforms.
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
From: Robert Richter rrich...@cavium.com
This patch enables Thunder SoCs in the arm64 defconfig. This is
esp. useful to add Thunder platforms to automated builds based on
arm64 defconfig.
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1
On 22.07.14 21:59:41, Chen, Gong wrote:
> Remove XXX_FROZEN state from oprofile/timer_int.
>
> Signed-off-by: Chen, Gong
Acked-by: Robert Richter
> ---
> drivers/oprofile/timer_int.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/driver
On 27.07.14 02:36:43, Chen, Gong wrote:
> On Fri, Jul 25, 2014 at 05:00:02PM +0200, Robert Richter wrote:
> > > Back to long time ago (about 1.5 years), Thomas began the work
> > > for CPU hot-plug, one first thing is CPU hotplug flag cleanup.
> > > Paul
On 27.07.14 02:36:43, Chen, Gong wrote:
On Fri, Jul 25, 2014 at 05:00:02PM +0200, Robert Richter wrote:
Back to long time ago (about 1.5 years), Thomas began the work
for CPU hot-plug, one first thing is CPU hotplug flag cleanup.
Paul hoped all the _FROZEN variants of the notifier
On 22.07.14 21:59:41, Chen, Gong wrote:
Remove XXX_FROZEN state from oprofile/timer_int.
Signed-off-by: Chen, Gong gong.c...@linux.intel.com
Acked-by: Robert Richter r...@kernel.org
---
drivers/oprofile/timer_int.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
On 22.07.14 21:58:36, Chen, Gong wrote:
> Back to long time ago (about 1.5 years), Thomas began the work
> for CPU hot-plug, one first thing is CPU hotplug flag cleanup.
> Paul hoped all the _FROZEN variants of the notifier actions
> can be removed at that time. Now here it is.
>
> Patch 1 ~ 69:
On 22.07.14 21:58:36, Chen, Gong wrote:
Back to long time ago (about 1.5 years), Thomas began the work
for CPU hot-plug, one first thing is CPU hotplug flag cleanup.
Paul hoped all the _FROZEN variants of the notifier actions
can be removed at that time. Now here it is.
Patch 1 ~ 69: remove
On 18.07.14 19:28:50, Tejun Heo wrote:
> On Fri, Jun 20, 2014 at 02:31:22PM -0500, Christoph Lameter wrote:
> > Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr.
> >
> > Cc: Robert Richter
> > Cc: oprofile-l...@lists.sf.net
> >
On 18.07.14 19:28:50, Tejun Heo wrote:
On Fri, Jun 20, 2014 at 02:31:22PM -0500, Christoph Lameter wrote:
Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr.
Cc: Robert Richter r...@kernel.org
Cc: oprofile-l...@lists.sf.net
Signed-off-by: Christoph Lameter c
On 30.06.14 12:01:15, Borislav Petkov wrote:
> Well, do you have it as a standalong program? If so, you can put it in
> a repo somewhere and we can start hacking away and playing with it. If
> not, we will have to copy the perf code *into* the RAS daemon first so
> that we can have a separate
On 30.06.14 12:01:15, Borislav Petkov wrote:
Well, do you have it as a standalong program? If so, you can put it in
a repo somewhere and we can start hacking away and playing with it. If
not, we will have to copy the perf code *into* the RAS daemon first so
that we can have a separate source
On 12.06.14 16:01:20, Borislav Petkov wrote:
> Additionally, if you'd like, we could sync among each other on who does
> what. Maybe Robert would like to help too.
As long as I stick with the persistent event kernel patches I don't
think I will have the time to work on further userspace changes.
On 13.06.14 13:02:57, Tomasz Nowicki wrote:
> Currently APEI depends on x86 architecture. It is because of NMI hardware
> error notification of GHES which is currently supported by x86 only.
> However, many other APEI features can be still used perfectly by other
> architectures.
>
> This commit
On 13.06.14 13:02:56, Tomasz Nowicki wrote:
> This commit abstracts MCE calls and provides weak corresponding default
> implementation for those architectures which do not need arch specific
> actions. Each platform willing to do additional architectural actions
> should provides desired function
On 11.06.14 18:41:44, Alexander Shishkin wrote:
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 853bc1c..ef95af4 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -488,9 +488,14 @@ struct perf_event_mmap_page {
>
On 13.06.14 13:03:00, Tomasz Nowicki wrote:
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 21aeac5..93a4d0b 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -113,12 +113,11 @@ static DEFINE_RAW_SPINLOCK(ghes_nmi_lock);
> */
>
> /*
> - *
On 13.06.14 13:02:59, Tomasz Nowicki wrote:
> Similar to MCE related patch, all NMI architectural calls are abstracted.
> Also, we are providing corresponding X86 functions' content.
We don't need to abstract nmi calls for archs that don't support
nmis. Just disable the code with #ifdefs
On 13.06.14 13:02:55, Tomasz Nowicki wrote:
> V2->V3
> - address Robert's comment
> - disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig
> - rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI
Btw, it would be easier to wait a bit with reposting a new patch set
until there are
On 13.06.14 13:02:58, Tomasz Nowicki wrote:
> @@ -811,6 +819,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> pt_regs *regs)
> int sev, sev_global = -1;
> int ret = NMI_DONE;
>
> + BUG_ON(!IS_ENABLED(ARCH_HAS_ACPI_APEI_NMI));
> +
Now that we have the
On 13.06.14 13:02:58, Tomasz Nowicki wrote:
@@ -811,6 +819,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
int sev, sev_global = -1;
int ret = NMI_DONE;
+ BUG_ON(!IS_ENABLED(ARCH_HAS_ACPI_APEI_NMI));
+
Now that we have the ARCH_HAS_ACPI_APEI_NMI
On 13.06.14 13:02:55, Tomasz Nowicki wrote:
V2-V3
- address Robert's comment
- disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig
- rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI
Btw, it would be easier to wait a bit with reposting a new patch set
until there are no
On 13.06.14 13:02:59, Tomasz Nowicki wrote:
Similar to MCE related patch, all NMI architectural calls are abstracted.
Also, we are providing corresponding X86 functions' content.
We don't need to abstract nmi calls for archs that don't support
nmis. Just disable the code with #ifdefs depending
On 13.06.14 13:03:00, Tomasz Nowicki wrote:
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 21aeac5..93a4d0b 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -113,12 +113,11 @@ static DEFINE_RAW_SPINLOCK(ghes_nmi_lock);
*/
/*
- * Two
On 11.06.14 18:41:44, Alexander Shishkin wrote:
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 853bc1c..ef95af4 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -488,9 +488,14 @@ struct perf_event_mmap_page {
On 13.06.14 13:02:56, Tomasz Nowicki wrote:
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do additional architectural actions
should provides desired function
On 13.06.14 13:02:57, Tomasz Nowicki wrote:
Currently APEI depends on x86 architecture. It is because of NMI hardware
error notification of GHES which is currently supported by x86 only.
However, many other APEI features can be still used perfectly by other
architectures.
This commit adds
On 12.06.14 16:01:20, Borislav Petkov wrote:
Additionally, if you'd like, we could sync among each other on who does
what. Maybe Robert would like to help too.
As long as I stick with the persistent event kernel patches I don't
think I will have the time to work on further userspace changes.
On 28.05.14 09:39:27, Tomasz Nowicki wrote:
> +config ACPI_APEI_NMI
> + bool "NMI error notification support"
> + default y
> + depends on ACPI_APEI_GHES && X86
> + help
> + Firmware first mode can use NMI notification mechanism to report
> errors
> + to operating
On 28.05.14 09:39:26, Tomasz Nowicki wrote:
> This commit abstracts MCE calls and provides weak corresponding default
> implementation for those architectures which do not need arch specific
> actions. Each platform willing to do additional architectural actions
> should provides desired function
On 28.05.14 09:39:26, Tomasz Nowicki wrote:
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do additional architectural actions
should provides desired function
On 28.05.14 09:39:27, Tomasz Nowicki wrote:
+config ACPI_APEI_NMI
+ bool NMI error notification support
+ default y
+ depends on ACPI_APEI_GHES X86
+ help
+ Firmware first mode can use NMI notification mechanism to report
errors
+ to operating system. This
On 23.05.14 07:01:41, Bjorn Helgaas wrote:
> [I guess I've been using the wrong term here. I think "ECS" just
> refers to the extended config space itself, and I should have been
> saying "IO ECS" or "EnableCf8ExtCfg".]
>
> My understanding was that if we don't enable IO ECS and we don't have
>
On 22.05.14 20:54:54, Bjorn Helgaas wrote:
> I'm going to go out on a limb and guess that Windows does not enable
> ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing
> of MCFG is broken in some way, and we probably *could* use ECAM in all
> these cases I'm seeing.
Even if ECS
On 22.05.14 20:54:54, Bjorn Helgaas wrote:
I'm going to go out on a limb and guess that Windows does not enable
ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing
of MCFG is broken in some way, and we probably *could* use ECAM in all
these cases I'm seeing.
Even if ECS is
On 23.05.14 07:01:41, Bjorn Helgaas wrote:
[I guess I've been using the wrong term here. I think ECS just
refers to the extended config space itself, and I should have been
saying IO ECS or EnableCf8ExtCfg.]
My understanding was that if we don't enable IO ECS and we don't have
MCFG, we
On 15.05.14 18:08:29, Alexander Shishkin wrote:
> @@ -488,9 +488,14 @@ struct perf_event_mmap_page {
>* In this case the kernel will not over-write unread data.
>*
>* See perf_output_put_handle() for the data ordering.
> + *
> + * data_{offset,size} indicate the
On 15.05.14 18:08:30, Alexander Shishkin wrote:
> From: Peter Zijlstra
>
> This patch introduces "AUX space" in the perf mmap buffer, intended for
> exporting high bandwidth data streams to userspace, such as instruction
> flow traces.
>
> AUX space is a ring buffer, defined by
On 15.05.14 18:08:30, Alexander Shishkin wrote:
From: Peter Zijlstra pet...@infradead.org
This patch introduces AUX space in the perf mmap buffer, intended for
exporting high bandwidth data streams to userspace, such as instruction
flow traces.
AUX space is a ring buffer, defined by
On 15.05.14 18:08:29, Alexander Shishkin wrote:
@@ -488,9 +488,14 @@ struct perf_event_mmap_page {
* In this case the kernel will not over-write unread data.
*
* See perf_output_put_handle() for the data ordering.
+ *
+ * data_{offset,size} indicate the
On 08.05.14 20:23:44, Borislav Petkov wrote:
> On Wed, May 07, 2014 at 06:44:07PM +0200, Robert Richter wrote:
> > With transparently I mean that the process even does not know that the
> > same event is already running by another process. The kernel detects
> > this
On 08.05.14 20:36:29, Borislav Petkov wrote:
> On Wed, May 07, 2014 at 07:01:55PM +0200, Robert Richter wrote:
> > For general-purpose... Why 512k buffers are ok? Depending on the
> > event, smaller buffers are maybe good enough, esp. since they are
> > permanently enabled and
On 08.05.14 20:36:29, Borislav Petkov wrote:
On Wed, May 07, 2014 at 07:01:55PM +0200, Robert Richter wrote:
For general-purpose... Why 512k buffers are ok? Depending on the
event, smaller buffers are maybe good enough, esp. since they are
permanently enabled and use system resources
On 08.05.14 20:23:44, Borislav Petkov wrote:
On Wed, May 07, 2014 at 06:44:07PM +0200, Robert Richter wrote:
With transparently I mean that the process even does not know that the
same event is already running by another process. The kernel detects
this and maps the request to that event
On 08.05.14 10:21:07, Suravee Suthikulanit wrote:
> The reason I put it all these comments here is because it took us a while to
> discuss what to do with this file going forward. There were some confusions.
> Therefore, I just want to document it here.
>
> Also, the check for (boot_cpu_data.x86
On 08.05.14 09:39:55, Suravee Suthikulanit wrote:
> On 5/8/2014 4:01 AM, Robert Richter wrote:
> >On 08.05.14 10:59:05, Robert Richter wrote:
> >>On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
> >>>@@ -113,10 +122,17 @@ static int __in
On 08.05.14 10:59:05, Robert Richter wrote:
> On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
> > @@ -113,10 +122,17 @@ static int __init early_fill_mp_bus_info(void)
> > info = alloc_pci_root_info(min_bus, max_
On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
> @@ -113,10 +122,17 @@ static int __init early_fill_mp_bus_info(void)
> info = alloc_pci_root_info(min_bus, max_bus, node, link);
> }
>
> + /*
> + * The following code is only supported until Fam11h.
> +
On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
@@ -113,10 +122,17 @@ static int __init early_fill_mp_bus_info(void)
info = alloc_pci_root_info(min_bus, max_bus, node, link);
}
+ /*
+ * The following code is only supported until Fam11h.
+ *
On 08.05.14 10:59:05, Robert Richter wrote:
On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
@@ -113,10 +122,17 @@ static int __init early_fill_mp_bus_info(void)
info = alloc_pci_root_info(min_bus, max_bus, node, link);
}
+ /*
+* The following code
On 08.05.14 09:39:55, Suravee Suthikulanit wrote:
On 5/8/2014 4:01 AM, Robert Richter wrote:
On 08.05.14 10:59:05, Robert Richter wrote:
On 07.05.14 13:58:45, suravee.suthikulpa...@amd.com wrote:
@@ -113,10 +122,17 @@ static int __init early_fill_mp_bus_info(void)
info
On 08.05.14 10:21:07, Suravee Suthikulanit wrote:
The reason I put it all these comments here is because it took us a while to
discuss what to do with this file going forward. There were some confusions.
Therefore, I just want to document it here.
Also, the check for (boot_cpu_data.x86
On 06.05.14 20:58:26, Borislav Petkov wrote:
> On Tue, May 06, 2014 at 02:39:07PM +0200, Robert Richter wrote:
> > I rather would change the ioctl to
> >
> > id = ioctl(PERF_EVENT_IOC_SET_PERSIST, arg);
> >
> > arg != 0: create persistent event (unclaim)
On 06.05.14 20:53:59, Borislav Petkov wrote:
> On Tue, May 06, 2014 at 02:39:07PM +0200, Robert Richter wrote:
> > Events could also be shared transparently. This means, if there is
> > already an event running with the same attr, it could be reused. Not
> > sure if
On 06.05.14 20:53:59, Borislav Petkov wrote:
On Tue, May 06, 2014 at 02:39:07PM +0200, Robert Richter wrote:
Events could also be shared transparently. This means, if there is
already an event running with the same attr, it could be reused. Not
sure if this makes sense much and is also
On 06.05.14 20:58:26, Borislav Petkov wrote:
On Tue, May 06, 2014 at 02:39:07PM +0200, Robert Richter wrote:
I rather would change the ioctl to
id = ioctl(PERF_EVENT_IOC_SET_PERSIST, arg);
arg != 0: create persistent event (unclaim)
arg == 0: delete persistent event (claim
> Robert Richter :
> This patch set implements the necessary kernel changes for persistent
> events.
I was reviewing the code again after a while. It demonstrates how
persistent events can be used esp. for kernel enabled tracing. It also
allows people to play with it. The initial
Robert Richter r...@kernel.org:
This patch set implements the necessary kernel changes for persistent
events.
I was reviewing the code again after a while. It demonstrates how
persistent events can be used esp. for kernel enabled tracing. It also
allows people to play with it. The initial use
On 30.04.14 02:50:21, Suravee Suthikulpanit wrote:
> Actually, if ECS is needed by IBS, then wouldn't this still be needed for
> every family since 10h and later (except family11h).
Yes, but you have stated that pci mmconfig should work on families >
10h. Thus, ECS would work there out-of-the-box
On 29.04.14 15:40:28, Myron Stowe wrote:
> On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote:
> > So sounds to me like we want to get rid of the whole IO ECS deal
> > altogether then.
> >
> > Now, I'm wondering whether we should kill it completely since I don't
> > think anyone cares about
On 18.04.14 20:53:23, Myron Stowe wrote:
> From: Suravee Suthikulpanit
> - start = reg & 0xff00; /* 39:16 on 31:8*/
> - start <<= 8;
> - reg = read_pci_config(bus, slot, 1, 0x84 + (i << 3));
> + start = (reg & 0xff00UL) << 8; /* 39:16
On 18.04.14 20:53:23, Myron Stowe wrote:
From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
- start = reg 0xff00; /* 39:16 on 31:8*/
- start = 8;
- reg = read_pci_config(bus, slot, 1, 0x84 + (i 3));
+ start = (reg 0xff00UL)
On 29.04.14 15:40:28, Myron Stowe wrote:
On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov b...@alien8.de wrote:
So sounds to me like we want to get rid of the whole IO ECS deal
altogether then.
Now, I'm wondering whether we should kill it completely since I don't
think anyone cares
On 30.04.14 02:50:21, Suravee Suthikulpanit wrote:
Actually, if ECS is needed by IBS, then wouldn't this still be needed for
every family since 10h and later (except family11h).
Yes, but you have stated that pci mmconfig should work on families
10h. Thus, ECS would work there out-of-the-box
In addition to Boris I have the following:
On 18.04.14 20:53:23, Myron Stowe wrote:
> +#define AMD_PCIE_CF8(bus, dev, fn, reg) \
> + (0x8000 | \
> + ((reg & 0xF00) << 16) | \
> + ((bus & 0xF) << 16) | \
> + ((dev
On 25.04.14 16:52:05, Peter Zijlstra wrote:
> But no, I don't think that helps, its still true that the moment you get
> a fd another thread can immediately close(). That would drop the last
> ref and free it, meanwhile perf_event_open() is happily poking at it.
>
> Now I think you could cure
On 29.04.14 09:33:09, Andreas Herrmann wrote:
> On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
> > On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
> > > This I/O ECS thing seems likely to cause future problems. My
> > > understanding (based on sec 2.8 of [1]) is
On 29.04.14 09:22:20, Masanari Iida wrote:
> Fix format string mismatch in oprofile_perf_create_files.
Please provide a compiler warning.
>
> Signed-off-by: Masanari Iida
> ---
> drivers/oprofile/oprofile_perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 29.04.14 09:22:20, Masanari Iida wrote:
Fix format string mismatch in oprofile_perf_create_files.
Please provide a compiler warning.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/oprofile/oprofile_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 29.04.14 09:33:09, Andreas Herrmann wrote:
On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
This I/O ECS thing seems likely to cause future problems. My
understanding (based on sec 2.8 of [1]) is that
On 25.04.14 16:52:05, Peter Zijlstra wrote:
But no, I don't think that helps, its still true that the moment you get
a fd another thread can immediately close(). That would drop the last
ref and free it, meanwhile perf_event_open() is happily poking at it.
Now I think you could cure this by
In addition to Boris I have the following:
On 18.04.14 20:53:23, Myron Stowe wrote:
+#define AMD_PCIE_CF8(bus, dev, fn, reg) \
+ (0x8000 | \
+ ((reg 0xF00) 16) | \
+ ((bus 0xF) 16) | \
+ ((dev 0x1F) 11)
On 22.04.14 16:27:59, Peter Zijlstra wrote:
> On Mon, Apr 07, 2014 at 05:04:26PM +0200, Jean Pihet wrote:
> > From: Robert Richter
> >
> > This new function creates a new fd for an event. We need this later to
> > get a fd from a persistent event.
> >
On 22.04.14 16:27:59, Peter Zijlstra wrote:
On Mon, Apr 07, 2014 at 05:04:26PM +0200, Jean Pihet wrote:
From: Robert Richter robert.rich...@linaro.org
This new function creates a new fd for an event. We need this later to
get a fd from a persistent event.
Signed-off-by: Robert
Commit-ID: bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6
Gitweb: http://git.kernel.org/tip/bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6
Author: Robert Richter
AuthorDate: Wed, 15 Jan 2014 15:57:29 +0100
Committer: Ingo Molnar
CommitDate: Thu, 16 Jan 2014 09:19:50 +0100
perf/x86/amd/ibs: Fix
(cc'ing Will)
Weng,
thanks for testing.
On 16.01.14 17:33:04, Weng Meiling wrote:
> Using the same test case, the problem also exists in the same kernel with the
> new patch applied:
>
>
> # opcontrol --start
>
> Using 2.6+ OProfile kernel interface.
> Using log file
(cc'ing Will)
Weng,
thanks for testing.
On 16.01.14 17:33:04, Weng Meiling wrote:
Using the same test case, the problem also exists in the same kernel with the
new patch applied:
# opcontrol --start
Using 2.6+ OProfile kernel interface.
Using log file
Commit-ID: bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6
Gitweb: http://git.kernel.org/tip/bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6
Author: Robert Richter r...@kernel.org
AuthorDate: Wed, 15 Jan 2014 15:57:29 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 16 Jan 2014 09:19:50
On 15.01.14 15:57:29, Robert Richter wrote:
> @@ -816,6 +817,18 @@ static int force_ibs_eilvt_setup(void)
> return ret;
> }
>
> +void ibs_eilvt_setup(void)
Grrr, this is not static. Could this be changed when the patch is
applied assuming the rest is ok? Otherwise I will
1001 - 1100 of 1735 matches
Mail list logo
