- Mar 13, 2014
-
-
Florian Vaussard authored
Chestnut43 is an expansion board for Gumstix Overo products. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Alto35 is an expansion board for Gumstix Overo products. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Gallop43 is an expansion board for Gumstix Overo products. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Palo43 is an expansion board for Gumstix Overo products. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
The LIS33DE accelerometer is used on several Gumstix expansion boards, thus add the DT node to omap3-overo-common-peripherals.dtsi. For the boards that do not have the accelerometer (like Tobi), mark the status as disabled. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Gumstix expansion boards share a couple of peripherals: - uart3 is used for the console - AT24C01 EEPROM on i2c3 Use this file for overo-tobi. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
UART3 is used by expansion boards to get a tty console. Thus, the pinmux should be defined by expansion boards, instead of being imposed by the processor board. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Add the AT24C01 EEPROM node populated on most Gumstix expansion board. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Use the timings provided by omap-gpmc-smsc9221. This does not change the timings, but it avoids code duplication. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Some devices (SMSC9217, SMSC9218 and SMSC9221 at least) have better timings, allowing a higher transfer speed. Create a common file with these timings. Performance results with iperf: - omap-gpmc-smsc911x.dtsi => 54.9 Mbps - omap-gpmc-smsc9221.dtsi => 92.7 Mbps Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Add the High-Speed USB PHY. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Acked-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). The Bluetooth is connected to UART2. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Add missing pinctrl entries for: - i2c1 - mmc1 Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Add missing pinctrl entries: - i2c3 Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Florian Vaussard authored
Currently, overo-related include files are organized as follow: omap3-overo.dtsi | | omap34xx.dtsi omap3-overo-tobi-common.dtsi omap36xx.dtsi | | | | --------------- --------------- | | omap3-overo-tobi.dts omap3-overo-storm-tobi.dts This is unpractical when one has to deal with SoC-specific pinmux belonging to the omap3_pmx_core2 (defined in omap34xx/omap36xx), for pins related to the processor board. With the current hierarchy, such pinmux has to be defined in the expansion board's .dts, which is not logical. This patches reorganizes the files to add (yet another) abstraction layer between the processor and the expansion boards. omap34xx.dtsi omap3-overo-base.dtsi omap36xx.dtsi | | | | --------------- --------------- | | omap3-overo.dtsi omap3-overo-storm.dtsi | | -------- ------ | omap3-overo-tobi-common.dtsi | | | | | --------------- --------------- | | omap3-overo-tobi.dts omap3-overo-storm-tobi.dts Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- Feb 22, 2014
-
-
Stephane Eranian authored
This patch updates the CBOX PMU filters mapping tables for SNB-EP and IVT (model 45 and 62 respectively). The NID umask always comes in addition to another umask. When set, the NID filter is applied. The current mapping tables were missing some code/umask combinations to account for the NID umask. This patch fixes that. Cc: mingo@elte.hu Cc: ak@linux.intel.com Reviewed-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140219131018.GA24475@quad Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Peter Zijlstra authored
The current code simply assumes Intel Arch PerfMon v2+ to have the IA32_PERF_CAPABILITIES MSR; the SDM specifies that we should check CPUID[1].ECX[15] (aka, FEATURE_PDCM) instead. This was found by KVM which implements v2+ but didn't provide the capabilities MSR. Change the code to DTRT; KVM will also implement the MSR and return 0. Cc: pbonzini@redhat.com Reported-by:
"Michael S. Tsirkin" <mst@redhat.com> Suggested-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140203132903.GI8874@twins.programming.kicks-ass.net Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Markus Metzger authored
When using BTS on Core i7-4*, I get the below kernel warning. $ perf record -c 1 -e branches:u ls Message from syslogd@labpc1501 at Nov 11 15:49:25 ... kernel:[ 438.317893] Uhhuh. NMI received for unknown reason 31 on CPU 2. Message from syslogd@labpc1501 at Nov 11 15:49:25 ... kernel:[ 438.317920] Do you have a strange power saving mode enabled? Message from syslogd@labpc1501 at Nov 11 15:49:25 ... kernel:[ 438.317945] Dazed and confused, but trying to continue Make intel_pmu_handle_irq() take the full exit path when returning early. Cc: eranian@google.com Cc: peterz@infradead.org Cc: mingo@kernel.org Signed-off-by:
Markus Metzger <markus.t.metzger@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1392425048-5309-1-git-send-email-andi@firstfloor.org Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Feb 20, 2014
-
-
Grant Likely authored
The testcase data is usable by any platform. This patch moves it into the drivers/of directory so it can be included by any architecture. Using the test cases requires manually adding #include <testcases.dtsi> to the end of the boards .dtsi file and enabling CONFIG_OF_SELFTEST. Not pretty though. A useful project would be to make the testcase code easier to execute. Signed-off-by:
Grant Likely <grant.likely@linaro.org>
-
Paul Gortmaker authored
While copy_to/from_user_page() users are uncommon, there is one in drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c which leads to the following: ERROR: "sparc32_cachetlb_ops" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! during routine allmodconfig build coverage. The reason this happens is as follows: In arch/sparc/include/asm/cacheflush_32.h we have: #define flush_cache_page(vma,addr,pfn) \ sparc32_cachetlb_ops->cache_page(vma, addr) #define copy_to_user_page(vma, page, vaddr, dst, src, len) \ do { \ flush_cache_page(vma, vaddr, page_to_pfn(page));\ memcpy(dst, src, len); \ } while (0) #define copy_from_user_page(vma, page, vaddr, dst, src, len) \ do { \ flush_cache_page(vma, vaddr, page_to_pfn(page));\ memcpy(dst, src, len); \ } while (0) However, sparc32_cachetlb_ops isn't exported and hence the error. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paul Gortmaker authored
In arch/sparc/Kernel/Makefile, we see: obj-$(CONFIG_SPARC64) += jump_label.o However, the Kconfig selects HAVE_ARCH_JUMP_LABEL unconditionally for all SPARC. This in turn leads to the following failure when doing allmodconfig coverage builds: kernel/built-in.o: In function `__jump_label_update': jump_label.c:(.text+0x8560c): undefined reference to `arch_jump_label_transform' kernel/built-in.o: In function `arch_jump_label_transform_static': (.text+0x85cf4): undefined reference to `arch_jump_label_transform' make: *** [vmlinux] Error 1 Change HAVE_ARCH_JUMP_LABEL to be conditional on SPARC64 so that it matches the Makefile. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mika Westerberg authored
Intel Baytrail is based on Silvermont core so MSR_FSB_FREQ[2:0] == 0 means that the CPU reference clock runs at 83.3MHz. Add this missing frequency to the table. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Bin Gao <bin.gao@linux.intel.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/r/1392810750-18660-2-git-send-email-mika.westerberg@linux.intel.com Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
If we cannot calibrate TSC via MSR based calibration try_msr_calibrate_tsc() stores zero to fast_calibrate and returns that to the caller. This value gets then propagated further to clockevents code resulting division by zero oops like the one below: divide error: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0+ #47 task: ffff880075508000 ti: ffff880075506000 task.ti: ffff880075506000 RIP: 0010:[<ffffffff810aec14>] [<ffffffff810aec14>] clockevents_config.part.3+0x24/0xa0 RSP: 0000:ffff880075507e58 EFLAGS: 00010246 RAX: ffffffffffffffff RBX: ffff880079c0cd80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff RBP: ffff880075507e70 R08: 0000000000000001 R09: 00000000000000be R10: 00000000000000bd R11: 0000000000000003 R12: 000000000000b008 R13: 0000000000000008 R14: 000000000000b010 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880079c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff880079fff000 CR3: 0000000001c0b000 CR4: 00000000001006f0 Stack: ffff880079c0cd80 000000000000b008 0000000000000008 ffff880075507e88 ffffffff810aecb0 ffff880079c0cd80 ffff880075507e98 ffffffff81030168 ffff880075507ed8 ffffffff81d1104f 00000000000000c3 0000000000000000 Call Trace: [<ffffffff810aecb0>] clockevents_config_and_register+0x20/0x30 [<ffffffff81030168>] setup_APIC_timer+0xc8/0xd0 [<ffffffff81d1104f>] setup_boot_APIC_clock+0x4cc/0x4d8 [<ffffffff81d0f5de>] native_smp_prepare_cpus+0x3dd/0x3f0 [<ffffffff81d02ee9>] kernel_init_freeable+0xc3/0x205 [<ffffffff8177c910>] ? rest_init+0x90/0x90 [<ffffffff8177c91e>] kernel_init+0xe/0x120 [<ffffffff8178deec>] ret_from_fork+0x7c/0xb0 [<ffffffff8177c910>] ? rest_init+0x90/0x90 Prevent this from happening by: 1) Modifying try_msr_calibrate_tsc() to return calibration value or zero if it fails. 2) Check this return value in native_calibrate_tsc() and in case of zero fallback to use normal non-MSR based calibration. [mw: Added subject and changelog] Reported-and-tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Bin Gao <bin.gao@linux.intel.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/r/1392810750-18660-1-git-send-email-mika.westerberg@linux.intel.com Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Feb 19, 2014
-
-
Stephen Warren authored
Fix tegra_init_cache() to check whether the system has a PL310 cache before touching the PL310 registers. This prevents access to non-existent registers on Tegra114 and later. Note for stable kernels: In <= v3.12, the file to patch is arch/arm/mach-tegra/common.c. Cc: <stable@vger.kernel.org> # v3.9+ Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Thierry Reding authored
The number of the head specifies the index of the display controller unit and is required to properly configure outputs so that they receive video data from the correct source. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Shawn Guo authored
When building a kernel image with only CONFIG_CPU_IDLE but no CONFIG_PM, we will get the following link error. LD init/built-in.o arch/arm/mach-imx/built-in.o: In function `imx6q_enter_wait': platform-spi_imx.c:(.text+0x25c0): undefined reference to `imx6q_set_lpm' platform-spi_imx.c:(.text+0x25d4): undefined reference to `imx6q_set_lpm' arch/arm/mach-imx/built-in.o: In function `imx6q_cpuidle_init': platform-spi_imx.c:(.init.text+0x75d4): undefined reference to `imx6q_set_chicken_bit' make[1]: *** [vmlinux] Error 1 Since pm-imx6q.c has been a collection of library functions that access CCM low-power registers used by not only suspend but also cpuidle and other drivers, let's build pm-imx6q.c independently of CONFIG_PM to fix above error. Reported-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: stable@vger.kernel.org Acked-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Stephen Warren authored
This alias entry was evidently cut/paste from a different board, and not correctly updated to match Cardhu. Fix this. Fixes: 553c0a20 ("ARM: tegra: set up /aliases entries for RTCs") Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Jason Cooper authored
The corresponding driver didn't make it into v3.14, so we need to remove the node. Dove systems fail to boot with the node present and no driver. This node will be re-added when the driver makes it to mainline. Reported-by:
Jean-Francois Moine <moinejf@free.fr> Tested-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
- Feb 18, 2014
-
-
Vinayak Kale authored
Add DSB after icache flush to complete the cache maintenance operation. Signed-off-by:
Vinayak Kale <vkale@apm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- Feb 17, 2014
-
-
Chen Gang authored
Need add generic "vga.h", or can not pass building for allmodconfig, the related error: CC [M] drivers/gpu/drm/drm_irq.o In file included from include/linux/vgaarb.h:34, from drivers/gpu/drm/drm_irq.c:42: include/video/vga.h:22:21: error: asm/vga.h: No such file or directory Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Hans-Christian Egtvedt <hegtvedt@cisco.com>
-
Chen Gang authored
Need generic ioremap_wc(), or can not pass compiling with allmodconfig, the related error: CC [M] drivers/gpu/drm/drm_bufs.o drivers/gpu/drm/drm_bufs.c: In function 'drm_addmap_core': drivers/gpu/drm/drm_bufs.c:217: error: implicit declaration of function 'ioremap_wc' drivers/gpu/drm/drm_bufs.c:218: warning: assignment makes pointer from integer without a cast Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Hans-Christian Egtvedt <hegtvedt@cisco.com>
-
Chen Gang authored
For avr32 cross compiler, do not define '__linux__' internally, so it will cause issue with allmodconfig. The related error: CC [M] fs/coda/psdev.o In file included from include/linux/coda.h:64, from fs/coda/psdev.c:45: include/uapi/linux/coda.h:221: error: expected specifier-qualifier-list before 'u_quad_t' The related toolchain version (which only download, not re-compile): [root@gchen linux-next]# /upstream/toolchain/download/avr32-gnu-toolchain-linux_x86/bin/avr32-gcc -v Using built-in specs. Target: avr32 Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/src/gcc/configure --target=avr32 --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-languages=c,c++ --disable-nls --disable-libssp --disable-libstdcxx-pch --with-dwarf2 --enable-version-specific-runtime-libs --disable-shared --enable-doc --with-mpfr-lib=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/lib --with-mpfr-include=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/include --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-__cxa_atexit --disable-shared --with-newlib --with-pkgversion=AVR_32_bit_GNU_Toolchain_3.4.2_435 --with-bugurl=http://www .atmel.com/avr Thread model: single gcc version 4.4.7 (AVR_32_bit_GNU_Toolchain_3.4.2_435) Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Hans-Christian Egtvedt <hegtvedt@cisco.com> Cc: stable@vger.kernel.org
-
Paul Gortmaker authored
Causing this: In file included from arch/avr32/boards/mimc200/fram.c:13: include/linux/miscdevice.h:51: error: field 'list' has incomplete type include/linux/miscdevice.h:55: error: expected specifier-qualifier-list before 'mode_t' arch/avr32/boards/mimc200/fram.c:42: error: 'THIS_MODULE' undeclared here (not in a function) Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: stable@vger.kernel.org
-
Gavin Shan authored
We possiblly detect EEH errors during reboot, particularly in kexec path, but it's impossible for device drivers and EEH core to handle or recover them properly. The patch registers one reboot notifier for EEH and disable EEH subsystem during reboot. That means the EEH errors is going to be cleared by hardware reset or second kernel during early stage of PCI probe. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Gavin Shan authored
The patch cleans up variable eeh_subsystem_enabled so that we needn't refer the variable directly from external. Instead, we will use function eeh_enabled() and eeh_set_enable() to operate the variable. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Gavin Shan authored
When doing reset in order to recover the affected PE, we issue hot reset on PE primary bus if it's not root bus. Otherwise, we issue hot or fundamental reset on root port or PHB accordingly. For the later case, we didn't cover the situation where PE only includes root port and it potentially causes kernel crash upon EEH error to the PE. The patch reworks the logic of EEH reset to improve the code readability and also avoid the kernel crash. Cc: stable@vger.kernel.org Reported-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
We are seeing a lot of hits in the VDSO that are not resolved by perf. A while(1) gettimeofday() loop shows the issue: 27.64% [vdso] [.] 0x000000000000060c 22.57% [vdso] [.] 0x0000000000000628 16.88% [vdso] [.] 0x0000000000000610 12.39% [vdso] [.] __kernel_gettimeofday 6.09% [vdso] [.] 0x00000000000005f8 3.58% test [.] 00000037.plt_call.gettimeofday@@GLIBC_2.18 2.94% [vdso] [.] __kernel_datapage_offset 2.90% test [.] main We are using a stripped VDSO image which means only symbols with relocation info can be resolved. There isn't a lot of point to stripping the VDSO, the debug info is only about 1kB: 4680 arch/powerpc/kernel/vdso64/vdso64.so 5815 arch/powerpc/kernel/vdso64/vdso64.so.dbg By using the unstripped image, we can resolve all the symbols in the VDSO and the perf profile data looks much better: 76.53% [vdso] [.] __do_get_tspec 12.20% [vdso] [.] __kernel_gettimeofday 5.05% [vdso] [.] __get_datapage 3.20% test [.] main 2.92% test [.] 00000037.plt_call.gettimeofday@@GLIBC_2.18 Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
perf is failing to resolve symbols in the VDSO. A while (1) gettimeofday() loop shows: 93.99% [vdso] [.] 0x00000000000005e0 3.12% test [.] 00000037.plt_call.gettimeofday@@GLIBC_2.18 2.81% test [.] main The reason for this is that we are linking our VDSO shared libraries at 1MB, which is a little weird. Even though this is uncommon, Alan points out that it is valid and we should probably fix perf userspace. Regardless, I can't see a reason why we are doing this. The code is all position independent and we never rely on the VDSO ending up at 1M (and we never place it there on 64bit tasks). Changing our link address to 0x0 fixes perf VDSO symbol resolution: 73.18% [vdso] [.] 0x000000000000060c 12.39% [vdso] [.] __kernel_gettimeofday 3.58% test [.] 00000037.plt_call.gettimeofday@@GLIBC_2.18 2.94% [vdso] [.] __kernel_datapage_offset 2.90% test [.] main We still have some local symbol resolution issues that will be fixed in a subsequent patch. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Aneesh Kumar K.V authored
Archs like ppc64 doesn't do tlb flush in set_pte/pmd functions when using a hash table MMU for various reasons (the flush is handled as part of the PTE modification when necessary). ppc64 thus doesn't implement flush_tlb_range for hash based MMUs. Additionally ppc64 require the tlb flushing to be batched within ptl locks. The reason to do that is to ensure that the hash page table is in sync with linux page table. We track the hpte index in linux pte and if we clear them without flushing hash and drop the ptl lock, we can have another cpu update the pte and can end up with duplicate entry in the hash table, which is fatal. We also want to keep set_pte_at simpler by not requiring them to do hash flush for performance reason. We do that by assuming that set_pte_at() is never *ever* called on a PTE that is already valid. This was the case until the NUMA code went in which broke that assumption. Fix that by introducing a new pair of helpers to set _PAGE_NUMA in a way similar to ptep/pmdp_set_wrprotect(), with a generic implementation using set_pte_at() and a powerpc specific one using the appropriate mechanism needed to keep the hash table in sync. Acked-by:
Mel Gorman <mgorman@suse.de> Reviewed-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Aneesh Kumar K.V authored
pte_update() is a powerpc-ism used to change the bits of a PTE when the access permission is being restricted (a flush is potentially needed). It uses atomic operations on when needed and handles the hash synchronization on hash based processors. It is currently only used to clear PTE bits and so the current implementation doesn't provide a way to also set PTE bits. The new _PAGE_NUMA bit, when set, is actually restricting access so it must use that function too, so this change adds the ability for pte_update() to also set bits. We will use this later to set the _PAGE_NUMA bit. Acked-by:
Mel Gorman <mgorman@suse.de> Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-