On 01/07/2014 02:35 PM, Scott Wood wrote:
On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
Yeah, Can you provide more detail info about why they can handle that
case? The following is my understand:
Let us assume that there is a atomic global variable(var_a) and its
initial value is 0.
The ker
On Mon, 2014-01-06 at 13:36 +0800, Lian Minghuan-b31939 wrote:
> HI Scott,
>
> please see my comments inline.
>
> On 01/04/2014 06:33 AM, Scott Wood wrote:
> > A lot of this seems duplicated from arch/powerpc/sysdev/indirect_pci.c.
> >
> > How generally applicable is that file to non-PPC implemen
On Tue, 2014-01-07 at 14:27 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
AFAICT this patch was originally written by Shaohui Xie.
> On P3041, P1020, P1021, P1022, P1023 eLBC event interrupts are routed
> to Int9(P3041) & Int3(P102x) while ELBC error interrupts are routed to
> Int0, we nee
Anton Blanchard writes:
>
> Thoughts? It seems like we could hit a similar situation if a machine
> is balanced but we run out of memory on a single node.
Yes I agree, but your patch doesn't seem to attempt to handle this?
-Andi
>
> Index: b/mm/slub.c
> ==
On Tue, 2014-01-07 at 13:38 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
Why did you change the author field?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
> Yeah, Can you provide more detail info about why they can handle that
> case? The following is my understand:
>
> Let us assume that there is a atomic global variable(var_a) and its
> initial value is 0.
>
> The kernel attempts to execute atomic
From: Wang Dongsheng
On P3041, P1020, P1021, P1022, P1023 eLBC event interrupts are routed
to Int9(P3041) & Int3(P102x) while ELBC error interrupts are routed to
Int0, we need to call request_irq for each.
Signed-off-by: Shaohui Xie
Signed-off-by: Wang Dongsheng
Signed-off-by: Kumar Gala
dif
From: Wang Dongsheng
P1020, P1021, P1022, P1023 when the lbc get error, the error
interrupt will be triggered. The corresponding interrupt is
internal IRQ0. So system have to process the lbc IRQ0 interrupt.
The corresponding lbc general interrupt is internal IRQ3.
Signed-off-by: Wang Dongsheng
sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe':
sound/soc/fsl/fsl_ssi.c:1180:6: warning: format '%d' expects argument
of type 'int', but argument 3 has type 'long int' [-Wformat=]
Reported-by: kbuild test robot
Signed-off-by: Alexander Shiyan
---
sound/soc/fsl/fsl_ssi.c | 2 +-
1 file cha
On Tue, 2014-01-07 at 13:38 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
>
> Currently MPIC provides .mask, but not .disable. This means that
> effectively disable_irq() soft-disables the interrupt, and you get
> a .mask call if an interrupt actually occurs.
>
> I'm not sure if this was
From: Wang Dongsheng
Currently MPIC provides .mask, but not .disable. This means that
effectively disable_irq() soft-disables the interrupt, and you get
a .mask call if an interrupt actually occurs.
I'm not sure if this was intended as a performance benefit (it seems common
to omit .disable on
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>
>We noticed a huge amount of slab memory consumed on a large ppc64 box:
>
>Slab:2094336 kB
>
>Almost 2GB. This box is not balanced and some nodes do not have local
>memory, causing slub to be very inefficient in its slab
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its slab usage.
Each time we call kmem_cache_alloc_node slub checks the per cpu
Benjamin Herrenschmidt writes:
> On Mon, 2014-01-06 at 14:33 +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> This avoid mmu-hash64.h including pagetable-ppc64.h. That inclusion
>> cause issues like
>
> I don't like this. We have that stuff split into too many includes
> already
On 01/07/2014 06:05 AM, Scott Wood wrote:
On Mon, 2014-01-06 at 13:27 +0800, wyang wrote:
On 01/06/2014 11:41 AM, Gavin Hu wrote:
Thanks your response. :)
But that means that these optimitive operations like atomic_add()
aren't optimitive actully in PPC architecture, right? Becuase they
can
On Mon, 2014-01-06 at 14:33 +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> This avoid mmu-hash64.h including pagetable-ppc64.h. That inclusion
> cause issues like
I don't like this. We have that stuff split into too many includes
already it's a mess.
Why do we need to include it
On Mon, 2014-01-06 at 20:28 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to m
On Mon, 2014-01-06 at 13:27 +0800, wyang wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> > Thanks your response. :)
> > But that means that these optimitive operations like atomic_add()
> > aren't optimitive actully in PPC architecture, right? Becuase they
> > can be interrupted by loacl
On 12/30/2013 05:05 PM, Srivatsa S. Bhat wrote:
> On POWER platforms, the hypervisor can notify the guest kernel about dynamic
> changes in the cpu-numa associativity (VPHN topology update). Hence the
> cpu-to-node mappings that we got from the firmware during boot, may no longer
> be valid after s
On Sun, Jan 05, 2014 at 10:21:16AM +0400, Alexander Shiyan wrote:
> Signed-off-by: Alexander Shiyan
Applied, thanks.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/list
On Friday, December 20, 2013 09:42:59 AM Bjorn Helgaas wrote:
> On Fri, Dec 20, 2013 at 3:03 AM, Dongsheng Wang
> wrote:
> > From: Wang Dongsheng
> >
> > make Freescale platform use pci_platform_pm_ops struct.
>
> This changelog doesn't say anything about what the patch does.
>
> I infer that y
On Friday, December 20, 2013 07:47:22 PM Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Some cpuidle drivers assume that cpuidle core will handle cases where
> device->state_count is smaller than driver->state_count, unfortunately
> currently this is untrue (device->state_count is used only for handli
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
The last time I got this error, I needed to apply pat
On Mon, Jan 6, 2014 at 10:01 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v3.13-rc7[1] to v3.13-rc6[3], the summaries are:
> - build errors: +14/-4
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error:
'cached_to_uncached' undeclared (first use in this function): =>
99:17
+ /scratch
From: "Aneesh Kumar K.V"
This avoid mmu-hash64.h including pagetable-ppc64.h. That inclusion
cause issues like
CC arch/powerpc/kernel/asm-offsets.s
In file included from
/home/aneesh/linus/arch/powerpc/include/asm/mmu-hash64.h:23:0,
from /home/aneesh/linus/arch/powerpc/i
From: "Aneesh Kumar K.V"
This patch fix the below crash
NIP [c004cee4] .__hash_page_thp+0x2a4/0x440
LR [c00439ac] .hash_page+0x18c/0x5e0
...
Call Trace:
[c00736103c40] [1b00] 0x1b00(unreliable)
[437908.479693] [c00736103d50] [c00439ac] .hash_pa
To give spi flash layout using "mtdparts=..." in cmdline, we must
give mtd_info a fixed name,because the cmdlinepart's parser will
match the name given in cmdline with the mtd_info.
Now, if use OF node, mtd_info's name will be spi->dev->name. It
consists of spi_master->bus_num, and the spi_master-
27 matches
Mail list logo
