Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on June 1st
in #linaro-meeting on irc.freenode.net at 15:00 UTC.
https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-06-01
New Actions:
* suihkulokki and rsalveti to discuss how to work with gles packages
with oneirc (update-alternatives? conflict/provide/replace? new
solution?)
* Dr_Who to check with help from wookey if debian is planning to
package the chromium bits
* aviksil to follow up SMARTT and create a wiki page giving more
details about the tool, how to install and how to run it
* aviksil follow up smartt with kurt to see where would be the
official place to put the code and make releases
* everyone, go over
http://status.linaro.org/natty/linaro-foundations.html and
close/postpone remaining items
Carried Over Actions:
* hrw and rsalveti to discuss with michaelh1 about a possible merge of BPs
Regards,
Tom
Developer Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
IRC) Dr_Who, tgall_foo
The Engineering Resources team has just updated information on
blueprints in the wiki. The page is the same:
https://wiki.linaro.org/Process/Blueprints
Before going further I want to clarify: The changes *do not* add
additional work to anyone. The goal was to make everyone's life a little
_easier_.
The changes were driven by feedback, experience, and discussions at UDS.
So let me first answer the "what's in it for me" question:
* consistency - in the past, information wasn't totally consistent.
The new pages should be consistent in content and also consistent
with what you here when you ask around about things.
* clarity - Linaro uses blueprints for more than one purpose and in the
past we haven't been that clear on this matter.
* one less blueprint - Linaro has sort of done 3 types of bp's:
1) Engineering Blueprint
2) Tech Requirement Blueprint
3) Session Scheduling Blueprint
The 3rd type isn't always needed now, and we've clarified when you
would need this. This will be in my yearly review as "a 50%
reduction in blueprints" :)
Summary of changes:
* the old Blueprints page you remember is now mostly contained in:
https://wiki.linaro.org/Process/Blueprints/EngineeringBlueprint
* the new main page shows you the two types of bp's and helps lead you
to the proper page in the wiki that you are needing information on.
* a new page for Tech Requirement Blueprints:
https://wiki.linaro.org/Process/Blueprints/TRBlueprint
* scheduling sessions at UDS:
https://wiki.linaro.org/Process/Blueprints/SchedulingBlueprint
* two new pages based on Mounir's past work:
https://wiki.linaro.org/Process/Blueprints/ImplementationWorkflowhttps://wiki.linaro.org/Process/Blueprints/DefinitionWorkflow
Feedback/Comments/Complaints are always welcome.
-andy
An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
---
include/drm/drm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 4be33b4..45435e3 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -36,7 +36,7 @@
#ifndef _DRM_H_
#define _DRM_H_
-#if defined(__linux__)
+#if defined(__KERNEL__) || defined(__linux__)
#include <linux/types.h>
#include <asm/ioctl.h>
--
1.7.1
Please check the status report in th wiki
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport
for more information and links.
== Team Highlights ==
11.05 release: libjpeg-turbo and smartt released. Smartt not a tarball
yet but we may get some help to get this released via a launchpad
project for this work. Need to get the individual patches from the
team sent out, in order to get feedback. Sending to patches(a)linaro.org
in order to get our patches counted to the Linaro metrics (this is
important for libjpeg-turbo as there is no libjpeg-turbo wide
community for now - we need to investigate about the upstreaming of
jpeg-turbo). Patches are right now being added to git.linaro.org.
Getting ready for the mini-summit, team has been asked to look through
the summit topics and give feedback.
Those who will not be able to attend in person, should try to get on
the conference line, and check the recorded meeting to review what was
discussed.
Suggestions for topics not covered in the agenda for the mini summit
- obviously OMX vs not-OMX vs something else
- gstreamer (0.11 or 1.0) in order to address some of the
challenges that we and other vendors have seen. Parsers
- Android work related to OMX work and the consolidation work that
the group is targeting could also be another point for the mini-summit
discussion - Kurt to discuss with Zach also on the Android pain points
and what Android folks would need to have fixed.
- Related to the Memory Management activities - 0-copy is the area
of interest in Multimedia. We will review the list of work items in
the mini-summit. As for the impact of the work to other components -
eg EGL API for video related images/surfaces may affect userspace
gstreamer APIs (or other multimedia framework) - to what extent
remains to be seen
Validation tasks (Mandeep) - looking at some new techniques for
analyzing code during optimization.
Worked on the gst-openmax with video raw format mapping
Putting together some documentation notes for the interface issues with OMX.
Uploaded the multimedia test content for 5 codecs (as indicated in
meeting minutes from 31.05.2011) - is the list of video codecs
sufficient or do we need more?
BR,
*************************************
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
*************************************
Hi Marek,
Thanks for your review.
On Friday 03 June 2011 11:23 AM, Marek Szyprowski wrote:
> Hello,
>
> On Friday, June 03, 2011 7:07 AM Tushar Behera wrote:
>
>> EHCI requires that USB support be enabled in kernel config.
>> Selecting USB_SUPPORT with S5P_DEV_USB_EHCI fixes the problem.
>>
>> Signed-off-by: Tushar Behera<tushar.behera(a)linaro.org>
>> ---
>> arch/arm/plat-s5p/Kconfig | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
>> index e98f5c5..c7e7419 100644
>> --- a/arch/arm/plat-s5p/Kconfig
>> +++ b/arch/arm/plat-s5p/Kconfig
>> @@ -87,6 +87,7 @@ config S5P_DEV_CSIS1
>>
>> config S5P_DEV_USB_EHCI
>> bool
>> + select USB_SUPPORT
>
> IMHO this is not the best way to solve this issue. The main problem is
> the fact that usb-phy.c file depends on CONFIG_USB_SUPPORT not it's own
> Kconfig entry. Please check arch/arm/mach-exynos4/Makefile. To match the
> style of other helper functions, usb-phy.c should be renamed to
> setup-usb-phy.c and get it's own Kconfig entry like
> CONFIG_EXYNOS4_SETUP_USB_PHY. Also the machine that uses it should select
> this new entry. This is really not related to CONFIG_USB_SUPPORT at all
> (one might want to have a kernel without USB support for some reason).
>
>
Ok. I will re-submit the patch.
>> help
>> Compile in platform device definition for USB EHCI
>>
>> --
>
> Best regards
--
Tushar Behera
== Weekly Status report ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-06-02
== Weekly Meetings minutes ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-05-30https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-06-02
== Summary ==
* Public plan review complete
* More investigation into hot functions in SPEC 2006
* EEMBC benchmarks have arrived
* Dave is profiling the memcpy() variants across the benchmarks
* Planning on the sync primitives is under way. Backwards compatibility is
the hard one.
* Peter has started pushing the OMAP2 patches upstream, which starts to
clear the backlog
* Other performance work is going on:
* Working on vectoriser widening multiplication
* Improving auto increment/decrement for memory accesses
* Talked with ARM's RVDS group re: sharing benchmarks and infrastructure
Regards,
Mounir
Here is a bunch of scenarii I am planning to integrate to the pm-qa package.
Any idea or comment will be appreciate.
Note the test cases are designed for a specific host configured to
have a minimal number of services running on it and without any pending cron
jobs. This pre-requisite is needed in order to not alter the expected
results.
Thanks
-- Daniel
cpufreq:
--------
(1) test the cpufreq framework is available
check the following files are present in the sysfs path:
/sys/devices/system/cpu/cpu[0-9].*
-> cpufreq/scaling_available_frequencies
-> cpufreq/scaling_cur_freq
-> cpufreq/scaling_setspeed
There are also several other files:
-> cpufreq/cpuinfo_max_freq
-> cpufreq/cpuinfo_cur_freq
-> cpufreq/cpuinfo_min_freq
-> cpufreq/cpuinfo_transition_latency
-> cpufreq/stats/time_in_state
-> cpufreq/stats/total_trans
-> cpufreq/stats/trans_table
-> ...
Should we do some testing on that or do we assume it is not up to
Linaro to do that as being part of the generic cpufreq framework ?
(2) test the change of the frequency is effective in 'userspace' mode
- set the governor to 'userspace' policy
- for each frequency and cpu
- write the frequency
- wait at least cpuinfo_transition_latency
- read the frequency
- check the frequency is the expected one
(3) test the change of the frequencies affect the performances of a test
program
(*) Write a simple program which takes a cpu list as parameter in
order to set the affinity on it. This program computes the number
of cycles (eg. a simple counter) it did in 1 second and display
the result. In case more than one cpu is specified, a process is
created for each cpu, setting the affinity on it.
(**) - set the governor to userspace policy
- set the frequency to the lower value
- wait at least cpuinfo_transition_latency
- run the test (*) program for each cpu, combinate them and
concatenate the result to a file
- for each frequency rerun (**)
- check the result file contains noticeable increasing values
(3) test the load of the cpu affects the frequency with 'ondemand'
(*) write a simple program which does nothing more than consuming
cpu (no syscall)
for each cpu
- set the governor to 'ondemand'
- run (*) in background
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- read the frequency
- kill (*)
- check the frequency is equal to the higher frequency available
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- read the frequency
- check the frequency is the lowest available
(4) test the load of the cpu does not affect the frequency with 'userspace'
for each cpu
- set the governor to 'userspace'
- set the frequency between min and max frequencies
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- run (*) in background
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- read the frequency
- kill (*)
- check the frequency is equal to the one we set
(5) test the load of the cpu does not affect the frequency with 'powersave'
for each cpu
- set the governor to 'powersave'
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- check the frequency is the lowest available
- run (*) in background
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies - - read the frequency
- kill (*)
- check the frequency is the lowest available
(6) test the load of the cpu affects the frequency with 'conservative'
for each cpu
- set the governor to 'conservative'
for each freq step
- set the up_threshold to the freq step
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- run (*) in background
- wait at least cpuinfo_transition_latency *
nr_scaling_available_frequencies
- read the frequency
- check the frequency is equal to higher we have with the
freq_step
- kill (*)
