Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

On 20.11.16 17:07:44, Ard Biesheuvel wrote: > On 17 November 2016 at 15:18, Robert Richter > wrote: > > The risk of breaking something with my patch is small and limited only > > to the mapping of efi reserved regions (which is the state of 4.4). If > > something bre

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Thanks for your answer. On 17.11.16 14:25:29, Will Deacon wrote: > On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote: > > Thus, I don't see where my patch breaks code. Even acpi_os_ioremap() > > keeps the same behaviour as before since it still uses memblock_is_ >

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Thanks for your answer. On 17.11.16 14:25:29, Will Deacon wrote: > On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote: > > Thus, I don't see where my patch breaks code. Even acpi_os_ioremap() > > keeps the same behaviour as before since it still uses memblock_is_ >

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Will, On 07.11.16 21:05:14, Will Deacon wrote: > Just to reiterate here, but your patch as it stands will break other parts > of the kernel. For example, acpi_os_ioremap relies on being able to ioremap > these regions afaict. > > I think any solution involving pfn_valid is just going to move the

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Will, On 07.11.16 21:05:14, Will Deacon wrote: > Just to reiterate here, but your patch as it stands will break other parts > of the kernel. For example, acpi_os_ioremap relies on being able to ioremap > these regions afaict. > > I think any solution involving pfn_valid is just going to move the

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On 08.11.16 19:27:39, Peter Zijlstra wrote: > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > the counter mask of such an event is not a subset of any other counter > mask of a constraint with an equal or higher weight". > > Esp. that latter part is of interest here I

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On 08.11.16 19:27:39, Peter Zijlstra wrote: > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > the counter mask of such an event is not a subset of any other counter > mask of a constraint with an equal or higher weight". > > Esp. that latter part is of interest here I

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

On 06.10.16 11:52:07, Robert Richter wrote: > There is a memory setup problem on ThunderX systems with certain > memory configurations. The symptom is > > kernel BUG at mm/page_alloc.c:1848! > > This happens for some configs with 64k page size enabled. The bug > tr

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

On 06.10.16 11:52:07, Robert Richter wrote: > There is a memory setup problem on ThunderX systems with certain > memory configurations. The symptom is > > kernel BUG at mm/page_alloc.c:1848! > > This happens for some configs with 64k page size enabled. The bug > tr

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

On 27.10.16 17:01:36, Will Deacon wrote: > Hi Robert, > > On Mon, Oct 17, 2016 at 08:58:01PM +0200, Robert Richter wrote: > > Mark, Will, any opinion here? > > Having looking at this, I'm inclined to agree with you; pfn_valid() is > all about whether the underlying mem_m

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

On 27.10.16 17:01:36, Will Deacon wrote: > Hi Robert, > > On Mon, Oct 17, 2016 at 08:58:01PM +0200, Robert Richter wrote: > > Mark, Will, any opinion here? > > Having looking at this, I'm inclined to agree with you; pfn_valid() is > all about whether the underlying mem_m

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

There has been some significant rework around __alloc_pages_nodemask(), adding Mel and linux-mm. -Robert On 26.10.16 10:00:02, David Daney wrote: > On 10/26/2016 06:43 AM, Robert Richter wrote: > >On 25.10.16 14:31:00, David Daney wrote: > >>From: David Daney <d

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

There has been some significant rework around __alloc_pages_nodemask(), adding Mel and linux-mm. -Robert On 26.10.16 10:00:02, David Daney wrote: > On 10/26/2016 06:43 AM, Robert Richter wrote: > >On 25.10.16 14:31:00, David Daney wrote: > >>From: David Daney > >> &

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

On 25.10.16 14:31:00, David Daney wrote: > From: David Daney > > On arm64 NUMA kernels we can pass "numa=off" on the command line to > disable NUMA. A side effect of this is that kmalloc_node() calls to > non-zero nodes will crash the system with an OOPS: > > [

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

On 25.10.16 14:31:00, David Daney wrote: > From: David Daney > > On arm64 NUMA kernels we can pass "numa=off" on the command line to > disable NUMA. A side effect of this is that kmalloc_node() calls to > non-zero nodes will crash the system with an OOPS: > > [0.00] []

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

> On Thu, Oct 06, 2016 at 06:11:14PM +0200, Robert Richter wrote: > > On 06.10.16 11:00:33, Ard Biesheuvel wrote: > > > On 6 October 2016 at 10:52, Robert Richter <rrich...@cavium.com> wrote: > > > > There is a memory setup problem on ThunderX systems with

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

> On Thu, Oct 06, 2016 at 06:11:14PM +0200, Robert Richter wrote: > > On 06.10.16 11:00:33, Ard Biesheuvel wrote: > > > On 6 October 2016 at 10:52, Robert Richter wrote: > > > > There is a memory setup problem on ThunderX systems with certain > > > > memo

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Mark, Will, any opinion here? Thanks, -Robert On 06.10.16 18:11:14, Robert Richter wrote: > Ard, > > thank you for your answer and you explanation. > > On 06.10.16 11:00:33, Ard Biesheuvel wrote: > > On 6 October 2016 at 10:52, Robert Richter <rr

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Mark, Will, any opinion here? Thanks, -Robert On 06.10.16 18:11:14, Robert Richter wrote: > Ard, > > thank you for your answer and you explanation. > > On 06.10.16 11:00:33, Ard Biesheuvel wrote: > > On 6 October 2016 at 10:52, Robert Richter wrote: > > > T

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Ard, thank you for your answer and you explanation. On 06.10.16 11:00:33, Ard Biesheuvel wrote: > On 6 October 2016 at 10:52, Robert Richter <rrich...@cavium.com> wrote: > > There is a memory setup problem on ThunderX systems with certain > > memory configurations. The sympt

Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

Ard, thank you for your answer and you explanation. On 06.10.16 11:00:33, Ard Biesheuvel wrote: > On 6 October 2016 at 10:52, Robert Richter wrote: > > There is a memory setup problem on ThunderX systems with certain > > memory configurations. The symptom is > >

[PATCH] arm64: mm: Fix memmap to be initialized for the entire section

memblock_is_map_memory() where necessary. This only affects code in ioremap.c. The code in mmu.c still can use the new version of pfn_valid(). Should be marked stable v4.5.. Signed-off-by: Robert Richter <rrich...@cavium.com> --- arch/arm64/mm/init.c| 2 +- arch/arm64/mm/ioremap

[PATCH] arm64: mm: Fix memmap to be initialized for the entire section

memblock_is_map_memory() where necessary. This only affects code in ioremap.c. The code in mmu.c still can use the new version of pfn_valid(). Should be marked stable v4.5.. Signed-off-by: Robert Richter --- arch/arm64/mm/init.c| 2 +- arch/arm64/mm/ioremap.c | 5 +++-- 2 files changed, 4

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 27.09.16 14:26:08, Hanjun Guo wrote: > On 09/20/2016 09:21 PM, Robert Richter wrote: > >On 20.09.16 19:32:34, Hanjun Guo wrote: > >>On 09/20/2016 06:43 PM, Robert Richter wrote: > > > >>>Unfortunately either your nor my code does fix the BUG_

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 27.09.16 14:26:08, Hanjun Guo wrote: > On 09/20/2016 09:21 PM, Robert Richter wrote: > >On 20.09.16 19:32:34, Hanjun Guo wrote: > >>On 09/20/2016 06:43 PM, Robert Richter wrote: > > > >>>Unfortunately either your nor my code does fix the BUG_

Re: [PATCH] arm64: Call numa_store_cpu_info() earlier.

n call, > simplify by removing the function and out-lining its contents. > > Suggested-by: Robert Richter <r...@kernel.org> > fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") > Cc: <sta...@vger.kernel.org> # 4.7.x- > Signed-off-by

Re: [PATCH] arm64: Call numa_store_cpu_info() earlier.

ng the function and out-lining its contents. > > Suggested-by: Robert Richter > fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") > Cc: # 4.7.x- > Signed-off-by: David Daney > --- > arch/arm64/kernel/smp.c | 14 ++ > 1 fil

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 20.09.16 19:32:34, Hanjun Guo wrote: > On 09/20/2016 06:43 PM, Robert Richter wrote: > >Instead we need to make sure the set_*numa_node() functions are called > >earlier before secondary cpus are booted. My suggested change for that > >is this: > > > > > >

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 20.09.16 19:32:34, Hanjun Guo wrote: > On 09/20/2016 06:43 PM, Robert Richter wrote: > >Instead we need to make sure the set_*numa_node() functions are called > >earlier before secondary cpus are booted. My suggested change for that > >is this: > > > > > >

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 20.09.16 19:32:34, Hanjun Guo wrote: > On 09/20/2016 06:43 PM, Robert Richter wrote: > >Unfortunately either your nor my code does fix the BUG_ON() I see with > >the numa kernel: > > > > kernel BUG at mm/page_alloc.c:1848! > > > >See below for the co

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

On 20.09.16 19:32:34, Hanjun Guo wrote: > On 09/20/2016 06:43 PM, Robert Richter wrote: > >Unfortunately either your nor my code does fix the BUG_ON() I see with > >the numa kernel: > > > > kernel BUG at mm/page_alloc.c:1848! > > > >See below for the co

[PATCH] irqchip, gicv3: Fix out-of-range cpumask access reported by cpumask_check()

() might be reworked at all in a way that a single each-cpu loop is used by squashing it with gic_compute_target_list(). Signed-off-by: Robert Richter <rrich...@cavium.com> --- drivers/irqchip/irq-gic-v3.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/irq-gic-v3.c b/d

[PATCH] irqchip, gicv3: Fix out-of-range cpumask access reported by cpumask_check()

() might be reworked at all in a way that a single each-cpu loop is used by squashing it with gic_compute_target_list(). Signed-off-by: Robert Richter --- drivers/irqchip/irq-gic-v3.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

David, On 19.09.16 11:49:30, David Daney wrote: > Fix by supplying a cpu_to_node() implementation that returns correct > node mappings. > +int cpu_to_node(int cpu) > +{ > + int nid; > + > + /* > + * Return 0 for unknown mapping so that we report something > + * sensible if

Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.

David, On 19.09.16 11:49:30, David Daney wrote: > Fix by supplying a cpu_to_node() implementation that returns correct > node mappings. > +int cpu_to_node(int cpu) > +{ > + int nid; > + > + /* > + * Return 0 for unknown mapping so that we report something > + * sensible if

Re: [PATCH 2/6] oprofile/x86: add regs->ip to oprofile trace

On 24.08.16 11:50:15, Josh Poimboeuf wrote: > dump_trace() doesn't add the interrupted instruction's address to the > trace, so add it manually. This makes the profile more useful, and also > makes it more consistent with what perf profiling does. > > Cc: Robert Richter &

Re: [PATCH 2/6] oprofile/x86: add regs->ip to oprofile trace

On 24.08.16 11:50:15, Josh Poimboeuf wrote: > dump_trace() doesn't add the interrupted instruction's address to the > trace, so add it manually. This makes the profile more useful, and also > makes it more consistent with what perf profiling does. > > Cc: Robert Richter > S

Re: [RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms

gt; -- > include/linux/pci-acpi.h | 5 ++ > include/linux/pci-ecam.h | 2 +- > 9 files changed, 252 insertions(+), 57 deletions(-) > create mode 100644 drivers/pci/host/mcfg-quirks.c > create mode 100644 drivers/pci/host

Re: [RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms

gt; -- > include/linux/pci-acpi.h | 5 ++ > include/linux/pci-ecam.h | 2 +- > 9 files changed, 252 insertions(+), 57 deletions(-) > create mode 100644 drivers/pci/host/mcfg-quirks.c > create mode 100644 drivers/pci/host/mcfg

Re: [RFC PATCH V5 5/5] PCI: thunder-pem: Support quirky configuration space access for ACPI based PCI host controller

cki <t...@semihalf.com> Acked-by: Robert Richter <rrich...@cavium.com> > --- > drivers/pci/host/mcfg-quirks.c | 7 +++ > drivers/pci/host/mcfg-quirks.h | 4 ++ > drivers/pci/host/pci-thunder-pem.c | 96 > -- > 3 files changed, 94 insertions(+), 13 deletions(-)

Re: [RFC PATCH V5 5/5] PCI: thunder-pem: Support quirky configuration space access for ACPI based PCI host controller

dcoded range addresses > 2. thunder_pem_init() ACPI extension to obtain hardcoded addresses for > PEM specific register ranges > 3. New quirk entry (for common quirk array) which identifies platform and > calls thunder_pem_cfg_init() from [1] > > Signed-off-by: Tomasz Nowi

Re: [PATCH V7 0/8] Introduce ACPI world to ITS irqchip

qchip/irq-gic-v3-its.c | 169 ++ > drivers/irqchip/irq-gic-v3.c | 7 +- > drivers/pci/msi.c| 11 +- > include/linux/iort.h | 41 > include/linux/irqchip/arm-gic-v3.h | 4 +- > 11 files chang

Re: [PATCH V7 0/8] Introduce ACPI world to ITS irqchip

qchip/irq-gic-v3-its.c | 169 ++ > drivers/irqchip/irq-gic-v3.c | 7 +- > drivers/pci/msi.c| 11 +- > include/linux/iort.h | 41 > include/linux/irqchip/arm-gic-v3.h | 4 +- > 11 files changed

Re: [PATCH] arm64: Add workaround for Cavium erratum 26026

On 04.08.16 14:40:48, David Daney wrote: > On 08/04/2016 01:57 PM, Robert Richter wrote: > >The patch below is on top of Matthias' patch series: > > > > arm64: Implement IPI based TLB invalidation > > > >The series is used to enable a workaround for Ca

Re: [PATCH] arm64: Add workaround for Cavium erratum 26026

On 04.08.16 14:40:48, David Daney wrote: > On 08/04/2016 01:57 PM, Robert Richter wrote: > >The patch below is on top of Matthias' patch series: > > > > arm64: Implement IPI based TLB invalidation > > > >The series is used to enable a workaround for Ca

[PATCH] arm64: Add workaround for Cavium erratum 26026

The patch below is on top of Matthias' patch series: arm64: Implement IPI based TLB invalidation The series is used to enable a workaround for Cavium ThunderX pass 1.x systems. -Robert >From abb99ee83473d9ecffb4fdaae9c69435ca670bc8 Mon Sep 17 00:00:00 2001 From: Robert Richter <

[PATCH] arm64: Add workaround for Cavium erratum 26026

The patch below is on top of Matthias' patch series: arm64: Implement IPI based TLB invalidation The series is used to enable a workaround for Cavium ThunderX pass 1.x systems. -Robert >From abb99ee83473d9ecffb4fdaae9c69435ca670bc8 Mon Sep 17 00:00:00 2001 From: Robert Richter Date:

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On 22.07.16 14:00:42, Ard Biesheuvel wrote: > On 22 July 2016 at 13:38, Robert Richter <r...@kernel.org> wrote: > > And, we should support some sort of MCFG_OEM_REVISION_ANY to move the > > rev handling optional to pci_cfg_fixup::init(). > > > > xxx_ANY implie

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On 22.07.16 14:00:42, Ard Biesheuvel wrote: > On 22 July 2016 at 13:38, Robert Richter wrote: > > And, we should support some sort of MCFG_OEM_REVISION_ANY to move the > > rev handling optional to pci_cfg_fixup::init(). > > > > xxx_ANY implies 'wildcard', which

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On 29.06.16 15:56:50, Ard Biesheuvel wrote: > On 29 June 2016 at 15:34, Christopher Covington wrote: > > Hi Tomasz, > > > > On 06/29/2016 06:48 AM, Tomasz Nowicki wrote: > >> On 28.06.2016 18:12, Duc Dang wrote: > >>> On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington >

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On 29.06.16 15:56:50, Ard Biesheuvel wrote: > On 29 June 2016 at 15:34, Christopher Covington wrote: > > Hi Tomasz, > > > > On 06/29/2016 06:48 AM, Tomasz Nowicki wrote: > >> On 28.06.2016 18:12, Duc Dang wrote: > >>> On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington > >>> wrote: > Hi

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On 14.06.16 07:36:08, Heiko Carstens wrote: > On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > > Heiko, > > > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > > However I'm wondering if we shouldn't simply remove at least the s390 > > > spe

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On 14.06.16 07:36:08, Heiko Carstens wrote: > On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > > Heiko, > > > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > > However I'm wondering if we shouldn't simply remove at least the s390 > > > spe

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

Heiko, On 09.06.16 11:00:56, Heiko Carstens wrote: > However I'm wondering if we shouldn't simply remove at least the s390 > specific hwswampler code from the oprofile module. This would still leave > the common code timer based sampling mode for oprofile working on s390. > > It looks like the

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

Heiko, On 09.06.16 11:00:56, Heiko Carstens wrote: > However I'm wondering if we shouldn't simply remove at least the s390 > specific hwswampler code from the oprofile module. This would still leave > the common code timer based sampling mode for oprofile working on s390. > > It looks like the

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

On 10.06.16 12:20:05, Robert Richter wrote: > On 04.06.16 00:07:04, Rafael J. Wysocki wrote: > > On Tuesday, May 24, 2016 03:35:30 PM David Daney wrote: > > > From: David Daney <david.da...@cavium.com> > > > > > > Rebased to Linus' master branch at com

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

On 10.06.16 12:20:05, Robert Richter wrote: > On 04.06.16 00:07:04, Rafael J. Wysocki wrote: > > On Tuesday, May 24, 2016 03:35:30 PM David Daney wrote: > > > From: David Daney > > > > > > Rebased to Linus' master branch at commit 1d6da87a3241 (&

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

and srat_disabled() to > > drivers/acpi/numa.c > > acpi, numa, srat: Improve SRAT error detection and add messages. > > ACPI / processor: Add acpi_map_madt_entry(). > > > > Hanjun Guo (10): > > acpi, numa: Use pr_fmt() instead of printk > > acpi, numa:

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

vers/acpi/numa.c > > acpi, numa, srat: Improve SRAT error detection and add messages. > > ACPI / processor: Add acpi_map_madt_entry(). > > > > Hanjun Guo (10): > > acpi, numa: Use pr_fmt() instead of printk > > acpi, numa: Replace ACPI_DEBUG_PRINT() wit

[PATCH v6] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

stream patches (Linus tree v4.6-10530-g28165ec7a99b). v6 (by Robert Richter): rebased onto v4.6-10530-g28165ec7a99b to solve minor conflicts with upstream, no further changes v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-e

[PATCH v6] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

-g28165ec7a99b). v6 (by Robert Richter): rebased onto v4.6-10530-g28165ec7a99b to solve minor conflicts with upstream, no further changes v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-errata.txt updated as per Robert Rich

Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

Will, Marc, On 22.04.16 10:00:52, Will Deacon wrote: > On Fri, Apr 22, 2016 at 09:01:05AM +0100, Marc Zyngier wrote: > > On 21/04/16 18:40, Robert Richter wrote: > > > On 15.04.16 21:30:05, Robert Richter wrote: > > >> From: Ganapatrao Kulkarni

Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

Will, Marc, On 22.04.16 10:00:52, Will Deacon wrote: > On Fri, Apr 22, 2016 at 09:01:05AM +0100, Marc Zyngier wrote: > > On 21/04/16 18:40, Robert Richter wrote: > > > On 15.04.16 21:30:05, Robert Richter wrote: > > >> From: Ganapatrao Kulkarni > > >>

Re: [PATCH] irqchip, gicv3-its, numa: Enable Cavium ThunderX #23144 workaround for ACPI

Marc, thanks for review and sorry for the delay of my answer. On 03.05.16 08:40:47, Marc Zyngier wrote: > On 02/05/16 17:38, Robert Richter wrote: > > From: Robert Richter <rrich...@cavium.com> > > > > In case of acpi the firmware does not provide node ids f

Re: [PATCH] irqchip, gicv3-its, numa: Enable Cavium ThunderX #23144 workaround for ACPI

Marc, thanks for review and sorry for the delay of my answer. On 03.05.16 08:40:47, Marc Zyngier wrote: > On 02/05/16 17:38, Robert Richter wrote: > > From: Robert Richter > > > > In case of acpi the firmware does not provide node ids for cpus and > > its device

[PATCH] irqchip, gicv3-its, numa: Enable Cavium ThunderX #23144 workaround for ACPI

From: Robert Richter <rrich...@cavium.com> In case of acpi the firmware does not provide node ids for cpus and its devices. Determine it from system topology special to Cavium ThunderX systems. This enables #23144 workaround for ACPI. Signed-off-by: Robert Richter <rrich...@c

[PATCH] irqchip, gicv3-its, numa: Enable Cavium ThunderX #23144 workaround for ACPI

From: Robert Richter In case of acpi the firmware does not provide node ids for cpus and its devices. Determine it from system topology special to Cavium ThunderX systems. This enables #23144 workaround for ACPI. Signed-off-by: Robert Richter --- drivers/irqchip/irq-gic-v3-its.c | 19

Re: [PATCH V6 00/13] Support for generic ACPI based PCI host controller

ested on Cavium ThunderX server. Any help in reviewing and > testing is very appreciated. For the whole series: Tested-by: Robert Richter <rrich...@cavium.com> Acked-by: Robert Richter <rrich...@cavium.com> -Robert > v5 -> v6 > - dropped idea of x86 MMCONFIG code refactor

Re: [PATCH V6 00/13] Support for generic ACPI based PCI host controller

ested on Cavium ThunderX server. Any help in reviewing and > testing is very appreciated. For the whole series: Tested-by: Robert Richter Acked-by: Robert Richter -Robert > v5 -> v6 > - dropped idea of x86 MMCONFIG code refactoring > - integrated JC's patches which introduce ne

Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

On 15.04.16 21:30:05, Robert Richter wrote: > From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > > The erratum fixes the hang of ITS SYNC command by avoiding inter node > io and collections/cpu mapping on thunderx dual-socket platform. > > This fix is only

Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

On 15.04.16 21:30:05, Robert Richter wrote: > From: Ganapatrao Kulkarni > > The erratum fixes the hang of ITS SYNC command by avoiding inter node > io and collections/cpu mapping on thunderx dual-socket platform. > > This fix is only applicable for Cavium's ThunderX du

[PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

MA v16 series. Message-Id: <1460155828-8690-1-git-send-email-ddaney.c...@gmail.com> v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-errata.txt updated as per Robert Richter review comment. v3: updatated as per Marc Zyngier's

[PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

828-8690-1-git-send-email-ddaney.c...@gmail.com> v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-errata.txt updated as per Robert Richter review comment. v3: updatated as per Marc Zyngier's review comments. http://www.spinics.

[PATCH] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

MA v16 series. Message-Id: <1460155828-8690-1-git-send-email-ddaney.c...@gmail.com> v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-errata.txt updated as per Robert Richter review comment. v3: updatated as per Marc Zyngier's

[PATCH] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

828-8690-1-git-send-email-ddaney.c...@gmail.com> v5 (by Robert Richter): fixed use of cpumask_of_node() only for (node >= 0) minor style fixes v4: updated silicon-errata.txt updated as per Robert Richter review comment. v3: updatated as per Marc Zyngier's review comments. http://www.spinics.

Re: [PATCH] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

I will resend this with a proper version tag. -Robert On 15.04.16 21:15:34, Robert Richter wrote: > From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > > The erratum fixes the hang of ITS SYNC command by avoiding inter node > io and collections/cpu mapping on th

Re: [PATCH] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

I will resend this with a proper version tag. -Robert On 15.04.16 21:15:34, Robert Richter wrote: > From: Ganapatrao Kulkarni > > The erratum fixes the hang of ITS SYNC command by avoiding inter node > io and collections/cpu mapping on thunderx dual-socket platform. > >

Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

On 23.01.16 17:39:23, Hanjun Guo wrote: > From: Hanjun Guo > > Rework numa_add_memblk() to update the parameter "u64 size" > to "u64 end", this will make it consistent with x86 and > can simplify the code later. > > Updates for arch/arm64/mm/numa.c should squash to core

Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

On 23.01.16 17:39:23, Hanjun Guo wrote: > From: Hanjun Guo > > Rework numa_add_memblk() to update the parameter "u64 size" > to "u64 end", this will make it consistent with x86 and > can simplify the code later. > > Updates for arch/arm64/mm/numa.c should squash to core NUMA > patches from

Re: [PATCH v14 2/6] Documentation, dt, numa: dt bindings for NUMA.

On 08.03.16 10:31:33, Ganapatrao Kulkarni wrote: > On Tue, Mar 8, 2016 at 1:17 AM, David Daney <dda...@caviumnetworks.com> wrote: > > On 03/07/2016 11:22 AM, Robert Richter wrote: > >> > >> On 03.03.16 15:55:35, David Daney wrote: > >>> > >>>

Re: [PATCH v14 2/6] Documentation, dt, numa: dt bindings for NUMA.

On 08.03.16 10:31:33, Ganapatrao Kulkarni wrote: > On Tue, Mar 8, 2016 at 1:17 AM, David Daney wrote: > > On 03/07/2016 11:22 AM, Robert Richter wrote: > >> > >> On 03.03.16 15:55:35, David Daney wrote: > >>> > >>> From: Ganapatrao Kulkarni >

Re: [PATCH v14 2/6] Documentation, dt, numa: dt bindings for NUMA.

On 03.03.16 15:55:35, David Daney wrote: > From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > > Add DT bindings for numa mapping of memory, CPUs and IOs. > > Reviewed-by: Robert Richter <rrich...@cavium.com> > Signed-off-by: Ganapatrao Kulkarni <gkulka...

Re: [PATCH v14 2/6] Documentation, dt, numa: dt bindings for NUMA.

On 03.03.16 15:55:35, David Daney wrote: > From: Ganapatrao Kulkarni > > Add DT bindings for numa mapping of memory, CPUs and IOs. > > Reviewed-by: Robert Richter > Signed-off-by: Ganapatrao Kulkarni > Signed-off-by: David Daney > --- > Documentation/devicet

Re: [PATCH 0/2] arm64, cma, gicv3-its: Use CMA for allocation of large device tables

On 29.02.16 15:17:53, Laura Abbott wrote: > On 02/29/2016 05:30 AM, Marc Zyngier wrote: > >On 29/02/16 12:25, Robert Richter wrote: > >>On 29.02.16 10:46:49, Marc Zyngier wrote: > >>>On 25/02/16 11:02, Robert Richter wrote: > >>>>From: Robert Richter &

Re: [PATCH 0/2] arm64, cma, gicv3-its: Use CMA for allocation of large device tables

On 29.02.16 15:17:53, Laura Abbott wrote: > On 02/29/2016 05:30 AM, Marc Zyngier wrote: > >On 29/02/16 12:25, Robert Richter wrote: > >>On 29.02.16 10:46:49, Marc Zyngier wrote: > >>>On 25/02/16 11:02, Robert Richter wrote: > >>>>From: Robert Richter

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

On 29.02.16 15:42:58, David Daney wrote: > On 02/29/2016 09:34 AM, Robert Richter wrote: > >On 22.02.16 17:58:22, David Daney wrote: > >>From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > >>+static int __init numa_init(int (*init_fu

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

On 29.02.16 15:42:58, David Daney wrote: > On 02/29/2016 09:34 AM, Robert Richter wrote: > >On 22.02.16 17:58:22, David Daney wrote: > >>From: Ganapatrao Kulkarni > >>+static int __init numa_init(int (*init_func)(void)) > >>+{ > >>+ int ret

Re: [PATCH v12 3/5] dt, numa: Add NUMA dt binding implementation.

On 29.02.16 10:13:48, David Daney wrote: > On 02/29/2016 09:29 AM, Robert Richter wrote: > >On 22.02.16 17:58:21, David Daney wrote: > >>From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > >> > >>ADD device tree node parsing for NUMA topolog

Re: [PATCH v12 3/5] dt, numa: Add NUMA dt binding implementation.

On 29.02.16 10:13:48, David Daney wrote: > On 02/29/2016 09:29 AM, Robert Richter wrote: > >On 22.02.16 17:58:21, David Daney wrote: > >>From: Ganapatrao Kulkarni > >> > >>ADD device tree node parsing for NUMA topology using device > >>"numa

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

by: Shannon Zhao <shannon.z...@linaro.org> > Reviewed-by: Robert Richter <rrich...@cavium.com> > Signed-off-by: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > Signed-off-by: David Daney <david.da...@cavium.com> > --- > arch/arm64/Kconfig| 26 +++ &

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

On 22.02.16 17:58:22, David Daney wrote: > From: Ganapatrao Kulkarni > > Attempt to get the memory and CPU NUMA node via of_numa. If that > fails, default the dummy NUMA node and map all memory and CPUs to node > 0. > > Tested-by: Shannon Zhao > Reviewed-by: Robe

Re: [PATCH v12 3/5] dt, numa: Add NUMA dt binding implementation.

On 22.02.16 17:58:21, David Daney wrote: > From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com> > > ADD device tree node parsing for NUMA topology using device > "numa-node-id" property distance-map. > > Reviewed-by: Robert Richter <rrich...@cavium.com&

Re: [PATCH v12 3/5] dt, numa: Add NUMA dt binding implementation.

On 22.02.16 17:58:21, David Daney wrote: > From: Ganapatrao Kulkarni > > ADD device tree node parsing for NUMA topology using device > "numa-node-id" property distance-map. > > Reviewed-by: Robert Richter > Signed-off-by: Ganapatrao Kulkarni > Signed-off

Re: [PATCH 0/2] arm64, cma, gicv3-its: Use CMA for allocation of large device tables

On 29.02.16 10:46:49, Marc Zyngier wrote: > On 25/02/16 11:02, Robert Richter wrote: > > From: Robert Richter <rrich...@cavium.com> > > > > This series implements the use of CMA for allocation of large device > > tables for the arm64 gicv3 interrupt control

Re: [PATCH 0/2] arm64, cma, gicv3-its: Use CMA for allocation of large device tables

On 29.02.16 10:46:49, Marc Zyngier wrote: > On 25/02/16 11:02, Robert Richter wrote: > > From: Robert Richter > > > > This series implements the use of CMA for allocation of large device > > tables for the arm64 gicv3 interrupt controller. > > > > Ther

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

On 27.02.16 09:43:49, Ganapatrao Kulkarni wrote: > On Sat, Feb 27, 2016 at 1:21 AM, David Daney > wrote: > > On 02/26/2016 10:53 AM, Will Deacon wrote: > >>> +static __init int numa_parse_early_param(char *opt) > >>> +{ > >>> + if (!opt) > >>> +

Re: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.

On 27.02.16 09:43:49, Ganapatrao Kulkarni wrote: > On Sat, Feb 27, 2016 at 1:21 AM, David Daney > wrote: > > On 02/26/2016 10:53 AM, Will Deacon wrote: > >>> +static __init int numa_parse_early_param(char *opt) > >>> +{ > >>> + if (!opt) > >>> + return -EINVAL; > >>> +

[PATCH 2/2] irqchip, gicv3-its, cma: Use CMA for allocation of large device tables

From: Robert Richter <rrich...@cavium.com> The gicv3-its device table may have a size of up to 16MB. With 4k pagesize the maximum size of memory allocation is 4MB. Use CMA for allocation of large tables. Signed-off-by: Robert Richter <rrich...@cavium.com> --- drivers/irqchip/irq-

[PATCH 2/2] irqchip, gicv3-its, cma: Use CMA for allocation of large device tables

From: Robert Richter The gicv3-its device table may have a size of up to 16MB. With 4k pagesize the maximum size of memory allocation is 4MB. Use CMA for allocation of large tables. Signed-off-by: Robert Richter --- drivers/irqchip/irq-gic-v3-its.c | 30 +- 1 file

[PATCH 1/2] mm: cma: arm64: Introduce dma_activate_contiguous() for early activation

From: Robert Richter <rrich...@cavium.com> For the arm64 gicv3 interrupt controller we need CMA to allocate large blocks of physically contiguous memory. Usually page_alloc() is limited by 2^(MAX_ORDER - 1), which is typically 4MB at 4k pagesize. A current gicv3-its device table may have

<    1   2   3   4   5   6   7   8   9   10   >