Enclosed please find the link to the Meeting Minutes & Weekly Status report
for the Power Management working group for the week ending 2011-08-26.
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-08-31
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-01
== Summary ==
* Made hotplug power measurements on st-e u8500 platform
* mp3 playback test showed between 7 to 8% power improvement
* cpuhotplug - For Linux idle case, no visible improvement as power is
already very low
* Finished GPIO support in power debug.
* linaro-pm-qa integration with LAVA went well, we should start seeing a
daily test of power management suite
* Published git tree containing common Samsung save and restore code
* Preparing thermal framework for upstreaming and preparing slides for
Plumbers conference
* Started to work on integration of thermal with OMAP4460 power management
* Re-writing cpuidle driver
* Started design work on struct clk, created some notes and design points
for discussion at LPC
* Rebased PMWG kernel git tree to 3.1-rc4
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>
Hi All,
As a reminder, please register and organise your attendance at Linaro
Connect Q4.11 as soon as possible. In particular:
· if you're going to need a visa you should register now so we can
get the process going with your respective embassy
· if you need internal company approvals for attendance, make sure
its underway - and let me know if you need any additional supporting
information
· if you are a Canonical secondee to Linaro, you should register to
Linaro Connect (not UDS)
The hotel registration and booking details are now here:
http://connect.linaro.org/events/event/linaro-connect-q411/
Schedule information should be following in the next couple of weeks, I'll
send an update when they are available.
Thx
Stephen Doel
Chief Operating Officer
T: +44 1223 45 00 23 │ M: +44 77 66 014 247
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook
<http://www.facebook.com/pages/Linaro/155974581091106> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
Status: https://wiki.linaro.org/OfficeofCTO/WeeklyReport
Last Meeting minutes: https://wiki.linaro.org/OfficeofCTO/2011-08-30
Not much to report as many were either on vacation or just returning
from vac.
Highlights:
ARMHF: build farm setup for the Freescale quickstart boards used. Build
farm is now ready - just waiting to be fit in a machine room at ARM.
On the Debian hardfp build: mono/armhf has been uploaded.
chromium-browser fails checking why, building both qtwebkit/webkitgtk+
now manually. Konstantinos also reported that he needs to get some 180
packages to be built to reach past the 90% mark
Boot architecture: meetings scheduled to restart on the week after LPC.
Best,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Enclosed, please find a link to the agenda, notes and actions from the Linaro
Release Weekly meeting held on September 1st in #linaro-meeting on
irc.freenode.net at 16:00 UTC.
== Meeting Minutes ==
http://wiki.linaro.org/Cycles/WeeklyReleaseMeeting/2011-09-01
== Meeting Log ==
http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2…
== Previous actions items ==
* fabo to sync with pfalcon/asac to get more space for android builders - DONE
RT#87 opened, space extended to 30G. RT#90 opened, quote of additional hard
drives INPROGRESS.
== Agenda ==
* Current focus:
the list of components delivered for this cycle is up-to-date - INPROGRESS
the milestone pages for this cycle are created - DONE
the blueprints are targeted to this cycle - INPROGRESS
the blueprints have a headline and an acceptance criteria - INPROGRESS
REMINDER: the headlines should be worded nicely to figure on the release
notes/announcement highlights and minimize re-wording.
* Toolchain WG release date
Dev Platform and Android would like to have the toolchain released 2 weeks
before Linaro release. 3rd Thursday vs last Thursday: delay varies. Sometime
it's a week, sometime it's 2 weeks.
* Release dashboard available on the wiki:
http://wiki.linaro.org/Cycles/1109/Release/Dashboard
* Next week:
- call for testing on Monday (using form, lava-qatracker will be used as soon
as available).
- release response team setup.
== Image status ==
* disk space issues raised for Ubuntu and Android builders. It's planned to
add additional hard drives for both. See also RT#86, RT#87 and RT#90.
== Bugs ==
* http://bugs.launchpad.net/bugs/709245 High
ARM SMP scheduler performance bug
=> Tracked by jcrigby
* http://bugs.launchpad.net/bugs/732912 High
omapdss DISPC error: GFX_FIFO_UNDERFLOW
=> Tracked by mounir/doanac; fixed according to doanac
* http://bugs.launchpad.net/bugs/753878 High
Ubuntu image - icons and parts of screen disappear with Origen
=> Assigned to rsalveti
* http://bugs.launchpad.net/bugs/754254 High
imx51 randomly truncates serial input at 31 characters
=> Waiting for springz
* http://bugs.launchpad.net/bugs/788746 High
Ethernet is not enabled be default
=> Assigned to mpoirier
* http://bugs.launchpad.net/bugs/807230 High
ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07
=> Assigned to vishal
* http://bugs.launchpad.net/bugs/816491 High
System crashes when display attempts to sleep
=> Waiting for agreen
* http://bugs.launchpad.net/bugs/816638 High
Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's
linaro LEB and 3.0.0-1402-linaro-lt-omap
=> Assigned to rsalveti, kan_hu is helping
* http://bugs.launchpad.net/bugs/823313 High
Android LEB fails to mount system and user partition interminttently
=> Assigned to philang
* http://bugs.launchpad.net/bugs/829220 Critical
linaro-media-create fails for snowball_emmc
=> Fixed but trigger another issue, mpoirier to comment
* http://bugs.launchpad.net/bugs/832356 High
LT-Panda 11.07/08 lacks device tree support
=> Assigned to rsalveti
* http://bugs.launchpad.net/bugs/832397 High
add Origen support to linaro-android-media-create
=> Fix committed but not released
== Action items ==
* mounir to open the discussion with michael hope about toolchain release date.
* james_w/pfalcon/fabo to follow-up closely on disk space issues, quote of
hardrive.
== People present ==
fabo
pfefferz
rsalveti
james_w
mounir
plars
ibiris
doanac
mpoirier
tgall_foo
uahmad
--
Fathi Boudra
Linaro Release Manager | Platform Project Manager
Linaro.org | Open source software for ARM SoCs
So being on vacation for a few days and checking my mail and have found
an explosion of emails. Unfortunately most of them are duplicates.
It seems the linaro-dev list isn't configed to avoid mailing folks who
are already recipients of the email. So if you're on linaro-dev and
you're also To/CC'ed in the email, you get it twice (three times if your
other work email was CC'ed as well, but that cannot be helped).
Is this something that can be easily resolved? I really don't know much
about maillist servers, but I do know I've not had this issue on other
mailing lists. So it should be possible.
Thoughts? (but don't CC me! :)
-john
Patch 1: It fixes the incorrect card detection type.
Patch 2: It enables secondary MMC port.
Patch 3: It extends support of 8-bit bus width
The patches are rebased to for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
Tushar Behera (3):
ARM: EXYNOS4: Fix sdhci card detection for ORIGEN
ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN
ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN
arch/arm/mach-exynos4/Kconfig | 1 +
arch/arm/mach-exynos4/mach-origen.c | 19 ++++++++++++++++---
2 files changed, 17 insertions(+), 3 deletions(-)
--
1.7.4.1
Hi all,
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm
seeing basically a very very small number of samples being recorded...
as in there's no way this is right.
Log:
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset
Signalling daemon... done
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start
Profiler running.
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg
~linaro/Saturn.jpg > /dev/null
Decoding took 1216 ms
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg
~linaro/Saturn.jpg > /dev/null
Decoding took 1206 ms
root@linaro-desktop:/home/linaro/ltj-1.1.90-d#
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg
~linaro/Saturn.jpg > /dev/null
Decoding took 1207 ms
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg
~linaro/Saturn.jpg > /dev/null
Decoding took 1212 ms
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop
Stopping profiling.
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg
Overflow stats not available
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples % symbol name
1 100.000 put_pixel_rows
I'll pull the latest and retry still, this I think is the11.07
ubuntu-desktop LEB release for panda (or pretty close)
uname -a
Linux linaro-desktop 3.0.0-1001-linaro-omap #1~ppa~natty-Ubuntu SMP
PREEMPT Mon Jul 25 22:44:36 UTC 2011 armv7l armv7l armv7l GNU/Linux
Thanks!
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hi Rob,
> + flipping between multiple back buffers, perhaps not in order (to
> handle video formats with B-frames)
Oh, yes please. The closed source drivers seems to do this also all the
time, and I never really understood why DRI is limiting the buffers to
the OGL attachment points.
...
> Current solutions use the GPU to do a scaled/colorconvert into a DRI2
> buffer from the client context. The goal of this protocol change is
> to push the decision to use overlay or GPU blit to the xorg driver.
You left one corner case out, HDMI allows for the framebuffer to be in
YUV 4:4:4 format. So it is possible to send YUV data to the display
(usually a TV) without color conversion at all, but I think with the
current state of X we are years away from that.
...
> In many cases, an overlay will avoid several passes through memory
> (blit/scale/colorconvert to DRI back-buffer on client side, blit to
> front and fake-front, and then whatever compositing is done by the
> window manager). On the other hand, overlays can often be handled
> directly by the scanout engine in the display hardware, with the GPU
> switched off.
Actually AMD has thrown out the hardware support for overlay with the
R7xx (or was it evergreen?) series, because they got support for turning
shader pipes off separately and figured out that it use less power to
turn off all shaders except one and then use this one for color
conversion and scaling, compared to having a distinct hardware block
doing the job. But there are tendencies to get a distinct color
conversion block back again.
...
> Note: video is not exactly the same as 3d, there are a number of other
> things to consider (scaling, colorconvert, multi-planar formats). But
> on the other hand the principle is similar (direct rendering from hw
> video codecs). And a lot infrastructure of connection, authentication,
> is same. So there are two options, either extend DRI2 or add a new
> protocol which duplicates some parts. I'd like to consider extending
> DRI2 first, but if people think the requirements for video are too
> much different from 3d, then I could split this into a new protocol.
If you ask me extending things seems the better way to do this.
..
> @@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
> These values describe various attachment points for DRI2
> buffers.
>
> + In the case of video driver (DRI2DriverXV) the attachment,
> + other than DRI2BufferFrontLeft, just indicates buffer
> + number and has no other special significance. There is no
> + automatic maintenance of DRI2BufferFakeFrontLeft.
I think that will created compatibility problems with existing
implementations, because the DDX side doesn't know if it's talking to a
video or 3D client side.
...
> + The "XV_OSD" attribute specifies the XID of a pixmap containing
> + ARGB data to be non-destructively overlayed over the video. This
> + could be used to implement subtiles, on-screen-menus, etc.
Why an XID? I'm not 100% sure about it, but using a DRI buffer name
directly here seems to be the better alternative.
> > Are you targeting/limiting this to a particular API (or the customary
> > limitations of overlay HW)? I ask because VDPAU allows clients to pass
> > in an arbitrary colour conversion matrix rather than color
> > standard/hue/sat/bri/con, so it wouldn't be possible to use this in
> > that context.
>
> Ideally it would something that could be used either from
> device-dependent VDPAU or VAAPI driver back-end, or something that
> could be used in a generic way, for example GStreamer sink element
> that could be used with software codecs.
AFAIK DRI mostly isn't a device driver dependent protocol, and the
client side doesn't necessary know to which hardware it is talking, just
look at how gallium 3D is working, talking with X over the DRI protocol
is part of the driver independent state tracker, and NOT part of the
driver itself.
So having this driver independent is just a must have, and not optional.
> Well, this is the goal anyways. There is one slight other
> complication for use in a generic way.. it would need to be a bit
> better defined what the buffer 'name' is, so that the client side
> would know how to interpret it, mmap it if needed. But I think there
> is a solution brewing:
> http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html
That's indeed true, but currently it is the only parameter that must be
interpreted in a driver dependent fashion. And I really think it should
stay that way.
> As far as color conversion matrix... well, the attribute system can
> have arbitrary device-dependent attributes. In the VDPAU case, I
> suppose the implementation on the client side knows which xorg driver
> it is talking to, and could introduce it's own attributes. Perhaps a
> bit awkward for communicating a matrix, but you could in theory have
> 4*3 different attributes (ie. XV_M00, XV_M01, ... XV_M23) for each
> entry in the matrix.
Yes, but you should define that clearly in the protocol, we also need
something to make the client side know what is supported: individual
values or matrix or both?
> > Also in general, their compositing API is a lot more
> > flexible and allows for a background + multiple layers, rather than
> > just a single layer. I suppose you could pre-flatten the layers into a
> > single one, but the background would be problematic.
>
> Yeah, pre-flatten into a single layer, I think. I mean, we *could*
> push that to xorg driver side too, but I was trying to not make things
> overly complicated in the protocol.
>
> I'm not sure I caught the issue about background.. or are you
> thinking about video w/ AYUV? Is there any hw out there that supports
> overlays w/ YUV that has an alpha channel? If this is enough of a
> weird edge case, maybe it is ok to fall back in these cases to the old
> way of doing the blending on the client side and just looking like a
> 3d app to the xorg side. (I suspect in this sort of case you'd end up
> falling back to the GPU on the xorg side otherwise.) But I'm always
> interested to hear any other suggestions.
VDPAU indeed defines two YUVA formats you can use, but currently I
haven't seen anybody using the background picture functionality so far,
because there are just not so much YUVA videos around.
Christian.
https://wiki.linaro.org/Boards/MX53QuickStart
Sorry guys, although been pushed and pinged several times by various people
we are finally able to come up with a preliminary starting page for i.MX53
QuickStart board. It's currently very simple, and hopefully we'll get it
more detailed in the future.
Feedback is welcome!
Thanks
- eric
