On Tue 18-02-14 14:27:11, David Rientjes wrote:
On Tue, 18 Feb 2014, Michal Hocko wrote:
Hi,
I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to
enable zone reclaim). The commit message suggests
On Tue 18-02-14 15:34:05, Nishanth Aravamudan wrote:
Hi Michal,
On 18.02.2014 [10:06:58 +0100], Michal Hocko wrote:
Hi,
I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
56608209d34b (powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to
enable zone reclaim).
On Tue 18-02-14 17:43:38, David Rientjes wrote:
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote:
How about the following?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5de4337..1a0eced 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1854,7 +1854,8 @@ static void
On Wed 19-02-14 00:20:21, David Rientjes wrote:
On Wed, 19 Feb 2014, Michal Hocko wrote:
I strongly suspect that the patch is correct since powerpc node distances
are different than the architectures you're talking about and get doubled
for every NUMA domain that the hardware
Missing bindings were found on running checkpatch.pl on bsc9132
device tree. This patch add/update the following
- Add bindings for L2 cache controller
- Add bindings for memory controller
- Update bindings for USB controller
Signed-off-by: Harninder Rai harninder@freescale.com
---
* Changes
Hello, Gerhard
2014-02-13 4:32 GMT+04:00 Gerhard Sittig g...@denx.de:
For some reason you have kept the DMA maintainers, but dropped
the dmaengine ML from Cc: -- was this intentional, given that the
series is specifically about DMA and you want to get feedback?
No, it was not done by
[ adding dmaengine ML to Cc: ]
Thanks for your feedback, Gerhard
2014-02-13 4:07 GMT+04:00 Gerhard Sittig g...@denx.de:
On Wed, Feb 12, 2014 at 17:25 +0400, Alexander Popov wrote:
/*
- * This is initial version of MPC5121 DMA driver. Only memory to memory
- * transfers are supported (tested
From: Sudeep Holla sudeep.ho...@arm.com
This patch removes the redundant sysfs cacheinfo code by making use of
the newly introduced generic cacheinfo infrastructure.
Signed-off-by: Sudeep Holla sudeep.ho...@arm.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras
From: Sudeep Holla sudeep.ho...@arm.com
Hi,
This series adds a generic cacheinfo support similar to topology. The
implementation is based on x86 cacheinfo support. Currently x86, powerpc,
ia64 and s390 have their own implementations. While adding similar support
to ARM and ARM64, here is the
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote:
the performance impact of the underlying NUMA configuration. I guess we
could special-case memoryless/cpuless configurations somewhat, but I
don't think there's any reason to do that if we can make memoryless-node
support work in-kernel?
Well
On 19.02.2014 [08:24:38 -0800], Nishanth Aravamudan wrote:
On 18.02.2014 [17:43:38 -0800], David Rientjes wrote:
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote:
How about the following?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5de4337..1a0eced 100644
---
On 18.02.2014 [17:43:38 -0800], David Rientjes wrote:
On Tue, 18 Feb 2014, Nishanth Aravamudan wrote:
How about the following?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5de4337..1a0eced 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1854,7 +1854,8 @@ static
On 19.02.2014 [09:23:13 +0100], Michal Hocko wrote:
On Tue 18-02-14 15:34:05, Nishanth Aravamudan wrote:
Hi Michal,
On 18.02.2014 [10:06:58 +0100], Michal Hocko wrote:
Hi,
I have just noticed that ppc has RECLAIM_DISTANCE reduced to 10 set by
56608209d34b (powerpc/numa: Set a
On a powerpc machine with CONFIG_NUMA_BALANCING=y and CONFIG_SPARSEMEM_VMEMMAP
not enabled, kernel panics.
This is true of kernel versions 3.13 to the latest commit 960dfc4 which is
3.14-rc3+. i.e the recent 3 fixups from Aneesh doesnt seem to help this case.
Sometimes it fails on boot up
On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao haoke...@gmail.com wrote:
When the device node do have a compatible property, we definitely
prefer the compatible match besides the type and name. Only if
there is no such a
[BTW, your html mail may be ignored by most people ; for example most of
the linux lists on vger.kernel.org actively reject it; top posting isn't
going to help either... ]
On 14-02-18 02:47 PM, John Donnelly wrote:
I am enable to get one keyboard sequence responded to with the noted change
in
On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao haoke...@gmail.com wrote:
When the device node do have a compatible property, we
This patchset fixes a couple of issues encountered in the suspend/resume code
base. First when using the kernel device tree update code update-nodes is
unnecessarily called more than once. Second the cpu cache lists are not
updated after a suspend/resume which under certain conditions may cause a
From: Haren Myneni hb...@us.ibm.com
The current code makes rtas calls for update-nodes, activate-firmware and then
update-nodes again. The FW provides the same data for both update-nodes calls.
As a result a proc entry exists error is reported for the second update while
adding device nodes.
From: Haren Myneni hb...@us.ibm.com
pHyp can change cache nodes for suspend/resume operation. Currently the
device tree is updated by drmgr in userspace after all non boot CPUs are
enabled. Hence, we do not modify the cache list based on the latest cache
nodes. Also we do not remove cache entries
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform an update
entirely in the kernel during the resume. Therefore, a mechanism is required
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel during the resume. Therefore, a mechanism is
On 14-02-19 03:41 PM, Grant Likely wrote:
On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao haoke...@gmail.com wrote:
When the device node
commit d2ae2e20fbdde5a65f3a5a153044ab1e5c53f7cc (driver/memory:Move
Freescale IFC driver to a common driver) introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In function `fsl_ifc_nand_remove':
drivers/mtd/nand/fsl_ifc_nand.c:1147: undefined reference to
On 02/19/2014 12:56 PM, Tyrel Datwyler wrote:
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel
On Wed, 2014-02-19 at 17:07 -0500, Paul Gortmaker wrote:
commit d2ae2e20fbdde5a65f3a5a153044ab1e5c53f7cc (driver/memory:Move
Freescale IFC driver to a common driver) introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In function `fsl_ifc_nand_remove':
On 14-02-19 05:19 PM, Scott Wood wrote:
On Wed, 2014-02-19 at 17:07 -0500, Paul Gortmaker wrote:
commit d2ae2e20fbdde5a65f3a5a153044ab1e5c53f7cc (driver/memory:Move
Freescale IFC driver to a common driver) introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In
On Wed, 19 Feb 2014 16:23:02 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On 14-02-19 03:41 PM, Grant Likely wrote:
On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring robherri...@gmail.com wrote:
On 14-02-19 05:40 PM, Grant Likely wrote:
On Wed, 19 Feb 2014 16:23:02 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On 14-02-19 03:41 PM, Grant Likely wrote:
On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Thu, Feb 13, 2014 at 2:01 PM,
commit d2ae2e20fbdde5a65f3a5a153044ab1e5c53f7cc (driver/memory:Move
Freescale IFC driver to a common driver) introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In function `fsl_ifc_nand_remove':
drivers/mtd/nand/fsl_ifc_nand.c:1147: undefined reference to
We have seen several issues recently on powerpc LPARs with memoryless
node NUMA configurations, e.g. (an extreme case):
numactl --hardware
available: 2 nodes (0,3)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 3 cpus: 0 1 2 3
node 3 size: 8142 MB
node 3 free: 7765 MB
node distances:
node
We can call local_memory_node() before the zonelists are setup. In that
case, first_zones_zonelist() will not set zone and the reference to
zone-node will Oops. Catch this case, and, since we presumably running
very early, just return that any node will do.
Signed-off-by: Nishanth Aravamudan
In order to enable CONFIG_HAVE_MEMORYLESS_NODES, it is necessary to have
somewhere to store the cpu - local-memory-node mapping. We could
create another powerpc-specific lookup table, but the generic functions
in include/linux/topology.h (protected by HAVE_PERCPU_NUMA_NODE_ID) are
sufficient. This
[Apologies, I sent a stale version of this patch a moment ago...]
In order to enable CONFIG_HAVE_MEMORYLESS_NODES, it is necessary to have
somewhere to store the cpu - local-memory-node mapping. We could
create another powerpc-specific lookup table, but the generic functions
in
Anton Blanchard found an issue with an LPAR that had no memory in Node
0. Christoph Lameter recommended, as one possible solution, to use
numa_mem_id() for locality of the nearest memory node-wise. However,
numa_mem_id() [and the other related APIs] are only useful if
CONFIG_HAVE_MEMORYLESS_NODES
[ Grr, sorry for not including you originally Andrew, if this ends up
being ok with others, it will probably need to go through your tree. ]
On 19.02.2014 [15:17:14 -0800], Nishanth Aravamudan wrote:
We can call local_memory_node() before the zonelists are setup. In that
case,
Grant Likely glik...@secretlab.ca wrote on 02/20/2014 07:41:34 AM:
From: Grant Likely grant.lik...@linaro.org
To: Paul Gortmaker paul.gortma...@windriver.com, Rob Herring
robherri...@gmail.com
Cc: Kevin Hao haoke...@gmail.com, devicet...@vger.kernel.org
devicet...@vger.kernel.org, Arnd
Hi,
I've been trying to understand why the uboot code is unable to work with
USB1.1 devices.
On a USB analyzer:
I notice on an analyzer that there are no SOF or IN tokens seen on the
bus at all. The only after the very first setup packet is sent and ACK'd.
The board has a hub chip on it
On 2/20/2014 4:16 AM, Paul Gortmaker wrote:
commit d2ae2e20fbdde5a65f3a5a153044ab1e5c53f7cc (driver/memory:Move
Freescale IFC driver to a common driver) introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In function `fsl_ifc_nand_remove':
39 matches
Mail list logo
