Re: [PATCH -V6 05/27] powerpc: New hugepage directory format

2013-04-23 Thread Paul Mackerras
On Mon, Apr 22, 2013 at 03:30:39PM +0530, Aneesh Kumar K.V wrote:

> Instead of storing shift value in hugepd pointer we use mmu_psize_def index
> so that we can fit all the supported hugepage size in 4 bits

That works, but does mean that we have to scan the mmu_psize_defs[]
array to work out the encoding for a particular page size.  Instead,
we could use the fact that all large page sizes are powers of 4, as
are all supported page sizes on embedded processors.  So we could
encode using page_code = (page_order - 12) / 2, where page_order is
the log base 2 of the page size, and that lets us represent all power
of 4 page sizes between 2^12 (4kB) and 2^42 bytes (4TB).

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data

2013-04-23 Thread Roy Zang
pci hose->private_data will be used by other function, for example,
fsl_pcie_check_link(), so do not iounmap it.

fix the kerenl crash on T4240:

Unable to handle kernel paging request for data at address
0x880080060f14
Faulting instruction address: 0xc0032554
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24 T4240 QDS
Modules linked in:
NIP: c0032554 LR: c003254c CTR: c001e5c0
REGS: c00179143440 TRAP: 0300   Not tainted
(3.8.8-rt2-00754-g951f064-dirt)
MSR: 80029000   CR: 24adbe22  XER: 
SOFTE: 0
DEAR: 880080060f14, ESR: 
TASK = c0017913d2c0[1] 'swapper/0' THREAD: c0017914 CPU: 2
GPR00: c003254c c001791436c0 c0ae2998
0027
GPR04:  05a5 
0002
GPR08: 3030303038303038 c0a2d4d0 c0aebeb8
c0af2998
GPR12: 24adbe22 cfffa800 c0001be0

GPR16:   

GPR20:   
c09ddf70
GPR24: c09e8d40 c0af2998 c0b1529c
c00179143b40
GPR28: c001799b4000 c00179143c00 88008006
c0727ec8
NIP [c0032554] .fsl_pcie_check_link+0x104/0x150
LR [c003254c] .fsl_pcie_check_link+0xfc/0x150
Call Trace:
[c001791436c0] [c003254c] .fsl_pcie_check_link+0xfc/0x150
(unreliab)
[c00179143a30] [c00325d4]
.fsl_indirect_read_config+0x34/0xb0
[c00179143ad0] [c02c7ee8]
.pci_bus_read_config_byte+0x88/0xd0
[c00179143b90] [c09c0528] .pci_apply_final_quirks+0x9c/0x18c
[c00179143c40] [c000142c] .do_one_initcall+0x5c/0x1f0
[c00179143cf0] [c09a0bb4] .kernel_init_freeable+0x180/0x264
[c00179143db0] [c0001bfc] .kernel_init+0x1c/0x420
[c00179143e30] [c8b4] .ret_from_kernel_thread+0x64/0xb0
Instruction dump:
6000 4ba0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
7fc5f378 486ea77d 6000 7c0004ac <801e0f14> 0c00 4c00012c
3c62ffe0
---[ end trace f841fbc03c9d2e1b ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

Rebooting in 180 seconds..

Signed-off-by: Yuanquan Chen 
Signed-off-by: Roy Zang 
---
based on Kumar's next branch
v2:v1, fix the exit issue

 arch/powerpc/sysdev/fsl_pci.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index f823304..cffe7ed 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -244,12 +244,12 @@ static void setup_pci_atmu(struct pci_controller *hose)
 
if (paddr_hi == paddr_lo) {
pr_err("%s: No outbound window space\n", name);
-   goto out;
+   return;
}
 
if (paddr_lo == 0) {
pr_err("%s: No space for inbound window\n", name);
-   goto out;
+   return;
}
 
/* setup PCSRBAR/PEXCSRBAR */
@@ -395,9 +395,6 @@ static void setup_pci_atmu(struct pci_controller *hose)
pr_info("%s: DMA window size is 0x%llx\n", name,
(u64)hose->dma_window_size);
}
-
-out:
-   iounmap(pci);
 }
 
 static void __init setup_pci_cmd(struct pci_controller *hose)
-- 
1.7.9.5


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH -V6 05/27] powerpc: New hugepage directory format

2013-04-23 Thread Aneesh Kumar K.V
Paul Mackerras  writes:

> On Mon, Apr 22, 2013 at 03:30:39PM +0530, Aneesh Kumar K.V wrote:
>
>> Instead of storing shift value in hugepd pointer we use mmu_psize_def index
>> so that we can fit all the supported hugepage size in 4 bits
>
> That works, but does mean that we have to scan the mmu_psize_defs[]
> array to work out the encoding for a particular page size.

We do the scan only when allocating hugepgd. While walking it is only
mmu_psize_defs dereference. Yes, that could possibly have a performance
impact, but having a well defined way to map page shift to a smaller
index and using the same method all the place is nice. I will try to
measure the impact and switch to the below method if needed.

>  Instead,
> we could use the fact that all large page sizes are powers of 4, as
> are all supported page sizes on embedded processors.  So we could
> encode using page_code = (page_order - 12) / 2, where page_order is
> the log base 2 of the page size, and that lets us represent all power
> of 4 page sizes between 2^12 (4kB) and 2^42 bytes (4TB).

I guess i can add this as an addon patch on the top of the series if the
current patch series is going in to Benh's tree ?

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Michael Ellerman
On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> Hello!

Hi Dennis,


> [1.] One line summary of the problem:
> Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
> 
> 
> [2.] Full description of the problem/report:
> On my IBM Cell blades, only 2 out of the 4 CPU cores are being used, even 
> when 
> several threads are running. 

Yes you're right, I see that too.

For me it is fixed by applying the following patch, it should be in v3.10:

  http://patchwork.ozlabs.org/patch/230103/

Maybe you can try it.


> Also /spu is always empty, despite the SPUs being 

Yes I see that too.

> For testing, I started an instance of cellminer with --ppe 2 --spe 16 (2 
> threads on the PPEs, 16 on the SPEs) and htop reports two CPU cores being 
> used 
> at 100% and two others at 0%, while 4 threads are running (each at 50% CPU 
> utilisation -> they share a core).

Does your cellminer actually work? ie. does it run OK?

I am using a fractal benchmark I had lying around, and it appears to
work, and runs fast enough that it must be running on the SPUs (I think).

So it sounds like we have some weirdness with stuff not appearing in
/spu, but spu programs are still able to run. Which is odd to say the
least.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data

2013-04-23 Thread Kevin Hao
On Tue, Apr 23, 2013 at 11:18:03PM +0800, Roy Zang wrote:
> pci hose->private_data will be used by other function, for example,
> fsl_pcie_check_link(), so do not iounmap it.

I already sent out a same patch ten days ago. :-)

http://patchwork.ozlabs.org/patch/236293/

Thanks,
Kevin

> 
> fix the kerenl crash on T4240:
> 
> Unable to handle kernel paging request for data at address
> 0x880080060f14
> Faulting instruction address: 0xc0032554
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24 T4240 QDS
> Modules linked in:
> NIP: c0032554 LR: c003254c CTR: c001e5c0
> REGS: c00179143440 TRAP: 0300   Not tainted
> (3.8.8-rt2-00754-g951f064-dirt)
> MSR: 80029000   CR: 24adbe22  XER: 
> SOFTE: 0
> DEAR: 880080060f14, ESR: 
> TASK = c0017913d2c0[1] 'swapper/0' THREAD: c0017914 CPU: 2
> GPR00: c003254c c001791436c0 c0ae2998
> 0027
> GPR04:  05a5 
> 0002
> GPR08: 3030303038303038 c0a2d4d0 c0aebeb8
> c0af2998
> GPR12: 24adbe22 cfffa800 c0001be0
> 
> GPR16:   
> 
> GPR20:   
> c09ddf70
> GPR24: c09e8d40 c0af2998 c0b1529c
> c00179143b40
> GPR28: c001799b4000 c00179143c00 88008006
> c0727ec8
> NIP [c0032554] .fsl_pcie_check_link+0x104/0x150
> LR [c003254c] .fsl_pcie_check_link+0xfc/0x150
> Call Trace:
> [c001791436c0] [c003254c] .fsl_pcie_check_link+0xfc/0x150
> (unreliab)
> [c00179143a30] [c00325d4]
> .fsl_indirect_read_config+0x34/0xb0
> [c00179143ad0] [c02c7ee8]
> .pci_bus_read_config_byte+0x88/0xd0
> [c00179143b90] [c09c0528] .pci_apply_final_quirks+0x9c/0x18c
> [c00179143c40] [c000142c] .do_one_initcall+0x5c/0x1f0
> [c00179143cf0] [c09a0bb4] .kernel_init_freeable+0x180/0x264
> [c00179143db0] [c0001bfc] .kernel_init+0x1c/0x420
> [c00179143e30] [c8b4] .ret_from_kernel_thread+0x64/0xb0
> Instruction dump:
> 6000 4ba0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
> 7fc5f378 486ea77d 6000 7c0004ac <801e0f14> 0c00 4c00012c
> 3c62ffe0
> ---[ end trace f841fbc03c9d2e1b ]---
> 
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> 
> Rebooting in 180 seconds..
> 
> Signed-off-by: Yuanquan Chen 
> Signed-off-by: Roy Zang 
> ---
> based on Kumar's next branch
> v2:v1, fix the exit issue
> 
>  arch/powerpc/sysdev/fsl_pci.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index f823304..cffe7ed 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -244,12 +244,12 @@ static void setup_pci_atmu(struct pci_controller *hose)
>  
>   if (paddr_hi == paddr_lo) {
>   pr_err("%s: No outbound window space\n", name);
> - goto out;
> + return;
>   }
>  
>   if (paddr_lo == 0) {
>   pr_err("%s: No space for inbound window\n", name);
> - goto out;
> + return;
>   }
>  
>   /* setup PCSRBAR/PEXCSRBAR */
> @@ -395,9 +395,6 @@ static void setup_pci_atmu(struct pci_controller *hose)
>   pr_info("%s: DMA window size is 0x%llx\n", name,
>   (u64)hose->dma_window_size);
>   }
> -
> -out:
> - iounmap(pci);
>  }
>  
>  static void __init setup_pci_cmd(struct pci_controller *hose)
> -- 
> 1.7.9.5
> 
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


pgpN7gEMolksD.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform

2013-04-23 Thread Chen Yuanquan-B41889

On 04/10/2013 05:08 PM, Chen Yuanquan-B41889 wrote:

On 04/03/2013 12:08 PM, Chen Yuanquan-B41889 wrote:

On 04/02/2013 11:10 PM, Benjamin Herrenschmidt wrote:

On Tue, 2013-04-02 at 19:26 +0800, Yuanquan Chen wrote:
So we move the DMA & IRQ initialization code from 
pcibios_setup_devices() and
construct a new function pcibios_enable_device. We call this 
function in
pcibios_enable_device, which will be called by PCI-e rescan code. 
At the
meanwhile, we avoid the the impact on cardbus. I also validate this 
patch with

silicon's PCIe-sata which encounters the IRQ issue.
My worry is that this delays the setup of the IRQ and DMA to very 
late in

the process, possibly after the quirks have been run, which can be
problematic. We have platform hooks that might try to "fixup" specific
IRQ issues on some platforms (especially macs) which I worry might fail
if delayed that way (I may be wrong, I don't have a specific case in 
mind,

but I would feel better if we kept setting up these things earlier).

Cheers,
Ben.



Hi Ben,

I have checked all the quirk functions which are declared in kernel 
arch/powerpc

with command :
grep DECLARE_PCI_FIXUP_ `find arch/powerpc/ *.[hc]`

All the quirk function are defined as DECLARE_PCI_FIXUP_EARLY , 
DECLARE_PCI_FIXUP_HEADER
and DECLARE_PCI_FIXUP_FINAL, except quirk_uli5229() in 
arch/powerpc/platforms/fsl_uli1575.c, which is
defined both as DECLARE_PCI_FIXUP_HEADER and 
DECLARE_PCI_FIXUP_RESUME. So the quirk_uli5229()
will also be called with PCI pm module. The quirk functions defined 
as xxx_FINAL, HEADER and EARLY,

will be called in the path:

pci_scan_child_bus()->pci_scan_slot()->pci_scan_single_device()->pci_scan_device()->pci_setup_device() 


->pci_device_add()

the pci_scan_slot() is called earlier than pcibios_fixup_bus() even 
for the first scan of PCI-e bus, so the quirk
functions on powerpc platform is called before the DMA & IRQ fixup. 
So in reality, the delay of DMA & IRQ fixup

won't affect anything.

Regards,
Yuanquan



Hi Ben,

How do you think about this? Do you have any comment?

Thanks,
Yuanquan



Hi Bjorn,

There's no response from Ben. How do you think about this patch? What's 
your advice?


Thanks,
Yuanquan














___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data

2013-04-23 Thread Roy Zang

On 04/23/2013 05:13 PM, Kevin Hao wrote:

On Tue, Apr 23, 2013 at 11:18:03PM +0800, Roy Zang wrote:

pci hose->private_data will be used by other function, for example,
fsl_pcie_check_link(), so do not iounmap it.

I already sent out a same patch ten days ago. :-)

http://patchwork.ozlabs.org/patch/236293/

Thanks,
Kevin


I do not notice it. That is good :-)
Kumar,
You can pick up the post from Kevin.
Thanks.
Roy


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/fsl-pci: don't unmap the PCI SoC controller registers in setup_pci_atmu

2013-04-23 Thread Roy Zang

On 04/13/2013 03:14 PM, Kevin Hao wrote:

In patch 34642bbb (powerpc/fsl-pci: Keep PCI SoC controller registers in
pci_controller) we choose to keep the map of the PCI SoC controller
registers. But we missed to delete the unmap in setup_pci_atmu
function. This will cause the following call trace once we access
the PCI SoC controller registers later.

Unable to handle kernel paging request for data at address 0x880080040f14
Faulting instruction address: 0xc002ea58
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24 T4240 QDS
Modules linked in:
NIP: c002ea58 LR: c002eaf4 CTR: c002eac0
REGS: c0017e10b4a0 TRAP: 0300   Not tainted  
(3.9.0-rc1-00052-gfa3529f-dirty)
MSR: 80029000   CR: 28adbe22  XER: 
SOFTE: 0
DEAR: 880080040f14, ESR: 
TASK = c0017e10[1] 'swapper/0' THREAD: c0017e108000 CPU: 2
GPR00:  c0017e10b720 c09928d8 c0017e578e00
GPR04:  000c 0001 c0017e10bb40
GPR08:  88008004  0016
GPR12: 88adbe22 cfffa800 c0001ba0 
GPR16:    
GPR20:    c08a5b70
GPR24: c08af938 c09a28d8 c09bb5dc c0017e10bb40
GPR28: c0017e32a400 c0017e10bc00 c0017e32a400 c0017e578e00
NIP [c002ea58] .fsl_pcie_check_link+0x88/0xf0
LR [c002eaf4] .fsl_indirect_read_config+0x34/0xb0
Call Trace:
[c0017e10b720] [c0017e10b7a0] 0xc0017e10b7a0 (unreliable)
[c0017e10ba30] [c002eaf4] .fsl_indirect_read_config+0x34/0xb0
[c0017e10bad0] [c033aa08] .pci_bus_read_config_byte+0x88/0xd0
[c0017e10bb90] [c088d708] .pci_apply_final_quirks+0x9c/0x18c
[c0017e10bc40] [c00013dc] .do_one_initcall+0x5c/0x1f0
[c0017e10bcf0] [c086ebac] .kernel_init_freeable+0x180/0x26c
[c0017e10bdb0] [c0001bbc] .kernel_init+0x1c/0x460
[c0017e10be30] [c880] .ret_from_kernel_thread+0x64/0xe4
Instruction dump:
38210310 2b800015 4fdde842 7c600026 5463fffe e8010010 7c0803a6 4e800020
6000 6000 e92301d0 7c0004ac <80690f14> 0c03 4c00012c 38210310
---[ end trace 7a8fe0cbccb7d992 ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

Signed-off-by: Kevin Hao 
---


acked.
thanks.
Roy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [linuxppc-release] [PATCH v2 01/15] powerpc/85xx: cache operations for Freescale SoCs based on BOOK3E

2013-04-23 Thread Zhao Chenhui
Hi Kumar, Scott,

Do you have any comments on this set of patches?

Best Regards,
-Chenhui

On Fri, Apr 19, 2013 at 06:47:34PM +0800, Zhao Chenhui wrote:
> These cache operations support Freescale SoCs based on BOOK3E.
> Move L1 cache operations to fsl_booke_cache.S in order to maintain
> easily. And, add cache operations for backside L2 cache and platform cache.
> 
> The backside L2 cache appears on e500mc and e5500 core. The platform cache
> supported by this patch is L2 Look-Aside Cache, which appears on SoCs
> with e500v1/e500v2 core, such as MPC8572, P1020, etc.
> 
> Signed-off-by: Zhao Chenhui 
> Signed-off-by: Li Yang 
> ---
>  arch/powerpc/include/asm/cacheflush.h |8 ++
>  arch/powerpc/kernel/Makefile  |1 +
>  arch/powerpc/kernel/fsl_booke_cache.S |  210 
> +
>  arch/powerpc/kernel/head_fsl_booke.S  |   74 
>  4 files changed, 219 insertions(+), 74 deletions(-)
>  create mode 100644 arch/powerpc/kernel/fsl_booke_cache.S
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 17:26 +0800, Chen Yuanquan-B41889 wrote:
> There's no response from Ben. How do you think about this patch?
> What's 
> your advice?

Didn't Michael put your patch in -next while I was on vacation ? I'll
check tomorrow.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

2013-04-23 Thread Wang Dongsheng-B40534
Hi Kumar,

Could you apply these patches?

Thanks.

[v3,1/4] powerpc/mpic: add irq_set_wake support
http://patchwork.ozlabs.org/patch/234934/

[v3,2/4] powerpc/mpic: add global timer support
http://patchwork.ozlabs.org/patch/234935/

[v3,3/4] powerpc/mpic: create mpic subsystem object
http://patchwork.ozlabs.org/patch/234936/

[v3,4/4] powerpc/fsl: add MPIC timer wakeup support
http://patchwork.ozlabs.org/patch/234937/


> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 17, 2013 7:30 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> ga...@kernel.crashing.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> ACK
> 
> -Scott
> 
> On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > Hi scott,
> >
> > Could you ACK these patches?
> >
> > [PATCH v3 2/4] powerpc/mpic: add global timer support
> > [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object
> > [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support
> >
> > Thanks.
> >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform

2013-04-23 Thread Chen Yuanquan-B41889

On 04/23/2013 06:05 PM, Benjamin Herrenschmidt wrote:

On Tue, 2013-04-23 at 17:26 +0800, Chen Yuanquan-B41889 wrote:

There's no response from Ben. How do you think about this patch?
What's
your advice?

Didn't Michael put your patch in -next while I was on vacation ? I'll
check tomorrow.

Cheers,
Ben.



Hi Ben,

I have checked the latest kernel(v3.9-rc7). This patch has been applied.

Thanks,
Yuanquan








___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 0/5] powerpc/powernv: PHB3 Support

2013-04-23 Thread Gavin Shan
The patchset includes minimal support for PHB3. Initially, flag "PNV_PHB_IODA2"
is introduced to differentiate IODA2 compliant PHB3 from other types of PHBs and
do initialization accordingly for PHB3. Besides, variable IODA2 tables reside in
system memory and we allocate them in kernel, then pass them to f/w and enable
the corresponding BARs through OPAL API. The P/Q bits of IVE should be handled
on PHB3 by software and the patchset intends to cover that as well.

NOTE: The first patch comes from Ben.

v1 -> v2
* Introduce CONFIG_POWERNV_MSI, which is similiar to CONFIG_PSERIES_MSI
* Enable CONFIG_PPC_MSI_BITMAP while selecting CONFIG_POWERNV_MSI
* Eleminate (struct pnv_phb::msi_count) since it has been removed in
  linux-next
* Replace (CONFIG_PPC_POWERNV && CONFIG_PCI_MSI) with CONFIG_POWERNV_MSI
* Move declaration of pnv_pci_msi_eoi() to asm/xics.h
* Remove unnecessary "#ifdef ... #endif" in icp-native.c
* Add support to invalidate TCE
* Let the IODA2 table allocated by firmware and kernel to retrieve them
  through device-tree

---

arch/powerpc/include/asm/iommu.h|1 +
arch/powerpc/include/asm/opal.h |5 +-
arch/powerpc/include/asm/xics.h |3 +
arch/powerpc/platforms/powernv/Kconfig  |5 +
arch/powerpc/platforms/powernv/pci-ioda.c   |  209 +++
arch/powerpc/platforms/powernv/pci-p5ioc2.c |2 +
arch/powerpc/platforms/powernv/pci.c|   74 --
arch/powerpc/platforms/powernv/pci.h|   24 +++-
arch/powerpc/sysdev/Kconfig |1 +
arch/powerpc/sysdev/xics/icp-native.c   |   27 -
10 files changed, 267 insertions(+), 84 deletions(-)

Thanks,
Gavin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 4/5] powerpc/powernv: Patch MSI EOI handler on P8

2013-04-23 Thread Gavin Shan
The EOI handler of MSI/MSI-X interrupts for P8 (PHB3) need additional
steps to handle the P/Q bits in IVE before EOIing the corresponding
interrupt. The patch changes the EOI handler to cover that.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/include/asm/xics.h   |3 ++
 arch/powerpc/platforms/powernv/pci-ioda.c |   33 +
 arch/powerpc/platforms/powernv/pci.c  |   19 
 arch/powerpc/platforms/powernv/pci.h  |1 +
 arch/powerpc/sysdev/xics/icp-native.c |   27 ++-
 5 files changed, 82 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/xics.h b/arch/powerpc/include/asm/xics.h
index 4ae9a09..c4b364b 100644
--- a/arch/powerpc/include/asm/xics.h
+++ b/arch/powerpc/include/asm/xics.h
@@ -72,6 +72,9 @@ extern int ics_opal_init(void);
 static inline int ics_opal_init(void) { return -ENODEV; }
 #endif
 
+/* Extra EOI handler for PHB3 */
+extern int pnv_pci_msi_eoi(unsigned int hw_irq);
+
 /* ICS instance, hooked up to chip_data of an irq */
 struct ics {
struct list_head link;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 0c15870..8ec77a7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -646,6 +646,37 @@ static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, 
struct pci_dev *dev,
return 0;
 }
 
+static int pnv_pci_ioda_msi_eoi(struct pnv_phb *phb, unsigned int hw_irq)
+{
+   u8 p_bit = 1, q_bit = 1;
+   long rc;
+
+   while (p_bit || q_bit) {
+   rc = opal_pci_get_xive_reissue(phb->opal_id,
+   hw_irq - phb->msi_base, &p_bit, &q_bit);
+   if (rc) {
+   pr_warning("%s: Failed to get P/Q bits of IRQ#%d "
+  "on PHB#%d, rc=%ld\n", __func__, hw_irq,
+  phb->hose->global_number, rc);
+   return -EIO;
+   }
+   if (!p_bit && !q_bit)
+   break;
+
+   rc = opal_pci_set_xive_reissue(phb->opal_id,
+   hw_irq - phb->msi_base, p_bit, q_bit);
+   if (rc) {
+   pr_warning("%s: Failed to clear P/Q (%01d/%01d) of "
+  "IRQ#%d on PHB#%d, rc=%ld\n", __func__,
+  p_bit, q_bit, hw_irq,
+  phb->hose->global_number, rc);
+   return -EIO;
+   }
+   }
+
+   return 0;
+}
+
 static void pnv_pci_init_ioda_msis(struct pnv_phb *phb)
 {
unsigned int count;
@@ -667,6 +698,8 @@ static void pnv_pci_init_ioda_msis(struct pnv_phb *phb)
}
 
phb->msi_setup = pnv_pci_ioda_msi_setup;
+   if (phb->type == PNV_PHB_IODA2)
+   phb->msi_eoi = pnv_pci_ioda_msi_eoi;
phb->msi32_support = 1;
pr_info("  Allocated bitmap for %d MSIs (base IRQ 0x%x)\n",
count, phb->msi_base);
diff --git a/arch/powerpc/platforms/powernv/pci.c 
b/arch/powerpc/platforms/powernv/pci.c
index 83514dc..1a03f42 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -115,6 +115,25 @@ static void pnv_teardown_msi_irqs(struct pci_dev *pdev)
irq_dispose_mapping(entry->irq);
}
 }
+
+int pnv_pci_msi_eoi(unsigned int hw_irq)
+{
+   struct pci_controller *hose, *tmp;
+   struct pnv_phb *phb = NULL;
+
+   list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
+   phb = hose->private_data;
+   if (hw_irq >= phb->msi_base &&
+   hw_irq < phb->msi_base + phb->msi_bmp.irq_count) {
+   if (!phb->msi_eoi)
+   return -EEXIST;
+   return phb->msi_eoi(phb, hw_irq);
+   }
+   }
+
+   /* For LSI interrupts, we needn't do it */
+   return 0;
+}
 #endif /* CONFIG_PCI_MSI */
 
 static void pnv_pci_dump_p7ioc_diag_data(struct pnv_phb *phb)
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index c048c29..c6690b3 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -81,6 +81,7 @@ struct pnv_phb {
int (*msi_setup)(struct pnv_phb *phb, struct pci_dev *dev,
 unsigned int hwirq, unsigned int is_64,
 struct msi_msg *msg);
+   int (*msi_eoi)(struct pnv_phb *phb, unsigned int hw_irq);
void (*dma_dev_setup)(struct pnv_phb *phb, struct pci_dev *pdev);
void (*fixup_phb)(struct pci_controller *hose);
u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
diff --git a/arch/powerpc/sysdev/xics/icp-native.c 
b/arch/powerpc/sysdev/xics/icp-native.c
index 48861d3..38dd2b1 100644
--- a/arch/powerpc/sysdev/xics/icp-native.c

[PATCH 2/5] powerpc/powernv: Retrieve IODA2 tables explicitly

2013-04-23 Thread Gavin Shan
The PHB3, which is compatible with IODA2, have lots of tables (RTT/
PETLV/PEST/IVT/RBA) in system memory and have corresponding BARs to
trace the system memory address. The tables have been allocated in
firmware and exported through device-tree. The patch retrieves the
tables explicitly.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/include/asm/opal.h   |5 +--
 arch/powerpc/platforms/powernv/pci-ioda.c |   35 +
 arch/powerpc/platforms/powernv/pci.h  |   13 ++
 3 files changed, 50 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index a4b28f1..0af7ba0 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -491,9 +491,8 @@ int64_t opal_pci_map_pe_mmio_window(uint64_t phb_id, 
uint16_t pe_number,
uint16_t window_type, uint16_t window_num,
uint16_t segment_num);
 int64_t opal_pci_set_phb_table_memory(uint64_t phb_id, uint64_t rtt_addr,
- uint64_t ivt_addr, uint64_t ivt_len,
- uint64_t reject_array_addr,
- uint64_t peltv_addr);
+ uint64_t peltv_addr, uint64_t pest_addr,
+ uint64_t ivt_addr, uint64_t rba_addr);
 int64_t opal_pci_set_pe(uint64_t phb_id, uint64_t pe_number, uint64_t 
bus_dev_func,
uint8_t bus_compare, uint8_t dev_compare, uint8_t 
func_compare,
uint8_t pe_action);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3d4e958..0c15870 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -852,6 +852,23 @@ static u32 pnv_ioda_bdfn_to_pe(struct pnv_phb *phb, struct 
pci_bus *bus,
return phb->ioda.pe_rmap[(bus->number << 8) | devfn];
 }
 
+static void __init pnv_pci_get_ioda2_table(struct device_node *np,
+  const char *name,
+  void **table,
+  unsigned int *len)
+{
+   const u32 *prop32;
+   u64 base;
+
+   prop32 = of_get_property(np, name, NULL);
+   if (prop32) {
+   base = be32_to_cpup(prop32);
+   base = base << 32 | be32_to_cpup(prop32 + 1);
+   *table = __va(base);
+   *len = be32_to_cpup(prop32 + 2);
+   }
+}
+
 void __init pnv_pci_init_ioda_phb(struct device_node *np, int ioda_type)
 {
struct pci_controller *hose;
@@ -998,6 +1015,24 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np, 
int ioda_type)
ppc_md.pcibios_window_alignment = pnv_pci_window_alignment;
pci_add_flags(PCI_REASSIGN_ALL_RSRC);
 
+   /* Retrieve variable IODA2 tables */
+   if (ioda_type == PNV_PHB_IODA2) {
+   pnv_pci_get_ioda2_table(np, "ibm,opal-rtt-table",
+   &phb->ioda.tbl_rtt, &phb->ioda.rtt_len);
+   pnv_pci_get_ioda2_table(np, "ibm,opal-peltv-table",
+   &phb->ioda.tbl_peltv, &phb->ioda.peltv_len);
+   pnv_pci_get_ioda2_table(np, "ibm,opal-pest-table",
+   &phb->ioda.tbl_pest, &phb->ioda.pest_len);
+   pnv_pci_get_ioda2_table(np, "ibm,opal-ivt-table",
+   &phb->ioda.tbl_ivt, &phb->ioda.ivt_len);
+   pnv_pci_get_ioda2_table(np, "ibm,opal-rba-table",
+   &phb->ioda.tbl_rba, &phb->ioda.rba_len);
+   /* Get IVE stride */
+   prop32 = of_get_property(np, "ibm,opal-ive-stride", NULL);
+   if (prop32)
+   phb->ioda.ive_stride = be32_to_cpup(prop32);
+   }
+
/* Reset IODA tables to a clean state */
rc = opal_pci_reset(phb_id, OPAL_PCI_IODA_TABLE_RESET, 
OPAL_ASSERT_RESET);
if (rc)
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index f6314d6..c048c29 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -100,6 +100,19 @@ struct pnv_phb {
unsigned intio_segsize;
unsigned intio_pci_base;
 
+   /* Variable tables for IODA2 */
+   void*tbl_rtt;
+   void*tbl_peltv;
+   void*tbl_pest;
+   void*tbl_ivt;
+   void*tbl_rba;
+   unsigned intive_stride;
+   unsigned intrtt_len;
+   unsigned intpeltv_len;
+ 

[PATCH 1/5] powerpc/powernv: Supports PHB3

2013-04-23 Thread Gavin Shan
The patch intends to initialize PHB3 during system boot stage. The
flag "PNV_PHB_MODEL_PHB3" is introduced to differentiate IODA2
compatible PHB3 from other types of PHBs.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/platforms/powernv/pci-ioda.c |   62 +++--
 arch/powerpc/platforms/powernv/pci.c  |7 +++-
 arch/powerpc/platforms/powernv/pci.h  |8 ++-
 3 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index a5c5f15..3d4e958 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -852,18 +852,19 @@ static u32 pnv_ioda_bdfn_to_pe(struct pnv_phb *phb, 
struct pci_bus *bus,
return phb->ioda.pe_rmap[(bus->number << 8) | devfn];
 }
 
-void __init pnv_pci_init_ioda1_phb(struct device_node *np)
+void __init pnv_pci_init_ioda_phb(struct device_node *np, int ioda_type)
 {
struct pci_controller *hose;
static int primary = 1;
struct pnv_phb *phb;
unsigned long size, m32map_off, iomap_off, pemap_off;
const u64 *prop64;
+   const u32 *prop32;
u64 phb_id;
void *aux;
long rc;
 
-   pr_info(" Initializing IODA OPAL PHB %s\n", np->full_name);
+   pr_info(" Initializing IODA%d OPAL PHB %s\n", ioda_type, np->full_name);
 
prop64 = of_get_property(np, "ibm,opal-phbid", NULL);
if (!prop64) {
@@ -890,37 +891,34 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
hose->last_busno = 0xff;
hose->private_data = phb;
phb->opal_id = phb_id;
-   phb->type = PNV_PHB_IODA1;
+   phb->type = ioda_type;
 
/* Detect specific models for error handling */
if (of_device_is_compatible(np, "ibm,p7ioc-pciex"))
phb->model = PNV_PHB_MODEL_P7IOC;
+   else if (of_device_is_compatible(np, "ibm,p8-pciex"))
+   phb->model = PNV_PHB_MODEL_PHB3;
else
phb->model = PNV_PHB_MODEL_UNKNOWN;
 
-   /* We parse "ranges" now since we need to deduce the register base
-* from the IO base
-*/
+   /* Parse 32-bit and IO ranges (if any) */
pci_process_bridge_OF_ranges(phb->hose, np, primary);
primary = 0;
 
-   /* Magic formula from Milton */
+   /* Get registers */
phb->regs = of_iomap(np, 0);
if (phb->regs == NULL)
pr_err("  Failed to map registers !\n");
 
-
-   /* XXX This is hack-a-thon. This needs to be changed so that:
-*  - we obtain stuff like PE# etc... from device-tree
-*  - we properly re-allocate M32 ourselves
-*(the OFW one isn't very good)
-*/
-
/* Initialize more IODA stuff */
-   phb->ioda.total_pe = 128;
+   prop32 = of_get_property(np, "ibm,opal-num-pes", NULL);
+   if (!prop32)
+   phb->ioda.total_pe = 1;
+   else
+   phb->ioda.total_pe = *prop32;
 
phb->ioda.m32_size = resource_size(&hose->mem_resources[0]);
-   /* OFW Has already off top 64k of M32 space (MSI space) */
+   /* FW Has already off top 64k of M32 space (MSI space) */
phb->ioda.m32_size += 0x1;
 
phb->ioda.m32_segsize = phb->ioda.m32_size / phb->ioda.total_pe;
@@ -930,7 +928,10 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
phb->ioda.io_segsize = phb->ioda.io_size / phb->ioda.total_pe;
phb->ioda.io_pci_base = 0; /* XXX calculate this ? */
 
-   /* Allocate aux data & arrays */
+   /* Allocate aux data & arrays
+*
+* XXX TODO: Don't allocate io segmap on PHB3
+*/
size = _ALIGN_UP(phb->ioda.total_pe / 8, sizeof(unsigned long));
m32map_off = size;
size += phb->ioda.total_pe * sizeof(phb->ioda.m32_segmap[0]);
@@ -960,7 +961,7 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
hose->mem_resources[2].start = 0;
hose->mem_resources[2].end = 0;
 
-#if 0
+#if 0 /* We should really do that ... */
rc = opal_pci_set_phb_mem_window(opal->phb_id,
 window_type,
 window_num,
@@ -974,16 +975,6 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
phb->ioda.m32_size, phb->ioda.m32_segsize,
phb->ioda.io_size, phb->ioda.io_segsize);
 
-   if (phb->regs)  {
-   pr_devel(" BUID = 0x%016llx\n", in_be64(phb->regs + 0x100));
-   pr_devel(" PHB2_CR  = 0x%016llx\n", in_be64(phb->regs + 0x160));
-   pr_devel(" IO_BAR   = 0x%016llx\n", in_be64(phb->regs + 0x170));
-   pr_devel(" IO_BAMR  = 0x%016llx\n", in_be64(phb->regs + 0x178));
-   pr_devel(" IO_SAR   = 0x%016llx\n", in_be64(phb->regs + 0x180));
-   pr_devel(" M32_BAR  = 0x%016llx\n", in_be64(phb->regs + 0x190));
-   pr_deve

[PATCH 3/5] powerpc/powernv: Add option CONFIG_POWERNV_MSI

2013-04-23 Thread Gavin Shan
As Michael Ellerman suggested, to add CONFIG_POWERNV_MSI for PowerNV
platform. That's similar to CONFIG_PSERIES_MSI for pSeries platform.
For now, we don't make it dependent on CONFIG_EEH since it's not ready
to enable that yet.

Apart from that, we also enable CONFIG_PPC_MSI_BITMAP on selecting
CONFIG_POWERNV_MSI.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/Kconfig |5 +
 arch/powerpc/sysdev/Kconfig|1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/Kconfig 
b/arch/powerpc/platforms/powernv/Kconfig
index 74fea5c..d3e840d 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -8,6 +8,11 @@ config PPC_POWERNV
select PPC_PCI_CHOICE if EMBEDDED
default y
 
+config POWERNV_MSI
+   bool "Support PCI MSI on PowerNV platform"
+   depends on PCI_MSI
+   default y
+
 config PPC_POWERNV_RTAS
depends on PPC_POWERNV
bool "Support for RTAS based PowerNV platforms such as BML"
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index a84fecf..ab4cb54 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -19,6 +19,7 @@ config PPC_MSI_BITMAP
default y if MPIC
default y if FSL_PCI
default y if PPC4xx_MSI
+   default y if POWERNV_MSI
 
 source "arch/powerpc/sysdev/xics/Kconfig"
 
-- 
1.7.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 5/5] powerpc/powernv: TCE invalidation for PHB3

2013-04-23 Thread Gavin Shan
The TCE should be invalidated while it's created or free'd. The
approach to do that for IODA1 and IODA2 compliant PHBs are different.
So the patch differentiate them with virtualized interface hooked
to the PHB. It's notable that the PCI address is used to invalidate
the corresponding TCE on IODA2 compliant PHB3.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/include/asm/iommu.h|1 +
 arch/powerpc/platforms/powernv/pci-ioda.c   |   79 ++-
 arch/powerpc/platforms/powernv/pci-p5ioc2.c |2 +
 arch/powerpc/platforms/powernv/pci.c|   48 ++---
 arch/powerpc/platforms/powernv/pci.h|2 +
 5 files changed, 86 insertions(+), 46 deletions(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index cbfe678..0db308e 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -76,6 +76,7 @@ struct iommu_table {
struct iommu_pool large_pool;
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map;   /* A simple allocation bitmap for now */
+   void *sysdata;
 };
 
 struct scatterlist;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 8ec77a7..a4b1c9a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -448,6 +448,73 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, 
struct pci_bus *bus)
}
 }
 
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+u64 *startp, u64 *endp)
+{
+   u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+   unsigned long start, end, inc;
+
+   start = __pa(startp);
+   end = __pa(endp);
+
+   /* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
+   if (tbl->it_busno) {
+   start <<= 12;
+   end <<= 12;
+   inc = 128 << 12;
+   start |= tbl->it_busno;
+   end |= tbl->it_busno;
+   } else if (tbl->it_type & TCE_PCI_SWINV_PAIR) {
+   /* p7ioc-style invalidation, 2 TCEs per write */
+   start |= (1ull << 63);
+   end |= (1ull << 63);
+   inc = 16;
+} else {
+   /* Default (older HW) */
+inc = 128;
+   }
+
+end |= inc - 1;/* round up end to be different than start */
+
+mb(); /* Ensure above stores are visible */
+while (start <= end) {
+__raw_writeq(start, invalidate);
+start += inc;
+}
+
+   /*
+* The iommu layer will do another mb() for us on build()
+* and we don't care on free()
+*/
+}
+
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
+u64 *startp, u64 *endp)
+{
+   unsigned long start, end, inc;
+   u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+   struct pnv_ioda_pe *pe = container_of(tbl, struct pnv_ioda_pe,
+ tce32_table);
+
+   /* We'll invalidate DMA address in PE scope */
+   start = 0x2ul << 60;
+   start |= (pe->pe_number & 0xFF);
+   end = start;
+
+   /* Figure out the start, end and step */
+   inc = tbl->it_offset + (((u64)startp - tbl->it_base) / sizeof(u64));
+   start |= (inc << 12);
+   inc = tbl->it_offset + (((u64)endp - tbl->it_base) / sizeof(u64));
+   end |= (inc << 12);
+   inc = (0x1ul << 12);
+   mb();
+
+   while (start <= end) {
+   __raw_writeq(start, invalidate);
+   start += inc;
+   }
+}
+
 static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
  struct pnv_ioda_pe *pe, unsigned int base,
  unsigned int segs)
@@ -509,6 +576,9 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
pnv_pci_setup_iommu_table(tbl, addr, TCE32_TABLE_SIZE * segs,
  base << 28);
 
+   /* Hook the IOMMU table to PHB */
+   tbl->sysdata = phb;
+
/* OPAL variant of P7IOC SW invalidated TCEs */
swinvp = of_get_property(phb->hose->dn, "ibm,opal-tce-kill", NULL);
if (swinvp) {
@@ -519,8 +589,9 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
 */
tbl->it_busno = 0;
tbl->it_index = (unsigned long)ioremap(be64_to_cpup(swinvp), 8);
-   tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE
-   | TCE_PCI_SWINV_PAIR;
+   tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
+   if (phb->type == PNV_PHB_IODA1)
+   tbl->it_type |= TCE_PCI_SWINV_PAIR;
}
iommu_init_table(tbl, phb->hose->node);
 
@@ -1032,6 +1103,10 @@ void __init pnv_pci_init_ioda_phb(struct de

Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform

2013-04-23 Thread Michael Ellerman
On Tue, Apr 23, 2013 at 06:51:09PM +0800, Chen Yuanquan-B41889 wrote:
> On 04/23/2013 06:05 PM, Benjamin Herrenschmidt wrote:
> >On Tue, 2013-04-23 at 17:26 +0800, Chen Yuanquan-B41889 wrote:
> >>There's no response from Ben. How do you think about this patch?
> >>What's
> >>your advice?
> >Didn't Michael put your patch in -next while I was on vacation ? I'll
> >check tomorrow.
> >
> >Cheers,
> >Ben.
> >
> 
> Hi Ben,
> 
> I have checked the latest kernel(v3.9-rc7). This patch has been applied.

No it's not in v3.9-rc7.

It is in my test branch, which is in linux-next.

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit?id=37f02195bee9c25ce44e25204f40b7961a6d7c9d

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Dennis Schridde
Hello Michael!

Am Tue, 23 Apr 2013 19:12:47 +1000
schrieb Michael Ellerman :
> On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> For me it is fixed by applying the following patch, it should be in
> v3.10:

I am currently compiling the patched kernel. Will report back with the
results later.

> Does your cellminer actually work? ie. does it run OK?
> 
> I am using a fractal benchmark I had lying around, and it appears to
> work, and runs fast enough that it must be running on the SPUs (I
> think).
> 
> So it sounds like we have some weirdness with stuff not appearing in
> /spu, but spu programs are still able to run. Which is odd to say the
> least.

Yes, that seems to be exactly what I see here. The SPE code seems to be
actually running (cellminer reports SPU threads being created and it
runs at 42 Megahash/s - which is coming closer and closer to the
expected ~60Mh/s, given that I started with about 6Mh/s), just /spu is
empty.


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Dennis Schridde
Am Mon, 22 Apr 2013 18:44:13 +0200
schrieb Dennis Schridde :
> [4.] Kernel information
> 
> [4.1.] Kernel version (from /proc/version):
> I am using the Linux 3.8.8 kernel (vanilla-sources-3.8.8 on
> Gentoo/Linux): # cat /proc/version 
> Linux version 3.8.8 (root@blade00) (gcc version 4.7.2 (Gentoo
> 4.7.2-r1 p1.5, pie-0.5.5) ) #2 SMP Mon Apr 22 18:21:20 CEST 2013

Actually this is only partially correct.

I applied following patch by Grant Likely
 to fix some IRQ mapping problems:

diff --git a/arch/powerpc/platforms/cell/pmu.c
b/arch/powerpc/platforms/cell/pmu.c index 59c1a16..348a27b 100644
--- a/arch/powerpc/platforms/cell/pmu.c
+++ b/arch/powerpc/platforms/cell/pmu.c
@@ -382,7 +382,7 @@ static int __init cbe_init_pm_irq(void)
unsigned int irq;
int rc, node;

-   for_each_node(node) {
+   for_each_online_node(node) {
irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
   (node <<
  IIC_IRQ_NODE_SHIFT)); if (irq == NO_IRQ) {


And now I also applied the patch by Michael Ellerman
 that supposedly fixes the
all-processes-running-on-CPU0 issue - I will report back with results
later.

--Dennis


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()

2013-04-23 Thread Michael Ellerman
None of the cell platforms support CPU hotplug, so we should iterate
only over online nodes when setting PMU interrupts.

This also fixes a warning during boot when NODES_SHIFT is large enough:

WARNING: at /scratch/michael/src/kmk/linus/kernel/irq/irqdomain.c:766
...
NIP [c00db278] .irq_linear_revmap+0x30/0x58
LR [c00dc2a0] .irq_create_mapping+0x38/0x1a8
Call Trace:
[c003fc9c3af0] [c00dc2a0] .irq_create_mapping+0x38/0x1a8 
(unreliable)
[c003fc9c3b80] [c0655c1c] 
.__machine_initcall_cell_cbe_init_pm_irq+0x84/0x158
[c003fc9c3c20] [c000afb4] .do_one_initcall+0x5c/0x1e0
[c003fc9c3cd0] [c0644580] .kernel_init_freeable+0x238/0x328
[c003fc9c3db0] [c000b784] .kernel_init+0x1c/0x120
[c003fc9c3e30] [c0009fb8] .ret_from_kernel_thread+0x64/0xac

This is caused by us overflowing our linear revmap because we're
requesting too many interrupts.

Reported-by: Dennis Schridde 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/cell/pmu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/pmu.c 
b/arch/powerpc/platforms/cell/pmu.c
index 59c1a16..348a27b 100644
--- a/arch/powerpc/platforms/cell/pmu.c
+++ b/arch/powerpc/platforms/cell/pmu.c
@@ -382,7 +382,7 @@ static int __init cbe_init_pm_irq(void)
unsigned int irq;
int rc, node;
 
-   for_each_node(node) {
+   for_each_online_node(node) {
irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
   (node << IIC_IRQ_NODE_SHIFT));
if (irq == NO_IRQ) {
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Michael Ellerman
On Tue, Apr 23, 2013 at 02:01:16PM +0200, Dennis Schridde wrote:
> Am Mon, 22 Apr 2013 18:44:13 +0200
> schrieb Dennis Schridde :
> > [4.] Kernel information
> > 
> > [4.1.] Kernel version (from /proc/version):
> > I am using the Linux 3.8.8 kernel (vanilla-sources-3.8.8 on
> > Gentoo/Linux): # cat /proc/version 
> > Linux version 3.8.8 (root@blade00) (gcc version 4.7.2 (Gentoo
> > 4.7.2-r1 p1.5, pie-0.5.5) ) #2 SMP Mon Apr 22 18:21:20 CEST 2013
> 
> Actually this is only partially correct.
> 
> I applied following patch by Grant Likely
>  to fix some IRQ mapping problems:

Ah yes, I forgot I also have basically the same patch. I've just sent it
to the list.

We appear to have a number of problems with the irq mapping on cell,
that patch fixes the worst of them but there are more.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Dennis Schridde
Am Dienstag, 23. April 2013, 22:16:21 schrieb Michael Ellerman:
> On Tue, Apr 23, 2013 at 02:01:16PM +0200, Dennis Schridde wrote:
> > I applied following patch by Grant Likely
> >  to fix some IRQ mapping problems:
> Ah yes, I forgot I also have basically the same patch. I've just sent it
> to the list.
> 
> We appear to have a number of problems with the irq mapping on cell,
> that patch fixes the worst of them but there are more.

Yes, and it would be great if that patch could actually be merged (I have been 
using it since November, but Grant apparently never merged it) and maybe the 
other problems could be solved, too. I am willing to assist in debugging and 
testing.

--Dennis

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Michael Ellerman
On Tue, Apr 23, 2013 at 02:41:18PM +0200, Dennis Schridde wrote:
> Am Dienstag, 23. April 2013, 22:16:21 schrieb Michael Ellerman:
> > On Tue, Apr 23, 2013 at 02:01:16PM +0200, Dennis Schridde wrote:
> > > I applied following patch by Grant Likely
> > >  to fix some IRQ mapping problems:
> > Ah yes, I forgot I also have basically the same patch. I've just sent it
> > to the list.
> > 
> > We appear to have a number of problems with the irq mapping on cell,
> > that patch fixes the worst of them but there are more.
> 
> Yes, and it would be great if that patch could actually be merged (I have 
> been 
> using it since November, but Grant apparently never merged it) and maybe the 
> other problems could be solved, too. I am willing to assist in debugging and 
> testing.

Yeah, it's not really Grant's patch to merge, so that's our fault. Ben
will merge it this cycle via the powerpc tree.

I'll reply to your other mail on the other issues.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.

2013-04-23 Thread Joerg Roedel
On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote:
> +#ifndef __PCI_H
> +#define __PCI_H

Using __PCI_H is not a wise choice, it has certainly a high risk of a
collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch.


Joerg


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()

2013-04-23 Thread Michael Ellerman
On Tue, Apr 23, 2013 at 02:45:50PM +0200, Dennis Schridde wrote:
> Hello everyone!
> 
> I have been testing this patch (given to me by Grant Likely 
> ) with various kernel versions (3.6.2, 3.6.11, 
> 3.8.6, 3.8.8) since November and can confirm that it solves part of the IRQ 
> mapping issue on Cell (namely the one Michael mentioned) and does not cause 
> any additional noticable problems.
> 
> Some problems remain after this patch, as can be seen in the attached 
> dmesg.log. If further information is required to debug this, or you need some 
> help in testing more patches, please contact me.

..

This one below I really don't understand.

It's saying that the domain->ops->map() returned -22.

But as far as I can see all the map routines we have on cell return
success unconditionally. So something strange is going on. I'll have to
dig into a bit more.

> [0.490734] irq: irq-93==>hwirq-0x5d mapping failed: -22
> [0.522130] [ cut here ]
> [0.549706] WARNING: at 
> /usr/src/linux-3.8.6-aufs/kernel/irq/irqdomain.c:467
> [0.591895] Modules linked in:
> [0.610126] NIP: c00bdeac LR: c00bdea8 CTR: 
> c0025670
> [0.652317] REGS: c000fe667190 TRAP: 0700   Not tainted  (3.8.6-aufs)
> [0.692940] MSR: 90029032   CR: 4424  
> XER: 
> [0.739817] SOFTE: 1
> [0.752840] TASK = c000fe668000[1] 'swapper/0' THREAD: 
> c000fe664000 CPU: 0
> GPR00: c00bdea8 c000fe667410 c0699cb0 002c 
> GPR04:  78e26d37 0008  
> GPR08: 78eef1c4    
> GPR12: d700 cfffb000 c000a460  
> GPR16:     
> GPR20:   c000fe006078 005e 
> GPR24: 0174 005d 005d c000fe65fc00 
> GPR28: c000fe006060 005d c0643be0 005d 
> [1.119009] NIP [c00bdeac] .irq_domain_associate_many+0x264/0x290
> [1.159628] LR [c00bdea8] .irq_domain_associate_many+0x260/0x290
> [1.199731] Call Trace:
> [1.214318] [c000fe667410] [c00bdea8] 
> .irq_domain_associate_many+0x260/0x290 (unreliable)
> [1.269528] [c000fe6674e0] [c00be928] 
> .irq_create_mapping+0xc8/0x1d0
> [1.313801] [c000fe667580] [c00bead8] 
> .irq_create_of_mapping+0xa8/0x170
> [1.359639] [c000fe667630] [c0290c30] 
> .irq_of_parse_and_map+0x40/0x58
> [1.404429] [c000fe6676c0] [c0290df0] .of_irq_count+0x30/0x58
> [1.445057] [c000fe667750] [c029182c] 
> .of_device_alloc+0x1ec/0x288
> [1.488287] [c000fe667850] [c029191c] 
> .of_platform_device_create_pdata+0x54/0xf8
> [1.538810] [c000fe6678f0] [c0291b04] 
> .of_platform_bus_create+0x144/0x1e0
> [1.585687] [c000fe6679e0] [c0291b60] 
> .of_platform_bus_create+0x1a0/0x1e0
> [1.632564] [c000fe667ad0] [c0291d50] 
> .of_platform_bus_probe+0xd0/0x140
> [1.678404] [c000fe667b70] [c04109e4] 
> .__machine_initcall_cell_cell_publish_devices+0x54/0x1b0
> [1.736219] [c000fe667c40] [c0009e70] 
> .do_one_initcall+0x168/0x1d0
> [1.779445] [c000fe667d00] [c03ffb6c] 
> .kernel_init_freeable+0x14c/0x21c
> [1.825281] [c000fe667db0] [c000a47c] .kernel_init+0x1c/0x108
> [1.865907] [c000fe667e30] [c0008cd8] 
> .ret_from_kernel_thread+0x64/0x8c
> [1.911738] Instruction dump:
> [1.929448] 7fa4eb78 7ca507b4 4828c965 6000 0fe0 3860ffea 4b80 
> e87e8020 
> [1.975803] 7fa4eb78 7fe5fb78 4828c945 6000 <0fe0> 3920 
> 7f83e378 7f44d378 
> [2.023213] ---[ end trace 093b23e74665976f ]---

...

> [   23.270411] Setting up PCI bus 
> /axon@300/plb5/pciex@a0a0
> [   23.312464] PCI host bridge /axon@300/plb5/pciex@a0a0  
> ranges:
> [   23.357765]   IO 0x03a1..0x03a1 -> 
> 0x
> [   23.400470]  MEM 0x03c08000..0x03c0bfff -> 
> 0x8000 
> [   23.443702]  MEM 0x03c0c000..0x03c0 -> 
> 0xc000 Prefetch
> [   23.491188] of-pci D3802400.pciex: PCI host bridge to bus 0004:00
> [   23.529643] pci_bus 0004:00: root bus resource [io  0x54000-0x63fff] (bus 
> address [0x-0x])
> [   23.583289] pci_bus 0004:00: root bus resource [mem 
> 0x3c08000-0x3c0bfff] (bus address [0x8000-0xbfff])
> [   23.647356] pci_bus 0004:00: root bus resource [mem 
> 0x3c0c000-0x3c0 pref] (bus address [0xc000-0x])
> [   23.714024] pci_bus 0004:00: root bus resource [bus 00-ff]
> [   23.746836] pci_bus 0004:00: busn_res: [bus 00-ff] end is updated to ff
> [   23.746935] pci 0004:00:0

RE: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.

2013-04-23 Thread Sethi Varun-B16395
Thanks.

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel
> Sent: Tuesday, April 23, 2013 6:32 PM
> To: Sethi Varun-B16395
> Cc: ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-
> B08248; linux-ker...@vger.kernel.org; io...@lists.linux-foundation.org;
> Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.
> 
> On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote:
> > +#ifndef __PCI_H
> > +#define __PCI_H
> 
> Using __PCI_H is not a wise choice, it has certainly a high risk of a
> collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch.
> 
> 
>   Joerg
> 
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Dennis Schridde
Hello!

Am Dienstag, 23. April 2013, 13:51:55 schrieb Dennis Schridde:
> Am Tue, 23 Apr 2013 19:12:47 +1000
> schrieb Michael Ellerman :
> > On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > For me it is fixed by applying the following patch, it should be in
> > v3.10:
> I am currently compiling the patched kernel. Will report back with the
> results later.

Thanks! The patch has the intended result on my Linux 3.8.8 kernel. All 4 CPU 
cores are now being used and the cellminer hashrate went up from 42Mh/s to 
62Mh/s (with 2 PPE and 16 SPE threads, just as before).

Could it be backported, especially to 3.8?

Again - thanks for your work and quick reply,
Dennis

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Michael Ellerman
On Tue, Apr 23, 2013 at 03:16:53PM +0200, Dennis Schridde wrote:
> Hello!
> 
> Am Dienstag, 23. April 2013, 13:51:55 schrieb Dennis Schridde:
> > Am Tue, 23 Apr 2013 19:12:47 +1000
> > schrieb Michael Ellerman :
> > > On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > > For me it is fixed by applying the following patch, it should be in
> > > v3.10:
> > I am currently compiling the patched kernel. Will report back with the
> > results later.
> 
> Thanks! The patch has the intended result on my Linux 3.8.8 kernel. All 4 CPU 
> cores are now being used and the cellminer hashrate went up from 42Mh/s to 
> 62Mh/s (with 2 PPE and 16 SPE threads, just as before).

Excellent.

> Could it be backported, especially to 3.8?

Yes we'll send it to stable.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Michael Ellerman
On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> Hello!
> 
> 
> [1.] One line summary of the problem:
> .. no threads shown in spufs

So I think I've got this one fixed, this works for me, can you test it
please?

I'll send a proper patch in the morning.

cheers

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 3f3bb4c..35f77a4 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -99,6 +99,7 @@ spufs_new_inode(struct super_block *sb, umode_t mode)
if (!inode)
goto out;
 
+   inode->i_ino = get_next_ino();
inode->i_mode = mode;
inode->i_uid = current_fsuid();
inode->i_gid = current_fsgid();
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()

2013-04-23 Thread Dennis Schridde
Hello!

Please find an up-to-date dmesg log attached. It was created from a Linux 
3.8.8 kernel with these two patches applied:
-   for_each_node(node) {
+   for_each_online_node(node) {

-   return distance;
+   return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);

More information on the setup (incl. config and lspci) can be found in:
Subject: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads 
shown in spufs
Message-ID: <1470334.YUWOQ37ijW@ernie>

Am Dienstag, 23. April 2013, 23:02:19 schrieb Michael Ellerman:
> On Tue, Apr 23, 2013 at 02:45:50PM +0200, Dennis Schridde wrote:
> This is probably not good, but I'll have to compare to an old kernel to
> be sure. Have you noticed that PCI is broken in any way?

How do I find out?

The only thing I noticed (and someone else, who has been contacting me about 
cellminer questions recently) is that there might be something weird going on 
with the network.
For example, on RHEL5 we had issues with NFS loosing connection to the server 
(the x86-64 server directly in the same rack).
And now me and the other guy notice that the connection to the Eligius bitcoin 
mining pool is a bit flakey - apparently not transmitting all our work.
But this might also be caused by bugs in cellminer or Ruby - and the RHEL5 
issue is very certainly not related, since now on Gentoo/Linux, with a current 
kernel, the problem is gone.

--Dennis

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

2013-04-23 Thread Joerg Roedel
On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> Added the following domain attributes for the FSL PAMU driver:
> 1. Added new iommu stash attribute, which allows setting of the
>LIODN specific stash id parameter through IOMMU API.
> 2. Added an attribute for enabling/disabling DMA to a particular
>memory window.
> 3. Added domain attribute to check for PAMUV1 specific constraints.
> 
> Signed-off-by: Varun Sethi 
> ---
> v14 changes:
> - Add FSL prefix to PAMU attributes.
> v13 changes:
> - created a new file include/linux/fsl_pamu_stash.h for stash
> attributes.
> v12 changes:
> - Moved PAMU specifc stash ids and structures to PAMU header file.
> - no change in v11.
> - no change in v10.
>  include/linux/fsl_pamu_stash.h |   39 +++

Isn't asm/ for your architecture a better place for that header?


Joerg


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

2013-04-23 Thread Sethi Varun-B16395


> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Tuesday, April 23, 2013 7:09 PM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> linux-ker...@vger.kernel.org; ga...@kernel.crashing.org;
> b...@kernel.crashing.org; Yoder Stuart-B08248; Wood Scott-B07421
> Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes
> required by the PAMU driver.
> 
> On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> > Added the following domain attributes for the FSL PAMU driver:
> > 1. Added new iommu stash attribute, which allows setting of the
> >LIODN specific stash id parameter through IOMMU API.
> > 2. Added an attribute for enabling/disabling DMA to a particular
> >memory window.
> > 3. Added domain attribute to check for PAMUV1 specific constraints.
> >
> > Signed-off-by: Varun Sethi 
> > ---
> > v14 changes:
> > - Add FSL prefix to PAMU attributes.
> > v13 changes:
> > - created a new file include/linux/fsl_pamu_stash.h for stash
> > attributes.
> > v12 changes:
> > - Moved PAMU specifc stash ids and structures to PAMU header file.
> > - no change in v11.
> > - no change in v10.
> >  include/linux/fsl_pamu_stash.h |   39
> +++
> 
> Isn't asm/ for your architecture a better place for that header?
> 
I think it's fine to have the header under linux, actually I also the 
intel-iommu header under linux.

-Varun


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC, PATCH] powerpc/prom: Scan reserved-ranges node for memory reservations

2013-04-23 Thread Jeremy Kerr
Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr 

---
 arch/powerpc/kernel/prom.c |   36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..1208c8f 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,34 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = ((unsigned long)initial_boot_params) +
+   be32_to_cpu(initial_boot_params->off_dt_struct);
+
+   prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each */
+   for (i = 0; i < len / sizeof(*prop);
+   i += dt_root_addr_cells + dt_root_size_cells) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4), 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +602,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params->totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 1/2] powerpc/rtas_flash: Update return token comments

2013-04-23 Thread Vasant Hegde
Add proper comment to ibm,validate-flash-image RTAS call
update result tokens.

Note: Only comment section is modified, no code change.

Signed-off-by: Vasant Hegde 
Signed-off-by: Ananth N Mavinakayanahalli 
---
 arch/powerpc/kernel/rtas_flash.c |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index a7020d2..bc97a21 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -57,13 +57,26 @@
 #define VALIDATE_READY-1001 /* Firmware image ready for validation */
 #define VALIDATE_PARAM_ERR -3/* RTAS Parameter Error */
 #define VALIDATE_HW_ERR-1/* RTAS Hardware Error */
-#define VALIDATE_TMP_UPDATE0 /* Validate Return Status */
-#define VALIDATE_FLASH_AUTH1 /* Validate Return Status */
-#define VALIDATE_INVALID_IMG   2 /* Validate Return Status */
-#define VALIDATE_CUR_UNKNOWN   3 /* Validate Return Status */
-#define VALIDATE_TMP_COMMIT_DL 4 /* Validate Return Status */
-#define VALIDATE_TMP_COMMIT5 /* Validate Return Status */
-#define VALIDATE_TMP_UPDATE_DL 6 /* Validate Return Status */
+
+/* ibm,validate-flash-image update result tokens */
+#define VALIDATE_TMP_UPDATE0 /* T side will be updated */
+#define VALIDATE_FLASH_AUTH1 /* Partition does not have authority */
+#define VALIDATE_INVALID_IMG   2 /* Candidate image is not valid */
+#define VALIDATE_CUR_UNKNOWN   3 /* Current fixpack level is unknown */
+/*
+ * Current T side will be committed to P side before being replace with new
+ * image, and the new image is downlevel from current image
+ */
+#define VALIDATE_TMP_COMMIT_DL 4
+/*
+ * Current T side will be committed to P side before being replaced with new
+ * image
+ */
+#define VALIDATE_TMP_COMMIT5
+/*
+ * T side will be updated with a downlevel image
+ */
+#define VALIDATE_TMP_UPDATE_DL 6
 
 /* ibm,manage-flash-image operation tokens */
 #define RTAS_REJECT_TMP_IMG   0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 2/2] powerpc/rtas_flash: New return code to indicate FW entitlement expiry

2013-04-23 Thread Vasant Hegde
Add new return code to rtas_flash to indicate firmware entitlement
expiry. Strictly we don't need this update. But to keep it in sync
with PAPR, this was added.

Signed-off-by: Ananth N Mavinakayanahalli 
Signed-off-by: Vasant Hegde 
---
 arch/powerpc/kernel/rtas_flash.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index bc97a21..a3e4034 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -77,6 +77,11 @@
  * T side will be updated with a downlevel image
  */
 #define VALIDATE_TMP_UPDATE_DL 6
+/*
+ * The candidate image's release date is later than the system's firmware
+ * service entitlement date - service warranty period has expired
+ */
+#define VALIDATE_OUT_OF_WRNTY  7

 /* ibm,manage-flash-image operation tokens */
 #define RTAS_REJECT_TMP_IMG   0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data

2013-04-23 Thread Kumar Gala

On Apr 23, 2013, at 12:44 AM, Zang Roy-R61911 wrote:

> 
> 
>> -Original Message-
>> From: Zang Roy-R61911
>> Sent: Tuesday, April 23, 2013 2:36 AM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: ga...@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889
>> Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
>>> private_data
>> 
>> pci hose->private_data will be used by other function, for example,
>> fsl_pcie_check_link(), so do not iounmap it.
>> 
>> fix the kerenl crash on T4240:
>> 
>> Unable to handle kernel paging request for data at address
>> 0x880080060f14
>> Faulting instruction address: 0xc0032554
>> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 T4240 QDS
>> Modules linked in:
>> NIP: c0032554 LR: c003254c CTR: c001e5c0
>> REGS: c00179143440 TRAP: 0300   Not tainted
>> (3.8.8-rt2-00754-g951f064-dirt)
>> MSR: 80029000   CR: 24adbe22  XER: 
>> SOFTE: 0
>> DEAR: 880080060f14, ESR:  TASK = c0017913d2c0[1]
>> 'swapper/0' THREAD: c0017914 CPU: 2
>> GPR00: c003254c c001791436c0 c0ae2998
>> 0027
>> GPR04:  05a5 
>> 0002
>> GPR08: 3030303038303038 c0a2d4d0 c0aebeb8
>> c0af2998
>> GPR12: 24adbe22 cfffa800 c0001be0
>> 
>> GPR16:   
>> 
>> GPR20:   
>> c09ddf70
>> GPR24: c09e8d40 c0af2998 c0b1529c
>> c00179143b40
>> GPR28: c001799b4000 c00179143c00 88008006
>> c0727ec8
>> NIP [c0032554] .fsl_pcie_check_link+0x104/0x150 LR
>> [c003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace:
>> [c001791436c0] [c003254c] .fsl_pcie_check_link+0xfc/0x150
>> (unreliab)
>> [c00179143a30] [c00325d4]
>> .fsl_indirect_read_config+0x34/0xb0
>> [c00179143ad0] [c02c7ee8]
>> .pci_bus_read_config_byte+0x88/0xd0
>> [c00179143b90] [c09c0528] .pci_apply_final_quirks+0x9c/0x18c
>> [c00179143c40] [c000142c] .do_one_initcall+0x5c/0x1f0
>> [c00179143cf0] [c09a0bb4] .kernel_init_freeable+0x180/0x264
>> [c00179143db0] [c0001bfc] .kernel_init+0x1c/0x420
>> [c00179143e30] [c8b4] .ret_from_kernel_thread+0x64/0xb0
>> Instruction dump:
>> 6000 4ba0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
>> 7fc5f378 486ea77d 6000 7c0004ac <801e0f14> 0c00 4c00012c 3c62ffe0
>> ---[ end trace f841fbc03c9d2e1b ]---
>> 
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
>> 
>> Rebooting in 180 seconds..
>> 
>> Signed-off-by: Yuanquan Chen 
>> Signed-off-by: Roy Zang 
>> ---
>> based on Kumar's next branch.
>> tested on P3041 and T4240.
> Please ignore this patch, I will send a v2 version.
> Thanks.
> Roy

Ok, did you see this patch:

http://patchwork.ozlabs.org/patch/236293/

- k

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data

2013-04-23 Thread Zang Roy-R61911


> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale@lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Tuesday, April 23, 2013 10:29 PM
> To: Zang Roy-R61911
> Cc: linuxppc-dev@lists.ozlabs.org; Chen Yuanquan-B41889
> Subject: Re: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
> >private_data
> 
> 
> On Apr 23, 2013, at 12:44 AM, Zang Roy-R61911 wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Zang Roy-R61911
> >> Sent: Tuesday, April 23, 2013 2:36 AM
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: ga...@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889
> >> Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
> >>> private_data
> >>
> >> pci hose->private_data will be used by other function, for example,
> >> fsl_pcie_check_link(), so do not iounmap it.
> >>
> >> fix the kerenl crash on T4240:
> >>
> >> Unable to handle kernel paging request for data at address
> >> 0x880080060f14
> >> Faulting instruction address: 0xc0032554
> >> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 T4240
> >> QDS Modules linked in:
> >> NIP: c0032554 LR: c003254c CTR: c001e5c0
> >> REGS: c00179143440 TRAP: 0300   Not tainted
> >> (3.8.8-rt2-00754-g951f064-dirt)
> >> MSR: 80029000   CR: 24adbe22  XER: 
> >> SOFTE: 0
> >> DEAR: 880080060f14, ESR:  TASK =
> >> c0017913d2c0[1] 'swapper/0' THREAD: c0017914 CPU: 2
> >> GPR00: c003254c c001791436c0 c0ae2998
> >> 0027
> >> GPR04:  05a5 
> >> 0002
> >> GPR08: 3030303038303038 c0a2d4d0 c0aebeb8
> >> c0af2998
> >> GPR12: 24adbe22 cfffa800 c0001be0
> >> 
> >> GPR16:   
> >> 
> >> GPR20:   
> >> c09ddf70
> >> GPR24: c09e8d40 c0af2998 c0b1529c
> >> c00179143b40
> >> GPR28: c001799b4000 c00179143c00 88008006
> >> c0727ec8
> >> NIP [c0032554] .fsl_pcie_check_link+0x104/0x150 LR
> >> [c003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace:
> >> [c001791436c0] [c003254c] .fsl_pcie_check_link+0xfc/0x150
> >> (unreliab)
> >> [c00179143a30] [c00325d4]
> >> .fsl_indirect_read_config+0x34/0xb0
> >> [c00179143ad0] [c02c7ee8]
> >> .pci_bus_read_config_byte+0x88/0xd0
> >> [c00179143b90] [c09c0528]
> >> .pci_apply_final_quirks+0x9c/0x18c
> >> [c00179143c40] [c000142c] .do_one_initcall+0x5c/0x1f0
> >> [c00179143cf0] [c09a0bb4]
> >> .kernel_init_freeable+0x180/0x264 [c00179143db0]
> >> [c0001bfc] .kernel_init+0x1c/0x420 [c00179143e30]
> >> [c8b4] .ret_from_kernel_thread+0x64/0xb0 Instruction dump:
> >> 6000 4ba0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78
> >> 7fe4fb78
> >> 7fc5f378 486ea77d 6000 7c0004ac <801e0f14> 0c00 4c00012c
> >> 3c62ffe0 ---[ end trace f841fbc03c9d2e1b ]---
> >>
> >> Kernel panic - not syncing: Attempted to kill init!
> >> exitcode=0x000b
> >>
> >> Rebooting in 180 seconds..
> >>
> >> Signed-off-by: Yuanquan Chen 
> >> Signed-off-by: Roy Zang 
> >> ---
> >> based on Kumar's next branch.
> >> tested on P3041 and T4240.
> > Please ignore this patch, I will send a v2 version.
> > Thanks.
> > Roy
> 
> Ok, did you see this patch:
> 
> http://patchwork.ozlabs.org/patch/236293/
Kevin remaindered me after I sent the v2 version.
You can pick up that one.
I add a ack to that patch.
Roy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


arch/powerpc/mm/mmap_64.c on 32bit systems?

2013-04-23 Thread Daniel Walker
Hi all,


I was looking at this file, and it looks like it could be used on 32bit
systems. There's patches in the history to add stuff accounting for both
32bits and 64bits .. My assumption was that it's not used because there
are many people who want it on 32bits, and so it hasn't been tested..

Can anyone shed some light on why it's not used for 32bit systems?

Thanks,
Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/5] powerpc/powernv: Supports PHB3

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
> -/* Fixup wrong class code in p7ioc root complex */
> +/* Fixup wrong class code in p7ioc and p8 root complex */
>  static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
>  {
> dev->class = PCI_CLASS_BRIDGE_PCI << 8;
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x3b9, pnv_p7ioc_rc_quirk);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x2da, pnv_p7ioc_rc_quirk);
>  
This can go away from the normal patch, it is only necessary to work
around a problem in the simulator. The real PHB3 doesn't need the
workaround (p7ioc still does).

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/5] powerpc/powernv: Patch MSI EOI handler on P8

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
> 
> +static int pnv_pci_ioda_msi_eoi(struct pnv_phb *phb, unsigned int hw_irq)
> +{
> +   u8 p_bit = 1, q_bit = 1;
> +   long rc;
> +
> +   while (p_bit || q_bit) {
> +   rc = opal_pci_get_xive_reissue(phb->opal_id,
> +   hw_irq - phb->msi_base, &p_bit, &q_bit);
> +   if (rc) {
> +   pr_warning("%s: Failed to get P/Q bits of IRQ#%d "
> +  "on PHB#%d, rc=%ld\n", __func__, hw_irq,
> +  phb->hose->global_number, rc);
> +   return -EIO;
> +   }
> +   if (!p_bit && !q_bit)
> +   break;
> +
> +   rc = opal_pci_set_xive_reissue(phb->opal_id,
> +   hw_irq - phb->msi_base, p_bit, q_bit);
> +   if (rc) {
> +   pr_warning("%s: Failed to clear P/Q (%01d/%01d) of "
> +  "IRQ#%d on PHB#%d, rc=%ld\n", __func__,
> +  p_bit, q_bit, hw_irq,
> +  phb->hose->global_number, rc);
> +   return -EIO;
> +   }
> +   }
> +
> +   return 0;
> +}

Can you turn that into a single opal_pci_msi_eoi() ? This means that a
single MSI will trigger only one OPAL call rather than two which is
better for performances.

We will later implement an "optimized" variant using direct MMIO based
on knowing specifically the HW type but not now.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

2013-04-23 Thread Yoder Stuart-B08248


> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Tuesday, April 23, 2013 8:39 AM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; 
> linux-ker...@vger.kernel.org;
> ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248; 
> Wood Scott-B07421
> Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes 
> required by the PAMU driver.
> 
> On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> > Added the following domain attributes for the FSL PAMU driver:
> > 1. Added new iommu stash attribute, which allows setting of the
> >LIODN specific stash id parameter through IOMMU API.
> > 2. Added an attribute for enabling/disabling DMA to a particular
> >memory window.
> > 3. Added domain attribute to check for PAMUV1 specific constraints.
> >
> > Signed-off-by: Varun Sethi 
> > ---
> > v14 changes:
> > - Add FSL prefix to PAMU attributes.
> > v13 changes:
> > - created a new file include/linux/fsl_pamu_stash.h for stash
> > attributes.
> > v12 changes:
> > - Moved PAMU specifc stash ids and structures to PAMU header file.
> > - no change in v11.
> > - no change in v10.
> >  include/linux/fsl_pamu_stash.h |   39 
> > +++
> 
> Isn't asm/ for your architecture a better place for that header?

The PAMU isn't strictly tied to Power architecture, although
that is where it is implemented now.  It could be implemented
on ARM for example.

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 5/5] powerpc/powernv: TCE invalidation for PHB3

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
>  * of flags if that becomes the case
>  */
> if (tbl->it_type & TCE_PCI_SWINV_CREATE)
> -   pnv_tce_invalidate(tbl, tces, tcep - 1);
> +   phb->dma_tce_invalidate(tbl, tces, tcep - 1);
>  
> return 0;
>  }

TCE invalidate is very performance sensitive, we might be better off
doing the if (ioda_type == PNV_PHB_IODA1) ... else ... here (which
the CPU can generally predict) rather than a function pointer call
which can be more tricky.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-04-23 Thread Dennis Schridde
Am Dienstag, 23. April 2013, 23:24:36 schrieb Michael Ellerman:
> On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > [1.] One line summary of the problem:
> > .. no threads shown in spufs
> 
> So I think I've got this one fixed, this works for me, can you test it
> please?
Patch works - spu-top outputs threads and there are directories in /spu now.

Please also backport this to 3.8, just like the IRQ and NUMA patches. :)

Thanks!
--Dennis

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/12] Create a powerpc update_devicetree interface

2013-04-23 Thread Nathan Fontenot
On 04/22/2013 07:15 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-22 at 13:30 -0500, Nathan Fontenot wrote:
> 
>> This patch exposes a method for updating the device tree via
>> ppc_md.update_devicetree that takes a single 32-bit value as a parameter.
>> For pseries platforms this is the existing pseries_devicetree_update routine
>> which is updated to take the new parameter which is a scope value
>> to indicate the the reason for making the rtas calls. This parameter is
>> required by the ibm,update-nodes/ibm,update-properties RTAS calls, and
>> the appropriate value is contained within the RTAS event for PRRN
>> notifications. In pseries_devicetree_update() it was previously
>> hard-coded to 1, the scope value for partition migration.
> 
> I think that's too much abstraction (see below)
> 
> Also you add this helper:
> 
>> Index: powerpc/arch/powerpc/kernel/rtas.c
>> ===
>> --- powerpc.orig/arch/powerpc/kernel/rtas.c  2013-03-08 19:23:06.0 
>> -0600
>> +++ powerpc/arch/powerpc/kernel/rtas.c   2013-04-17 13:02:29.0 
>> -0500
>> @@ -1085,3 +1085,13 @@
>>  timebase = 0;
>>  arch_spin_unlock(&timebase_lock);
>>  }
>> +
>> +int update_devicetree(s32 scope)
>> +{
>> +int rc = 0;
>> +
>> +if (ppc_md.update_devicetree)
>> +rc = ppc_md.update_devicetree(scope);
>> +
>> +return rc;
>> +}
> 
> But then don't use it afaik (you call directly ppc_md.update_... from
> prrn_work_fn().
> 
> In the end, the caller (PRRN stuff), while in rtasd, is really pseries
> specific and the resulting update_device_tree() as well, so I don't
> think we need the ppc_md. hook in the middle with that "oddball" scope
> parameter which is not defined outside of pseries specific areas.
> 
> In this case, it might be better to make sure the PRRN related stuff in
> rtasd is inside an ifdef CONFIG_PPC_PSERIES and have it call directly
> into pseries_update_devicetree().
> 
> It makes the code somewhat easier to follow and I doubt anybody else
> will ever use that specific hook, at least not in its current form. If
> we need an abstraction later, we can add one then.
> 

