== 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
==== 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 --
=== 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
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
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(-)
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
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
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
* 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.
