RE: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of tiejun.chen Sent: Wednesday, May 08, 2013 4:54 AM To: Wood Scott-B07421 Cc: ag...@suse.de; kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest On 05/08/2013 07:40 AM, Scott Wood wrote: On 05/07/2013 06:06:30 AM, Tiejun Chen wrote: We also can direct ISI exception to Guest like DSI. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/kvm/booke_emulate.c |3 +++ arch/powerpc/kvm/e500mc.c|3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) Are you seeing a real performance improvement from this? This will interfere No. But after we reduce the exit to host, shouldn't this improve performance? We lose some flexibility for this so it make sense only if we gain measurable improvements. somewhat with using the VF bit, if we were to ever do so, since VF only affects Sorry, what is the VF you said? VF stands for virtualization fault see MAS8[VF] and we may use it for virtualized MMIO. The hypervisor should deny execute access on pages marked with VF. Accordingly in this case guest ISI exceptions should be handled by the hypervisor. -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
On 05/08/2013 05:20 PM, Caraman Mihai Claudiu-B02008 wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of tiejun.chen Sent: Wednesday, May 08, 2013 4:54 AM To: Wood Scott-B07421 Cc: ag...@suse.de; kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest On 05/08/2013 07:40 AM, Scott Wood wrote: On 05/07/2013 06:06:30 AM, Tiejun Chen wrote: We also can direct ISI exception to Guest like DSI. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/kvm/booke_emulate.c |3 +++ arch/powerpc/kvm/e500mc.c|3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) Are you seeing a real performance improvement from this? This will interfere No. But after we reduce the exit to host, shouldn't this improve performance? We lose some flexibility for this so it make sense only if we gain measurable improvements. Sounds we have much more works to do. somewhat with using the VF bit, if we were to ever do so, since VF only affects Sorry, what is the VF you said? VF stands for virtualization fault see MAS8[VF] and we may use it for virtualized I almost forget this point :) MMIO. The hypervisor should deny execute access on pages marked with VF. Accordingly in this case guest ISI exceptions should be handled by the hypervisor. Thanks for your information. Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix numa distance for form0 device tree
On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote: From: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com Commit 7122b7bc1757682049780179d7c216dd1c83 upstream. Thanks, I'm queuing it for the 3.5 kernel. Cheers, -- Luis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Anthony Foiani t...@scrye.com writes:
Maybe I need to call ata_set_sata_spd as well. Can I do that before
discovery, or should it be a part of the port_start callback? And
if the latter, shouldn't it be handled within the ata core, instead
of expecting each host driver to do that call?
My final version calls sata_set_spd from within the hard reset
callback for the fsl sata driver.
If there's a better place to put it, please let me know.
With this patch (and an appropriate entry in the device tree), the
machine comes up and reports:
# cd /sys/devices/e000.immr/e0019000.sata
# find * -name '*_spd*' -print | xargs grep .
ata2/link2/ata_link/link2/sata_spd:1.5 Gbps
ata2/link2/ata_link/link2/hw_sata_spd_limit:1.5 Gbps
ata2/link2/ata_link/link2/sata_spd_limit:1.5 Gbps
Which is what I needed to see.
Thanks for the hints!
Best regards,
Anthony Foiani
--
From 357c96b4f31b457eca0b96147c749c21d0f4f086 Mon Sep 17 00:00:00 2001
From: Anthony Foiani anthony.foi...@gmail.com
Date: Wed, 8 May 2013 05:24:20 -0600
Subject: [PATCH] sata: fsl: allow device tree to limit sata speed.
There used to be an orphan config symbol (CONFIG_MPC8315_DS) that
would artificially limit SATA speed to generation 1 (1.5Gbps).
Since that config symbol got lost whenever any sort of configuration
was done, we instead extract the limitation from the device tree,
using a new name sata-spd-limit.
Signed-off-by: Anthony Foiani anthony.foi...@gmail.com
---
.../devicetree/bindings/powerpc/fsl/board.txt | 23 ++
drivers/ata/sata_fsl.c | 28 +++---
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..9c9fed4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,26 @@ Example:
gpio-controller;
};
};
+
+* Maximum SATA Generation workaround
+
+Some boards advertise SATA speeds that they cannot actually achieve.
+Previously, this was dealt with via the orphaned config symbol
+CONFIG_MPC8315_DS. We now have a device tree property
+sata-spd-limit to control this. It should live within the sata
+block.
+
+Example:
+
+ sata@18000 {
+ compatible = fsl,mpc8315-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ cell-index = 1;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ sata-spd-limit = 1;
+ };
+
+By default, there is no limitation; if a value is given, it indicates
+the maximum generation that should be negotiated. Gen 1 is 1.5Gbps,
+Gen 2 is 3.0Gbps.
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..9e3f3ec 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -726,20 +726,6 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL));
VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA));
-#ifdef CONFIG_MPC8315_DS
- /*
-* Workaround for 8315DS board 3gbps link-up issue,
-* currently limit SATA port to GEN1 speed
-*/
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- temp = ~(0xF 4);
- temp |= (0x1 4);
- sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
-
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- dev_warn(dev, scr_control, speed limited to %x\n, temp);
-#endif
-
return 0;
}
@@ -836,6 +822,11 @@ try_offline_again:
*/
ata_msleep(ap, 1);
+ /* if the device tree forces a speed limit, set it here. */
+ ata_link_info(link, setting speed (in hard reset)\n);
+ DPRINTK(setting spd_limit\n);
+ sata_set_spd(link);
+
/*
* Now, bring the host controller online again, this can take time
* as PHY reset and communication establishment, 1st D2H FIS and
@@ -1444,6 +1435,15 @@ static int sata_fsl_probe(struct platform_device *ofdev)
goto error_exit_with_cleanup;
}
+ /* record speed limit if requested by device tree */
+ if (!of_property_read_u32(ofdev-dev.of_node, sata-spd-limit,
+ temp)) {
+ int i;
+ for (i = 0; i SATA_FSL_MAX_PORTS; ++i)
+ host-ports[i]-link.hw_sata_spd_limit = temp;
+ dev_warn(ofdev-dev, speed limit set to gen %u\n, temp);
+ }
+
/* host-iomap is not used currently */
host-private_data = host_priv;
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
This only disable soft interrupt for kvmppc_restart_interrupt() that restarts interrupts if they were meant for the host: a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL | BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL Those aren't the only exceptions that can end up going to the host. We could get a TLB miss that results in a heavyweight MMIO exit, etc. And shouldn't we handle kvmppc_restart_interrupt() like the original HOST flow? #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr, ack) \ START_EXCEPTION(label); \ NORMAL_EXCEPTION_PROLOG(trapnum, intnum, PROLOG_ADDITION_MASKABLE)\ EXCEPTION_COMMON(trapnum, PACA_EXGEN, *INTS_DISABLE*) \ ... Could you elaborate on what you mean? I think Tiejun was saying that host has flags and replays only EE/DEC/DBELL interrupts. There is special macro masked_interrupt_book3e in those exception handlers that sets paca-irq_happened. The list of replied interrupts is limited to asynchronous noncritical interrupts which can be masked by MSR[EE] (therefore no TLB miss). Now on KVM book3e we don't want to put them in the irq_happened lazy state but rather to execute them directly, so there is no reason for exception handling symmetry between host and guest. -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rapidio/tsi721: fix bug in MSI interrupt handling
Fix bug in MSI interrupt handling which causes loss of event notifications.
Typical indication of lost MSI interrupts are stalled message and doorbell
transfers between RapidIO endpoints. To avoid loss of MSI interrupts all
interrupts from the device must be disabled on entering the interrupt handler
routine and re-enabled when exiting it. Re-enabling device interrupts will
trigger new MSI message(s) if Tsi721 registered new events since entering
interrupt handler routine.
This patch is applicable to kernel versions starting from v3.2.
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Matt Porter mpor...@kernel.crashing.org
---
drivers/rapidio/devices/tsi721.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 6faba40..a8b2c23 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -471,6 +471,10 @@ static irqreturn_t tsi721_irqhandler(int irq, void *ptr)
u32 intval;
u32 ch_inte;
+ /* For MSI mode disable all device-level interrupts */
+ if (priv-flags TSI721_USING_MSI)
+ iowrite32(0, priv-regs + TSI721_DEV_INTE);
+
dev_int = ioread32(priv-regs + TSI721_DEV_INT);
if (!dev_int)
return IRQ_NONE;
@@ -560,6 +564,14 @@ static irqreturn_t tsi721_irqhandler(int irq, void *ptr)
}
}
#endif
+
+ /* For MSI mode re-enable device-level interrupts */
+ if (priv-flags TSI721_USING_MSI) {
+ dev_int = TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
+ TSI721_DEV_INT_SMSG_CH | TSI721_DEV_INT_BDMA_CH;
+ iowrite32(dev_int, priv-regs + TSI721_DEV_INTE);
+ }
+
return IRQ_HANDLED;
}
--
1.7.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5, part4 31/41] mm/ppc: prepare for removing num_physpages and simplify mem_init()
Prepare for removing num_physpages and simplify mem_init().
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/mm/mem.c | 56 +++--
1 file changed, 12 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index b890245..4e24f1c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -299,46 +299,27 @@ void __init paging_init(void)
void __init mem_init(void)
{
-#ifdef CONFIG_NEED_MULTIPLE_NODES
- int nid;
-#endif
- pg_data_t *pgdat;
- unsigned long i;
- struct page *page;
- unsigned long reservedpages = 0, codesize, initsize, datasize, bsssize;
-
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
- num_physpages = memblock_phys_mem_size() PAGE_SHIFT;
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
#ifdef CONFIG_NEED_MULTIPLE_NODES
-for_each_online_node(nid) {
- if (NODE_DATA(nid)-node_spanned_pages != 0) {
- printk(freeing bootmem node %d\n, nid);
- free_all_bootmem_node(NODE_DATA(nid));
- }
+ {
+ pg_data_t *pgdat;
+
+ for_each_online_pgdat(pgdat)
+ if (pgdat-node_spanned_pages != 0) {
+ printk(freeing bootmem node %d\n,
+ pgdat-node_id);
+ free_all_bootmem_node(pgdat);
+ }
}
#else
max_mapnr = max_pfn;
free_all_bootmem();
#endif
- for_each_online_pgdat(pgdat) {
- for (i = 0; i pgdat-node_spanned_pages; i++) {
- if (!pfn_valid(pgdat-node_start_pfn + i))
- continue;
- page = pgdat_page_nr(pgdat, i);
- if (PageReserved(page))
- reservedpages++;
- }
- }
-
- codesize = (unsigned long)_sdata - (unsigned long)_stext;
- datasize = (unsigned long)_edata - (unsigned long)_sdata;
- initsize = (unsigned long)__init_end - (unsigned long)__init_begin;
- bsssize = (unsigned long)__bss_stop - (unsigned long)__bss_start;
#ifdef CONFIG_HIGHMEM
{
@@ -348,13 +329,9 @@ void __init mem_init(void)
for (pfn = highmem_mapnr; pfn max_mapnr; ++pfn) {
phys_addr_t paddr = (phys_addr_t)pfn PAGE_SHIFT;
struct page *page = pfn_to_page(pfn);
- if (memblock_is_reserved(paddr))
- continue;
- free_highmem_page(page);
- reservedpages--;
+ if (!memblock_is_reserved(paddr))
+ free_highmem_page(page);
}
- printk(KERN_DEBUG High memory: %luk\n,
- totalhigh_pages (PAGE_SHIFT-10));
}
#endif /* CONFIG_HIGHMEM */
@@ -367,16 +344,7 @@ void __init mem_init(void)
(mfspr(SPRN_TLB1CFG) TLBnCFG_N_ENTRY) - 1;
#endif
- printk(KERN_INFO Memory: %luk/%luk available (%luk kernel code,
- %luk reserved, %luk data, %luk bss, %luk init)\n,
- nr_free_pages() (PAGE_SHIFT-10),
- num_physpages (PAGE_SHIFT-10),
- codesize 10,
- reservedpages (PAGE_SHIFT-10),
- datasize 10,
- bsssize 10,
- initsize 10);
-
+ mem_init_print_info(NULL);
#ifdef CONFIG_PPC32
pr_info(Kernel virtual memory layout:\n);
pr_info( * 0x%08lx..0x%08lx : fixmap\n, FIXADDR_START, FIXADDR_TOP);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Invalid perf_branch_entry.to entries question
On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote: Peter Stephane, We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into struct perf_branch_entry. Sometimes on POWER8 we may not be able to fill out the to address. Just because I'm curious.. however does that happen? Surely the CPU knows where next to fetch instructions? We initially thought of just making this 0, but it's feasible that this could be a valid address to branch to. Right, while highly unlikely, x86 actually has some cases where 0 address is valid *shudder*.. The other logical value to indicate an invalid entry would be all 1s which is not possible (on POWER at least). Do you guys have a preference as to what we should use as an invalid entry? This would have some consequences for the userspace tool also. The alternative would be to add a flag alongside mispred/predicted to indicate the validity of the to address. Either would work with me I suppose.. Stephane do you have any preference? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
On 05/07/2013 08:53:50 PM, tiejun.chen wrote: On 05/08/2013 07:40 AM, Scott Wood wrote: On 05/07/2013 06:06:30 AM, Tiejun Chen wrote: We also can direct ISI exception to Guest like DSI. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- arch/powerpc/kvm/booke_emulate.c |3 +++ arch/powerpc/kvm/e500mc.c|3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) Are you seeing a real performance improvement from this? This will interfere No. But after we reduce the exit to host, shouldn't this improve performance? Not if ISIs are too rare to matter. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Invalid perf_branch_entry.to entries question
On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote: Peter Stephane, We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into struct perf_branch_entry. Sometimes on POWER8 we may not be able to fill out the to address. Just because I'm curious.. however does that happen? Surely the CPU knows where next to fetch instructions? We initially thought of just making this 0, but it's feasible that this could be a valid address to branch to. Right, while highly unlikely, x86 actually has some cases where 0 address is valid *shudder*.. The other logical value to indicate an invalid entry would be all 1s which is not possible (on POWER at least). Do you guys have a preference as to what we should use as an invalid entry? This would have some consequences for the userspace tool also. The alternative would be to add a flag alongside mispred/predicted to indicate the validity of the to address. Either would work with me I suppose.. Stephane do you have any preference? But if the 'to' is bogus, why not just drop the sample? That happens on x86 if the HW captured branches which do not correspond to user filter settings (due to bug). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Invalid perf_branch_entry.to entries question
Peter Zijlstra pet...@infradead.org wrote: On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote: Peter Stephane, We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into struct perf_branch_entry. Sometimes on POWER8 we may not be able to fill out the to address. Just because I'm curious.. however does that happen? Surely the CPU knows where next to fetch instructions? For computed gotos (ie. branch to a register value), the hardware gives you the from and to address in the branch history buffer. For branches where the branch target address is an immediate encoded in the instruction, the hardware only logs the from address. It assumes that software (perf irq handler in this case) can read this branch instruction, calculate the corresponding offset and hence the to/target address. It's entirely possible that when the perf IRQ handler happens, the instruction in question is not readable or is no longer a branch (self modifying code). Hence we aren't able to calculate a valid to address. Mikey We initially thought of just making this 0, but it's feasible that this could be a valid address to branch to. Right, while highly unlikely, x86 actually has some cases where 0 address is valid *shudder*.. The other logical value to indicate an invalid entry would be all 1s which is not possible (on POWER at least). Do you guys have a preference as to what we should use as an invalid entry? This would have some consequences for the userspace tool also. The alternative would be to add a flag alongside mispred/predicted to indicate the validity of the to address. Either would work with me I suppose.. Stephane do you have any preference? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Invalid perf_branch_entry.to entries question
Stephane Eranian eran...@google.com wrote: On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote: Peter Stephane, We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into struct perf_branch_entry. Sometimes on POWER8 we may not be able to fill out the to address. Just because I'm curious.. however does that happen? Surely the CPU knows where next to fetch instructions? We initially thought of just making this 0, but it's feasible that this could be a valid address to branch to. Right, while highly unlikely, x86 actually has some cases where 0 address is valid *shudder*.. The other logical value to indicate an invalid entry would be all 1s which is not possible (on POWER at least). Do you guys have a preference as to what we should use as an invalid entry? This would have some consequences for the userspace tool also. The alternative would be to add a flag alongside mispred/predicted to indicate the validity of the to address. Either would work with me I suppose.. Stephane do you have any preference? But if the 'to' is bogus, why not just drop the sample? That happens on x86 if the HW captured branches which do not correspond to user filter settings (due to bug). We can I guess but it seems useful to log the from address when possible. Can we log it and userspace tools can ignore it if it's not useful? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Invalid perf_branch_entry.to entries question
On Thu, 2013-05-09 at 08:45 +1000, Michael Neuling wrote: Stephane Eranian eran...@google.com wrote: On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote: Peter Stephane, We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into struct perf_branch_entry. Sometimes on POWER8 we may not be able to fill out the to address. Just because I'm curious.. however does that happen? Surely the CPU knows where next to fetch instructions? We initially thought of just making this 0, but it's feasible that this could be a valid address to branch to. Right, while highly unlikely, x86 actually has some cases where 0 address is valid *shudder*.. The other logical value to indicate an invalid entry would be all 1s which is not possible (on POWER at least). Do you guys have a preference as to what we should use as an invalid entry? This would have some consequences for the userspace tool also. The alternative would be to add a flag alongside mispred/predicted to indicate the validity of the to address. Either would work with me I suppose.. Stephane do you have any preference? But if the 'to' is bogus, why not just drop the sample? That happens on x86 if the HW captured branches which do not correspond to user filter settings (due to bug). We can I guess but it seems useful to log the from address when possible. Yeah I think it is useful. Knowing that you were there, but the to address is invalid, is better than wondering why you never hit the code at all. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix numa distance for form0 device tree
On Wed, 2013-05-08 at 11:29 +0100, Luis Henriques wrote: On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote: From: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com Commit 7122b7bc1757682049780179d7c216dd1c83 upstream. Thanks, I'm queuing it for the 3.5 kernel. Thanks, I didn't know you guys were maintaining a 3.5 stable branch. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Update currituck pci/usb fixup for new board revision
The currituck board uses a different IRQ for the pci usb host
controller depending on the board revision. This patch adds support
for newer board revisions by retrieving the board revision from the
FPGA and mapping the appropriate IRQ.
Signed-off-by: Alistair Popple alist...@popple.id.au
---
arch/powerpc/boot/dts/currituck.dts|5
arch/powerpc/platforms/44x/currituck.c | 39 ++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/currituck.dts
b/arch/powerpc/boot/dts/currituck.dts
index b801dd0..cd3247e 100644
--- a/arch/powerpc/boot/dts/currituck.dts
+++ b/arch/powerpc/boot/dts/currituck.dts
@@ -103,6 +103,11 @@
interrupts = 34 2;
};
+ FPGA0: fpga@5000 {
+ compatible = ibm,currituck-fpga;
+ reg = 0x5000 0x1;
+ };
+
IIC0: i2c@ {
compatible = ibm,iic-currituck, ibm,iic;
reg = 0x0 0x0014;
diff --git a/arch/powerpc/platforms/44x/currituck.c
b/arch/powerpc/platforms/44x/currituck.c
index ecd3890..c52e1b3 100644
--- a/arch/powerpc/platforms/44x/currituck.c
+++ b/arch/powerpc/platforms/44x/currituck.c
@@ -176,13 +176,48 @@ static int __init ppc47x_probe(void)
return 1;
}
+static int board_rev = -1;
+static int __init ppc47x_get_board_rev(void)
+{
+ u8 fpga_reg0;
+ void *fpga;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ibm,currituck-fpga);
+ if (!np)
+ goto fail;
+
+ fpga = of_iomap(np, 0);
+ of_node_put(np);
+ if (!fpga)
+ goto fail;
+
+ fpga_reg0 = ioread8(fpga);
+ board_rev = fpga_reg0 0x03;
+ pr_info(%s: Found board revision %d\n, __func__, board_rev);
+ iounmap(fpga);
+ return 0;
+
+fail:
+ pr_info(%s: Unable to find board revision\n, __func__);
+ return 0;
+}
+machine_arch_initcall(ppc47x, ppc47x_get_board_rev);
+
/* Use USB controller should have been hardware swizzled but it wasn't :( */
static void ppc47x_pci_irq_fixup(struct pci_dev *dev)
{
if (dev-vendor == 0x1033 (dev-device == 0x0035 ||
dev-device == 0x00e0)) {
- dev-irq = irq_create_mapping(NULL, 47);
- pr_info(%s: Mapping irq 47 %d\n, __func__, dev-irq);
+ if (board_rev == 0) {
+ dev-irq = irq_create_mapping(NULL, 47);
+ pr_info(%s: Mapping irq %d\n, __func__, dev-irq);
+ } else if (board_rev == 2) {
+ dev-irq = irq_create_mapping(NULL, 49);
+ pr_info(%s: Mapping irq %d\n, __func__, dev-irq);
+ } else {
+ pr_alert(%s: Unknown board revision\n, __func__);
+ }
}
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update currituck pci/usb fixup for new board revision
The currituck board uses a different IRQ for the pci usb host
controller depending on the board revision. This patch adds support
for newer board revisions by retrieving the board revision from the
FPGA and mapping the appropriate IRQ.
Signed-off-by: Alistair Popple alist...@popple.id.au
---
Sorry - I had forgotten to commit a minor fix to the device tree
changes in the last patch. Corrected patch below.
arch/powerpc/boot/dts/currituck.dts|5
arch/powerpc/platforms/44x/currituck.c | 39 ++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/currituck.dts
b/arch/powerpc/boot/dts/currituck.dts
index b801dd0..d2c8a87 100644
--- a/arch/powerpc/boot/dts/currituck.dts
+++ b/arch/powerpc/boot/dts/currituck.dts
@@ -103,6 +103,11 @@
interrupts = 34 2;
};
+ FPGA0: fpga@5000 {
+ compatible = ibm,currituck-fpga;
+ reg = 0x5000 0x4;
+ };
+
IIC0: i2c@ {
compatible = ibm,iic-currituck, ibm,iic;
reg = 0x0 0x0014;
diff --git a/arch/powerpc/platforms/44x/currituck.c
b/arch/powerpc/platforms/44x/currituck.c
index ecd3890..c52e1b3 100644
--- a/arch/powerpc/platforms/44x/currituck.c
+++ b/arch/powerpc/platforms/44x/currituck.c
@@ -176,13 +176,48 @@ static int __init ppc47x_probe(void)
return 1;
}
+static int board_rev = -1;
+static int __init ppc47x_get_board_rev(void)
+{
+ u8 fpga_reg0;
+ void *fpga;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ibm,currituck-fpga);
+ if (!np)
+ goto fail;
+
+ fpga = of_iomap(np, 0);
+ of_node_put(np);
+ if (!fpga)
+ goto fail;
+
+ fpga_reg0 = ioread8(fpga);
+ board_rev = fpga_reg0 0x03;
+ pr_info(%s: Found board revision %d\n, __func__, board_rev);
+ iounmap(fpga);
+ return 0;
+
+fail:
+ pr_info(%s: Unable to find board revision\n, __func__);
+ return 0;
+}
+machine_arch_initcall(ppc47x, ppc47x_get_board_rev);
+
/* Use USB controller should have been hardware swizzled but it wasn't :( */
static void ppc47x_pci_irq_fixup(struct pci_dev *dev)
{
if (dev-vendor == 0x1033 (dev-device == 0x0035 ||
dev-device == 0x00e0)) {
- dev-irq = irq_create_mapping(NULL, 47);
- pr_info(%s: Mapping irq 47 %d\n, __func__, dev-irq);
+ if (board_rev == 0) {
+ dev-irq = irq_create_mapping(NULL, 47);
+ pr_info(%s: Mapping irq %d\n, __func__, dev-irq);
+ } else if (board_rev == 2) {
+ dev-irq = irq_create_mapping(NULL, 49);
+ pr_info(%s: Mapping irq %d\n, __func__, dev-irq);
+ } else {
+ pr_alert(%s: Unknown board revision\n, __func__);
+ }
}
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/pmu: Fix order of interpreting BHRB target entries
The current Branch History Rolling Buffer (BHRB) code misinterprets the order
of entries in the hardware buffer. It assumes that a branch target address
will be read _after_ its corresponding branch. In reality the branch target
comes before (lower mfbhrb entry) it's corresponding branch.
This is a rewrite of the code to take this into account.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/perf/core-book3s.c | 86 ---
1 file changed, 45 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index c627843..2d81372 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1463,66 +1463,70 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
u64 val;
u64 addr;
- int r_index, u_index, target, pred;
+ int r_index, u_index, 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) {
+ val = read_bhrb(r_index++);
+ if (!val)
+ /* Terminal marker: End of valid BHRB entries */
break;
- } else {
- /* BHRB field break up */
+ else {
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++;
+ if (!addr)
+ /* invalid entry */
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;
- }
+ /* Branches are read most recent first (ie. mfbhrb 0 is
+* the most recent branch).
+* There are two types of valid entries:
+* 1) a target entry which is the to address of a
+*computed goto like a blr,bctr,btar. The next
+*entry read from the bhrb will be branch
+*corresponding to this target (ie. the actual
+*blr/bctr/btar instruction).
+* 2) a from address which is an actual branch. If a
+*target entry proceeds this, then this is the
+*matching branch for that target. If this is not
+*following a target entry, then this is a branch
+*where the target is given as an immediate field
+*in the instruction (ie. an i or b form branch).
+*In this case we need to read the instruction from
+*memory to determine the target/to address.
+*/
- /* 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;
+ /* Target branches use two entries
+* (ie. computed gotos/XL form)
+*/
+ cpuhw-bhrb_entries[u_index].to = addr;
+ cpuhw-bhrb_entries[u_index].mispred = pred;
+ cpuhw-bhrb_entries[u_index].predicted = ~pred;
- /* Dont increment u_index */
- r_index++;
+ /* Get from address in next entry */
+ val = read_bhrb(r_index++);
+
[PATCH 2/2] powerpc/perf: Fix setting of to addresses for BHRB
Currently we only set the to address in the branch stack when the CPU
explicitly gives us a value. Unfortunately it only does this for XL form
branches (eg blr, bctr, bctar) and not I and B form branches (eg b, bc).
Fortunately if we read the instruction from memory we can extract the offset of
a branch and calculate the target address.
This adds a function power_pmu_bhrb_to() to calculate the target/to address of
the corresponding I and B form branches. It handles branches in both user and
kernel spaces. It also plumbs this into the perf brhb reading code.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/perf/core-book3s.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 2d81372..37f652f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -13,11 +13,13 @@
#include linux/perf_event.h
#include linux/percpu.h
#include linux/hardirq.h
+#include linux/uaccess.h
#include asm/reg.h
#include asm/pmc.h
#include asm/machdep.h
#include asm/firmware.h
#include asm/ptrace.h
+#include asm/code-patching.h
#define BHRB_MAX_ENTRIES 32
#define BHRB_TARGET0x0002
@@ -1458,6 +1460,33 @@ struct pmu power_pmu = {
.flush_branch_stack = power_pmu_flush_branch_stack,
};
+/* Calculate the to address for a branch */
+static __u64 power_pmu_bhrb_to(u64 addr)
+{
+ unsigned int instr;
+ int ret;
+ __u64 target;
+
+ if (is_kernel_addr(addr))
+ return branch_target((unsigned int *)addr);
+
+ /* Userspace: need copy instruction here then translate it */
+ pagefault_disable();
+ ret = __get_user_inatomic(instr, (unsigned int *)addr);
+ if (ret) {
+ pagefault_enable();
+ return 0;
+ }
+ pagefault_enable();
+
+ target = branch_target(instr);
+ if ((!target) || (instr BRANCH_ABSOLUTE))
+ return target;
+
+ /* Translate relative branch target from kernel to user address */
+ return target - (unsigned long)instr + addr;
+}
+
/* Processing BHRB entries */
void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
@@ -1521,7 +1550,8 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
/* Branches to immediate field
(ie I or B form) */
cpuhw-bhrb_entries[u_index].from = addr;
- cpuhw-bhrb_entries[u_index].to = 0;
+ cpuhw-bhrb_entries[u_index].to =
+ power_pmu_bhrb_to(addr);
cpuhw-bhrb_entries[u_index].mispred = pred;
cpuhw-bhrb_entries[u_index].predicted = ~pred;
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
