The Linaro Kernel Working Group (KWG) is excited to announce the
availability our January 2012 development snapshot:
linux-linaro-3.2-2021.01-0
As the word "snapshot" implies, these are meant as development kernels
and have not been fully validated. You should expect issues and to help
us deliver a better kernel in the future, please file bugs in Launchpad at
https://bugs.launchpad.net/linux-linaro.
This is our first kernel release run by Andrey Konovalov and I want to
thank him for getting up and running in short time period and getting
this release out the door. Andrey will be creating a 3.3 tracking branch
soon and we can then start merging code from the other WGs and LTs to
provide a common baseline for the 2012.02 release.
The source tarball is available at:
http://launchpad.net/linux-linaro/3.2/3.2-2012.01/+download/linux-linaro-3.…
The kernel sources can also be accessed using git at:
git://git.linaro.org/people/ynk/linux-linaro-tracking.git
tag: linux-linaro-3.2-2012.01-0
This kernel includes the following changes from the 2011.11 kernel:
- Update to 3.2.1 stable kernel
- Various patches from 3.3-rc1 and other trees:
- Restart code cleanup (Russell King)
- Config fragment support (John Stultz)
- Pinctrl updates (Dong Aishang, Rajendra Nayak, Linus Walleij)
- Thermal cpu cooling branch from PMWG (Amit Kacchap, Jaecheol Lee)
- LPAE support (Catalin Marinas)
- MULTI_IRQ_HANDLER support (Marc Zyngier)
- ioremap() consolidation (Nicolas Pitre)
A full change log against the 3.2.1 release is available at:
http://launchpad.net/linux-linaro/3.2/3.2-2012.01/+download/CHANGELOG-linux…
High Priority Known Issues:
- None at this time
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev
Questions? https://ask.linaro.org/
Hi,
Currently we are playing with Linaro in combination with a pandaboard, it
looks great but we have some follow-up questions.
Using Linaro-Android 11.12 we have noticed that it launches in phone mode
with a low resolution.
Is there a possibility to launch it in tablet mode and increase the
resolution to 1920x1080?
On the omappedia wiki is described how to set the bootargs for the
pandaboard through editing the boot.scr, but the result was a black screen,
on both DVI and HDMI.
Do you have some good suggestions that will help us continue?
With kind regards,
Mark Kuipers
Ion Aalbers
Enclosed please find the link to the Weekly Status & Individual Activity
reports
for the kernel working group for the week ending 2012-01-20
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2012-01-19
<https://wiki.linaro.org/WorkingGroups/Kernel/Status/2012-01-12>
== Individual Activity Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2012-01-13
<https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2012-01-06>
== Summary ==
(For more details, please see the Status report or the Individual Activity
report above)
* Working on Linaro-kernel transition, this month release will be the
first release based
on Andrey Linaro-kernel-tracking release.
* Device Tree
* Started looking at the DT support for imx audio driver.
The first step would be consolidating SSI driver between PowerPC family
and
i.MX family. Working on making the PowerPC driver work for i.MX,
since the DT support is already there.
* pinctrl DT binding is approaching some level of agreement, after an
extensive
discussion with Stephen Warren, Aisheng and Shawn, Stephen came up
with a draft proposal based on the discussion, which should work at
least for imx and tegra.
* Storage
* Data tag patch pushed to mmc-next
* Debug session together with Venkat for the BKOPS issue
* Context ID patch prepared. Internal review ongoing
* Android
* Started work on a range-tree algorithm for better managing the volatile
page ranges used with the fadvise volatile mapping alternative to ashmem.
* Got buy in from alternative monotonic evdev input timestamp patch.
* Sent a small missing patch for Android lowmemory
http://lkml.org/lkml/2012/1/13/251
* Performed some low memory killer behaviour tests regarding how it
handles full file cache conditions, looking at why it starts killing
processes
* kconfig
* Merge_config.sh script is ready for merging, it is now with the kbuild
maintainer and not to Linus, so its unlikely to make it in for 3.3.
* Reposted merge_config.sh script and sent it to Andrey for inclusion
into the linaro kernel.
* misc
* Reviewed charger manager and TI LP8727 drivers. This is now all in
mainline via this pull request: http://lkml.org/lkml/2012/1/10/514
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Enclosed please find the link to the Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2012-01-20
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2012-01-19
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2012-01-18
== Summary ==
(For details, see the Weekly Status Report and Meeting Minutes )
* Thermal Management
* Submitted a patch that uses the temperature information in thermal
layer to generate useful information like temperature drop per cooling
state.
* Submitted v2 and v3 of the imx6q thermal driver
* hrtimer
* Submitted patches to implement core high-res timers feature to return
time spent in usleep_range(). Need feedback in order to know how to
proceed.
* Sched_mc
* Continue test/improvement of sched_mc, waiting for the integration of
a smp cpuidle driver on Panda to consolidate the results.
* Continue discussion about the scheduler, how to improve the scheduler
for power savings.
* Preparing for the scheduler mini-summit at the up coming Connect in
San Francisco
* Cpuidle
* Provided new assembly routine and worked on the standby function for
at91 factoring out the code.
* Issue
* Team is not getting fast enough feedback on their patches.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
FYI - see below.
Mathieu.
-------- Original Message --------
Subject: Re: Latest kernel build information for snowball
Date: Thu, 19 Jan 2012 13:53:26 -0700
From: Mathieu Poirier <mathieu.poirier(a)linaro.org>
To: users(a)igloocommunity.org
Sharad and friends,
I have updated the build instructions. You will find the latest and
greatest here:
https://wiki.linaro.org/Platform/Android/snowballAcceleratedGraphics
I also included a section that indicates how to find the exact SHA of a
kernel for a given build number.
As usual question, complaint and rants can be sent to me via email or
openly in #igloo.
Mathieu.
On 12-01-19 05:56 AM, Sharad Srivastava wrote:
> Hi,
>
> I would like to build the latest stable kernel release for snowball, for
> which I am trying to gather some information such as;
>
> 1. Location of the git repository for the latest source code .
>
> 2. The tag to use to check out the code.
>
> 3. The .config file to use for building the kernel source code.
>
> regards,
> sharad.
>
>
>
>
> _______________________________________________
> users mailing list
> users(a)igloocommunity.org
> http://igloocommunity.org/cgi-bin/mailman/listinfo/users
Arvind,
Thanks for taking and publishing the notes from our discussion.
The following are additional notes for the STM metadata discussion:
STM Framework Spec version .4 uses the STP 2.0 Mark packets for driver generated binary messages primarily for broadcasting context changes (process id) on an STM channel. So no plan to use Mark packets for metadata. We are currently using a dedicated channel for metadata (for processing hw generated STM messages), which worked out very efficiently for our decoder. Since we would use a dedicated channel for metadata, I don't see any reason not to simply use the basic byte-stream message format to broadcast metadata.
For broadcasting metadata into an ETB, there is a solution Michael and I talked about last week that I forgot to mention during our discussion. We can simply store the metadata in a debugfs file when routing to the ETB. We may need to use some other switch to determine this since routing through the first level of trace funnel may be all we should handle from the STM drivers. Would also need an interface (another debugfs file) that allows user mode libraries to hand off metadata to the driver.
We also touched a bit on the possibility of metadata providing a descriptor for binary data allowing for generic decoding beyond simple string data. This may be a good solution for decoding tracepoints since they broadcast binary data on a dedicated channel. Adding sw message metadata would mean that a STM channel would have to be dedicated to a specific data type, which is something OST headers avoid.
Other than additions to the spec for metadata support I don't recall anything in our discussion that would cause me to modify the STM Framework spec. I have started implementation so would like to get feedback on the .4 spec as soon as possible.
Thanks,
Doug
________________________________
From: Arvind Chauhan [mailto:Arvind.Chauhan@arm.com]
Sent: Wednesday, January 18, 2012 6:51 AM
To: Deao, Douglas; Ian Spray; Robin Randhawa; John Horley; Al Grant; Ashwin Namjoshi
Subject: Meeting Minutes: Discussion on STM framework proposal (17 January 2012)
Minutes - Discussion on STM framework proposal
Present: Linaro: Deao Douglas; ARM: Ian Spray, John Horley, Robin Randhawa, Al Grant, Aswhin Namjoshi, Arvind Chauhan
Local Decode
* Doug mentioned about a requirement for local decode, where some customers want to capture data in ETB and decode locally.
o Use cases: Power and Bus profiling - (hardware messages)
o Easier to explain to customers in terms of use cases than about STM details - they look at it as just another driver to get trace data out
* Ian provided views on ETB decode being not an optimal option
Trace Ecosystem
* Discussion on how rest of Coresight world fits together, in terms of configuring other sub-systems like funnel, replicators to get trace data out reliably
o Doug mentioned that current view is to have these modules sit side-by-side together in a system - STM specifics taken care of by STM Framework driver, like so by respective drivers. These various drivers may not be interacting a lot beyond init
* Question: Is it part of Linaro's remit to look at overall Coresight components (not just STM)?
o Answer from Doug: Not particularly.
* Ian emphasized the point that it's very important to address overall trace ecosystem view beyond STM framework driver and testing
o At least getting the high level overview written down will help in guiding how everything fits together
o Doug is open to considering this aspect.
* Question: Can ARM put some thoughts together, maybe expand initial section of STM framework driver spec to cover overall trace flow?
o This may lead to future blueprints, increased scope.
o Ian to see if some text can be put together
Validation Platform
* Local decode setup: STM framework driver + OMAP Plugins + Standalone decoder + User mode library to configure ETB + OMAP4 Platform, OMAP5 in future
o Pandaboard can be an option
Roadmap
* Doug mentioned that though most of their customer/tools are for local decode, 'agrees that there does exist valid case for transferring trace data to host machine/tools for processing
* Roadmap mentions about LTTng etc. - so not just limited to local decode
Metadata channel
* Question: Any plans of reserved block of channels for metadata? Ver 0.4 of STM Framework spec doesn't give any details on metadata channel.
o Doug mentioned that it's not included in current spec - looking at using mark packet - were not in favor of metadata transport, as OST headers were supported that describes data for TI's decoders
o Don't see a strong need for broadcasting metadata for software messages - have found it useful lately for hardware messages
o Challenge to determine when to broadcast, as metadata may flood buffers - so reluctant for software messages
* Standard required for software and hardware message descriptions - difficult for hardware messages
o Ian to send a note on metadata approach
* Ian updated on need for metadata - 'not so much for dynamic channel reallocation, but more for external debugger attached and tools to identify trace data
Message Format
* Key to interoperability is with message formatting - Not specific to one OS (Linux), OS level interoperability is a goal
* Hardware messages may be vendor specific
* Linaro may develop standard set of decoders
* Not thought much on standardization yet
Security aspects
* Not much thought given to security aspects of STM framework driver at this stage.
* Point of consideration from Doug - STM exports data, no way to broadcast it back in to change system state; Also, will security be important while debugging/profiling?
Integration with Perf
* Robin asked about plans for integration with tools like perf
o Doug mentions it's on the roadmap
* Ian described why perf is not ideal as a STM use case
* Robin discussed about when a developer makes a call to use perf vs trace flow around STM
o Is it that STM gets used for fine grained tuning?
? Doug updated that it depends on use case and trace using STM is relevant for all debug/profiling - not necessarily for only fine grained tuning
As we ran out of planned 1hr, we had to cut short our discussions. Let me know if we need to schedule another phone discussion.
Please add/modify with your comments - I may have missed stuff.
Best regards,
Arvind
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