ok, good. I was not crazy about using ppc_md to do this and if you're fine
with putting the pseries specific stuff in ifdef CONFIG_PPC_PSERIES I'll
update the code to do that.

Question concerning rtas code. There is quite a bit of pseries specific 
pieces in the general powerpc/kernel directory. Has there been, or should
there be, any effort to move that to the pseries directory?

-Nathan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 5/12] Update firmware_has_feature() to check architecture bits

2013-04-23 Thread Nathan Fontenot
On 04/22/2013 08:50 PM, Stephen Rothwell wrote:
> Hi Nathan,
> 
> On Mon, 22 Apr 2013 13:38:47 -0500 Nathan Fontenot  
> wrote:
>>
>> -/* Option vector 5: PAPR/OF options supported */
>> -#define OV5_LPAR0x80/* logical partitioning supported */
>> -#define OV5_SPLPAR  0x40/* shared-processor LPAR supported */
>> +/* Option vector 5: PAPR/OF options supported
>> + * Thses bits are also used for the platform_has_feature() call so
>   ^
> typo

will fix.

> 
>> + * we encode the vector index in the define and use the OV5_FEAT()
>> + * and OV5_INDX() macros to extract the desired information.
>> + */
>> +#define OV5_FEAT(x) ((x) & 0xff)
>> +#define OV5_INDX(x) ((x) >> 8)
>> +#define OV5_LPAR0x0280  /* logical partitioning supported */
>> +#define OV5_SPLPAR  0x0240  /* shared-processor LPAR supported */
> 
> Wouldn't it be clearer to say
> 
> #define OV5_LPAR  (OV5_INDX(0x2) | OV5_FEAT(0x80))

The defines won't work the way you used them, they were designed to take the
combined value, i.e. 0x0280, and parse out the index and the feature.

I do think having macros to create the actual values as your example does is 
easier
to read. We could do something like...

#define OV5_FEAT(x) ((x) & 0xff)
#define OV5_SETINDX(x)  ((x) << 8)
#define OV5_GETINDX(x)  ((x) >> 8)

#define OV5_LPAR(OV5_SETINDX(0x2) | OV5_FEAT(0x80))

Thoughts?

> 
> etc?
> 
>> @@ -145,6 +141,7 @@
>>   * followed by # option vectors - 1, followed by the option vectors.
>>   */
>>  extern unsigned char ibm_architecture_vec[];
>> +bool platform_has_feature(unsigned int);
> 
> "extern", please (if nothing else, for consistency).
> 

That shouldn't really be there, its an artifact from a previous patch. I'll 
remove it.

>> +static __initdata struct vec5_fw_feature
>> +vec5_fw_features_table[FIRMWARE_MAX_FEATURES] = {
> 
> Why make this array FIRMWARE_MAX_FEATURES (63) long?  You could just
> restrict the for loop below to ARRAY_SIZE(vec5_fw_features_table).
> 
>> +{FW_FEATURE_TYPE1_AFFINITY, OV5_TYPE1_AFFINITY},
>> +};
>> +
>> +void __init fw_vec5_feature_init(const char *vec5, unsigned long len)
>> +{
>> +unsigned int index, feat;
>> +int i;
>> +
>> +pr_debug(" -> fw_vec5_feature_init()\n");
>> +
>> +for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
>> +if (!vec5_fw_features_table[i].feature)
>> +continue;
> 
> And this test could go away.
> 
> I realise that you have just copied the existing code, but you should not
> do that blindly.  Maybe you could even add an (earlier) patch that fixes
> the existing code.

I think that could be done easily enough.

Thanks for looking,
-Nathan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 7/12] Use stop machine to update cpu maps

2013-04-23 Thread Nathan Fontenot
On 04/22/2013 07:24 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-22 at 13:41 -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew 
>>
>> 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.
> 
> I see no more mention of stop_machine() ... is the patch subject stale ?
> 

Nope, just me mistakenly putting the wrong subject for this patch. I'll
correct it in the next version.

-Nathan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 12/12] Add /proc interface to control topology updates

2013-04-23 Thread Nathan Fontenot
On 04/22/2013 09:49 PM, Michael Ellerman wrote:
> On Tue, Apr 23, 2013 at 12:00:26PM +1000, Stephen Rothwell wrote:
>> Hi Nathan,
>>
>> On Mon, 22 Apr 2013 13:47:55 -0500 Nathan Fontenot 
>>  wrote:
>>>
>>>  #if defined(CONFIG_NUMA) && defined(CONFIG_PPC_SPLPAR)
>>>  extern int start_topology_update(void);
>>>  extern int stop_topology_update(void);
>>> +extern inline int prrn_is_enabled(void);
>>
>> You really can't do "extern inline" with no body ...
> 
> No you can't, and at least with my compiler it causes a build error.
> 

Easy enough, no more inline for this.

This for looking,
-Nathan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 1/12] Create a powerpc update_devicetree interface

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 13:46 -0500, Nathan Fontenot wrote:
> ok, good. I was not crazy about using ppc_md to do this and if you're fine
> with putting the pseries specific stuff in ifdef CONFIG_PPC_PSERIES I'll
> update the code to do that.
> 
> Question concerning rtas code. There is quite a bit of pseries specific 
> pieces in the general powerpc/kernel directory. Has there been, or should
> there be, any effort to move that to the pseries directory?

It's a good question ... it's shared in part with CHRP, it might make
sense to split it but only if the split can be done cleanly, which I
haven't looked into.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 01/15] powerpc/85xx: cache operations for Freescale SoCs based on BOOK3E

2013-04-23 Thread Scott Wood

On 04/19/2013 05:47:34 AM, Zhao Chenhui wrote:

These cache operations support Freescale SoCs based on BOOK3E.
Move L1 cache operations to fsl_booke_cache.S in order to maintain
easily. And, add cache operations for backside L2 cache and platform  
cache.


The backside L2 cache appears on e500mc and e5500 core. The platform  
cache

supported by this patch is L2 Look-Aside Cache, which appears on SoCs
with e500v1/e500v2 core, such as MPC8572, P1020, etc.

Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
---
 arch/powerpc/include/asm/cacheflush.h |8 ++
 arch/powerpc/kernel/Makefile  |1 +
 arch/powerpc/kernel/fsl_booke_cache.S |  210  
+

 arch/powerpc/kernel/head_fsl_booke.S  |   74 
 4 files changed, 219 insertions(+), 74 deletions(-)
 create mode 100644 arch/powerpc/kernel/fsl_booke_cache.S

diff --git a/arch/powerpc/include/asm/cacheflush.h  
b/arch/powerpc/include/asm/cacheflush.h

index b843e35..bc3f937 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -32,6 +32,14 @@ extern void flush_dcache_page(struct page *page);

 extern void __flush_disable_L1(void);

+#ifdef CONFIG_FSL_SOC_BOOKE
+void flush_dcache_L1(void);
+void flush_backside_L2_cache(void);
+void disable_backside_L2_cache(void);
+void flush_disable_L2(void);
+void invalidate_enable_L2(void);
+#endif


Don't ifdef prototypes unless there's a good reason, such as providing  
an inline alternative.


Why do you have "flush_backside_L2_cache" and  
"disable_backside_L2_cache" as something different from  
"flush_disable_L2"?  The latter should flush whatever L2 is present.   
Don't treat pre-corenet as the default.


Why do we even need to distinguish L1 from L2 at all?  Shouldn't the  
function that gets exposed just be "flush and disable data caches that  
are specific to this cpu"?  What should happen on e6500?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 02/15] powerpc/85xx: add sleep and deep sleep support

2013-04-23 Thread Scott Wood

On 04/19/2013 05:47:35 AM, Zhao Chenhui wrote:

 static int pmc_suspend_enter(suspend_state_t state)
 {
-   int ret;
+   int ret = 0;
+
+   switch (state) {
+#ifdef CONFIG_PPC_85xx
+   case PM_SUSPEND_MEM:
+#ifdef CONFIG_SPE
+   enable_kernel_spe();
+#endif
+   enable_kernel_fp();


Why does enable_kernel_spe() need an ifdef but enable_kernel_fp()  
doesn't?



+   case PM_SUSPEND_STANDBY:
+#ifdef CONFIG_FSL_SOC_BOOKE
+   flush_dcache_L1();
+#endif
+   setbits32(&pmc_regs->powmgtcsr, POWMGTCSR_SLP);


Only L1, even on e500mc?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 07/15] powerpc/85xx: add time base sync for SoCs based on e500mc/e5500

2013-04-23 Thread Scott Wood

On 04/19/2013 05:47:40 AM, Zhao Chenhui wrote:

From: Chen-Hui Zhao 

In the case of SMP, during the time base sync period, all time bases  
of

online cores must stop, then start simultaneously.

There is a RCPM (Run Control/Power Management) module in CoreNet  
based SoCs.

Define a struct ccsr_rcpm to describe the register map.

This patch supports SoCs based on e500mc/e5500, such as P4080, P5020,
etc.

Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
---
 arch/powerpc/include/asm/fsl_guts.h |   38  
+++
 arch/powerpc/platforms/85xx/smp.c   |   32  
+

 2 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_guts.h  
b/arch/powerpc/include/asm/fsl_guts.h

index 77ced0b..4eac1cf 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -106,6 +106,44 @@ struct ccsr_guts {
 /* Alternate function signal multiplex control */
 #define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))

+struct ccsr_rcpm {
+   u8  res[4];
+   __be32  cdozsr; /* 0x0004 - Core Doze Status Register */
+   u8  res0008[4];
+	__be32	cdozcr;		/* 0x000c - Core Doze Control Register  
*/

+   u8  res0010[4];
+   __be32  cnapsr; /* 0x0014 - Core Nap Status Register */
+   u8  res0018[4];
+   __be32  cnapcr; /* 0x001c - Core Nap Control Register */
+   u8  res0020[4];
+	__be32	cdozpsr;	/* 0x0024 - Core Doze Previous Status  
Register */

+   u8  res0028[4];
+	__be32	cnappsr;	/* 0x002c - Core Nap Previous Status  
Register */

+   u8  res0030[4];
+   __be32  cwaitsr;/* 0x0034 - Core Wait Status Register */
+   u8  res0038[4];
+	__be32	cwdtdsr;	/* 0x003c - Core watchdog detect status  
register */
+	__be32	powmgtcsr;	/* 0x0040 - Power Mangement Control &  
Status Register */

+   u8  res0044[12];
+	__be32	ippdexpcr;	/* 0x0050 - IP Powerdown Exception  
Control Register */

+   u8  res0054[16];
+   __be32  cpmimr; /* 0x0064 - Core PM IRQ Mask Register */
+   u8  res0068[4];
+	__be32	cpmcimr;	/* 0x006c - Core PM Critical IRQ Mask  
Register */

+   u8  res0070[4];
+	__be32	cpmmcmr;	/* 0x0074 - Core PM Machine Check Mask  
Register */

+   u8  res0078[4];
+   __be32  cpmnmimr;   /* 0x007c - Core PM NMI Mask Register */
+   u8  res0080[4];
+	__be32	ctbenr;		/* 0x0084 - Core Time Base Enable  
Register */

+   u8  res0088[4];
+	__be32	ctbckselr;	/* 0x008c - Core Time Base Clock Select  
Register */

+   u8  res0090[4];
+	__be32	ctbhltcr;	/* 0x0094 - Core Time Base Halt Control  
Register */

+   u8  res0098[4];
+	__be32	cmcpmaskcr;	/* 0x00a4 - Core machine check mask  
control register */

+};
+
 #ifdef CONFIG_PPC_86xx

 #define CCSR_GUTS_DMACR_DEV_SSI	0	/* DMA  
controller/channel set to SSI */
diff --git a/arch/powerpc/platforms/85xx/smp.c  
b/arch/powerpc/platforms/85xx/smp.c

index 6a17599..6c2fe6b 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -44,7 +44,36 @@ static struct ccsr_guts __iomem *guts;
 static u64 timebase;
 static int tb_req;
 static int tb_valid;
+static u32 cur_booting_core;

+#ifdef CONFIG_PPC_E500MC
+/* get a physical mask of online cores and booting core */
+static inline u32 get_phy_cpu_mask(void)
+{
+   u32 mask;
+   int cpu;
+
+   mask = 1 << cur_booting_core;
+   for_each_online_cpu(cpu)
+   mask |= 1 << get_hard_smp_processor_id(cpu);
+
+   return mask;
+}
+
+static void mpc85xx_timebase_freeze(int freeze)
+{
+   struct ccsr_rcpm __iomem *rcpm = (typeof(rcpm))guts;
+   u32 mask = get_phy_cpu_mask();
+
+   if (freeze)
+   clrbits32(&rcpm->ctbenr, mask);
+   else
+   setbits32(&rcpm->ctbenr, mask);
+
+   /* read back to push the previos write */
+   in_be32(&rcpm->ctbenr);
+}
+#else


Please determine the timebase sync implementation at runtime, rather  
than relying on our current inability to have e500v2 and e500mc in the  
same kernel.  e6500 will be different from e5500, but both can be in  
the same kernel image.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 13/15] powerpc/85xx: add support for e6500 L1 cache operation

2013-04-23 Thread Scott Wood

On 04/19/2013 05:47:46 AM, Zhao Chenhui wrote:

From: Chen-Hui Zhao 

The L1 Data Cache of e6500 contains no modified data, no flush
is required.

Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
Signed-off-by: Andy Fleming 
---
 arch/powerpc/kernel/fsl_booke_cache.S |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/fsl_booke_cache.S  
b/arch/powerpc/kernel/fsl_booke_cache.S

index 232c47b..24a52bb 100644
--- a/arch/powerpc/kernel/fsl_booke_cache.S
+++ b/arch/powerpc/kernel/fsl_booke_cache.S
@@ -65,13 +65,22 @@ _GLOBAL(flush_dcache_L1)

blr

+#define PVR_E6500  0x8040
+
 /* Flush L1 d-cache, invalidate and disable d-cache and i-cache */
 _GLOBAL(__flush_disable_L1)
+/* L1 Data Cache of e6500 contains no modified data, no flush is  
required */

+   mfspr   r3, SPRN_PVR
+   rlwinm  r4, r3, 16, 0x
+   lis r5, 0
+   ori r5, r5, PVR_E6500@l
+   cmpwr4, r5
+   beq 2f
mflrr10
bl  flush_dcache_L1 /* Flush L1 d-cache */
mtlrr10

-   msync
+2: msync
mfspr   r4, SPRN_L1CSR0 /* Invalidate and disable d-cache */
li  r5, 2
rlwimi  r4, r5, 0, 3


Note that disabling the cache is a core operation, rather than a thread  
operation.  Is this only called when the second thread is disabled?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 12/15] powerpc/85xx: add time base sync support for e6500

2013-04-23 Thread Scott Wood

On 04/19/2013 05:47:45 AM, Zhao Chenhui wrote:

From: Chen-Hui Zhao 

For e6500, two threads in one core share one time base. Just need
to do time base sync on first thread of one core, and skip it on
the other thread.

Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
Signed-off-by: Andy Fleming 
---
 arch/powerpc/platforms/85xx/smp.c |   52  
+++-

 1 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/smp.c  
b/arch/powerpc/platforms/85xx/smp.c

index 74d8cde..5f3eee3 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -45,6 +46,7 @@ static u64 timebase;
 static int tb_req;
 static int tb_valid;
 static u32 cur_booting_core;
+static bool rcpmv2;

 #ifdef CONFIG_PPC_E500MC
 /* get a physical mask of online cores and booting core */
@@ -53,26 +55,40 @@ static inline u32 get_phy_cpu_mask(void)
u32 mask;
int cpu;

-   mask = 1 << cur_booting_core;
-   for_each_online_cpu(cpu)
-   mask |= 1 << get_hard_smp_processor_id(cpu);
+   if (smt_capable()) {
+   /* two threads in one core share one time base */
+   mask = 1 << cpu_core_index_of_thread(cur_booting_core);
+   for_each_online_cpu(cpu)
+   mask |= 1 << cpu_core_index_of_thread(
+   get_hard_smp_processor_id(cpu));
+   } else {
+   mask = 1 << cur_booting_core;
+   for_each_online_cpu(cpu)
+   mask |= 1 << get_hard_smp_processor_id(cpu);
+   }


Where is smt_capable defined()?  I assume somewhere in the patchset but  
it's a pain to search 12 patches...


Is this really about whether we're SMT-capable or whether we have rcpm  
v2?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] arch: powerpc: mm: make mmap_64.c compile on 32bit powerpc

2013-04-23 Thread Daniel Walker


There appears to be no good reason to keep this as 64bit only. It works
on 32bit also, and has checks so that it can work correctly with 32bit
binaries on 64bit hardware which is why I think this works.

I tested this on qemu using the virtex-ml507 machine type.

Before,

/bin2 # ./test & cat /proc/${!}/maps
0010-00103000 r-xp  00:00 0  [vdso]
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
4800-4802 r-xp  00:01 224/lib/ld-2.11.3.so
48021000-48023000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bfd03000-bfd24000 rw-p  00:00 0  [stack]
/bin2 # ./test & cat /proc/${!}/maps
0010-00103000 r-xp  00:00 0  [vdso]
0fe6e000-0ffd8000 r-xp  00:01 214/lib/libc-2.11.3.so
0ffd8000-0ffe8000 ---p 0016a000 00:01 214/lib/libc-2.11.3.so
0ffe8000-0ffed000 rw-p 0016a000 00:01 214/lib/libc-2.11.3.so
0ffed000-0fff rw-p  00:00 0
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
4800-4802 r-xp  00:01 224/lib/ld-2.11.3.so
4802-48021000 rw-p  00:00 0
48021000-48023000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bf98a000-bf9ab000 rw-p  00:00 0  [stack]
/bin2 # ./test & cat /proc/${!}/maps
0010-00103000 r-xp  00:00 0  [vdso]
0fe6e000-0ffd8000 r-xp  00:01 214/lib/libc-2.11.3.so
0ffd8000-0ffe8000 ---p 0016a000 00:01 214/lib/libc-2.11.3.so
0ffe8000-0ffed000 rw-p 0016a000 00:01 214/lib/libc-2.11.3.so
0ffed000-0fff rw-p  00:00 0
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
4800-4802 r-xp  00:01 224/lib/ld-2.11.3.so
4802-48021000 rw-p  00:00 0
48021000-48023000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bfa54000-bfa75000 rw-p  00:00 0  [stack]

After,

bash-4.1# ./test & cat /proc/${!}/maps
[7] 803
0010-00103000 r-xp  00:00 0  [vdso]
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
b7eb-b7ed r-xp  00:01 224/lib/ld-2.11.3.so
b7ed1000-b7ed3000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bfbc-bfbe1000 rw-p  00:00 0  [stack]
bash-4.1# ./test & cat /proc/${!}/maps
[8] 805
0010-00103000 r-xp  00:00 0  [vdso]
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
b7b03000-b7b23000 r-xp  00:01 224/lib/ld-2.11.3.so
b7b24000-b7b26000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bfc27000-bfc48000 rw-p  00:00 0  [stack]
bash-4.1# ./test & cat /proc/${!}/maps
[9] 807
0010-00103000 r-xp  00:00 0  [vdso]
1000-10007000 r-xp  00:01 454/bin2/test
10017000-10018000 rw-p 7000 00:01 454/bin2/test
b7f37000-b7f57000 r-xp  00:01 224/lib/ld-2.11.3.so
b7f58000-b7f5a000 rw-p 00021000 00:01 224/lib/ld-2.11.3.so
bff96000-bffb7000 rw-p  00:00 0  [stack]

Signed-off-by: Daniel Walker 
---
 arch/powerpc/include/asm/processor.h |2 -
 arch/powerpc/mm/Makefile |5 +-
 arch/powerpc/mm/mmap.c   |  101 ++
 arch/powerpc/mm/mmap_64.c|  101 --
 4 files changed, 103 insertions(+), 106 deletions(-)
 create mode 100644 arch/powerpc/mm/mmap.c
 delete mode 100644 arch/powerpc/mm/mmap_64.c

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index 7ff9eaa..6ef17bd 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -402,9 +402,7 @@ static inline void prefetchw(const void *x)
 
 #define spin_lock_prefetch(x)  prefetchw(x)
 
-#ifdef CONFIG_PPC64
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
-#endif
 
 #ifdef CONFIG_PPC64
 static inline unsigned long get_clean_sp(struct pt_regs *regs, int is_32)
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index cf16b57..26f29a7 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -6,17 +6,16 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
 
-obj-y  := fault.o mem.o pgtable.o gup.o \
+obj-y  := fault.o mem.o pgtable.o gup.o mmap.o \
   init_$(CONFIG_WORD_SIZE).o \
   pgtable_$(CONFIG_WORD_SIZE).o
 obj-$(CONFIG_PPC_MMU_NOHASH)   += mmu_context_nohash.o tlb_nohash.o \
   tlb_nohash_low.o
 obj-$(CONFIG_PPC_BOOK3E)   += tlb_low_$(CONFIG_WORD_SIZE)e.o
-obj-$(CONFIG_PPC64)+

[PATCH] powerpc/spufs: Initialise inode->i_ino in spufs_new_inode()

2013-04-23 Thread Michael Ellerman
In commit 85fe402 (fs: do not assign default i_ino in new_inode), the
initialisation of i_ino was removed from new_inode() and pushed down
into the callers. However spufs_new_inode() was not updated.

This exhibits as no files appearing in /spu, because all our dirents
have a zero inode, which readdir() seems to dislike.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/cell/spufs/inode.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 3f3bb4c..35f77a4 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -99,6 +99,7 @@ spufs_new_inode(struct super_block *sb, umode_t mode)
if (!inode)
goto out;
 
+   inode->i_ino = get_next_ino();
inode->i_mode = mode;
inode->i_uid = current_fsuid();
inode->i_gid = current_fsgid();
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/spufs: Initialise inode->i_ino in spufs_new_inode()

2013-04-23 Thread Benjamin Herrenschmidt
On Wed, 2013-04-24 at 11:13 +1000, Michael Ellerman wrote:
> In commit 85fe402 (fs: do not assign default i_ino in new_inode), the
> initialisation of i_ino was removed from new_inode() and pushed down
> into the callers. However spufs_new_inode() was not updated.
> 
> This exhibits as no files appearing in /spu, because all our dirents
> have a zero inode, which readdir() seems to dislike.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michael Ellerman 

Christoph/Al, can I have an Ack for this before I shoot it to Linus ?

Thanks !

Cheers,
Ben.

---
>  arch/powerpc/platforms/cell/spufs/inode.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/platforms/cell/spufs/inode.c
b/arch/powerpc/platforms/cell/spufs/inode.c
> index 3f3bb4c..35f77a4 100644
> --- a/arch/powerpc/platforms/cell/spufs/inode.c
> +++ b/arch/powerpc/platforms/cell/spufs/inode.c
> @@ -99,6 +99,7 @@ spufs_new_inode(struct super_block *sb, umode_t
mode)
>   if (!inode)
>   goto out;
>  
> + inode->i_ino = get_next_ino();
>   inode->i_mode = mode;
>   inode->i_uid = current_fsuid();
>   inode->i_gid = current_fsgid();
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/5] powerpc/powernv: Supports PHB3

2013-04-23 Thread Gavin Shan
On Wed, Apr 24, 2013 at 01:19:00AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
>> -/* Fixup wrong class code in p7ioc root complex */
>> +/* Fixup wrong class code in p7ioc and p8 root complex */
>>  static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
>>  {
>> dev->class = PCI_CLASS_BRIDGE_PCI << 8;
>>  }
>>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x3b9, pnv_p7ioc_rc_quirk);
>> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x2da, pnv_p7ioc_rc_quirk);
>>  
>This can go away from the normal patch, it is only necessary to work
>around a problem in the simulator. The real PHB3 doesn't need the
>workaround (p7ioc still does).
>

Ok. I'll remove it in next version ;-)

Thanks,
Gavin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/5] powerpc/powernv: Patch MSI EOI handler on P8

2013-04-23 Thread Gavin Shan
On Wed, Apr 24, 2013 at 01:21:53AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
>> 
>> +static int pnv_pci_ioda_msi_eoi(struct pnv_phb *phb, unsigned int hw_irq)
>> +{
>> +   u8 p_bit = 1, q_bit = 1;
>> +   long rc;
>> +
>> +   while (p_bit || q_bit) {
>> +   rc = opal_pci_get_xive_reissue(phb->opal_id,
>> +   hw_irq - phb->msi_base, &p_bit, &q_bit);
>> +   if (rc) {
>> +   pr_warning("%s: Failed to get P/Q bits of IRQ#%d "
>> +  "on PHB#%d, rc=%ld\n", __func__, hw_irq,
>> +  phb->hose->global_number, rc);
>> +   return -EIO;
>> +   }
>> +   if (!p_bit && !q_bit)
>> +   break;
>> +
>> +   rc = opal_pci_set_xive_reissue(phb->opal_id,
>> +   hw_irq - phb->msi_base, p_bit, q_bit);
>> +   if (rc) {
>> +   pr_warning("%s: Failed to clear P/Q (%01d/%01d) of "
>> +  "IRQ#%d on PHB#%d, rc=%ld\n", __func__,
>> +  p_bit, q_bit, hw_irq,
>> +  phb->hose->global_number, rc);
>> +   return -EIO;
>> +   }
>> +   }
>> +
>> +   return 0;
>> +}
>
>Can you turn that into a single opal_pci_msi_eoi() ? This means that a
>single MSI will trigger only one OPAL call rather than two which is
>better for performances.
>

Ok. I will add new OPAL API opal_pci_msi_eoi() and use that in next version.

>We will later implement an "optimized" variant using direct MMIO based
>on knowing specifically the HW type but not now.
>

Ok :-)

Thanks,
Gavin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 5/5] powerpc/powernv: TCE invalidation for PHB3

2013-04-23 Thread Gavin Shan
On Wed, Apr 24, 2013 at 01:25:08AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
>>  * of flags if that becomes the case
>>  */
>> if (tbl->it_type & TCE_PCI_SWINV_CREATE)
>> -   pnv_tce_invalidate(tbl, tces, tcep - 1);
>> +   phb->dma_tce_invalidate(tbl, tces, tcep - 1);
>>  
>> return 0;
>>  }
>
>TCE invalidate is very performance sensitive, we might be better off
>doing the if (ioda_type == PNV_PHB_IODA1) ... else ... here (which
>the CPU can generally predict) rather than a function pointer call
>which can be more tricky.
>

Ok. I'll change it in next version ;-)

Thanks,
Gavin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/spufs: Initialise inode->i_ino in spufs_new_inode()

2013-04-23 Thread Christoph Hellwig
Looks good.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] Make CONFIG_BOOTX an exclusive early debug option

2013-04-23 Thread Alistair Popple

This patch makes the kernel configuration option "Support for early boot text
console (BootX or OpenFirmware only)" an exclusive choice under the "Early
debugging" menu. This prevents selection of two early debug consoles
simultaneously which does not appear to be supported by the code in
arch/powerpc/kernel/udbg.c.

Currently if two consoles are enabled the code in udbg.c selects one based on
the order in which initialisation functions are called which seems fairly
arbitrary.

For example if both CONFIG_BOOTX_TEXT and CONFIG_PPC_EARLY_DEBUG_LPAR are
enabled then the BootX console will be used. However if both CONFIG_BOOTX_TEXT
and CONFIG_PPC_EARLY_DEBUG_PS3GELIC are selected then the latter will be used.

Signed-off-by: Alistair Popple 
---

diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 5416e28..659120c 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -122,13 +122,6 @@ config BDI_SWITCH
  Unless you are intending to debug the kernel with one of these
  machines, say N here.

-config BOOTX_TEXT
-   bool "Support for early boot text console (BootX or OpenFirmware only)"
-   depends on PPC_OF && PPC_BOOK3S
-   help
- Say Y here to see progress messages from the boot firmware in text
- mode. Requires either BootX or Open Firmware.
-
config PPC_EARLY_DEBUG
bool "Early debugging (dangerous)"
help
@@ -147,6 +140,13 @@ choice
  enable debugging for the wrong type of machine your kernel
  _will not boot_.

+config BOOTX_TEXT
+   bool "Support for early boot text console (BootX or OpenFirmware only)"
+   depends on PPC_OF && PPC_BOOK3S
+   help
+ Say Y here to see progress messages from the boot firmware in text
+ mode. Requires either BootX or Open Firmware.
+
config PPC_EARLY_DEBUG_LPAR
bool "LPAR HV Console"
depends on PPC_PSERIES

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/1] usb: ehci-fsl: set INCR8 mode only on MPC512x

2013-04-23 Thread Tiejun Chen
commit 761bbcb7, "usb: ehci-fsl: set INCR8 mode for system bus interface
on MPC512x", introduced to fix one MPC5121e (M36P) Errata by setting
INCR8 mode for system bus interface on MPC512x, but we should make sure
this is only valid for MPC512x like other parts of this commit. Otherwise
this would issue other platforms as abnormal without this similar Errata.

Signed-off-by: Tiejun Chen 
---
 drivers/usb/host/ehci-fsl.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index d81d2fc..f4f2a7b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -509,7 +509,15 @@ static int ehci_fsl_mpc512x_drv_resume(struct device *dev)
ehci_writel(ehci, ISIPHYCTRL_PXE | ISIPHYCTRL_PHYE,
hcd->regs + FSL_SOC_USB_ISIPHYCTRL);
 
-   ehci_writel(ehci, SBUSCFG_INCR8, hcd->regs + FSL_SOC_USB_SBUSCFG);
+   if (of_device_is_compatible(dev->parent->of_node,
+   "fsl,mpc5121-usb2-dr")) {
+   /*
+* set SBUSCFG:AHBBRST so that control msgs don't
+* fail when doing heavy PATA writes.
+*/
+   ehci_writel(ehci, SBUSCFG_INCR8,
+   hcd->regs + FSL_SOC_USB_SBUSCFG);
+   }
 
/* restore EHCI registers */
ehci_writel(ehci, pdata->pm_command, &ehci->regs->command);
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/1] usb: ehci-fsl: set INCR8 mode only on MPC512x

2013-04-23 Thread tiejun.chen

Sorry, please ignore this temporarily since looks this is already covered in 
tree.

I will look further into this to send another version.

Tiejun

On 04/24/2013 10:55 AM, Tiejun Chen wrote:

commit 761bbcb7, "usb: ehci-fsl: set INCR8 mode for system bus interface
on MPC512x", introduced to fix one MPC5121e (M36P) Errata by setting
INCR8 mode for system bus interface on MPC512x, but we should make sure
this is only valid for MPC512x like other parts of this commit. Otherwise
this would issue other platforms as abnormal without this similar Errata.

Signed-off-by: Tiejun Chen 
---
  drivers/usb/host/ehci-fsl.c |   10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index d81d2fc..f4f2a7b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -509,7 +509,15 @@ static int ehci_fsl_mpc512x_drv_resume(struct device *dev)
ehci_writel(ehci, ISIPHYCTRL_PXE | ISIPHYCTRL_PHYE,
hcd->regs + FSL_SOC_USB_ISIPHYCTRL);

-   ehci_writel(ehci, SBUSCFG_INCR8, hcd->regs + FSL_SOC_USB_SBUSCFG);
+   if (of_device_is_compatible(dev->parent->of_node,
+   "fsl,mpc5121-usb2-dr")) {
+   /*
+* set SBUSCFG:AHBBRST so that control msgs don't
+* fail when doing heavy PATA writes.
+*/
+   ehci_writel(ehci, SBUSCFG_INCR8,
+   hcd->regs + FSL_SOC_USB_SBUSCFG);
+   }

/* restore EHCI registers */
ehci_writel(ehci, pdata->pm_command, &ehci->regs->command);



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC, PATCH v2] powerpc/prom: Scan reserved-ranges node for memory reservations

2013-04-23 Thread Jeremy Kerr
Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr 

---
v2: fix range property iteration

---
 arch/powerpc/kernel/prom.c |   36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..c77307e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,34 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = ((unsigned long)initial_boot_params) +
+   be32_to_cpu(initial_boot_params->off_dt_struct);
+
+   prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each,
+* totalling 4 cells per range. */
+   for (i = 0; i < len / (sizeof(*prop) * 4); i++) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4) + 0, 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +602,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params->totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h

2013-04-23 Thread Benjamin Herrenschmidt
On Tue, 2013-04-23 at 06:36 +, Jia Hongtao-B38951 wrote:
> These definitions are firstly used by KVM defined like OP_31_XOP_TRAP.
> Two ways to extract these definitions for public use:
> 
> 1. Like this patch did. For keeping the KVM code that using these
>definitions unchanged we do not update them to match.
> 
> 2. Move these definitions to another .h file like my last patch did:
>http://patchwork.ozlabs.org/patch/235646/
>You can see the comments there.

There's a better way ... but it's more work.

All opcodes are based on a primary opcode and a potential secondary
opcode. You could/should rework ppc-opcodes.h to in fact define them
all that way as well, which would "reconcile" the KVM way and the
existing stuff.

Cheers,
Ben.

> Thanks.
> -Hongtao
> 
> 
> 
> 
> 
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/1] usb: ehci-fsl: set INCR8 mode only on MPC512x

2013-04-23 Thread Anatolij Gustschin
On Wed, 24 Apr 2013 10:55:10 +0800
Tiejun Chen  wrote:

> commit 761bbcb7, "usb: ehci-fsl: set INCR8 mode for system bus interface
> on MPC512x", introduced to fix one MPC5121e (M36P) Errata by setting
> INCR8 mode for system bus interface on MPC512x, but we should make sure
> this is only valid for MPC512x like other parts of this commit. Otherwise

NAK. It is already only valid for MPC512x.

> this would issue other platforms as abnormal without this similar Errata.

This setting is in the ehci_fsl_mpc512x_drv_resume() function which is
not called on other platforms.

Thanks,

Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 0/8] powerpc/pseries: Nvram-to-pstore

2013-04-23 Thread Aruna Balakrishnaiah
Currently the kernel provides the contents of p-series NVRAM only as a
simple stream of bytes via /dev/nvram, which must be interpreted in user
space by the nvram command in the powerpc-utils package. This patch set
exploits the pstore subsystem to expose each partition in NVRAM as a
separate file in /dev/pstore. For instance Oops messages will stored in a
file named [dmesg-nvram-2].

Changes from v1:
- Reduce #ifdefs by and remove forward declarations of pstore callbacks
- Handle return value of nvram_write_os_partition
- Remove empty pstore callbacks and register pstore only when pstore
  is configured

---

Aruna Balakrishnaiah (8):
  powerpc/pseries: Remove syslog prefix in uncompressed oops text
  powerpc/pseries: Add version and timestamp to oops header
  powerpc/pseries: Introduce generic read function to read nvram-partitions
  powerpc/pseries: Read/Write oops nvram partition via pstore
  powerpc/pseries: Read rtas partition via pstore
  powerpc/pseries: Distinguish between a os-partition and non-os partition
  powerpc/pseries: Read of-config partition via pstore
  powerpc/pseries: Read common partition via pstore


 arch/powerpc/platforms/pseries/nvram.c |  353 +++-
 fs/pstore/inode.c  |9 +
 include/linux/pstore.h |4 
 3 files changed, 313 insertions(+), 53 deletions(-)

-- 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 1/8] powerpc/pseries: Remove syslog prefix in uncompressed oops text

2013-04-23 Thread Aruna Balakrishnaiah
Removal of syslog prefix in the uncompressed oops text will
help in capturing more oops data.

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 8733a86..e54a8b7 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -619,7 +619,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
}
if (rc != 0) {
kmsg_dump_rewind(dumper);
-   kmsg_dump_get_buffer(dumper, true,
+   kmsg_dump_get_buffer(dumper, false,
 oops_data, oops_data_sz, &text_len);
err_type = ERR_TYPE_KERNEL_PANIC;
*oops_len = (u16) text_len;

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 2/8] powerpc/pseries: Add version and timestamp to oops header

2013-04-23 Thread Aruna Balakrishnaiah
Introduce version and timestamp information in the oops header.
oops_log_info (oops header) holds version (to distinguish between old
and new format oops header), length of the oops text
(compressed or uncompressed) and timestamp.

The version field will sit in the same place as the length in old
headers. version is assigned 5000 (greater than oops partition size)
so that existing tools will refuse to dump new style partitions as
the length is too large. The updated tools will work with both
old and new format headers.

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |   57 +---
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index e54a8b7..742735a 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -29,6 +29,13 @@
 /* Max bytes to read/write in one go */
 #define NVRW_CNT 0x20
 
+/*
+ * Set oops header version to distingush between old and new format header.
+ * lnx,oops-log partition max size is 4000, header version > 4000 will
+ * help in identifying new header.
+ */
+#define OOPS_HDR_VERSION 5000
+
 static unsigned int nvram_size;
 static int nvram_fetch, nvram_store;
 static char nvram_buf[NVRW_CNT];   /* assume this is in the first 4GB */
@@ -67,6 +74,12 @@ static const char *pseries_nvram_os_partitions[] = {
NULL
 };
 
+struct oops_log_info {
+   u16 version;
+   u16 report_length;
+   u64 timestamp;
+} __attribute__((packed));
+
 static void oops_to_nvram(struct kmsg_dumper *dumper,
  enum kmsg_dump_reason reason);
 
@@ -83,28 +96,28 @@ static unsigned long last_unread_rtas_event;/* 
timestamp */
 
  * big_oops_buf[] holds the uncompressed text we're capturing.
  *
- * oops_buf[] holds the compressed text, preceded by a prefix.
- * The prefix is just a u16 holding the length of the compressed* text.
- * (*Or uncompressed, if compression fails.)  oops_buf[] gets written
- * to NVRAM.
+ * oops_buf[] holds the compressed text, preceded by a oops header.
+ * oops header has u16 holding the version of oops header (to differentiate
+ * between old and new format header) followed by u16 holding the length of
+ * the compressed* text (*Or uncompressed, if compression fails.) and u64
+ * holding the timestamp. oops_buf[] gets written to NVRAM.
  *
- * oops_len points to the prefix.  oops_data points to the compressed text.
+ * oops_log_info points to the header. oops_data points to the compressed text.
  *
  * +- oops_buf
- * |   +- oops_data
- * v   v
- * ++---+
- * | length| text  |
- * | (2 bytes) | (oops_data_sz bytes)  |
- * ++---+
+ * |   +- oops_data
+ * v   v
+ * +---+---+---++
+ * | version   | length| timestamp | text   |
+ * | (2 bytes) | (2 bytes) | (8 bytes) | (oops_data_sz bytes)   |
+ * +---+---+---++
  * ^
- * +- oops_len
+ * +- oops_log_info
  *
  * We preallocate these buffers during init to avoid kmalloc during oops/panic.
  */
 static size_t big_oops_buf_sz;
 static char *big_oops_buf, *oops_buf;
-static u16 *oops_len;
 static char *oops_data;
 static size_t oops_data_sz;
 
@@ -425,9 +438,8 @@ static void __init nvram_init_oops_partition(int 
rtas_partition_exists)
oops_log_partition.name);
return;
}
-   oops_len = (u16*) oops_buf;
-   oops_data = oops_buf + sizeof(u16);
-   oops_data_sz = oops_log_partition.size - sizeof(u16);
+   oops_data = oops_buf + sizeof(struct oops_log_info);
+   oops_data_sz = oops_log_partition.size - sizeof(struct oops_log_info);
 
/*
 * Figure compression (preceded by elimination of each line's 
@@ -555,6 +567,7 @@ error:
 /* Compress the text from big_oops_buf into oops_buf. */
 static int zip_oops(size_t text_len)
 {
+   struct oops_log_info *oops_hdr = (struct oops_log_info *)oops_buf;
int zipped_len = nvram_compress(big_oops_buf, oops_data, text_len,
oops_data_sz);
if (zipped_len < 0) {
@@ -562,7 +575,9 @@ static int zip_oops(size_t text_len)
pr_err("nvram: logging uncompressed oops/panic report\n");
return -1;
}
-   *oops_len = (u16) zipped_len;
+   oops_hdr->version = OOPS_HDR_VERSION;
+   oops_hdr->report_length = (u16) zipped_len;
+   oops_hdr->timestamp = get_seconds();
return 0;
 }
 
@@ -576,6 +591,7 @@ static int zip_oops(size_t text_len)
 stat

[PATCH v2 3/8] powerpc/pseries: Introduce generic read function to read nvram-partitions

2013-04-23 Thread Aruna Balakrishnaiah
Introduce generic read function to read nvram partitions other than rtas.
nvram_read_error_log will be retained which is used to read rtas partition
from rtasd. nvram_read_partition is the generic read function to read from
any nvram partition.

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |   32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 742735a..088f023 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -293,34 +293,35 @@ int nvram_write_error_log(char * buff, int length,
return rc;
 }
 
-/* nvram_read_error_log
+/* nvram_read_partition
  *
- * Reads nvram for error log for at most 'length'
+ * Reads nvram partition for at most 'length'
  */
-int nvram_read_error_log(char * buff, int length,
- unsigned int * err_type, unsigned int * error_log_cnt)
+int nvram_read_partition(struct nvram_os_partition *part, char *buff,
+   int length, unsigned int *err_type,
+   unsigned int *error_log_cnt)
 {
int rc;
loff_t tmp_index;
struct err_log_info info;

-   if (rtas_log_partition.index == -1)
+   if (part->index == -1)
return -1;
 
-   if (length > rtas_log_partition.size)
-   length = rtas_log_partition.size;
+   if (length > part->size)
+   length = part->size;
 
-   tmp_index = rtas_log_partition.index;
+   tmp_index = part->index;
 
rc = ppc_md.nvram_read((char *)&info, sizeof(struct err_log_info), 
&tmp_index);
if (rc <= 0) {
-   printk(KERN_ERR "nvram_read_error_log: Failed nvram_read 
(%d)\n", rc);
+   pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__, rc);
return rc;
}
 
rc = ppc_md.nvram_read(buff, length, &tmp_index);
if (rc <= 0) {
-   printk(KERN_ERR "nvram_read_error_log: Failed nvram_read 
(%d)\n", rc);
+   pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__, rc);
return rc;
}
 
@@ -330,6 +331,17 @@ int nvram_read_error_log(char * buff, int length,
return 0;
 }
 
+/* nvram_read_error_log
+ *
+ * Reads nvram for error log for at most 'length'
+ */
+int nvram_read_error_log(char *buff, int length,
+   unsigned int *err_type, unsigned int *error_log_cnt)
+{
+   return nvram_read_partition(&rtas_log_partition, buff, length,
+   err_type, error_log_cnt);
+}
+
 /* This doesn't actually zero anything, but it sets the event_logged
  * word to tell that this event is safely in syslog.
  */

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 4/8] powerpc/pseries: Read/Write oops nvram partition via pstore

2013-04-23 Thread Aruna Balakrishnaiah
IBM's p series machines provide persistent storage for LPARs through NVRAM.
NVRAM's lnx,oops-log partition is used to log oops messages.
Currently the kernel provides the contents of p-series NVRAM only as a
simple stream of bytes via /dev/nvram, which must be interpreted in user
space by the nvram command in the powerpc-utils package.

This patch set exploits the pstore subsystem to expose oops partition in
NVRAM as a separate file in /dev/pstore. For instance, Oops messages will be
stored in a file named [dmesg-nvram-2]. In case pstore registration fails it
will fall back to kmsg_dump mechanism.

This patch will read/write the oops messages from/to this partition via pstore.

Signed-off-by: Jim Keniston 
Signed-off-by: Aruna Balakrishnaiah 
---
 arch/powerpc/platforms/pseries/nvram.c |  172 +---
 1 file changed, 157 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 088f023..9edec8e 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,14 @@ static size_t oops_data_sz;
 #define MEM_LEVEL 4
 static struct z_stream_s stream;
 
+#ifdef CONFIG_PSTORE
+static enum pstore_type_id nvram_type_ids[] = {
+   PSTORE_TYPE_DMESG,
+   -1
+};
+static int read_type;
+#endif
+
 static ssize_t pSeries_nvram_read(char *buf, size_t count, loff_t *index)
 {
unsigned int i;
@@ -430,6 +439,149 @@ static int __init pseries_nvram_init_os_partition(struct 
nvram_os_partition
return 0;
 }
 
+/*
+ * Are we using the ibm,rtas-log for oops/panic reports?  And if so,
+ * would logging this oops/panic overwrite an RTAS event that rtas_errd
+ * hasn't had a chance to read and process?  Return 1 if so, else 0.
+ *
+ * We assume that if rtas_errd hasn't read the RTAS event in
+ * NVRAM_RTAS_READ_TIMEOUT seconds, it's probably not going to.
+ */
+static int clobbering_unread_rtas_event(void)
+{
+   return (oops_log_partition.index == rtas_log_partition.index
+   && last_unread_rtas_event
+   && get_seconds() - last_unread_rtas_event <=
+   NVRAM_RTAS_READ_TIMEOUT);
+}
+
+#ifdef CONFIG_PSTORE
+static int nvram_pstore_open(struct pstore_info *psi)
+{
+   /* Reset the iterator to start reading partitions again */
+   read_type = -1;
+   return 0;
+}
+
+/**
+ * nvram_pstore_write - pstore write callback for nvram
+ * @type:   Type of message logged
+ * @reason: reason behind dump (oops/panic)
+ * @id: identifier to indicate the write performed
+ * @part:   pstore writes data to registered buffer in parts,
+ *  part number will indicate the same.
+ * @count:  Indicates oops count
+ * @size:   number of bytes written to the registered buffer
+ * @psi:registered pstore_info structure
+ *
+ * Called by pstore_dump() when an oops or panic report is logged in the
+ * printk buffer.
+ * Returns 0 on successful write.
+ */
+static int nvram_pstore_write(enum pstore_type_id type,
+   enum kmsg_dump_reason reason,
+   u64 *id, unsigned int part, int count,
+   size_t size, struct pstore_info *psi)
+{
+   int rc;
+   struct oops_log_info *oops_hdr = (struct oops_log_info *) oops_buf;
+
+   /* part 1 has the recent messages from printk buffer */
+   if (part > 1 || type != PSTORE_TYPE_DMESG ||
+   clobbering_unread_rtas_event())
+   return -1;
+
+   oops_hdr->version = OOPS_HDR_VERSION;
+   oops_hdr->report_length = (u16) size;
+   oops_hdr->timestamp = get_seconds();
+   rc = nvram_write_os_partition(&oops_log_partition, oops_buf,
+   (int) (sizeof(*oops_hdr) + size), ERR_TYPE_KERNEL_PANIC,
+   count);
+
+   if (rc != 0)
+   return rc;
+
+   *id = part;
+   return 0;
+}
+
+/*
+ * Reads the oops/panic report.
+ * Returns the length of the data we read from each partition.
+ * Returns 0 if we've been called before.
+ */
+static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
+   int *count, struct timespec *time, char **buf,
+   struct pstore_info *psi)
+{
+   struct oops_log_info *oops_hdr;
+   unsigned int err_type, id_no;
+   struct nvram_os_partition *part = NULL;
+   char *buff = NULL;
+
+   read_type++;
+
+   switch (nvram_type_ids[read_type]) {
+   case PSTORE_TYPE_DMESG:
+   part = &oops_log_partition;
+   *type = PSTORE_TYPE_DMESG;
+   break;
+   default:
+   return 0;
+   }
+
+   buff = kmalloc(part->size, GFP_KERNEL);

[PATCH v2 5/8] powerpc/pseries: Read rtas partition via pstore

2013-04-23 Thread Aruna Balakrishnaiah
This patch set exploits the pstore subsystem to read details of rtas partition
in NVRAM to a separate file in /dev/pstore. For instance, rtas details will be
stored in a file named [rtas-nvram-4].

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |   33 +---
 fs/pstore/inode.c  |3 +++
 include/linux/pstore.h |2 ++
 3 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 9edec8e..8a7eefb 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -131,9 +131,11 @@ static struct z_stream_s stream;
 #ifdef CONFIG_PSTORE
 static enum pstore_type_id nvram_type_ids[] = {
PSTORE_TYPE_DMESG,
+   PSTORE_TYPE_RTAS,
-1
 };
 static int read_type;
+static unsigned long last_rtas_event;
 #endif
 
 static ssize_t pSeries_nvram_read(char *buf, size_t count, loff_t *index)
@@ -297,8 +299,13 @@ int nvram_write_error_log(char * buff, int length,
 {
int rc = nvram_write_os_partition(&rtas_log_partition, buff, length,
err_type, error_log_cnt);
-   if (!rc)
+   if (!rc) {
last_unread_rtas_event = get_seconds();
+#ifdef CONFIG_PSTORE
+   last_rtas_event = get_seconds();
+#endif
+   }
+
return rc;
 }
 
@@ -506,7 +513,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
 }
 
 /*
- * Reads the oops/panic report.
+ * Reads the oops/panic report and ibm,rtas-log partition.
  * Returns the length of the data we read from each partition.
  * Returns 0 if we've been called before.
  */
@@ -526,6 +533,12 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
part = &oops_log_partition;
*type = PSTORE_TYPE_DMESG;
break;
+   case PSTORE_TYPE_RTAS:
+   part = &rtas_log_partition;
+   *type = PSTORE_TYPE_RTAS;
+   time->tv_sec = last_rtas_event;
+   time->tv_nsec = 0;
+   break;
default:
return 0;
}
@@ -542,11 +555,17 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
 
*count = 0;
*id = id_no;
-   oops_hdr = (struct oops_log_info *)buff;
-   *buf = buff + sizeof(*oops_hdr);
-   time->tv_sec = oops_hdr->timestamp;
-   time->tv_nsec = 0;
-   return oops_hdr->report_length;
+
+   if (nvram_type_ids[read_type] == PSTORE_TYPE_DMESG) {
+   oops_hdr = (struct oops_log_info *)buff;
+   *buf = buff + sizeof(*oops_hdr);
+   time->tv_sec = oops_hdr->timestamp;
+   time->tv_nsec = 0;
+   return oops_hdr->report_length;
+   }
+
+   *buf = buff;
+   return part->size;
 }
 
 static struct pstore_info nvram_pstore_info = {
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index e4bcb2c..ec24f9c 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -324,6 +324,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
case PSTORE_TYPE_MCE:
sprintf(name, "mce-%s-%lld", psname, id);
break;
+   case PSTORE_TYPE_PPC_RTAS:
+   sprintf(name, "rtas-%s-%lld", psname, id);
+   break;
case PSTORE_TYPE_UNKNOWN:
sprintf(name, "unknown-%s-%lld", psname, id);
break;
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 75d0176..d7a8fe9 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -35,6 +35,8 @@ enum pstore_type_id {
PSTORE_TYPE_MCE = 1,
PSTORE_TYPE_CONSOLE = 2,
PSTORE_TYPE_FTRACE  = 3,
+   /* PPC64 partition types */
+   PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_UNKNOWN = 255
 };
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 6/8] powerpc/pseries: Distinguish between a os-partition and non-os partition

2013-04-23 Thread Aruna Balakrishnaiah
Introduce os_partition member in nvram_os_partition structure to identify
if the partition is an os partition or not. This will be useful to handle
non-os partitions of-config and common.

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 8a7eefb..b118382 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -53,20 +53,23 @@ struct nvram_os_partition {
int min_size;   /* minimum acceptable size (0 means req_size) */
long size;  /* size of data portion (excluding err_log_info) */
long index; /* offset of data portion of partition */
+   bool os_partition; /* partition initialized by OS, not FW */
 };
 
 static struct nvram_os_partition rtas_log_partition = {
.name = "ibm,rtas-log",
.req_size = 2079,
.min_size = 1055,
-   .index = -1
+   .index = -1,
+   .os_partition = true
 };
 
 static struct nvram_os_partition oops_log_partition = {
.name = "lnx,oops-log",
.req_size = 4000,
.min_size = 2000,
-   .index = -1
+   .index = -1,
+   .os_partition = true
 };
 
 static const char *pseries_nvram_os_partitions[] = {

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 7/8] powerpc/pseries: Read of-config partition via pstore

2013-04-23 Thread Aruna Balakrishnaiah
This patch set exploits the pstore subsystem to read details of
of-config partition in NVRAM to a separate file in /dev/pstore.
For instance, of-config partition details will be stored in a
file named [of-nvram-5].

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |   55 +++-
 fs/pstore/inode.c  |3 ++
 include/linux/pstore.h |1 +
 3 files changed, 50 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index b118382..de448af 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -132,9 +132,16 @@ static size_t oops_data_sz;
 static struct z_stream_s stream;
 
 #ifdef CONFIG_PSTORE
+static struct nvram_os_partition of_config_partition = {
+   .name = "of-config",
+   .index = -1,
+   .os_partition = false
+};
+
 static enum pstore_type_id nvram_type_ids[] = {
PSTORE_TYPE_DMESG,
PSTORE_TYPE_RTAS,
+   PSTORE_TYPE_OF,
-1
 };
 static int read_type;
@@ -332,10 +339,15 @@ int nvram_read_partition(struct nvram_os_partition *part, 
char *buff,
 
tmp_index = part->index;
 
-   rc = ppc_md.nvram_read((char *)&info, sizeof(struct err_log_info), 
&tmp_index);
-   if (rc <= 0) {
-   pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__, rc);
-   return rc;
+   if (part->os_partition) {
+   rc = ppc_md.nvram_read((char *)&info,
+   sizeof(struct err_log_info),
+   &tmp_index);
+   if (rc <= 0) {
+   pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__,
+   rc);
+   return rc;
+   }
}
 
rc = ppc_md.nvram_read(buff, length, &tmp_index);
@@ -344,8 +356,10 @@ int nvram_read_partition(struct nvram_os_partition *part, 
char *buff,
return rc;
}
 
-   *error_log_cnt = info.seq_num;
-   *err_type = info.error_type;
+   if (part->os_partition) {
+   *error_log_cnt = info.seq_num;
+   *err_type = info.error_type;
+   }
 
return 0;
 }
@@ -516,7 +530,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
 }
 
 /*
- * Reads the oops/panic report and ibm,rtas-log partition.
+ * Reads the oops/panic report, rtas and of-config partition.
  * Returns the length of the data we read from each partition.
  * Returns 0 if we've been called before.
  */
@@ -525,9 +539,11 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
struct pstore_info *psi)
 {
struct oops_log_info *oops_hdr;
-   unsigned int err_type, id_no;
+   unsigned int err_type, id_no, size = 0;
struct nvram_os_partition *part = NULL;
char *buff = NULL;
+   int sig = 0;
+   loff_t p;
 
read_type++;
 
@@ -542,10 +558,29 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
time->tv_sec = last_rtas_event;
time->tv_nsec = 0;
break;
+   case PSTORE_TYPE_OF:
+   sig = NVRAM_SIG_OF;
+   part = &of_config_partition;
+   *type = PSTORE_TYPE_OF;
+   *id = PSTORE_TYPE_OF;
+   time->tv_sec = 0;
+   time->tv_nsec = 0;
+   break;
default:
return 0;
}
 
+   if (!part->os_partition) {
+   p = nvram_find_partition(part->name, sig, &size);
+   if (p <= 0) {
+   pr_err("nvram: Failed to find partition %s, "
+   "err %d\n", part->name, (int)p);
+   return 0;
+   }
+   part->index = p;
+   part->size = size;
+   }
+
buff = kmalloc(part->size, GFP_KERNEL);
 
if (!buff)
@@ -557,7 +592,9 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
}
 
*count = 0;
-   *id = id_no;
+
+   if (part->os_partition)
+   *id = id_no;
 
if (nvram_type_ids[read_type] == PSTORE_TYPE_DMESG) {
oops_hdr = (struct oops_log_info *)buff;
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index ec24f9c..8d4fb65 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -327,6 +327,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
case PSTORE_TYPE_PPC_RTAS:
sprintf(name, "rtas-%s-%lld", psname, id);
break;
+   case PSTORE_TYPE_PPC_OF:
+   sprintf(name, "of-%s-%lld", psname, id);
+   break;
case PSTORE_TYPE_UNKNOWN:
sprintf(name, "unknown-%s-%lld", psname, id);

[PATCH v2 8/8] powerpc/pseries: Read common partition via pstore

2013-04-23 Thread Aruna Balakrishnaiah
This patch exploits pstore subsystem to read details of common partition
in NVRAM to a separate file in /dev/pstore. For instance, common partition
details will be stored in a file named [common-nvram-6].

Signed-off-by: Aruna Balakrishnaiah 
Reviewed-by: Jim Keniston 
---
 arch/powerpc/platforms/pseries/nvram.c |   17 -
 fs/pstore/inode.c  |3 +++
 include/linux/pstore.h |1 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index de448af..8417816 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -138,10 +138,17 @@ static struct nvram_os_partition of_config_partition = {
.os_partition = false
 };
 
+static struct nvram_os_partition common_partition = {
+   .name = "common",
+   .index = -1,
+   .os_partition = false
+};
+
 static enum pstore_type_id nvram_type_ids[] = {
PSTORE_TYPE_DMESG,
PSTORE_TYPE_RTAS,
PSTORE_TYPE_OF,
+   PSTORE_TYPE_COMMON,
-1
 };
 static int read_type;
@@ -530,7 +537,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
 }
 
 /*
- * Reads the oops/panic report, rtas and of-config partition.
+ * Reads the oops/panic report, rtas, of-config and common partition.
  * Returns the length of the data we read from each partition.
  * Returns 0 if we've been called before.
  */
@@ -566,6 +573,14 @@ static ssize_t nvram_pstore_read(u64 *id, enum 
pstore_type_id *type,
time->tv_sec = 0;
time->tv_nsec = 0;
break;
+   case PSTORE_TYPE_COMMON:
+   sig = NVRAM_SIG_SYS;
+   part = &common_partition;
+   *type = PSTORE_TYPE_COMMON;
+   *id = PSTORE_TYPE_COMMON;
+   time->tv_sec = 0;
+   time->tv_nsec = 0;
+   break;
default:
return 0;
}
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 8d4fb65..88cc050 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -330,6 +330,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
case PSTORE_TYPE_PPC_OF:
sprintf(name, "of-%s-%lld", psname, id);
break;
+   case PSTORE_TYPE_PPC_COMMON:
+   sprintf(name, "common-%s-%lld", psname, id);
+   break;
case PSTORE_TYPE_UNKNOWN:
sprintf(name, "unknown-%s-%lld", psname, id);
break;
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 615dc18..656699f 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -38,6 +38,7 @@ enum pstore_type_id {
/* PPC64 partition types */
PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_PPC_OF  = 5,
+   PSTORE_TYPE_PPC_COMMON  = 6,
PSTORE_TYPE_UNKNOWN = 255
 };
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC, PATCH v3] powerpc/prom: Scan reserved-ranges node for memory reservations

2013-04-23 Thread Jeremy Kerr
Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr 

---
v3: Use of_get_flat_dt_root

---
 arch/powerpc/kernel/prom.c |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..9c753bc 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,33 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = of_get_flat_dt_root();
+
+   prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each,
+* totalling 4 cells per range. */
+   for (i = 0; i < len / (sizeof(*prop) * 4); i++) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4) + 0, 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +601,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params->totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH -V6 05/27] powerpc: New hugepage directory format

2013-04-23 Thread Paul Mackerras
On Mon, Apr 22, 2013 at 03:30:39PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" 

[snip]

>  /*
> - * Use the top bit of the higher-level page table entries to indicate whether
> - * the entries we point to contain hugepages.  This works because we know 
> that
> - * the page tables live in kernel space.  If we ever decide to support having
> - * page tables at arbitrary addresses, this breaks and will have to change.
> - */
> -#ifdef CONFIG_PPC64
> -#define PD_HUGE 0x8000
> -#else
> -#define PD_HUGE 0x8000
> -#endif

I think this is a good thing to do ultimately, but if you do this you
also need to fix arch/powerpc/kernel/head_fsl_booke.S:

#ifdef CONFIG_PTE_64BIT
#ifdef CONFIG_HUGETLB_PAGE
#define FIND_PTE\
rlwinm  r12, r10, 13, 19, 29;   /* Compute pgdir/pmd offset */  \
lwzxr11, r12, r11;  /* Get pgd/pmd entry */ \
rlwinm. r12, r11, 0, 0, 20; /* Extract pt base address */   \
blt 1000f;  /* Normal non-huge page */  \
beq 2f; /* Bail if no table */  \
orisr11, r11, PD_HUGE@h;/* Put back address bit */  \
andi.   r10, r11, HUGEPD_SHIFT_MASK@l; /* extract size field */ \
xor r12, r10, r11;  /* drop size bits from pointer */ \
b   1001f;  \

and this, from arch/powerpc/mm/tlb_low_64e.S:

cmpdi   cr0,r14,0
bge tlb_miss_fault_bolted   /* Bad pgd entry or hugepage; bail */

(of which there are several similar instances in that file).

If you want to avoid fixing these bits of assembly code (and any
others I missed in my quick scan), you'll need to keep the definition
of PD_HUGE, at least on anything not 64-bit Book3S.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] PowerPC: kernel: memory access violation when rtas_data_buf contents are more than 1026

2013-04-23 Thread Vasant Hegde

On 04/23/2013 08:42 AM, Chen Gang wrote:


need set '\0' for 'local_buffer'.

SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
rtas_data_buf may truncated in memcpy.

if contents are really truncated.
   the splpar_strlen is more than 1026. the next while loop checking will
   not find the end of buffer. that will cause memory access violation.



Per parameter length in ibm,get-system-parameter RTAS call is limited to 1026 
bytes (1024 bytes of data + 2 bytes  length). And 'rtas_data_buf' was set to 0 
(first 1026 bytes) before call RTAS call. At the worst if we get junk in RTAS 
output length field helps to exit from the while loop. So I don't think we need 
this patch.


-Vasant



Signed-off-by: Chen Gang
---
  arch/powerpc/kernel/lparcfg.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index 801a757..d92f387 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -299,6 +299,7 @@ static void parse_system_parameter_string(struct seq_file 
*m)
__pa(rtas_data_buf),
RTAS_DATA_BUF_SIZE);
memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
+   local_buffer[SPLPAR_MAXLENGTH - 1] = '\0';
spin_unlock(&rtas_data_buf_lock);

if (call_status != 0) {


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/1] usb: ehci-fsl: set INCR8 mode only on MPC512x

2013-04-23 Thread tiejun.chen

On 04/24/2013 01:55 PM, Anatolij Gustschin wrote:

On Wed, 24 Apr 2013 10:55:10 +0800
Tiejun Chen  wrote:


commit 761bbcb7, "usb: ehci-fsl: set INCR8 mode for system bus interface
on MPC512x", introduced to fix one MPC5121e (M36P) Errata by setting
INCR8 mode for system bus interface on MPC512x, but we should make sure
this is only valid for MPC512x like other parts of this commit. Otherwise


NAK. It is already only valid for MPC512x.


this would issue other platforms as abnormal without this similar Errata.


This setting is in the ehci_fsl_mpc512x_drv_resume() function which is
not called on other platforms.


Yes, I already notice this and also send a notification to ignore this improper 
patch immediately ;-)


Thanks,

Tiejun

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 1/1] USB/EHCI: work for different PHY_CLK_VALID detecting order

2013-04-23 Thread Tiejun Chen
Due to different controller issue of PHY_CLK_VALID in ULPI mode,
in some cases, after set PHY_CLK_SEL, we should set
USB_CTRL_USB_EN before checking PHY_CLK_VALID, otherwise
PHY_CLK_VALID doesn't work.

But in other cases USB_CTRL_USB_EN is already set previously and
PHY_CLK_VALID is not valid once USB_CTRL_USB_EN is set. But
since PHY_CLK_VALID is w1c, we can force clear USB_CTRL_USB_EN
firstly after set PHY_CLK_SEL, then PHY_CLK_VALID status can
be kept even we re-set USB_CTRL_USB_EN.

Signed-off-by: Tiejun Chen 
---
 drivers/usb/host/ehci-fsl.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index d81d2fc..57f2aa0 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -234,11 +234,20 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
/* controller version 1.6 or above */
setbits32(non_ehci + FSL_SOC_USB_CTRL,
ULPI_PHY_CLK_SEL);
+
/*
-* Due to controller issue of PHY_CLK_VALID in ULPI
-* mode, we set USB_CTRL_USB_EN before checking
-* PHY_CLK_VALID, otherwise PHY_CLK_VALID doesn't work.
+* Due to different controller issue of PHY_CLK_VALID
+* in ULPI mode, in some cases we should set
+* USB_CTRL_USB_EN before checking PHY_CLK_VALID,
+* otherwise PHY_CLK_VALID doesn't work.
+*
+* But in other cases USB_CTRL_USB_EN is already set
+* and PHY_CLK_VALID is not valid once USB_CTRL_USB_EN
+* is set. But since PHY_CLK_VALID is w1c, we can force
+* clear USB_CTRL_USB_EN firstly then PHY_CLK_VALID
+* status can be kept even we re-set USB_CTRL_USB_EN.
 */
+   clrbits32(non_ehci + FSL_SOC_USB_CTRL, USB_CTRL_USB_EN);
clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
UTMI_PHY_EN, USB_CTRL_USB_EN);
}
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev