linaro-kernel

linaro-kernel@lists.linaro.org

10094 discussions

[ACTIVITY] (Rajanikanth H V) 2012-12-03 to 2012-12-07

by Rajanikanth HV

==== Activity Summary ==== * Implemented review comments from LeeJones on ab8500-DT delta patch set, communicated to anton. * Review discussion with deepak on runtime size gathering and updated my blueprints accordingly. * Discussion with arnd on my observation regarding drivers having FDT and "not supporting for module build", arnd is OK to have it as built-in. We can continue to measure for rest of the modules. * Did platform setup, Qemu-vexpress-a9 setup with confined/minimal rootfs to gather runtime information, first cut memory information is available from a sample ethernet module, communicated the data to arnd and others * Pinged shawn Guo to initiate run time data gathering on i.MX platform ==== Plan ==== * Work on runtime on zImage size analysis across U8500, OMAP, VExpress and i.MX ==== Issues ==== -- NA --

12 years, 4 months

[ACTIVITY] (John Stultz) Dec 3-7

by John Stultz

=== Highlights === * Got the Linaro Android kernel branch updated with Anton's 3.7 forward port along with numerous updates from the AOSP 3.4 tree. * Finally merged fixes from Tixy and Tushar into Linaro-Android (sorry for being so slow!) * Discussions with Zach/Deepak around aligning Android Upstreaming team with other work being done. * Continued discussions around Minchan's vma/madvise approach to volatile ranges. * Discussed some issues with Anton around his vmpressure notification work. === Plans === * Again: Continue hacking on the vma/madvise approach to volatile ranges. - Integrate this approach into the ashmem driver - Try to add limits so it returns -EINVAL on non-tmpfs filesystems - Find a way to deal with aging anonymous pages so we purge volatile ranges in the swapoff case === Issues === * NA

12 years, 5 months

RE: ACPI 5.0 implementation for armv7 and armv8 architecture

by Ayan Halder

Hi Leif/Linaro Team, Thanks for your response. >Will they both be needing ACPI? >Cortex-A5 is an ARMv7 processor. Yes I need to implement ACPI 5.0 for both( armv7 and armv8 architecture ) processors. >As I see it, C0 and C1 are straightforward enough: C0 is "running" >and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for >S1-S5. Does Arm have a power controller which can fulfill such requirements. >ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: >http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html As the document has discussed Operating System and Power Management(OSPM) and its interfaces, does ARM have any codebase which implements the features described in the document. > Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. I would interested to know further the implementation of ACPI for ARM. Which ACPI model(Reduced/Fixed/Generic as described by Hardware specifications of ACPI5.0) does the Linaro group plan to implement on the SOC. Do they intend to target both armv7 and armv8 architecture? Besides adding ACPI registers and an ACPI compliant BIOS(UEFI containing ACPI tables), are there any changes from the hardware perspective( of armv7 and armv8 ). I would greatly appreciate if you could provide me some more details on this. Regards, Ayan Kumar Halder -----Original Message----- From: Leif Lindholm [mailto:leif.lindholm@linaro.org] Sent: Monday, December 03, 2012 11:49 PM To: Ayan Halder Cc: linaro-kernel(a)lists.linaro.org Subject: Re: ACPI 5.0 implementation for armv7 and armv8 archoitecture Hi, > I am planning to implement ACPI5.0 on an SOC having Cortex A5 and > Atlas cpu( based on armv8 architecture) running linux on top of them. Will they both be needing ACPI? Cortex-A5 is an ARMv7 processor. > As per the ACPI 5.0 hardware specification(Fixed Hardware/ Generic > Hardware model) of ACPI5.0, the processor needs to support various > low power modes(C0, C1, C2, C3) and sleep states(S1, S2, S3, S4, S5) > via register interfaces as well as OEM provided AML(ACPI Machine > Language). OK. > Therefore, which instructions in armv7 and armv8 put the processor > into the afore-mentioned low power modes and sleep states? > ( The arm instruction manual specifies "wfe" and "wfi" to put the > processor in a sleep state, but I am not sure if this confirms to the > ACPI 5.0 requirements ) As I see it, C0 and C1 are straightforward enough: C0 is "running" and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for S1-S5. ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html (free registration required). It does not however contain ACPI-specific information. > Besides, does arm provide any AML(ACPI Machine Language) code to put > the processor to low power modes? If not, then how do we create an > ACPI machine language code for armv7 and armv8 architecture and do we > have an AML interpreter for armv7 and armv8 architecture? Not as far as I'm aware. Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. / Leif

12 years, 5 months

[PATCH resend 0/4] ARM: KDB FIQ debugger

by Anton Vorontsov

Hello Andrew, Russell, The KDB/NMI core support has been merged into v3.7-rc1, so the only ARM bits are pending now. I addressed all the comments ~two month ago, and since then just resending these patches. I know we're all busy, so no blaming. :) But then let's pass this via -mm? Short description of the KDB/FIQ debugger: The FIQ debugger is a facility that can be used to debug situations when the kernel stuck in uninterruptable sections, e.g. the kernel infinitely loops or deadlocked in an interrupt or with interrupts disabled. On some development boards there is even a special NMI button, which is very useful for debugging weird kernel hangs. And FIQ is basically an NMI, it has a higher priority than IRQs, and upon IRQ exception FIQs are not disabled. It is still possible to disable FIQs (as well as some "NMIs" on other architectures), but via special means. Old changelogs and a full rationale for these patches can be found here: v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2 v6: http://lkml.org/lkml/2012/9/10/2 v7: http://lkml.org/lkml/2012/9/13/367 v8: http://lkml.org/lkml/2012/9/19/525 v9: http://lkml.org/lkml/2012/9/24/538 Thanks! Anton. -- arch/arm/Kconfig | 19 ++++ arch/arm/common/vic.c | 28 +++++ arch/arm/include/asm/hardware/vic.h | 2 + arch/arm/include/asm/kgdb.h | 8 ++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +-------------------------- arch/arm/kernel/entry-header.S | 170 ++++++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 124 ++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 ++++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++ 11 files changed, 472 insertions(+), 166 deletions(-)

12 years, 5 months

PMU Based Cycle Count Enablement

by Eric Van Hensbergen

Hi, I'm doing a bunch of high-performance computing benchmarking on ARM -- the benchmarks and runtimes like to have a fine-grained cycle counter that is available from user space (something like MFTB on PowerPC), so I've been using the PMU cycle counter in a similar fashion to what has been documented here: https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/4VUJyOJx2r8 The downside is that I have to have a kernel module which enables it's use by user space, which complicates up-streaming ARM versions of the various benchmarks (as I don't want to have to include a kernel module with them....). It would seem to me that it would be better to have a sysfs interface (or something similar) which allowed privileged users to enable/disable user-land access to the PMU in the mainstream kernel. This could also help with arbitrating access to PMU from conflicting sources (such as trying to use the CCNT from user-space when it is being used by oprofile). I'm open to other suggestions, but if this sounds like a good idea I'd be willing to draft a patch to add such an interface (assuming it doesn't already exist elsewhere and I just didn't find it with some quick greps). Thanks, -eric

12 years, 5 months

Arndale board Linaro kernel

by Simon Baines

Hi everyone, I'm trying to use the Linaro kernel for Ubuntu on the Arndale board as described here: https://wiki.linaro.org/Boards/Arndale/Setup/EnterpriseUbuntuServer Can anyone give advice on support for the Arndale touchscreen display board in that kernel base? Is it supported, or does the kernel not have graphics support for the board? I have tried to boot that kernel and it works so that I get a root shell on the serial port, but I'm now wanting to use the touchscreen as well but couldn't find support for it in that Linaro kernel. Can anyone confirm this? Thanks for any pointers, Simon

12 years, 5 months

Performance counter's value is 0,why?

by Peng Fan

hardware platform :* Pandaboard ES Rev B1.* Processor: *Omap4460*. software Version :* linaro-12.10* kernel config: android_omap4_defconfig. I changed a few options in order to use perf. *CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y CONFIG_HW_PERF_EVENTS=y* The command `Perf stat echo "linaro"` gives such results. root@android:/ # perf stat echo "linaro" linaro Performance counter stats for 'echo linaro': 269.561767 task-clock # 0.148 CPUs utilized 10 context-switches # 0.000 M/sec 1 CPU-migrations # 0.000 M/sec 105 page-faults # 0.000 M/sec 29678044 cycles # 0.110 GHz 0 stalled-cycles-frontend # 0.00% frontend cycles idle 0 stalled-cycles-backend # 0.00% backend cycles idle 0 instructions # 0.00 insns per cycle 0 branches # 0.000 M/sec 0 branch-misses # 0.00% of all branches 1.823486284 seconds time elapsed I use the option `-v`, and I can see that the first number of branches, instructions branch-misses and so on is zero.why? root@android:/ # perf stat -v echo "linaro" linaro task-clock: 93902590 93902590 93902590 context-switches: 9 93902590 93902590 CPU-migrations: 0 93902590 93902590 page-faults: 104 93902590 93902590 cycles: 4284725 76202392 76202392 stalled-cycles-frontend: 0 76202392 76202392 stalled-cycles-backend: 0 76202392 76202392 instructions: 0 76202392 76202392 branches: 0 76202392 76202392 branch-misses: 0 76202392 76202392 Performance counter stats for 'echo linaro': 93.902590 task-clock # 0.282 CPUs utilized 9 context-switches # 0.000 M/sec 0 CPU-migrations # 0.000 M/sec 104 page-faults # 0.001 M/sec 4284725 cycles # 0.046 GHz * 0 stalled-cycles-frontend # 0.00% frontend cycles idle 0 stalled-cycles-backend # 0.00% backend cycles idle 0 instructions # 0.00 insns per cycle 0 branches # 0.000 M/sec 0 branch-misses # 0.00% of all branches * 0.332550049 seconds time elapsed Can anybody give me suggestions?How can I use perf to get the value of hardware performance counter

12 years, 5 months

Re: ACPI 5.0 implementation for armv7 and armv8 archoitecture

by Leif Lindholm

Hi, > I am planning to implement ACPI5.0 on an SOC having Cortex A5 and > Atlas cpu( based on armv8 architecture) running linux on top of > them. Will they both be needing ACPI? Cortex-A5 is an ARMv7 processor. > As per the ACPI 5.0 hardware specification(Fixed Hardware/ Generic > Hardware model) of ACPI5.0, the processor needs to support various > low power modes(C0, C1, C2, C3) and sleep states(S1, S2, S3, S4, S5) > via register interfaces as well as OEM provided AML(ACPI Machine > Language). OK. > Therefore, which instructions in armv7 and armv8 put the processor > into the afore-mentioned low power modes and sleep states? > ( The arm instruction manual specifies "wfe" and "wfi" to put the > processor in a sleep state, but I am not sure if this confirms to > the ACPI 5.0 requirements ) As I see it, C0 and C1 are straightforward enough: C0 is "running" and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for S1-S5. ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html (free registration required). It does not however contain ACPI-specific information. > Besides, does arm provide any AML(ACPI Machine Language) code to put > the processor to low power modes? If not, then how do we create an > ACPI machine language code for armv7 and armv8 architecture and do > we have an AML interpreter for armv7 and armv8 architecture? Not as far as I'm aware. Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. / Leif

12 years, 5 months

[ACTIVITY] (Dong Aisheng) 2012-11-20 - 2012-12-03

by Dong Aisheng

* KVM/ARM VGIC state saving and restoring implementation. Completed the initial RFC patch and sent it out. [RFC PATCH 1/1] KVM: ARM: add vgic state save and restore support During the implementation, I met a lot issues and some of them were hard to make decision. There're two different ways to implement such function, however, each way has different issues. I currently can not make sure which one is better. So i raised them in the RFC patch and request for people's comments and suggestions.

12 years, 5 months

[ACTIVITY] (Rajanikanth H V) 2012-11-26 to 2012-11-30

by Rajanikanth HV

==== Activity Summary ==== - Communicated final patch to anton regarding ab8500 BM devices which is over the - Communicated detailed observation with possible suspect on snowball ethernet issue to linus, lee. lee suggested a clk related patch(http://paste.ubuntu.com/1396710/) from linus which did not help - Discussion with arnd on Runtime size analysis, finalized steps to analyze and test, updated blueprint accordingly. - Discussion with shawnguo regarding i.MX support for runtime size information, understood that some of the drivers does not support module build, same with u8500 as well - Completed first cut Static data gathering from vmlinux across all the platforms ==== Plan ==== * Work on runtime on zImage size analysis across U8500, OMAP, VExpress and i.MX * Discuss with arnd on runtime size analysis under the case where some of the drivers does not support module build ==== Issues ==== -- NA --

12 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel