Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Sat, May 18, 2013 at 12:14 AM, Michael Neuling wrote: > Stephane Eranian wrote: > >> On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra wrote: >> > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote: >> >> Peter Zijlstra wrote: >> > >> >> > Wouldn't it be mostly conditional branches that are the primary control >> >> > flow >> >> > and can get predicted wrong? I mean, I'm sure someone will miss-predict >> >> > an >> >> > unconditional branch but its not like we care about people with such >> >> > afflictions do we? >> >> >> >> You could mispredict the target address of a computed goto. You'd know >> >> it was taken but not know target address until later in the pipeline. >> > >> > Oh right, computed targets could indeed be mis predicted. I was more >> > thinking >> > about jumps with immediate values. >> > >> >> On this, the POWER8 branch history buffer tells us two things about the >> >> prediction status. >> >> 1) if the branch was predicted taken/not taken correctly >> >> 2) if the target address was predicted correctly or not (for computed >> >> gotos only) >> >> So we'd actually like more prediction bits too :-D >> > >> > So if I understand this right, 1) maps to the predicted flags we have; 2) >> > would be new stuff? >> > >> > We don't really have anything like that on x86, but I suppose if you make >> > the >> > thing optional and present a 'useful' use-case implemented in userspace >> > code >> > we could take it :-) >> > >> >> > Anyway, since PPC people thought it worth baking into hardware, >> >> > presumably they have a compelling use case. Mikey could you see if you >> >> > can retrieve that from someone in the know? It might be interesting. >> >> >> >> I don't think we can mispredict a non-conditional non-computed but I'll >> >> have to check with the HW folks. >> > >> > I was mostly wondering about the use-case for the conditional filter. >> > Stephane >> > didn't think it useful, clearly your hardware guys thought different :-) >> >> From my experience talking with compiler people, they care about ALL >> the branches and not the conditional so much. They use LBR to do basic >> block profiling. > > OK. I don't have a good handle on what's useful for compilers or JITs > right now. I'm just plumbing through what's possible. > I understand. It is okay to extend the interface. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
Stephane Eranian wrote: > On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra wrote: > > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote: > >> Peter Zijlstra wrote: > > > >> > Wouldn't it be mostly conditional branches that are the primary control > >> > flow > >> > and can get predicted wrong? I mean, I'm sure someone will miss-predict > >> > an > >> > unconditional branch but its not like we care about people with such > >> > afflictions do we? > >> > >> You could mispredict the target address of a computed goto. You'd know > >> it was taken but not know target address until later in the pipeline. > > > > Oh right, computed targets could indeed be mis predicted. I was more > > thinking > > about jumps with immediate values. > > > >> On this, the POWER8 branch history buffer tells us two things about the > >> prediction status. > >> 1) if the branch was predicted taken/not taken correctly > >> 2) if the target address was predicted correctly or not (for computed > >> gotos only) > >> So we'd actually like more prediction bits too :-D > > > > So if I understand this right, 1) maps to the predicted flags we have; 2) > > would be new stuff? > > > > We don't really have anything like that on x86, but I suppose if you make > > the > > thing optional and present a 'useful' use-case implemented in userspace code > > we could take it :-) > > > >> > Anyway, since PPC people thought it worth baking into hardware, > >> > presumably they have a compelling use case. Mikey could you see if you > >> > can retrieve that from someone in the know? It might be interesting. > >> > >> I don't think we can mispredict a non-conditional non-computed but I'll > >> have to check with the HW folks. > > > > I was mostly wondering about the use-case for the conditional filter. > > Stephane > > didn't think it useful, clearly your hardware guys thought different :-) > > From my experience talking with compiler people, they care about ALL > the branches and not the conditional so much. They use LBR to do basic > block profiling. OK. I don't have a good handle on what's useful for compilers or JITs right now. I'm just plumbing through what's possible. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra wrote: > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote: >> Peter Zijlstra wrote: > >> > Wouldn't it be mostly conditional branches that are the primary control >> > flow >> > and can get predicted wrong? I mean, I'm sure someone will miss-predict an >> > unconditional branch but its not like we care about people with such >> > afflictions do we? >> >> You could mispredict the target address of a computed goto. You'd know >> it was taken but not know target address until later in the pipeline. > > Oh right, computed targets could indeed be mis predicted. I was more thinking > about jumps with immediate values. > >> On this, the POWER8 branch history buffer tells us two things about the >> prediction status. >> 1) if the branch was predicted taken/not taken correctly >> 2) if the target address was predicted correctly or not (for computed >> gotos only) >> So we'd actually like more prediction bits too :-D > > So if I understand this right, 1) maps to the predicted flags we have; 2) > would be new stuff? > > We don't really have anything like that on x86, but I suppose if you make the > thing optional and present a 'useful' use-case implemented in userspace code > we could take it :-) > >> > Anyway, since PPC people thought it worth baking into hardware, >> > presumably they have a compelling use case. Mikey could you see if you >> > can retrieve that from someone in the know? It might be interesting. >> >> I don't think we can mispredict a non-conditional non-computed but I'll >> have to check with the HW folks. > > I was mostly wondering about the use-case for the conditional filter. Stephane > didn't think it useful, clearly your hardware guys thought different :-) >From my experience talking with compiler people, they care about ALL the branches and not the conditional so much. They use LBR to do basic block profiling. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
On Thu, May 9, 2013 at 12:36 PM, Denis Efremov wrote:
> EXPORT_SYMBOL and inline directives are contradictory to each other.
> The patch fixes this inconsistency.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Denis Efremov
> ---
> arch/powerpc/platforms/ps3/spu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/ps3/spu.c
> b/arch/powerpc/platforms/ps3/spu.c
> index e17fa14..a0bca05 100644
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -143,7 +143,7 @@ static void _dump_areas(unsigned int spe_id, unsigned
> long priv2,
> pr_debug("%s:%d: shadow: %lxh\n", func, line, shadow);
> }
>
> -inline u64 ps3_get_spe_id(void *arg)
> +u64 ps3_get_spe_id(void *arg)
> {
> return spu_pdata(arg)->spe_id;
> }
FYI, this symbol is not used in mainline.
IIRC, it's used for profiling only. Any chance the profile code will
ever make it
in mainline?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()
Hello!
Just wanted to remind you: The patchto fix cbe_init_pm_irq() that Michael and
Grant sent me is still not included in Linux 3.8.12.
--Dennis
Am Dienstag, 23. April 2013, 22:14:51 schrieb Michael Ellerman:
> None of the cell platforms support CPU hotplug, so we should iterate
> only over online nodes when setting PMU interrupts.
>
> This also fixes a warning during boot when NODES_SHIFT is large enough:
>
> WARNING: at /scratch/michael/src/kmk/linus/kernel/irq/irqdomain.c:766
> ...
> NIP [c00db278] .irq_linear_revmap+0x30/0x58
> LR [c00dc2a0] .irq_create_mapping+0x38/0x1a8
> Call Trace:
> [c003fc9c3af0] [c00dc2a0] .irq_create_mapping+0x38/0x1a8
> (unreliable) [c003fc9c3b80] [c0655c1c]
> .__machine_initcall_cell_cbe_init_pm_irq+0x84/0x158 [c003fc9c3c20]
> [c000afb4] .do_one_initcall+0x5c/0x1e0
> [c003fc9c3cd0] [c0644580] .kernel_init_freeable+0x238/0x328
> [c003fc9c3db0] [c000b784] .kernel_init+0x1c/0x120
> [c003fc9c3e30] [c0009fb8] .ret_from_kernel_thread+0x64/0xac
>
> This is caused by us overflowing our linear revmap because we're
> requesting too many interrupts.
>
> Reported-by: Dennis Schridde
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/platforms/cell/pmu.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/cell/pmu.c
> b/arch/powerpc/platforms/cell/pmu.c index 59c1a16..348a27b 100644
> --- a/arch/powerpc/platforms/cell/pmu.c
> +++ b/arch/powerpc/platforms/cell/pmu.c
> @@ -382,7 +382,7 @@ static int __init cbe_init_pm_irq(void)
> unsigned int irq;
> int rc, node;
>
> - for_each_node(node) {
> + for_each_online_node(node) {
> irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
> (node << IIC_IRQ_NODE_SHIFT));
> if (irq == NO_IRQ) {
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
Hello! Am Dienstag, 23. April 2013, 19:12:47 schrieb Michael Ellerman: > For me it is fixed by applying the following patch, it should be in v3.10: > > http://patchwork.ozlabs.org/patch/230103/ Can you please also backport this to 3.8? It is still missing in 3.8.12. The patch for cbe_init_pm_irq() was included - Thanks! --Dennis signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote: > Peter Zijlstra wrote: > > Wouldn't it be mostly conditional branches that are the primary control flow > > and can get predicted wrong? I mean, I'm sure someone will miss-predict an > > unconditional branch but its not like we care about people with such > > afflictions do we? > > You could mispredict the target address of a computed goto. You'd know > it was taken but not know target address until later in the pipeline. Oh right, computed targets could indeed be mis predicted. I was more thinking about jumps with immediate values. > On this, the POWER8 branch history buffer tells us two things about the > prediction status. > 1) if the branch was predicted taken/not taken correctly > 2) if the target address was predicted correctly or not (for computed > gotos only) > So we'd actually like more prediction bits too :-D So if I understand this right, 1) maps to the predicted flags we have; 2) would be new stuff? We don't really have anything like that on x86, but I suppose if you make the thing optional and present a 'useful' use-case implemented in userspace code we could take it :-) > > Anyway, since PPC people thought it worth baking into hardware, > > presumably they have a compelling use case. Mikey could you see if you > > can retrieve that from someone in the know? It might be interesting. > > I don't think we can mispredict a non-conditional non-computed but I'll > have to check with the HW folks. I was mostly wondering about the use-case for the conditional filter. Stephane didn't think it useful, clearly your hardware guys thought different :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
Peter Zijlstra wrote: > On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote: > > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra > > wrote: > > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote: > > >> Peter, > > >> > > >> BTW PowerPC also has the ability to filter on conditional branches. Any > > >> chance we could add something like the follow to perf also? > > >> > > > > > > I don't see an immediate problem with that except that we on x86 need to > > > implement that in the software filter. Stephane do you see any > > > fundamental issue with that? > > > > > On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it > > would > > have to be done in SW. I did not add that because I think those branches are > > not necessarily useful for tools. > > Wouldn't it be mostly conditional branches that are the primary control flow > and can get predicted wrong? I mean, I'm sure someone will miss-predict an > unconditional branch but its not like we care about people with such > afflictions do we? You could mispredict the target address of a computed goto. You'd know it was taken but not know target address until later in the pipeline. On this, the POWER8 branch history buffer tells us two things about the prediction status. 1) if the branch was predicted taken/not taken correctly 2) if the target address was predicted correctly or not (for computed gotos only) So we'd actually like more prediction bits too :-D > Anyway, since PPC people thought it worth baking into hardware, > presumably they have a compelling use case. Mikey could you see if you > can retrieve that from someone in the know? It might be interesting. I don't think we can mispredict a non-conditional non-computed but I'll have to check with the HW folks. Mikey > > Also, it looks like its trivial to add to x86, you seem to have already done > all the hard work by having X86_BR_JCC. > > The only missing piece would be: > > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c > @@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter > > if (br_type & PERF_SAMPLE_BRANCH_IND_CALL) > mask |= X86_BR_IND_CALL; > + > + if (br_type & PERF_SAMPLE_BRANCH_CONDITIONAL) > + mask |= X86_BR_JCC; > + > /* >* stash actual user request into reg, it may >* be used by fixup code for some CPU > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote: > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra wrote: > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote: > >> Peter, > >> > >> BTW PowerPC also has the ability to filter on conditional branches. Any > >> chance we could add something like the follow to perf also? > >> > > > > I don't see an immediate problem with that except that we on x86 need to > > implement that in the software filter. Stephane do you see any > > fundamental issue with that? > > > On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it > would > have to be done in SW. I did not add that because I think those branches are > not necessarily useful for tools. Wouldn't it be mostly conditional branches that are the primary control flow and can get predicted wrong? I mean, I'm sure someone will miss-predict an unconditional branch but its not like we care about people with such afflictions do we? Anyway, since PPC people thought it worth baking into hardware, presumably they have a compelling use case. Mikey could you see if you can retrieve that from someone in the know? It might be interesting. Also, it looks like its trivial to add to x86, you seem to have already done all the hard work by having X86_BR_JCC. The only missing piece would be: --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c @@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter if (br_type & PERF_SAMPLE_BRANCH_IND_CALL) mask |= X86_BR_IND_CALL; + + if (br_type & PERF_SAMPLE_BRANCH_CONDITIONAL) + mask |= X86_BR_JCC; + /* * stash actual user request into reg, it may * be used by fixup code for some CPU ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
> and allowing compilation unconditionally on all arm and powerpc platforms.
>
> This brings a bigger compile time coverage and removes the following
> dependency
> warning found by Arnd Bergmann:
>
> warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
> IMX_HAVE_PLATFORM_FLEXCAN &&
> SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
> which has unmet direct dependencies (NET && CAN && CAN_DEV)
>
> Cc: Arnd Bergmann
> Cc: Shawn Guo
Acked-by: Shawn Guo
> Cc: Sascha Hauer
> Cc: Kumar Gala
> Cc: U Bhaskar-B22300
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Marc Kleine-Budde
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
and allowing compilation unconditionally on all arm and powerpc platforms.
This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:
warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN
&&
SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET && CAN && CAN_DEV)
Cc: Arnd Bergmann
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Kumar Gala
Cc: U Bhaskar-B22300
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde
---
Changes since v1:
- don't remove IMX_HAVE_PLATFORM_FLEXCAN, which breaks non DT imx platforms
tnx Shawn
arch/arm/mach-imx/Kconfig | 4
arch/arm/mach-imx/devices/Kconfig | 1 -
arch/arm/mach-mxs/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
drivers/net/can/Kconfig | 5 +
5 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..af8e109 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -111,7 +111,6 @@ config SOC_IMX25
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select MXC_AVIC
config SOC_IMX27
@@ -137,7 +136,6 @@ config SOC_IMX35
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_V6K
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_EPIT
select MXC_AVIC
select SMP_ON_UP if SMP
@@ -776,7 +774,6 @@ comment "Device tree only"
config SOC_IMX53
bool "i.MX53 support"
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_SRC
select IMX_HAVE_PLATFORM_IMX2_WDT
select PINCTRL
@@ -799,7 +796,6 @@ config SOC_IMX6Q
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if LOCAL_TIMERS
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
diff --git a/arch/arm/mach-imx/devices/Kconfig
b/arch/arm/mach-imx/devices/Kconfig
index 3dd2b1b..68c74fb 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -4,7 +4,6 @@ config IMX_HAVE_PLATFORM_FEC
config IMX_HAVE_PLATFORM_FLEXCAN
bool
- select HAVE_CAN_FLEXCAN if CAN
config IMX_HAVE_PLATFORM_FSL_USB2_UDC
bool
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 4dc2fbb..ce6e7d6 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -11,7 +11,6 @@ config SOC_IMX28
select ARM_AMBA
select ARM_CPU_SUSPEND if PM
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_PWM
select PINCTRL_IMX28
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..7754c6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -674,7 +674,6 @@ config SBUS
config FSL_SOC
bool
- select HAVE_CAN_FLEXCAN if NET && CAN
config FSL_PCI
bool
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3c06947 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -102,12 +102,9 @@ config CAN_JANZ_ICAN3
This driver can also be built as a module. If so, the module will be
called janz-ican3.ko.
-config HAVE_CAN_FLEXCAN
- bool
-
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on HAVE_CAN_FLEXCAN
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
--
1.8.2.rc2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] can: flexcan: allow compilation on arm and powerpc
On 05/17/2013 04:03 AM, Shawn Guo wrote:
> Hi Marc,
>
> On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
>> This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
>> IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
>> all arm and powerpc platforms.
>
> I'm generally fine with the approach. But with Kconfig symbol
> IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
> platform-flexcan.o work?
>
> arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) +=
> platform-flexcan.o
Doh! - I've removed too much, will change.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: split hugepage when using subpage protection
"Aneesh Kumar K.V" writes:
> From: "Aneesh Kumar K.V"
>
> We find all the overlapping vma and mark them such that we don't allocate
> hugepage in that range. Also we split existing huge page so that the
> normal page hash can be invalidated and new page faulted in with new
> protection bits.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/mm/subpage-prot.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
> index 7c415dd..33fd329 100644
> --- a/arch/powerpc/mm/subpage-prot.c
> +++ b/arch/powerpc/mm/subpage-prot.c
> @@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr,
> unsigned long len)
> up_write(&mm->mmap_sem);
> }
>
> +static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
> + unsigned long end, struct mm_walk *walk)
> +{
> + struct vm_area_struct *vma = walk->private;
> + split_huge_page_pmd(vma, addr, pmd);
> + return 0;
> +}
> +
> /*
> * Copy in a subpage protection map for an address range.
> * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
> @@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long
> len, u32 __user *map)
> size_t nw;
> unsigned long next, limit;
> int err;
> + struct vm_area_struct *vma;
> +
> + struct mm_walk subpage_proto_walk = {
> + .mm = mm,
> + .pmd_entry = subpage_walk_pmd_entry,
> + };
>
> /* Check parameters */
> if ((addr & ~PAGE_MASK) || (len & ~PAGE_MASK) ||
> @@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long
> len, u32 __user *map)
> return -EFAULT;
>
> down_write(&mm->mmap_sem);
> +
> + /*
> + * We don't try too hard, we just mark all the vma in that range
> + * VM_NOHUGEPAGE and split them.
> + */
> + for (vma = find_vma(mm, addr);
> + (vma && vma->vm_end < (addr + len)); vma = vma->vm_next) {
should be, Missed commit -amend
(vma && vma->vm_start < (addr + len)); vma = vma->vm_next) {
> + vma->vm_flags |= VM_NOHUGEPAGE;
> + subpage_proto_walk.private = vma;
> + walk_page_range(vma->vm_start, vma->vm_end,
> + &subpage_proto_walk);
> + }
> for (limit = addr + len; addr < limit; addr = next) {
> next = pmd_addr_end(addr, limit);
> err = -ENOMEM;
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: use smp_rmb when looking at deposisted pgtable to store hash index
From: "Aneesh Kumar K.V"
We need to use smb_rmb when looking at hpte slot array. Otherwise we could
reorder the hpte_slot array load bfore even we marked the pmd trans huge.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable-ppc64.h | 15 +++
arch/powerpc/mm/hugepage-hash64.c| 6 +-
arch/powerpc/mm/pgtable_64.c | 6 +-
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d046289..46db094 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -10,6 +10,7 @@
#else
#include
#endif
+#include
#define FIRST_USER_ADDRESS 0
@@ -393,6 +394,20 @@ static inline void mark_hpte_slot_valid(unsigned char
*hpte_slot_array,
hpte_slot_array[index] = hidx << 4 | 0x1 << 3;
}
+static inline char *get_hpte_slot_array(pmd_t *pmdp)
+{
+ /*
+* The hpte hindex is stored in the pgtable whose address is in the
+* second half of the PMD
+*
+* Order this load with the test for pmd_trans_huge in the caller
+*/
+ smp_rmb();
+ return *(char **)(pmdp + PTRS_PER_PMD);
+
+
+}
+
extern void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
pmd_t *pmdp);
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff --git a/arch/powerpc/mm/hugepage-hash64.c
b/arch/powerpc/mm/hugepage-hash64.c
index e430766..c3ba3d5 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -84,11 +84,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access,
unsigned long vsid,
vpn = hpt_vpn(ea, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
- /*
-* The hpte hindex are stored in the pgtable whose address is in the
-* second half of the PMD
-*/
- hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+ hpte_slot_array = get_hpte_slot_array(pmdp);
valid = hpte_valid(hpte_slot_array, index);
if (valid) {
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 8dd7c83..19d6734 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -701,11 +701,7 @@ void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned
long addr,
* Flush all the hptes mapping this hugepage
*/
s_addr = addr & HPAGE_PMD_MASK;
- /*
-* The hpte hindex are stored in the pgtable whose address is in the
-* second half of the PMD
-*/
- hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+ hpte_slot_array = get_hpte_slot_array(pmdp);
/*
* IF we try to do a HUGE PTE update after a withdraw is done.
* we will find the below NULL. This happens when we do
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: split hugepage when using subpage protection
From: "Aneesh Kumar K.V"
We find all the overlapping vma and mark them such that we don't allocate
hugepage in that range. Also we split existing huge page so that the
normal page hash can be invalidated and new page faulted in with new
protection bits.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/subpage-prot.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
index 7c415dd..33fd329 100644
--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr,
unsigned long len)
up_write(&mm->mmap_sem);
}
+static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
+ unsigned long end, struct mm_walk *walk)
+{
+ struct vm_area_struct *vma = walk->private;
+ split_huge_page_pmd(vma, addr, pmd);
+ return 0;
+}
+
/*
* Copy in a subpage protection map for an address range.
* The map has 2 bits per 4k subpage, so 32 bits per 64k page.
@@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long
len, u32 __user *map)
size_t nw;
unsigned long next, limit;
int err;
+ struct vm_area_struct *vma;
+
+ struct mm_walk subpage_proto_walk = {
+ .mm = mm,
+ .pmd_entry = subpage_walk_pmd_entry,
+ };
/* Check parameters */
if ((addr & ~PAGE_MASK) || (len & ~PAGE_MASK) ||
@@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long
len, u32 __user *map)
return -EFAULT;
down_write(&mm->mmap_sem);
+
+ /*
+* We don't try too hard, we just mark all the vma in that range
+* VM_NOHUGEPAGE and split them.
+*/
+ for (vma = find_vma(mm, addr);
+(vma && vma->vm_end < (addr + len)); vma = vma->vm_next) {
+
+ vma->vm_flags |= VM_NOHUGEPAGE;
+ subpage_proto_walk.private = vma;
+ walk_page_range(vma->vm_start, vma->vm_end,
+ &subpage_proto_walk);
+ }
for (limit = addr + len; addr < limit; addr = next) {
next = pmd_addr_end(addr, limit);
err = -ENOMEM;
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pci: fix PCI-e check link issue
For Freescale powerpc platform, the PCI-e bus number uses the reassign mode
by default. It means the second PCI-e controller's hose->first_busno is the
first controller's last bus number adding 1. For some hotpluged device(or
controlled by FPGA), the device is linked to PCI-e slot at linux runtime.
It needs rescan for the system to add it and driver it to work. It successes
to rescan the device linked to the first PCI-e controller's slot, but fails to
rescan the device linked to the second PCI-e controller's slot. The cause is
that the bus->number is reset to 0, which isn't equal to the hose->first_busno
for the second controller checking PCI-e link. So it doesn't really check the
PCI-e link status, the link status is always no_link. The device won't be
really rescaned. Reset the bus->number to hose->first_busno in the function
fsl_pcie_check_link(), it will do the real checking PCI-e link status for the
second controller, the device will be rescaned.
Signed-off-by: Yuanquan Chen
---
arch/powerpc/sysdev/fsl_pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..534597a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -64,7 +64,7 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
if (hose->indirect_type & PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
if (hose->ops->read == fsl_indirect_read_config) {
struct pci_bus bus;
- bus.number = 0;
+ bus.number = hose->first_busno;
bus.sysdata = hose;
bus.ops = hose->ops;
indirect_read_config(&bus, 0, PCIE_LTSSM, 4, &val);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/pci: remove the unused variables in pci_process_bridge_OF_ranges
The codes which ever used these two variables have gone. Throw away
them too.
Signed-off-by: Kevin Hao
---
arch/powerpc/kernel/pci-common.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8245d51..50fabab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -671,10 +671,9 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
int rlen;
int pna = of_n_addr_cells(dev);
int np = pna + 5;
- int memno = 0, isa_hole = -1;
+ int memno = 0;
u32 pci_space;
unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
- unsigned long long isa_mb = 0;
struct resource *res;
printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
@@ -768,8 +767,6 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
}
/* Handles ISA memory hole space here */
if (pci_addr == 0) {
- isa_mb = cpu_addr;
- isa_hole = memno;
if (primary || isa_mem_base == 0)
isa_mem_base = cpu_addr;
hose->isa_mem_phys = cpu_addr;
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/pci: remove the stale comments of pci_process_bridge_OF_ranges
These comments already don't apply to the current code. So just remove them. Signed-off-by: Kevin Hao --- arch/powerpc/kernel/pci-common.c | 9 - 1 file changed, 9 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 6053f03..8245d51 100644 --- a/arch/powerpc/kernel/pci-common.c +++ b/arch/powerpc/kernel/pci-common.c @@ -657,15 +657,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar, * ranges. However, some machines (thanks Apple !) tend to split their * space into lots of small contiguous ranges. So we have to coalesce. * - * - We can only cope with all memory ranges having the same offset - * between CPU addresses and PCI addresses. Unfortunately, some bridges - * are setup for a large 1:1 mapping along with a small "window" which - * maps PCI address 0 to some arbitrary high address of the CPU space in - * order to give access to the ISA memory hole. - * The way out of here that I've chosen for now is to always set the - * offset based on the first resource found, then override it if we - * have a different offset and the previous was set by an ISA hole. - * * - Some busses have IO space not starting at 0, which causes trouble with * the way we do our IO resource renumbering. The code somewhat deals with * it for 64 bits but I would expect problems on 32 bits. -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
