* RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
From: Wang Dongsheng-B40534 @ 2013-04-23 10:10 UTC (permalink / raw)
To: galak@kernel.crashing.org
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1366155021.23030.24@snotra>
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;
> galak@kernel.crashing.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
>=20
> ACK
>=20
> -Scott
>=20
> 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.
> >
^ permalink raw reply
* Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
From: Benjamin Herrenschmidt @ 2013-04-23 10:05 UTC (permalink / raw)
To: Chen Yuanquan-B41889
Cc: Bjorn Helgaas, Yuanquan Chen, Hiroo Matsumoto, linuxppc-dev,
linux-pci
In-Reply-To: <517653D8.8000205@freescale.com>
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.
^ permalink raw reply
* Re: [linuxppc-release] [PATCH v2 01/15] powerpc/85xx: cache operations for Freescale SoCs based on BOOK3E
From: Zhao Chenhui @ 2013-04-23 9:53 UTC (permalink / raw)
To: Kumar Gala, Scott Wood; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1366368468-29143-1-git-send-email-chenhui.zhao@freescale.com>
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 <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> 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
>
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: don't unmap the PCI SoC controller registers in setup_pci_atmu
From: Roy Zang @ 2013-04-23 17:37 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1365837281-27002-1-git-send-email-haokexin@gmail.com>
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 0x8000080080040f14
> Faulting instruction address: 0xc00000000002ea58
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24 T4240 QDS
> Modules linked in:
> NIP: c00000000002ea58 LR: c00000000002eaf4 CTR: c00000000002eac0
> REGS: c00000017e10b4a0 TRAP: 0300 Not tainted (3.9.0-rc1-00052-gfa3529f-dirty)
> MSR: 0000000080029000 <CE,EE,ME> CR: 28adbe22 XER: 00000000
> SOFTE: 0
> DEAR: 8000080080040f14, ESR: 0000000000000000
> TASK = c00000017e100000[1] 'swapper/0' THREAD: c00000017e108000 CPU: 2
> GPR00: 0000000000000000 c00000017e10b720 c0000000009928d8 c00000017e578e00
> GPR04: 0000000000000000 000000000000000c 0000000000000001 c00000017e10bb40
> GPR08: 0000000000000000 8000080080040000 0000000000000000 0000000000000016
> GPR12: 0000000088adbe22 c00000000fffa800 c000000000001ba0 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a5b70
> GPR24: c0000000008af938 c0000000009a28d8 c0000000009bb5dc c00000017e10bb40
> GPR28: c00000017e32a400 c00000017e10bc00 c00000017e32a400 c00000017e578e00
> NIP [c00000000002ea58] .fsl_pcie_check_link+0x88/0xf0
> LR [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
> Call Trace:
> [c00000017e10b720] [c00000017e10b7a0] 0xc00000017e10b7a0 (unreliable)
> [c00000017e10ba30] [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
> [c00000017e10bad0] [c00000000033aa08] .pci_bus_read_config_byte+0x88/0xd0
> [c00000017e10bb90] [c00000000088d708] .pci_apply_final_quirks+0x9c/0x18c
> [c00000017e10bc40] [c0000000000013dc] .do_one_initcall+0x5c/0x1f0
> [c00000017e10bcf0] [c00000000086ebac] .kernel_init_freeable+0x180/0x26c
> [c00000017e10bdb0] [c000000000001bbc] .kernel_init+0x1c/0x460
> [c00000017e10be30] [c000000000000880] .ret_from_kernel_thread+0x64/0xe4
> Instruction dump:
> 38210310 2b800015 4fdde842 7c600026 5463fffe e8010010 7c0803a6 4e800020
> 60000000 60000000 e92301d0 7c0004ac <80690f14> 0c030000 4c00012c 38210310
> ---[ end trace 7a8fe0cbccb7d992 ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
>
acked.
thanks.
Roy
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Roy Zang @ 2013-04-23 17:33 UTC (permalink / raw)
To: Kevin Hao; +Cc: Yuanquan Chen, linuxppc-dev
In-Reply-To: <20130423091327.GA23644@pek-khao-d1.corp.ad.wrs.com>
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
^ permalink raw reply
* Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
From: Chen Yuanquan-B41889 @ 2013-04-23 9:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yuanquan Chen, Hiroo Matsumoto, linux-pci, bhelgaas, linuxppc-dev
In-Reply-To: <51652C20.2060105@freescale.com>
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
>>>
>>>
>>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Kevin Hao @ 2013-04-23 9:13 UTC (permalink / raw)
To: Roy Zang; +Cc: Yuanquan Chen, linuxppc-dev
In-Reply-To: <1366730283-14606-1-git-send-email-tie-fei.zang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 3981 bytes --]
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
> 0x8000080080060f14
> Faulting instruction address: 0xc000000000032554
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24 T4240 QDS
> Modules linked in:
> NIP: c000000000032554 LR: c00000000003254c CTR: c00000000001e5c0
> REGS: c000000179143440 TRAP: 0300 Not tainted
> (3.8.8-rt2-00754-g951f064-dirt)
> MSR: 0000000080029000 <CE,EE,ME> CR: 24adbe22 XER: 00000000
> SOFTE: 0
> DEAR: 8000080080060f14, ESR: 0000000000000000
> TASK = c00000017913d2c0[1] 'swapper/0' THREAD: c000000179140000 CPU: 2
> GPR00: c00000000003254c c0000001791436c0 c000000000ae2998
> 0000000000000027
> GPR04: 0000000000000000 00000000000005a5 0000000000000000
> 0000000000000002
> GPR08: 3030303038303038 c000000000a2d4d0 c000000000aebeb8
> c000000000af2998
> GPR12: 0000000024adbe22 c00000000fffa800 c000000000001be0
> 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000
> c0000000009ddf70
> GPR24: c0000000009e8d40 c000000000af2998 c000000000b1529c
> c000000179143b40
> GPR28: c0000001799b4000 c000000179143c00 8000080080060000
> c000000000727ec8
> NIP [c000000000032554] .fsl_pcie_check_link+0x104/0x150
> LR [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
> Call Trace:
> [c0000001791436c0] [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
> (unreliab)
> [c000000179143a30] [c0000000000325d4]
> .fsl_indirect_read_config+0x34/0xb0
> [c000000179143ad0] [c0000000002c7ee8]
> .pci_bus_read_config_byte+0x88/0xd0
> [c000000179143b90] [c0000000009c0528] .pci_apply_final_quirks+0x9c/0x18c
> [c000000179143c40] [c00000000000142c] .do_one_initcall+0x5c/0x1f0
> [c000000179143cf0] [c0000000009a0bb4] .kernel_init_freeable+0x180/0x264
> [c000000179143db0] [c000000000001bfc] .kernel_init+0x1c/0x420
> [c000000179143e30] [c0000000000008b4] .ret_from_kernel_thread+0x64/0xb0
> Instruction dump:
> 60000000 4bffffa0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
> 7fc5f378 486ea77d 60000000 7c0004ac <801e0f14> 0c000000 4c00012c
> 3c62ffe0
> ---[ end trace f841fbc03c9d2e1b ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Rebooting in 180 seconds..
>
> Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> 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
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Michael Ellerman @ 2013-04-23 9:12 UTC (permalink / raw)
To: Dennis Schridde; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <1470334.YUWOQ37ijW@ernie>
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
^ permalink raw reply
* Re: [PATCH -V6 05/27] powerpc: New hugepage directory format
From: Aneesh Kumar K.V @ 2013-04-23 8:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20130423070103.GB30092@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> 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
^ permalink raw reply
* [PATCH v2] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Roy Zang @ 2013-04-23 15:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Yuanquan Chen
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
0x8000080080060f14
Faulting instruction address: 0xc000000000032554
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24 T4240 QDS
Modules linked in:
NIP: c000000000032554 LR: c00000000003254c CTR: c00000000001e5c0
REGS: c000000179143440 TRAP: 0300 Not tainted
(3.8.8-rt2-00754-g951f064-dirt)
MSR: 0000000080029000 <CE,EE,ME> CR: 24adbe22 XER: 00000000
SOFTE: 0
DEAR: 8000080080060f14, ESR: 0000000000000000
TASK = c00000017913d2c0[1] 'swapper/0' THREAD: c000000179140000 CPU: 2
GPR00: c00000000003254c c0000001791436c0 c000000000ae2998
0000000000000027
GPR04: 0000000000000000 00000000000005a5 0000000000000000
0000000000000002
GPR08: 3030303038303038 c000000000a2d4d0 c000000000aebeb8
c000000000af2998
GPR12: 0000000024adbe22 c00000000fffa800 c000000000001be0
0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000
c0000000009ddf70
GPR24: c0000000009e8d40 c000000000af2998 c000000000b1529c
c000000179143b40
GPR28: c0000001799b4000 c000000179143c00 8000080080060000
c000000000727ec8
NIP [c000000000032554] .fsl_pcie_check_link+0x104/0x150
LR [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
Call Trace:
[c0000001791436c0] [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
(unreliab)
[c000000179143a30] [c0000000000325d4]
.fsl_indirect_read_config+0x34/0xb0
[c000000179143ad0] [c0000000002c7ee8]
.pci_bus_read_config_byte+0x88/0xd0
[c000000179143b90] [c0000000009c0528] .pci_apply_final_quirks+0x9c/0x18c
[c000000179143c40] [c00000000000142c] .do_one_initcall+0x5c/0x1f0
[c000000179143cf0] [c0000000009a0bb4] .kernel_init_freeable+0x180/0x264
[c000000179143db0] [c000000000001bfc] .kernel_init+0x1c/0x420
[c000000179143e30] [c0000000000008b4] .ret_from_kernel_thread+0x64/0xb0
Instruction dump:
60000000 4bffffa0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
7fc5f378 486ea77d 60000000 7c0004ac <801e0f14> 0c000000 4c00012c
3c62ffe0
---[ end trace f841fbc03c9d2e1b ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Rebooting in 180 seconds..
Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
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
^ permalink raw reply related
* Re: [PATCH -V6 05/27] powerpc: New hugepage directory format
From: Paul Mackerras @ 2013-04-23 7:01 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1366624861-24948-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
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.
^ permalink raw reply
* RE: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
From: Jia Hongtao-B38951 @ 2013-04-23 6:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130423052951.GB20902@concordia>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Michael
> Ellerman
> Sent: Tuesday, April 23, 2013 1:30 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc: Move opcode definitions from
> kvm/emulate.c to asm/ppc-opcode.h
>=20
> On Tue, Apr 23, 2013 at 10:39:35AM +0800, Jia Hongtao wrote:
> > Opcode and xopcode are useful definitions not just for KVM. Move these
> > definitions to asm/ppc-opcode.h for public use.
>=20
> Agreed. Though nearly everything else in ppc-opcode.h uses PPC_INST_FOO,
> or at least PPC_FOO, any reason not to update these to match?
>=20
> cheers
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.
Thanks.
-Hongtao
^ permalink raw reply
* Re: [PATCH] powerpc/rtas_flash: New return code to indicate FW entitlement expiry
From: Ananth N Mavinakayanahalli @ 2013-04-23 5:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Vasant Hegde, paulus, linuxppc-dev
In-Reply-To: <1366695150.2886.14.camel@pasglop>
On Tue, Apr 23, 2013 at 03:32:30PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-04-23 at 10:35 +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > > > Add new return code to rtas_flash to indicate firmware entitlement
> > > > expiry. This will be used by the update_flash script to return
> > > > appropriate message to the user.
> > >
> > > What's the point of that patch ? It adds a definition to a private .c
> > > file not exposed to user space and doesn't do anything with it ...
> >
> > Ben,
> >
> > The userspace update_flash script invokes the rtas_flash module. With
> > upcoming System p servers, the firmware will have the entitlement dates
> > encoded in it and RTAS will return an error if the entitlement has
> > expired. All we need from this module is for it to return that new error
> > which will then be communicated to the user by the update_flash.
>
> That doesn't answer my question :-)
>
> What is the point of adding a #define to a piece of code without any user
> of that definition and in a file that isn't exposed to user space ?
>
> IE. What is the point of the patch ?
Strictly, we don't need this (kernel) update...
But to keep the code in sync with PAPR, this was added. Agree that the
other return codes also don't say much about what they are for. Will
redo the patch with that info for better code readability.
^ permalink raw reply
* RE: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Zang Roy-R61911 @ 2013-04-23 5:44 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org; +Cc: Zang Roy-R61911, Chen Yuanquan-B41889
In-Reply-To: <1366655754-19400-1-git-send-email-tie-fei.zang@freescale.com>
> -----Original Message-----
> From: Zang Roy-R61911
> Sent: Tuesday, April 23, 2013 2:36 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: galak@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889
> Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
> >private_data
>=20
> pci hose->private_data will be used by other function, for example,
> fsl_pcie_check_link(), so do not iounmap it.
>=20
> fix the kerenl crash on T4240:
>=20
> Unable to handle kernel paging request for data at address
> 0x8000080080060f14
> Faulting instruction address: 0xc000000000032554
> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=3D24 T4240 QDS
> Modules linked in:
> NIP: c000000000032554 LR: c00000000003254c CTR: c00000000001e5c0
> REGS: c000000179143440 TRAP: 0300 Not tainted
> (3.8.8-rt2-00754-g951f064-dirt)
> MSR: 0000000080029000 <CE,EE,ME> CR: 24adbe22 XER: 00000000
> SOFTE: 0
> DEAR: 8000080080060f14, ESR: 0000000000000000 TASK =3D c00000017913d2c0[1=
]
> 'swapper/0' THREAD: c000000179140000 CPU: 2
> GPR00: c00000000003254c c0000001791436c0 c000000000ae2998
> 0000000000000027
> GPR04: 0000000000000000 00000000000005a5 0000000000000000
> 0000000000000002
> GPR08: 3030303038303038 c000000000a2d4d0 c000000000aebeb8
> c000000000af2998
> GPR12: 0000000024adbe22 c00000000fffa800 c000000000001be0
> 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000
> c0000000009ddf70
> GPR24: c0000000009e8d40 c000000000af2998 c000000000b1529c
> c000000179143b40
> GPR28: c0000001799b4000 c000000179143c00 8000080080060000
> c000000000727ec8
> NIP [c000000000032554] .fsl_pcie_check_link+0x104/0x150 LR
> [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace:
> [c0000001791436c0] [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
> (unreliab)
> [c000000179143a30] [c0000000000325d4]
> .fsl_indirect_read_config+0x34/0xb0
> [c000000179143ad0] [c0000000002c7ee8]
> .pci_bus_read_config_byte+0x88/0xd0
> [c000000179143b90] [c0000000009c0528] .pci_apply_final_quirks+0x9c/0x18c
> [c000000179143c40] [c00000000000142c] .do_one_initcall+0x5c/0x1f0
> [c000000179143cf0] [c0000000009a0bb4] .kernel_init_freeable+0x180/0x264
> [c000000179143db0] [c000000000001bfc] .kernel_init+0x1c/0x420
> [c000000179143e30] [c0000000000008b4] .ret_from_kernel_thread+0x64/0xb0
> Instruction dump:
> 60000000 4bffffa0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
> 7fc5f378 486ea77d 60000000 7c0004ac <801e0f14> 0c000000 4c00012c 3c62ffe0
> ---[ end trace f841fbc03c9d2e1b ]---
>=20
> Kernel panic - not syncing: Attempted to kill init! exitcode=3D0x0000000b
>=20
> Rebooting in 180 seconds..
>=20
> Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> based on Kumar's next branch.
> tested on P3041 and T4240.
Please ignore this patch, I will send a v2 version.
Thanks.
Roy
^ permalink raw reply
* [PATCH V4 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM
POWER8 processor which records the branch instructions inside the execution
pipeline. This patchset enables the basic functionality of the feature through
generic perf branch stack sampling framework.
Sample output
-------------
$./perf record -b top
$./perf report
Overhead Command Source Shared Object Source Symbol Target Shared Object Target Symbol
# ........ ....... .................... ...................................... .................... ...................................
#
7.82% top libc-2.11.2.so [k] _IO_vfscanf libc-2.11.2.so [k] _IO_vfscanf
6.17% top libc-2.11.2.so [k] _IO_vfscanf [unknown] [k] 00000000
2.37% top [unknown] [k] 0xf7aafb30 [unknown] [k] 00000000
1.80% top [unknown] [k] 0x0fe07978 libc-2.11.2.so [k] _IO_vfscanf
1.60% top libc-2.11.2.so [k] _IO_vfscanf [kernel.kallsyms] [k] .do_task_stat
1.20% top [kernel.kallsyms] [k] .do_task_stat [kernel.kallsyms] [k] .do_task_stat
1.02% top libc-2.11.2.so [k] vfprintf libc-2.11.2.so [k] vfprintf
0.92% top top [k] _init [unknown] [k] 0x0fe037f4
Changes in V2
--------------
- Added copyright messages to the newly created files
- Modified couple of commit messages
Changes in V3
-------------
- Incorporated review comments from Segher https://lkml.org/lkml/2013/4/16/350
- Worked on a solution for review comment from Michael Ellerman https://lkml.org/lkml/2013/4/17/548
- Could not move updated cpu_hw_events structure from core-book3s.c file into perf_event_server.h
Because perf_event_server.h is pulled in first inside linux/perf_event.h before the definition of
perf_branch_entry structure. Thats the reason why perf_branch_entry definition is not available
inside perf_event_server.h where we define the array inside cpu_hw_events structure.
- Finally have pulled in the code from perf_event_bhrb.c into core-book3s.c
- Improved documentation for the patchset
Changes in V4
-------------
- Incorporated review comments on V3 regarding new instruction encoding
Anshuman Khandual (5):
powerpc, perf: Add new BHRB related instructions for POWER8
powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
powerpc, perf: Add new BHRB related generic functions, data and flags
powerpc, perf: Define BHRB generic functions, data and flags for POWER8
powerpc, perf: Enable branch stack sampling framework
arch/powerpc/include/asm/perf_event_server.h | 7 ++
arch/powerpc/include/asm/ppc-opcode.h | 8 ++
arch/powerpc/perf/Makefile | 2 +-
arch/powerpc/perf/bhrb.S | 44 +++++++
arch/powerpc/perf/core-book3s.c | 167 ++++++++++++++++++++++++++-
arch/powerpc/perf/power8-pmu.c | 57 ++++++++-
6 files changed, 280 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/perf/bhrb.S
--
1.7.11.7
^ permalink raw reply
* [PATCH V4 2/5] powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
This patch adds the basic assembly code to read BHRB buffer. BHRB entries
are valid only after a PMU interrupt has happened (when MMCR0[PMAO]=1)
and BHRB has been freezed. BHRB read should not be attempted when it is
still enabled (MMCR0[PMAE]=1) and getting updated, as this can produce
non-deterministic results.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/Makefile | 2 +-
arch/powerpc/perf/bhrb.S | 44 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/perf/bhrb.S
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index 472db18..510fae1 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,7 +2,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
obj-$(CONFIG_PERF_EVENTS) += callchain.o
-obj-$(CONFIG_PPC_PERF_CTRS) += core-book3s.o
+obj-$(CONFIG_PPC_PERF_CTRS) += core-book3s.o bhrb.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o \
power8-pmu.o
diff --git a/arch/powerpc/perf/bhrb.S b/arch/powerpc/perf/bhrb.S
new file mode 100644
index 0000000..d85f9a5
--- /dev/null
+++ b/arch/powerpc/perf/bhrb.S
@@ -0,0 +1,44 @@
+/*
+ * Basic assembly code to read BHRB entries
+ *
+ * Copyright 2013 Anshuman Khandual, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <asm/ppc_asm.h>
+#include <asm/ppc-opcode.h>
+
+ .text
+
+.balign 8
+
+/* r3 = n (where n = [0-31])
+ * The maximum number of BHRB entries supported with PPC_MFBHRBE instruction
+ * is 1024. We have limited number of table entries here as POWER8 implements
+ * 32 BHRB entries.
+ */
+
+/* .global read_bhrb */
+_GLOBAL(read_bhrb)
+ cmpldi r3,31
+ bgt 1f
+ ld r4,bhrb_table@got(r2)
+ sldi r3,r3,3
+ add r3,r4,r3
+ mtctr r3
+ bctr
+1: li r3,0
+ blr
+
+#define MFBHRB_TABLE1(n) PPC_MFBHRBE(R3,n); blr
+#define MFBHRB_TABLE2(n) MFBHRB_TABLE1(n); MFBHRB_TABLE1(n+1)
+#define MFBHRB_TABLE4(n) MFBHRB_TABLE2(n); MFBHRB_TABLE2(n+2)
+#define MFBHRB_TABLE8(n) MFBHRB_TABLE4(n); MFBHRB_TABLE4(n+4)
+#define MFBHRB_TABLE16(n) MFBHRB_TABLE8(n); MFBHRB_TABLE8(n+8)
+#define MFBHRB_TABLE32(n) MFBHRB_TABLE16(n); MFBHRB_TABLE16(n+16)
+
+bhrb_table:
+ MFBHRB_TABLE32(0)
--
1.7.11.7
^ permalink raw reply related
* [PATCH V4 1/5] powerpc, perf: Add new BHRB related instructions for POWER8
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
This patch adds new POWER8 instruction encoding for reading
and clearing Branch History Rolling Buffer entries. The new
instruction 'mfbhrbe' (move from branch history rolling buffer
entry) is used to read BHRB buffer entries and instruction
'clrbhrb' (clear branch history rolling buffer) is used to
clear the entire buffer. The instruction 'clrbhrb' has straight
forward encoding. But the instruction encoding format for
reading the BHRB entries is like 'mfbhrbe RT, BHRBE' where it
takes two arguments, i.e the index for the BHRB buffer entry to
read and a general purpose register to put the value which was
read from the buffer entry.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 8752bc8..0c34e48 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -82,6 +82,8 @@
#define __REGA0_R31 31
/* sorted alphabetically */
+#define PPC_INST_BHRBE 0x7c00025c
+#define PPC_INST_CLRBHRB 0x7c00035c
#define PPC_INST_DCBA 0x7c0005ec
#define PPC_INST_DCBA_MASK 0xfc0007fe
#define PPC_INST_DCBAL 0x7c2005ec
@@ -297,6 +299,12 @@
#define PPC_NAP stringify_in_c(.long PPC_INST_NAP)
#define PPC_SLEEP stringify_in_c(.long PPC_INST_SLEEP)
+/* BHRB instructions */
+#define PPC_CLRBHRB stringify_in_c(.long PPC_INST_CLRBHRB)
+#define PPC_MFBHRBE(r, n) stringify_in_c(.long PPC_INST_BHRBE | \
+ __PPC_RT(r) | \
+ (((n) & 0x3ff) << 11))
+
/* Transactional memory instructions */
#define TRECHKPT stringify_in_c(.long PPC_INST_TRECHKPT)
#define TRECLAIM(r) stringify_in_c(.long PPC_INST_TRECLAIM \
--
1.7.11.7
^ permalink raw reply related
* [PATCH V4 5/5] powerpc, perf: Enable branch stack sampling framework
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
Provides basic enablement for perf branch stack sampling framework on
POWER8 processor based platforms. Adds new BHRB related elements into
cpu_hw_event structure to represent current BHRB config, BHRB filter
configuration, manage context and to hold output BHRB buffer during
PMU interrupt before passing to the user space. This also enables
processing of BHRB data and converts them into generic perf branch
stack data format.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/perf_event_server.h | 1 +
arch/powerpc/perf/core-book3s.c | 167 ++++++++++++++++++++++++++-
2 files changed, 165 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 3f0c15c..f265049 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -73,6 +73,7 @@ extern int register_power_pmu(struct power_pmu *);
struct pt_regs;
extern unsigned long perf_misc_flags(struct pt_regs *regs);
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
+extern unsigned long int read_bhrb(int n);
/*
* Only override the default definitions in include/linux/perf_event.h
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..c627843 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,11 @@
#include <asm/firmware.h>
#include <asm/ptrace.h>
+#define BHRB_MAX_ENTRIES 32
+#define BHRB_TARGET 0x0000000000000002
+#define BHRB_PREDICTION 0x0000000000000001
+#define BHRB_EA 0xFFFFFFFFFFFFFFFC
+
struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,7 +43,15 @@ struct cpu_hw_events {
unsigned int group_flag;
int n_txn_start;
+
+ /* BHRB bits */
+ u64 bhrb_filter; /* BHRB HW branch filter */
+ int bhrb_users;
+ void *bhrb_context;
+ struct perf_branch_stack bhrb_stack;
+ struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
};
+
DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
struct power_pmu *ppmu;
@@ -858,6 +871,9 @@ static void power_pmu_enable(struct pmu *pmu)
}
out:
+ if (cpuhw->bhrb_users)
+ ppmu->config_bhrb(cpuhw->bhrb_filter);
+
local_irq_restore(flags);
}
@@ -888,6 +904,47 @@ static int collect_events(struct perf_event *group, int max_count,
return n;
}
+/* Reset all possible BHRB entries */
+static void power_pmu_bhrb_reset(void)
+{
+ asm volatile(PPC_CLRBHRB);
+}
+
+void power_pmu_bhrb_enable(struct perf_event *event)
+{
+ struct cpu_hw_events *cpuhw = &__get_cpu_var(cpu_hw_events);
+
+ if (!ppmu->bhrb_nr)
+ return;
+
+ /* Clear BHRB if we changed task context to avoid data leaks */
+ if (event->ctx->task && cpuhw->bhrb_context != event->ctx) {
+ power_pmu_bhrb_reset();
+ cpuhw->bhrb_context = event->ctx;
+ }
+ cpuhw->bhrb_users++;
+}
+
+void power_pmu_bhrb_disable(struct perf_event *event)
+{
+ struct cpu_hw_events *cpuhw = &__get_cpu_var(cpu_hw_events);
+
+ if (!ppmu->bhrb_nr)
+ return;
+
+ cpuhw->bhrb_users--;
+ WARN_ON_ONCE(cpuhw->bhrb_users < 0);
+
+ if (!cpuhw->disabled && !cpuhw->bhrb_users) {
+ /* BHRB cannot be turned off when other
+ * events are active on the PMU.
+ */
+
+ /* avoid stale pointer */
+ cpuhw->bhrb_context = NULL;
+ }
+}
+
/*
* Add a event to the PMU.
* If all events are not already frozen, then we disable and
@@ -947,6 +1004,9 @@ nocheck:
ret = 0;
out:
+ if (has_branch_stack(event))
+ power_pmu_bhrb_enable(event);
+
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
return ret;
@@ -999,6 +1059,9 @@ static void power_pmu_del(struct perf_event *event, int ef_flags)
cpuhw->mmcr[0] &= ~(MMCR0_PMXE | MMCR0_FCECE);
}
+ if (has_branch_stack(event))
+ power_pmu_bhrb_disable(event);
+
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
}
@@ -1117,6 +1180,15 @@ int power_pmu_commit_txn(struct pmu *pmu)
return 0;
}
+/* Called from ctxsw to prevent one process's branch entries to
+ * mingle with the other process's entries during context switch.
+ */
+void power_pmu_flush_branch_stack(void)
+{
+ if (ppmu->bhrb_nr)
+ power_pmu_bhrb_reset();
+}
+
/*
* Return 1 if we might be able to put event on a limited PMC,
* or 0 if not.
@@ -1231,9 +1303,11 @@ static int power_pmu_event_init(struct perf_event *event)
if (!ppmu)
return -ENOENT;
- /* does not support taken branch sampling */
- if (has_branch_stack(event))
- return -EOPNOTSUPP;
+ if (has_branch_stack(event)) {
+ /* PMU has BHRB enabled */
+ if (!(ppmu->flags & PPMU_BHRB))
+ return -EOPNOTSUPP;
+ }
switch (event->attr.type) {
case PERF_TYPE_HARDWARE:
@@ -1314,6 +1388,15 @@ static int power_pmu_event_init(struct perf_event *event)
cpuhw = &get_cpu_var(cpu_hw_events);
err = power_check_constraints(cpuhw, events, cflags, n + 1);
+
+ if (has_branch_stack(event)) {
+ cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+ event->attr.branch_sample_type);
+
+ if(cpuhw->bhrb_filter == -1)
+ return -EOPNOTSUPP;
+ }
+
put_cpu_var(cpu_hw_events);
if (err)
return -EINVAL;
@@ -1372,8 +1455,79 @@ struct pmu power_pmu = {
.cancel_txn = power_pmu_cancel_txn,
.commit_txn = power_pmu_commit_txn,
.event_idx = power_pmu_event_idx,
+ .flush_branch_stack = power_pmu_flush_branch_stack,
};
+/* Processing BHRB entries */
+void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
+{
+ u64 val;
+ u64 addr;
+ int r_index, u_index, target, pred;
+
+ r_index = 0;
+ u_index = 0;
+ while (r_index < ppmu->bhrb_nr) {
+ /* Assembly read function */
+ val = read_bhrb(r_index);
+
+ /* Terminal marker: End of valid BHRB entries */
+ if (val == 0) {
+ break;
+ } else {
+ /* BHRB field break up */
+ addr = val & BHRB_EA;
+ pred = val & BHRB_PREDICTION;
+ target = val & BHRB_TARGET;
+
+ /* Probable Missed entry: Not applicable for POWER8 */
+ if ((addr == 0) && (target == 0) && (pred == 1)) {
+ r_index++;
+ continue;
+ }
+
+ /* Real Missed entry: Power8 based missed entry */
+ if ((addr == 0) && (target == 1) && (pred == 1)) {
+ r_index++;
+ continue;
+ }
+
+ /* Reserved condition: Not a valid entry */
+ if ((addr == 0) && (target == 1) && (pred == 0)) {
+ r_index++;
+ continue;
+ }
+
+ /* Is a target address */
+ if (val & BHRB_TARGET) {
+ /* First address cannot be a target address */
+ if (r_index == 0) {
+ r_index++;
+ continue;
+ }
+
+ /* Update target address for the previous entry */
+ cpuhw->bhrb_entries[u_index - 1].to = addr;
+ cpuhw->bhrb_entries[u_index - 1].mispred = pred;
+ cpuhw->bhrb_entries[u_index - 1].predicted = ~pred;
+
+ /* Dont increment u_index */
+ r_index++;
+ } else {
+ /* Update address, flags for current entry */
+ cpuhw->bhrb_entries[u_index].from = addr;
+ cpuhw->bhrb_entries[u_index].mispred = pred;
+ cpuhw->bhrb_entries[u_index].predicted = ~pred;
+
+ /* Successfully popullated one entry */
+ u_index++;
+ r_index++;
+ }
+ }
+ }
+ cpuhw->bhrb_stack.nr = u_index;
+ return;
+}
/*
* A counter has overflowed; update its count and record
@@ -1433,6 +1587,13 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (event->attr.sample_type & PERF_SAMPLE_ADDR)
perf_get_data_addr(regs, &data.addr);
+ if (event->attr.sample_type & PERF_SAMPLE_BRANCH_STACK) {
+ struct cpu_hw_events *cpuhw;
+ cpuhw = &__get_cpu_var(cpu_hw_events);
+ power_pmu_bhrb_read(cpuhw);
+ data.br_stack = &cpuhw->bhrb_stack;
+ }
+
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH V4 3/5] powerpc, perf: Add new BHRB related generic functions, data and flags
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
This patch adds couple of generic functions to power_pmu structure
which would configure the BHRB and it's filters. It also adds
representation of the number of BHRB entries present on the PMU.
A new PMU flag PPMU_BHRB would indicate presence of BHRB feature.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/perf_event_server.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 57b42da..3f0c15c 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -33,6 +33,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
+ u64 (*bhrb_filter_map)(u64 branch_sample_type);
+ void (*config_bhrb)(u64 pmu_bhrb_filter);
void (*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
u32 flags;
@@ -42,6 +44,9 @@ struct power_pmu {
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
[PERF_COUNT_HW_CACHE_RESULT_MAX];
+
+ /* BHRB entries in the PMU */
+ int bhrb_nr;
};
/*
@@ -54,6 +59,7 @@ struct power_pmu {
#define PPMU_SIAR_VALID 0x00000010 /* Processor has SIAR Valid bit */
#define PPMU_HAS_SSLOT 0x00000020 /* Has sampled slot in MMCRA */
#define PPMU_HAS_SIER 0x00000040 /* Has SIER */
+#define PPMU_BHRB 0x00000080 /* has BHRB feature enabled */
/*
* Values for flags to get_alternatives()
--
1.7.11.7
^ permalink raw reply related
* [PATCH V4 4/5] powerpc, perf: Define BHRB generic functions, data and flags for POWER8
From: Anshuman Khandual @ 2013-04-23 5:42 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: mikey
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
This patch populates BHRB specific data for power_pmu structure. It
also implements POWER8 specific BHRB filter and configuration functions.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/power8-pmu.c | 57 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 106ae0b..153408c 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -109,6 +109,16 @@
#define EVENT_IS_MARKED (EVENT_MARKED_MASK << EVENT_MARKED_SHIFT)
#define EVENT_PSEL_MASK 0xff /* PMCxSEL value */
+/* MMCRA IFM bits - POWER8 */
+#define POWER8_MMCRA_IFM1 0x0000000040000000UL
+#define POWER8_MMCRA_IFM2 0x0000000080000000UL
+#define POWER8_MMCRA_IFM3 0x00000000C0000000UL
+
+#define ONLY_PLM \
+ (PERF_SAMPLE_BRANCH_USER |\
+ PERF_SAMPLE_BRANCH_KERNEL |\
+ PERF_SAMPLE_BRANCH_HV)
+
/*
* Layout of constraint bits:
*
@@ -428,6 +438,48 @@ static int power8_generic_events[] = {
[PERF_COUNT_HW_BRANCH_MISSES] = PM_BR_MPRED_CMPL,
};
+static u64 power8_bhrb_filter_map(u64 branch_sample_type)
+{
+ u64 pmu_bhrb_filter = 0;
+ u64 br_privilege = branch_sample_type & ONLY_PLM;
+
+ /* BHRB and regular PMU events share the same prvillege state
+ * filter configuration. BHRB is always recorded along with a
+ * regular PMU event. So privilege state filter criteria for BHRB
+ * and the companion PMU events has to be the same. As a default
+ * "perf record" tool sets all privillege bits ON when no filter
+ * criteria is provided in the command line. So as along as all
+ * privillege bits are ON or they are OFF, we are good to go.
+ */
+ if ((br_privilege != 7) && (br_privilege != 0))
+ return -1;
+
+ /* No branch filter requested */
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY)
+ return pmu_bhrb_filter;
+
+ /* Invalid branch filter options - HW does not support */
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_RETURN)
+ return -1;
+
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_IND_CALL)
+ return -1;
+
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) {
+ pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
+ return pmu_bhrb_filter;
+ }
+
+ /* Every thing else is unsupported */
+ return -1;
+}
+
+static void power8_config_bhrb(u64 pmu_bhrb_filter)
+{
+ /* Enable BHRB filter in PMU */
+ mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
+}
+
static struct power_pmu power8_pmu = {
.name = "POWER8",
.n_counter = 6,
@@ -435,12 +487,15 @@ static struct power_pmu power8_pmu = {
.add_fields = POWER8_ADD_FIELDS,
.test_adder = POWER8_TEST_ADDER,
.compute_mmcr = power8_compute_mmcr,
+ .config_bhrb = power8_config_bhrb,
+ .bhrb_filter_map = power8_bhrb_filter_map,
.get_constraint = power8_get_constraint,
.disable_pmc = power8_disable_pmc,
- .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER,
+ .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_BHRB,
.n_generic = ARRAY_SIZE(power8_generic_events),
.generic_events = power8_generic_events,
.attr_groups = power8_pmu_attr_groups,
+ .bhrb_nr = 32,
};
static int __init init_power8_pmu(void)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] powerpc/rtas_flash: New return code to indicate FW entitlement expiry
From: Benjamin Herrenschmidt @ 2013-04-23 5:32 UTC (permalink / raw)
To: ananth; +Cc: Vasant Hegde, paulus, linuxppc-dev
In-Reply-To: <20130423050540.GA30690@in.ibm.com>
On Tue, 2013-04-23 at 10:35 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > > Add new return code to rtas_flash to indicate firmware entitlement
> > > expiry. This will be used by the update_flash script to return
> > > appropriate message to the user.
> >
> > What's the point of that patch ? It adds a definition to a private .c
> > file not exposed to user space and doesn't do anything with it ...
>
> Ben,
>
> The userspace update_flash script invokes the rtas_flash module. With
> upcoming System p servers, the firmware will have the entitlement dates
> encoded in it and RTAS will return an error if the entitlement has
> expired. All we need from this module is for it to return that new error
> which will then be communicated to the user by the update_flash.
That doesn't answer my question :-)
What is the point of adding a #define to a piece of code without any user
of that definition and in a file that isn't exposed to user space ?
IE. What is the point of the patch ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/rtas_flash: New return code to indicate FW entitlement expiry
From: Vasant Hegde @ 2013-04-23 5:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev
In-Reply-To: <1366677610.2886.8.camel@pasglop>
On 04/23/2013 06:10 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
>> Add new return code to rtas_flash to indicate firmware entitlement
>> expiry. This will be used by the update_flash script to return
>> appropriate message to the user.
>
> What's the point of that patch ? It adds a definition to a private .c
> file not exposed to user space and doesn't do anything with it ...
>
This is to keep our code in sync with PAPR. And when we get this return
code from "ibm,validate-flash-image" RTAS call, user space tools (update_flash)
reads output buffer via /proc interface to display appropriate message to user.
-Vasant
> Ben.
>
>> Signed-off-by: Ananth N Mavinakayanahalli<ananth@in.ibm.com>
>> Signed-off-by: Vasant Hegde<hegdevasant@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kernel/rtas_flash.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
>> index a7020d2..0a12c16 100644
>> --- a/arch/powerpc/kernel/rtas_flash.c
>> +++ b/arch/powerpc/kernel/rtas_flash.c
>> @@ -64,6 +64,7 @@
>> #define VALIDATE_TMP_COMMIT_DL 4 /* Validate Return Status */
>> #define VALIDATE_TMP_COMMIT 5 /* Validate Return Status */
>> #define VALIDATE_TMP_UPDATE_DL 6 /* Validate Return Status */
>> +#define VALIDATE_OUT_OF_WRNTY 7 /* Validate Return Status */
>>
>> /* ibm,manage-flash-image operation tokens */
>> #define RTAS_REJECT_TMP_IMG 0
>
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
From: Michael Ellerman @ 2013-04-23 5:29 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
In-Reply-To: <1366684776-10946-1-git-send-email-hongtao.jia@freescale.com>
On Tue, Apr 23, 2013 at 10:39:35AM +0800, Jia Hongtao wrote:
> Opcode and xopcode are useful definitions not just for KVM. Move these
> definitions to asm/ppc-opcode.h for public use.
Agreed. Though nearly everything else in ppc-opcode.h uses PPC_INST_FOO,
or at least PPC_FOO, any reason not to update these to match?
cheers
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 8752bc8..18de83a 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -81,6 +81,51 @@
> #define __REGA0_R30 30
> #define __REGA0_R31 31
>
> +/* opcode and xopcode for instructions */
> +#define OP_TRAP 3
> +#define OP_TRAP_64 2
> +
> +#define OP_31_XOP_TRAP 4
> +#define OP_31_XOP_LWZX 23
> +#define OP_31_XOP_LWZUX 55
> +#define OP_31_XOP_TRAP_64 68
> +#define OP_31_XOP_DCBF 86
> +#define OP_31_XOP_LBZX 87
> +#define OP_31_XOP_STWX 151
> +#define OP_31_XOP_STBX 215
> +#define OP_31_XOP_LBZUX 119
> +#define OP_31_XOP_STBUX 247
> +#define OP_31_XOP_LHZX 279
> +#define OP_31_XOP_LHZUX 311
> +#define OP_31_XOP_MFSPR 339
> +#define OP_31_XOP_LHAX 343
> +#define OP_31_XOP_STHX 407
> +#define OP_31_XOP_STHUX 439
> +#define OP_31_XOP_MTSPR 467
> +#define OP_31_XOP_DCBI 470
> +#define OP_31_XOP_LWBRX 534
> +#define OP_31_XOP_TLBSYNC 566
> +#define OP_31_XOP_STWBRX 662
> +#define OP_31_XOP_LHBRX 790
> +#define OP_31_XOP_STHBRX 918
> +
> +#define OP_LWZ 32
> +#define OP_LD 58
> +#define OP_LWZU 33
> +#define OP_LBZ 34
> +#define OP_LBZU 35
> +#define OP_STW 36
> +#define OP_STWU 37
> +#define OP_STD 62
> +#define OP_STB 38
> +#define OP_STBU 39
> +#define OP_LHZ 40
> +#define OP_LHZU 41
> +#define OP_LHA 42
> +#define OP_LHAU 43
> +#define OP_STH 44
> +#define OP_STHU 45
> +
> /* sorted alphabetically */
> #define PPC_INST_DCBA 0x7c0005ec
> #define PPC_INST_DCBA_MASK 0xfc0007fe
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index 7a73b6f..426d3f5 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -30,52 +30,10 @@
> #include <asm/byteorder.h>
> #include <asm/kvm_ppc.h>
> #include <asm/disassemble.h>
> +#include <asm/ppc-opcode.h>
> #include "timing.h"
> #include "trace.h"
>
> -#define OP_TRAP 3
> -#define OP_TRAP_64 2
> -
> -#define OP_31_XOP_TRAP 4
> -#define OP_31_XOP_LWZX 23
> -#define OP_31_XOP_TRAP_64 68
> -#define OP_31_XOP_DCBF 86
> -#define OP_31_XOP_LBZX 87
> -#define OP_31_XOP_STWX 151
> -#define OP_31_XOP_STBX 215
> -#define OP_31_XOP_LBZUX 119
> -#define OP_31_XOP_STBUX 247
> -#define OP_31_XOP_LHZX 279
> -#define OP_31_XOP_LHZUX 311
> -#define OP_31_XOP_MFSPR 339
> -#define OP_31_XOP_LHAX 343
> -#define OP_31_XOP_STHX 407
> -#define OP_31_XOP_STHUX 439
> -#define OP_31_XOP_MTSPR 467
> -#define OP_31_XOP_DCBI 470
> -#define OP_31_XOP_LWBRX 534
> -#define OP_31_XOP_TLBSYNC 566
> -#define OP_31_XOP_STWBRX 662
> -#define OP_31_XOP_LHBRX 790
> -#define OP_31_XOP_STHBRX 918
> -
> -#define OP_LWZ 32
> -#define OP_LD 58
> -#define OP_LWZU 33
> -#define OP_LBZ 34
> -#define OP_LBZU 35
> -#define OP_STW 36
> -#define OP_STWU 37
> -#define OP_STD 62
> -#define OP_STB 38
> -#define OP_STBU 39
> -#define OP_LHZ 40
> -#define OP_LHZU 41
> -#define OP_LHA 42
> -#define OP_LHAU 43
> -#define OP_STH 44
> -#define OP_STHU 45
> -
> void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
> {
> unsigned long dec_nsec;
> --
> 1.8.0
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc/rtas_flash: New return code to indicate FW entitlement expiry
From: Ananth N Mavinakayanahalli @ 2013-04-23 5:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Vasant Hegde, paulus, linuxppc-dev
In-Reply-To: <1366677610.2886.8.camel@pasglop>
On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > Add new return code to rtas_flash to indicate firmware entitlement
> > expiry. This will be used by the update_flash script to return
> > appropriate message to the user.
>
> What's the point of that patch ? It adds a definition to a private .c
> file not exposed to user space and doesn't do anything with it ...
Ben,
The userspace update_flash script invokes the rtas_flash module. With
upcoming System p servers, the firmware will have the entitlement dates
encoded in it and RTAS will return an error if the entitlement has
expired. All we need from this module is for it to return that new error
which will then be communicated to the user by the update_flash.
Ananth
^ permalink raw reply
* RE: [PATCH 2/3 v13] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
From: Sethi Varun-B16395 @ 2013-04-23 4:45 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: joro@8bytes.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1366674609.10399.12@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, April 23, 2013 5:20 AM
> To: Sethi Varun-B16395
> Cc: joro@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> galak@kernel.crashing.org; benh@kernel.crashing.org; Yoder Stuart-B08248;
> Sethi Varun-B16395
> Subject: Re: [PATCH 2/3 v13] iommu/fsl: Add additional iommu attributes
> required by the PAMU driver.
>=20
> On 04/22/2013 12:31:55 AM, 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 <Varun.Sethi@freescale.com>
> > ---
> > 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
> > +++++++++++++++++++++++++++++++++++++++
> > include/linux/iommu.h | 16 ++++++++++++++++
> > 2 files changed, 55 insertions(+), 0 deletions(-) create mode 100644
> > include/linux/fsl_pamu_stash.h
> >
> > diff --git a/include/linux/fsl_pamu_stash.h
> > b/include/linux/fsl_pamu_stash.h new file mode 100644 index
> > 0000000..caa1b21
> > --- /dev/null
> > +++ b/include/linux/fsl_pamu_stash.h
> > @@ -0,0 +1,39 @@
> > +/*
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License, version 2,
> > as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301, USA.
> > + *
> > + * Copyright (C) 2013 Freescale Semiconductor, Inc.
> > + *
> > + */
> > +
> > +#ifndef __FSL_PAMU_STASH_H
> > +#define __FSL_PAMU_STASH_H
> > +
> > +/* cache stash targets */
> > +enum pamu_stash_target {
> > + PAMU_ATTR_CACHE_L1 =3D 1,
> > + PAMU_ATTR_CACHE_L2,
> > + PAMU_ATTR_CACHE_L3,
> > +};
> > +
> > +/*
> > + * This attribute allows configuring stashig specific parameters
> > + * in the PAMU hardware.
> > + */
> > +
> > +struct pamu_stash_attribute {
> > + u32 cpu; /* cpu number */
> > + u32 cache; /* cache to stash to: L1,L2,L3 */
> > +};
> > +
> > +#endif /* __FSL_PAMU_STASH_H */
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
> > 2727810..c5dc2b9 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -57,10 +57,26 @@ struct iommu_domain {
> > #define IOMMU_CAP_CACHE_COHERENCY 0x1
> > #define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device
> > intrs */
> >
> > +/*
> > + * Following constraints are specifc to PAMUV1:
>=20
> FSL_PAMUV1
>=20
> > + * -aperture must be power of 2, and naturally aligned
> > + * -number of windows must be power of 2, and address space size
> > + * of each window is determined by aperture size / # of windows
> > + * -the actual size of the mapped region of a window must be power
> > + * of 2 starting with 4KB and physical address must be naturally
> > + * aligned.
> > + * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned
> > contraints.
> > + * The caller can invoke iommu_domain_get_attr to check if the
> > underlying
> > + * iommu implementation supports these constraints.
> > + */
> > +
> > enum iommu_attr {
> > DOMAIN_ATTR_GEOMETRY,
> > DOMAIN_ATTR_PAGING,
> > DOMAIN_ATTR_WINDOWS,
> > + DOMAIN_ATTR_PAMU_STASH,
> > + DOMAIN_ATTR_PAMU_ENABLE,
> > + DOMAIN_ATTR_FSL_PAMUV1,
> > DOMAIN_ATTR_MAX,
>=20
> Please be consistent on whether "PAMU" gets an "FSL_" namespace prefix
> (I'd prefer that it does).
Submitted new version(v14) of the patch with updated attribute names.
-Varun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox