linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[ACTIVITY] (Linus Walleij) 2012-12-03 - 2012-12-10

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Hardening and lining up pinctrl patches for the next merge window. * Spent most of the week helping others: * Reviewed a patch set for device tree support on the Nomadik pinctrl driver. * Internal pinctrl workshop. * Discussed FOSS strategies. * Discussed CodeAurora's CoreSight patches. * People at my desk 24/7 asking questions. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * Had to take a day off to watch over my daughter. * Had to put time aside for internal career development. Thanks, Linus Walleij

13 years, 1 month

[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 --

13 years, 1 month

[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

13 years, 1 month

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

13 years, 1 month

[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(-)

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

[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.

13 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel