On ARM the debug info is not present in the .eh_frame sections but
in .debug_frame instead, in dwarf format.
This patch set uses libunwind to load and parse the dwarf debug info from
the .debug_frame section if no .eh_frame_hdr section is found; also it
sets the hooks in the perf_regs and libunwind code for ARMv7.
Dependencies:
. if present, libunwind >= 1.1 is needed to prevent a segfault when
parsing the dwarf info,
. libunwind needs to be configured with --enable-debug-frame
to prevent a linkage error. Note: --enable-debug-frame is automatically
selected on ARM).
The generated perf has been tested on ARMv7 (OMAP4, Marvell Armada XP) and
x86_64, using the following commands:
perf record -g [dwarf] -- <binary>
perf report --sort symbol --call-graph --stdio
Jean Pihet (2):
perf tools: Check libunwind for availability of dwarf parsing feature
perf: parse the .debug_frame section in case .eh_frame is not present
Will Deacon (2):
ARM: perf: add support for perf registers API
ARM: perf: wire up perf_regs and unwind support for ARM
arch/arm/Kconfig | 2 +
arch/arm/include/uapi/asm/Kbuild | 1 +
arch/arm/include/uapi/asm/perf_regs.h | 23 +++++++++++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/perf_regs.c | 30 ++++++++++++++
tools/perf/arch/arm/Makefile | 3 ++
tools/perf/arch/arm/include/perf_regs.h | 54 +++++++++++++++++++++++++
tools/perf/arch/arm/util/unwind.c | 48 ++++++++++++++++++++++
tools/perf/config/Makefile | 7 +++-
tools/perf/config/feature-tests.mak | 11 ++++-
tools/perf/util/unwind.c | 71 +++++++++++++++++++++++++--------
11 files changed, 232 insertions(+), 19 deletions(-)
create mode 100644 arch/arm/include/uapi/asm/perf_regs.h
create mode 100644 arch/arm/kernel/perf_regs.c
create mode 100644 tools/perf/arch/arm/include/perf_regs.h
create mode 100644 tools/perf/arch/arm/util/unwind.c
--
1.7.11.7
Lots of device drivers especially for platform/I2C/SPI bus devices,
they want to be initialized earlier than other devices, so the driver
use initcall such as subsys_initcall for the device initialization.
But for those drivers, lots of them just do nothing special in
xxx_initcall/module_exit, and produce lots of boilerplate.
This patch set introduces a helper macro initcall_driver() to
eliminate lots of boilerplate just like module_driver() did, and use
it for platform/I2C/SPI bus devices.
I use following command under the lastest kernel source code:
$grep -r -E "*_initcall" drivers/ | cut -d":" -f1 |xargs grep -E
"return platform_driver_register|return i2c_add_driver|return spi_register_driver"
| cut -d":" -f1 | xargs grep "module_exit" | wc -l
and get 205 hits, so if we use helper macro initcall_driver(),
we can reduce thousands lines of code.
Hanjun Guo (4):
driver core: introduce helper macro initcall_driver()
platform device: introduce helper macro initcall_platform_driver()
i2c: introduce helper macro initcall_i2c_driver()
spi: introduce helper macro initcall_spi_driver()
include/linux/device.h | 27 +++++++++++++++++++++++++++
include/linux/i2c.h | 11 +++++++++++
include/linux/platform_device.h | 11 +++++++++++
include/linux/spi/spi.h | 11 +++++++++++
4 files changed, 60 insertions(+)
--
1.7.9.5
It will be very useful for user space (QEMU/KVMTOOL) if it has a
method of querying VCPU target type matching to underlying Host.
We can use such querying mechanism and implement machine models
in user space where VCPU target type is always same-as/similar-to
underlying Host (i.e. Target CPU=Host).
This patch series implements KVM_ARM_PREFERRED_TARGET vm ioclt for
querying VCPU target type matching underlying host. Using this new
ioctl we can implement VCPU target CPU=Host in user space.
Also, it is not mandatory to call KVM_ARM_PREFERRED_TARGET vm ioctl
and the old method of trying all possible target types using the
KVM_ARM_VCPU_INIT ioctl to initialize VCPU works fine.
V4:
- Fixed files exchanged between patches
- For now return zeroed features in struct kvm_vcpu_init instance
V3:
- Return -ENODEV if no preferred target available for host
- Make KVM_ARM_PREFERRED_TARGET ioctl as vm ioctl
V2:
- Renamed the ioclt to KVM_ARM_PREFERRED_TARGET
- Return struct kvm_vcpu_init instace instead of just target type
V1:
- Initial patch-set with ioctl named as KVM_ARM_SUITABLE_TARGET
Anup Patel (4):
ARM: KVM: Implement kvm_vcpu_preferred_target() function
ARM64: KVM: Implement kvm_vcpu_preferred_target() function
ARM/ARM64: KVM: Implement KVM_ARM_PREFERRED_TARGET ioctl
KVM: Add documentation for KVM_ARM_PREFERRED_TARGET ioctl
Documentation/virtual/kvm/api.txt | 27 +++++++++++++++++++++++----
arch/arm/include/asm/kvm_host.h | 1 +
arch/arm/kvm/arm.c | 13 +++++++++++++
arch/arm/kvm/guest.c | 20 ++++++++++++++++++++
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/guest.c | 20 ++++++++++++++++++++
include/uapi/linux/kvm.h | 1 +
7 files changed, 79 insertions(+), 4 deletions(-)
--
1.7.9.5
This patch set just did one simple thing: convert to module_platform_driver()
in video driver to simplify the code.
Hanjun Guo (10):
Video / hecubafb: Use module_platform_driver() to simplify code
Video / bfin-t350mcqb-fb: Use module_platform_driver() to simplify
code
Video / metronomefb: Use module_platform_driver() to simplify code
Video / jz4740_fb: Use module_platform_driver() to simplify code
Video / da8xx-fb: Use module_platform_driver() to simplify code
Video / cobalt_lcdfb: Use module_platform_driver() to simplify code
Video / broadsheetfb: Use module_platform_driver() to simplify code
Video / bf54x-lq043fb: Use module_platform_driver() to simplify code
Video / au1200fb: Use module_platform_driver() to simplify code
Video / au1100fb: Use module_platform_driver() to simplify code
drivers/video/au1100fb.c | 14 +-------------
drivers/video/au1200fb.c | 16 +---------------
drivers/video/bf54x-lq043fb.c | 14 +-------------
drivers/video/bfin-t350mcqb-fb.c | 14 +-------------
drivers/video/broadsheetfb.c | 14 +-------------
drivers/video/cobalt_lcdfb.c | 14 +-------------
drivers/video/da8xx-fb.c | 14 +-------------
drivers/video/hecubafb.c | 14 +-------------
drivers/video/jz4740_fb.c | 13 +------------
drivers/video/metronomefb.c | 14 +-------------
10 files changed, 10 insertions(+), 131 deletions(-)
--
1.7.9.5
Hi,
I tried to build linaro kernel for pandaboard. I have tried everything what
I can think of but the kernel still can't boot correctly. Any help will be
appreciated. Here is what I did:
1. I flash the 13.07 linaro-ubuntu-pandaboard image into the sd card (
http://releases.linaro.org/13.07/ubuntu/panda). This image works fine.
2. I clone the kernel source code from git://
git.linaro.org/kernel/linux-linaro-stable.git.
3. checkout the lsk 13.07 tag.
4. copy the config file from original image (i.e.
/boot/config-3.10.1.0-1-linaro-omap).
5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CFLAGS="-O"
LOADADDR=0x80008000 uImage
The cross compiler on my machine is gcc-4.7-arm-linux-gnueabihf-base
6. From pandaboard, I load the built uImage via scp.
The problem I met:
1. In most cases, the kernel can't boot correctly. And the terminal keeps
printing "hub 1-1:1.0: hub_port_status failed (err = -71)".
2.Sometime, the kernel can finish booting. But the terminal prints for
several times the aforementioned error message after booting. Plus, I don't
have any module running, 'lsmod' shows nothing.
Please help! Thank you.
--
Regards,
Chao Xu